{"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\/sv\/blog\/administrirovanie\/gitops-sravnenie-metodov-pull-i-push","title":{"rendered":"GitOps: J\u00e4mf\u00f6relse mellan Pull och Push-metoder","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Obs. \u00f6vers.<\/b>: Inom Kubernetes-samh\u00e4llet vinner en trend som kallas GitOps tydlig popularitet, vilket vi personligen har bevittnat, genom att bes\u00f6ka<\/a><\/noindex> KubeCon Europe 2019. Denna term skapades relativt nyligen av<\/a><\/noindex> chefen f\u00f6r Weaveworks \u2013 Alexis Richardson \u2013 och betyder till\u00e4mpningen av verktyg som utvecklare \u00e4r vana vid (fr\u00e4mst Git, vilket ocks\u00e5 ger namnet) f\u00f6r att l\u00f6sa drifts\u00e4ttningsproblem. Specifikt handlar det om drifts\u00e4ttningen av Kubernetes genom att lagra dess konfigurationer i Git och automatiskt till\u00e4mpa \u00e4ndringar i klustret. Om tv\u00e5 tillv\u00e4gag\u00e5ngss\u00e4tt f\u00f6r denna drifts\u00e4ttning ber\u00e4ttar Matthias Jg i denna artikel.<\/i><\/p>\n

\"GitOps:
\n
\nF\u00f6rra \u00e5ret (egentligen skedde detta formellt i augusti 2017 \u2013 anm. \u00f6vers.)<\/i> En ny metod f\u00f6r distribution av applikationer i Kubernetes har dykt upp. Den kallas GitOps, och den grundar sig p\u00e5 en grundl\u00e4ggande uppfattning om att versionering av deployment g\u00f6rs i en s\u00e4ker Git-repository.<\/a><\/noindex><\/p>\n

Huvudf\u00f6rdelarna med denna metod \u00e4r f\u00f6ljande<\/b>:<\/p>\n

    \n
  1. Versionering av deployment och \u00e4ndringshistorik<\/b>. Tillst\u00e5ndet f\u00f6r hela klustret lagras i en Git-repository, och deployment uppdateras endast genom commits. Dessutom kan alla \u00e4ndringar sp\u00e5ras med hj\u00e4lp av commit-historik.<\/li>\n
  2. \u00c5terst\u00e4llningar med hj\u00e4lp av vanliga Git-kommandon<\/b>. En enkel git reset<\/code> m\u00f6jligg\u00f6r att \u00e5terst\u00e4lla \u00e4ndringar i deployments; tidigare tillst\u00e5nd \u00e4r alltid tillg\u00e4ngliga.<\/li>\n
  3. F\u00e4rdigt \u00e5tkomstkontroll<\/b>. Vanligtvis inneh\u00e5ller Git-system m\u00e5nga konfidentiella uppgifter, s\u00e5 de flesta f\u00f6retag l\u00e4gger stor vikt vid att skydda dem. D\u00e4rf\u00f6r omfattar detta skydd \u00e4ven operationer med deployments.<\/li>\n
  4. Policies f\u00f6r drifts\u00e4ttningar<\/b>. De flesta Git-system har ursprungligen st\u00f6d f\u00f6r olika grenpolicyer \u2014 till exempel kan endast pull requests uppdatera master, och \u00e4ndringar m\u00e5ste granskas och godk\u00e4nnas av en annan teammedlem. Liksom vid \u00e5tkomstr\u00e4tt kontrolleras samma policyer vid uppdatering av deployments.<\/li>\n<\/ol>\n

    \nSom ni ser finns det m\u00e5nga f\u00f6rdelar med GitOps-metoden. Under det senaste \u00e5ret har tv\u00e5 tillv\u00e4gag\u00e5ngss\u00e4tt blivit s\u00e4rskilt popul\u00e4ra. Det ena \u00e4r baserat p\u00e5 push, det andra p\u00e5 pull. Innan vi g\u00e5r in p\u00e5 dem, l\u00e5t oss f\u00f6rst titta p\u00e5 hur typiska Kubernetes-deployments ser ut.<\/p>\n

    Metoder f\u00f6r drifts\u00e4ttning<\/h2>\n

    \nUnder de senaste \u00e5ren har olika metoder och verktyg f\u00f6r drifts\u00e4ttningar blivit etablerade i Kubernetes:<\/p>\n

      \n
    1. Baserat p\u00e5 ursprungliga mallar Kubernetes\/Kustomize<\/b>Det h\u00e4r \u00e4r det enklaste s\u00e4ttet att distribuera applikationer i Kubernetes. Utvecklaren skapar grundl\u00e4ggande YAML-filer och till\u00e4mpar dem. F\u00f6r att undvika att st\u00e4ndigt skriva om samma mallar, utvecklades Kustomize (som omvandlar Kubernetes-mallar till moduler). Obs. \u00f6vers.<\/b>: Kustomize har integrerats i kubectl med utg\u00e5van av Kubernetes 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Helm Charts<\/b>. Helm-diagram g\u00f6r det m\u00f6jligt att skapa upps\u00e4ttningar av mallar, init-containrar, sidecars etc., som anv\u00e4nds f\u00f6r att deploya applikationer med mer flexibla anpassningsm\u00f6jligheter \u00e4n i mallbaserat tillv\u00e4gag\u00e5ngss\u00e4tt. Grunden f\u00f6r denna metod \u00e4r mappade YAML-filer. Helm fyller dem med olika parametrar och skickar dem sedan till Tiller \u2014 klusterkomponenten som implementerar dem i klustret och till\u00e5ter uppdateringar och \u00e5terst\u00e4llningar. Viktigt \u00e4r att Helm i grund och botten bara ins\u00e4tter n\u00f6dv\u00e4ndiga v\u00e4rden i mallarna och till\u00e4mpar dem p\u00e5 samma s\u00e4tt som i det traditionella tillv\u00e4gag\u00e5ngss\u00e4ttet (mer om hur detta fungerar och hur man kan anv\u00e4nda det, l\u00e4s i v\u00e5r artikel om Helm<\/a><\/noindex> \u2014 anm. red.)<\/i>. Det finns en stor variation av f\u00e4rdiga Helm-chartar som t\u00e4cker ett brett spektrum av uppgifter.<\/li>\n
    3. Alternativa verktyg<\/b>. Det finns m\u00e5nga alternativa verktyg. Gemensamt f\u00f6r dem alla \u00e4r att de omvandlar vissa mallfiler till begripbara Kubernetes YAML-filer och till\u00e4mpar dem.<\/li>\n<\/ol>\n

      \nI v\u00e5rt arbete anv\u00e4nder vi st\u00e4ndigt Helm-charts f\u00f6r viktiga verktyg (eftersom mycket redan \u00e4r klart, vilket f\u00f6renklar livet) och \"rena\" Kubernetes YAML-filer f\u00f6r att distribuera egna applikationer.<\/p>\n

      Pull & Push<\/h2>\n

      \nI ett av sina senaste blogginl\u00e4gg presenterade jag verktyget Weave Flux<\/a><\/noindex>, vilket m\u00f6jligg\u00f6r att commitera mallar till Git-repository och uppdatera deployment efter varje commit eller push av containern. Min erfarenhet visar att detta verktyg \u00e4r en av de grundl\u00e4ggande i marknadsf\u00f6ringen av pull-approachen, s\u00e5 jag kommer ofta att referera till det. Om du vill veta mer om hur du anv\u00e4nder det, h\u00e4r \u00e4r en l\u00e4nk till artikeln<\/a><\/noindex>.<\/p>\n

      NB!<\/b> Alla f\u00f6rdelar med att anv\u00e4nda GitOps kvarst\u00e5r f\u00f6r b\u00e5da tillv\u00e4gag\u00e5ngss\u00e4tena.<\/i><\/p>\n

      Pull-baserat tillv\u00e4gag\u00e5ngss\u00e4tt<\/h2>\n

      \n\"GitOps:
      \n
      \nI grunden f\u00f6r pull-metoden ligger det faktum att alla \u00e4ndringar till\u00e4mpas inifr\u00e5n klustret. Inuti klustret finns en operator som regelbundet kontrollerar de relaterade Git-repositorierna och Docker-registret. Om det sker n\u00e5gra \u00e4ndringar uppdateras klustrets tillst\u00e5nd inifr\u00e5n. Det anses vanligtvis att en s\u00e5dan process \u00e4r ganska s\u00e4ker, eftersom inga externa klienter har administrat\u00f6rsr\u00e4ttigheter till klustret.<\/p>\n

      F\u00f6rdelar:<\/b><\/p>\n

        \n
      1. Ingen extern klient har r\u00e4ttigheter att g\u00f6ra \u00e4ndringar i klustret, alla uppdateringar till\u00e4mpas inifr\u00e5n.<\/li>\n
      2. Vissa verktyg g\u00f6r det ocks\u00e5 m\u00f6jligt att synkronisera uppdateringar av Helm-diagram och knyta dem till klustret.<\/li>\n
      3. Docker-registret kan skannas efter nya versioner. Om en ny bild dyker upp, uppdateras Git-repositoriet och distributionen till den nya versionen.<\/li>\n
      4. Pull-verktyg kan distribueras \u00f6ver olika namnrymder med olika Git-repositorier och \u00e5tkomstr\u00e4ttigheter. Detta g\u00f6r det m\u00f6jligt att till\u00e4mpa en fleranv\u00e4ndarmodell. Till exempel kan team A anv\u00e4nda namnrymd A, team B namnrymd B, och teamet som hanterar infrastrukturen kan anv\u00e4nda den globala namnrymden.<\/li>\n
      5. I allm\u00e4nhet \u00e4r verktygen ganska l\u00e4tta.<\/li>\n
      6. I kombination med verktyg som operatorn Bitnami Sealed Secrets<\/a><\/noindex>, kan hemligheter lagras krypterat i Git-repositoriet och h\u00e4mtas inuti klustret.<\/li>\n
      7. Det saknas kopplingar till CD-pipelines, eftersom distributionerna sker inuti klustret.<\/li>\n<\/ol>\n

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

          \n
        1. Att hantera hemligheter f\u00f6r deployment fr\u00e5n Helm-diagram \u00e4r mer komplicerat \u00e4n vanliga, eftersom de f\u00f6rst m\u00e5ste genereras som till exempel sealed secrets, sedan avkrypteras av den interna operat\u00f6ren och f\u00f6rst d\u00e4refter blir de tillg\u00e4ngliga f\u00f6r pull-verktyget. Sedan kan man k\u00f6ra en release i Helm med v\u00e4rden fr\u00e5n redan distribuerade hemligheter. Det enklaste s\u00e4ttet \u00e4r att skapa en hemlighet med alla Helm-v\u00e4rden som anv\u00e4nds f\u00f6r deployment, avkryptera den och commita den till Git.<\/li>\n
        2. Genom att anv\u00e4nda en pull-approach \u00e4r du knuten till verktyg som hanterar pulls. Detta begr\u00e4nsar m\u00f6jligheten att anpassa deploymentsprocessen i klustret. Till exempel g\u00f6rs arbetet med Kustomize mer komplicerat eftersom det m\u00e5ste utf\u00f6ras innan de slutliga mallarna g\u00e5r till Git. Jag s\u00e4ger inte att man inte kan anv\u00e4nda separata verktyg, men de \u00e4r sv\u00e5rare att integrera i deployeringsprocessen.<\/li>\n<\/ol>\n

          <\/p>\n

          Push-baserad metod<\/h2>\n

          \n\"GitOps:
          \n
          \nI push-metoden initierar ett externt system (vanligtvis CD-pipelines) deployment i klustret efter en commit till Git-repositoriet eller vid framg\u00e5ngsrik slutf\u00f6rande av f\u00f6reg\u00e5ende CI-pipeline. I denna metod har systemet \u00e5tkomst till klustret.<\/p>\n

          F\u00f6rdelar<\/b>:<\/p>\n

            \n
          1. S\u00e4kerheten best\u00e4ms av Git-repositoriet och byggpipen.<\/li>\n
          2. Det \u00e4r enklare att distribuera Helm-charts, det finns st\u00f6d f\u00f6r Helm-plugins.<\/li>\n
          3. Det \u00e4r l\u00e4ttare att hantera hemligheter, eftersom hemligheter kan till\u00e4mpas i pipelines och ocks\u00e5 lagras i Git i krypterad form (beroende p\u00e5 anv\u00e4ndarens preferenser).<\/li>\n
          4. Ingen bindning till ett specifikt verktyg, eftersom alla typer av verktyg kan anv\u00e4ndas.<\/li>\n
          5. Versionsuppdateringar av containrar kan initieras av byggpipen.<\/li>\n<\/ol>\n

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

              \n
            1. Uppgifter f\u00f6r \u00e5tkomst till klustret finns inom byggsystemet.<\/li>\n
            2. Uppdatering av containrar f\u00f6r deployment \u00e4r fortfarande enklare med en pull-process.<\/li>\n
            3. Stark beroende av CD-systemet, eftersom de pipelines vi beh\u00f6ver kanske ursprungligen \u00e4r skrivna f\u00f6r Gitlab Runners, och sedan best\u00e4mmer teamet sig f\u00f6r att byta till Azure DevOps eller Jenkins\u2026 och det blir n\u00f6dv\u00e4ndigt att migrera en stor m\u00e4ngd byggpipelines.<\/li>\n<\/ol>\n

              <\/p>\n

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

              \nSom vanligt har varje metod sina f\u00f6rdelar och nackdelar. Vissa uppgifter \u00e4r l\u00e4ttare att genomf\u00f6ra med en metod och sv\u00e5rare med en annan. Jag b\u00f6rjade med att g\u00f6ra distributioner manuellt, men efter att ha snubblat \u00f6ver n\u00e5gra artiklar om Weave Flux beslutade jag att implementera GitOps-processer f\u00f6r alla projekt. F\u00f6r grundl\u00e4ggande mallar var det enkelt, men sedan b\u00f6rjade jag st\u00f6ta p\u00e5 sv\u00e5righeter med Helm-diagram. Vid den tiden erbj\u00f6d Weave Flux bara en tidig version av Helm Chart Operator, men \u00e4ven nu \u00e4r vissa uppgifter sv\u00e5rare p\u00e5 grund av behovet av att manuellt skapa hemligheter och till\u00e4mpa dem. Man kan s\u00e4ga att pull-metoden \u00e4r mycket s\u00e4krare, eftersom klustrets autentiseringsuppgifter \u00e4r otillg\u00e4ngliga utanf\u00f6r det, vilket \u00f6kar s\u00e4kerheten s\u00e5 mycket att det motiverar den extra anstr\u00e4ngningen.<\/p>\n

              Efter lite eftertanke kom jag till en ov\u00e4ntad slutsats: det \u00e4r inte s\u00e5. N\u00e4r det kommer till komponenter som kr\u00e4ver maximal skydd, inkluderar en s\u00e5dan lista hemlighetslagringsl\u00f6sningar och CI\/CD-system, s\u00e5v\u00e4l som Git-repositorier. Informationen d\u00e4r \u00e4r mycket s\u00e5rbar och beh\u00f6ver maximal skydd. Dessutom, om n\u00e5gon lyckas tr\u00e4nga sig in i ditt Git-repository och kan pusha kod dit, s\u00e5 kan de implementera vad de vill (oavsett om det handlar om en pull- eller push-approach) och infiltrera klustrets system. S\u00e5ledes \u00e4r de mest kritiska komponenterna som beh\u00f6ver skydd, Git-repository och CI\/CD-system, och inte klusters\u00e5tg\u00e4rder. Om du har bra konfigurerade policyer och s\u00e4kerhets\u00e5tg\u00e4rder f\u00f6r s\u00e5dana system, och klusteruppgifterna h\u00e4mtas i pipelines endast i form av hemligheter, kan den extra s\u00e4kerheten av pull-approchen visa sig vara mindre v\u00e4rdefull \u00e4n vad som f\u00f6rst antogs.<\/p>\n

              S\u00e5, om pull-metoden \u00e4r mer arbetskr\u00e4vande och inte ger n\u00e5gra s\u00e4kerhetsvinster, \u00e4r det inte irrationellt att bara anv\u00e4nda push-metoden? Men n\u00e5gon kan h\u00e4vda att i push-metoden \u00e4r du alltf\u00f6r beroende av CI\/CD-systemet och att det kanske \u00e4r b\u00e4ttre att inte g\u00f6ra s\u00e5, s\u00e5 att det i framtiden blir l\u00e4ttare att genomf\u00f6ra migrationer.<\/p>\n

              Enligt min \u00e5sikt (som alltid) b\u00f6r man anv\u00e4nda det som passar b\u00e4st f\u00f6r det specifika fallet eller kombinera. Personligen anv\u00e4nder jag b\u00e5da metoderna: Weave Flux f\u00f6r deployment baserat p\u00e5 pull, som fr\u00e4mst inkluderar v\u00e5ra egna tj\u00e4nster, och push-metoden med Helm och plugins, vilket f\u00f6renklar till\u00e4mpningen av Helm-diagram p\u00e5 klustret och g\u00f6r det m\u00f6jligt att enkelt skapa hemligheter. Jag tror att det aldrig kommer att finnas en enda l\u00f6sning som passar alla fall, eftersom det alltid finns m\u00e5nga nyanser som beror p\u00e5 det specifika anv\u00e4ndningsfallet. Jag rekommenderar starkt GitOps \u2013 det g\u00f6r livet mycket l\u00e4ttare och \u00f6kar s\u00e4kerheten.<\/p>\n

              Jag hoppas att min erfarenhet inom detta \u00e4mne kan hj\u00e4lpa er att best\u00e4mma vilken metod som passar b\u00e4st f\u00f6r er typ av deployment, och jag ser fram emot att h\u00f6ra er \u00e5sikt.<\/p>\n

              P.S. Notering fr\u00e5n \u00f6vers\u00e4ttaren<\/h2>\n

              \nEn nackdel med pull-modellen \u00e4r att det \u00e4r sv\u00e5rt att l\u00e4gga de renderade manifesten i Git, men det finns ingen nackdel i att CD-pipelinen i pull-modellen lever separat fr\u00e5n rollout och i princip blir en pipeline av typen Continuous Apply<\/i>. D\u00e4rf\u00f6r kommer det att kr\u00e4va \u00e4nnu mer anstr\u00e4ngning f\u00f6r att samla in status fr\u00e5n alla deployment och p\u00e5 n\u00e5got s\u00e4tt ge tillg\u00e5ng till loggar\/status, g\u00e4rna kopplade till CD-systemet.<\/p>\n

              I det h\u00e4r avseendet g\u00f6r push-modellen det m\u00f6jligt att ge vissa garantier f\u00f6r distribution, eftersom livsl\u00e4ngden p\u00e5 pipeline kan g\u00f6ras lika med livsl\u00e4ngden f\u00f6r distribution.<\/p>\n

              Vi har testat b\u00e5da modellerna och kommit fram till samma slutsatser som artikelns f\u00f6rfattare:<\/p>\n

                \n
              1. Pull-modellen passar oss f\u00f6r att organisera uppdatering av systemkomponenter p\u00e5 ett stort antal kluster (se. artikeln om addon-operator<\/a><\/noindex>).<\/li>\n
              2. Push-modellen baserad p\u00e5 GitLab CI passar bra f\u00f6r distribution av applikationer med hj\u00e4lp av Helm-diagram. Samtidigt \u00f6vervakas distributionen av deployment inom pipelines med hj\u00e4lp av verktyget werf<\/a><\/noindex>. F\u00f6r \u00f6vrigt, i sammanhanget av v\u00e5rt projekt h\u00f6rde vi konstant \"GitOps\" n\u00e4r vi diskuterade aktuella problem med DevOps-ingenj\u00f6rer vid v\u00e5r monter p\u00e5 KubeCon Europe'19.<\/li>\n<\/ol>\n

                <\/p>\n

                P.P.S. fr\u00e5n \u00f6vers\u00e4ttaren<\/h2>\n

                \nL\u00e4s \u00e4ven i v\u00e5r blogg:<\/p>\n