🥇Практики Continuous Delivery с Docker (преглед и видео)

Свой блог ще започнем с публикации, създадени по мотиви от последните изяви на нашия технически директор distol (Дмитрий Столяров). Всички те се състояха през 2016 година на различни професионални мероприятия и бяха посветени на темата DevOps и Docker. Едно видео, от срещата Docker Moscow в офиса на Badoo, вече публикувахме на сайта. Новите ще бъдат придружени от статии, предаващи същността на докладите. И така…

31 май на конференцията RootConf 2016, провеждаща се като част от фестивала „Руски интернет технологии“ (РИТ++ 2016), секцията „Непрекъснато разгръщане и деплой“ беше открита с доклад „Най-добри практики за Continuous Delivery с Docker“. В него бяха обобщени и систематизирани най-добрите практики за изграждане на процеса на Continuous Delivery (CD) с използване на Docker и други Open Source продукти. С тези решения работим в продукция, което ни позволява да се опираме на практически опит.

Ако имате възможност да отделите час на видеото с доклада, препоръчваме да го гледате изцяло. В противен случай – по-долу е представен основният резюме в текстов формат.

Continuous Delivery с Docker

Под Continuous Delivery разбираме веригата от мероприятия, в резултат на която кодът на приложението от Git хранилището първо достига продукция, а след това попада в архив. Изглежда така: Git → Build (сглобяване) → Test (тестиране) → Release (релиз) → Operate (последваща поддръжка).

По-голямата част от доклада е посветена на етапа build (сглобяване на приложението), а темите release и operate са засегнати в обобщен вид. Ще стане дума за проблемите и шаблоните, които позволяват тяхното решаване, а конкретните реализации на тези шаблони могат да бъдат различни.

Защо тук изобщо е необходим Docker? Не просто така решихме да говорим за практиките на Continuous Delivery в контекста на този Open Source инструмент. Въпреки че целият доклад е посветен на него, много причини се разкриват още при разглеждането на основния шаблон за внедряване на кода на приложението.

Основен шаблон за внедряване

И така, при внедряване на нови версии на приложението неизменно се сблъскваме с проблема на простоя, който се образува по време на превключването на продукционния сървър. Трафикът от старата версия на приложението към новата не може да се прехвърля мигновено: предварително трябва да се уверим, че новата версия не само е успешно пусната, но и е "подгрята" (т.е. напълно готова за обслужване на запитвания).

Така, известно време и двете версии на приложението (стара и нова) ще работят едновременно. Което автоматично води до конфликт на общи ресурси: мрежа, файлове, IPC и т.н. С Docker този проблем лесно се разрешава, като се стартират различни версии на приложението в отделни контейнери, за които е гарантирана изолация на ресурсите в рамките на един хост (сървър/виртуална машина). Разбира се, може да се разчита на някои хитрини и без изолация, но ако има готов и удобен инструмент, то има и контрарезон — да не се пренебрегва.

Контейнеризацията предлага много други предимства при деплоя. Всяко приложение зависи от определена версия (или диапазон версии) интерпретатора, наличието на модули/разширения и т.н., както и техните версии. И това важи не само за непосредствената изпълнителна среда, но и за цялата обкръжаваща среда, включително системен софтуер и неговите версии (включително до използвания Linux-дистрибутив). Благодарение на факта, че контейнерите съдържат не само кода на приложенията, но и предварително инсталиран системен и приложен софтуер в нужните версии, можете да забравите за проблемите с зависимостите.

Обобщим основния шаблон на издаване на нови версии, вземайки предвид посочените фактори:

Първо, старата версия на приложението работи в първия контейнер.
След това новата версия се издава и "загрява" във втория контейнер. Забележително е, че самата нова версия може да съдържа не само обновен код на приложението, но и всякакви негови зависимости, както и системни компоненти (например, нова версия на OpenSSL или целия дистрибутив).
Когато новата версия е напълно готова да обслужва заявките, трафикът се прехвърля от първия контейнер на втория.
Сега старата версия може да бъде спряна.

Такъв подход с разгръщането на различни версии на приложението в отделни контейнери предлага още едно удобство — бързо възстановяване на старата версия (все пак е достатъчно да преместите трафика на нужния контейнер).

Заключителната първа препоръка звучи така, че дори Капитанът няма как да възрази: "[при организиране на Continuous Delivery с Docker] Използвайте Docker [и разберете какво предлага]". Помнете, че не е "сребърна куршумица", която решава всякакви проблеми, а инструмент, който предлага отлична основа.

Възпроизводимост

Под „възпроизводимост“ разбираме обобщен набор от проблеми, с които се сблъскваме при експлоатацията на приложения. Става въпрос за такива случаи:

Сценарии, проверени от отдела за качество на staging, трябва точно да се възпроизвеждат в production.
Приложенията се публикуват на сървъри, които могат да получават пакети от различни огледални репозитории (с течение на времето те се обновяват, а заедно с тях и версиите на инсталираните приложения).
„При мен локално всичко работи!“ (… и разработчиците не са допуснати до production.)
Необходимо е да се провери нещо в стара (архивна) версия.
…

Общата им същност се свежда до това, че е необходимо пълно съответствие на използваните среди (както и отсъствие на човешки фактор). Как да гарантираме възпроизводимост? Да се правят Docker-образи на база кода от Git и след това да се използват за каквито и да е задачи: на тестови площадки, в production, на локални машини на програмисти… При това е важно минимизиране на действията, които се извършват след по време на изграждането на образа: колкото по-просто — толкова по-малка вероятност за грешки.

Инфраструктурата е код

Ако изискванията към инфраструктурата (наличие на сървърно ПО, негови версии и т.н.) не се формализират и не „програмират“, всяко обновление на приложението може да завърши с неприятни последици. Например, на staging вече сте преминали на PHP 7.0 и сте пренаписали кода съответно — тогава появата му на production с някаква стара версия на PHP (5.5) непременно ще изненада някого. Макар да не трябва да забравяте за голямото изменение на версията на интерпретатора, „дяволът се крие в детайлите“: изненада може да се крие в малко обновление на всяка зависимост.

Подходът, който решава този проблем, е известен като IaC (Infrastructure as Code, „инфраструктура като код“) и предполага съхраняване на изискванията към инфраструктурата заедно с кода на приложението. С него разработчиците и DevOps специалистите могат да работят с един Git репозиторий на приложението, но над различни негови части. От този код в Git се създава Docker образ, в който приложението е разположено с оглед на цялата специфика на инфраструктурата. По-просто казано, скриптовете (правилата) за изграждане на образи трябва да се намират в един репозиторий с изходния код и заедно да се сливат.

В случай на многостепенна архитектура на приложението — например, nginx, който стои пред приложението, вече стартирано в Docker контейнер — Docker образите трябва да се създават от кода в Git за всеки слой. Тогава в първия образ ще бъде приложението с интерпретатор и други "ближайши" зависимости, а във втория — по-горният nginx.

Docker образи, свързани с Git

Всички Docker образи, събрани от Git, разделяме на две категории: временни и релийзни. Временни образи се етикетират по името на клона в Git, могат да бъдат презаписвани с всеки следващ комит и се прилагат само за предварителен преглед (не за продукция). В това е основната им разлика от релийзните: никога не знаете кой конкретен комит съдържат.

Има смисъл да се събират във временни образи: клона master (може да се прилага автоматично на отделна площадка, за да се вижда постоянно текущата версия на master), клоните с релийзи, клоните на конкретни нововъведения.

След като предварителният преглед на временните образи достигне необходимостта от превод в продукция, разработчиците поставят определен етикет. На базата на етикета автоматично се събира релийзен образ (етикетът му съответства на етикет от Git) и се прилага на staging. В случай на успешна проверка от отдела по качество, той преминава в продукция.

dapp

Всичко описано (прилагане, събиране на образи, последваща поддръжка) може да бъде реализирано самостоятелно с помощта на Bash скриптове и други "подръчни" средства. Но ако се прави така, в определен момент реализацията ще доведе до голяма сложност и лоша управляемост. Разбирайки това, ние създадохме своя специализирана Workflow утилита за изграждане на CI/CD — dapp.

Неин исходен код е написан на Ruby, е открит и публикуван на GitHub. За съжаление, документацията в момента е най-слабата страна на инструмента, но работим по нея. И още неведнъж ще напишем и разкажем за dapp, тъй като искрено не можем да чакаме да споделим възможностите му със заинтересованото общество, а засега изпращайте своите проблеми и pull requests и/или следете развитието на проекта на GitHub.

Обновено на 13 август 2019 г.: в момента проектът dapp е преименуван на werf, неговият код е изцяло преписан на Go, а документацията е значително подобрена.

Kubernetes

Друг готов инструмент с открит код, който вече е получил значително признание в професионалната среда, е Kubernetes, клъстер за управление на Docker. Темата за използването му в експлоатацията на проекти, изградени на Docker, надхвърля кръга на изложението, затова представянето е ограничено до преглед на някои интересни възможности.

За пускането Kubernetes предлага:

readiness probe — проверка на готовността на новата версия на приложението (за пренасочване на трафика към нея);
rolling update — последователно обновление на образа в клъстера от контейнери (изключване, обновление, подготовка за пускане, пренасочване на трафика);
synchronous update — обновление на образа в клъстера с друг подход: първо на половината контейнери, след това на останалите;
canary releases — стартиране на нов образ на ограничен (малък) брой контейнери за наблюдение на аномалии.

Тъй като Continuous Delivery не е само освобождаване на нова версия, в Kubernetes има редица възможности за последваща поддръжка на инфраструктурата: вградена мониторингова система и логиране за всички контейнери, автоматично мащабиране и др. Всичко това вече работи и просто очаква компетентно внедряване в вашите процеси.