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

Obs. overs.<\/b>: I Kubernetes-samfunnet blir trenden kalt GitOps stadig mer popul\u00e6r, noe vi personlig fikk bekreftet da vi bes\u00f8kte<\/a><\/noindex> KubeCon Europe 2019. Dette begrepet ble relativt nylig oppfunnet<\/a><\/noindex> av lederen for Weaveworks \u2014 Alexis Richardson \u2014 og inneb\u00e6rer bruk av de verkt\u00f8yene som utviklere kjenner godt (i f\u00f8rste rekke \u2014 Git, derav navnet) for \u00e5 l\u00f8se driftsoppgaver. Spesielt handler det om drift av Kubernetes gjennom \u00e5 lagre konfigurasjonene i Git og automatisk rulle ut endringer til klyngen. Matthias Jg forklarer de to tiln\u00e6rmingene til denne utrullingen i denne artikkelen.<\/i><\/p>\n

\"GitOps:
\n
\nI fjor (egentlig, formelt sett skjedde dette i august 2017 \u2014 anm. oversetter.)<\/i> Det har kommet en ny tiln\u00e6rming til distribusjon av applikasjoner i Kubernetes. Den kalles GitOps, og den er basert p\u00e5 det grunnleggende prinsippet om at versjonskontroll av distribusjoner skjer i et sikkert Git-repositorium.<\/a><\/noindex><\/p>\n

De viktigste fordelene med denne tiln\u00e6rmingen er som f\u00f8lger<\/b>:<\/p>\n

    \n
  1. Versjonskontroll av distribusjoner og endringshistorikk<\/b>. Tilstanden til hele klusteret lagres i Git-repositoriet, og distribusjoner oppdateres kun gjennom commits. I tillegg kan alle endringer spores med endringshistorikk.<\/li>\n
  2. Tilbakerullinger ved bruk av kjente Git-kommandoer<\/b>. En enkel git reset<\/code> det muliggj\u00f8r tilbakestilling av endringer i distribusjoner; tidligere tilstander er alltid tilgjengelige.<\/li>\n
  3. Klar tilgangskontroll<\/b>. Vanligvis inneholder Git-systemet mange konfidentielle data, s\u00e5 de fleste selskaper legger stor vekt p\u00e5 \u00e5 beskytte det. Denne beskyttelsen gjelder derfor ogs\u00e5 for operasjoner med distribusjoner.<\/li>\n
  4. Retningslinjer for distribusjoner<\/b>. De fleste Git-systemer st\u00f8tter opprinnelig policyer for ulike grener \u2014 for eksempel kan bare pull-requests oppdatere master, og endringer m\u00e5 gjennomg\u00e5s og godkjennes av et annet teammedlem. Som med tilgangskontroll, anvendes de samme policyene p\u00e5 oppdateringer av distribusjoner.<\/li>\n<\/ol>\n

    \nSom du ser, har GitOps-metoden mange fordeler. I l\u00f8pet av det siste \u00e5ret har to tiln\u00e6rminger blitt spesielt popul\u00e6re. Den ene er basert p\u00e5 push, den andre p\u00e5 pull. F\u00f8r vi ser n\u00e6rmere p\u00e5 dem, la oss f\u00f8rst se p\u00e5 hvordan typiske distribusjoner i Kubernetes ser ut.<\/p>\n

    Distributionsmetoder<\/h2>\n

    \nI l\u00f8pet av de siste \u00e5rene har det etablert seg ulike metoder og verkt\u00f8y for distribusjoner i Kubernetes:<\/p>\n

      \n
    1. Basert p\u00e5 native maler Kubernetes\/Kustomize<\/b>Dette er den enkleste m\u00e5ten \u00e5 deployere applikasjoner i Kubernetes. Utvikleren lager grunnleggende YAML-filer og anvender dem. For \u00e5 unng\u00e5 \u00e5 m\u00e5tte skrive de samme malene om igjen, ble Kustomize utviklet (det omdanner Kubernetes-maler til moduler). Obs. overs.<\/b>: Kustomize ble integrert i kubectl med Kubernetes versjon 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Helm Charts<\/b>. Helm-diagrammer tillater opprettelse av malsett, init-containere, sidecar-er osv., som brukes til distribusjon av applikasjoner med mer fleksible konfigurasjonsmuligheter enn i malbaserte tiln\u00e6rminger. Grunnlaget for denne metoden er templaterte YAML-filer. Helm fyller ut dem med ulike parametere og sender dem deretter til Tiller \u2014 den klyngesammenstillingskomponenten som distribuerer dem i klyngen og muliggj\u00f8r oppdateringer og tilbakestillinger. Det viktige er at Helm i hovedsak bare setter inn de n\u00f8dvendige verdiene i malene og bruker dem p\u00e5 samme m\u00e5te som i den tradisjonelle tiln\u00e6rmingen. (for mer informasjon om hvordan dette fungerer og hvordan det kan brukes, se v\u00e5r artikkel om Helm<\/a><\/noindex> \u2013 obs. overs.)<\/i>. Det finnes et stort mangfold av ferdige Helm-charts som dekker et bredt spekter av oppgaver.<\/li>\n
    3. Alternativer<\/b>. Det finnes mange alternative verkt\u00f8y. Alle deler det at de omdanner visse malfiler til forst\u00e5elige Kubernetes YAML-filer og deretter anvender dem.<\/li>\n<\/ol>\n

      \nI v\u00e5rt arbeid bruker vi kontinuerlig Helm-charts for viktige verkt\u00f8y (siden mye allerede er klart, noe som betydelig forenkler livet) og 'rene' Kubernetes YAML-filer for \u00e5 deployere egne applikasjoner.<\/p>\n

      Pull & Push<\/h2>\n

      \nI et av mine nyere blogginnlegg presenterte jeg verkt\u00f8yet Weave Flux<\/a><\/noindex>, som gj\u00f8r det mulig \u00e5 commite maler i Git-repositoriet og oppdatere distribusjonen etter hver commit eller push av containeren. Min erfaring viser at dette verkt\u00f8yet er et av de viktigste i arbeidet med \u00e5 fremme pull-tiln\u00e6rmingen, s\u00e5 jeg vil ofte referere til det. Hvis du vil vite mer om hvordan du bruker det, her er lenken til artikkelen<\/a><\/noindex>.<\/p>\n

      NB!<\/b> Alle fordelene ved \u00e5 bruke GitOps gjelder for begge tiln\u00e6rminger.<\/i><\/p>\n

      Pull-baserte tiln\u00e6rminger<\/h2>\n

      \n\"GitOps:
      \n
      \nGrunnlaget for pull-tiln\u00e6rmingen ligger i det faktum at alle endringer blir anvendt fra innsiden av klyngen. Inne i klyngen finnes det en operat\u00f8r som regelmessig sjekker de tilknyttede Git-repositoriene og Docker Registry. Hvis det skjer noen endringer der, oppdateres tilstanden til klyngen fra innsiden. Det anses vanligvis for \u00e5 v\u00e6re ganske sikkert, ettersom ingen eksterne kunder har tilgang til administratorrettighetene til klyngen.<\/p>\n

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

        \n
      1. Ingen eksterne kunder har rett til \u00e5 foreta endringer i klyngen, alle oppdateringer rulles ut fra innsiden.<\/li>\n
      2. Noen verkt\u00f8y lar ogs\u00e5 synkronisere oppdateringer av Helm-diagrammer og knytte dem til klyngen.<\/li>\n
      3. Docker Registry kan skannes for nye versjoner. Hvis et nytt bilde dukker opp, oppdateres Git-repositoriet og distribusjonen til den nye versjonen.<\/li>\n
      4. Pull-verkt\u00f8y kan distribueres p\u00e5 forskjellige navnerom med ulike Git-repositorier og tilgangsrettigheter. Dette gj\u00f8r det mulig \u00e5 benytte en multitenant-modell. For eksempel kan Team A bruke navnerom A, Team B et navnerom B, mens teamet som jobber med infrastrukturen kan bruke et globalt navnerom.<\/li>\n
      5. Generelt er verkt\u00f8yene ganske lette.<\/li>\n
      6. I kombinasjon med verkt\u00f8y som operat\u00f8ren Bitnami Sealed Secrets<\/a><\/noindex>, kan hemmeligheter lagres i kryptert format i Git-repositoriet og hentes inne i klyngen.<\/li>\n
      7. Det er ingen forbindelse til CD-pipelines, ettersom distribusjoner skjer inne i klyngen.<\/li>\n<\/ol>\n

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

          \n
        1. \u00c5 h\u00e5ndtere hemmeligheter fra deployeringer i Helm-diagrammer er mer komplisert enn med vanlige hemmeligheter, siden de f\u00f8rst m\u00e5 genereres som for eksempel sealed secrets, deretter dekrypteres av den interne operat\u00f8ren, og f\u00f8rst etter dette blir de tilgjengelige for pull-verkt\u00f8y. Deretter kan du kj\u00f8re en utgivelse i Helm med verdiene i de allerede distribuert hemmelighetene. Den enkleste m\u00e5ten er \u00e5 lage en hemmelighet med alle Helm-verdiene som brukes til deployeringen, dekryptere den og commite den til Git.<\/li>\n
        2. Ved \u00e5 bruke pull-tiln\u00e6rmingen blir du bundet til verkt\u00f8y som opererer med pull. Dette begrenser muligheten til \u00e5 tilpasse deployeringsprosessen i klyngen. For eksempel er det vanskeligere \u00e5 arbeide med Kustomize fordi det m\u00e5 kj\u00f8res f\u00f8r de endelige malene g\u00e5r til Git. Jeg sier ikke at separate verkt\u00f8y ikke kan brukes, men de er vanskeligere \u00e5 integrere i deployeringsprosessen.<\/li>\n<\/ol>\n

          <\/p>\n

          Push-basert tiln\u00e6rming<\/h2>\n

          \n\"GitOps:
          \n
          \nI push-tiln\u00e6rmingen starter et eksternt system (for det meste CD-pipelines) distribusjonene i klyngen etter at det er gjort et commit i Git-repositoriet eller etter vellykket kj\u00f8ring av den foreg\u00e5ende CI-pipelinen. I denne tiln\u00e6rmingen har systemet tilgang til klyngen.<\/p>\n

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

            \n
          1. Sikkerheten bestemmes av Git-repositoriet og bygge-pipelinen.<\/li>\n
          2. Det er enklere \u00e5 distribuere Helm-diagrammer, med st\u00f8tte for Helm-plugins.<\/li>\n
          3. \u00c5 administrere hemmeligheter er enklere, siden man kan bruke hemmelighetene i pipeliner og oppbevare dem i Git i kryptert form (avhengig av brukerens preferanser).<\/li>\n
          4. Ingen binding til spesifikke verkt\u00f8y, siden alle typer kan brukes.<\/li>\n
          5. Oppdateringer av containerversjoner kan initieres av bygge-pipelinen.<\/li>\n<\/ol>\n

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

              \n
            1. Data for \u00e5 f\u00e5 tilgang til klyngen er inne i byggesystemet.<\/li>\n
            2. Oppdatering av containere i deployeringene er fortsatt enklere med en pull-prosess.<\/li>\n
            3. Sterk avhengighet av CD-systemet, siden de n\u00f8dvendige pipeline-ene kanskje f\u00f8rst ble skrevet for Gitlab Runners, og s\u00e5 bestemmer teamet seg for \u00e5 g\u00e5 over til Azure DevOps eller Jenkins\u2026 og det m\u00e5 migreres mange bygge-pipelines.<\/li>\n<\/ol>\n

              <\/p>\n

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

              \nSom vanlig har hver tiln\u00e6rming sine fordeler og ulemper. Noen oppgaver er lettere \u00e5 utf\u00f8re med \u00e9n l\u00f8sning, mens andre er vanskeligere med en annen. I starten utf\u00f8rte jeg distribusjoner manuelt, men etter \u00e5 ha kommet over noen artikler om Weave Flux, bestemte jeg meg for \u00e5 implementere GitOps-prosesser for alle prosjektene mine. For grunnleggende maler var dette enkelt, men jeg begynte deretter \u00e5 m\u00f8te utfordringer med Helm-diagrammer. Da tilb\u00f8d Weave Flux bare en tidlig versjon av Helm Chart Operator, men selv n\u00e5 er noen oppgaver vanskeligere p\u00e5 grunn av behovet for manuelt \u00e5 opprette hemmeligheter og bruke dem. Du kan si at pull-tiln\u00e6rmingen er mye sikrere, siden klyngelegitimasjonen ikke er tilgjengelig utenfor, noe som \u00f8ker sikkerheten s\u00e5 mye at det er verdt den ekstra innsatsen.<\/p>\n

              Etter \u00e5 ha tenkt litt, kom jeg til den overraskende konklusjonen at dette ikke er tilfelle. N\u00e5r det gjelder komponenter som krever maksimal beskyttelse, vil lagre av hemmeligheter og CI\/CD-systemer, samt Git-repositorier, v\u00e6re i en slik liste. Informasjonen inni dem er sv\u00e6rt s\u00e5rbar og trenger maksimal beskyttelse. I tillegg, hvis noen bryter seg inn i Git-repositoriet ditt og kan pushe kode dit, kan de distribuere hva de vil (uavhengig av hvilken tiln\u00e6rming som brukes, enten det er pull eller push), og infiltrere systemene i klyngen. Dermed er de viktigste komponentene som krever beskyttelse, Git-repositoriet og CI\/CD-systemene, og ikke klyngelegitimasjonene. Hvis du har godt konfigurerte policyer og sikkerhetstiltak for slike systemer, og klyngelegitimasjonene hentes inn i pipeline bare som hemmeligheter, kan den ekstra sikkerheten fra pull-tiln\u00e6rmingen vise seg \u00e5 v\u00e6re mindre verdifull enn f\u00f8rst antatt.<\/p>\n

              S\u00e5, hvis pull-tiln\u00e6rmingen er mer arbeidskrevende og ikke gir noen sikkerhetsfordel, er det ikke logisk \u00e5 bruke kun push-tiln\u00e6rmingen? Men noen kan hevde at med push-tiln\u00e6rmingen er du for avhengig av CI-systemet, og det kan v\u00e6re bedre \u00e5 unng\u00e5 det for \u00e5 gj\u00f8re fremtidige migrasjoner enklere.<\/p>\n

              Etter min mening (som alltid) b\u00f8r man bruke det som passer best til den spesifikke situasjonen, eller kombinere. Jeg bruker personlig begge tiln\u00e6rmingene: Weave Flux for pull-baserte deployeringer som hovedsakelig inkluderer v\u00e5re egne tjenester, og push-tiln\u00e6rmingen med Helm og plugins som forenkler bruken av Helm-diagrammer til klyngen og lar deg enkelt opprette hemmeligheter. Jeg tror det aldri vil v\u00e6re \u00e9n l\u00f8sning som passer for alle tilfeller, fordi det alltid er mange nyanser og de avhenger av den spesifikke bruken. Jeg anbefaler sterkt GitOps \u2014 det gj\u00f8r livet mye enklere og \u00f8ker sikkerheten.<\/p>\n

              Jeg h\u00e5per min erfaring med dette emnet kan hjelpe deg med \u00e5 avgj\u00f8re hvilken metode som passer best for din type deployeringer, og jeg ser frem til \u00e5 h\u00f8re din mening.<\/p>\n

              P.S. Merknad fra oversetteren<\/h2>\n

              \nUlempen med pull-modellen er at det er vanskelig \u00e5 legge de rendert manifestene i Git, men det er ikke en ulempe at CD-pipeline i pull-modellen lever adskilt fra utrullingen og i praksis blir en pipeline av kategorien Continuous Apply<\/i>. Dette krever derfor enda mer innsats for \u00e5 samle status fra alle deployeringene og gi tilgang til logger\/status, helst med tilknytning til CD-systemet.<\/p>\n

              I denne forstand tillater push-modellen \u00e5 gi en viss garanti for utrulling, fordi levetiden til pipeline kan settes lik levetiden til utrullingen.<\/p>\n

              Vi har testet begge modeller og kommet til de samme konklusjonene som forfatteren av artikkelen:<\/p>\n

                \n
              1. Pull-modellen passer oss for \u00e5 organisere oppdatering av systemkomponenter p\u00e5 et stort antall klynger (se artikkelen om addon-operator<\/a><\/noindex>).<\/li>\n
              2. Push-modellen basert p\u00e5 GitLab CI passer godt for utrulling av applikasjoner ved hjelp av Helm-diagrammer. Utrullingen av deployeringene i pipeline er sporet med hjelp av verkt\u00f8yet werf<\/a><\/noindex>. For \u00f8vrig, i konteksten av dette prosjektet h\u00f8rte vi stadig \u00abGitOps\u00bb da vi diskuterte aktuelle problemer for DevOps-ingeni\u00f8rer p\u00e5 v\u00e5r stand p\u00e5 KubeCon Europe 19.<\/li>\n<\/ol>\n

                <\/p>\n

                P.P.S. fra oversetteren<\/h2>\n

                \nAlso read in our blog:<\/p>\n