Maksym Yemelyanov, 123RF

Wer dem Charme der sehr leichtgewichtigen und sehr gut transportierbaren Virtualisierungstechnik erliegt, bekommt am Anfang des Software-Lebenszyklus tatsächlich eine Menge Vorteile zu spüren. Jeder Container-Eigner sollte aber auch vorbereitet sein auf ein dickes Ende.

Ein Großteil angestellter Entwickler muss schnell Prototypen vorweisen und im Stakkato Updates nachschieben. Da bleibt keine Zeit, sich mit Abhängigkeiten späterer Zielplattformen auseinanderzusetzen. Dass unter den Rapid-Developern die Containertechnologien am schnellsten Anhänger findet, ist kein Wunder, denn diese Anwender dürfen in einem reichhaltigen Fundus vorgefertigter und erprobter (Docker-)Container sich den aussuchen, der am besten zu ihrer künftigen Applikation passt, und ohne Umschweife mit der Arbeit beginnen.

In der Praxis verwenden viele Teams ein gemeinsames Git-Repository mit Docker-Containern, die kompatibel zur firmeneignen Policy sind. Stellt sich im Laufe der Entwicklung heraus, dass im System noch Bibliotheken oder Dienste fehlen, installiert die der Entwickler selbst nach. Im besten Fall gelingt es ihm, nur die Komponenten in den Container zu packen, die seine Anwendung benötigt. Je näher er diesem Ideal kommt, umso besser wird sich die Kiste später warten lassen – und umso geringer ist das von ihr ausgehende Sicherheitsrisiko.

Der wahrscheinlich wichtigste Tipp lautet: Dokumentieren Sie alle Installations- und Deinstalltionsschritte an Ihren Containern! Das macht es möglich, einen Container mit veralteten Komponenten einfach wegzuwerfen und mit einem neuen Container weiterzumachen.

Bei der Übergabe der neuen Applikation an die Tester und Qualitätsingenieure reicht der Entwickler statt eines Pakets mit (möglicherweise unzureichend definierten) Abhängigkeiten einfach eine Kopie seines Arbeitscontainers (besser noch: nur die Containerbeschreibungen samt Applikationsdaten) weiter; auf den PCs der Tester wird der Container ohne Murren loslaufen.

Ist er getestet, erreicht der Container “Operations” und wird ausgerollt. Es sind Bestrebungen erkennbar, dass Distributionshersteller ihre bislang Paket-basierten App-Stores auf Container umstellen – Univention beispielsweise tut dies.

Wenn die Admins verzahnt mit dem Development und den Testern zusammenarbeiten, dürfen die Beteilgten das auch Devops nennen. Container scheinen wie geschaffen dafür, weil sie hoch portabel sind und zweitens eine Abstraktionsschicht vor der Applikation einziehen.

Unklare Maintenance

Container sind jedoch nicht eitel Sonnenschein. Der erste Artikel in diesem Schwerpunkt greift gleich das schwerwiegendste Problem auf: Die Versorgung der Container mit Sicherheits- und Bug-bereinigenden Patches ist technisch schwierig und – mehr noch – nicht im natürlichen Interesse der Entwickler. Wer Container zu Kunden gibt, hat dort eventuell auch keinen Einfluss mehr auf die Geschicke der Pakete im Container.

Das Ganze ist der Preis für die Container-Vorteile beim Entwicklungsprozess. Unlösbar sind die Probleme zum Glück nicht – Magazin-Autor Martin Loschwitz hat jedenfalls mehrere Lösungswege gefunden, um nicht offenen Auges Sicherheitslücken auszuliefern.

Im nächsten Artikel begründet Autor Udo Seidel, dass Container im Unternehmen einzuführen, kein rein technisches Problem ist. Das sich mit Containern ändernde Nutzungsverhalten bedingt nämlich fast immer, dass der Teamleiter die betriebliche Organisation dahingehend umstellen muss.

Am Ende steht ein Artikel eines Unternehmensgründers. Er verrät, wie seine Entwickler und Administratoren es geschafft haben, Tausende Container auf engem Raum zu betreiben, ohne dass dabei alles zusammenbricht.