Camptocamp – News

Container Einführung bei Camptocamp

24 Oktober 2017

Einleitung

Container bieten Lösungen für Abstraktions- und Portabilitätsprobleme die für die IT-Welt nichts Neues sind. Containerisierung von Anwendungen ist jedoch zu einem zentralen Konzept geworden, um der stetig wachsenden Komplexität von IT-Systemen zu begegnen. Bei Camptocamp haben wir langjährige Erfahrungen in der Verwendung von Containertechnologien. Beginnend mit chroots (als Teil von Unix seit 1979 und Linux seit seiner Gründung), wechselten wir etwas später zum Linux-VServer , der bereits das Management von Rechnerressourcen anbot, und dann zu OpenVZ, das bereits 2005 eine Revolution zu sein schien.

Seit 2006 wurde im Linux-Kernel viel Aufwand betrieben, um die Ressourcennutzung (Arbeitsspeicher, CPU und IO) zu limitieren, zu priorisieren und zu isolieren. Diese Entwicklung, die auch als Cgroups (Kontrollgruppen) bekannt ist, ermöglichte sowohl die Entstehung von Linux Container (LXC) als auch Docker. Heute gibt es aber auch ernsthafte Konkurrenz für Docker, wie rkt (entwickelt durch CoreOS) oder neuerdings auch cri-o (aus dem Kubernetes-Projekt).

IT-Unternehmen wie Camptocamp können nicht eine oder mehrere Software-Lösungen nur zu einem bestimmten Zeitpunkt entwickeln und ausrollen. Das Ziel besteht vielmehr darin, vollständige Plattformen einzurichten, um während des gesamten Lebenszyklus der Anwendung die verschiedenen Lösungskomponenten zu orchestrieren und zu überwachen. Diese Plattformen sollen sowohl funktional veränderbar sein als auch hinsichtlich der Größe skalieren, um etwa einer gestiegenen Nutzerzahl gerecht zu werden. Service-Redundanz soll außerdem eine sehr hohe Verfügbarkeit der Anwendungen ermöglichen.

Anfang 2016: Umzug nach Rancher’s Cattle

Im Laufe des Jahres 2015 haben wir Docker dazu benutzt, Build-Prozesse zu isolieren und vereinzelte Host-Deployments durchzuführen, bei denen jeder Dienst ebenfalls in einem Docker-Container isoliert wurde. Mitte 2015 erkannten wir, wie wichtig und auch notwendig es für uns war, mehr über Container-Orchestrierung zu lernen. Orchestrierungssysteme lösen viele Probleme im Bereich der Verteilung von IT-Services auf mehrere physische oder virtuelle Server. Die wichtigsten Funktionen von Orchestrierungssystemen sind:

  • Netzwerk-Orchestrierung mit mehreren Hosts (Overlay-Netzwerke, Softwaredefiniertes Netzwerk)
  • Scheduling und Ressourcen-Affinität
  • Schnittstelle zu Speicherdiensten
  • Skalierbarkeit
  • Lastverteilung
  • Rolling- oder Blue Green Deployment (aktive/inaktive Umgebungen)

Ende 2015 haben wir verschiedene Analysen nach den Kriterien durchgeführt, die wir zuvor für unsere Bedürfnisse definiert hatten. Unser Ziel war es herauszufinden welches OpenSource-Orchestrierungstool für unsere Projekte am besten geeignet ist. Folgende Orchestrierungssysteme habe wir untersucht:

Die verschiedenen Tests die wir durchgeführt haben, ermöglichten es uns, einige schnell auszuschließen. Im Ergebnis konzentrierten wir uns schließlich auf Kubernetes, OpenShift und Rancher. Die Gründe werden im Folgenden kurz erläutert.

Kubernetes

Anfang 2016 galt Kubernetes (auch bekannt als k8s) als eine äußerst vollständige Lösung (abgeleitet von Googles Borg), die jedoch nur schwer zu implementieren ist. Die Idee, Standard-Docker-APIs (insbesondere Docker Compose) nicht (wieder-) verwenden zu können, störte uns jedoch. Die Eigenschaften von Kubernetes und seiner Architektur erschienen überdies unverhältnismässig in Bezug auf die Bedürfnisse unserer Teams zu dieser Zeit. Zudem glaubten wir, dass die Lernkurve für unsere technischen Teams wahrscheinlich zu steil wäre.

OpenShift

Als Red Hat Partner war Camptocamp natürlich sehr an dieser Lösung interessiert. Umso mehr, als OpenShift ab Version 3 um Kubernetes neu entwickelt wurde. Theoretisch fügte OpenShift zu Kubernetes alle die Elemente hinzu, die notwendig sind, um Container in einem Unternehmenskontext (Authentifizierung, RBAC, Private Registry usw.) zu orchestrieren und außerdem viele weitere Funktionen, die mit dem Paradigma der kontinuierlichen Entwicklung verbunden sind. Nach dem Test der Version 3.1 kamen wir jedoch zu dem Schluss, dass diese Versprechen leider nicht alle erfüllt wurden und es uns unmöglich schien, diese Lösung für Produktionsprojekte zu nutzen. Zwar gefiel uns die Idee einer Lösung in Richtung einer PaaS-Anwendungsplattform (sehr DevOps-orientiert), aber wir mussten leider feststellen, dass diese Lösung noch nicht ausgereift genug für unsere Bedürfnisse war.

Rancher

Es ist mehr ein Zufall gewesen, dass wir Rancher Ende 2015 entdeckt haben. Der erste Ansatz von Rancher bestand darin, so viel wie möglich auf Standard-Docker-APIs zu belassen. Dies vereinfacht den Umgang mit Rancher für Entwickler, die bereits Erfahrungen mit Docker gesammelt haben. Diese Einfachheit, gepaart mit einer äußerst intuitiven Management-Schnittstelle, hat uns schnell überzeugt. Im Gegensatz zu anderen Lösungen ist das Deployment von Anwendungen vollständig in Rancher integriert.

Anfang 2016 zogen wir unsere Schlussfolgerungen zur Reife dieser verschiedenen Orchestrierungssysteme , wobei uns natürlich bewusst war, dass dieser Technologiebereich sehr umfangreich ist. Technologische Entwicklungen erfolgen in der Regel so: Sie ermöglichen konkrete Antworten auf komplexe Probleme, stellen damit aber oft viele der gewohnten und bewährten Methoden in Frage. Daraus ergibt sich vielfach der Zwang zu einem Kompromiss zwischen Innovation und Stabilität.

Wir können unsere Erfahrungen, die wir bis Ende 2016 gesammelt haben, wie folgt zusammenfassen:

Kubernetes war von einem funktionalen Standpunkt aus sehr beeindruckend, sah aber mehr wie ein Orchestrierungssystem aus, als eine vollständig integrierte Lösung im Kontext eines realen Projektes.

OpenShift entwickelte sich in Richtung einer wirklich integrierten Lösung im Unternehmenskontext und nutzte die bewährten Funktionen von Kubernetes voll aus. Die Version 3.1 war jedoch noch nicht ausgereift, sie war zu sehr Platform-as-a-Service-orientiert und noch nicht genug Container-as-a-Service. Dieser Aspekt von OpenShift hat sich seitdem aber sehr verändert.

Rancher, zusammen mit seinem Orchestrierungswerkzeug Cattle, war einfach zu implementieren und erfüllte unsere Bedürfnisse zu dieser Zeit. Es erschien uns als die vernünftigste Lösung um stabile Plattformen aufzubauen und die Akzeptanz in unseren Teams voranzutreiben.

Juni 2016: Rancher/Cattle im Betrieb

Anfang 2016 haben wir begonnen, Rancher und Cattle massiv für interne Bedürfnisse zu verwenden. Nach und nach auch um eine neue Architektur von Projekten zu entwickeln und umzusetzen. Wir haben im Laufe des Jahres 2016 viel gelernt und herausgefunden, wie viel wir uns durch Docker und Rancher, sowohl technisch als auch kulturell weiter entwickelt haben. Neben der Verwaltung von verteilten Ressourcen und Diensten, waren die Möglichkeiten der kontinuierlichen Integration und Bereitstellung von Anwendungen für uns am wirkungsvollsten.

Die interne Zusammenarbeit zwischen den Verantwortlichen der Operations- und Engineering- Abteilungen erfolgte in dieser Zeit in einer ganz neuen Dimension: Mauern wurden niedergerissen und die Arbeit mit den eingesetzten Technologien brachte uns wirklich näher. Offensichtlich erfordert die Einführung von DevOps in einem Unternehmen, neben kulturellen Veränderungen, auch den Austausch von Werkzeugen und das Überdenken von Verantwortlichkeiten.

Im März 2016 begann Rancher Kubernetes und Docker Swarm als Alternativen zu seinem eigenen Orchestrierungstool Cattle vorzuschlagen. Einige unserer Projekte wurden mit Cattle in Betrieb genommen und trotz Problemen in der Anfangsphase war das Feedback durchaus positiv. Die Übernahme von Docker und Rancher hat es uns auch ermöglicht, an anderen Fronten sehr schnell voranzukommen. Aus der Sicht der Provisionierung hat die Entwicklung unserer Terraform-Integration es uns ermöglicht, den Einsatz von Rancher-Umgebungen zu automatisieren. Prometheus/Grafana hat darüber hinaus unseren Ansatz zur Überwachung von Anwendungen revolutioniert. Schließlich führte die Integration einer kontinuierlicher Entwicklung mit Jenkins in unseren Entwicklungsprojekten zu einer neuen Dynamik. All dies wurde erreicht ohne Zugeständnisse in Bezug auf Wartungsfreundlichkeit oder Sicherheit der eingesetzten Dienste eingehen zu müssen.

Beginn 2017: Kubernetes ist überall

Seit Anfang 2017 verbreitet sich die Verwendung von Containern flächendeckend. Die meisten der neuen Projekte an denen wir arbeiteten, basierten in der einen oder anderen Weise auf Docker. Im allgemeinen sind wir mit Rancher und Cattle als Orchestrierungstool zufrieden, sehen jedoch einige wenige Punkte, die es etwas einschränken, insbesondere das Fehlen einer Private Registry, ein zu begrenztes Zugriffskontrollsystem und Probleme mit der Netzwerkstabilität. Die Einschränkung in Bezug auf die Zugriffskontrolle erlaubt es uns nicht, multimandantenfähige Architekturen einzurichten, die eine Voraussetzung dafür sind, eine Plattform und deren Ressourcen zwischen verschiedenen Kundenorganisationen zu teilen.

Anfang 2017 war außerdem ein Meilenstein im Kampf zwischen den verschiedenen Container-Orchestrierungsplattformen. Es wurde offensichtlich, dass Kubernetes seine Konkurrenten in Bezug auf die technischen Eigenschaften und auch hinsichtlich der Kommunikationsstrategie überholte. Charismatische Entwickler, wie der allgegenwärtige Kelsey Hightower, trugen dazu bei, die Kubernetes-Community zu begeistern und die Zahl an Mitwirkenden und Nutzern wächst stetig.

Diese starke Verbreitung von Kubernetes als de facto Container-Orchestrierungsstandard spiegelt sich auch in den Editor-Lösungen wider. CoreOS gab Fleet zugunsten von Kubernetes auf, IBM integrierte Kubernetes in seine Bluemix-Lösung und Red Hat beschleunigte die Entwicklung von OpenShift, indem es sich sehr aktiv an der Entwicklung von Kubernetes beteiligte. VMWare ist intensiv mit Pivotal am Kubo-Projekt beteiligt. Auch Rancher Labs verstärkte seine Bemühungen um Kubernetes ohne jedoch auf ihr eigenes Orchestrierungstool Cattle zu verzichten.

April 2017: OpenShift 3.5 veröffentlicht

Nach mehr als einem Jahr intensiver Arbeit an Docker/Rancher haben wir beschlossen, unsere Expertise im Bereich Kubernetes und OpenShift parallel auszubauen. Als Red Hat Partner haben wir die Möglichkeit, an verschiedenen Schulungen und Workshops in diesem Bereich teilzunehmen und nutzen diese Chance auch.

Nach einigen Wochen der Beschäftigung mit Kubernetes und OpenShift müssen wir zugeben, dass sich diese Lösungen, sowohl im Hinblick auf ihren Einsatz als auch hinsichtlich ihrer Funktionen, erheblich weiterentwickelt haben. Unser Eindruck ist im Vergleich zu unseren Tests Ende 2015 und Anfang 2016 sehr gut. Wir sind jedoch nicht vollständig überzeugt, wenn es um die notwendigen Ressourcen (die Anzahl der Server) geht, die für die Einrichtung eines Clusters erforderlich sind. Offensichtlich ist Kubernetes/OpenShift nicht wirklich an kleine Projekte angepasst. Die Verwendung von Rancher/Cattle hat für uns immer Sinn gemacht, auch wenn wir uns mehr und mehr darüber im Klaren sind, dass Rancher Labs die Cattle-Entwicklung irgendwann aufgeben wird.

Um unsere OpenShift-Fähigkeiten zu validieren, haben wir verschiedene Proof-of-Concepts entwickelt, insbesondere eine CI/CD-Plattform einer mit GeoMapFish entwickelten Lösung. Diese Demo verwendet nicht nur als Grundstock die Docker-Orchestrierung von Kubernetes, sondern auch die überwiegende Mehrheit der OpenShift-Funktionen. Insbesondere den als Source-to-Image (S2I) bekannten Docker-Image-Erstellungsprozess, die Jenkins-Integrationsmöglichkeiten sowie den an OpenShift gekoppeltenHelm zum Verkapseln der bereitgestellten Komponenten. Diese Demo wurde während des letzten Red Hat Forums präsentiert, das kürzlich in Zürich stattgefunden hat.

September 2017: Veröffentlichung von Rancher 2.0

Unser Annahmen über die Zukunft von Rancher/Cattle wurden am 26. September 2017 mit der Ankündigung von Rancher Labs bezüglich der Version 2.0 von Rancher bestätigt. Nachdem Rancher Labs verschiedene Orchestrierungswerkzeuge in seiner Lösung integriert hat, wurde beschlossen, diese Strategie zu überprüfen und sich in der neuen Hauptversion ausschliesslich auf Kubernetes zu konzentrieren. Diese Ankündigung ist beruhigend für Rancher/Cattle-Nutzer. Insbesondere wird die Cattle-Version 1.6 bis mindestens Mitte 2018 beibehalten und der Übergang zwischen Cattle und Kubernetes wird durch eine größere rückwärtskompatible Schicht erleichtert.

Die Zukunft

Die Konvergenz von Rancher in Richtung Kubernetes konnte nicht vorher gesehen werden, aber zumindest bringt sie Klarheit in eine komplexe Situation, indem sie die Bemühungen vieler OpenSource-Autoren (wie Camptocamp) um ein kohärentes Ökosystem rund um das Kubernetes-Projekt unter der Leitung der Cloud Native Computing Foundation (CNCF) berücksichtigt.

Camptocamp möchte die Bemühungen in Bezug zu OpenShift weiter verstärken, ohne aber auf andere Plattformen wie Rancher, die ebenfalls auf Kubernetes basieren, zu verzichten. Das Erstellen von Anwendungen, die auf verschiedenen Kubernetes-Clustern bereitgestellt werden können, ist sehr gut möglich. Helm geht eindeutig in diese Richtung und wir hoffen, dass unsere Erfahrung in der Entwicklung von Terraform uns in die Lage versetzen wird, zur Verbesserung von automatisierten Deployments auf Basis von Helm beizutragen.

Red Hat hat Kubernetes um extrem nützliche Dienste für On-Premise-Installationen erweitert. Die Verwendung von Containern schränkt die Wahl des Orchestrierungstools nicht ein. Viele andere (nicht nur technische) Aspekte müssen aber neu überdacht und behandelt werden und dies ist zweifellos der Grund, warum Camptocamp in den letzten zwei Jahren hier am meisten investiert und gelernt hat. Täglich setzen wir diese Erfahrung in vielen Projekten und in unseren Anwendungsplattformen ein.

  1. *
  2. *
  3. *
  4. *