Процес на разработка и тестване с Docker и Gitlab CI

Представям ви разискването на доклада на Александър Сигачев от Inventos "Процес на разработка и тестване с Docker + Gitlab CI"

Тези, които започват да внедряват процеса на разработка и тестване на база Docker + Gitlab CI, често задават основни въпроси. От къде да започнат? Как да организират процеса? Как да тестват?

Този доклад е ценен, тъй като структурирано обяснява процеса на разработка и тестване, използвайки Docker и Gitlab CI. Самият доклад е от 2017 година. Смятам, че от него може да се извлекат основни принципи, методология, идеи и опит във употребата.

На когото му е интересно, моля под кат.

Казвам се Александър Сигачев. Работя в компанията Inventos. Ще споделя опита си с Docker и как постепенно го внедряваме в проектите на компанията.

Тема на доклада: Процес на разработка с използване на Docker и Gitlab CI.

Това е моят втори доклад за Docker. При първия доклад използвахме Docker само в Development на машините на разработчиците. Броят на служителите, използващи Docker, беше около 2-3 души. Постепенно натрупахме опит и постигнахме малко напредък. Линк към нашия първи доклад.

Какво ще включва този доклад? Ще споделим опита си за проблемите, които срещнахме, и как ги решавахме. Не всичко беше перфектно, но ни позволи да напредваме.

Нашият девиз: dockerize everything we can reach.

Какви проблеми решаваме?

Когато в компанията има няколко екипа, програмистът става общ ресурс. Понякога програмистът се изтегля от един проект и се назначава за някакво време в друг проект.

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

Обикновено, ако започвате от нулата, документалната поддръжка на проекта е оскъдна. Информацията за настройките я имат само по-опитните. Служителите сами настройват работното си място за един-два дни. За да ускорим този процес, използвахме Docker.

Следващата причина е стандартизацията на настройките в Development. По мое мнение, разработчиците винаги показват инициатива. Във всеки пети случай се въвежда персонализиран домейн, например vasya.dev. Съседът Петя, който седи до него, има домейн petya.dev. Те разработват сайт или компонент на системата, използвайки тези домейни.

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

Същото се случва и с настройките на базата данни. Някой не се замисля за сигурността и работи с празна парола за потребител root. Някой друг на етапа на инсталацията на MySQL е поискал парола, която е била 123. Често се случва конфигурацията на базата данни постоянно да се променя в зависимост от commit на разработчика. Някой е поправил, някой не е поправил конфигурацията. Има случаи, когато извеждахме тестова конфигурация в .gitignore и всеки разработчик трябваше да инсталира базата данни. Това затрудняваше стартирането. Освен всичко друго, е необходимо да помним за базата данни. Базата данни трябва да бъде инициирана, трябва да бъде зададена парола, трябва да бъде зададен потребител, да бъде създадена таблица и т.н.

Още един от проблемите е различните версии на библиотеките. Често разработчикът работи по различни проекти. Има Legacy проект, който започна преди пет години (от 2017 година — забел. редактора). При старта започнахме с MySQL 5.5. Има и съвременни проекти, където се стараем да внедряваме вече по-съвременни версии на MySQL, например 5.7 или по-нови (през 2017 година — забел. редактора).

Който работи с MySQL знае, че тези библиотеки водят със себе си зависимости. Достатъчно проблематично е да се стартират две бази заедно. Най-малкото, старите клиенти е проблем да бъдат свързани към новата база данни. Това от своя страна поражда няколко проблема.

Следващият проблем е, когато разработчикът работи на локалната машина, той използва локални ресурси, локални файлове, локална RAM. Цялото взаимодействие по време на разработката на решенията се извършва в рамките на това, че всичко работи на една машина. Пример е, когато в продукция имаме 3 backend сървъра, а разработчикът запазва файлове в кореновата папка, от която nginx взема файловете за отговор на заявките. Когато такъв код попадне в продукция, се оказва, че файлът присъства само на един от трите сървъра.

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

Frontend разработчик, работещ на JS, практически не влияе на Backend. Backend разработчикът от своя страна разработва, в нашия случай, Ruby on Rails и не пречи на Frontend. Взаимодействието се осъществява чрез API.

Като бонус, с помощта на Docker успяхме да оптимизираме ресурсите на Staging. Всеки проект, поради своята специфика, изискваше определени настройки. Физически трябваше да отделяме или по един виртуален сървър и да ги конфигурираме отделно, или да споделяме някаква променлива среда, което можеше да влияе на проектите в зависимост от версиите на библиотеките.

Инструменти. Какво използваме?

• Самият Docker. В Dockerfile се описват зависимостите на едно приложение.
• Docker-compose — това е свързване, което обединява няколко наши Docker приложения.
• GitLab използваме за съхранение на изходния код.
• GitLab-CI използваме за системна интеграция.

Докладът съдържа две части.

Първата част ще разкаже как стартирахме Docker на машините на разработчиците.

Втората част ще разкаже как взаимодействаме с GitLab, как стартираме тестове и как развиваме на Staging.

Docker — това е технология, която позволява (използвайки декларативен подход) да опишем необходимите компоненти. Това е пример за Dockerfile. Тук обявяваме, че наследяваме от официалния Docker образ Ruby:2.3.0. Той съдържа инсталиран Ruby версия 2.3. Установяваме необходимите библиотеки за компилация и NodeJS. Описваме, че създаваме каталог. /appНазначаваме каталога app за работна директория. В този каталог поставяме необходимия минимален Gemfile и Gemfile.lock. След това изпълняваме компилация на проектите, които инсталират зависимостите на този образ. Указваме, че контейнерът ще бъде готов да слуша на външен порт 3000. Последната команда — това е командата, която директно стартира нашето приложение. Ако изпълним командата за стартиране на проекта, приложението ще се опита да стартира и ще изпълни указаната команда.

Това е минимален пример на docker-compose файл. В този случай показваме как се свързват два контейнера — сервизът за базата данни и уеб сервизът. В повечето случаи нашите уеб приложения изискват за backend съхранение на данни, което е база данни. Тъй като използваме MySQL, примерът е с MySQL — но нищо не пречи да се използва друга база данни (PostgreSQL, Redis).

Вземаме образ на MySQL 5.7.14 от официалния източник в Docker hub без промени. Образът, който отговаря за нашето уеб приложение, събираме от текущата директория. При първото стартиране той ще създаде образа. След това стартира командата, която тук изпълняваме. Ако се върнем назад, ще видим, че е определена команда за стартиране чрез Puma. Puma е сервиз, написан на Ruby. Във втория случай я пренаписваме. Тази команда може да бъде произволна в зависимост от нашите нужди или задачи.

Също така описваме как да пробием порта на нашата хост машини разработчик от 3000 на 3000 порта на контейнера. Това се изпълнява автоматично с помощта на iptables и механизма, който е заложен в Docker.

Разработчикът може както и преди да се обърне към всеки достъпен IP адрес, например 127.0.0.1 локален или външен IP адрес на машината.

Последният ред казва, че контейнерът web зависи от контейнера db. Когато стартираме контейнера web, преди това docker-compose ще стартира базата данни. След стартиране на базата данни (в действителност — след стартиране на контейнера! Готовността на БД не се гарантира) ще стартира приложението, нашия backend.

Това позволява да избегнем грешки, когато базата данни не е стартирана и спестява ресурси, когато спираме контейнера на базата данни, освобождавайки ресурси за други проекти.

Какво ни дава използването на контейнеризация на базата данни в проекта. Установяваме версията на MySQL за всички разработчици. Това позволява да избегнем някои грешки, които могат да се появят при различия в версиите, когато се променя синтаксисът, конфигурацията, настройките по подразбиране. Това позволява да посочим общи hostname за базата данни, потребителско име, парола. Отдалечаваме се от зоологическия парк от имена и конфликти в конфигурационните файлове, които бяха по-рано.

Имаме възможността да използваме по-оптимална конфигурация за средата на Development, която ще се различава от подразбиращата се. MySQL по подразбиране е настроен за слаби машини и производителността му от кутията е много ниска.

Docker позволява да използваме интерпретатор Python, Ruby, NodeJS, PHP в нужната версия. Отпада необходимостта от използването на мениджър на версии. Преди това използвахме rpm пакет за Ruby, който позволяваше смяна на версията в зависимост от проекта. Също така, благодаря на Docker контейнера, плавно мигрираме кода и го версионираме заедно със зависимостите. Нямаме проблем да разберем версията на интерпретатора и кода. За обновяване на версията е необходимо да свалим стария контейнер и да пуснем новия. Ако нещо не върви, можем да свалим новия контейнер и да пуснем стария.

След изграждането на образа, контейнерите както в Development, така и в Production ще бъдат идентични. Това е особено актуално за големи инсталации.

На фронтенда използваме JavaScript и NodeJS.

В момента последният ни проект е на ReactJS. Разработчикът стартира всички контейнери и разработва, използвайки hot-reload.

След това стартира задача за изграждане на JavaScript и кодът, събран в статиката, се предоставя чрез nginx, спестявайки ресурси.

Тук представям схемата на последния ни проект.

Какви задачи решавахме? Изправихме се пред необходимостта да изградим система, с която взаимодействат мобилни устройства. Те получават данни. Една от възможностите е да изпратим push уведомления на устройството.

Какво направихме за това?

Разделихме приложението на такива компоненти като: администраторска част на JS, бекенд, който работи чрез REST интерфейс под Ruby on Rails. Бекендът взаимодейства с базата данни. Резултатът, който се генерира, се предоставя на клиента. Админ панелът взаимодейства с бекенда и базата данни по REST интерфейса.

Също така, имахме необходимост да изпращаме Push уведомления. Преди това имахме проект, в който беше реализиран механизъм, който отговаря за доставката на уведомления до мобилните платформи.

Разработихме такава схема: операторът от браузъра взаимодейства с админ панела, админ панелът взаимодейства с бекенда, поставя се задача за изпращане на Push уведомления.

Push уведомленията взаимодействат с друг компонент, реализиран на NodeJS.

Опашките се образуват и уведомленията се изпращат по своя механизъм.

Тук са изрисувани две бази данни. В момента използваме 2 независими бази данни чрез Docker, които не са свързани помежду си. Единственото, което ги свързва, е общата виртуална мрежа, а физическите данни се съхраняват в различни директории на компютъра на разработчика.

Същото, но в цифри. Важно е повторното използване на кода.

Ако до сега говорехме за повторно използване на кода под формата на библиотеки, в този пример нашият сервис, отговорен за Push уведомленията, се използва като напълно независим сървър. Той предоставя API и взаимодейства с новата ни разработка.

По това време използвахме 4 версия на NodeJS. Сега (през 2017 година — забележка на редактора) в новите разработки използваме 7 версия на NodeJS. Няма проблем да използваме нови версии на библиотеките в новите компоненти.

При необходимост можем да направим рефакторинг и да увеличим версията на NodeJS за сервиса за Push уведомления.

А ако можем да запазим съвместимост по API, ще можем да го заменим в други проекти, които сме използвали преди.

Какво е необходимо, за да добавим Docker? Добавяме в нашия репозиторий Dockerfile, който описва необходими зависимости. В този пример компонентите са разпределени логически. Това е минималният набор за backend-разработчик.

При създаване на нов проект създаваме Dockerfile, описваме необходимата екосистема (Python, Ruby, NodeJS). В docker-compose описваме необходимата зависимост — база данни. Описваме, че е необходима база от определена версия, и че данните трябва да се съхраняват в зададени директории.

Използваме отделен трети контейнер с nginx за предоставяне на статични файлове. Предвидена е възможността за качване на изображения. Backend изпраща изображенията в предварително подготвена директория, която също е монтирана в контейнера с nginx, който предоставя статичните файлове.

За да съхраните конфигурацията на nginx и mysql, добавихме папка Docker, в която съхраняваме необходимите конфигурации. Когато разработчикът направи git clone на репозитория на своя компютър, той получава проект, готов за локална разработка. Не възниква въпрос какъв порт или какви настройки да прилага.

След това имаме няколко компонента: админ, информ-API, push-уведомления.

За да стартираме всичко това, създадохме още едно хранилище, което нарекохме dockerized-app. В момента използваме няколко хранилища за всеки компонент. Те просто логически се различават — в GitLab изглежда като папка, а на компютъра на разработчика е папка за конкретния проект. На по-ниско ниво се намират компонентите, които ще се комбинират.

Това е пример за съдържанието на dockerized-app. Също така изнасяме тук Docker директория, в която попълваме конфигурации, изисквани за взаимодействие на всички компоненти. Има README.md, в който накратко е описано как да стартирате проекта.

Тук приложихме два docker-compose файла. Това е направено, за да имаме възможност да стартираме на етапи. Когато разработчикът работи с ядрото и не се нуждае от Push-уведомления, той просто стартира docker-compose файла и съответно спестява ресурси.

Ако има нужда от интеграция с Push-уведомления, тогава се стартира docker-compose.yaml и docker-compose-push.yaml.

Тъй като docker-compose.yaml и docker-compose-push.yaml се намират в папката, автоматично се създава единна виртуална мрежа.

Описание на компонентите. Това е по-обширен файл, който отговаря за сбор на компонентите. Какво е забележителното тук? Въведохме компонент за балансиране.

Това е готов Docker образ, в който се стартира nginx и приложение, което слуша Docker сокет. Динамично, с включването и изключването на контейнери, генерира конфигурацията на nginx. Обращенията с компонентите разпределяме по домейн имена трето ниво.

За Development среда използваме домейн .dev — api.informer.dev. Приложението с домейн .dev е достъпно на локалната машина на разработчика.

След това конфигурациите се прехвърлят до всеки проект и всички проекти се стартират едновременно.

Ако графично изобразим, клиентът е нашият браузър или инструмент, с който правим заявки към балансиращия сървър.

Балансиращият сървър по домейн името определя кой контейнер да бъде извикан.

Това може да бъде nginx, който предоставя JS админския панел. Може да бъде nginx, който предоставя API или статични файлове, които nginx предоставя под формата на изображения.

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

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

Какъв пример мога да разгледам, за да докеризирам своето приложение? На мое мнение, добър пример е официалният Docker образ за MySQL.

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

В hub.docker.com обикновено присъстват връзки към github.com, където са предоставени суровите данни, от които можете сами да създадете образ.

В това хранилище има скрипт docker-endpoint.sh, който отговаря за първоначалната инициализация и за по-нататъшната обработка на стартиране на приложението.

В този пример също има възможност за конфигуриране чрез променливи на околната среда. Определяйки променливото окружение при стартиране на единичен контейнер или чрез docker-compose, можете да зададете, че искаме да зададем празна парола за root в MySQL или друга, която предпочитаме.

Има вариант да се създаде произволна парола. Казваме, че ни трябва потребител, трябва да зададем парола на потребителя и трябва да създадем база данни.

В проектите си малко уеднаквихме Dockerfile, който отговаря за инициализацията. Настроихме го според нашите нужди, за да разширим правата на потребителя, който приложението използва. Това позволи по-късно просто да създадем база данни от конзолата на приложението. В Ruby приложенията има команди за създаване, модифициране и изтриване на бази данни.

Този пример показва как изглежда конкретна версия на MySQL на github.com. Можете да отворите Dockerfile и да видите как става инсталирането.

docker-endpoint.sh е скриптът, отговарящ за точката на достъп. При първоначалната инициализация са необходими определени подготвителни действия и всички тези действия са изнесени именно в скрипта за инициализация.

Преминаваме към втората част.

За съхранение на изходния код преминахме на gitlab. Това е доста мощна система, която разполага с визуален интерфейс.

Един от компонентите на Gitlab е Gitlab CI. Той позволява да опишем последователността на командите, които впоследствие ще се използват за организиране на системата за доставка на код или стартиране на автоматично тестване.

Доклад за Gitlab CI 2 https://goo.gl/uohKjI — доклад от Ruby Russia club — доста подробен и вероятно ще ви заинтересува.

Сега ще разгледаме какво е необходимо, за да активираме Gitlab CI. За да стартираме Gitlab CI, ни е необходим един файл .gitlab-ci.yml в корена на проекта.

Тук описваме какво искаме да изпълняваме в последователността от състояния като тестове и деплой.

Изпълняваме скриптове, които директно извикват docker-compose за изграждане на нашето приложение. Това е пример точно за backend.

След това казваме, че е необходимо да изпълним миграциите за промяна на базата данни и да извършим тестовете.

Ако скриптовете се изпълняват коректно и не връщат код за грешка, съответно системата преминава към втората фаза на деплоя.

Фазата на деплой в момента е реализирана за staging. Ние не организирахме безпроблемен рестарт.

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

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

Има забележка, че това трябва да се прилага само за клон master.

При промяна на други клонове не се изпълнява.

Има възможност да организираме издания по клонове.

За да го организираме по-нататък, трябва да инсталираме Gitlab Runner.

Тази утилита е написана на Golang. Тя представлява единен файл, както е прието в света на Golang, без нужда от зависимости.

При стартиране регистрираме Gitlab Runner.

Получаваме ключ в уеб интерфейса на Gitlab.

След това извикваме команда за иницииране в командния ред.

Настройваме Gitlab Runner в диалогов режим (Shell, Docker, VirtualBox, SSH)

Кодът на Gitlab Runner ще се изпълнява при всяко комитиране в зависимост от настройките на .gitlab-ci.yml.

Как изглежда визуално в Gitlab в уеб интерфейса. След като свържем Gitlab CI, получаваме флаг, който показва в какво състояние е билдът в текущия момент.

Видим, че преди 4 минути е направен комит, който е преминал всички тестове и не е предизвикал проблеми.

Можем да разгледаме по-подробно билдовете. Тук виждаме, че вече са преминали два състояния. Състояние на тестване и състояние на деплой на staging.

Ако кликнем на конкретен билд, там ще има конзолния изход на командите, които са били стартирани в процеса съгласно .gitlab-ci.yml.

Така изглежда историята на нашия продукт. Виждаме, че има успешни опити. Когато тестовете се провалят, следващата стъпка не се изпълнява и кодът на staging не се обновява.

Какви задачи решавахме на staging, когато внедрихме docker? Нашата система се състои от компоненти и имаше необходимост да рестартираме само частта от компонентите, които бяха обновени в репозитория, а не цялата система.

За това ни се наложи да разпределим всичко в отделни папки.

След като направихме това, се появи проблем с Docker-compose, който създава свое собствено мрежово пространство за всяка папка и не вижда компонентите на съседа.

За да заобиколим това, създадохме мрежа в Docker ръчно. В Docker-compose написахме да използва за този проект такава мрежа.

По този начин всеки компонент, който стартира с тази мрежа, вижда компонентите в другите части на системата.

Следващият проблем е разделянето на staging между няколко проекта.

Тъй като за да изглежда всичко красиво и максимално приближено до production, е добре да се използва порт 80 или 443, който се използва навсякъде в WEB.

Как решихме това? Назначихме един Gitlab Runner на всички големи проекти.

Gitlab позволява да стартирате няколко разпределени Gitlab Runner, които просто по редица в хаотичен ред взимат всички задачи и ги изпълняват.

За да избегнем хаос, ограничихме групата на нашите проекти до един Gitlab Runner, който при нашите обеми справя без проблеми.

Изнесохме nginx-proxy в отделен стартиращ скрипт и в него написахме мрежите на всички проекти.

Нашият проект има една мрежа, а балансерът има няколко мрежи по имена на проекти. Той може да проксирва нататък по домейни.

Запитванията идват по домейн на порт 80 и се разпределят в група от контейнери, които обслужват този домейн.

Какви бяха още проблемите? Това е, че по подразбиране всички контейнери работят от потребителя root. Този root не е равен на root на хост системата.

Ако влезете в контейнера, ще бъдете root и файлът, който създаваме в този контейнер, получава права root.

Ако разработчикът е влезъл в контейнера и е изпълнил команди, които генерират файлове, след това е излязъл от контейнера, в неговата работна директория остава файл, до който няма достъп.

Как може да се реши това? Можете да добавите потребители, които ще бъдат в контейнера.

Какви проблеми възникнаха, когато добавихме потребител?

Когато създаваме потребител, често ID на групата (UID) и ID на потребителя (GID) не съвпадат.

За да решим този проблем, в контейнера използваме потребители с ID 1000.

В нашия случай това съвпадна с факта, че практически всички разработчици използват ОС Ubuntu. Първият потребител в ОС Ubuntu има ID 1000.

Какви са нашите планове?

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

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

Много ми се иска да преминем напред и директно да стигнем до оркестрацията.

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

Генерирането на контейнери създава неудобства при работата с логовете. В момента логовете са изолирани. Те са разпръснати по контейнерите. Една от задачите е да се направи удобен достъп до логовете чрез уеб интерфейс.

Източник: habr.com