🥇werf — нашият инструмент за CI/CD в Kubernetes (преглед и видео на доклада)

На 27 май в главната зала на конференцията DevOpsConf 2019, която се провежда в рамките на фестивала РИТ++ 2019, в секцията „Непрекъсната доставка“, беше представен докладът „werf — нашият инструмент за CI/CD в Kubernetes“. В него се говори за проблемите и предизвикателствата, с които всеки се сблъсква при деплойването в Kubernetes, както и за нюансите, които не винаги се забелязват веднага. Разглеждайки възможните решения, показваме как това е реализирано в Open Source инструмента werf.

След представянето ни, нашият инструмент (по-рано известен като dapp) премина историческия праг от 1000 звезди в GitHub — ние се надяваме, че растящата общност от потребители ще улесни живота на много DevOps инженери.

И така, представяме видео с доклада (~47 минути, много по-информативно от статията) и основната същност от него в текстов формат. Да започнем!

Доставката на код в Kubernetes

В доклада ще говорим не толкова за werf, а за CI/CD в Kubernetes, предполагайки, че нашият софтуер е опакован в Docker контейнери (за това говоря в доклада от 2016 година), и K8s ще се използва за неговото стартиране в продукция (за това — в 2017 година).

Как изглежда доставката в Kubernetes?

Има Git репозиториум с код и инструкции за неговото изграждане. Приложението се изгражда в Docker образ и се публикува в Docker Registry.
В същия репозиториум има инструкции и за това как да се деплойва и стартира приложението. На етапа на деплойване тези инструкции се изпращат в Kubernetes, който получава нужния образ от registry и го стартира.
Освен това, обикновено има тестове. Някои от тях могат да се изпълняват при публикуването на образа. Също така, може (по същите инструкции) да се разгръне копие на приложението (в отделно пространство от имената на K8s или в отделен клъстер) и да се изпълняват тестове там.
Накрая, нужна е CI система, която получава събития от Git (или натискания на бутони) и задейства всички обозначени етапи: build, publish, deploy, test.

Тук има няколко важни забележки:

Тъй като имаме неизменяема инфраструктура (immutable infrastructure), образът на приложението, който се използва на всички етапи (staging, production и т.н.), трябва да бъде един. По-подробно за това и с примери съм говорил тук..
Тъй като следваме подхода инфраструктура като код (IaC), кодът на приложението, инструкциите за неговото изграждане и стартиране трябва да се съхраняват в именно един репозиториум. По-подробно за това — виж в същия доклад.
Цепочката за доставка (delivery) обикновено я виждаме така: приложението е събрано, тествано, релизнато (етап release) и всичко — доставката е извършена. Но всъщност потребителят получава това, което сте пуснали, не когато вие сте го доставили в production, а когато той е могъл да влезе и производството е работило. Затова считам, че веригата на доставка приключва само на етапа на експлоатация (run), а ако говорим по-точно, дори в момента, когато кодът е премахнат от production (заменяйки го с нов).

Нека се върнем към посочената по-горе схема на доставка в Kubernetes: тя е изобретена не само от нас, но и почти от всеки, който се е занимавал с този проблем. По същество този патърн сега наричат GitOps (повече за термина и стоящите зад него идеи може да се прочете тук.). Нека разгледаме етапите на схемата.

Етап на сглобяване (build)

На пръв поглед, какво може да се разкаже през 2019 г. за сглобяването на Docker образи, когато всички умеят да пишат Dockerfile-и и да стартират docker build?.. Вот нюансы, на которые хотелось бы обратить внимание:

Размерът на образа има значение, затова използвайте multi-stage, за да оставите в образа само наистина нужното за работа на приложението.
Броят на слоевете трябва да се минимизира, като се комбинират вериги от RUN-команди по смисъл.
Въпреки това, това добавя проблеми в отстраняването на грешки, тъй като при провал на сглобяването трябва да се открие нужната команда от веригата, която е причинила проблема.
Скоростта на сглобяване е важна, защото искаме бързо да пускаме промени и да наблюдаваме резултатите. Например, не искаме да преосъществяваме зависимостите в библиотеките на езика при всяко сглобяване на приложението.
Често от един Git репозиторий се изискват много образи, което може да се реши с набор от Dockerfile-и (или именувани етапи в един файл) и Bash скрипт с тяхната последователна сглобка.

Това беше само връх на айсберга, с който се сблъскват всички. Но има и други проблеми, а именно:

Често на етапа на сглобяване ни е нужно нещо да монтираме (например, да кешираме резултата от команда тип apt в външна директория).
Искаме Ansible вместо да пишем на shell-а.
Искаме да сглобяваме без Docker (защо ни е допълнителна виртуална машина, в която трябва да настроим всичко за това, когато вече имаме клъстер Kubernetes, в който можем да стартираме контейнери?).
Паралелна сглобка, която може да се интерпретира по различен начин: различни команди от Dockerfile (ако се използва multi-stage), няколко комита от един репозиторий, няколко Dockerfile-а.
Разпределена сглобка: искаме да създаваме нещо в подове, които са „ефимерни“, тъй като кешът изчезва, а следователно — трябва да се съхранява някъде отделно.
Накрая нарекох върха на желанията си автоматизация: идеално би било да влезем в репозитория, да напишем някаква команда и да получим готов образ, събран с разбиране как и какво е правилно да се направи. Въпреки това, лично аз не съм убеден, че всички нюанси могат да бъдат предвидени по този начин.

И така, имаме проекти:

moby/buildkit — сборщик от компанията Docker Inc (вече интегриран в актуалните версии на Docker), който се опитва да реши всички тези проблеми;
kaniko — сборщик от Google, позволяващ събиране без Docker;
Buildpacks.io — опит на CNCF за автоматизация и в частност интересно решение с rebase за слоеве;
и още много други инструменти, като buildah, genuinetools/img…

… и вижте колко звезди имат в GitHub. Тоест, от една страна, docker build има и може нещо да направи, но в действителност въпросът не е решен окончателно — доказателство за това е паралелното развитие на алтернативни сборщики, всеки от които решава част от проблемите.

Сборка в werf

Така стигнахме до werf (преди известна както dapp) — Open Source инструмент на компания „Флант“, който разработваме вече много години. Всичко започна преди 5 години с Bash скриптове, оптимизиращи събирането на Dockerfile-ове, а през последните 3 години се провежда пълноценна разработка в рамките на един проект с собствен Git репозиторий (първоначално на Ruby, а след това пренаписан на Go, и заедно с това преименуван). Какви проблеми със сборката са решени в werf?

Засенчените в синьо проблеми вече са реализирани, паралелната сборка е направена в рамките на един хост, а отделените жълто въпроси планираме да завършим до края на лятото.

Фаза на публикуване в registry (publish)

Събрахме docker push… — какво може да бъде трудно в това да качиш образ в registry? И тук възниква въпросът: „Какъв таг да поставим на образа?“ Възниква той по причина, че имаме Gitflow (или друга стратегия на Git) и Kubernetes, а индустрията се стреми случващото се в Kubernetes да следва това, което прави в Git. Все пак Git — нашият единствен източник на истина.

Какво има трудно в това? Гарантиране на повторяемост: от комита в Git, който по своята същност е неизменим (immutable), до образа на Docker, който трябва да остане същият.

Също така е важно за нас да определим произхода, защото искаме да разберем от коя версия е събрано приложението, стартирано в Kubernetes (по този начин можем да правим разлики и подобни неща).

Стратегии за тагиране

Първият е просто git tag. Имаме регистър с образ, тагиран като 1.0. В Kubernetes има staging и production, където този образ е разположен. В Git правим комити и в даден момент поставяме таг 2.0. Събираме го по инструкциите от репозитория и го поставяме в регистъра с таг 2.0. Разгъваме на staging и, ако всичко е наред, след това на production.

Проблемът с този подход е, че първо поставяме тага, а едва след това тестваме и разгръщаме. Защо? Първо, това е просто нелогично: издаваме версия на софтуер, който даже не сме проверили (не можем да направим иначе, защото за да проверим, е нужно да поставим таг). Второ, този път не съвпада с Gitflow.

Вторият вариант е git commit + tag. В основната клонка (master) има таг 1.0; за него в регистъра – образ, развърнат на production. Освен това, в Kubernetes клъстера има контури preview и staging. След това следваме Gitflow: в основната клонка за разработка (develop) правим нови функции, в резултат на което се появява комит с идентификатор #c1. Събираме го и публикуваме в регистъра, използвайки този идентификатор (#c1). С такъв идентификатор разгъваме на preview. Аналогично правим с комитите #c2 и #c3.

Когато разберем, че функциите са достатъчно стабилни, започваме всичко да стабилизираме. В Git създаваме клон release_1.1 (на базата на #c3 от develop). Не е необходимо да събираме този релиз, тъй като това е направено на предишния етап. Следователно можем просто да го разположим на staging. Коригираме грешките в #c4 и аналогично ги разгъваме на staging. Паралелно с това, разработката в develop, където периодично взимаме промените от release_1.1. В даден момент получаваме събран и разположен на staging комит, с който сме доволни (#c25).

Тогава правим merge (с fast-forward) на релизната клонка (release_1.1) в master. Поставяме на този комит таг с нова версия (1.1). Но този образ вече е събран в регистъра, затова, за да не го събираме отново, просто добавяме втори таг към съществуващия образ (сега той в регистъра има тагове #c25 и 1.1). След това го разположим на production.

Има недостатък, че на staging е разположен един образ (#c25), а на production – сякаш друг (1.1), но знаем, че "физически" това е един и същ образ от регистъра.

Истинският недостатък е, че няма поддръжка за merge commit-ове, трябва да правим fast-forward.

Можем да продължим и да направим трик… Нека разгледаме пример за прост 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-образа.

Нека се върнем към схемата и вместо комити да използваме такива сигнатури, т.е. да тагираме образите с сигнатури.

Сега, когато е необходимо, например, да 'сливаме' изменения от релиз в master, можем да направим истински merge commit: той ще има друг идентификатор, но същата сигнатура. С такъв идентификатор можем да пуснем образа и на продукция.

Недостатъкът е, че сега не можем да определим какъв комит е изтеглен на продукция — контролни суми работят само в една посока. Този проблем се решава с допълнителен слой с метаданни — по-подробно ще разкажа по-късно.

Тагиране в werf

В werf отидохме още по-далеч и се готвим да направим разпределена компилация с кеш, който не се съхранява на една машина… И така, създаваме Docker-образи от два типа, които наричаме и да разпространявате обновления в него преди разпространението в каналите и image.

В Git репозитория werf се съхраняват специфични инструкции за компилация, описващи различни етапи на компилацията (beforeInstall, инсталиране, предиНастройка, настройка). Първият stage-образ компилираме със сигнатура, определена като контролна сума на първоначалните стъпки. След това добавяме изходния код, за новия stage-образ смятаме неговата контролна сума… Тези операции се повтарят за всички етапи, в резултат на което получаваме набор от stage-образи. След това правим финален image-образ, съдържащ също метаданни за неговия произход. И именно този образ тагираме по различни начини (подробности по-късно).

Нека след това се появи нов комит, в който е променен само кода на приложението. Какво ще се случи? За промените в кода ще бъде създаден патч, подготвен нов stage-имидж. Неговият подпис ще бъде определен като контролна сума на стария stage-имидж и новия патч. От този имидж ще бъде формиран нов финален image-имидж. Аналогично поведение ще се случи при изменения на други етапи.

Така stage-имиджите са кеш, който може да бъде съхраняван разпределено, а създадените от него image-имиджи се качват в Docker Registry.

Почистване на регистъра

Става въпрос не за изтриване на слоеве, които остават висящи след изтрити тагове, — това е стандартна възможност на самия Docker Registry. Става дума за ситуация, когато се натрупват множество Docker-тагове и разбираме, че част от тях не са ни повече необходими, а заемат място (и/или плащаме за него).

Какви стратегии за почистване съществуват?

Просто може да не чистим. Понякога наистина е по-добре да платим малко за излишното пространство, отколкото да разплета огромен клубък от тагове. Но това работи само до определен момент.
Пълен ресет. Ако изтрием всички имиджи и пресъздадем само актуалните в CI-системата, може да се появи проблем. Ако на продукция се рестартира контейнер, за него ще се зареди нов имидж — такъв, който още никой не е тествал. Това убива идеята за неизменна инфраструктура.
Blue-green. Един регистър започна да прелива — качваме имиджи в друг. Същият проблем, както в предишния метод: в кой момент можем да почистим регистъра, който започна да прелива?
По време. Да изтрием всички имиджи по-стари от 1 месец? Но задължително ще има услуга, която не е обновявана цял месец…
Ръчно да определим какво вече може да се изтрие.

Наистина жизнеспособни варианти са два: да не чистим или да комбинираме blue-green + ръчно. В последния случай става дума за следното: когато разберете, че е време да почистите регистъра, създавате нов и добавяте всички нови имиджи в него в продължение, например, на месец. А след месец гледате кои подове в Kubernetes все още използват стария регистър и ги премествате и в новия регистър.

До какво стигнахме в werf? Мы собираем:

Git head: всички тагове, всички клонове, — предполагайки, че всичко, което е означено в Git, ни е необходимо и в имиджите (а ако не, трябва да се изтрие в самия Git);
всички pod’и, които в момента са качени в Kubernetes;
стари ReplicaSet’и (това, което наскоро беше качено), а също така планираме да сканираме Helm-релизите и да изберем последните образи там.

… и правим от този набор whitelist — списък с образи, които няма да изтриваме. Всичко останало почистваме, след което намираме осиротели stage-образи и ги изтриваме също.

Етап на деплой (deploy)

Надеждна декларативност

Първият момент, на който бих искал да обърна внимание в деплоя, е изтеглянето на обновената конфигурация на ресурсите, обявена декларативно. Оригиналният YAML-документ с описание на Kubernetes-ресурсите винаги силно се различава от резултата, който реално работи в клъстера. Защото Kubernetes добавя в конфигурацията:

идентификатори;
служебна информация;
множество стойности по подразбиране;
секция с текущ статус;
промени, направени в рамките на работа на admission webhook;
резултат от работата на различни контролери (и планировщика).

Затова, когато се появи нова конфигурация на ресурс (нов), не можем просто да вземем и презапишем текущата, 'жива', конфигурация (live). За това ще трябва да сравним нов с предишно приложената конфигурация ('last-applied') и да приложим live получения патч.

Този подход се нарича 2-way merge.Той се използва, например, в Helm.

Има и 3-way merge,който се различава с това, че:

при сравняване 'last-applied' и нов, гледаме какво е било изтрито;
при сравняване нов и live, гледаме какво е добавено или променено;
сумарният патч налагаме на live.

Деплойваме 1000+ приложения с Helm, така че всъщност живеем с 2-way merge. Въпреки това, той има редица проблеми, които решихме с нашите патчове, които помагат на Helm да работи нормално.

Реален статус на изтеглянето

След като на поредно събитие нашата CI-система генерира нова конфигурация за Kubernetes, тя я предава за прилагане (apply) в клъстера — с помощта на Helm или kubectl apply. Следва вече описаният N-way merge, на което Kubernetes API одобрително отговаря на CI-системата, а тя — на своя потребител.

Но има огромен проблем: всъщност успешното прилагане не означава успешно изтегляне.Ако Kubernetes е разпознал какви промени трябва да бъдат приложени и ги прилага — ние все още не знаем какъв ще бъде резултатът. Например, обновление и рестарт на pod’овете във frontend’а може да мине успешно, а в backend’а — не, и ще получим различни версии на стартираните образи на приложението.

За да се направи всичко правилно, в тази схема е необходимо допълнително звено — специален тракер, който ще получава информация от Kubernetes API за статуса и ще я предава за по-нататъшен анализ на реалната ситуация. Създадохме библиотека с отворен код на Go — kubedog (вж. нейното анонсиране тук.), — която решава този проблем и е вградена в werf.

Поведението на този тракер на ниво werf се настройва с помощта на анотации, които се поставят на Deployments или StatefulSets. Основната анотация — fail-mode — разбира следните стойности:

IgnoreAndContinueDeployProcess — игнориране на проблемите при внедряването на този компонент и продължаване на деплоя;
FailWholeDeployProcessImmediately — грешка в този компонент спира процеса на деплой;
HopeUntilEndOfDeployProcess — надежда, че този компонент ще заработи до края на деплоя.

Например, такава комбинация от ресурси и стойности на анотация fail-mode:

Когато внедряваме за първи път, базата данни (MongoDB) все още може да не е готова — Deployment-ите ще паднат. Но можем да изчакаме момента, в който тя се стартира, и деплой все пак ще премине.

Има още две анотации за kubedog в werf:

failures-allowed-per-replica — брой разрешени падения на всяка реплика;
show-logs-until — регулира момента, до който werf показва (в stdout) логовете от всички внедрявани pod-ове. По подразбиране това е PodIsReady (за да игнорираме съобщенията, които едва ли ще ни трябват, когато на pod започне да идва трафик), но са допустими също стойности ControllerIsReady и EndOfDeploy.

Какво още искаме от деплоя?

Освен вече описаните два пункта, бихме искали:

да виждаме логовете — и то само нужните, а не всичките.
да следим прогреса, защото ако job „мълчи“ няколко минути, е важно да разберем какво се случва;
да имаме автоматичен откат в случай, че нещо се обърка (поради това е критично да знаем реалния статус на деплоя). Процесът на внедряване трябва да бъде атомарен: или преминава до края, или всичко се връща в предишно състояние.

Итог

Като компания, за да реализираме всички описани нюанси на различните етапи на доставка (build, publish, deploy), ни е достатъчна CI-система и утилита. werf.

В заключение:

С помощта на werf напреднахме съществено в решаването на редица проблеми на DevOps инженери и ще се радваме, ако по-широкото общество поне опита тази утилита в действие. Да постигнем добри резултати заедно ще бъде по-лесно.