{"id":35594,"date":"2019-10-31T22:05:15","date_gmt":"2019-10-31T19:05:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/gitops-sravnenie-metodov-pull-i-push\/"},"modified":"2019-10-31T22:05:15","modified_gmt":"2019-10-31T19:05:15","slug":"gitops-sravnenie-metodov-pull-i-push","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/gitops-sravnenie-metodov-pull-i-push","title":{"rendered":"GitOps: Vergleich von Pull- und Push-Methoden","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hinweis.<\/b>: In der Kubernetes-Community gewinnt der Trend namens GitOps zunehmend an Beliebtheit, was wir pers\u00f6nlich festgestellt haben, als wir<\/a><\/noindex> die KubeCon Europe 2019 besucht haben. Dieser Begriff wurde relativ neu geschaffen<\/a><\/noindex> von Alexis Richardson, dem Gesch\u00e4ftsf\u00fchrer von Weaveworks, und bezieht sich auf die Nutzung von g\u00e4ngigen Entwicklerwerkzeugen (vor allem Git, was auch den Namen erkl\u00e4rt) zur L\u00f6sung von Betriebsproblemen. Insbesondere geht es um den Betrieb von Kubernetes durch die Speicherung seiner Konfigurationen in Git und die automatische Bereitstellung von \u00c4nderungen im Cluster. \u00dcber zwei Ans\u00e4tze zur Umsetzung berichtet Matthias Jg in diesem Artikel.<\/i><\/p>\n

\"GitOps:
\n
\nIm vergangenen Jahr (tats\u00e4chlich fand dies formell im August 2017 statt \u2013 Anmerkung des \u00dcbersetzers)<\/i> Ein neuer Ansatz zur Bereitstellung von Anwendungen in Kubernetes hat sich entwickelt. Er wird GitOps genannt und basiert auf der grundlegenden Vorstellung, dass die Versionierung von Deployments in einer sicheren Umgebung eines Git-Repositoriums erfolgt.<\/a><\/noindex><\/p>\n

Die Hauptvorteile dieses Ansatzes sind folgende<\/b>:<\/p>\n

    \n
  1. Versionierung von Deployments und \u00c4nderungsverlauf<\/b>. Der Zustand des gesamten Clusters wird in einem Git-Repositorium gespeichert, und Deployments werden nur durch Commits aktualisiert. Au\u00dferdem k\u00f6nnen alle \u00c4nderungen \u00fcber die Commit-Historie nachverfolgt werden.<\/li>\n
  2. Rollbacks mit den gewohnten Git-Befehlen<\/b>. Einfach git reset<\/code> erm\u00f6glicht das Zur\u00fccksetzen von \u00c4nderungen an Deployments; fr\u00fchere Zust\u00e4nde sind immer verf\u00fcgbar.<\/li>\n
  3. Fertige Zugriffskontrolle<\/b>. Da ein typisches Git-System viele vertrauliche Daten enth\u00e4lt, legen die meisten Unternehmen gro\u00dfen Wert auf dessen Sicherheit. Entsprechend gilt dieser Schutz auch f\u00fcr die Operationen mit Deployments.<\/li>\n
  4. Richtlinien f\u00fcr Deployments<\/b>. Die meisten Git-Systeme unterst\u00fctzen von Anfang an Richtlinien f\u00fcr verschiedene Branches \u2013 zum Beispiel k\u00f6nnen nur Pull Requests den Master aktualisieren, und \u00c4nderungen m\u00fcssen von einem anderen Teammitglied \u00fcberpr\u00fcft und genehmigt werden. Wie beim Zugangskontrollsystem gelten dieselben Richtlinien auch f\u00fcr die Aktualisierungen von Deployments.<\/li>\n<\/ol>\n

    \nWie Sie sehen, bietet die GitOps-Methode viele Vorteile. Im vergangenen Jahr haben sich zwei Ans\u00e4tze besonders hervorgetan. Der eine basiert auf Push, der andere auf Pull. Bevor wir diese n\u00e4her betrachten, lassen Sie uns zun\u00e4chst anschauen, wie typische Deployments in Kubernetes aussehen.<\/p>\n

    Bereitstellungsmethoden<\/h2>\n

    \nIn den letzten Jahren haben sich verschiedene Methoden und Werkzeuge f\u00fcr Deployments in Kubernetes etabliert:<\/p>\n

      \n
    1. Basierend auf nativen Vorlagen von Kubernetes\/Kustomize<\/b>. Dies ist der einfachste Weg, um Anwendungen in Kubernetes zu deployen. Der Entwickler erstellt grundlegende YAML-Dateien und wendet sie an. Um das st\u00e4ndige Neu schreiben der gleichen Vorlagen zu vermeiden, wurde Kustomize entwickelt (es verwandelt Kubernetes-Vorlagen in Module). Hinweis.<\/b>: Kustomize wurde mit der Kubernetes-Version 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Helm Charts<\/b>Helm-Charts erm\u00f6glichen die Erstellung von Vorlagensets, Init-Containern, Sidecars usw., die f\u00fcr das Deployment von Anwendungen mit flexibleren Anpassungsm\u00f6glichkeiten genutzt werden k\u00f6nnen als im vorlagenbasierten Ansatz. Der Kern dieser Methode sind vorlagengest\u00fctzte YAML-Dateien. Helm f\u00fcllt diese mit verschiedenen Parametern aus und sendet sie dann an Tiller \u2013 die Clusterkomponente, die sie im Cluster implementiert und Aktualisierungen sowie Rollbacks erm\u00f6glicht. Wichtig ist, dass Helm im Grunde genommen lediglich die ben\u00f6tigten Werte in die Vorlagen einf\u00fcgt und diese dann auf die gleiche Weise anwendet wie im traditionellen Ansatz. (mehr dar\u00fcber, wie das alles funktioniert und wie man es verwenden kann, lesen Sie in unserem Artikel \u00fcber Helm<\/a><\/noindex> \u2014 Anmerkung des \u00dcbersetzers).<\/i>. Es gibt eine Vielzahl von fertigen Helm-Charts, die ein breites Spektrum an Aufgaben abdecken.<\/li>\n
    3. Alternative Werkzeuge<\/b>. Es gibt zahlreiche alternative Werkzeuge. Alle haben gemeinsam, dass sie bestimmte Vorlage-Dateien in verst\u00e4ndliche Kubernetes-YAML-Dateien umwandeln und diese dann anwenden.<\/li>\n<\/ol>\n

      \nIn unserer Arbeit verwenden wir st\u00e4ndig Helm-Charts f\u00fcr wichtige Werkzeuge (da sie viele Vorbereitungen bereits getroffen haben, was das Leben erheblich vereinfacht) und \"reine\" Kubernetes-YAML-Dateien, um unsere eigenen Anwendungen bereitzustellen.<\/p>\n

      Pull & Push<\/h2>\n

      \nIn einem meiner letzten Blogbeitr\u00e4ge habe ich ein Werkzeug vorgestellt Weave Flux<\/a><\/noindex>, was es Ihnen erm\u00f6glicht, Vorlagen in ein Git-Repository zu committen und das Deployment nach jedem Commit oder Push des Containers zu aktualisieren. Meine Erfahrung zeigt, dass dieses Werkzeug zu den wichtigsten f\u00fcr die F\u00f6rderung des Pull-Ansatzes geh\u00f6rt, daher werde ich oft darauf verweisen. Wenn Sie mehr dar\u00fcber erfahren m\u00f6chten, wie es verwendet wird, hier ist Link zum Artikel<\/a><\/noindex>.<\/p>\n

      NB!<\/b> Alle Vorteile der Nutzung von GitOps bleiben f\u00fcr beide Ans\u00e4tze erhalten.<\/i><\/p>\n

      Pull-basierter Ansatz<\/h2>\n

      \n\"GitOps:
      \n
      \nDer Pull-Ansatz basiert auf der Tatsache, dass alle \u00c4nderungen intern im Cluster angewendet werden. Im Cluster gibt es einen Operator, der regelm\u00e4\u00dfig die verbundenen Git-Repositorys und das Docker-Registry \u00fcberpr\u00fcft. Wenn \u00c4nderungen festgestellt werden, wird der Zustand des Clusters intern aktualisiert. Dieser Prozess gilt im Allgemeinen als sehr sicher, da kein externer Client Administratorrechte f\u00fcr das Cluster hat.<\/p>\n

      Vorteile:<\/b><\/p>\n

        \n
      1. Kein externer Client hat das Recht, \u00c4nderungen am Cluster vorzunehmen; alle Updates werden intern angewendet.<\/li>\n
      2. Einige Werkzeuge erm\u00f6glichen zudem die Synchronisierung von Helm-Charts und deren Anbindung an das Cluster.<\/li>\n
      3. Das Docker-Registry kann auf neue Versionen gescannt werden. Wenn ein neues Image verf\u00fcgbar ist, werden das Git-Repository und das Deployment auf die neue Version aktualisiert.<\/li>\n
      4. Pull-Tools k\u00f6nnen in verschiedenen Namespaces mit unterschiedlichen Git-Repositories und Zugriffsrechten verteilt werden. Dadurch l\u00e4sst sich ein multitenant-Modell umsetzen. Zum Beispiel kann Team A den Namespace A nutzen, Team B den Namespace B und das Infrastrukturteam kann den globalen Namespace verwenden.<\/li>\n
      5. In der Regel sind die Tools sehr leichtgewichtig.<\/li>\n
      6. In Kombination mit Tools wie dem Operator Bitnami Sealed Secrets<\/a><\/noindex>, k\u00f6nnen Geheimnisse verschl\u00fcsselt im Git-Repository gespeichert und innerhalb des Clusters abgerufen werden.<\/li>\n
      7. Es besteht keine Verbindung zu CD-Pipelines, da die Bereitstellungen innerhalb des Clusters erfolgen.<\/li>\n<\/ol>\n

        \nNachteile<\/b>:<\/p>\n

          \n
        1. Die Verwaltung von Deployment-Geheimnissen aus Helm-Charts ist komplizierter als mit herk\u00f6mmlichen, da sie zuerst in Form von, sagen wir, sealed secrets generiert, dann von einem internen Operator entschl\u00fcsselt werden m\u00fcssen, bevor sie f\u00fcr das Pull-Werkzeug verf\u00fcgbar sind. Anschlie\u00dfend kann ein Release in Helm mit den bereits bereitgestellten Geheimnissen gestartet werden. Der einfachste Weg besteht darin, ein Geheimnis mit allen Helm-Werten, die f\u00fcr das Deployment verwendet werden, zu erstellen, es zu entschl\u00fcsseln und in Git zu committen.<\/li>\n
        2. Mit dem Pull-Ansatz sind Sie an Tools gebunden, die mit Pulls arbeiten. Dies schr\u00e4nkt die Anpassungsm\u00f6glichkeiten f\u00fcr den Deployment-Prozess im Cluster ein. Beispielsweise wird die Arbeit mit Kustomize kompliziert, da es vor dem Hinzuf\u00fcgen der endg\u00fcltigen Vorlagen zu Git ausgef\u00fchrt werden muss. Ich sage nicht, dass man keine separaten Tools verwenden kann, aber deren Integration in den Deployment-Prozess gestaltet sich schwieriger.<\/li>\n<\/ol>\n

          <\/p>\n

          Push-basierten Ansatz<\/h2>\n

          \n\"GitOps:
          \n
          \nIm Push-Ansatz initiiert ein externes System (vorwiegend CD-Pipelines) die Bereitstellungen im Cluster nach einem Commit im Git-Repository oder nach erfolgreichem Abschluss der vorherigen CI-Pipeline. In diesem Ansatz hat das System Zugriff auf das Cluster.<\/p>\n

          Vorteile<\/b>:<\/p>\n

            \n
          1. Die Sicherheit wird durch das Git-Repository und die Build-Pipeline bestimmt.<\/li>\n
          2. Helm-Charts lassen sich einfacher bereitstellen, und es gibt Unterst\u00fctzung f\u00fcr Helm-Plugins.<\/li>\n
          3. Die Verwaltung von Geheimnissen ist einfacher, da Geheimnisse in Pipelines angewendet und je nach Benutzerpr\u00e4ferenz verschl\u00fcsselt im Git gespeichert werden k\u00f6nnen.<\/li>\n
          4. Es gibt keine Bindung an ein spezifisches Tool, da verschiedene Typen verwendet werden k\u00f6nnen.<\/li>\n
          5. Container-Versionen k\u00f6nnen \u00fcber die Build-Pipeline aktualisiert werden.<\/li>\n<\/ol>\n

            \nNachteile<\/b>:<\/p>\n

              \n
            1. Zugangsdaten zum Cluster befinden sich innerhalb des Build-Systems.<\/li>\n
            2. Die Aktualisierung von Containern in Deployments l\u00e4sst sich nach wie vor einfacher mit einem Pull-Prozess durchf\u00fchren.<\/li>\n
            3. Es besteht eine starke Abh\u00e4ngigkeit von der CD-System, da die ben\u00f6tigten Pipelines m\u00f6glicherweise urspr\u00fcnglich f\u00fcr Gitlab Runners geschrieben wurden und das Team dann entscheidet, zu Azure DevOps oder Jenkins zu wechseln\u2026 was eine Migration einer gro\u00dfen Anzahl von Build-Pipelines erforderlich macht.<\/li>\n<\/ol>\n

              <\/p>\n

              Fazit: Push oder Pull?<\/h2>\n

              \nWie so oft hat jede Herangehensweise ihre Vor- und Nachteile. Einige Aufgaben lassen sich leichter mit einer Methode umsetzen, w\u00e4hrend andere eine andere Vorgehensweise erfordern. Zun\u00e4chst habe ich Deployments manuell durchgef\u00fchrt, aber nachdem ich auf einige Artikel \u00fcber Weave Flux gesto\u00dfen bin, entschied ich mich, GitOps-Prozesse f\u00fcr alle Projekte einzuf\u00fchren. F\u00fcr die grundlegenden Templates war das einfach, doch dann stie\u00df ich auf Herausforderungen im Umgang mit Helm-Charts. Zu dieser Zeit bot Weave Flux nur eine sehr rudiment\u00e4re Version des Helm Chart Operators an, aber selbst jetzt sind einige Aufgaben komplizierter, da man Geheimnisse manuell erstellen und anwenden muss. Man k\u00f6nnte sagen, dass der Pull-Ansatz viel sicherer ist, da die Cluster-Zugangsdaten au\u00dferhalb des Clusters nicht zug\u00e4nglich sind, was die Sicherheit so sehr erh\u00f6ht, dass sich der zus\u00e4tzliche Aufwand lohnt.<\/p>\n

              Nach einigem Nachdenken bin ich zu einer unerwarteten Erkenntnis gelangt: Das ist nicht der Fall. Wenn es um Komponenten geht, die maximalen Schutz ben\u00f6tigen, geh\u00f6ren dazu geheimnisvolle Speicher und CI\/CD-Systeme sowie Git-Repositories. Die Informationen darin sind recht anf\u00e4llig und bed\u00fcrfen gr\u00f6\u00dftm\u00f6glichen Schutzes. Dar\u00fcber hinaus, wenn jemand in Ihr Git-Repository eindringt und dort Code pushen kann, kann er alles bereitstellen, was er m\u00f6chte (unabh\u00e4ngig davon, ob es sich um einen Pull- oder Push-Ansatz handelt) und in die Systeme des Clusters eindringen. Somit sind die beiden wichtigsten Komponenten, die Schutz ben\u00f6tigen, das Git-Repository und die CI\/CD-Systeme und nicht die Anmeldedaten des Clusters. Wenn Sie gut konfigurierte Richtlinien und Sicherheitsma\u00dfnahmen f\u00fcr solche Systeme haben und die Anmeldedaten des Clusters nur als Geheimnisse in die Pipelines extrahiert werden, k\u00f6nnte die zus\u00e4tzliche Sicherheit des Pull-Ansatzes nicht so wertvoll sein, wie zun\u00e4chst angenommen.<\/p>\n

              Wenn der Pull-Ansatz also arbeitsintensiver ist und keinen Sicherheitsgewinn bringt, w\u00e4re es dann nicht logisch, nur den Push-Ansatz zu verwenden? Aber jemand k\u00f6nnte argumentieren, dass man im Push-Ansatz zu sehr an ein CD-System gebunden ist und es m\u00f6glicherweise besser ist, dies nicht zu tun, um zuk\u00fcnftige Migrationen zu erleichtern.<\/p>\n

              Meiner Meinung nach (wie immer) sollte man das verwenden, was am besten zum jeweiligen Fall passt oder kombinieren. Ich pers\u00f6nlich nutze beide Ans\u00e4tze: Weave Flux f\u00fcr Deployments, die auf Pull basieren, die haupts\u00e4chlich unsere eigenen Dienste einschlie\u00dfen, und den Push-Ansatz mit Helm und Plugins, der die Anwendung von Helm-Charts im Cluster vereinfacht und die Erstellung von Secrets problemlos erm\u00f6glicht. Ich denke, es wird nie eine einheitliche L\u00f6sung geben, die f\u00fcr alle F\u00e4lle geeignet ist, da es immer viele Nuancen gibt, die vom spezifischen Anwendungsfall abh\u00e4ngen. Dennoch empfehle ich GitOps nachdr\u00fccklich \u2013 es erleichtert das Leben erheblich und erh\u00f6ht die Sicherheit.<\/p>\n

              Ich hoffe, dass meine Erfahrungen zu diesem Thema Ihnen helfen, zu entscheiden, welche Methode am besten f\u00fcr Ihre Art von Deployments geeignet ist, und ich w\u00fcrde mich freuen, Ihre Meinung zu h\u00f6ren.<\/p>\n

              P.S. Hinweis des \u00dcbersetzers<\/h2>\n

              \nEin Nachteil des Pull-Modells ist, dass es schwierig ist, gerenderte Manifeste in Git abzulegen. Ein Vorteil ist jedoch, dass die CD-Pipeline im Pull-Modell unabh\u00e4ngig vom Rollout existiert und im Grunde zu einer Pipeline der Kategorie wird. Continuous Apply<\/i>. Daher wird es noch mehr Aufwand erfordern, um den Status aller Deployments zu sammeln und irgendwie Zugang zu Logs\/Status zu gew\u00e4hren, idealerweise mit Bezug auf das CD-System.<\/p>\n

              In diesem Sinne erm\u00f6glicht das Push-Modell, zumindest einige Garantien f\u00fcr das Rollout zu geben, da die Lebensdauer des Pipelines dem Rollout-Zeitraum gleichgesetzt werden kann.<\/p>\n

              Wir haben beide Modelle getestet und sind zu denselben Schlussfolgerungen gekommen wie der Autor des Artikels:<\/p>\n

                \n
              1. Das Pull-Modell eignet sich f\u00fcr die Aktualisierung von Systemkomponenten auf einer gro\u00dfen Anzahl von Clustern (siehe Artikel \u00fcber den Addon-Operator<\/a><\/noindex>).<\/li>\n
              2. Das Push-Modell basierend auf GitLab CI eignet sich hervorragend f\u00fcr das Deployen von Anwendungen mit Helm-Charts. Dabei wird das Deployment im Rahmen der Pipelines mit einem Tool verfolgt. werf<\/a><\/noindex>\u00dcbrigens haben wir im Kontext dieses Projekts st\u00e4ndig von \"GitOps\" geh\u00f6rt, als wir die dr\u00e4ngenden Probleme von DevOps-Ingenieuren an unserem Stand auf der KubeCon Europe '19 diskutierten.<\/li>\n<\/ol>\n

                <\/p>\n

                P.P.S. vom \u00dcbersetzer<\/h2>\n

                \nLesen Sie auch in unserem Blog:<\/p>\n