{"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\/pl\/blog\/administrirovanie\/gitops-sravnenie-metodov-pull-i-push","title":{"rendered":"GitOps: por\u00f3wnanie metod Pull i Push","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Przyp. t\u0142um.<\/b>: W spo\u0142eczno\u015bci Kubernetes zyskuje na popularno\u015bci trend zwany GitOps, w co osobi\u015bcie si\u0119 przekonali\u015bmy, uczestnicz\u0105c w<\/a><\/noindex> KubeCon Europe 2019. Termin ten zosta\u0142 stworzony stosunkowo niedawno przez szefa firmy Weaveworks \u2014 Alexisa Richardsona \u2014 i oznacza stosowanie znanych deweloperom narz\u0119dzi (przede wszystkim \u2014 Git, st\u0105d nazwa) do rozwi\u0105zywania problem\u00f3w zwi\u0105zanych z eksploatacj\u0105. W szczeg\u00f3lno\u015bci chodzi o eksploatacj\u0119 Kubernetes poprzez przechowywanie jego konfiguracji w Git i automatyczne wdra\u017canie zmian w klastrze. O dw\u00f3ch podej\u015bciach do tego wdra\u017cania opowiada Matthias Jg w tym artykule.<\/a><\/noindex> W zesz\u0142ym roku<\/i><\/p>\n

\"GitOps:
\n
\n(w rzeczywisto\u015bci formalnie mia\u0142o to miejsce w sierpniu 2017 r. \u2014 przyp. t\u0142um.) pojawi\u0142o si\u0119 nowe podej\u015bcie do wdra\u017cania aplikacji w Kubernetes. Nazywa si\u0119 GitOps i jego podstawow\u0105 ide\u0105 jest to, \u017ce wersjonowanie deployment\u00f3w odbywa si\u0119 w bezpiecznym \u015brodowisku repozytorium Git.<\/i> Pojawi\u0142 si\u0119 nowy spos\u00f3b wdra\u017cania aplikacji w Kubernetes. Nazywa si\u0119 GitOps, a jego podstaw\u0105 jest za\u0142o\u017cenie, \u017ce \u015bledzenie wersji wdro\u017ce\u0144 odbywa si\u0119 w bezpiecznym \u015brodowisku repozytorium Git.<\/a><\/noindex><\/p>\n

Wersjonowanie deployment\u00f3w i historia zmian<\/b>:<\/p>\n

    \n
  1. Wersjonowanie wdro\u017ce\u0144 i historia zmian<\/b>. Stan ca\u0142ego klastra jest przechowywany w repozytorium Git, a wdro\u017cenia aktualizowane s\u0105 tylko za pomoc\u0105 commit\u00f3w. Dodatkowo wszystkie zmiany mo\u017cna \u015bledzi\u0107 za pomoc\u0105 historii commit\u00f3w.<\/li>\n
  2. . Prosta<\/b>git reset pozwala na cofanie zmian w deploymentach; zawsze dost\u0119pne s\u0105 poprzednie stany.<\/code> pozwala na przywracanie zmian w wdro\u017ceniach; zawsze dost\u0119pne s\u0105 wcze\u015bniejsze stany.<\/li>\n
  3. . Zwykle system Git zawiera wiele poufnych danych, dlatego wi\u0119kszo\u015b\u0107 firm zwraca szczeg\u00f3ln\u0105 uwag\u0119 na jego zabezpieczenia. Odpowiednio, ta ochrona obejmuje r\u00f3wnie\u017c operacje zwi\u0105zane z deploymentami.<\/b>. Zwykle systemy Git zawieraj\u0105 wiele poufnych danych, dlatego wi\u0119kszo\u015b\u0107 firm szczeg\u00f3lnie dba o ich zabezpieczenie. St\u0105d te\u017c ta ochrona dotyczy r\u00f3wnie\u017c operacji na wdro\u017ceniach.<\/li>\n
  4. . Wi\u0119kszo\u015b\u0107 system\u00f3w Git domy\u015blnie wspiera polityki dla r\u00f3\u017cnych ga\u0142\u0119zi \u2014 na przyk\u0142ad tylko pull requesty mog\u0105 aktualizowa\u0107 master, a zmiany musz\u0105 by\u0107 zweryfikowane i zaakceptowane przez innego cz\u0142onka zespo\u0142u. Podobnie jak w przypadku kontroli dost\u0119pu, te same polityki stosuje si\u0119 do aktualizacji deployment\u00f3w.<\/b>. Wi\u0119kszo\u015b\u0107 system\u00f3w Git domy\u015blnie wspiera polityki dla r\u00f3\u017cnych ga\u0142\u0119zi \u2014 na przyk\u0142ad tylko pull requesty mog\u0105 aktualizowa\u0107 master, a zmiany musz\u0105 by\u0107 zatwierdzone przez innego cz\u0142onka zespo\u0142u. Tak jak w przypadku kontroli dost\u0119pu, te same polityki stosuje si\u0119 do aktualizacji wdro\u017ce\u0144.<\/li>\n<\/ol>\n

    \nJak wida\u0107, metoda GitOps ma wiele zalet. W ci\u0105gu ostatniego roku szczeg\u00f3ln\u0105 popularno\u015b\u0107 zyska\u0142y dwa podej\u015bcia. Jedno opiera si\u0119 na push, drugie \u2014 na pull. Zanim je om\u00f3wimy, przyjrzyjmy si\u0119 najpierw, jak wygl\u0105daj\u0105 typowe wdro\u017cenia Kubernetes.<\/p>\n

    W ci\u0105gu ostatnich kilku lat w Kubernetes ugruntowa\u0142y si\u0119 r\u00f3\u017cne metody i narz\u0119dzia do wdra\u017cania:<\/h2>\n

    \nNa podstawie rodzimych szablon\u00f3w Kubernetes\/Kustomize<\/p>\n

      \n
    1. Na podstawie natywnych szablon\u00f3w Kubernetes\/Kustomize<\/b>To najprostszy spos\u00f3b wdra\u017cania aplikacji w Kubernetes. Programista tworzy podstawowe pliki YAML i je stosuje. Aby unikn\u0105\u0107 ci\u0105g\u0142ego przepisywania tych samych szablon\u00f3w, stworzono Kustomize (przekszta\u0142ca szablony Kubernetes w modu\u0142y). Przyp. t\u0142um.<\/b>: Kustomize zosta\u0142 zintegrowany z kubectl w wydaniu Kubernetes 1.14<\/a><\/noindex>.<\/i><\/li>\n
    2. Chart\u00f3w Helm<\/b>. Wykresy Helm pozwalaj\u0105 tworzy\u0107 zestawy szablon\u00f3w, kontener\u00f3w init, sidecar\u00f3w itd., kt\u00f3re s\u0105 stosowane do wdra\u017cania aplikacji z bardziej elastycznymi mo\u017cliwo\u015bciami konfiguracji ni\u017c w podej\u015bciu opartym na szablonach. W podstawach tej metody le\u017c\u0105 szablony plik\u00f3w YAML. Helm wype\u0142nia je r\u00f3\u017cnymi parametrami, a nast\u0119pnie przesy\u0142a je do Tillera \u2014 komponentu klastra, kt\u00f3ry wdra\u017ca je w klastrze i umo\u017cliwia aktualizacje i wycofania. Wa\u017cne jest to, \u017ce w istocie Helm po prostu wstawia odpowiednie warto\u015bci do szablon\u00f3w, a nast\u0119pnie stosuje je tak samo, jak w tradycyjnym podej\u015bciu (wi\u0119cej o tym, jak to dzia\u0142a i jak mo\u017cna to wykorzysta\u0107, przeczytaj w naszej artyku\u0142 o Helm<\/a><\/noindex> \u2014 przyp. t\u0142um.)<\/i>. Istnieje wiele gotowych chart\u00f3w Helm, obejmuj\u0105cych szeroki zakres zada\u0144.<\/li>\n
    3. Alternatywne narz\u0119dzia<\/b>. Istnieje wiele alternatywnych narz\u0119dzi. Wszystkie \u0142\u0105cz\u0105, \u017ce przekszta\u0142caj\u0105 pewne pliki szablon\u00f3w w zrozumia\u0142e pliki YAML Kubernetes, a nast\u0119pnie je stosuj\u0105.<\/li>\n<\/ol>\n

      \nW naszej pracy stale korzystamy z chart\u00f3w Helm do wa\u017cnych narz\u0119dzi (poniewa\u017c wiele z nich jest ju\u017c gotowych, co znacznie u\u0142atwia \u017cycie) oraz 'czystych' plik\u00f3w YAML Kubernetes do wdra\u017cania w\u0142asnych aplikacji.<\/p>\n

      Pull & Push<\/h2>\n

      \nW jednym z moich ostatnich wpis\u00f3w na blogu przedstawi\u0142em narz\u0119dzie Weave Flux<\/a><\/noindex>, umo\u017cliwiaj\u0105cy commitowanie szablon\u00f3w do repozytorium Git i aktualizowanie wdro\u017cenia po ka\u017cdym commicie lub pushu kontenera. Moje do\u015bwiadczenie pokazuje, \u017ce to narz\u0119dzie jest jednym z kluczowych w promowaniu podej\u015bcia pull, dlatego b\u0119d\u0119 si\u0119 na nie cz\u0119sto powo\u0142ywa\u0142. Je\u015bli chcesz dowiedzie\u0107 si\u0119 wi\u0119cej o tym, jak go u\u017cywa\u0107, oto link do artyku\u0142u<\/a><\/noindex>.<\/p>\n

      NB!<\/b> Wszystkie zalety korzystania z GitOps s\u0105 zachowane w obu podej\u015bciach.<\/i><\/p>\n

      Podej\u015bcie oparte na Pull<\/h2>\n

      \n\"GitOps:
      \n
      \nPodstaw\u0105 podej\u015bcia pull jest fakt, \u017ce wszystkie zmiany s\u0105 wprowadzane wewn\u0105trz klastra. W obr\u0119bie klastra znajduje si\u0119 operator, kt\u00f3ry regularnie sprawdza powi\u0105zane repozytoria Git i Docker Registry. Je\u015bli dochodzi w nich do jakichkolwiek zmian, stan klastra jest aktualizowany od wewn\u0105trz. Zazwyczaj uwa\u017ca si\u0119, \u017ce taki proces jest do\u015b\u0107 bezpieczny, poniewa\u017c \u017caden zewn\u0119trzny klient nie ma dost\u0119pu do praw administracyjnych klastra.<\/p>\n

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

        \n
      1. \u017baden zewn\u0119trzny klient nie ma uprawnie\u0144 do wprowadzania zmian w klastrze, wszystkie aktualizacje s\u0105 wprowadzane od wewn\u0105trz.<\/li>\n
      2. Niekt\u00f3re narz\u0119dzia pozwalaj\u0105 r\u00f3wnie\u017c synchronizowa\u0107 aktualizacje Helm chart\u00f3w i powi\u0105zywa\u0107 je z klastrem.<\/li>\n
      3. Docker Registry mo\u017cna skanowa\u0107 w poszukiwaniu nowych wersji. Je\u015bli nowy obraz si\u0119 pojawia, repozytorium Git i wdro\u017cenie s\u0105 aktualizowane do nowej wersji.<\/li>\n
      4. Narz\u0119dzia pull mog\u0105 by\u0107 rozdzielone na r\u00f3\u017cne przestrzenie nazw z r\u00f3\u017cnymi repozytoriami Git i uprawnieniami dost\u0119pu. Dzi\u0119ki temu mo\u017cna zastosowa\u0107 model wielodost\u0119powy (multitenant). Na przyk\u0142ad zesp\u00f3\u0142 A mo\u017ce korzysta\u0107 z przestrzeni nazw A, zesp\u00f3\u0142 B \u2014 z przestrzeni nazw B, a zesp\u00f3\u0142 zajmuj\u0105cy si\u0119 infrastruktur\u0105 mo\u017ce korzysta\u0107 z przestrzeni globalnej.<\/li>\n
      5. Zazwyczaj narz\u0119dzia s\u0105 do\u015b\u0107 lekkie.<\/li>\n
      6. W po\u0142\u0105czeniu z takimi narz\u0119dziami jak operator Bitnami Sealed Secrets<\/a><\/noindex>, sekrety mog\u0105 by\u0107 przechowywane w zaszyfrowanej formie w repozytorium Git i wydobywane wewn\u0105trz klastra.<\/li>\n
      7. Brak po\u0142\u0105czenia z pipeline'ami CD, poniewa\u017c wdro\u017cenia odbywaj\u0105 si\u0119 wewn\u0105trz klastra.<\/li>\n<\/ol>\n

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

          \n
        1. Zarz\u0105dzanie sekretami wdro\u017ce\u0144 z wykres\u00f3w Helm jest trudniejsze ni\u017c zwyk\u0142ymi, poniewa\u017c najpierw musz\u0105 by\u0107 one generowane w formie, powiedzmy, sealed secrets, a nast\u0119pnie odszyfrowywane przez wewn\u0119trznego operatora, i dopiero wtedy staj\u0105 si\u0119 dost\u0119pne dla narz\u0119dzia pull. Nast\u0119pnie mo\u017cna uruchomi\u0107 wydanie w Helmie z warto\u015bciami ju\u017c wdro\u017conych sekret\u00f3w. Najprostszym sposobem jest utworzenie sekretu ze wszystkimi warto\u015bciami Helm u\u017cywanymi do wdro\u017cenia, odszyfrowanie go i zapisanie w Git.<\/li>\n
        2. Stosuj\u0105c podej\u015bcie pull, jeste\u015b zwi\u0105zany z narz\u0119dziami operuj\u0105cymi na pull. To ogranicza mo\u017cliwo\u015b\u0107 dostosowania procesu wdra\u017cania w klastrze. Na przyk\u0142ad praca z Kustomize jest trudna, poniewa\u017c musi by\u0107 wykonana zanim ostateczne szablony trafi\u0105 do Gita. Nie twierdz\u0119, \u017ce nie mo\u017cna u\u017cywa\u0107 oddzielnych narz\u0119dzi, ale ich integracja w proces wdra\u017cania jest bardziej skomplikowana.<\/li>\n<\/ol>\n

          <\/p>\n

          Podej\u015bcie oparte na Push<\/h2>\n

          \n\"GitOps:
          \n
          \nW podej\u015bciu push zewn\u0119trzny system (g\u0142\u00f3wnie pipeline'y CD) uruchamia wdro\u017cenia w klastrze po zatwierdzeniu w repozytorium Git lub po pomy\u015blnym zako\u0144czeniu poprzedniego pipeline'a CI. W tym podej\u015bciu system ma dost\u0119p do klastra.<\/p>\n

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

            \n
          1. Bezpiecze\u0144stwo jest okre\u015blane przez repozytorium Git i pipeline budowy.<\/li>\n
          2. Wdra\u017canie chart\u00f3w Helm jest prostsze, istnieje wsparcie dla wtyczek Helm.<\/li>\n
          3. Zarz\u0105dzanie sekretami jest \u0142atwiejsze, poniewa\u017c sekrety mo\u017cna stosowa\u0107 w pipeline'ach, a tak\u017ce przechowywa\u0107 w Git w zaszyfrowanej formie (w zale\u017cno\u015bci od preferencji u\u017cytkownika).<\/li>\n
          4. Brak przywi\u0105zania do konkretnego narz\u0119dzia, poniewa\u017c mo\u017cna u\u017cywa\u0107 r\u00f3\u017cnych ich typ\u00f3w.<\/li>\n
          5. Aktualizacje wersji kontener\u00f3w mog\u0105 by\u0107 inicjowane przez pipeline budowy.<\/li>\n<\/ol>\n

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

              \n
            1. Dane do dost\u0119pu do klastra znajduj\u0105 si\u0119 wewn\u0105trz systemu budowy.<\/li>\n
            2. Aktualizacja kontener\u00f3w wdro\u017ce\u0144 jest wci\u0105\u017c prostsza z procesem pull.<\/li>\n
            3. Silne uzale\u017cnienie od systemu CD, poniewa\u017c potrzebne pipeline'y mog\u0105 by\u0107 pierwotnie napisane pod GitLab Runners, a p\u00f3\u017aniej zesp\u00f3\u0142 zdecyduje si\u0119 przej\u015b\u0107 na Azure DevOps lub Jenkins\u2026 wi\u0119c b\u0119dzie konieczne przeprowadzenie migracji du\u017cej liczby pipeline'\u00f3w budowy.<\/li>\n<\/ol>\n

              <\/p>\n

              Podsumowanie: Push czy Pull?<\/h2>\n

              \nJak to zwykle bywa, ka\u017cdy z podej\u015b\u0107 ma swoje zalety i wady. Niekt\u00f3re zadania \u0142atwiej wykona\u0107 jednym sposobem, a trudniej innym. Na pocz\u0105tku przeprowadza\u0142em wdro\u017cenia r\u0119cznie, ale po natkni\u0119ciu si\u0119 na kilka artyku\u0142\u00f3w o Weave Flux postanowi\u0142em wdro\u017cy\u0107 procesy GitOps dla wszystkich projekt\u00f3w. Dla podstawowych szablon\u00f3w okaza\u0142o si\u0119 to \u0142atwe, ale potem zacz\u0105\u0142em napotyka\u0107 trudno\u015bci w pracy z chartami Helm. W tamtym czasie Weave Flux oferowa\u0142 tylko wczesn\u0105 wersj\u0119 operatora Helm Chart, ale nawet teraz niekt\u00f3re zadania s\u0105 trudniejsze z powodu konieczno\u015bci r\u0119cznego tworzenia sekret\u00f3w i ich stosowania. Mo\u017cna powiedzie\u0107, \u017ce podej\u015bcie pull jest znacznie bardziej zabezpieczone, poniewa\u017c dane uwierzytelniaj\u0105ce klastra nie s\u0105 dost\u0119pne poza nim, co tak bardzo zwi\u0119ksza bezpiecze\u0144stwo, \u017ce warto ponie\u015b\u0107 dodatkowy wysi\u0142ek.<\/p>\n

              Po chwili refleksji doszed\u0142em do nieoczekiwanego wniosku, \u017ce tak nie jest. Je\u015bli chodzi o komponenty wymagaj\u0105ce maksymalnej ochrony, do takiego zestawienia nale\u017c\u0105 magazyny sekret\u00f3w oraz systemy CI\/CD, repozytoria Git. Informacje w nich s\u0105 bardzo podatne na ataki i potrzebuj\u0105 maksymalnej ochrony. Ponadto, je\u015bli kto\u015b wniknie do twojego repozytorium Git i b\u0119dzie m\u00f3g\u0142 wprowadzi\u0107 tam kod, to b\u0119dzie m\u00f3g\u0142 wdro\u017cy\u0107 cokolwiek zechce (niezale\u017cnie od wybranego podej\u015bcia, czy to pull czy push), i wnikn\u0105\u0107 do system\u00f3w klastra. Tak wi\u0119c najbardziej krytycznymi komponentami wymagaj\u0105cymi ochrony s\u0105 repozytorium Git oraz systemy CI\/CD, a nie po\u015bwiadczenia klastra. Je\u015bli masz dobrze skonfigurowane polityki i \u015brodki bezpiecze\u0144stwa dla tego typu system\u00f3w, a po\u015bwiadczenia klastra s\u0105 wydobywane do pipeline'\u00f3w tylko w postaci sekret\u00f3w, dodatkowe bezpiecze\u0144stwo podej\u015bcia pull mo\u017ce okaza\u0107 si\u0119 nie tak cenne, jak pocz\u0105tkowo zak\u0142adano.<\/p>\n

              Zatem, je\u015bli podej\u015bcie pull jest bardziej pracoch\u0142onne i nie przynosi korzy\u015bci w zakresie bezpiecze\u0144stwa, czy nie by\u0142oby logiczne u\u017cywa\u0107 tylko podej\u015bcia push? Ale kto\u015b mo\u017ce zauwa\u017cy\u0107, \u017ce w podej\u015bciu push jeste\u015b zbyt uzale\u017cniony od systemu CD i by\u0107 mo\u017ce lepiej jest tego nie robi\u0107, aby w przysz\u0142o\u015bci u\u0142atwi\u0107 migracje.<\/p>\n

              Moim zdaniem (jak zawsze) nale\u017cy u\u017cywa\u0107 tego, co najlepiej pasuje do konkretnego przypadku lub \u0142\u0105czy\u0107 r\u00f3\u017cne podej\u015bcia. Osobi\u015bcie korzystam z obu metod: Weave Flux do deployment\u00f3w opartych na pull, kt\u00f3re g\u0142\u00f3wnie obejmuj\u0105 nasze w\u0142asne us\u0142ugi, oraz podej\u015bcia push z Helm'em i wtyczkami, co u\u0142atwia stosowanie chart\u00f3w Helm do klastra i pozwala na bezproblemowe tworzenie sekret\u00f3w. My\u015bl\u0119, \u017ce nigdy nie b\u0119dzie jednego uniwersalnego rozwi\u0105zania, kt\u00f3re pasuje do wszystkich przypadk\u00f3w, poniewa\u017c zawsze jest wiele niuans\u00f3w, kt\u00f3re zale\u017c\u0105 od konkretnego zastosowania. Przy tym zdecydowanie polecam GitOps \u2014 znacznie u\u0142atwia \u017cycie i zwi\u0119ksza bezpiecze\u0144stwo.<\/p>\n

              Mam nadziej\u0119, \u017ce moje do\u015bwiadczenie w tej kwestii pomo\u017ce zdecydowa\u0107, kt\u00f3ra metoda najlepiej odpowiada Twojemu typowi deployment\u00f3w, a ja ch\u0119tnie poznam Twoje zdanie.<\/p>\n

              P.S. Notka od t\u0142umacza<\/h2>\n

              \nW minusach modelu pull pojawia si\u0119 punkt m\u00f3wi\u0105cy o trudno\u015bciach z umieszczaniem odrenderowanych manifest\u00f3w w Git, jednak nie ma minus\u00f3w, \u017ce pipeline CD w modelu pull dzia\u0142a oddzielnie od wdro\u017ce\u0144 i w zasadzie staje si\u0119 pipeline'em z kategorii Continuous Apply<\/i>. Dlatego b\u0119dzie potrzeba jeszcze wi\u0119cej wysi\u0142ku, aby zbiera\u0107 statusy ze wszystkich deployment\u00f3w i jako\u015b udost\u0119pnia\u0107 logi\/status, najlepiej powi\u0105zane z systemem CD.<\/p>\n

              W tym sensie model push pozwala na zapewnienie jakichkolwiek gwarancji w zakresie wdro\u017cenia, poniewa\u017c czas \u017cycia pipeline'a mo\u017cna ustawi\u0107 r\u00f3wnym czasowi \u017cycia wdro\u017cenia.<\/p>\n

              Wypr\u00f3bowali\u015bmy oba modele i doszli\u015bmy do tych samych wniosk\u00f3w co autor artyku\u0142u:<\/p>\n

                \n
              1. Model pull nadaje si\u0119 do organizacji aktualizacji komponent\u00f3w systemowych w du\u017cej liczbie klastr\u00f3w (patrz artyku\u0142 o addon-operatorze<\/a><\/noindex>).<\/li>\n
              2. Model push oparty na GitLab CI dobrze nadaje si\u0119 do wdra\u017cania aplikacji przy u\u017cyciu chart\u00f3w Helm. Przy tym wdro\u017cenie deployment\u00f3w w ramach pipeline'\u00f3w jest \u015bledzone za pomoc\u0105 narz\u0119dzia werf<\/a><\/noindex>. Swoj\u0105 drog\u0105, w kontek\u015bcie tego naszego projektu s\u0142yszeli\u015bmy ci\u0105g\u0142e \u201eGitOps\u201d, gdy omawiali\u015bmy bie\u017c\u0105ce problemy in\u017cynier\u00f3w DevOps przy naszym stoisku na KubeCon Europe \u201919.<\/li>\n<\/ol>\n

                <\/p>\n

                P.P.S. od t\u0142umacza<\/h2>\n

                \nPrzeczytaj tak\u017ce na naszym blogu:<\/p>\n