{"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\/nl\/blog\/administrirovanie\/gitops-sravnenie-metodov-pull-i-push","title":{"rendered":"GitOps: vergelijking van Pull- en Push-methoden","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Opmerking vertaler.<\/b>: In de Kubernetes-gemeenschap wint een trend genaamd GitOps duidelijk aan populariteit, iets wat wij persoonlijk hebben ervaren, door<\/a><\/noindex> KubeCon Europe 2019 bij te wonen. Deze term is relatief recentelijk uitgevonden<\/a><\/noindex> door de CEO van Weaveworks \u2014 Alexis Richardson \u2014 en betekent het gebruik van vertrouwde tools voor ontwikkelaars (vooral Git, waar de naam ook vandaan komt) voor operationele taken. Met name gaat het om het beheren van Kubernetes door zijn configuraties in Git op te slaan en automatische uitrol van wijzigingen naar de cluster te realiseren. Over twee benaderingen van deze uitrol vertelt Matthias Jg in dit artikel.<\/i><\/p>\n

\"GitOps:
\n
\nVorig jaar (eigenlijk gebeurde dit formeel in augustus 2017 \u2014 opmerking van de vertaler)<\/i> Er is een nieuwe aanpak voor het implementeren van applicaties in Kubernetes. Het wordt GitOps genoemd en de basisgedachte is dat versiebeheer van deployments plaatsvindt in een veilige omgeving van een Git-repository.<\/a><\/noindex><\/p>\n

De belangrijkste voordelen van deze aanpak zijn als volgt<\/b>:<\/p>\n

    \n
  1. Versiebeheer van deployments en wijzigingshistorie<\/b>. De staat van de hele cluster wordt opgeslagen in de Git-repository, en deployments worden alleen bijgewerkt door middel van commits. Bovendien kunnen alle wijzigingen worden bijgehouden met de commitgeschiedenis.<\/li>\n
  2. Rollback met behulp van vertrouwde Git-commando's<\/b>. Een eenvoudige git reset<\/code> maakt het mogelijk om wijzigingen in deployments terug te draaien; vorige toestanden zijn altijd beschikbaar.<\/li>\n
  3. Klaar toegangsbeheer<\/b>. Gewoonlijk bevat een Git-systeem veel vertrouwelijke gegevens, daarom besteden de meeste bedrijven bijzondere aandacht aan de beveiliging ervan. Deze beveiliging is ook van toepassing op de operaties met deployments.<\/li>\n
  4. Beleid voor deployments<\/b>. De meeste Git-systemen ondersteunen van nature beleidsregels voor verschillende takken \u2014 bijvoorbeeld, alleen pull-requests mogen de master bijwerken, en wijzigingen moeten gecontroleerd en goedgekeurd worden door een ander teamlid. Net als bij toegangscontrole worden dezelfde beleidsregels toegepast op het bijwerken van deployments.<\/li>\n<\/ol>\n

    \nZoals je ziet, heeft de GitOps-methode veel voordelen. Het afgelopen jaar zijn twee benaderingen bijzonder populair geworden. De ene is gebaseerd op push, de andere op pull. Voordat we deze bekijken, laten we eerst eens kijken naar hoe typische Kubernetes deployments eruitzien.<\/p>\n

    Deploymentmethoden<\/h2>\n

    \nIn de afgelopen jaren zijn er verschillende manieren en tools voor deployments in Kubernetes ontstaan:<\/p>\n

      \n
    1. Gebaseerd op de native sjablonen van Kubernetes\/Kustomize<\/b>Dit is de eenvoudigste manier om applicaties in Kubernetes te implementeren. De ontwikkelaar maakt basis YAML-bestanden en past deze toe. Om het constante herschrijven van dezelfde sjablonen te vermijden, is Kustomize ontwikkeld (dit verandert Kubernetes-sjablonen in modules). Opmerking vertaler.<\/b>: Kustomize is ge\u00efntegreerd in kubectl met de release van Kubernetes 1.14.<\/a><\/noindex>.<\/i><\/li>\n
    2. Helm Charts<\/b>. Helm-charts maken het mogelijk om sets van sjablonen, init-containers, sidecars, enz. te cre\u00ebren, die worden gebruikt voor het deployen van applicaties met meer flexibele configuratiemogelijkheden dan bij de sjabloon-gebaseerde aanpak. De basis van deze methode zijn gemoduleerde YAML-bestanden. Helm vulde ze met verschillende parameters en stuurt ze vervolgens naar Tiller \u2014 het clustercomponent dat deze in de cluster implementeert en updates en terugdraaiingen mogelijk maakt. Belangrijk is dat Helm in wezen gewoon de juiste waarden in de sjablonen plaatst en deze vervolgens toepast zoals dat gebeurt in de traditionele benadering (voor meer informatie over hoe dit allemaal werkt en hoe je het kunt gebruiken, lees onze Helm-artikel<\/a><\/noindex> \u2013 opmerking vert.)<\/i>. Er is een grote verscheidenheid aan kant-en-klare Helm-charts die een breed scala aan taken dekken.<\/li>\n
    3. Alternatieve tools<\/b>. Er zijn tal van alternatieve tools. Wat hen verbindt, is dat ze bepaalde sjabloonbestanden omzetten in begrijpelijke Kubernetes YAML-bestanden en deze vervolgens toepassen.<\/li>\n<\/ol>\n

      \nIn ons werk gebruiken we voortdurend Helm-charts voor belangrijke tools (omdat veel al vooraf is voorbereid, wat het leven aanzienlijk vergemakkelijkt) en 'schone' Kubernetes YAML-bestanden voor het implementeren van onze eigen applicaties.<\/p>\n

      Pull & Push<\/h2>\n

      \nIn een van mijn recente blogberichten heb ik een tool ge\u00efntroduceerd Weave Flux<\/a><\/noindex>, waarmee sjablonen in de Git-repository kunnen worden gecommit en de deployment kan worden bijgewerkt na elke commit of push van de container. Mijn ervaring laat zien dat dit hulpmiddel een van de belangrijkste is voor het bevorderen van de pull-aanpak, dus ik zal er vaak naar verwijzen. Als je meer wilt weten over hoe je het kunt gebruiken, hier is de link naar het artikel<\/a><\/noindex>.<\/p>\n

      NB!<\/b> Alle voordelen van het gebruik van GitOps blijven behouden voor beide benaderingen.<\/i><\/p>\n

      Pull-gebaseerde aanpak<\/h2>\n

      \n\"GitOps:
      \n
      \nDe pull-benadering is gebaseerd op het feit dat alle wijzigingen van binnenuit het cluster worden toegepast. Binnen het cluster is er een operator die regelmatig de gekoppelde Git- en Docker Registry-repositories controleert. Als er wijzigingen zijn, wordt de status van het cluster van binnenuit bijgewerkt. Deze methode wordt doorgaans als veilig beschouwd, aangezien geen enkele externe klant toegang heeft tot de beheerdersrechten van het cluster.<\/p>\n

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

        \n
      1. Geen enkele externe klant heeft de rechten om wijzigingen in het cluster aan te brengen; alle updates worden vanuit het cluster doorgevoerd.<\/li>\n
      2. Sommige tools maken het ook mogelijk om updates van Helm-charts te synchroniseren en deze aan het cluster te koppelen.<\/li>\n
      3. Docker Registry kan worden gescand op nieuwe versies. Wanneer er een nieuw beeld verschijnt, worden de Git-repository en de deployment bijgewerkt naar de nieuwe versie.<\/li>\n
      4. Pull-tools kunnen over verschillende namespaces worden verdeeld met verschillende Git-repositories en toegangsrechten. Dit maakt het mogelijk om een multitenant-model toe te passen. Bijvoorbeeld, team A kan namespace A gebruiken, team B namespace B, en het team dat verantwoordelijk is voor de infrastructuur kan de globale namespace gebruiken.<\/li>\n
      5. Over het algemeen zijn tools tamelijk lichtgewicht.<\/li>\n
      6. In combinatie met tools zoals de operator Bitnami Sealed Secrets<\/a><\/noindex>, kunnen geheimen in versleutelde vorm in de Git-repository worden opgeslagen en binnen het cluster worden opgehaald.<\/li>\n
      7. Er is geen verbinding met CD-pijplijnen, aangezien deployments binnen het cluster plaatsvinden.<\/li>\n<\/ol>\n

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

          \n
        1. Het beheren van secrets voor deployments vanuit Helm-charts is ingewikkelder dan bij reguliere secrets, omdat je ze eerst moet genereren als bijvoorbeeld sealed secrets, vervolgens decoderen met een interne operator en pas daarna worden ze beschikbaar voor het pull-instrument. Daarna kan je een release in Helm starten met de waarden die al in de uitgerolde secrets zijn. De eenvoudigste manier is om een secret te maken met alle Helm-waarden die voor de deployment worden gebruikt, deze te decoderen en in Git te commiten.<\/li>\n
        2. Door een pull-aanpak te gebruiken, ben je gebonden aan tools die met pulls werken. Dit beperkt de mogelijkheid om het deployment-proces in het cluster aan te passen. Bijvoorbeeld, werken met Kustomize wordt moeilijker omdat het uitgevoerd moet worden voordat de uiteindelijke templates in Git komen. Ik zeg niet dat je geen aparte tools kunt gebruiken, maar het is moeilijker om ze in het deployment-proces te integreren.<\/li>\n<\/ol>\n

          <\/p>\n

          Push-gebaseerde aanpak<\/h2>\n

          \n\"GitOps:
          \n
          \nBij de push-aanpak start een extern systeem (voornamelijk CD-pijplijnen) de deployments in het cluster na een commit in de Git-repository of na een succesvolle uitvoering van de vorige CI-pijplijn. In deze aanpak heeft het systeem toegang tot het cluster.<\/p>\n

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

            \n
          1. Beveiliging wordt bepaald door de Git-repository en de build-pijplijn.<\/li>\n
          2. Het is eenvoudiger om Helm-charts te deployen, er is ondersteuning voor Helm-plugins.<\/li>\n
          3. Het beheren van geheimen is gemakkelijker, omdat geheimen in pijplijnen kunnen worden toegepast en ook in Git versleuteld kunnen worden opgeslagen (afhankelijk van de voorkeur van de gebruiker).<\/li>\n
          4. Geen binding aan een specifieke tool, omdat elk type kan worden gebruikt.<\/li>\n
          5. Versie-updates van containers kunnen worden ge\u00efnitieerd door de build-pijplijn.<\/li>\n<\/ol>\n

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

              \n
            1. Gegevens voor toegang tot het cluster bevinden zich binnen het build-systeem.<\/li>\n
            2. Het bijwerken van container deployments is nog steeds eenvoudiger met een pull-proces.<\/li>\n
            3. Sterke afhankelijkheid van het CD-systeem, aangezien de benodigde pijplijnen mogelijk aanvankelijk zijn geschreven voor GitLab Runners, en het team besluit misschien over te schakelen naar Azure DevOps of Jenkins\u2026 en er moet een migratie van een groot aantal build-pijplijnen plaatsvinden.<\/li>\n<\/ol>\n

              <\/p>\n

              Conclusie: Push of Pull?<\/h2>\n

              \nZoals gewoonlijk heeft elke benadering zijn eigen voor- en nadelen. Sommige taken zijn gemakkelijker uit te voeren met de ene methode en moeilijker met de andere. In het begin maakte ik deployments handmatig, maar nadat ik verschillende artikelen over Weave Flux had gelezen, besloot ik GitOps-processen voor alle projecten in te voeren. Voor de basis sjablonen bleek dit eenvoudig te zijn, maar daarna kwam ik moeilijkheden tegen bij het werken met Helm charts. In die tijd bood Weave Flux alleen een vroege versie van de Helm Chart Operator aan, maar zelfs nu zijn sommige taken moeilijker door de noodzaak om handmatig geheimen te cre\u00ebren en die toe te passen. Je zou kunnen zeggen dat de pull-benadering veel veiliger is, aangezien de clusterreferenties niet buiten het cluster toegankelijk zijn, en dat verhoogt de veiligheid zo veel dat het de extra moeite waard is.<\/p>\n

              Na er even over nagedacht te hebben, kwam ik tot de onverwachte conclusie dat dit niet het geval is. Als we het hebben over componenten die maximale bescherming vereisen, omvat deze lijst secret repositories en CI\/CD-systemen, Git-repositories. De informatie daarin is behoorlijk kwetsbaar en heeft maximale bescherming nodig. Bovendien, als iemand je Git-repository binnendringt en in staat is om daar code te pushen, kan hij alles uitrollen wat hij wil (ongeacht de gekozen aanpak, hetzij pull of push) en binnenkomen in de cluster systemen. Daarmee zijn de belangrijkste componenten die bescherming vereisen de Git-repository en CI\/CD-systemen, niet de cluster credentials. Als je goede beveiligingsbeleid en -maatregelen hebt ingesteld voor systemen van dit type, en de cluster credentials alleen als secrets in de pipelines worden gehaald, kan de extra beveiliging van de pull-aanpak minder waardevol blijken te zijn dan oorspronkelijk gedacht.<\/p>\n

              Dus, als de pull-benadering arbeidsintensiever is en geen beveiligingsvoordeel biedt, is het dan niet logisch om alleen de push-benadering te gebruiken? Maar iemand zou kunnen beweren dat je bij de push-benadering te afhankelijk bent van het CD-systeem en dat het misschien beter is om dat niet te doen, zodat het in de toekomst gemakkelijker is om migraties uit te voeren.<\/p>\n

              Naar mijn mening (zoals altijd) moet je gebruiken wat het beste past bij de specifieke situatie of combineren. Persoonlijk gebruik ik beide benaderingen: Weave Flux voor deployments op basis van pull, die meestal onze eigen services omvatten, en de push-benadering met Helm en plugins, die het toepassen van Helm-templates op de cluster vereenvoudigt en het cre\u00ebren van geheimen probleemloos laat verlopen. Ik denk niet dat er ooit \u00e9\u00e9n oplossing zal zijn die voor alle gevallen geschikt is, omdat er altijd veel nuances zijn die afhankelijk zijn van de specifieke toepassing. Desondanks raad ik GitOps ten zeerste aan \u2014 het vergemakkelijkt het leven enorm en verhoogt de veiligheid.<\/p>\n

              Ik hoop dat mijn ervaring op dit gebied helpt bij het bepalen welke methode het beste past bij jouw type deployments, en ik zou graag jouw mening horen.<\/p>\n

              P.S. Opmerking van de vertaler<\/h2>\n

              \nEen nadeel van het pull-model is dat het moeilijk is om gerenderde manifesten in Git op te slaan, maar er is geen nadeel dat de CD-pipeline in het pull-model apart van de rollout leeft en in wezen een pipeline van de categorie Continuous Apply<\/i>. Daarom zijn er nog meer inspanningen nodig om de status van alle deployments te verzamelen en op een of andere manier toegang te geven tot de logs\/status, het liefst gekoppeld aan het CD-systeem.<\/p>\n

              In dit opzicht biedt het push-model enige garanties voor de uitrol, omdat de levensduur van de pipeline gelijk kan worden gemaakt aan de levensduur van de uitrol.<\/p>\n

              We hebben beide modellen uitgeprobeerd en kwamen tot dezelfde conclusies als de auteur van het artikel:<\/p>\n

                \n
              1. Het pull-model is geschikt voor het organiseren van updates van systeemcomponenten op een groot aantal clusters (zie het artikel over addon-operator<\/a><\/noindex>).<\/li>\n
              2. Het push-model op basis van GitLab CI is goed geschikt voor het uitrollen van applicaties met behulp van Helm-templates. Bij dit alles wordt de uitrol van deployments binnen de pipelines gevolgd met behulp van de tool werf<\/a><\/noindex>. Trouwens, in de context van dit project hoorden we voortdurend 'GitOps' toen we de dringende problemen van DevOps-engineers bespraken bij onze stand op KubeCon Europe '19.<\/li>\n<\/ol>\n

                <\/p>\n

                P.P.S. van de vertaler<\/h2>\n

                \nLees ook op onze blog:<\/p>\n