Ескерту. аударма: Жақында жарияланғаннан кейін GitOps-те тарту және итеру әдістері туралы біз бұл модельге қызығушылық таныттық, бірақ бұл тақырып бойынша орыс тіліндегі басылымдар өте аз болды (Habré-де ешқайсысы жоқ). Сондықтан, сіздердің назарларыңызға тағы бір мақаланың аудармасын ұсынуға қуаныштымыз – бір жылға жуық уақыт бұрын болса да! — Weaveworks компаниясынан, оның басшысы «GitOps» терминін енгізді. Мәтін тәсілдің мәнін және қолданыстағылардан негізгі айырмашылықтарын түсіндіреді.
Бір жыл бұрын шығардық . Сол кезде біз Weaveworks тобының толығымен Kubernetes негізіндегі SaaS жүйесін қалай іске қосқанын және бұлтты жергілікті ортада орналастыру, басқару және бақылау үшін нұсқаулы ең жақсы тәжірибелер жинағын әзірлегенімен бөлістік.
Мақала танымал болып шықты. Басқа адамдар GitOps туралы айта бастады және жаңа құралдарды жариялай бастады , , , , және т.б. Біздің веб-сайтта пайда болды жарияланымдар және GitOps қолдану жағдайлары. Бірақ кейбір адамдарда әлі де сұрақтар бар. Модель дәстүрліден қалай ерекшеленеді? және үздіксіз жеткізу ()? Kubernetes пайдалану қажет пе?
Көп ұзамай біз жаңа сипаттама қажет екенін түсіндік, ол мыналарды ұсынады:
- Көптеген мысалдар мен әңгімелер;
- GitOps арнайы анықтамасы;
- Дәстүрлі үздіксіз жеткізумен салыстыру.
Бұл мақалада біз осы тақырыптардың барлығын қамтуға тырыстық. Ол GitOps жаңартылған кіріспесін және әзірлеуші мен CI/CD перспективасын ұсынады. Модельді жалпылауға болатынына қарамастан, біз бірінші кезекте Кубернетеске назар аударамыз.
GitOps-пен танысыңыз
Алиса елестетіңіз. Ол келісім-шарттардың қыр-сырын анықтауға тым бос емес адамдарға денсаулықты, автокөлікті, үйді және саяхатты сақтандыруды ұсынатын Family Insurance компаниясын басқарады. Оның бизнесі Элис банкте деректанушы болып жұмыс істеген кезде қосалқы жоба ретінде басталды. Бір күні ол деректерді тиімдірек талдау және сақтандыру пакеттерін тұжырымдау үшін жетілдірілген компьютерлік алгоритмдерді пайдалана алатынын түсінді. Инвесторлар жобаны қаржыландырды, қазір оның компаниясы жылына 20 миллион доллардан астам табыс әкеледі және қарқынды дамып келеді. Қазір мұнда 180 адам әртүрлі қызметте жұмыс істейді. Бұл веб-сайтты, дерекқорды әзірлейтін, жүргізетін және тұтынушылар базасын талдайтын технологиялық топты қамтиды. 60 адамнан тұратын команданы компанияның техникалық директоры Боб басқарады.
Бобтың командасы бұлтта өндірістік жүйелерді орналастырады. Олардың негізгі қолданбалары Google Cloud жүйесіндегі Kubernetes мүмкіндіктерін пайдалана отырып, GKE жүйесінде жұмыс істейді. Сонымен қатар, олар өз жұмыстарында әртүрлі деректер мен аналитикалық құралдарды пайдаланады.
Family Insurance контейнерлерді пайдалануды мақсат етпеді, бірақ Docker ынта-ықыласына ие болды. Көп ұзамай компания GKE жаңа мүмкіндіктерді сынау үшін кластерлерді орналастыруды оңай және оңай ететінін анықтады. Контейнер тізілімін ұйымдастыру үшін CI және Quay үшін Дженкинс қосылды, Дженкинс үшін жаңа контейнерлер мен конфигурацияларды GKE-ге итермелейтін сценарийлер жазылды.
Біраз уақыт өтті. Алиса мен Боб таңдаған тәсілінің өнімділігіне және оның бизнеске әсеріне көңілі қалды. Контейнерлерді енгізу өнімділікті ұжым күткендей жақсарта алмады. Кейде орналастырулар бұзылып, код өзгерістерінің кінәлі екені белгісіз болды. Сондай-ақ конфигурация өзгерістерін қадағалау қиын болды. Көбінесе жаңа кластерді құру және оған қосымшаларды жылжыту қажет болды, өйткені бұл жүйеде пайда болған тәртіпсіздікті жоюдың ең оңай жолы болды. Алиса қосымша дамыған сайын жағдай нашарлайды деп қорықты (соған қоса, машиналық оқытуға негізделген жаңа жоба дайындалуда). Боб жұмыстың көп бөлігін автоматтандырды және құбырдың неге әлі де тұрақсыз екенін, жақсы масштабталмағанын және мерзімді түрде қолмен араласуды қажет ететінін түсінбеді?
Содан кейін олар GitOps туралы білді. Бұл шешім оларға сенімді түрде алға жылжу үшін қажет болды.
Алиса мен Боб Git, DevOps және инфрақұрылым туралы кодтық жұмыс үрдісі ретінде жылдар бойы естіп келеді. GitOps-тың ерекшелігі - ол Kubernetes контекстінде осы идеяларды жүзеге асыру үшін ең жақсы тәжірибелер жиынтығын - түпкілікті және нормативті - әкеледі. Бұл тақырып , оның ішінде .
Family Insurance GitOps енгізу туралы шешім қабылдады. Қазір компанияда Kubernetes және комбайндармен үйлесімді автоматтандырылған жұмыс үлгісі бар жылдамдық бар тұрақтылықөйткені олар:
- команданың өнімділігі ешкімді есінен шығармай екі есе өсетінін анықтады;
- сценарийлерге қызмет көрсетуді тоқтатты. Оның орнына, олар енді жаңа мүмкіндіктерге назар аударып, инженерлік әдістерді жетілдіре алады - мысалы, канарларды шығаруды енгізу және тестілеуді жақсарту;
- біз орналастыру процесін ол сирек бұзылатындай жақсарттық;
- қолмен араласусыз ішінара сәтсіздіктерден кейін орналастыруды қалпына келтіру мүмкіндігіне ие болды;
- пайдаланылған сатып алынғаноЖеткізу жүйелеріне үлкен сенім. Элис пен Боб топты параллель жұмыс істейтін микросервис топтарына бөлуге болатынын анықтады;
- әр топтың күш-жігері арқылы жобаға күн сайын 30-50 өзгерту енгізе алады және жаңа әдіс-тәсілдерді қолдана алады;
- жобаға жаңа әзірлеушілерді тарту оңай, олар бірнеше сағат ішінде тарту сұрауларын пайдалана отырып, өндіріске жаңартуларды шығару мүмкіндігіне ие;
- SOC2 шеңберінде аудиттен оңай өту (қызмет провайдерлерінің деректерді қауіпсіз басқару талаптарына сәйкестігі үшін; толығырақ оқу, мысалы, - шамамен. аудар.).
Не болды?
GitOps екі нәрсе:
- Kubernetes үшін операциялық үлгі және жергілікті бұлт. Ол контейнерлік кластерлер мен қолданбаларды орналастыру, басқару және бақылау үшін ең жақсы тәжірибелер жинағын қамтамасыз етеді. Пішіндегі талғампаз анықтама от :
- Әзірлеушіге бағытталған қолданбаларды басқару ортасын құру жолы. Біз Git жұмыс процесін операцияларға да, әзірлеуге де қолданамыз. Бұл тек Git push туралы емес, CI/CD және UI/UX құралдарының бүкіл жинағын ұйымдастыру туралы екенін ескеріңіз.
Гит туралы бірнеше сөз
Нұсқаларды басқару жүйелерімен және Git негізіндегі жұмыс процесімен таныс болмасаңыз, олар туралы білуге кеңес береміз. Бұтақтармен жұмыс істеу және тарту сұраулары бастапқыда қара сиқыр сияқты көрінуі мүмкін, бірақ артықшылықтар күш салуға тұрарлық. Мұнда алдымен.
Кубернетес қалай жұмыс істейді
Біздің тарихымызда Элис пен Боб Кубернетеспен біраз уақыт жұмыс істегеннен кейін GitOps-ке жүгінді. Шынында да, GitOps Kubernetes-пен тығыз байланысты - бұл Kubernetes негізіндегі инфрақұрылым мен қосымшалардың операциялық үлгісі.
Kubernetes пайдаланушыларға не береді?
Міне, кейбір негізгі мүмкіндіктер:
- Кубернетес үлгісінде барлығын декларативті түрде сипаттауға болады.
- Kubernetes API сервері бұл мәлімдемені кіріс ретінде қабылдайды, содан кейін кластерді декларацияда сипатталған күйге келтіруге үнемі әрекет жасайды.
- Декларациялар әртүрлі жұмыс жүктемелерін — «қолданбаларды» сипаттау және басқару үшін жеткілікті.
- Нәтижесінде қолданбаға және кластерге өзгерістер мыналарға байланысты болады:
- контейнер кескіндеріндегі өзгерістер;
- декларативті спецификациядағы өзгерістер;
- ортадағы қателер - мысалы, контейнердің бұзылуы.
Кубернетестің үлкен конвергенция мүмкіндіктері
Әкімші конфигурацияға өзгерістер енгізген кезде, Kubernetes оркестрі күйі өзгерген кезде оларды кластерге қолданады. жаңа конфигурацияға жақындамайды. Бұл модель кез келген Kubernetes ресурсы үшін жұмыс істейді және пайдаланушы ресурс анықтамаларымен (CRDs) кеңейтіледі. Сондықтан, Kubernetes орналастырулары келесі тамаша қасиеттерге ие:
- Автоматтандыру: Kubernetes жаңартулары өзгерістерді әдемі және уақтылы қолдану процесін автоматтандыру механизмін қамтамасыз етеді.
- Конвергенция: Kubernetes сәтті болғанша жаңартулар әрекетін жалғастырады.
- Импотенттілік: Конвергенцияның қайталанатын қолданбалары бірдей нәтижеге әкеледі.
- Детерминизм: Ресурстар жеткілікті болғанда, жаңартылған кластердің күйі тек қалаған күйге байланысты.
GitOps қалай жұмыс істейді
GitOps қалай жұмыс істейтінін түсіндіру үшін біз Кубернетес туралы жеткілікті білдік.
Отбасылық сақтандырудың микросервис топтарына оралайық. Олар әдетте не істеуі керек? Төмендегі тізімге қараңыз (егер ондағы қандай да бір элементтер оғаш немесе бейтаныс болып көрінсе, сынауды тоқтатып, бізбен бірге болыңыз). Бұл Дженкинс негізіндегі жұмыс процестерінің мысалдары ғана. Басқа құралдармен жұмыс істегенде басқа да көптеген процестер бар.
Ең бастысы, біз әрбір жаңарту конфигурация файлдары мен Git репозиторийлеріндегі өзгерістермен аяқталатынын көреміз. Git-ке жасалған бұл өзгерістер «GitOps операторының» кластерді жаңартуына себеп болады:
1.Жұмыс процесі: "Дженкинс құрастыру – басты филиал«.
Тапсырмалар тізімі:
- Дженкинс тегтелген кескіндерді Quay-ге итереді;
- Дженкинс конфигурация және Helm диаграммаларын негізгі сақтау шелекіне итереді;
- Бұлттық функция конфигурация мен диаграммаларды басты сақтау шелегінен басты Git репозиторийіне көшіреді;
- GitOps операторы кластерді жаңартады.
2. Дженкинс құрастыру - шығару немесе түзету тармағы:
- Дженкинс белгіленбеген кескіндерді Quay-ге итереді;
- Дженкинс конфигурация және Helm диаграммаларын кезеңдік сақтау шелегіне итереді;
- Бұлт функциясы конфигурация мен диаграммаларды кезеңдік сақтау шелегінен кезеңдік Git репозиторийіне көшіреді;
- GitOps операторы кластерді жаңартады.
3. Дженкинс құрастыру - тармақты дамыту немесе ерекшелеу:
- Дженкинс белгіленбеген кескіндерді Quay-ге итереді;
- Дженкинс конфигурация және Helm диаграммаларын әзірлеу қоймасына итереді;
- Бұлттық функция конфигурация мен диаграммаларды әзірлеу қоймасынан әзірлеу Git репозиторийіне көшіреді;
- GitOps операторы кластерді жаңартады.
4. Жаңа клиент қосу:
- Менеджер немесе әкімші (LCM/ops) бастапқыда желілік жүктеме теңестірушілерін (NLBs) орналастыру және конфигурациялау үшін Gradle-ді шақырады;
- LCM/ops жаңартуларға орналастыруды дайындау үшін жаңа конфигурацияны тапсырады;
- GitOps операторы кластерді жаңартады.
GitOps қысқаша сипаттамасы
- Әрбір орта үшін декларативті спецификацияларды пайдалана отырып, бүкіл жүйенің қалаған күйін сипаттаңыз (біздің әңгімемізде Боб командасы Git жүйесінде бүкіл жүйе конфигурациясын анықтайды).
- Git репозиторийі бүкіл жүйенің қалаған күйіне қатысты ақиқаттың жалғыз көзі болып табылады.
- Қажетті күйге барлық өзгертулер Git-те тапсырмалар арқылы жасалады.
- Барлық қалаған кластер параметрлері кластердің өзінде де байқалады. Осылайша олардың сәйкес келетінін анықтауға болады (біріктіру, айырғысыз) немесе әртүрлі (айыру, алшақтау) қалаған және байқалатын күйлер.
- Қажетті және бақыланатын күйлер әртүрлі болса, онда:
- Мақсатты және байқалатын күйлерді ерте ме, кеш пе автоматты түрде синхрондайтын конвергенция механизмі бар. Кластердің ішінде Кубернетес мұны жасайды.
- Процесс бірден «өзгеріс жасалған» ескертуімен басталады.
- Кейбір конфигурацияланатын уақыт кезеңінен кейін күйлер әртүрлі болса, «айырма» ескертуін жіберуге болады.
- Осылайша, Git ішіндегі барлық міндеттемелер кластерге тексерілетін және идемпотентті жаңартуларды тудырады.
- Қайтару - бұл бұрын қалаған күйге жақындау.
- Конвергенция түпкілікті болып табылады. Оның пайда болуын көрсетеді:
- Белгілі бір уақыт аралығында ешқандай айырмашылық ескертулері жоқ.
- «біріктірілген» ескерту (мысалы, webhook, Git writeback оқиғасы).
Дивергенция дегеніміз не?
Тағы да қайталайық: барлық қалаған кластер сипаттары кластердің өзінде байқалуы керек.
Айырмашылықтың кейбір мысалдары:
- Git-тегі тармақтарды біріктіруге байланысты конфигурация файлындағы өзгеріс.
- GUI клиенті жасаған Git міндеттемесіне байланысты конфигурация файлындағы өзгеріс.
- Git-тегі PR арқасында қалаған күйге бірнеше өзгерістер, содан кейін контейнер кескінін құру және конфигурация өзгерістері.
- Қатеге байланысты кластердің күйінің өзгеруі, «жаман мінез-құлыққа» әкелетін ресурс қақтығысы немесе бастапқы күйден жай ғана кездейсоқ ауытқу.
Конвергенция механизмі қандай?
Бірнеше мысал:
- Контейнерлер мен кластерлер үшін конвергенция механизмін Kubernetes қамтамасыз етеді.
- Дәл осындай механизмді Kubernetes негізіндегі қолданбалар мен дизайндарды (Istio және Kubeflow сияқты) басқару үшін пайдалануға болады.
- Kubernetes, кескін репозиторийлері және Git арасындағы операциялық өзара әрекеттесуді басқару механизмі қамтамасыз етіледі бөлігі болып табылатын .
- Негізгі машиналар үшін конвергенция механизмі декларативті және автономды болуы керек. Мұны өз тәжірибемізден айта аламыз бұл анықтамаға ең жақын, бірақ бәрібір адам бақылауын қажет етеді. Бұл мағынада GitOps инфрақұрылым дәстүрін код ретінде кеңейтеді.
GitOps пайдалану үлгісін қамтамасыз ету үшін Git-ті Kubernetes-тің тамаша конвергенция қозғалтқышымен біріктіреді.
GitOps бізге мынаны айтуға мүмкіндік береді: Тек сипаттауға және бақылауға болатын жүйелерді ғана автоматтандыруға және басқаруға болады.
GitOps бүкіл бұлттық стекке арналған (мысалы, Terraform және т.б.)
GitOps тек Кубернетес емес. Біз бүкіл жүйенің декларативті түрде басқарылуын және конвергенцияны қолдануын қалаймыз. Бүкіл жүйе деп біз Kubernetes-пен жұмыс істейтін орталардың жиынтығын түсінеміз - мысалы, «дев кластері 1», «өндіріс» және т.б. Әрбір ортаға машиналар, кластерлер, қолданбалар, сондай-ақ деректерді, мониторингті қамтамасыз ететін сыртқы қызметтерге арналған интерфейстер кіреді. және т.б.
Бұл жағдайда жүктеу мәселесі үшін Terraform қаншалықты маңызды екенін байқаңыз. Kubernetes бір жерде орналастырылуы керек және Terraform көмегімен біз Kubernetes және қолданбаларды қолдайтын басқару қабатын жасау үшін бірдей GitOps жұмыс үрдістерін қолдануға болады дегенді білдіреді. Бұл пайдалы ең жақсы тәжірибе.
GitOps тұжырымдамаларын Kubernetes үстіңгі қабаттарына қолдануға ерекше назар аударылады. Қазіргі уақытта Istio, Helm, Ksonnet, OpenFaaS және Kubeflow, сондай-ақ, мысалы, Pulumi үшін GitOps типті шешімдер бар, олар жергілікті бұлтқа арналған қосымшаларды әзірлеу үшін қабат жасайды.
Kubernetes CI/CD: GitOps-ті басқа тәсілдермен салыстыру
Жоғарыда айтылғандай, GitOps екі нәрсе:
- Жоғарыда сипатталған Kubernetes және жергілікті бұлтқа арналған операциялық үлгі.
- Әзірлеушіге бағытталған қолданбаларды басқару ортасына жол.
Көптеген адамдар үшін GitOps ең алдымен Git push-қа негізделген жұмыс процесі болып табылады. Бізге де ол ұнайды. Бірақ бұл бәрі емес: енді CI/CD құбырларын қарастырайық.
GitOps Kubernetes үшін үздіксіз орналастыруды (CD) қосады
GitOps бөлек «орналастыруды басқару жүйелері» қажеттілігін болдырмайтын үздіксіз орналастыру механизмін ұсынады. Кубернетес барлық жұмысты сіз үшін жасайды.
- Қолданбаны жаңарту Git жүйесінде жаңартуды қажет етеді. Бұл қалаған күйге транзакциялық жаңарту. Содан кейін "орналастыру" жаңартылған сипаттамаға негізделген Kubernetes арқылы кластер ішінде орындалады.
- Kubernetes жұмысының сипатына байланысты бұл жаңартулар конвергентті болып табылады. Бұл барлық жаңартулар атомдық болып табылатын үздіксіз орналастыру механизмін қамтамасыз етеді.
- Ескертпе: Git және Kubernetes біріктіретін GitOps операторын ұсынады және кластердің қажетті және ағымдағы күйін сәйкестендіру арқылы CD-ді орындауға мүмкіндік береді.
kubectl және сценарийлерсіз
Кластерді жаңарту үшін Kubectl қолданбауыңыз керек және әсіресе kubectl пәрмендерін топтау үшін сценарийлерді пайдаланудан аулақ болуыңыз керек. Оның орнына, GitOps құбырымен пайдаланушы Git арқылы Kubernetes кластерін жаңарта алады.
Артықшылықтары мыналарды қамтиды:
- Дұрыс. Жаңартулар тобын қолдануға, біріктіруге және ақырында растауға болады, бұл бізді атомды орналастыру мақсатына жақындатады. Керісінше, сценарийлерді пайдалану конвергенцияға ешқандай кепілдік бермейді (төменде бұл туралы толығырақ).
- Қауіпсіздік. Келси Хайтауэр: «Кубернетес кластеріне кіруді автоматтандыру құралдары мен оны жөндеуге немесе жөндеуге жауапты әкімшілерге шектеңіз.» да қараңыз қауіпсіздік және техникалық шарттарға сәйкестігі туралы, сондай-ақ абайсызда жазылған Дженкинс сценарийінен тіркелгі деректерін ұрлау арқылы.
- Пайдаланушы тәжірибесі. Kubectl өте күрделі Kubernetes нысан моделінің механикасын ашады. Ең дұрысы, пайдаланушылар абстракцияның жоғары деңгейінде жүйемен өзара әрекеттесуі керек. Мұнда мен Келсиге тағы да сілтеме жасаймын және көруге кеңес беремін .
CI және CD арасындағы айырмашылық
GitOps бар CI/CD үлгілерін жақсартады.
Заманауи CI сервері - оркестрлеу құралы. Атап айтқанда, бұл CI құбырларын ұйымдастыруға арналған құрал. Оларға құрастыру, сынау, магистральға біріктіру және т.б. кіреді. CI серверлері күрделі көп сатылы құбырларды басқаруды автоматтандырады. Кластерге өзгерістер енгізу үшін Kubernetes жаңартуларының жинағын сценарий жазу және оны құбырдың бөлігі ретінде іске қосу жалпы азғыру болып табылады. Шынында да, мұны көптеген сарапшылар жасайды. Дегенмен, бұл оңтайлы емес, сондықтан да осында.
Жаңартуларды магистральға жіберу үшін CI пайдаланылуы керек, ал Кубернетес кластері CD дискісін іштей басқару үшін сол жаңартулардың негізінде өзін өзгертуі керек. Біз оны атаймыз , CI push үлгісінен айырмашылығы. CD бөлігі болып табылады орындау уақытының оркестрі.
Неліктен CI серверлері Kubernetes-тегі тікелей жаңартулар арқылы ықшам дискілерді жасамауы керек
CI тапсырмаларының жинағы ретінде Kubernetes бағдарламасына тікелей жаңартуларды реттеу үшін CI серверін пайдаланбаңыз. Бұл біз айтып отырған анти-үлгі сіздің блогыңызда.
Алиса мен Бобқа оралайық.
Олар қандай қиындықтарға тап болды? Bob's CI сервері өзгерістерді кластерге қолданады, бірақ ол процесте бұзылса, Боб кластердің қандай күйде екенін (немесе болуы керек) немесе оны қалай түзету керектігін білмейді. Сәтті болған жағдайда да солай.
Бобтың командасы жаңа кескінді құрастырды, содан кейін кескінді орналастыру үшін (барлығы CI құбырынан) орналастыруларын түзетеді делік.
Егер кескін қалыпты түрде құрастырылса, бірақ құбыр сәтсіз болса, команда мынаны анықтауы керек:
- Жаңарту шықты ма?
- Біз жаңа құрылысты іске қосамыз ба? Бұл қажетсіз жанама әсерлерге әкеледі - бірдей өзгермейтін кескіннің екі құрылымын алу мүмкіндігі бар ма?
- Құрылымды іске қоспас бұрын келесі жаңартуды күтуіміз керек пе?
- Нақты не дұрыс болмады? Қандай қадамдарды қайталау қажет (және қайсысын қайталау қауіпсіз)?
Git негізіндегі жұмыс процесін орнату Боб командасының бұл мәселелерге тап болмайтынына кепілдік бермейді. Олар әлі де commit push, тег немесе басқа параметрмен қателесуі мүмкін; дегенмен, бұл тәсіл әлі де айқын «бәрі немесе ештеңе» тәсіліне әлдеқайда жақын.
Қорытындылай келе, CI серверлері CD-мен жұмыс істемеуі керек:
- Жаңарту сценарийлері әрқашан детерминистік бола бермейді; Оларда қателесу оңай.
- CI серверлері декларативті кластер үлгісіне біріктірілмейді.
- Импотенттілікке кепілдік беру қиын. Пайдаланушылар жүйенің терең семантикасын түсінуі керек.
- Ішінара сәтсіздікті қалпына келтіру қиынырақ.
Helm туралы ескертпе: Helm қолданбасын пайдаланғыңыз келсе, оны GitOps операторымен біріктіруді ұсынамыз, мысалы: . Бұл конвергенцияны қамтамасыз етуге көмектеседі. Хельмнің өзі детерминистік те, атомдық та емес.
GitOps - Kubernetes үшін үздіксіз жеткізуді жүзеге асырудың ең жақсы тәсілі
Алиса мен Бобтың командасы GitOps-ті енгізеді және бағдарламалық өнімдермен жұмыс істеу, жоғары өнімділік пен тұрақтылықты сақтау әлдеқайда оңай болғанын анықтайды. Осы мақаланы олардың жаңа тәсілі қандай болатынын көрсететін иллюстрациямен аяқтайық. Біз негізінен қолданбалар мен қызметтер туралы айтып жатқанымызды есте сақтаңыз, бірақ GitOps бүкіл платформаны басқару үшін пайдаланылуы мүмкін.
Kubernetes үшін операциялық үлгі
Келесі диаграмманы қараңыз. Ол Git және контейнерлік кескін репозиторийін екі реттелген өмірлік цикл үшін ортақ ресурстар ретінде ұсынады:
- Git жүйесіне файлдарды оқитын және жазатын және контейнер кескіндерінің репозиторийін жаңарта алатын үздіксіз біріктіру құбыры.
- Орналастыруды басқару және бақылау мүмкіндігімен біріктіретін Runtime GitOps конвейері. Ол Git-ке файлдарды оқиды және жазады және контейнерлік кескіндерді жүктей алады.
Негізгі қорытындылар қандай?
- Мазасыздықтарды бөлу: Екі конвейер тек Git немесе кескін репозиторийін жаңарту арқылы байланыса алатынын ескеріңіз. Басқаша айтқанда, CI және орындау ортасы арасында брандмауэр бар. Біз оны «өзгермейтін брандмауэр» деп атаймыз. (өзгермейтін брандмауэр), өйткені барлық репозиторий жаңартулары жаңа нұсқаларды жасайды. Осы тақырып бойынша қосымша ақпарат алу үшін 72-87 слайдтарды қараңыз .
- Сіз кез келген CI және Git серверін пайдалана аласыз: GitOps кез келген компонентпен жұмыс істейді. Таңдаулы CI және Git серверлерін, кескін репозиторийлерін және сынақ жинақтарын пайдалануды жалғастыра аласыз. Нарықтағы барлық дерлік үздіксіз жеткізу құралдары өздерінің жеке CI/Git серверін немесе кескін репозиторийін қажет етеді. Бұл жергілікті бұлтты дамытуда шектеуші фактор болуы мүмкін. GitOps көмегімен сіз таныс құралдарды пайдалана аласыз.
- Оқиғалар интеграция құралы ретінде: Git-тегі деректер жаңартылған бойда Weave Flux (немесе Weave Cloud операторы) орындалу уақытын хабарлайды. Kubernetes өзгерту жиынын қабылдаған сайын Git жаңартылады. Бұл төменде көрсетілгендей GitOps үшін жұмыс үрдістерін ұйымдастыруға арналған қарапайым интеграция үлгісін береді.
қорытынды
GitOps кез келген заманауи CI/CD құралы талап ететін күшті жаңарту кепілдіктерін қамтамасыз етеді:
- автоматтандыру;
- конвергенция;
- импотенттілік;
- детерминизм.
Бұл маңызды, себебі ол бұлтты жергілікті әзірлеушілер үшін операциялық үлгіні ұсынады.
- Жүйені басқаруға және бақылауға арналған дәстүрлі құралдар runbook ішінде жұмыс істейтін операциялық топтармен байланысты (кәдімгі процедуралар мен операциялардың жиынтығы – шамамен аудар.), арнайы орналастыруға байланысты.
- Бұлтты жергілікті басқаруда бақылау құралдары әзірлеу тобының жылдам жауап беруі үшін орналастыру нәтижелерін өлшеудің ең жақсы тәсілі болып табылады.
Әр түрлі бұлттарға шашыраған көптеген кластерлерді және жеке топтары мен орналастыру жоспарлары бар көптеген қызметтерді елестетіп көріңіз. GitOps осы молшылықты басқаруға арналған масштабты инвариантты модельді ұсынады.
Аудармашыдан PS
Біздің блогта да оқыңыз:
- ««;
- ««;
- ««.
Сауалнамаға тек тіркелген пайдаланушылар қатыса алады. , өтінемін.
Сіз GitOps туралы осы екі аударма Хабреде пайда болғанға дейін білесіз бе?
-
Иә, мен бәрін білдім
-
Тек үстірт
-
жоқ
35 пайдаланушы дауыс берді. 10 пайдаланушы қалыс қалды.
Ақпарат көзі: www.habr.com