{"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\/da\/blog\/administrirovanie\/gitops-sravnenie-metodov-pull-i-push","title":{"rendered":"GitOps: sammenligning af Pull- og Push-metoder","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bem. overs.<\/b>: I Kubernetes-f\u00e6llesskabet vinder en trend kaldet GitOps tydelig popularitet, hvilket vi personligt har erfaret, da vi bes\u00f8gte<\/a><\/noindex> KubeCon Europe 2019. Denne betegnelse blev forholdsvis for nylig opfundet<\/a><\/noindex> af lederen af Weaveworks \u2014 Alexis Richardson \u2014 og refererer til anvendelsen af velkendte v\u00e6rkt\u00f8jer for udviklere (prim\u00e6rt Git, hvilket ogs\u00e5 er grunden til navnet) til at l\u00f8se driftsm\u00e6ssige opgaver. Specifikt handler det om driften af Kubernetes ved at opbevare dets konfigurationer i Git og automatisk udrulning af \u00e6ndringer til klusteret. Om to tilgange til denne udrulning fort\u00e6ller Matthias Jg i denne artikel.<\/i><\/p>\n

\"GitOps:
\n
\nI sidste \u00e5r (det skete faktisk formelt i august 2017 \u2014 bem. fra overs.)<\/i> en ny tilgang til udrulning af applikationer i Kubernetes er blevet introduceret. Den kaldes GitOps, og dens fundamentale koncept er, at versionssporing af deployment'er foreg\u00e5r i et sikkert Git-repositorium.<\/a><\/noindex><\/p>\n

De vigtigste fordele ved denne tilgang er som f\u00f8lger<\/b>:<\/p>\n

    \n
  1. Versionsstyring af deployment'er og \u00e6ndringshistorik<\/b>. Tilstanden for hele klyngen opbevares i Git-repositoriet, og deployment'er opdateres kun via commits. Derudover kan alle \u00e6ndringer spores ved hj\u00e6lp af commit-historikken.<\/li>\n
  2. Tilbagef\u00f8rsel ved hj\u00e6lp af velkendte Git-kommandoer<\/b>. En simpel git reset<\/code> giver mulighed for at nulstille \u00e6ndringer i deployment'er; tidligere tilstande er altid tilg\u00e6ngelige.<\/li>\n
  3. F\u00e6rdig adgangskontrol<\/b>. Normalt indeholder Git-systemer mange fortrolige data, s\u00e5 de fleste virksomheder l\u00e6gger stor v\u00e6gt p\u00e5 deres beskyttelse. F\u00f8lgelig g\u00e6lder denne beskyttelse ogs\u00e5 for operationer med deployment'er.<\/li>\n
  4. Politikker for udrulninger<\/b>. De fleste Git-systemer har oprindeligt politikker for forskellige grene \u2014 for eksempel kan kun pull requests opdatere master, og \u00e6ndringer skal gennemg\u00e5s og godkendes af et andet teammedlem. Som med adgangskontrol anvendes de samme politikker for opdateringer af deployment'er.<\/li>\n<\/ol>\n

    \nSom du kan se, har GitOps-metoden mange fordele. I det seneste \u00e5r er to tilgange blevet s\u00e6rligt popul\u00e6re. En er baseret p\u00e5 push, den anden p\u00e5 pull. F\u00f8r vi ser n\u00e6rmere p\u00e5 dem, lad os f\u00f8rst tage et kig p\u00e5, hvordan typiske Kubernetes-deployment'er ser ud.<\/p>\n

    Metoder til implementering<\/h2>\n

    \nI l\u00f8bet af de seneste \u00e5r er der i Kubernetes blevet etableret forskellige metoder og v\u00e6rkt\u00f8jer til udrulninger:<\/p>\n

      \n
    1. Baseret p\u00e5 Kubernetes\/Kustomizes indf\u00f8dte skabeloner<\/b>. Det er den nemmeste m\u00e5de at implementere applikationer i Kubernetes p\u00e5. Udvikleren opretter grundl\u00e6ggende YAML-filer og anvender dem. For at undg\u00e5 konstant oml\u00e6gning af de samme skabeloner blev Kustomize udviklet (det omdanner Kubernetes-skabeloner til moduler). Bem. overs.<\/b>: Kustomize er blevet integreret i kubectl med udgivelsen af Kubernetes 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Helm Charts<\/b>. Helm-diagrammer giver mulighed for at oprette s\u00e6t af skabeloner, init-containere, sidecar'er osv., som anvendes til at deploye applikationer med mere fleksible konfigurationsmuligheder end i den skabelonbaserede tilgang. Grundlaget for denne metode er skabeloniserede YAML-filer. Helm udfylder dem med forskellige parametre og sender dem derefter til Tiller \u2014 den klyngens komponent, der implementerer dem i klyngen og muligg\u00f8r opdateringer og tilbagef\u00f8ringer. Det vigtige er, at Helm i bund og grund blot inds\u00e6tter de n\u00f8dvendige v\u00e6rdier i skabelonerne og anvender dem p\u00e5 samme m\u00e5de som i den traditionelle tilgang (l\u00e6s mere om, hvordan det hele fungerer, og hvordan du kan bruge det, i vores artikel om Helm<\/a><\/noindex> \u2014 red. anm.)<\/i>. Der findes et stort udvalg af f\u00e6rdige Helm-charts, der d\u00e6kker et bredt spektrum af opgaver.<\/li>\n
    3. Alternative v\u00e6rkt\u00f8jer<\/b>. Der er mange alternative v\u00e6rkt\u00f8jer. F\u00e6lles for dem alle er, at de omdanner nogle skabelonfiler til forst\u00e5elige Kubernetes YAML-filer og derefter anvender dem.<\/li>\n<\/ol>\n

      \nI vores arbejde bruger vi konstant Helm-charts til vigtige v\u00e6rkt\u00f8jer (da meget allerede er klar, hvilket g\u00f8r livet betydeligt lettere) og \u00abrene\u00bb YAML-filer fra Kubernetes til implementering af vores egne applikationer.<\/p>\n

      Pull & Push<\/h2>\n

      \nI et af mine nylige blogindl\u00e6g pr\u00e6senterede jeg et v\u00e6rkt\u00f8j Weave Flux<\/a><\/noindex>, der tillader at commite skabeloner til Git-repositoriet og opdatere deployment efter hver commit eller push af containere. Min erfaring viser, at dette v\u00e6rkt\u00f8j er et af de vigtigste i fremme af pull-tilgangen, s\u00e5 jeg vil ofte referere til det. Hvis du vil vide mere om, hvordan man bruger det, her er linket til artiklen<\/a><\/noindex>.<\/p>\n

      NB!<\/b> Alle fordelene ved at bruge GitOps bevares for begge tilgange.<\/i><\/p>\n

      Pull-baseret tilgang<\/h2>\n

      \n\"GitOps:
      \n
      \nI kernen af pull-tilgangen ligger det faktum, at alle \u00e6ndringer anvendes indefra klyngen. Inden i klyngen er der en operat\u00f8r, der regelm\u00e6ssigt tjekker de tilknyttede Git- og Docker Registry-repositorier. Hvis der sker \u00e6ndringer i dem, opdateres klyngets tilstand indefra. Det betragtes generelt som en sikker proces, da ingen ekstern klient har adgang til administratorrettigheder i klyngen.<\/p>\n

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

        \n
      1. Ingen ekstern klient har rettigheder til at foretage \u00e6ndringer i klyngen; alle opdateringer anvendes indefra.<\/li>\n
      2. Nogle v\u00e6rkt\u00f8jer tillader ogs\u00e5 synkronisering af opdateringer af Helm-diagrammer og knytter dem til klyngen.<\/li>\n
      3. Docker Registry kan scannes for nye versioner. Hvis der kommer et nyt billede, opdateres Git-repositoriet og deployment til den nye version.<\/li>\n
      4. Pull-v\u00e6rkt\u00f8jer kan distribueres p\u00e5 forskellige navnerum med forskellige Git-repositories og adgangsrettigheder. Dette muligg\u00f8r en multitenant-model. For eksempel kan team A bruge navnerum A, team B navnerum B, mens teamet, der arbejder med infrastrukturen, kan bruge et globalt rum.<\/li>\n
      5. Generelt er v\u00e6rkt\u00f8jerne meget letv\u00e6gts.<\/li>\n
      6. I kombination med v\u00e6rkt\u00f8jer som operat\u00f8ren Bitnami Sealed Secrets<\/a><\/noindex>, kan hemmeligheder opbevares krypteret i Git-repositoriet og hentes inden i klyngen.<\/li>\n
      7. Der er ingen forbindelse til CD-pipelines, da deployment finder sted inden i klyngen.<\/li>\n<\/ol>\n

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

          \n
        1. At styre hemmeligheder fra deployment'er i Helm-diagrammer er mere komplekst end almindelige, da de f\u00f8rst skal genereres som, lad os sige, sealed secrets, derefter dekrypteres af en intern operator og f\u00f8rst derefter er de tilg\u00e6ngelige for pull-v\u00e6rkt\u00f8jet. Herefter kan en release i Helm startes med v\u00e6rdier i allerede deployerede hemmeligheder. Den nemmeste m\u00e5de er at oprette en hemmelighed med alle Helm-v\u00e6rdier, der bruges til deployment, dekryptere den og commite den til Git.<\/li>\n
        2. Ved at anvende pull-tilgangen er du bundet til v\u00e6rkt\u00f8jer, der arbejder med pulls. Dette begr\u00e6nser muligheden for at tilpasse deployeringsprocessen i klyngen. For eksempel er arbejdet med Kustomize kompliceret, da det skal udf\u00f8res, f\u00f8r de endelige skabeloner n\u00e5r Git. Jeg siger ikke, at du ikke kan bruge separate v\u00e6rkt\u00f8jer, men de er sv\u00e6re at integrere i deployeringsprocessen.<\/li>\n<\/ol>\n

          <\/p>\n

          Push-baseret tilgang<\/h2>\n

          \n\"GitOps:
          \n
          \nI push-tilgangen igangs\u00e6tter det eksterne system (prim\u00e6rt CD-pipelines) deployment i klyngen efter commit i Git-repositoriet eller i tilf\u00e6lde af, at den foreg\u00e5ende CI-pipeline er blevet udf\u00f8rt med succes. I denne tilgang har systemet adgang til klyngen.<\/p>\n

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

            \n
          1. Sikkerheden defineres af Git-repositoriet og bygge-pipelinen.<\/li>\n
          2. Det er lettere at deployere Helm-charter, da der er st\u00f8tte for Helm-plugins.<\/li>\n
          3. Det er lettere at administrere hemmeligheder, da hemmeligheder kan anvendes i pipelines og ogs\u00e5 opbevares i Git i krypteret form (afh\u00e6ngigt af brugerens pr\u00e6ferencer).<\/li>\n
          4. Der er ingen binding til et specifikt v\u00e6rkt\u00f8j, da man kan bruge enhver type.<\/li>\n
          5. Opdateringer af container-versioner kan initieres af bygge-pipelinen.<\/li>\n<\/ol>\n

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

              \n
            1. Dataene til adgang til klyngen er inde i byggesystemet.<\/li>\n
            2. Opdatering af containere i deployment'er er stadig lettere at udf\u00f8re med pull-processen.<\/li>\n
            3. Der er en st\u00e6rk afh\u00e6ngighed af CD-systemet, da de n\u00f8dvendige pipelines muligvis oprindeligt er skrevet til Gitlab Runners, og s\u00e5 beslutter teamet at skifte til Azure DevOps eller Jenkins... og skal migrere mange bygge-pipelines.<\/li>\n<\/ol>\n

              <\/p>\n

              Sammenfatning: Push eller Pull?<\/h2>\n

              \nSom vanligt er der fordele og ulemper ved hver tilgang. Nogle opgaver er lettere at udf\u00f8re med den ene, mens det er sv\u00e6rere med den anden. I starten udf\u00f8rte jeg deployment manuelt, men efter at jeg st\u00f8dte p\u00e5 nogle artikler om Weave Flux, besluttede jeg at implementere GitOps-processer for alle projekter. For de grundl\u00e6ggende skabeloner var det nemt, men senere begyndte jeg at st\u00f8de p\u00e5 udfordringer med Helm-diagrammer. P\u00e5 det tidspunkt tilb\u00f8d Weave Flux kun en tidlig version af Helm Chart Operator, men selv nu er nogle opgaver mere komplekse p\u00e5 grund af behovet for manuelt at oprette hemmeligheder og anvende dem. Man kan sige, at pull-tilgangen er meget mere sikker, da klyngetr\u00e6k-kontooplysningerne ikke er tilg\u00e6ngelige uden for det, hvilket \u00f8ger sikkerheden s\u00e5 meget, at det er v\u00e6rd at g\u00f8re en ekstra indsats.<\/p>\n

              Efter lidt overvejelse kom jeg til den overraskende konklusion, at det ikke er tilf\u00e6ldet. N\u00e5r det kommer til komponenter, der kr\u00e6ver maksimal beskyttelse, vil s\u00e5dan en liste inkludere hemmelighedslager og CI\/CD-systemer, Git-repositorier. Informationen inden i dem er meget s\u00e5rbar og har brug for maksimal beskyttelse. Desuden, hvis nogen f\u00e5r adgang til dit Git-repositorie og kan pushe kode der, s\u00e5 kan de deploye hvad de \u00f8nsker (uanset om det er pull eller push-tilgangen), og infiltrere klyngens systemer. S\u00e5ledes er de mest kritiske komponenter, der kr\u00e6ver beskyttelse, Git-repositoriet og CI\/CD-systemerne, ikke klynge legitimationsoplysninger. Hvis du har godt konfigurerede politikker og sikkerhedsforanstaltninger for denne type systemer, og klynge legitimationsoplysninger kun tr\u00e6kkes ind i pipelines som hemmeligheder, s\u00e5 kan den ekstra sikkerhed ved pull-tilgangen vise sig at v\u00e6re mindre v\u00e6rdifuld end f\u00f8rst antaget.<\/p>\n

              S\u00e5 hvis pull-tilgangen er mere besv\u00e6rlig og ikke giver sikkerhedsfordele, er det s\u00e5 ikke logisk kun at bruge push-tilgangen? Men nogen kunne m\u00e5ske h\u00e6vde, at i push-tilgangen er du for afh\u00e6ngig af CD-systemet, og det kan v\u00e6re bedre at undg\u00e5 det for at g\u00f8re fremtidige migreringer lettere.<\/p>\n

              Efter min mening (som altid) b\u00f8r man anvende det, der bedst passer til den konkrete situation eller kombinere dem. Personligt bruger jeg begge tilgange: Weave Flux til deployment baseret p\u00e5 pull, som prim\u00e6rt inkluderer vores egne tjenester, og push-tilgangen med Helm og plugins, der forenkler implementeringen af Helm-diagrammer til klyngen og g\u00f8r det muligt at oprette hemmeligheder uden problemer. Jeg tror aldrig, der vil v\u00e6re \u00e9n l\u00f8sning, der passer til alle tilf\u00e6lde, da der altid er mange nuancer, og de afh\u00e6nger af den specifikke anvendelse. Jeg anbefaler st\u00e6rkt GitOps - det g\u00f8r livet meget lettere og forbedrer sikkerheden.<\/p>\n

              Jeg h\u00e5ber, at min erfaring med emnet kan hj\u00e6lpe med at bestemme, hvilken metode der passer bedst til din type deployment, og jeg vil v\u00e6re glad for at h\u00f8re din mening.<\/p>\n

              P.S. Notat fra overs\u00e6tteren<\/h2>\n

              \nUlempen ved pull-modellen er, at det er sv\u00e6rt at l\u00e6gge de rendere manifeste i Git, men der er ikke nogen ulempe ved, at CD-pipelinen i pull-modellen lever separat fra udrulningen og i virkeligheden bliver en pipeline af kategorien Continuous Apply<\/i>. Derfor vil der kr\u00e6ves endnu mere indsats for at indsamle statussen fra alle deployment og give adgang til logs\/status, helst med tilknytning til CD-systemet.<\/p>\n

              I denne forstand giver push-modellen nogle garantier for udrulning, fordi levetiden for pipelinen kan g\u00f8res lig med levetiden for udrulningen.<\/p>\n

              Vi har afpr\u00f8vet begge modeller og er n\u00e5et til de samme konklusioner som forfatteren af artiklen:<\/p>\n

                \n
              1. Pull-modellen passer os til at organisere opdateringer af systemkomponenter p\u00e5 et stort antal klynger (se artiklen om addon-operator<\/a><\/noindex>).<\/li>\n
              2. Push-modellen baseret p\u00e5 GitLab CI er velegnet til udrulning af applikationer ved hj\u00e6lp af Helm-diagrammer. Udrulningen af deployment i pipeline overv\u00e5ges med v\u00e6rkt\u00f8jet werf<\/a><\/noindex>. For at sige det s\u00e5dan, s\u00e5 h\u00f8rte vi konstant om \"GitOps\" i konteksten af dette projekt, n\u00e5r vi diskuterede de presserende problemer for DevOps-ingeni\u00f8rer ved vores stand p\u00e5 KubeCon Europe '19.<\/li>\n<\/ol>\n

                <\/p>\n

                P.P.S. fra overs\u00e6tteren<\/h2>\n

                \nL\u00e6s ogs\u00e5 p\u00e5 vores blog:<\/p>\n