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

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

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

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

На кого му пука, моля под котката.

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

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

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

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

Нашето мото е: закачете всичко, до което можем да се докопаме.

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

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

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

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

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

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

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

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

Всеки, който работи с MySQL, знае, че тези библиотеки носят зависимости със себе си. Доста е проблематично да управлявате 2 бази заедно. Поне старите клиенти са проблематични за свързване към новата база данни. Това от своя страна създава няколко проблема.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Последният ред казва, че уеб контейнерът зависи от db контейнера. Когато извикаме началото на уеб контейнера, docker-compose първо ще стартира базата данни вместо нас. Още в началото на базата данни (всъщност след стартирането на контейнера! Това не гарантира готовността на базата данни) ще стартира приложението, нашият бекенд.

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

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

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

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

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

Във Frontend използваме JavaScipt и NodeJS.

Сега имаме последния проект на ReacJS. Разработчикът стартира всичко в контейнера и разработи чрез горещо презареждане.

След това се стартира задачата за асемблиране на JavaScipt и кодът, компилиран в статика, се дава чрез nginx за спестяване на ресурси.

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

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

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

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

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

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

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

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

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

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

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

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

Ако е необходимо, можете да преработите и повишите версията на NodeJS от услугата Push notification.

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

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

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

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

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

След това имаме няколко компонента: администратор, inform-API, насочени известия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кой пример да разгледате, за да докеризирате приложението си? Според мен добър пример е официалният докер образ за 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, за да изградим нашето приложение. Това е само пример за бекенд.

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

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

Етапът на разгръщане в момента е внедрен за етапно изпълнение. Не организирахме рестартиране с нулев престой.

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

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

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

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

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

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

Тази помощна програма е написана на Golang. Това е един файл, както е обичайно в света на Golang, който не изисква никакви зависимости.

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

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

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

Настройте Gitlab Runner интерактивно (Shell, Docker, VirtualBox, SSH)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нашият проект има една мрежа, а балансьорът има няколко мрежи по имена на проекти. Може да проксира допълнително чрез имена на домейни.

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

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

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

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

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

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

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

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

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

Имаме ли планове?

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

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

Така че искам вече да отида по-нататък, за да премина директно към оркестрацията.

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

Контейнерите за хвърляне на хайвера правят неудобна работата с трупи. Сега трупите са изолирани. Те са разпръснати в контейнери. Една от задачите е да се направи удобен достъп до регистрационните файлове през уеб интерфейса.

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