GitOps: тарту және итеру әдістерін салыстыру

Ескерту. аударма: Kubernetes қауымдастығында GitOps деп аталатын тренд айқын танымалдыққа ие болуда, біз өзіміз көргендей, келу KubeCon Europe 2019. Бұл термин салыстырмалы түрде жақында болған қапталған Weaveworks басшысы - Алексис Ричардсон - және операциялық мәселелерді шешу үшін әзірлеушілерге таныс құралдарды (ең алдымен Git, сондықтан атауы) пайдалануды білдіреді. Атап айтқанда, біз Git-те оның конфигурацияларын сақтау және кластерге өзгерістерді автоматты түрде шығару арқылы Kubernetes жұмысы туралы айтып отырмыз. Маттиас Джг осы мақалада осы шығарудың екі тәсілі туралы айтады.

Өткен жылы (шын мәнінде, бұл ресми түрде 2017 жылдың тамызында болды - шамамен аудар.) Kubernetes-те қолданбаларды орналастырудың жаңа тәсілі бар. Ол GitOps деп аталады және ол орналастыру нұсқалары Git репозиторийінің қауіпсіз ортасында бақыланады деген негізгі идеяға негізделген.

Бұл тәсілдің негізгі артықшылықтары келесідей::

1. Орналастыру нұсқасы және өзгерту тарихы. Бүкіл кластердің күйі Git репозиторийінде сақталады және орналастырулар тек тапсырмалар арқылы жаңартылады. Сонымен қатар, барлық өзгерістерді орындау тарихы арқылы бақылауға болады.
2. Таныс Git командалары арқылы кері қайтару... Жазық git reset орналастырулардағы өзгерістерді қалпына келтіруге мүмкіндік береді; бұрынғы күйлер әрқашан қол жетімді.
3. Дайын қол жеткізуді басқару. Әдетте, Git жүйесінде көптеген құпия деректер бар, сондықтан көптеген компаниялар оны қорғауға ерекше назар аударады. Сәйкесінше, бұл қорғау орналастырулармен операцияларға да қолданылады.
4. Орналастыруға арналған саясаттар. Көптеген Git жүйелері салалық саясаттарды қолдайды — мысалы, тек тарту сұраулары ғана басты жаңарта алады және өзгертулерді басқа топ мүшесі қарап шығып, қабылдауы керек. Қол жеткізуді басқару сияқты, бірдей саясаттар орналастыру жаңартуларына қолданылады.

Көріп отырғаныңыздай, GitOps әдісінің көптеген артықшылықтары бар. Соңғы бір жылда екі тәсіл ерекше танымалдылыққа ие болды. Біреуі итеруге негізделген, екіншісі тартуға негізделген. Оларды қарастырмас бұрын, алдымен әдеттегі Kubernetes орналастырулары қандай болатынын қарастырайық.

Орналастыру әдістері

Соңғы жылдары Kubernetes-те орналастырудың әртүрлі әдістері мен құралдары құрылды:

1. Түпнұсқа Kubernetes/Kustomize үлгілеріне негізделген. Бұл Kubernetes жүйесінде қолданбаларды орналастырудың ең оңай жолы. Әзірлеуші ​​негізгі YAML файлдарын жасайды және оларды қолданады. Бірдей үлгілерді үнемі қайта жазудан құтылу үшін Kustomize әзірленді (ол Kubernetes үлгілерін модульдерге айналдырады). Ескерту. аударма: Kustomize kubectl бағдарламасына біріктірілген Kubernetes 1.14 шығарылымы.
2. Штурвал диаграммалары. Шеңбер диаграммалары үлгіге негізделген тәсілге қарағанда икемді теңшеу опциялары бар қолданбаларды орналастыру үшін пайдаланылатын үлгілер жиынын, бастапқы контейнерлерін, қосалқы таспаларды және т.б. жасауға мүмкіндік береді. Бұл әдіс үлгілік YAML файлдарына негізделген. Helm оларды әртүрлі параметрлермен толтырады, содан кейін оларды кластерге орналастыратын және жаңартулар мен кері қайтаруға мүмкіндік беретін кластер құрамдас бөлігі болып табылатын Tiller-ге жібереді. Ең бастысы, Helm негізінен шаблондарға қажетті мәндерді енгізеді, содан кейін оларды дәстүрлі тәсілде жасалғандай қолданады. (бәрі қалай жұмыс істейтіні және оны қалай пайдалануға болатыны туралы толығырақ біздің мақалада оқыңыз Хельмнің мақаласы - шамамен. аудар.). Тапсырмалардың кең ауқымын қамтитын дайын Helm диаграммаларының кең таңдауы бар.
3. Балама құралдар. Көптеген балама құралдар бар. Олардың барлығына ортақ нәрсе - олар кейбір үлгі файлдарын Kubernetes оқылатын YAML файлдарына айналдырады, содан кейін оларды пайдаланады.

Біздің жұмысымызда біз үнемі маңызды құралдар үшін Helm диаграммаларын (өйткені оларда дайын көп нәрсе бар, бұл өмірді әлдеқайда жеңілдетеді) және жеке қолданбаларды орналастыру үшін «таза» Kubernetes YAML файлдарын пайдаланамыз.

Тарту және итеру

Жақында блог жазбаларымның бірінде мен құралды таныстырдым Weave Flux, бұл сізге Git репозиторийіне үлгілерді бекітуге және контейнерді әрбір тапсырудан немесе итеруден кейін орналастыруды жаңартуға мүмкіндік береді. Менің тәжірибем көрсеткендей, бұл құрал тарту тәсілін ілгерілетудегі негізгі құралдардың бірі болып табылады, сондықтан мен оған жиі сілтеме жасаймын. Егер сіз оны қалай пайдалану керектігі туралы көбірек білгіңіз келсе, мына жерде мақалаға сілтеме.

NB! GitOps қолданудың барлық артықшылықтары екі тәсіл үшін де бірдей болып қалады.

Тартуға негізделген тәсіл

Тарту тәсілі барлық өзгертулер кластер ішінен қолданылатынына негізделген. Кластердің ішінде Git және Docker Registry репозитарийлерімен байланыстырылған репозитарийлерді үнемі тексеретін оператор бар. Егер оларда қандай да бір өзгерістер орын алса, кластердің күйі ішкі түрде жаңартылады. Бұл процесс әдетте өте қауіпсіз болып саналады, өйткені ешқандай сыртқы клиент кластер әкімшісі құқықтарына қол жеткізе алмайды.

Артықшылықтары:

1. Ешбір сыртқы клиенттің кластерге өзгертулер енгізу құқығы жоқ; барлық жаңартулар ішінен шығарылады.
2. Кейбір құралдар сонымен қатар Helm диаграммасының жаңартуларын синхрондауға және оларды кластерге байланыстыруға мүмкіндік береді.
3. Docker тізілімін жаңа нұсқалар үшін сканерлеуге болады. Жаңа кескін қол жетімді болса, Git репозиторийі және орналастыру жаңа нұсқаға жаңартылады.
4. Тарту құралдарын әртүрлі Git репозиторийлері мен рұқсаттары бар әртүрлі аттар кеңістігіне таратуға болады. Осының арқасында көп пәтерлі модельді пайдалануға болады. Мысалы, А командасы А аттар кеңістігін, В тобы B аттар кеңістігін пайдалана алады және инфрақұрылым тобы жаһандық кеңістікті пайдалана алады.
5. Әдетте, құралдар өте жеңіл.
6. Оператор сияқты құралдармен біріктірілген Bitnami мөрленген құпиялары, құпияларды Git репозиторийінде шифрланған түрде сақтауға және кластер ішінде алуға болады.
7. Орналастыру кластер ішінде орын алатындықтан, CD құбырларына қосылым жоқ.

Минусы:

1. Helm диаграммаларынан орналастыру құпияларын басқару әдеттегіге қарағанда қиынырақ, өйткені олар алдымен, айталық, мөрленген құпиялар түрінде жасалуы керек, содан кейін ішкі оператор шифрын шешуі керек, содан кейін ғана олар тарту құралына қолжетімді болады. Содан кейін сіз Helm ішіндегі шығарылымды бұрыннан енгізілген құпиялардағы мәндермен іске қоса аласыз. Ең оңай жолы - орналастыру үшін пайдаланылатын барлық Helm мәндерімен құпияны жасау, оның шифрын ашу және оны Git-ке тапсыру.
2. Тарту тәсілін қолданғанда, сіз тарту құралдарына байланып қаласыз. Бұл кластерде орналастыру процесін теңшеу мүмкіндігін шектейді. Мысалы, Kustomize соңғы үлгілер Git-ке бекітілгенге дейін іске қосылуы керек болғандықтан қиын. Мен сіз дербес құралдарды пайдалана алмайсыз деп айтпаймын, бірақ оларды орналастыру процесіне біріктіру қиынырақ.

Басуға негізделген тәсіл

Басу тәсілінде сыртқы жүйе (негізінен CD құбырлары) Git репозиторийіне міндеттеме алғаннан кейін немесе алдыңғы CI конвейері сәтті болса, кластерге орналастыруларды іске қосады. Бұл тәсілде жүйе кластерге қол жеткізе алады.

Плюсы:

1. Қауіпсіздік Git репозиторийі және құрылыс құбыры арқылы анықталады.
2. Helm диаграммаларын қолдану оңайырақ және Helm плагиндерін қолдайды.
3. Құпияларды басқару оңай, себебі құпияларды құбыр желілерінде қолдануға болады және Git-те шифрланған түрде сақталуы мүмкін (пайдаланушының қалауына байланысты).
4. Белгілі бір құралмен байланыс жоқ, себебі кез келген түрін пайдалануға болады.
5. Контейнер нұсқасының жаңартуларын құрастыру құбыры арқылы бастауға болады.

Минусы:

1. Кластерге қатынасу деректері құрастыру жүйесінің ішінде.
2. Орналастыру контейнерлерін жаңарту тарту процесімен әлі де оңай.
3. CD жүйесіне қатты тәуелділік, өйткені бізге қажет құбырлар бастапқыда Gitlab Runners үшін жазылған болуы мүмкін, содан кейін команда Azure DevOps немесе Jenkins-ке көшуді шешеді... және құрылыс құбырларының көп санын көшіруге тура келеді.

Нәтижелер: итеру немесе тарту?

Әдеттегідей, әр әдістің оң және теріс жақтары бар. Кейбір тапсырмаларды біреуімен орындау оңай, екіншісімен қиынырақ. Алдымен мен орналастыруды қолмен жасадым, бірақ Weave Flux туралы бірнеше мақаланы көргеннен кейін мен барлық жобалар үшін GitOps процестерін енгізуді шештім. Негізгі үлгілер үшін бұл оңай болды, бірақ кейін мен Helm диаграммаларымен қиындықтарға тап болдым. Сол кезде Weave Flux тек Helm Chart Operator бағдарламасының қарапайым нұсқасын ұсынды, бірақ қазірдің өзінде құпияларды қолмен жасау және оларды қолдану қажеттілігіне байланысты кейбір тапсырмалар қиынырақ. Тарту тәсілі әлдеқайда қауіпсіз деп дауласуға болады, себебі кластердің тіркелгі деректері кластерден тыс қол жетімді емес, бұл оны әлдеқайда қауіпсіз етеді, бұл қосымша күш салуға тұрарлық.

Біраз ойланып отырып, бұл олай емес деген күтпеген қорытындыға келдім. Максималды қорғауды қажет ететін компоненттер туралы айтатын болсақ, бұл тізімге құпия сақтау, CI/CD жүйелері және Git репозиторийлері кіреді. Олардың ішіндегі ақпарат өте осал және барынша қорғауды қажет етеді. Оған қоса, егер біреу Git репозиторийіне кіріп, сол жерге кодты итермелей алса, олар қалағанын (тарту немесе итеру) орналастыра алады және кластердің жүйелеріне ене алады. Осылайша, қорғауды қажет ететін ең маңызды компоненттер кластердің тіркелгі деректері емес, Git репозиторийі және CI/CD жүйелері болып табылады. Жүйелердің осы түрлері үшін жақсы конфигурацияланған саясаттарыңыз бен қауіпсіздікті басқару элементтері болса және кластер тіркелгі деректері құпиялар ретінде тек құбырларға шығарылса, тарту тәсілінің қосымша қауіпсіздігі бастапқыда ойлағандай құнды болмауы мүмкін.

Сонымен, егер тарту тәсілі көп еңбекті қажет ететін болса және қауіпсіздік пайдасын қамтамасыз етпесе, тек қана түрткі әдісін қолдану қисынды емес пе? Бірақ біреу итермелеу тәсілінде сіз CD жүйесіне тым байланғансыз және болашақта көші-қонды жүзеге асыру оңайырақ болуы үшін мұны жасамағаныңыз дұрыс деп айтуы мүмкін.

Менің ойымша (әдеттегідей), белгілі бір жағдайға немесе комбинацияға ең қолайлысын пайдалану керек. Жеке мен екі тәсілді де қолданамын: негізінен өз қызметтерімізді қамтитын тартуға негізделген орналастырулар үшін Weave Flux және Helm және плагиндері бар push тәсілі, бұл Helm диаграммаларын кластерге қолдануды жеңілдетеді және құпияларды біркелкі жасауға мүмкіндік береді. Менің ойымша, барлық жағдайларға сәйкес келетін жалғыз шешім ешқашан болмайды, өйткені әрқашан көптеген нюанстар бар және олар нақты қолданбаға байланысты. Айтпақшы, мен GitOps ұсынамын - бұл өмірді айтарлықтай жеңілдетеді және қауіпсіздікті жақсартады.

Осы тақырып бойынша тәжірибем сізге орналастыру түріне қай әдіс қолайлырақ екенін анықтауға көмектеседі деп үміттенемін және мен сіздің пікіріңізді тыңдауға қуаныштымын.

PS Аудармашы ескертпесі

Тарту үлгісінің кемшілігі мынада: Git-ке көрсетілген манифесттерді қою қиын, бірақ тарту үлгісіндегі CD конвейері шығарылымнан бөлек өмір сүреді және шын мәнінде санат құбырына айналады. Үздіксіз қолдану. Сондықтан, барлық орналастырулардан олардың күйін жинау және қандай да бір түрде CD жүйесіне сілтеме жасай отырып, журналдарға/күйлерге қол жеткізуді қамтамасыз ету үшін одан да көп күш қажет болады.

Бұл мағынада итермелеу моделі кем дегенде шығарудың кейбір кепілдіктерін қамтамасыз етуге мүмкіндік береді, өйткені құбырдың қызмет ету мерзімін шығарудың қызмет ету мерзіміне теңестіруге болады.

Біз екі модельді де сынап көрдік және мақала авторымен бірдей қорытындыға келдік:

1. Тарту үлгісі бізге көптеген кластерлерде жүйе құрамдастарын жаңартуды ұйымдастыру үшін қолайлы (қараңыз. addon-оператор туралы мақала).
2. GitLab CI негізіндегі push моделі Helm диаграммалары арқылы қолданбаларды шығару үшін өте қолайлы. Сонымен қатар, құралдың көмегімен құбырлар ішіндегі орналастырулардың шығуы бақыланады верф. Айтпақшы, осы жобамыздың контекстінде біз KubeCon Europe'19 стендінде DevOps инженерлерінің өзекті мәселелерін талқылаған кезде тұрақты «GitOps» естідік.

Аудармашыдан PPS

Біздің блогта да оқыңыз:

• «Kubernetes кеңестері мен айлалары: кластерде жұмыс істейтін ресурстарды Helm 2 басқаруына тасымалдау«;
• «Kubernetes ресурстарын қадағалауға арналған кітапхана - kubedog-пен таныстыру«;
• «Kubernetes кеңейту және толықтыру (шолу және бейне есеп)«;
• «GitLab CI жүйесінде теңшелетін жұмыс үрдістерін жасауға арналған кеңестер«.

Сауалнамаға тек тіркелген пайдаланушылар қатыса алады. Кіру, өтінемін.

GitOps пайдаланасыз ба?

• Иә, тартыңыз

• Иә, итер

• Иә, тартыңыз + итеріңіз

• Иә, басқа нәрсе

• жоқ

30 пайдаланушы дауыс берді. 10 пайдаланушы қалыс қалды.

Ақпарат көзі: www.habr.com