🥇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 (или натискания на бутони) и задейства всички определени етапи: сборка, публикуване, разгръщане, тестване.

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

Тъй като имаме неизменна инфраструктура (immutable infrastructure), образът на приложението, който се използва на всички етапи (staging, production и т.н.) трябва да бъде един. Повече за това и с примери съм говорил тук.
Тъй като следваме подхода инфраструктура като код (IaC), кодът на приложението, инструкциите за неговото събиране и разгръщане трябва да се намират в именно един репозиторий. Повече за това — вижте в същия доклад.
Верига на доставката (delivery) обикновено виждаме следното: приложението е събрано, тествано, пуснато на пазара (етап release) и всичко — доставката е извършена. Но всъщност потребителят получава това, което сте издали, не в момента, в който вие го доставяте в production, и когато той е успял да влезе там и този 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, който по своята природа е неизменен (неизменен), до образа Docker, който трябва да остане същият.

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

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

Първата е проста git tag. Имаме регистър с образ, тагиран като 1.0. В Kubernetes имаме stage и production, където този образ е качен. В Git правим комити и в някакъв момент слагаме таг 2.0. Събираме го по инструкциите от репозитория и го поставяме в регистъра с таг 2.0. Пускаме го на stage и, ако всичко е наред, след това на 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-образа.

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

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

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

Тагиране в werf

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

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

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

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

Почистване на registry

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

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

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

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

До какво стигнахме в 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’ите във фронтенда може да премине успешно, а в бекенда — не, и ще получим различни версии на стартираните образи на приложението.. Если Kubernetes понял, что за изменения надо применить, применяет его — мы ещё не знаем, что получится в результате. Например, обновление и рестарт pod’ов во frontend’е может пройти успешно, а в backend’е — нет, и мы получим разные версии запущенных образов приложения.

За да направим всичко правилно, в тази схема се налага допълнителен елемент — специален тракер, който ще получава информация за статуса от Kubernetes API и ще я предава за по-нататъшен анализ на реалното състояние на нещата. Създадохме Open Source библиотека на 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 инженерите и ще се радваме, ако по-широката общност поне опита тази утилита на практика. Да постигнем добър резултат заедно ще бъде по-лесно.