Unternehmen früher oft Monate und sogar Jahre dauerten , hat das Leistungsspektrum der Cloud-Technologien in Verbindung mit DevOps-Konzepten dieses Modell unwiderruflich verändert .
Wichtige Entscheidungsträger in vielen IT-Organisationen haben das Potenzial von Containern erkannt , die Entwicklungszyklen zu beschleunigen und die Betriebskosten zu senken , insbesondere wenn sie mit der Cloud und DevOps kombiniert werden . Diese Möglichkeiten können zu einem erheblichen Wettbewerbsvorteil führen – und wenn irgendetwas die Unternehmens-IT in Bewegung bringen kann , sind es existenzielle Faktoren wir direkter Wettbewerb .
Ich habe das erst kürzlich in der Praxis erlebt , und zwar bei den jüngsten Containerprojekten , an denen ich mit den Docker-Architekten Aaron Huslage und Matt Bentley beteiligt war . Beide Projekte wurden mit den IT-Abteilungen von lange etablierten Fortune-50-Unternehmen durchgeführt . In beiden Fällen war eine umfangreiche Infrastruktur mit unzähligen Prozessen im Spiel . Trotzdem setzten sich beide stark dafür ein , Container in ihre Prozesse und Architekturen für die Anwendungsbereitstellung zu integrieren und dabei von der Expertise von Docker zu profitieren .
Mythos 3 – WIDERLEGT !
Mythos 4 : Docker-Container sind nicht so sicher wie eine herkömmliche Infrastruktur .
Dieser Mythos wird häufig noch direkter ( und weniger zutreffend ) wie folgt zum Ausdruck gebracht : „ Container sind nicht sicher “. Sicherheitsbeurteilungen sind nur unter Einbeziehung der akzeptierten Standards hilfreich : Schließlich kann absolute Sicherheit nur durch absolute Unzugänglichkeit erreicht werden . Wenn der Standard eine virtuelle Maschine wie die von VMware ist , steht außer Frage , dass Container nicht dieselbe Isolation bieten und dass es bei Docker-Containern Sicherheitslücken gibt , die geschlossen werden müssen .
Eine Tatsache , die häufig übersehen wird , ist aber auch , dass die Containerimplementierung oft zu einer entsprechenden Reduzierung von implementierten Betriebssysteminstanzen führt . Moderne virtuelle Maschinen bieten eine begrenzte Angriffsfläche . Auf jeder virtuellen Maschine wird jedoch eine Betriebssysteminstanz ausgeführt . Die gesamte Angriffsfläche jeder Instanz besteht daher aus der Kombination der VM und des Betriebssystems . Wenn ein virtualisiertes Betriebssystem kompromittiert wird , bringt es keinen wirklichen Nutzen , die Attacke auf der Hypervisor-Schicht fortzusetzen . Wird ein Docker-Container kompromittiert , erhält der Angreifer – wenn keine Standardabschottungsprotokolle ignoriert werden – nur Zugriff auf diesen einen An wendungsprozess , nicht das gesamte Betriebssystem .
Das Fazit ist , dass selbst in dieser Phase der Container-Entwicklung , in der die Sicherheit noch nicht voll ausgereift ist , sich die gesamte Angriffsfläche eines containerisierten Anwendungsstacks nicht nennenswert von der eines virtualisierten Stacks unterscheidet .
Mythos 4 – klingt plausibel , wurde aber WIDERLEGT !
Mythos 5 : Container lassen sich nicht im richtigen Maß implementieren und koordinieren .
Dieser Mythos ist wahrscheinlich am einfachsten zu widerlegen . Früher traf diese Aussage zu , wenn sie folgendermaßen ergänzt wurde : „ Container lassen sich mit vordefinierten , direkt einsetzbaren Lösungen nicht im richtigen Maßstab koordinieren .“ Doch seit der allgemeinen Verfügbarkeit von Machine , Swarm und Compose von Docker ist selbst diese ergänzte Aussage heute überholt .
Ungeachtet der Docker-Beiträge gibt es etliche aktuelle Beispiele für Container-Koordinierung , die sich in der Produktion bewährt hat – angeführt vom eigenen Entwicklungserlebnis von Google und dem daraus resultierenden Kubernetes . Nach der Übernahme von Orchard & Fig macht die Docker-API jetzt den Weg frei für die Entwicklung von Tools zur Container-Koordinierung – ein Weg , der nicht nur von Fig / Compose , sondern auch von Spotify mit Helios und New Relic mit Centurion beschritten wird .
Mythos 5 – WIDERLEGT !
Mythos 6 : Rocket und dessen Mitbewerber werden die Docker-Einführung ausbremsen .
Die Einführung und das Timing von Rocket ( Core OS ) als konkurrierendem Container-Standard veranlasste viele flüchtige Beobachter dazu , die Überlebensfähigkeit von Docker infrage zu stellen . „ Wenn Docker so toll ist “, so lautete die Argumentation , „ warum entsteht dann so schnell schon ein Konkurrenzstandard ? Schließlich hat es mehrere Jahre gedauert , bis VMware und sein Hypervisor ernsthaft herausgefordert wurden .“ Die Antwort ist ziemlich einfach : Docker , die Technologie , ist ein Open-Source-Projekt mit einer offenen API – ein Projekt , das von der gesamten Open-Source-Entwicklungscommunity vorangetrieben wird , nicht nur von Docker , dem Unternehmen . VMware wählte ein geschlosse-
42 | THE DOPPLER | WINTER 2016