werf - біздің Kubernetes-тегі CI/CD құралы (шолу және бейне есеп)

27 мамырда фестиваль аясында өткен DevOpsConf 2019 конференциясының басты залында RIT++ 2019, «Үздіксіз жеткізу» бөлімінің бөлігі ретінде «werf - Kubernetes-тегі CI/CD үшін біздің құралымыз» есеп берілді. Солар туралы айтады Kubernetes-ке орналастыру кезінде кез келген адам кездесетін мәселелер мен қиындықтар, сондай-ақ бірден байқалмауы мүмкін нюанстар туралы. Ықтимал шешімдерді талдай отырып, біз бұл ашық бастапқы құралда қалай жүзеге асырылатынын көрсетеміз верф.

Тұсаукесерден бері біздің утилитамыз (бұрын dapp ретінде белгілі) тарихи кезеңге жетті. GitHub сайтындағы 1000 жұлдыз — оның өсіп келе жатқан пайдаланушылар қауымдастығы көптеген DevOps инженерлерінің өмірін жеңілдетеді деп үміттенеміз.

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

Кубернетеске кодты жеткізу

Әңгіме енді werf туралы емес, Kubernetes-тегі CI/CD туралы болады, бұл біздің бағдарламалық жасақтаманың Docker контейнерлеріне оралғанын білдіреді. (Мен бұл туралы айттым 2016 жылғы есеп), ал K8s оны өндірісте іске қосу үшін пайдаланылады (бұл туралы толығырақ 2017 жыл).

Кубернетесте жеткізу қалай көрінеді?

• Коды және оны құру нұсқаулары бар Git репозиторийі бар. Қолданба Docker кескініне салынған және Docker Registry-де жарияланған.
• Сол репозиторийде қолданбаны орналастыру және іске қосу туралы нұсқаулар да бар. Орналастыру кезеңінде бұл нұсқаулар Кубернетеске жіберіледі, ол тізілімнен қажетті кескінді алады және оны іске қосады.
• Сонымен қатар, әдетте сынақтар бар. Олардың кейбіреулерін суретті жариялау кезінде жасауға болады. Сондай-ақ (сол нұсқауларды орындай отырып) қолданбаның көшірмесін (бөлек K8s аттар кеңістігінде немесе бөлек кластерде) орналастыруға және сол жерде сынақтарды орындауға болады.
• Соңында, сізге Git-тен оқиғаларды қабылдайтын (немесе түймені басу) және барлық белгіленген кезеңдерді шақыратын CI жүйесі қажет: құрастыру, жариялау, орналастыру, сынау.

Мұнда бірнеше маңызды ескертулер бар:

1. Өйткені бізде өзгермейтін инфрақұрылым бар (өзгермейтін инфрақұрылым), барлық кезеңдерде қолданылатын қолданба кескіні (қойылым, өндіру және т.б.), біреу болуы керек. Мен бұл туралы толығырақ және мысалдармен айттым. осында.
2. Өйткені біз инфрақұрылымды кодтық тәсіл ретінде ұстанамыз (IaC), қолданбаның коды, оны құрастыру және іске қосу нұсқаулары болуы керек дәл бір репозиторийде. Бұл туралы қосымша ақпаратты қараңыз бірдей есеп.
3. Жеткізу тізбегі (жеткізу) біз оны әдетте былай көреміз: қолданба құрастырылды, сыналды, шығарылды (шығару кезеңі) және бұл - жеткізу орын алды. Бірақ шын мәнінде, пайдаланушы сіз шығарған нәрсені алады, емес содан кейін сіз оны өндіріске жеткізген кезде және ол жерге бара алған кезде және бұл өндіріс жұмыс істеді. Сондықтан жеткізу тізбегі аяқталады деп ойлаймын операциялық кезеңде ғана (жүгіру), немесе дәлірек айтқанда, код өндірістен жойылған кезде де (оны жаңасымен ауыстыру).

Кубернетестегі жоғарыда келтірілген жеткізу схемасына оралайық: оны біз ғана емес, сонымен бірге осы мәселемен айналысқандардың барлығы ойлап тапты. Шын мәнінде, бұл үлгі қазір GitOps деп аталады (термин және оның астарында жатқан идеялар туралы толығырақ оқуға болады осында). Схеманың кезеңдерін қарастырайық.

Құру кезеңі

2019 жылы Docker кескіндерін құру туралы сөйлесуге болатын сияқты, бұл кезде барлығы Dockerfiles жазуды және іске қосуды біледі. docker build?.. Міне, мен назар аударғым келетін нюанстар:

1. Сурет салмағы маңызды, сондықтан пайдаланыңыз көп сатылысуретте операцияға шынымен қажет қолданбаны ғана қалдыру.
2. Қабаттар саны тізбектерін біріктіру арқылы азайту керек RUN-мағынасына қарай командалар.
3. Дегенмен, бұл проблемаларды қосады жөндеу, себебі жинақ бұзылғанда, ақаулықты тудырған тізбектен дұрыс пәрменді табу керек.
4. Құрастыру жылдамдығы маңызды, өйткені біз өзгерістерді жылдам енгізіп, нәтижелерді көргіміз келеді. Мысалы, қолданбаны құрастырған сайын тіл кітапханаларындағы тәуелділіктерді қайта құрғыңыз келмейді.
5. Көбінесе сізге қажет бір Git репозиторийінен көптеген суреттер, оны Dockerfiles жиыны (немесе бір файлдағы аталған кезеңдер) және олардың ретті құрастыруымен Bash сценарийі арқылы шешуге болады.

Бұл әркім бетпе-бет келетін айсбергтің бір ұшы ғана еді. Бірақ басқа да проблемалар бар, атап айтқанда:

1. Жиі құрастыру кезеңінде бізге бір нәрсе қажет монтаждау (мысалы, үшінші тарап каталогындағы apt сияқты пәрмен нәтижесін кэштеу).
2. Біз қалаймыз Қажет қабықшада жазудың орнына.
3. Біз қалаймыз Dockerсіз құрастыру (бізде контейнерлерді іске қоса алатын Kubernetes кластері болған кезде, бізге бұл үшін барлығын конфигурациялау қажет қосымша виртуалды машина не үшін қажет?).
4. Параллель құрастыру, оны әртүрлі тәсілдермен түсінуге болады: Dockerfile-тен әртүрлі пәрмендер (егер көп сатылы пайдаланылса), бір репозиторийдің бірнеше тапсырмалары, бірнеше Докерфайлдар.
5. Бөлінген жинақ: Біз «эфемерлік» нәрселерді түйіршіктерге жинағымыз келеді, өйткені олардың кэш жоғалады, яғни оны бөлек жерде сақтау керек.
6. Ақыры тілектердің шыңын атадым автоматтық: Репозиторийге өтіп, қандай да бір пәрменді теріп, қалай және нені дұрыс істеу керектігін түсінетін дайын кескінді алу өте жақсы болар еді. Дегенмен, мен барлық нюанстарды осылай болжауға болатынына сенімді емеспін.

Міне, жобалар:

• moby/buildkit — Docker Inc конструкторы (қазірдің өзінде Docker-тың ағымдағы нұсқаларына біріктірілген), ол барлық осы мәселелерді шешуге тырысады;
• канико — Google компаниясынан Dockerсіз құруға мүмкіндік беретін құрылысшы;
• Buildpacks.io — CNCF-тің автоматты сиқырды және, атап айтқанда, қабаттар үшін ребазасы бар қызықты шешімді жасауға әрекеті;
• және басқа да көптеген утилиталар, мысалы бұйлда, genuinetools/img...

...және олардың GitHub-та қанша жұлдызы бар екенін қараңыз. Яғни, бір жағынан, docker build бар және бірдеңе істей алады, бірақ шын мәнінде мәселе толық шешілген жоқ - соның дәлелі - балама коллекторлардың қатар дамуы, олардың әрқайсысы есептердің кейбір бөлігін шешеді.

Верфте құрастыру

Сонымен біз келдік верф (бұрын әйгілі дап сияқты) — Біз көп жылдар бойы жасап келе жатқан Flant компаниясының ашық бастапқы коды. Мұның бәрі 5 жыл бұрын Dockerfiles құрастыруын оңтайландыратын Bash сценарийлерінен басталды және соңғы 3 жылда толыққанды әзірлеу жеке Git репозиторийі бар бір жоба аясында жүзеге асырылды. (алдымен Ruby-де, содан кейін қайта жазылған Go және бір уақытта атауы өзгертілді). Верфте қандай құрастыру мәселелері шешіледі?

Көк түспен боялған мәселелер қазірдің өзінде орындалды, параллель құрастыру бір хост ішінде жасалды, ал сары түспен белгіленген мәселелерді жаздың соңына дейін аяқтау жоспарлануда.

Тізілімде жариялау кезеңі (жариялау)

Біз телефон шалдық docker push... - тізілімге суретті жүктеп салуда не қиын болуы мүмкін? Содан кейін сұрақ туындайды: «Суретке қандай тег қою керек?» Ол бізде бар себеппен туындайды Gitflow (немесе басқа Git стратегиясы) және Kubernetes және өнеркәсіп Кубернетесте болып жатқан нәрсе Git-те болған оқиғадан кейін болуын қамтамасыз етуге тырысады. Өйткені, Гит біздің шындықтың жалғыз көзі.

Мұның несі қиын? Қайта шығару мүмкіндігін қамтамасыз ету: табиғаты өзгермейтін Git-тегі міндеттемеден (өзгермейтін), бірдей сақталуы керек Docker кескініне.

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

Белгілеу стратегиялары

Біріншісі қарапайым git тегі. Бізде сурет тегтелген тізілім бар 1.0. Kubernetes-те бұл сурет жүктелетін сахна мен қойылым бар. Git-те біз міндеттеме жасаймыз және бір сәтте біз белгілейміз 2.0. Біз оны репозиторийдің нұсқауларына сәйкес жинап, тегпен тізілімге орналастырамыз 2.0. Біз оны сахнаға, егер бәрі жақсы болса, өндіріске шығарамыз.

Бұл тәсілдің мәселесі мынада, біз алдымен тегті қойып, содан кейін ғана оны сынап, шығардық. Неліктен? Біріншіден, бұл жай ғана қисынсыз: біз әлі сынамаған бағдарламалық жасақтама нұсқасын шығарып жатырмыз (басқаша істей алмаймыз, өйткені тексеру үшін тег қою керек). Екіншіден, бұл жол Gitflow-пен үйлесімді емес.

Екінші нұсқа - git commit + тег. Негізгі тармақта тег бар 1.0; ол үшін тізілімде - өндіріске орналастырылған кескін. Бұған қоса, Kubernetes кластерінде алдын ала қарау және қою контурлары бар. Әрі қарай біз Gitflow: әзірлеуге арналған негізгі тармақта (develop) біз жаңа мүмкіндіктер жасаймыз, нәтижесінде идентификатормен міндеттеме жасалады #c1. Біз оны жинаймыз және осы идентификаторды пайдаланып тізілімде жариялаймыз (#c1). Сол идентификатор арқылы біз алдын ала қарауға шығарамыз. Біз міндеттемелермен де солай істейміз #c2 и #c3.

Мүмкіндіктер жеткілікті екенін түсінген кезде біз бәрін тұрақтандыруға кірісеміз. Git-те филиал жасаңыз release_1.1 (негізінде #c3 -дан develop). Бұл шығарылымды жинаудың қажеті жоқ, себебі... бұл алдыңғы қадамда жасалды. Сондықтан біз оны жай ғана қойылымға шығара аламыз. Біз қателерді түзетеміз #c4 және сол сияқты сахнаға шығару. Сонымен бірге, дамыту жұмыстары жүргізілуде develop, өзгерістер кезеңді түрде қайдан алынады release_1.1. Бір сәтте біз құрастырылған және қойылымға жүктелген міндеттеме аламыз, біз оған ризамыз (#c25).

Содан кейін біз босату тармағын (жылдам алға) біріктіреміз (release_1.1) шеберде. Біз бұл міндеттемеге жаңа нұсқасы бар тег қойдық (1.1). Бірақ бұл сурет тізілімде жинақталған, сондықтан оны қайтадан жинамас үшін біз бар суретке екінші тегті қосамыз (қазір оның тізілімде тегтері бар. #c25 и 1.1). Осыдан кейін біз оны өндіріске шығарамыз.

Қойылымға бір ғана сурет жүктелетін кемшілік бар (#c25), ал өндірісте ол басқаша (1.1), бірақ біз «физикалық» бұл тізілімдегі бірдей кескін екенін білеміз.

Нақты кемшілігі - біріктіру міндеттемелерін қолдаудың жоқтығы, алға қарай жылдам әрекет ету керек.

Біз ары қарай жүріп, трюк жасай аламыз... Қарапайым Dockerfile мысалын қарастырайық:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

Одан келесі принцип бойынша файл құрастырайық:

• SHA256 пайдаланылған кескіндердің идентификаторларынан (ruby:2.3 и nginx:alpine) олардың мазмұнының бақылау сомасы болып табылады;
• барлық командалар (RUN, CMD және т.б.);
• Қосылған файлдардан SHA256.

... және осындай файлдан бақылау сомасын (қайтадан SHA256) алыңыз. Бұл қол қою Docker кескінінің мазмұнын анықтайтын барлық нәрсе.

Диаграммаға қайта оралайық және міндеттеменің орнына біз осындай қолтаңбаларды қолданамыз, яғни. суреттерді қолтаңбаларымен белгілеңіз.

Енді, мысалы, шығарылымнан негізгіге өзгертулерді біріктіру қажет болғанда, біз нақты біріктіру міндеттемесін орындай аламыз: оның идентификаторы басқа, бірақ бірдей қолтаңбасы болады. Сол идентификатор арқылы біз кескінді өндіріске шығарамыз.

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

werf ішінде тегтеу

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

werf Git репозиторийі құрастырудың әртүрлі кезеңдерін сипаттайтын құрастыруға қатысты нұсқауларды сақтайды (орнату алдында, орнату, орнату алдында, орнату). Біз бірінші кезеңнің суретін алғашқы қадамдардың бақылау сомасы ретінде анықталған қолтаңбамен жинаймыз. Содан кейін бастапқы кодты қосамыз, жаңа сахналық кескін үшін біз оның бақылау сомасын есептейміз... Бұл операциялар барлық кезеңдер үшін қайталанады, нәтижесінде біз сахналық кескіндер жинағын аламыз. Содан кейін біз оның шығу тегі туралы метадеректерді қамтитын соңғы кескінді жасаймыз. Және біз бұл суретті әртүрлі тәсілдермен белгілейміз (толығырақ кейінірек).

Осыдан кейін тек қолданба коды өзгертілген жаңа міндеттеме пайда болды делік. Не болады? Кодты өзгерту үшін патч жасалады және жаңа сахналық кескін дайындалады. Оның қолтаңбасы ескі сахналық кескін мен жаңа патчтың бақылау сомасы ретінде анықталады. Бұл кескіннен жаңа соңғы кескін қалыптасады. Басқа кезеңдердегі өзгерістермен ұқсас мінез-құлық пайда болады.

Осылайша, сахналық кескіндер таратылған түрде сақталуы мүмкін кэш болып табылады және одан жасалған кескіндер Docker тізіліміне жүктеледі.

Реестрді тазалау

Біз жойылған тегтерден кейін ілулі қалған қабаттарды жою туралы айтып отырған жоқпыз - бұл Docker Registry-дің стандартты мүмкіндігі. Біз көптеген Docker тегтері жиналатын жағдай туралы айтып отырмыз және олардың кейбіреулері бізге енді қажет емес екенін түсінеміз, бірақ олар бос орын алады (және/немесе біз ол үшін төлейміз).

Тазалау стратегиялары қандай?

1. Сіз ештеңе істей алмайсыз тазаламаңыз. Кейде тегтердің үлкен шиеленісін шешкеннен гөрі қосымша орын үшін аздап төлеу оңайырақ. Бірақ бұл белгілі бір нүктеге дейін ғана жұмыс істейді.
2. Толық қалпына келтіру. Егер сіз барлық кескіндерді жойсаңыз және CI жүйесіндегі ағымдағыларды ғана қайта жасасаңыз, мәселе туындауы мүмкін. Контейнер өндірісте қайта іске қосылса, ол үшін жаңа сурет жүктеледі - оны әлі ешкім сынамаған. Бұл өзгермейтін инфрақұрылым идеясын жояды.
3. Көк-жасыл. Бір тізілім толып кете бастады - біз суреттерді екіншісіне жүктейміз. Алдыңғы әдістегідей мәселе: толып кете бастаған тізілімді қай кезде тазалауға болады?
4. Уақыт өте келе. 1 айдан асқан барлық кескіндерді жою қажет пе? Бірақ бір ай бойы жаңартылмаған қызмет міндетті түрде болады...
5. Қолмен жоюға болатын нәрсені анықтаңыз.

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

Неге келдік верф? Біз жинаймыз:

1. Git басшысы: барлық тегтер, барлық тармақтар - суреттерде Git-те белгіленген барлық нәрсе қажет деп есептейміз (ал болмаса, оны Git-тің өзінде жоюымыз керек);
2. қазіргі уақытта Кубернетеске айдалатын барлық бөтелкелер;
3. ескі ReplicaSets (жақында шығарылған) және біз Helm шығарылымдарын сканерлеуді және сол жерде соңғы кескіндерді таңдауды жоспарлап отырмыз.

... және осы жиынтықтан ақ тізім жасаңыз - біз жоймайтын кескіндер тізімін жасаңыз. Біз қалғандарының бәрін тазалаймыз, содан кейін жетім сахналық суреттерді тауып, оларды да жоямыз.

Орналастыру кезеңі

Сенімді декларативтілік

Орналастыру кезінде назар аударғым келетін бірінші мәселе - бұл декларациялық түрде жарияланған жаңартылған ресурс конфигурациясын шығару. Kubernetes ресурстарын сипаттайтын түпнұсқа YAML құжаты әрқашан кластерде нақты іске қосылған нәтижеден өте ерекшеленеді. Өйткені Кубернетес конфигурацияға қосады:

1. идентификаторлар;
2. қызмет туралы ақпарат;
3. көптеген әдепкі мәндер;
4. ағымдағы күйі бар бөлім;
5. қабылдау веб-хук бөлігі ретінде енгізілген өзгерістер;
6. әртүрлі контроллерлердің (және жоспарлаушының) жұмысының нәтижесі.

Сондықтан, жаңа ресурс конфигурациясы пайда болғанда (жаңа), біз онымен ағымдағы, «тірі» конфигурацияны алып, қайта жаза алмаймыз (тірі). Мұны істеу үшін біз салыстыруымыз керек жаңа соңғы қолданылған конфигурациямен (соңғы қолданылған) және айналдырыңыз тірі патч алды.

Бұл тәсіл деп аталады 2 жақты біріктіру. Ол, мысалы, Helm тілінде қолданылады.

Сондай-ақ бар 3 жақты біріктіру, ол мынамен ерекшеленеді:

• салыстыру соңғы қолданылған и жаңа, біз не жойылғанын қарастырамыз;
• салыстыру жаңа и тірі, не қосылғанын немесе өзгертілгенін қараймыз;
• жинақталған патч қолданылады тірі.

Біз Helm көмегімен 1000+ қолданбаларды орналастырамыз, сондықтан біз екі жақты біріктіру арқылы өмір сүреміз. Дегенмен, Хельмге қалыпты жұмыс істеуге көмектесетін патчтарымызбен шешкен бірқатар мәселелер бар.

Нақты шығару күйі

Біздің CI жүйесі келесі оқиғаға негізделген Kubernetes үшін жаңа конфигурацияны жасағаннан кейін оны пайдалану үшін жібереді. (қолдану) кластерге - Helm немесе көмегімен kubectl apply. Содан кейін, Kubernetes API жүйесі CI жүйесіне және оның пайдаланушысына мақұлдайтын жауап беретін бұрыннан сипатталған N-жолды біріктіру орын алады.

Дегенмен, үлкен мәселе бар: ақыр соңында сәтті қолдану сәтті шығу дегенді білдірмейді. Егер Кубернетес қандай өзгерістерді қолдану керектігін түсінсе және оны қолданса, біз нәтиженің қандай болатынын әлі білмейміз. Мысалы, фронтондағы подкасттарды жаңарту және қайта іске қосу сәтті болуы мүмкін, бірақ бэкэнд емес, және біз іске қосылған қолданба кескіндерінің әртүрлі нұсқаларын аламыз.

Барлығын дұрыс орындау үшін бұл схемаға қосымша сілтеме қажет - Kubernetes API-ден күй туралы ақпаратты алатын және оны заттардың нақты жағдайын одан әрі талдау үшін жіберетін арнайы трекер. Go бағдарламасында ашық бастапқы кітапхананы жасадық - текше ит (хабарландыруды қараңыз осында), бұл мәселені шешеді және werf ішіне салынған.

Бұл трекердің werf деңгейіндегі әрекеті Deployments немесе StatefulSets ішінде орналастырылған аннотациялар арқылы конфигурацияланады. Негізгі аннотация - fail-mode - келесі мағыналарды түсінеді:

• IgnoreAndContinueDeployProcess — біз бұл компонентті шығару проблемаларын елемейміз және орналастыруды жалғастырамыз;
• FailWholeDeployProcessImmediately — осы құрамдастағы қате орналастыру процесін тоқтатады;
• HopeUntilEndOfDeployProcess — бұл компонент орналастырудың соңына дейін жұмыс істейді деп үміттенеміз.

Мысалы, ресурстар мен аннотация мәндерінің бұл тіркесімі fail-mode:

Біз бірінші рет орналастырған кезде, дерекқор (MongoDB) әлі дайын болмауы мүмкін - Орналастырулар сәтсіз болады. Бірақ сіз оның басталуын күте аласыз және орналастыру әлі де орын алады.

Верфте kubedog үшін тағы екі аннотация бар:

• failures-allowed-per-replica — әрбір көшірме үшін рұқсат етілген құлдырау саны;
• show-logs-until — werf барлық шығарылған бөренелердегі журналдарды (stdout ішінде) көрсететін сәтті реттейді. Әдепкі болып табылады PodIsReady (подкаға трафик келе бастағанда біз шынымен қаламайтын хабарларды елемеу үшін), бірақ мәндер де жарамды: ControllerIsReady и EndOfDeploy.

Орналастырудан тағы не қалаймыз?

Жоғарыда сипатталған екі тармаққа қосымша біз:

• көру үшін журналдар - және қатардағы барлық емес, тек қажеттілер;
• трек прогресс, өйткені жұмыс бірнеше минут бойы «үнсіз» ілулі тұрса, онда не болып жатқанын түсіну маңызды;
• бар автоматты кері қайтару бірдеңе дұрыс болмаған жағдайда (сондықтан орналастырудың нақты күйін білу өте маңызды). Шығарылым атомдық болуы керек: не ол соңына дейін өтеді, не бәрі бұрынғы күйіне оралады.

Нәтижелері

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

Қорытынды орнына:

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

Бейнелер мен слайдтар

Спектакльден бейне (~47 минут):

Баяндаманы көрсету:

PS

Біздің блогтағы Кубернетес туралы басқа есептер:

• «Kubernetes жүйесінде автомасштабтау және ресурстарды басқару» (Дмитрий Столяров; 27 жылғы 2019 сәуірде «Ереуіл» туралы);
• «Кубернеттерді кеңейту және толықтыру» (Андрей Половов; 8 сәуір, 2019 ж. Saint HighLoad++);
• «Мәліметтер базасы және Кубернет» (Дмитрий Столяров; 8 жылғы 2018 қарашада HighLoad++);
• «Мониторинг және Kubernetes» (Дмитрий Столяров; 28 жылғы 2018 мамырда RootConf сайтында);
• «Kubernetes және GitLab көмегімен CI/CD үздік тәжірибелері» (Дмитрий Столяров; 7 жылғы 2017 қарашада HighLoad++);
• «Біздің Кубернетеспен шағын жобалардағы тәжірибеміз» (Дмитрий Столяров; 6 жылғы 2017 маусымда RootConf сайтында).

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