Illustration: Absmeier freepik nespix
Container sind kein Wundermittel gegen Grabenkämpfe zwischen Dev und Ops. Wer seiner IT eine Kubernetes-Plattform vor die Nase setzt, seine alte Software lieblos in Container verpackt und dann auf der Plattform auf die Reise schickt, kann nicht erwarten, dass nun der DevOps-Segen magisch auf ihn herabregnet. Gute Technologie ist wichtig, keine Frage, aber am Ende ist sie doch maximal das Mittel zum Zweck. Und für den Zweck der besseren Zusammenarbeit der Abteilungen wird man in erster Linie die Mitarbeiter abholen müssen.
Projekte, die trotz »nicht optimaler« technischer Rahmenbedingungen diesen Zweck fest im Blick haben und auch erreichen, beweisen das eindrucksvoll. Es gibt durchaus Teams, die seit Jahr und Tag DevOps auch ohne Container leben. Der Erfolg dieser Projekte hat erstmal mit Menschen zu tun: Die Grundvoraussetzung ist meist ein starkes, abteilungsübergreifendes Vertrauen, das im Zweifel erst einmal gewonnen werden will. Auch ein respektvoller Umgang miteinander sowie eine lösungsorientierte Fehlerkultur sind für erfolgreiches DevOps wichtig. Ein bereichsübergreifendes Fachwissen bei Entwicklern wie Admins und das daraus entstehende Verständnis runden das Grundlagenpaket ab. Solide Schutzmaßnahmen für die Produktionsumgebung, die Entwicklern trotzdem einen limitierten Zugang ermöglichen, gehören ebenfalls dazu: Nur so ist sichergestellt, dass sie alles sehen, was sie für ihren Job brauchen. Der Weg dahin ist nicht immer komfortabel. Es dreht sich alles ums Lernen, Verstehen und konstruktiv um die besten Lösungen ringen. Aber schließlich kommt das Team an einem Ort an, an dem es effektiver, effizienter und einfach besser arbeiten kann.
Container können bei der Reise helfen. Sie sind der gemeinsame Nenner in der Arbeit beider Abteilungen, sozusagen das gemeinsame Vokabular beider Parteien. Sie garantieren, dass sich die Test- und Betriebsumgebungen möglichst wenig unterscheiden – eine Grundvoraussetzung für effektives Testing. Für diese Umgebungen forcieren sie ein Code-getriebenes Arbeitsmodell plus Versionierung. Daher ist im Problemfall eine neue, erratische Umgebungsversion schnell wieder durch eine alte ersetzt. Das eröffnet einen gewissen Spielraum für den Zugriff durch Entwickler zwecks Problemanalyse. Gerade für dieses Vorhaben bieten Container-Plattformen wie Kubernetes und darauf aufbauende Observability-Systeme deutlich bessere Möglichkeiten.
Das alles ist machbar, vorausgesetzt die Software ist für den Container-Betrieb geeignet, was wieder ein ganz anderes Kapitel aufschlägt. So manche Legacy-Anwendung muss dafür einige Refactorings durchlaufen. Das reflexhafte Umwandeln von Monolithen in Microservices greift an dieser Stelle leider meistens zu kurz. Der Ressourcenhunger einer Anwendung ist nur ein Kriterium unter vielen. Bisweilen sind es eher unscheinbare Verhaltensweisen, mit denen eine Containerisierung nicht gelingen kann, etwa Cluster-unfähige Prozesse. Manchmal sind Container auch toleranter als gedacht und der Monolith passt mit ein paar Anpassungen doch hinein. Für eine passende Entscheidung ist in jedem Fall Augenmaß gefordert.
Aber warum eigentlich DevOps? Das Ziel ist, den Software-Lifecycle sowohl zu beschleunigen als auch die Qualität der Software zu erhöhen. Dazu müssen sich aber in erster Linie die involvierten Abteilungen vertragen. Ihnen muss bewusst sein, dass sie in einem gemeinsamen Prozess arbeiten, den sie auch gemeinsam gestalten können. Das geht auch ohne Container, aber mit ihnen eben besser. So wie sich das IT-Business entwickelt, kommen Unternehmen auch aus anderen Gründen bald nicht mehr um sie herum. Warum also warten?
Oliver Weise, Principal Software Engineer bei Consol
Das Container-Management optimieren
Illustration: Absmeier StockSnap
Kein Softwareprojekt gleicht dem anderen. Das war schon immer so und gilt selbstverständlich auch im Zeitalter von Cloud- und Container-Technologie. Eine Standardformel für das Container-Management gibt es daher nicht. Dennoch gibt es Best Practices, an die sich Entwickler und Administratoren halten sollten.
Als Docker im März 2013 veröffentlicht wurde, waren Container in der Linux-Community schon mehr als zehn Jahre im Einsatz. Dennoch hat die Nutzerfreundlichkeit und Funktionsvielfalt von Docker Container erst in den Mainstream gebracht. Eine Erfolgsgeschichte, die nun – wiederum zehn Jahre später – so einige Learnings und Best Practices hervorgebracht hat. IT-Dienstleister Consol stellt fünf der wichtigsten vor.
- Mandanten- und Verantwortungsmodell sorgfältig planen
Die Frage nach der Menge der eingesetzten logischen Cluster wird bei der Container-Orchestrierung oft zur Gretchenfrage: Während manche Administratoren meinen, ein großer Cluster für alle Projekte reiche aus, sind andere der Auffassung, dass pro Projekt ein Cluster genüge. Eine einheitliche Antwort auf die Frage gibt es nicht, da die Lösung von individuellen Bedürfnissen oder Vorlieben abhängig ist – und von den eingesetzten Tools und deren Eigenschaften. Wichtig ist eine frühzeitige und sorgfältige Planung des Verantwortungsmodells. IT-Abteilungen müssen festlegen, für welchen Bestandteil der Infrastruktur und welche Aufgaben die jeweiligen Projektteams zuständig sind und ob diese Domäne sich überhaupt eindeutig isolieren lässt. Falls sich Zuständigkeiten überschneiden, müssen die Verantwortlichen sie zu Projektbeginn klar an alle möglichen Stakeholder kommunizieren, um Missverständnissen vorzubeugen.
- Ressourcen-Verwaltung forcieren
Container-Orchestrierungstools wie Kubernetes trennen streng zwischen der zu betreibenden Software und der Hardware, auf der sie läuft. Sie nehmen Instruktionen zum Scheduling von Workloads daher erst einmal pauschal an – egal ob die notwendigen Hardwareressourcen für die Prozesse zur Verfügung stehen. Das erschwert die Kapazitätsplanung seitens der Administratoren. Es ist daher unbedingt notwendig, dass die jeweiligen Workloads die für sie benötigten Ressourcen explizit deklarieren. Nur auf diese Weise können Orchestrierungstools die Ressourcen optimal verteilen. Das ist vor allem für den Schutz regulär laufender Container wichtig: Container ohne deklarierten Ressourcenbedarf sind potenziell gefährlich für alle anderen Workloads, die auf derselben Hardware laufen.
- Automatisierung nutzen
Container-Orchestrierung hat viele Vorteile, zum Beispiel einen sehr flexiblen und zuverlässigen Betrieb. Ein wichtiger Aspekt ist allerdings auch, dass die Entwickler von Kubernetes und anderen Tools besonders die Automatisierung im Blick hatten. Daher sind heute unter anderem die Infrastrukturverwaltung über Infrastructure as Code, containerisierte Continuous-Integration-Pipelines sowie Deployments über GitOps möglich. Die verschiedenen Automatisierungsmöglichkeiten reduzieren nicht nur den manuellen Aufwand, sondern verbessern auch die Zuverlässigkeit – auf lange Sicht sogar die Nachvollziehbarkeit von Konfigurationen und deren Änderungen im Betrieb. Daher ist die klare Empfehlung, soviel zu automatisieren, wie sinnvoll möglich ist.
- Die Sicherheit stets im Auge behalten
Container Images enthalten nicht nur die auszuführende Software, sondern auch diverse Komponenten für deren Funktionalität wie beispielsweise Bibliotheken. Das ist ein großer Vorteil und erleichtert vieles, allerdings geht damit auch eine Verantwortung einher: Administratoren müssen diese Komponenten, wie die Software selbst, auf dem aktuellen Stand halten – nicht nur in deren Basis- oder Muster-Images, sondern auch in den aktiven Images, die sich gerade in Produktion befinden. Nur so können sie möglicherweise existierende Sicherheitslücken schließen und Bugs ausmerzen. Es ist daher unabdingbar, dass IT-Teams Prozesse definieren, die sie über notwendige Updates informieren, und festlegen, wie der Rollout von Updates vonstatten geht.
- Öffentliche Image-Registries mit Vorsicht genießen
Registries wie der Docker Hub sind beliebte Quellen für alle möglichen Container-Images – dort wurden und werden viele bahnbrechende Ideen getestet und entwickelt. Allerdings sollten gerade Unternehmen diese öffentlich zugänglichen Sammlungen mit Open-Source-Software mit Vorsicht verwenden, denn das Qualitätsspektrum ist breit. Neben hochprofessionellen Images von Softwareherstellern gibt es auch fragwürdige Pakete, die besser unbeachtet bleiben. Eine private Image-Registry, die Mitarbeiter mit Expertenwissen auf dem Gebiet kuratieren, ist eine bessere Alternative zur Verwendung von Images aus öffentlichen Quellen.
»Das Container-Management stellt Administratoren oft vor neue Herausforderungen«, betont Oliver Weise, Principal Software Engineer bei Consol. »Sie ergeben sich überwiegend aus den speziellen Eigenarten des Container-Betriebs. Beim Aufbau von Container-Plattformen und ihrer Verwaltung sollten Unternehmen sich daher an etablierten Best Practices orientieren: So können sie von den Praxiserfahrungen anderer Plattform-Teams profitieren.«
Weitere Informationen unter: https://www.consol.de/software-engineering/ci-cd
Oliver Weise, Principal Software Engineer bei Consol (Quelle: Consol)