{"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 der Pull- und Push-Methoden","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Anmerkung des \u00dcbersetzers.<\/b>: In der Kubernetes-Community gewinnt der Trend namens GitOps zunehmend an Beliebtheit, was wir pers\u00f6nlich festgestellt haben, bei<\/a><\/noindex> KubeCon Europe 2019. Dieser Begriff wurde relativ neu von<\/a><\/noindex> Alexis Richardson, dem Gesch\u00e4ftsf\u00fchrer von Weaveworks, gepr\u00e4gt und bedeutet die Anwendung von Werkzeugen, die Entwicklern vertraut sind (vor allem Git, daher der Name), zur L\u00f6sung von Betriebsaufgaben. 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 Bereitstellung berichtet Matthias Jg in diesem Artikel.<\/i><\/p>\n

\"GitOps:
\n
\nIm vergangenen Jahr (tats\u00e4chlich geschah dies formal im August 2017 \u2013 Anmerkung des \u00dcbersetzers)<\/i> Es gibt einen neuen Ansatz zum Bereitstellen von Anwendungen in Kubernetes. Er hei\u00dft GitOps und basiert auf der grundlegenden Vorstellung, dass die Versionsverlauf von Deployments in einer sicheren Git-Repository-Umgebung verfolgt wird.<\/a><\/noindex><\/p>\n

Die wichtigsten Vorteile dieses Ansatzes sind<\/b>:<\/p>\n

    \n
  1. Versionierung von Deployments und \u00c4nderungsverlauf<\/b>. Der Zustand des gesamten Clusters wird in einer Git-Repository gespeichert, und Deployments werden nur durch Commits aktualisiert. Zudem k\u00f6nnen alle \u00c4nderungen anhand des Commit-Verlaufs verfolgt werden.<\/li>\n
  2. R\u00fcckrolls mit den gewohnten Git-Befehlen<\/b>. Einfach git reset<\/code> erm\u00f6glicht das Zur\u00fccksetzen von \u00c4nderungen in Deployments; vergangene Zust\u00e4nde sind immer verf\u00fcgbar.<\/li>\n
  3. Fertige Zugriffskontrolle<\/b>. In der Regel enth\u00e4lt ein Git-System viele vertrauliche Daten, weshalb den meisten Unternehmen besondere Aufmerksamkeit auf dessen Schutz gelegt wird. Dementsprechend wird dieser Schutz auch auf die Operationen mit Deployments angewendet.<\/li>\n
  4. Richtlinien f\u00fcr Bereitstellungen<\/b>. Die meisten Git-Systeme unterst\u00fctzen von Anfang an Richtlinien f\u00fcr verschiedene Branches \u2014 zum Beispiel d\u00fcrfen nur Pull-Requests den Master aktualisieren, und \u00c4nderungen m\u00fcssen von einem anderen Teammitglied \u00fcberpr\u00fcft und angenommen werden. Wie bei der Zugriffskontrolle gelten die gleichen Richtlinien f\u00fcr die Updates der Deployments.<\/li>\n<\/ol>\n

    \nWie Sie sehen, hat die GitOps-Methode viele Vorteile. Im letzten Jahr haben zwei Ans\u00e4tze besondere Beliebtheit erlangt. Einer basiert auf Push, der andere auf Pull. Bevor wir uns diese genauer ansehen, schauen wir uns zun\u00e4chst an, wie typische Deployments in Kubernetes aussehen.<\/p>\n

    Methoden zur Bereitstellung<\/h2>\n

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

      \n
    1. Basierend auf nativen Kubernetes-\/Kustomize-Vorlagen<\/b>. Dies ist der einfachste Weg, Anwendungen in Kubernetes bereitzustellen. Der Entwickler erstellt grundlegende YAML-Dateien und wendet sie an. Um das st\u00e4ndige Neubeschreiben derselben Vorlagen zu vermeiden, wurde Kustomize entwickelt (es verwandelt Kubernetes-Vorlagen in Module). Anmerkung des \u00dcbersetzers.<\/b>: Kustomize wurde mit dem Release von Kubernetes 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Helm-Charts<\/b>. Helm-Charts erm\u00f6glichen das Erstellen von Sets von Vorlagen, Init-Containern, Sidecars usw., die eine flexiblere Anpassung beim Deployment von Anwendungen als der template-basierte Ansatz bieten. Bei dieser Methode stehen templatebasierte YAML-Dateien im Vordergrund. Helm f\u00fcllt diese mit verschiedenen Parametern und sendet sie dann an Tiller \u2014 eine Cluster-Komponente, die sie im Cluster bereitstellt und Updates sowie Rollbacks erm\u00f6glicht. Wichtig ist, dass Helm im Grunde nur die ben\u00f6tigten Werte in die Vorlagen einf\u00fcgt und sie dann genauso anwendet, wie es im traditionellen Ansatz geschieht. (Mehr dar\u00fcber, wie das alles funktioniert und wie man es verwenden kann, lesen Sie in unserem Artikel \u00fcber Helm<\/a><\/noindex> \u2014 Anm. d. \u00dcbersetzer)<\/i>. Es gibt eine gro\u00dfe Vielfalt an verf\u00fcgbaren Helm-Charts, die ein breites Spektrum von Aufgaben abdecken.<\/li>\n
    3. Alternative Werkzeuge<\/b>. Es gibt viele alternative Werkzeuge. Alle vereint, dass sie bestimmte Template-Dateien in verst\u00e4ndliche Kubernetes YAML-Dateien umwandeln und diese dann anwenden.<\/li>\n<\/ol>\n

      \nIn unserer Arbeit nutzen wir st\u00e4ndig Helm-Charts f\u00fcr wichtige Tools (da sie viele bereits vorbereitete Elemente enthalten, die das Leben erheblich erleichtern) sowie \u201ereine\u201c Kubernetes YAML-Dateien zur Bereitstellung unserer eigenen Anwendungen.<\/p>\n

      Pull & Push<\/h2>\n

      \nIn einem meiner letzten Blog-Beitr\u00e4ge habe ich ein Tool vorgestellt, Weave Flux<\/a><\/noindex>, was das Commiteren von Vorlagen in ein Git-Repository und das Aktualisieren von Deployments nach jedem Commit oder Push des Containers erm\u00f6glicht. Meine Erfahrung zeigt, dass dieses Tool eines der wichtigsten beim Vorantreiben des Pull-Ansatzes ist, deshalb werde ich oft darauf verweisen. Wenn Sie mehr dar\u00fcber erfahren m\u00f6chten, wie Sie es verwenden k\u00f6nnen, hier ist der Link zum Artikel<\/a><\/noindex>.<\/p>\n

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

      Pull-basierter Ansatz<\/h2>\n

      \n\"GitOps:
      \n
      \nDer Ansatz des Pull-Systems basiert auf der Tatsache, dass alle \u00c4nderungen aus dem Inneren des Clusters angewendet werden. Innerhalb des Clusters gibt es einen Operator, der regelm\u00e4\u00dfig die verbundenen Git- und Docker-Registry-Repositories \u00fcberpr\u00fcft. Wenn dort \u00c4nderungen auftreten, wird der Zustand des Clusters von innen aktualisiert. Man geht normalerweise davon aus, dass ein solches Verfahren recht sicher ist, da kein externes Client-System Administratorrechte f\u00fcr das Cluster hat.<\/p>\n

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

        \n
      1. Kein externes Client-System hat das Recht, \u00c4nderungen am Cluster vorzunehmen; alle Aktualisierungen werden von innen angewendet.<\/li>\n
      2. Einige Werkzeuge erm\u00f6glichen es auch, Updates von Helm-Charts zu synchronisieren und sie mit dem Cluster zu verkn\u00fcpfen.<\/li>\n
      3. Die Docker-Registry kann auf neue Versionen gescannt werden. Wenn ein neues Image verf\u00fcgbar wird, werden das Git-Repository und das Deployment auf die neue Version aktualisiert.<\/li>\n
      4. Pull-Tools k\u00f6nnen \u00fcber verschiedene Namensr\u00e4ume mit unterschiedlichen Git-Repositories und Zugriffsrechten verteilt werden. Dadurch kann ein Multi-Tenant-Modell implementiert werden. Zum Beispiel kann Team A den Namensraum A verwenden, Team B den Namensraum B, w\u00e4hrend das Infrastrukturteam den globalen Namensraum nutzen kann.<\/li>\n
      5. In der Regel sind die Tools sehr leichtgewichtig.<\/li>\n
      6. In Kombination mit Werkzeugen wie dem Operator Bitnami Sealed Secrets<\/a><\/noindex>, k\u00f6nnen Geheimnisse in verschl\u00fcsselter Form im Git-Repository gespeichert und im Cluster abgerufen werden.<\/li>\n
      7. Es besteht keine Verbindung zu CD-Pipelines, da die Deployments innerhalb des Clusters stattfinden.<\/li>\n<\/ol>\n

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

          \n
        1. Die Verwaltung von Secrets aus Helm-Charts bei Deployments ist komplexer als bei normalen, da sie zun\u00e4chst in Form von, sagen wir, sealed secrets, generiert, dann vom internen Operator entschl\u00fcsselt und erst danach f\u00fcr das Pull-Tool verf\u00fcgbar werden. Danach kann ein Release in Helm mit den Werten der bereits bereitgestellten Secrets gestartet werden. Der einfachste Weg besteht darin, ein Secret mit allen Helm-Werten zu erstellen, die f\u00fcr das Deployment verwendet werden, es zu entschl\u00fcsseln und in Git zu committen.<\/li>\n
        2. Beim Pull-Ansatz sind Sie an Tools gebunden, die mit Pulls arbeiten. Dies schr\u00e4nkt die M\u00f6glichkeit ein, den Deployment-Prozess im Cluster anzupassen. Beispielsweise wird die Arbeit mit Kustomize dadurch komplizierter, dass sie durchgef\u00fchrt werden muss, bevor die finalen Templates in Git gelangen. Ich sage nicht, dass man keine separaten Tools verwenden kann, aber sie lassen sich schwerer in den Deployment-Prozess integrieren.<\/li>\n<\/ol>\n

          <\/p>\n

          Push-basierter Ansatz<\/h2>\n

          \n\"GitOps:
          \n
          \nIm Push-Ansatz startet ein externes System (haupts\u00e4chlich CD-Pipelines) die Bereitstellungen im Cluster nach dem Commit im Git-Repository oder im Falle eines erfolgreichen Abschlusses der vorherigen CI-Pipeline. In diesem Ansatz hat das System Zugriff auf den Cluster.<\/p>\n

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

            \n
          1. Die Sicherheit wird durch das Git-Repository und die Build-Pipeline definiert.<\/li>\n
          2. Das Bereitstellen von Helm-Charts ist einfacher, da es Unterst\u00fctzung f\u00fcr Helm-Plugins gibt.<\/li>\n
          3. Das Verwalten von Geheimnissen ist einfacher, da Geheimnisse in den Pipelines angewendet und auch verschl\u00fcsselt in Git gespeichert werden k\u00f6nnen (je nach den Vorlieben des Benutzers).<\/li>\n
          4. Keine Bindung an ein bestimmtes Werkzeug, da verschiedene Arten verwendet werden k\u00f6nnen.<\/li>\n
          5. Container-Versionen k\u00f6nnen durch die Build-Pipeline aktualisiert werden.<\/li>\n<\/ol>\n

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

              \n
            1. Die Daten f\u00fcr den Zugriff auf den Cluster befinden sich im Build-System.<\/li>\n
            2. Das Aktualisieren von Containern bei Deployments gestaltet sich weiterhin einfacher mit einem Pull-Prozess.<\/li>\n
            3. Starke Abh\u00e4ngigkeit vom CD-System, da die ben\u00f6tigten Pipelines m\u00f6glicherweise urspr\u00fcnglich f\u00fcr Gitlab Runners geschrieben wurden, und das Team dann beschlie\u00dft, auf Azure DevOps oder Jenkins umzusteigen... und eine Migration einer gro\u00dfen Anzahl von Build-Pipelines erforderlich ist.<\/li>\n<\/ol>\n

              <\/p>\n

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

              \nWie \u00fcblich hat jeder Ansatz seine eigenen Vor- und Nachteile. Einige Aufgaben lassen sich mit dem einen Ansatz leichter umsetzen, mit dem anderen hingegen schwieriger. Zu Beginn habe ich die Bereitstellungen manuell durchgef\u00fchrt, aber nachdem ich auf einige Artikel \u00fcber Weave Flux gesto\u00dfen bin, beschloss ich, GitOps-Prozesse f\u00fcr alle Projekte einzuf\u00fchren. F\u00fcr grundlegende Vorlagen stellte sich das als einfach heraus, aber sp\u00e4ter begann ich, Schwierigkeiten im Umgang mit Helm-Charts zu haben. Zu dieser Zeit bot Weave Flux nur eine embryonale Version des Helm Chart Operators an, aber selbst jetzt sind einige Aufgaben schwieriger, da man Geheimnisse manuell erstellen und anwenden muss. Man k\u00f6nnte sagen, dass der Pull-Ansatz viel sicherer ist, da die Cluster-Anmeldeinformationen au\u00dferhalb des Clusters nicht zug\u00e4nglich sind, was die Sicherheit so sehr erh\u00f6ht, dass es die zus\u00e4tzlichen Anstrengungen wert ist.<\/p>\n

              Nach ein wenig \u00dcberlegung kam ich zu der unerwarteten Erkenntnis, dass dem nicht so ist. Wenn man \u00fcber Komponenten spricht, die maximalen Schutz ben\u00f6tigen, geh\u00f6ren dazu Secret Stores und CI\/CD-Systeme, Git-Repositories. Die Informationen darin sind sehr anf\u00e4llig und ben\u00f6tigen den maximalen Schutz. Zudem, wenn jemand in Ihr Git-Repository eindringt und in der Lage ist, Code dorthin zu pushen, kann er alles deployen, was er m\u00f6chte (unabh\u00e4ngig von dem gew\u00e4hlten Ansatz, sei es Pull oder Push), und sich in die Systeme des Clusters einschleusen. Daher sind die wichtigsten Komponenten, die Schutz ben\u00f6tigen, das Git-Repository und die CI\/CD-Systeme und nicht die Cluster-Anmeldeinformationen. Wenn Sie gut konfigurierte Richtlinien und Sicherheitsma\u00dfnahmen f\u00fcr solche Systeme haben und die Cluster-Anmeldeinformationen nur in Form von Secrets in die Pipelines eingegeben werden, mag die zus\u00e4tzliche Sicherheit des Pull-Ansatzes nicht so wertvoll sein, wie urspr\u00fcnglich angenommen.<\/p>\n

              Also, wenn der Pull-Ansatz arbeitsintensiver ist und keinen Sicherheitsvorteil bietet, w\u00e4re es dann nicht sinnvoll, nur den Push-Ansatz zu verwenden? Aber jemand k\u00f6nnte argumentieren, dass man im Push-Ansatz zu sehr an das CD-System gebunden ist und es m\u00f6glicherweise besser w\u00e4re, das nicht zu tun, um in Zukunft Migrationen zu erleichtern.<\/p>\n

              Meiner Meinung nach sollte man (wie immer) das verwenden, was am besten zum konkreten Fall passt oder kombinieren. Ich pers\u00f6nlich nutze beide Ans\u00e4tze: Weave Flux f\u00fcr Pull-basierte Deployments, die haupts\u00e4chlich unsere eigenen Dienste umfassen, und den Push-Ansatz mit Helm und Plugins, der die Anwendung von Helm-Charts im Cluster vereinfacht und das Erstellen von Secrets problemlos erm\u00f6glicht. Ich denke, es wird niemals eine universelle L\u00f6sung geben, die f\u00fcr alle F\u00e4lle geeignet ist, da es immer viele Nuancen gibt, die von dem spezifischen Anwendungsfall abh\u00e4ngen. Ich empfehle jedoch dringend GitOps \u2014 es erleichtert das Leben erheblich und erh\u00f6ht die Sicherheit.<\/p>\n

              Ich hoffe, dass meine Erfahrungen zu diesem Thema Ihnen helfen, herauszufinden, welche Methode besser f\u00fcr Ihre Art der 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 zu legen, es gibt jedoch keinen Nachteil, dass die CD-Pipeline im Pull-Modell separat vom Deployment existiert und somit zu einer Pipeline der Kategorie wird Continuous Apply<\/i>. Daher wird es noch mehr Anstrengungen erfordern, um den Status aus allen Deployments zu sammeln und einen Zugang zu Logs\/Status zu gew\u00e4hren, idealerweise in Verbindung mit dem CD-System.<\/p>\n

              In diesem Sinne erm\u00f6glicht das Push-Modell wenigstens einige Garantien f\u00fcr die Bereitstellung, da die Lebensdauer der Pipeline auf die Lebensdauer der Bereitstellung abgestimmt werden kann.<\/p>\n

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

                \n
              1. Das Pull-Modell eignet sich f\u00fcr die Organisation von Aktualisierungen systemrelevanter Komponenten in einer gro\u00dfen Anzahl von Clustern (siehe den Artikel \u00fcber den Addon-Operator<\/a><\/noindex>).<\/li>\n
              2. Das Push-Modell auf Basis von GitLab CI eignet sich gut f\u00fcr die Bereitstellung von Anwendungen mithilfe von Helm-Charts. Dabei wird die Bereitstellung der Deployments innerhalb der Pipelines mit Hilfe eines Tools \u00fcberwacht werf<\/a><\/noindex>. \u00dcbrigens haben wir im Zusammenhang mit diesem Projekt st\u00e4ndig \"GitOps\" geh\u00f6rt, als wir die dr\u00e4ngenden Probleme der DevOps-Ingenieure 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