27. маја у главној сали конференције ДевОпсЦонф 2019, одржане у оквиру фестивала , као део одељка „Непрекидна испорука“, дат је извештај „верф – наш алат за ЦИ/ЦД у Кубернетесу“. О њима се говори проблеми и изазови са којима се сви суочавају приликом постављања на Кубернетес, као и о нијансама које можда неће бити одмах уочљиве. Анализирајући могућа решења, показујемо како се то имплементира у Опен Соурце алату .
Од презентације, наш услужни програм (раније познат као дапп) достигао је историјску прекретницу од 1000 звездица на ГитХуб-у — надамо се да ће његова растућа заједница корисника олакшати живот многим ДевОпс инжењерима.
Дакле, хајде да се представимо (~47 минута, много информативније од чланка) и главни извод из њега у текстуалном облику. Иди!
Испорука кода у Кубернетес
Више неће бити речи о верф-у, већ о ЦИ/ЦД-у у Кубернетесу, што подразумева да је наш софтвер упакован у Доцкер контејнере (Причао сам о овоме у ), а К8с ће се користити за покретање у производњи (више о овоме у ).
Како изгледа достава у Кубернетесу?
- Постоји Гит спремиште са кодом и упутствима за његову изградњу. Апликација је уграђена у Доцкер слику и објављена у Доцкер регистру.
- Исто спремиште такође садржи упутства о томе како да примените и покренете апликацију. У фази имплементације, ова упутства се шаљу Кубернетесу, који прима жељену слику из регистра и покреће је.
- Осим тога, обично постоје тестови. Неке од њих се могу урадити приликом објављивања слике. Такође можете (пратећи иста упутства) да примените копију апликације (у засебном К8с именском простору или засебном кластеру) и тамо покренете тестове.
- Коначно, потребан вам је ЦИ систем који прима догађаје из Гита (или кликове на дугме) и позива све одређене фазе: прављење, објављивање, примену, тестирање.
Овде постоји неколико важних напомена:
- Зато што имамо непроменљиву инфраструктуру (непроменљива инфраструктура), слика апликације која се користи у свим фазама (припрема, производња, итд.), мора постојати један. О овоме сам говорио детаљније и са примерима. .
- Зато што следимо инфраструктуру као приступ коду (ИаЦ), код апликације, упутства за састављање и покретање треба да буду тачно у једном спремишту. За више информација о овоме, погледајте .
- Ланац испоруке (испорука) обично то видимо овако: апликација је састављена, тестирана, пуштена (фаза пуштања) и то је то - испорука је обављена. Али у стварности, корисник добија оно што сте представили, не онда када сте га испоручили у производњу, и када је он могао да оде тамо и када је ова производња прорадила. Тако да верујем да се ланац испоруке завршава само у оперативној фази (трцати), тачније, чак и у тренутку када је код скинут из производње (замена новим).
Вратимо се на горњу шему испоруке у Кубернетесу: измислили смо је не само ми, већ буквално сви који су се бавили овим проблемом. У ствари, овај образац се сада зове ГитОпс (можете прочитати више о термину и идејама иза њега ). Хајде да погледамо фазе шеме.
Буилд стаге
Чини се да можете причати о изградњи Доцкер слика у 2019. години, када сви знају како да напишу Доцкер фајлове и покрећу docker build?.. Ево нијанси на које бих желео да обратим пажњу:
- Тежина слике ствари, па користите да се на слици остави само апликација која је заиста неопходна за операцију.
- Број слојева мора се минимизирати комбиновањем ланаца од
RUN-команде према значењу. - Међутим, ово додаје проблеме отклањање грешака, јер када се склоп сруши, морате пронаћи праву команду из ланца који је изазвао проблем.
- Брзина изградње важно јер желимо брзо да уведемо промене и видимо резултате. На пример, не желите да поново градите зависности у библиотекама језика сваки пут када правите апликацију.
- Често вам је потребно из једног Гит спремишта много слика, који се може решити скупом Доцкер фајлова (или именованим фазама у једној датотеци) и Басх скриптом са њиховим узастопним склапањем.
Ово је био само врх леденог брега са којим се сви суочавају. Али постоје и други проблеми, посебно:
- Често нам у фази монтаже нешто треба моунт (на пример, кеширајте резултат команде као што је апт у директоријуму треће стране).
- Желимо Могуће уместо писања у љусци.
- Желимо градити без Доцкер-а (зашто нам је потребна додатна виртуелна машина у којој морамо све да конфигуришемо за ово, када већ имамо Кубернетес кластер у коме можемо да покрећемо контејнере?).
- Паралелни склоп, што се може разумети на различите начине: различите команде из Доцкерфиле-а (ако се користи вишестепени), неколико урезивања истог спремишта, неколико Доцкерфиле-а.
- Дистрибуирана монтажа: Желимо да сакупљамо ствари у махунама које су „ефемерне” јер њихова кеш меморија нестаје, што значи да треба да се чува негде одвојено.
- Коначно сам назвао врхунац жеља аутомагиц: Идеално би било да одете у спремиште, откуцате неку команду и добијете готову слику, састављену са разумевањем како и шта да радите исправно. Међутим, лично нисам сигуран да се на овај начин могу предвидети све нијансе.
А ево и пројеката:
- — буилдер компаније Доцкер Инц (већ интегрисан у тренутне верзије Доцкер-а), који покушава да реши све ове проблеме;
- — буилдер из Гоогле-а који вам омогућава да градите без Доцкер-а;
- — ЦНЦФ-ов покушај да направи аутоматску магију и, посебно, занимљиво решење са ребазом за слојеве;
- и гомила других услужних програма, као нпр , ...
...и погледајте колико звезда имају на ГитХубу. То јест, с једне стране, docker build постоји и може нешто, али у стварности питање није у потпуности решено - доказ за то је паралелни развој алтернативних колектора, од којих сваки решава неки део проблема.
Скупштина у верф
Па смо морали (раније као дапп) — Услужни програм отвореног кода компаније Флант, који правимо дуги низ година. Све је почело пре 5 година са Басх скриптама које су оптимизовале склапање Доцкерфилес-а, а последње 3 године потпуни развој је спроведен у оквиру једног пројекта са сопственим Гит репозиторијумом (прво у Рубију, а затим то Го, и истовремено преименован). Која се питања монтаже решавају у верфу?
Проблеми осенчени плавом бојом су већ реализовани, паралелна градња је урађена у оквиру истог хоста, а планирано је да се проблеми означени жутом бојом заврше до краја лета.
Фаза објављивања у регистру (објави)
Звали смо docker push... - шта би могло бити тешко око отпремања слике у регистар? И онда се поставља питање: "Коју ознаку да ставим на слику?" Она настаје из разлога што имамо Гитфлов (или неку другу Гит стратегију) и Кубернетес, а индустрија покушава да обезбеди да оно што се дешава у Кубернетесу прати оно што се дешава у Гиту. На крају крајева, Гит је наш једини извор истине.
Шта је ту тако тешко? Осигурајте поновљивост: из урезивања у Гиту, који је по природи непроменљив (непроменљиво), на Доцкер слику, која треба да остане иста.
Нама је такође важно утврди порекло, јер желимо да разумемо из којег урезивања је направљена апликација која ради у Кубернетес-у (онда можемо да радимо разлике и сличне ствари).
Стратегије означавања
Први је једноставан гит таг. Имамо регистар са сликом означеном као 1.0. Кубернетес има позорницу и продукцију, где се ова слика поставља. У Гиту правимо урезивање и у неком тренутку означавамо 2.0. Сакупљамо га према упутствима из спремишта и стављамо у регистар са ознаком 2.0. Пребацујемо га на сцену и, ако је све у реду, онда у производњу.
Проблем са овим приступом је што смо прво ставили ознаку, а тек онда је тестирали и избацили. Зашто? Прво, једноставно је нелогично: издајемо верзију софтвера коју још нисмо ни тестирали (не можемо другачије, јер да бисмо проверили, морамо да ставимо ознаку). Друго, ова путања није компатибилна са Гитфлов-ом.
Друга опција - гит урезивање + ознака. Главна грана има ознаку 1.0; за то у регистру - слика распоређена у производњу. Поред тога, Кубернетес кластер има контуре за преглед и постављање. Затим пратимо Гитфлов: у главној грани за развој (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), али знамо да су то „физички“ исте слике из регистра.
Прави недостатак је што не постоји подршка за урезивање спајања, морате да радите брзо унапред.
Можемо ићи даље и направити трик... Погледајмо пример једноставног Доцкерфиле-а:
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Хајде да направимо датотеку од ње према следећем принципу:
- СХА256 из идентификатора коришћених слика (
ruby:2.3иnginx:alpine), који су контролни суми њиховог садржаја; - сви тимови (
RUN,CMDитд.); - СХА256 из датотека које су додате.
... и узмите контролни збир (опет СХА256) из такве датотеке. Ово потпис све што дефинише садржај Доцкер слике.
Вратимо се дијаграму и уместо урезивања користићемо такве потписе, тј. означите слике потписима.
Сада, када је потребно, на пример, да спојимо измене из издања у мастер, можемо да урадимо право обједињавање: имаће другачији идентификатор, али исти потпис. Са истим идентификатором ћемо приказати слику у производњи.
Недостатак је што сада неће бити могуће утврдити која врста урезивања је гурнута у производњу - контролни суми раде само у једном правцу. Овај проблем је решен додатним слојем са метаподацима - рећи ћу вам више касније.
Означавање у верф
У верф-у смо отишли још даље и спремамо се да урадимо дистрибуирану градњу са кешом који није ускладиштен на једној машини... Дакле, градимо две врсте Доцкер слика, називамо их фаза и слика.
верф Гит спремиште чува упутства специфична за изградњу која описују различите фазе изградње (пре инсталирања, инсталирати, пре подешавања, намештаљка). Сакупљамо слику прве фазе са потписом дефинисаним као контролни збир првих корака. Затим додајемо изворни код, за нову слику позорнице израчунавамо њен контролни збир... Ове операције се понављају за све етапе, као резултат добијамо скуп слика позорнице. Затим правимо коначну слику, која такође садржи метаподатке о свом пореклу. И ову слику означавамо на различите начине (детаљи касније).
Претпоставимо да се након овога појави ново урезивање у којем је промењен само код апликације. Шта ће се десити? За промене кода, биће направљена закрпа и биће припремљена нова слика позорнице. Његов потпис ће бити одређен као контролни збир старе слике сцене и нове закрпе. Нова коначна слика ће се формирати од ове слике. Слично понашање ће се десити са променама у другим фазама.
Према томе, сценске слике су кеш који се може складиштити дистрибуирано, а слике које су већ креиране из њега се учитавају у Доцкер регистар.
Чишћење регистра
Не говоримо о брисању слојева који су остали да висе након обрисаних ознака – ово је стандардна карактеристика самог Доцкер регистра. Говоримо о ситуацији када се накупи много Доцкер ознака и разумемо да нам неки од њих више нису потребни, али заузимају простор (и/или ми то плаћамо).
Које су стратегије чишћења?
- Не можете ништа учинити не чисти. Понекад је заиста лакше платити мало за додатни простор него размрсити огроман сплет ознака. Али ово функционише само до одређене тачке.
- Потпуно ресетовање. Ако избришете све слике и поново изградите само оне тренутне у ЦИ систему, може настати проблем. Ако се контејнер поново покрене у производњи, за њега ће се учитати нова слика - она коју још нико није тестирао. Ово убија идеју непроменљиве инфраструктуре.
- Плаво зелене. Један регистар је почео да се прелива - слике учитавамо у други. Исти проблем као у претходној методи: у ком тренутку можете да обришете регистар који је почео да се прелива?
- По времену. Желите ли да избришете све слике старије од 1 месеца? Али сигурно ће постојати сервис који није ажуриран месец дана...
- Ручно одредити шта се већ може избрисати.
Постоје две заиста одрживе опције: не чистите или комбинација плаво-зелене + ручно. У другом случају, говоримо о следећем: када схватите да је време за чишћење регистра, креирате нови и додајете све нове слике у њега током, на пример, месец дана. И после месец дана, погледајте који подови у Кубернетесу још увек користе стари регистар и пренесите их такође у нови регистар.
До чега смо дошли верф? Прикупљамо:
- Гит глава: све ознаке, све гране - под претпоставком да нам је потребно све што је означено у Гиту на сликама (а ако није, онда морамо то да избришемо у самом Гиту);
- све махуне које се тренутно испумпају у Кубернетес;
- старе РеплицаСетс (оно што је недавно објављено), а такође планирамо да скенирамо Хелм издања и тамо одаберемо најновије слике.
... и направите белу листу од овог скупа - листу слика које нећемо избрисати. Чистимо све остало, након чега проналазимо слике сирочади и бришемо их.
Деплои стаге
Поуздана декларативност
Прва тачка на коју бих желео да скренем пажњу у примени је увођење ажуриране конфигурације ресурса, декларативно декларисане. Оригинални ИАМЛ документ који описује Кубернетес ресурсе је увек веома различит од резултата који се стварно изводи у кластеру. Зато што Кубернетес додаје у конфигурацију:
- идентификатори;
- сервисне информације;
- многе подразумеване вредности;
- одељак са тренутним статусом;
- измене направљене као део вебхоока за пријем;
- резултат рада разних контролера (и планера).
Стога, када се појави нова конфигурација ресурса (нови), не можемо само да узмемо и препишемо тренутну, „живу“ конфигурацију са њом (живети). Да бисмо то урадили, мораћемо да упоредимо нови са последњом примењеном конфигурацијом (последње примењено) и откотрљајте на живети примљена закрпа.
Овај приступ се зове Двосмерно спајање. Користи се, на пример, у Хелму.
Постоје Двосмерно спајање, који се разликује по томе:
- поредећи последње примењено и нови, гледамо шта је обрисано;
- поредећи нови и живети, гледамо шта је додато или промењено;
- збирни фластер се примењује на живети.
Ми примењујемо 1000+ апликација са Хелмом, тако да заправо живимо са двосмерним спајањем. Међутим, има низ проблема које смо решили нашим закрпама, које помажу Хелму да нормално ради.
Прави статус увођења
Након што наш ЦИ систем генерише нову конфигурацију за Кубернетес на основу следећег догађаја, он је преноси на употребу (применити) на кластер – помоћу Хелм или kubectl apply. Затим долази до већ описаног Н-смерног спајања, на које Кубернетес АПИ са одобравањем одговара ЦИ систему, а то и свом кориснику.
Међутим, постоји огроман проблем: на крају крајева успешна примена не значи успешно увођење. Ако Кубернетес разуме које промене треба применити и примени их, још увек не знамо какав ће бити резултат. На пример, ажурирање и поновно покретање подова у фронтенду може бити успешно, али не и у позадини, и добићемо различите верзије слика покренутих апликација.
Да би све урадили исправно, ова шема захтева додатну везу - посебан трацкер који ће примати информације о статусу од Кубернетес АПИ-ја и преносити их на даљу анализу стварног стања ствари. Направили смо библиотеку отвореног кода у Го - (погледајте његову најаву ), који решава овај проблем и уграђен је у верф.
Понашање овог трагача на верф нивоу је конфигурисано коришћењем напомена које се постављају на Деплоиментс или СтатефулСетс. Главна напомена - fail-mode - разуме следећа значења:
-
IgnoreAndContinueDeployProcess— игноришемо проблеме увођења ове компоненте и настављамо са применом; -
FailWholeDeployProcessImmediately— грешка у овој компоненти зауставља процес примене; -
HopeUntilEndOfDeployProcess— надамо се да ће ова компонента радити до краја имплементације.
На пример, ова комбинација ресурса и вредности напомена fail-mode:
Када имплементирамо по први пут, база података (МонгоДБ) можда још није спремна – имплементације неће успети. Али можете сачекати тренутак да почне, а распоређивање ће се ипак одржати.
Постоје још две напомене за кубедог у верф-у:
-
failures-allowed-per-replica— број дозвољених падова за сваку реплику; -
show-logs-until— регулише тренутак до којег верф приказује (у стандардном излазу) дневнике из свих избачених подова. Подразумевано јеPodIsReady(да игноришемо поруке које вероватно не желимо када саобраћај почне да долази до под), али вредности су такође важеће:ControllerIsReadyиEndOfDeploy.
Шта још желимо од распоређивања?
Поред две већ описане тачке, желели бисмо:
- види трупаца - и то само оне неопходне, а не све редом;
- трацк напредак, јер ако посао виси „тихо” неколико минута, важно је разумети шта се ту дешава;
- има аутоматско враћање уназад у случају да нешто пође по злу (и стога је од кључне важности знати прави статус распоређивања). Увођење мора бити атомско: или иде до краја, или се све враћа у своје претходно стање.
Резултати
За нас као компанију, за имплементацију свих описаних нијанси у различитим фазама испоруке (израда, објављивање, имплементација), довољни су ЦИ систем и услужни програм .
Уместо закључка:
Уз помоћ верф-а, направили смо добар напредак у решавању великог броја проблема за ДевОпс инжењере и било би нам драго да шира заједница бар испроба овај услужни програм на делу. Заједно ће бити лакше постићи добар резултат.
Видео снимци и слајдови
Видео са наступа (~47 минута):
Презентација извештаја:
ПС
Остали извештаји о Кубернетес-у на нашем блогу:
- «» (Дмитриј Стољаров; 27. април 2019. на „Штрајку“);
- «» (Андреј Половов; 8. април 2019. на Саинт ХигхЛоад++);
- «» (Дмитриј Стољаров; 8. новембар 2018. на ХигхЛоад++);
- «» (Дмитриј Стољаров; 28. мај 2018. на РоотЦонф-у);
- «» (Дмитриј Стољаров; 7. новембар 2017. на ХигхЛоад++);
- «» (Дмитриј Стољаров; 6. јун 2017. на РоотЦонф-у).
Извор: ввв.хабр.цом