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

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

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

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

Непрекъсната доставка с Docker

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

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

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

Основен модел на разгръщане

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

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

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

Ние се обобщи основен модел на разгръщане нови версии, като се вземат предвид следните фактори:

1. Първоначално старата версия на приложението работи в първия контейнер.
2. След това новата версия се разгръща и „загрява“ във втори контейнер. Трябва да се отбележи, че самата тази нова версия може да носи не само актуализиран код на приложението, но и всяка негова зависимост, както и системни компоненти (например нова версия на OpenSSL или цялата дистрибуция).
3. Когато новата версия е напълно готова да обслужва заявки, трафикът се превключва от първия контейнер към втория.
4. Старата версия вече може да бъде спряна.

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

Последната първа препоръка звучи като нещо, в което дори капитанът не може да намери грешка: „[при организиране на непрекъсната доставка с Docker] Използвайте Docker [и разберете какво дава]" Не забравяйте, че това не е сребърен куршум, който ще реши всеки проблем, а инструмент, който осигурява чудесна основа.

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

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

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

Тяхната обща същност се свежда до факта, че е необходимо пълното съответствие на използваните среди (както и липсата на човешкия фактор). Как можем да гарантираме възпроизводимост? Направете Docker изображения базирани на код от Git и след това да ги използвате за всяка задача: на тестови сайтове, в производство, на локални машини на програмисти... В същото време е важно да се сведат до минимум действията, които се извършват след сглобяване на изображението: колкото по-просто е, толкова по-малко вероятно е да има грешки.

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

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

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

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

Docker изображения, комуникация с Git

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

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

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

DAPP

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

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

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

Kubernetes

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

За внедряване Kubernetes предлага:

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

Тъй като 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