Практики за континуирана испорака со Docker (преглед и видео)

Ќе го започнеме нашиот блог со публикации базирани на најновите говори на нашиот технички директор дистол (Дмитриј Столјаров). Сите тие се одржаа во 2016 година на различни професионални настани и беа посветени на темата DevOps и Docker. Веќе имаме едно видео од состанокот на Докер Москва во канцеларијата на Badoo објавено Онлајн. Новите ќе бидат придружени со написи кои ја пренесуваат суштината на извештаите. Така…

31 мај на конференцијата RootConf 2016 година, што се одржа како дел од фестивалот „Руски интернет технологии“ (RIT++ 2016), делот „Континуирано распоредување и распоредување“ беше отворен со извештајот „Најдобри практики за континуирана испорака со Docker“. Ги сумираше и систематизираше најдобрите практики за градење процес на континуирана испорака (CD) со користење на Docker и други производи со отворен код. Ние работиме со овие решенија во производството, што ни овозможува да се потпреме на практично искуство.

Ако имате можност да поминете еден час видео од извештајот, препорачуваме да го погледнете во целост. Инаку, подолу е главното резиме во текстуална форма.

Континуирана испорака со Docker

Под Континуирана испорака го разбираме синџирот на настани како резултат на кој кодот на апликацијата од складиштето Git прво доаѓа до производство, а потоа завршува во архивата. Изгледа вака: Git → Build → Test → Release → Operate.

Поголемиот дел од извештајот е посветен на фазата на изградба (склопување на апликацијата), а темите за објавување и функционирање се накратко допрени. Ќе зборуваме за проблеми и обрасци кои ви дозволуваат да ги решите, а специфичните имплементации на овие обрасци може да бидат различни.

Зошто воопшто е потребен Докер овде? Не за џабе решивме да зборуваме за практиките за континуирана испорака во контекст на оваа алатка со отворен код. Иако целиот извештај е посветен на неговата употреба, многу причини се откриваат кога се разгледува главниот образец на пуштање на кодот на апликацијата.

Главна шема на пуштање

Значи, кога ќе објавиме нови верзии на апликацијата, сигурно ќе се соочиме со проблем со застојот, генерирана при префрлување на производниот сервер. Сообраќајот од старата верзија на апликацијата на новата не може веднаш да се префрли: прво мора да се увериме дека новата верзија не само што е успешно преземена, туку и „загреана“ (т.е. целосно подготвена да опслужува барања).

Така, некое време двете верзии на апликацијата (стара и нова) ќе работат истовремено. Што автоматски води до конфликт на споделени ресурси: мрежа, датотечен систем, IPC, итн. Со Docker, овој проблем лесно се решава со извршување на различни верзии на апликацијата во посебни контејнери, за кои изолацијата на ресурсите е загарантирана во истиот хост (сервер/виртуелна машина). Се разбира, можете да поминете со некои трикови без воопшто изолација, но ако постои готова и удобна алатка, тогаш постои спротивна причина - да не ја занемарите.

Контејнеризацијата обезбедува многу други придобивки кога се користи. Секоја апликација зависи од специфична верзија (или опсег на верзии) преведувач, достапност на модули/екстензии итн., како и нивните верзии. И ова се однесува не само на непосредната извршна околина, туку и на целата околина, вклучително и системски софтвер и неговата верзија (до користената дистрибуција на Linux). Поради фактот што контејнерите содржат не само код за апликација, туку и претходно инсталиран системски и апликативен софтвер на потребните верзии, можете да заборавите на проблемите со зависностите.

Да генерализираме шаблон за главна пуштање нови верзии земајќи ги предвид следните фактори:

1. Отпрвин, старата верзија на апликацијата работи во првиот контејнер.
2. Новата верзија потоа се вала и се „загрева“ во втор контејнер. Вреди да се одбележи дека самата оваа нова верзија може да носи не само ажуриран код на апликацијата, туку и која било нејзина зависност, како и компоненти на системот (на пример, нова верзија на OpenSSL или целата дистрибуција).
3. Кога новата верзија е целосно подготвена да опслужува барања, сообраќајот се префрла од првиот контејнер на вториот.
4. Старата верзија сега може да се запре.

Овој пристап на распоредување на различни верзии на апликацијата во посебни контејнери обезбедува уште една погодност - брзо враќање назад на старата верзија (на крајот на краиштата, доволно е да го префрлите сообраќајот во саканиот контејнер).

Последната прва препорака звучи како нешто на што дури ни капетанот не можеше да му замери: „[при организирање на континуирана испорака со Docker] Користете Docker [и разберете што дава тоа]" Запомнете, ова не е сребрен куршум што ќе го реши секој проблем, туку алатка која обезбедува прекрасна основа.

Репродуктивност

Под „репродуктивност“ мислиме на генерализиран сет на проблеми што се среќаваат при работа со апликации. Зборуваме за такви случаи:

• Скриптите проверени од одделот за квалитет за инсценирање мора прецизно да се репродуцираат во производството.
• Апликациите се објавуваат на сервери кои можат да примаат пакети од различни огледала на складиштето (со текот на времето тие се ажурираат, а со нив и верзиите на инсталираните апликации).
• „Сè работи за мене локално! (...и на програмерите не им е дозволено да се произведуваат.)
• Треба да проверите нешто во старата (архивирана) верзија.
• ...

Нивната општа суштина се сведува на фактот дека е неопходна целосна усогласеност на употребените средини (како и отсуството на човечки фактор). Како можеме да гарантираме репродуктивност? Направете Docker слики врз основа на код од Git, а потоа користете ги за која било задача: на тест места, во производство, на локални машини на програмери... Истовремено, важно е да се минимизираат дејствата што се изведуваат по склопување на сликата: колку е поедноставно, толку е помала веројатноста да има грешки.

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

Ако барањата за инфраструктура (достапност на софтвер за сервер, неговата верзија итн.) не се формализирани и „програмирани“, тогаш објавувањето на кое било ажурирање апликација може да резултира со катастрофални последици. На пример, при инсценирањето веќе сте се префрлиле на PHP 7.0 и соодветно сте го преработиле кодот - тогаш неговото појавување во производство со некој стар PHP (5.5) сигурно ќе изненади некого. Можеби нема да заборавите на голема промена во верзијата на преведувачот, но „ѓаволот е во деталите“: изненадувањето може да биде во мало ажурирање на каква било зависност.

Пристап за решавање на овој проблем е познат како IaC (Инфраструктура како код, „инфраструктура како код“) и вклучува складирање на барањата за инфраструктура заедно со кодот на апликацијата. Користејќи го, програмерите и специјалистите за DevOps можат да работат со истото складиште за апликации Git, но на различни делови од него. Од овој код, во Git се креира слика на Docker, во која апликацијата е распоредена земајќи ги предвид сите специфики на инфраструктурата. Едноставно кажано, скриптите (правилата) за составување слики треба да бидат во исто складиште со изворниот код и да се спојат заедно.

Во случај на повеќеслојна архитектура на апликации - на пример, постои nginx, која стои пред апликација која веќе работи во контејнер на Docker - Docker сликите мора да се креираат од кодот во Git за секој слој. Тогаш првата слика ќе содржи апликација со преведувач и други „блиски“ зависности, а втората слика ќе го содржи upstream nginx.

Докер слики, комуникација со Git

Сите слики на Docker собрани од Git ги делиме во две категории: привремени и пуштени. Привремени слики означени со името на гранката во Git, може да се пребришат од следниот commit и се пуштаат само за преглед (не за производство). Ова е нивната клучна разлика од оние за ослободување: никогаш не знаете која специфична обврска е во нив.

Има смисла да се собираат во привремени слики: главната гранка (можете автоматски да ја префрлите на посебна локација за постојано да ја гледате тековната верзија на мастер), гранки со изданија, гранки на специфични иновации.

Откако прегледот на привремените слики дојде до потребата за преведување во производство, програмерите ставаат одредена ознака. Автоматски се собира по ознака ослободи слика (нејзината ознака кореспондира со ознаката од Git) и е префрлена на сцена. Ако е успешно верификуван од одделот за квалитет, тој оди во производство.

дап

Сè што е опишано (распоредување, склопување слики, последователно одржување) може да се имплементира независно со користење на Bash скрипти и други „импровизирани“ алатки. Но, ако го направите ова, тогаш во одреден момент имплементацијата ќе доведе до голема сложеност и слаба контрола. Разбирајќи го ова, дојдовме да создадеме сопствена специјализирана алатка Workflow за изградба на CI/CD - дап.

Неговиот изворен код е напишан во Руби, со отворен код и објавен на GitHub. За жал, документацијата во моментов е најслабата точка на алатката, но ние работиме на тоа. А за дапот ќе пишуваме и зборуваме повеќе пати, бидејќи ... Искрено не можеме да дочекаме да ги споделиме неговите способности со целата заинтересирана заедница, но во меѓувреме, испратете ги вашите проблеми и повлекувајте барања и/или следете го развојот на проектот на GitHub.

Ажурирано на 13 август 2019 година: моментално проект дап преименувана во верф, неговиот код е целосно препишан во Go, а неговата документација е значително подобрена.

Кубернети

Друга готова алатка со отворен код која веќе доби значајно признание во професионалната средина е Кубернети, кластер за управување со Docker. Темата за неговата употреба во работењето на проекти изградени на Docker е надвор од опсегот на извештајот, така што презентацијата е ограничена на преглед на некои интересни карактеристики.

За воведување, Kubernetes нуди:

• сонда за подготвеност - проверка на подготвеноста на нова верзија на апликацијата (за да се префрли сообраќај на неа);
• тркалање ажурирање - последователно ажурирање на сликата во кластер од контејнери (исклучување, ажурирање, подготовка за лансирање, префрлување сообраќај);
• синхроно ажурирање - ажурирање на слика во кластер со различен пристап: прво на половина од контејнерите, потоа на останатите;
• изданија на канари - лансирање на нова слика на ограничен (мал) број контејнери за следење на аномалиите.

Бидејќи Continuous Delivery не е само издавање на нова верзија, Kubernetes има голем број можности за последователно одржување на инфраструктурата: вграден мониторинг и логирање за сите контејнери, автоматско скалирање итн. Сето ова веќе функционира и само се чека правилното имплементација во вашите процеси.

Конечни препораки

1. Користете Docker.
2. Креирајте Docker слики од апликации за сите ваши потреби.
3. Следете го принципот „Инфраструктурата е код“.
4. Поврзете го Git со Docker.
5. Регулирајте го редоследот на пуштање.
6. Користете готова платформа (Kubernetes или друга).

Видеа и слајдови

Видео од настапот (околу еден час) објавено на YouTube (самиот извештај започнува од 5-та минута - следете го линкот за да играте од овој момент).

Презентација на извештајот:

PS

Други извештаи за оваа тема на нашиот блог:

• «werf - нашата алатка за CI / CD во Kubernetes (преглед и видео извештај)» (Дмитриј Столјаров; 27 мај 2019 година на DevOpsConf);
• «Бази на податоци и Kubernetes» (Дмитриј Столјаров; 8 ноември 2018 година на HighLoad++);
• «CI/CD Најдобри практики со Kubernetes и GitLab» (Дмитриј Столјаров; 7 ноември 2017 година на HighLoad++);
• «Нашето искуство со Kubernetes во мали проекти» (Дмитриј Столјаров; 6 јуни 2017 година на RootConf).

Извор: www.habr.com