27-майда фестивалдын алкагында өтүп жаткан DevOpsConf 2019 конференциясынын башкы залында , "Үзгүлтүксүз жеткирүү" бөлүмүнүн бир бөлүгү катары, "werf - Kubernetesтеги CI/CD үчүн биздин куралыбыз" отчету берилди. Ошолор жөнүндө сөз болот Кубернетеске жайылтууда ар бир адам туш болгон көйгөйлөр жана кыйынчылыктар, ошондой эле дароо байкалбай турган нюанстар жөнүндө. Мүмкүн болгон чечимдерди талдап, биз бул Open Source куралында кантип ишке ашырыларын көрсөтөбүз .
Презентациядан бери, биздин утилитабыз (мурдагы Dapp катары белгилүү) тарыхый этапка жетти. GitHubдагы 1000 жылдыз — анын өсүп жаткан колдонуучулар коомчулугу көптөгөн DevOps инженерлеринин жашоосун жеңилдетет деп үмүттөнөбүз.
Ошентип, биз сунуштайбыз (~47 мүнөт, макалага караганда алда канча маалыматтуу) жана андан негизги үзүндү текст түрүндө. Go!
Кубернетеске код жеткирилүүдө
Кеп мындан ары werf жөнүндө эмес, Kubernetesтеги CI/CD жөнүндө болмокчу, бул биздин программалык камсыздообуз Docker контейнерлерине топтолгон дегенди билдирет. (Мен бул тууралуу айттым ), жана K8s өндүрүштө иштетүү үчүн колдонулат (бул тууралуу көбүрөөк маалымат ).
Кубернетесте жеткирүү кандай көрүнөт?
- Git репозиторийинин коду жана аны куруу боюнча нускамалары бар. Колдонмо Docker сүрөтүнө курулган жана Docker реестринде жарыяланган.
- Ошол эле репозиторийде тиркемени кантип жайгаштыруу жана иштетүү боюнча нускамалар да бар. Жайгаштыруу стадиясында бул көрсөтмөлөр реестрден керектүү сүрөттү алып, аны ишке киргизген Kubernetesке жөнөтүлөт.
- Мындан тышкары, адатта, тесттер бар. Алардын айрымдары сүрөттү жарыялоодо жасалышы мүмкүн. Сиз ошондой эле (ошол эле нускамаларды аткаруу менен) тиркеменин көчүрмөсүн (өзүнчө K8s аттар мейкиндигинде же өзүнчө кластерде) жайгаштырып, ал жерде сыноолорду жүргүзө аласыз.
- Акыр-аягы, сизге Gitтен окуяларды кабыл алган (же кнопканы басуу) жана бардык белгиленген этаптарды чакырган CI системасы керек: куруу, жарыялоо, жайылтуу, сыноо.
Бул жерде бир нече маанилүү эскертүүлөр бар:
- Анткени бизде өзгөрүлгүс инфраструктура бар (өзгөрбөс инфраструктура), бардык этаптарда колдонулган колдонмо сүрөтү (сценарий, өндүрүш ж.б.), бирөө болушу керек. Мен бул тууралуу кененирээк жана мисалдар менен айттым. .
- Анткени биз инфраструктураны коддуу ыкма катары карманабыз (IaC), колдонмонун коду, аны чогултуу жана ишке киргизүү боюнча нускамалар болушу керек так бир репозиторийде. Бул тууралуу көбүрөөк маалымат алуу үчүн, карагыла .
- Жеткирүү чынжыр (жеткирүү) биз муну адатта мындай көрөбүз: тиркеме чогулду, сыналды, чыгарылды (чыгаруу баскычы) жана бул - жеткирүү ишке ашты. Бирок, чындыгында, колдонуучу сиз чыгарган нерсени алат, жок анан аны өндүрүшкө тапшырганыңызда, ал жакка барганда бул өндүрүш иштеген. Ошентип, мен жеткирүү чынжыр аяктайт деп ишенем операциялык стадиясында гана (чуркоо), же тагыраак айтканда, код өндүрүштөн алынып салынган учурда да (аны жаңысына алмаштыруу).
Кубернетестеги жогорудагы жеткирүү схемасына кайрылып көрөлү: аны биз гана эмес, бул көйгөй менен алектенгендердин бардыгы ойлоп тапкан. Чынында, бул үлгү азыр GitOps деп аталат (сиз термин жана анын артында турган идеялар жөнүндө көбүрөөк окуй аласыз ). Келгиле, схеманын этаптарын карап көрөлү.
Этап куруу
2019-жылы Docker сүрөттөрүн куруу жөнүндө сүйлөшө аласыз окшойт, качан баары Dockerfiles жазууну жана иштетүүнү билет docker build?.. Мына мен көңүл бургум келген нюанстар:
- Сүрөттүн салмагы маанилүү, ошондуктан колдонуу Сүрөттө операция үчүн чындап зарыл болгон тиркемени гана калтыруу.
- катмарлардын саны чынжырларын айкалыштыруу менен минималдаштыруу керек
RUN-мааниси боюнча буйруктар. - Бирок, бул көйгөйлөрдү кошот мүчүлүштүктөрдү оңдоо, анткени жыйын бузулганда, көйгөйдү жараткан чынжырдан туура буйрукту табышыңыз керек.
- Чогултуу ылдамдыгы маанилүү, анткени биз тез арада өзгөртүүлөрдү киргизип, натыйжаларды көргүбүз келет. Мисалы, сиз тиркемени курган сайын тил китепканаларындагы көз карандылыкты калыбына келтиргиңиз келбейт.
- Көбүнчө бир Git репозиторийинен сизге керек көптөгөн сүрөттөр, аны Dockerfiles жыйындысы (же бир файлдагы аталган этаптар) жана алардын ырааттуу жыйыны менен Bash скрипти менен чечсе болот.
Бул ар бир адам туш болгон айсбергдин бир чети эле. Бирок, атап айтканда, башка көйгөйлөр бар:
- Көбүнчө монтаждоо баскычында бизге бир нерсе керек тоо (мисалы, apt сыяктуу буйруктун натыйжасын үчүнчү тараптын каталогунда кэштеңиз).
- Биз каалайбыз Ansible кабыкчага жазуунун ордуна.
- Биз каалайбыз Docker жок куруу (Эмне үчүн бизде контейнерлерди иштете ала турган Кубернетес кластери бар болгондо, бул үчүн бардыгын конфигурациялашыбыз керек болгон кошумча виртуалдык машина керек?).
- Параллель чогултуу, ар кандай жолдор менен түшүнүүгө болот: Dockerfileден ар кандай буйруктар (эгерде көп баскычтуу колдонулса), бир репозиторийдин бир нече тапшырмалары, бир нече Докерфайлдар.
- Бөлүштүрүлгөн жыйын: Биз "эфемердик" болгон нерселерди породаларга чогултууну каалайбыз, анткени алардын кэши жок болот, бул өзүнчө бир жерде сакталышы керек дегенди билдирет.
- Акыры каалоолордун туу чокусун атадым automagic: Репозиторийге барып, кандайдыр бир буйруктарды терип, кантип жана эмнени туура кылуу керектигин түшүнүү менен чогултулган даяр сүрөттү алуу идеалдуу болмок. Бирок, мен жеке бардык нюанстарды ушундай жол менен алдын ала айтууга болот деп ишенбейм.
Жана бул жерде долбоорлор:
- — бардык ушул маселелерди чечүүгө аракет кылып жаткан Docker Incтин куруучусу (Докердин учурдагы версияларына мурунтан эле интеграцияланган);
- — Google компаниясынан Dockerсиз курууга мүмкүндүк берүүчү куруучу;
- — CNCFтин автоматтык сыйкырды жасоо аракети жана, атап айтканда, катмарлар үчүн ребаза менен кызыктуу чечим;
- жана башка бир топ коммуналдык кызматтар, мисалы , ...
...жана алардын GitHubда канча жылдызы бар экенин караңыз. Башкача айтканда, бир жагынан, docker build бар жана бир нерсе кыла алат, бирок чындыгында маселе толук чечиле элек - мунун далили - ар бири маселелердин кандайдыр бир бөлүгүн чечүүчү альтернативдик коллекторлордун параллелдүү өнүгүшү.
werfтеги чогулуш
Ошентип, биз керек (мурунку дап сыяктуу) — Биз көп жылдардан бери жасап келе жаткан Flant компаниясынын ачык булагы. Мунун баары 5 жыл мурун Dockerfiles жыйындысын оптималдаштыруучу Bash скрипттери менен башталган жана акыркы 3 жылда толук кандуу иштеп чыгуу өзүнүн Git репозиторийси бар бир долбоордун алкагында ишке ашырылган. (биринчи Ruby, анан Go, жана ошол эле учурда атын өзгөрттү). werfте кандай чогулуш маселелери чечилет?
Көк түскө боёлгон көйгөйлөр буга чейин ишке ашырылган, параллелдүү куруу бир эле хосттун ичинде жасалган, ал эми сары менен белгиленген маселелерди жайдын аягына чейин бүтүрүү пландалууда.
Реестрге жарыялоо стадиясы (жарыялоо)
Биз тердик docker push... - реестрге сүрөт жүктөөдө эмне кыйын болушу мүмкүн? Анан суроо туулат: "Сүрөткө кандай белги коюу керек?" Бул бизде болгон себеп менен келип чыгат Gitflow (же башка Git стратегиясы) жана Kubernetes жана өнөр жай Kubernetesте болуп жаткан окуялар Гитте болуп жаткан окуяларга дал келүүсүн камсыздоого аракет кылууда. Анткени, Гит биздин чындыктын жалгыз булагы.
Мунун эмнеси мынчалык кыйын? кайра чыгарууну камсыз кылуу: табияты боюнча өзгөрүлгүс болгон Гиттеги милдеттенмеден (өзгөрбөс), ошол эле сакталышы керек болгон Докер сүрөтүнө.
Бул биз үчүн да маанилүү келип чыгышын аныктоо, анткени биз Kubernetes'те иштеп жаткан тиркеме кайсы милдеттен жасалганын түшүнгүбүз келет (анда биз айырмачылыктарды жана ушул сыяктуу нерселерди жасай алабыз).
Белгилөө стратегиялары
Биринчиси жөнөкөй гит күнү. Бизде сүрөтү бар реестр бар 1.0. Kubernetes бул сүрөт жүктөлгөн сахна жана өндүрүш бар. Гитте биз милдеттенмелерди жасайбыз жана кандайдыр бир учурда тег жасайбыз 2.0. Биз аны репозиторийден көрсөтмөлөргө ылайык чогултуп, теги менен реестрге жайгаштырабыз 2.0. Биз аны сахнага, эгер баары жакшы болсо, өндүрүшкө чыгарабыз.
Бул ыкманын көйгөйү, биз алгач тегди коюп, андан кийин гана аны сынап көрүп, жайылтканыбызда. Неге? Биринчиден, бул жөн эле логикага сыйбаган нерсе: биз сынай элек программалык камсыздоонун версиясын чыгарып жатабыз (башкача кыла албайбыз, анткени текшерүү үчүн тег коюшубуз керек). Экинчиден, бул жол Gitflow менен шайкеш келбейт.
Экинчи жол - git commit + теги. Мастер бутагынын теги бар 1.0; ал үчүн реестрде - өндүрүшкө жайгаштырылган сүрөт. Мындан тышкары, Kubernetes кластеринде алдын ала көрүү жана коюу контурлары бар. Андан кийин биз Gitflow ээрчебиз: өнүктүрүү үчүн негизги тармагында (develop) биз жаңы функцияларды жасайбыз, натыйжада идентификатор менен милдеттенебиз #c1. Биз аны чогултуп, ушул идентификатордун жардамы менен реестрге жарыялайбыз (#c1). Ошол эле идентификатор менен биз алдын ала көрүү үчүн чыгабыз. Биз милдеттенмелер менен да ушундай кылабыз #c2 и #c3.
Жетиштүү өзгөчөлүктөр бар экенин түшүнгөндө, биз бардыгын турукташтыра баштайбыз. Гитте филиал түзүңүз 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'де тег коюу
Верфте биз андан да ары кеттик жана бир машинада сакталбаган кэш менен бөлүштүрүлгөн курууга даярданып жатабыз... Ошентип, биз Docker сүрөттөрүнүн эки түрүн куруп жатабыз, биз аларды чакырабыз. сахна и сүрөт.
werf Git репозиторийинде куруунун ар кандай этаптарын сүрөттөгөн атайын нускамалар сакталат (орнотуудан мурун, орнотуу, Орнотуудан мурун, жайгашуу). Биз биринчи кадамдардын текшерүү суммасы катары аныкталган кол менен биринчи этап сүрөтүн чогултабыз. Андан кийин баштапкы кодду кошобуз, жаңы сахналык образ үчүн биз анын контролдук суммасын эсептейбиз... Бул операциялар бардык этаптар үчүн кайталанат, натыйжада биз сахналык сүрөттөрдүн топтомун алабыз. Андан кийин биз акыркы сүрөттү жасайбыз, анда анын келип чыгышы жөнүндө метаберилиштер да камтылган. Жана биз бул сүрөттү ар кандай жолдор менен белгилейбиз (кийинирээк).
Мындан кийин жаңы милдеттенме пайда болду дейли, анда колдонмонун коду гана өзгөртүлгөн. Эмне болот? Кодду өзгөртүү үчүн патч түзүлүп, жаңы сахналык образ даярдалат. Анын колтамгасы эски сахна сүрөтүнүн жана жаңы патчтын текшерүү суммасы катары аныкталат. Бул сүрөттөн жаңы акыркы сүрөт түзүлөт. Ушундай эле жүрүм-турум башка этаптардагы өзгөрүүлөр менен да болот.
Ошентип, сахна сүрөттөрү бөлүштүрүлүп сактала турган кэш болуп саналат жана андан мурунтан эле түзүлгөн сүрөттөр Docker реестрине жүктөлөт.
Реестрди тазалоо
Жок кылынган тегдерден кийин илинип калган катмарларды жок кылуу жөнүндө сөз кылбайбыз - бул Docker Реестринин стандарттуу өзгөчөлүгү. Биз көп Docker тэгдери топтолуп калган кырдаал жөнүндө айтып жатабыз жана биз алардын айрымдарына муктаж болбой калганыбызды түшүнөбүз, бирок алар орун ээлейт (жана/же биз бул үчүн төлөйбүз).
Тазалоо стратегиялары кандай?
- Сиз эч нерсе кыла албайсыз тазалаба. Кээде чоң чаташкан тегдерди чечкенге караганда, кошумча орун үчүн бир аз төлөө оңой. Бирок бул белгилүү бир чекитке чейин гана иштейт.
- Толук баштапкы абалга келтирүү. Эгер сиз бардык сүрөттөрдү өчүрүп, CI тутумундагы учурдагыларды гана калыбына келтирсеңиз, көйгөй келип чыгышы мүмкүн. Эгерде контейнер өндүрүштө кайра иштетилсе, ал үчүн жаңы сүрөт жүктөлөт - ал азырынча эч ким тарабынан сынала элек. Бул өзгөрбөс инфраструктура идеясын жок кылат.
- Көк жашыл. Бир реестр толуп баштады - биз башкасына сүрөттөрдү жүктөйбүз. Мурунку ыкмадагыдай эле көйгөй: толуп баштаган реестрди кайсы учурда тазалай аласыз?
- убакыт менен. 1 айдан ашкан бардык сүрөттөр жок кылынсынбы? Бирок бир айдан бери жаңыланбаган кызмат сөзсүз болот...
- кол менен буга чейин жок кылынышы мүмкүн аныктоо.
Эки чындап жарактуу варианттары бар: тазалабаңыз же көк-жашылдын айкалышы + кол менен. Акыркы учурда, биз төмөнкүлөр жөнүндө айтып жатабыз: реестрди тазалоого убакыт келгенин түшүнгөндө, сиз жаңысын түзүп, ага бардык жаңы сүрөттөрдү кошосуз, мисалы, бир айдын ичинде. Бир айдан кийин, Кубернетестеги кайсы подкасттар дагы эле эски реестрди колдонуп жатканын көрүп, аларды да жаңы реестрге өткөрүңүз.
Эмнеге келдик werf? Биз чогултабыз:
- Git башчысы: бардык тегдер, бардык бутактар - сүрөттөрдө Gitте белгиленген нерселердин бардыгы керек деп ойлосок (жана эгер жок болсо, анда аны Gitтин өзүндө жок кылышыбыз керек);
- учурда Кубернетеске сордурулуп жаткан бардык поддондор;
- эски ReplicaSets (жакында чыккан), ошондой эле Helm релиздерин сканерлеп, ал жерден эң акыркы сүрөттөрдү тандоону пландаштырып жатабыз.
... жана бул топтомдон ак тизме түзүңүз - биз жок кылбай турган сүрөттөрдүн тизмесин. Калганынын баарын тазалап, андан кийин жетим сахнанын сүрөттөрүн таап, аларды да жок кылабыз.
Этапты жайылтуу
Ишенимдүү декларативдүүлүк
Жайгаштырууда мен көңүл бургум келген биринчи жагдай - бул декларативдик түрдө жарыяланган жаңыланган ресурс конфигурациясынын жайылуусу. Kubernetes ресурстарын сүрөттөгөн түпнуска YAML документи кластерде иштеген натыйжадан ар дайым абдан айырмаланып турат. Анткени Kubernetes конфигурацияга кошумчалайт:
- идентификаторлор;
- кызмат жөнүндө маалымат;
- көп демейки маанилер;
- учурдагы абалы менен бөлүм;
- кабыл алуу вебхукунун бир бөлүгү катары киргизилген өзгөртүүлөр;
- ар кандай контролерлордун (жана пландоочунун) ишинин натыйжасы.
Ошондуктан, жаңы ресурс конфигурациясы пайда болгондо (жаңы), биз аны менен учурдагы, "тирүү" конфигурацияны алып, үстүнө жаза албайбыз (жашоо). Бул үчүн биз салыштырууга туура келет жаңы акыркы колдонулган конфигурация менен (акыркы колдонулган) жана тоголоктоп коюңуз жашоо патч алды.
Бул ыкма деп аталат 2 тараптуу бириктирүү. Ал, мисалы, Helm колдонулат.
Ошондой эле бар 3 тараптуу бириктирүү, бул менен айырмаланат:
- салыштыруу акыркы колдонулган и жаңы, биз эмне жок кылынганын карайбыз;
- салыштыруу жаңы и жашоо, эмне кошулганын же өзгөртүлгөнүн карайбыз;
- жалпыланган жамаачы колдонулат жашоо.
Биз Helm менен 1000+ тиркемелерди орнотобуз, ошондуктан биз чындыгында эки тараптуу биригүү менен жашайбыз. Бирок, биз Хелмдин нормалдуу иштешине жардам берген патчтарыбыз менен чечкен бир катар көйгөйлөр бар.
Чыныгы жайылтуу абалы
Биздин CI тутумубуз кийинки окуянын негизинде Kubernetes үчүн жаңы конфигурацияны жараткандан кийин, аны колдонууга өткөрүп берет (колдонуу) кластерге - Helm же колдонуу kubectl apply. Андан кийин, буга чейин эле сүрөттөлгөн N-жол менен бириктирүү пайда болот, ага Kubernetes API CI тутумуна жана анын колдонуучусуна макулдук менен жооп берет.
Бирок, бир чоң көйгөй бар: баары бир ийгиликтүү колдонуу ийгиликтүү жайылтуу дегенди билдирбейт. Эгер Кубернетес кандай өзгөрүүлөрдү колдонуу керектигин түшүнүп, аны колдонсо, натыйжасы кандай болорун дагы деле билбейбиз. Мисалы, фронтондо подкасттарды жаңыртуу жана кайра иштетүү ийгиликтүү болушу мүмкүн, бирок бэкендинде эмес, биз иштеп жаткан колдонмо сүрөттөрүнүн ар кандай версияларын алабыз.
Баарын туура кылуу үчүн, бул схема кошумча шилтемени талап кылат - 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++ боюнча);
- «» (Дмитрий Столяров; 28-жылдын 2018-майы, RootConf сайтында);
- «» (Дмитрий Столяров; 7-жылдын 2017-ноябрында HighLoad++ боюнча);
- «» (Дмитрий Столяров; 6-жылдын 2017-июнунда RootConf сайтында).
Source: www.habr.com