Процес на развој и тестирање со Docker и Gitlab CI

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

Оние кои штотуку почнуваат да го спроведуваат процесот на развој и тестирање базиран на Docker + Gitlab CI често поставуваат основни прашања. Каде да се започне? Како да се организирате? Како да се тестира?

Овој извештај е добар затоа што на структуриран начин зборува за процесот на развој и тестирање со помош на Docker и Gitlab CI. Самиот извештај е од 2017 година. Мислам дека од овој извештај можете да ги соберете основите, методологијата, идејата и искуството за користење.

Кој се грижи, ве молам под мачката.

Јас се викам Александар Сигачев. Работам за Inventos. Ќе ви кажам за моето искуство со користење на Docker и како постепено го имплементираме на проекти во компанијата.

Тема на извештајот: Процес на развој со помош на Docker и Gitlab CI.

Ова е мојот втор разговор за Докер. Во времето на првиот извештај, го користевме Docker само во развојот на машините за програмери. Бројот на вработени кои користеле Docker бил околу 2-3 лица. Постепено се стекна искуство и отидовме малку подалеку. Линк до нашата првиот извештај.

Што ќе има во овој извештај? Ќе го споделиме нашето искуство за тоа какви гребла собравме, какви проблеми решивме. Не беше насекаде убаво, но ни овозможи да продолжиме понатаму.

Нашето мото: приклучете го сето она што ни доаѓа во рака.

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

Кога една компанија има неколку тимови, програмерот е заеднички ресурс. Постојат фази кога програмерот е извлечен од еден проект и даден на друг проект на одредено време.

За да може програмерот брзо да разбере, тој треба што побрзо да го преземе изворниот код на проектот и да започне средина, што ќе му овозможи дополнително да напредува во решавањето на проблемите на овој проект.

Обично, ако почнете од нула, има мала документација во проектот. Само олдтајмерите имаат информации како да го постават. Вработените сами го поставуваат своето работно место за еден или два дена. За да го забрзаме ова, го користевме Docker.

Следната причина е стандардизацијата на поставките во Development. Според моето искуство, програмерите секогаш преземаат иницијатива. Во секој петти случај се внесува сопствен домен, на пример vasya.dev. До мене седи мојот сосед Петја, чиј домен е petya.dev. Тие развиваат веб-страница или некоја системска компонента користејќи го ова име на домен.

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

Истото се случува и со поставките за базата на податоци. Некои луѓе не се мачат со безбедноста и работат со празна лозинка за root. Во фазата на инсталација, MySQL побара некого лозинка и лозинката се покажа дека е 123. Често се случува конфигурацијата на базата на податоци постојано да се менува во зависност од посветеноста на развивачот. Некој ја коригирал, некој не ја коригирал конфигурацијата. Имаше трикови кога ставивме тест конфигурација .gitignore и секој развивач мораше да ја инсталира базата на податоци. Ова го отежна процесот на започнување. Меѓу другото, треба да запомните и за базата на податоци. Базата на податоци мора да се иницијализира, да се регистрира лозинка, да се регистрира корисник, да се креира знак итн.

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

Секој кој работи со MySQL знае дека овие библиотеки носат зависности. Прилично е проблематично да се извршуваат 2 бази на податоци заедно. Во најмала рака, проблематично е да се поврзат старите клиенти со новата база на податоци. Ова пак предизвикува неколку проблеми.

Следниот проблем е кога развивачот работи на локална машина, тој користи локални ресурси, локални датотеки, локална RAM меморија. Целата интеракција во моментот на развивање решение за проблемите се врши во рамките на фактот дека работи на една машина. Пример би бил кога имаме задни сервери во Production 3, а развивачот ги зачувува датотеките во root директориумот и од таму nginx ги зема датотеките за да одговори на барањето. Кога таков код ќе влезе во Production, излегува дека датотеката е присутна на еден од 3-те сервери.

Во моментов се развива насоката на микросервисите. Кога ги делиме нашите големи апликации на некои мали компоненти кои комуницираат едни со други. Ова ви овозможува да изберете технологии за одреден куп задачи. Ова исто така ви овозможува да ја поделите работата и областа на одговорност помеѓу програмерите.

Развивач на преден дел, кој се развива во JS, практично нема никакво влијание врз задниот дел. Развивачот на заднината, пак, развива, во нашиот случај, Ruby on Rails и не се меша со Frondend. Интеракцијата се изведува со помош на API.

Како бонус, користејќи го Docker, можевме да рециклираме ресурси на Staging. Секој проект, поради неговите специфики, бараше одредени поставки. Физички, беше неопходно да се распредели или виртуелен сервер и да се конфигурираат одделно, или да се подели некој вид на променлива средина и проектите може да влијаат еден на друг, во зависност од верзијата на библиотеките.

Алатки. Што користиме?

• Самиот Докер. Dockerfile ги опишува зависностите на една апликација.
• Docker-compose е пакет што обединува неколку наши Docker апликации.
• Ние користиме GitLab за складирање на изворниот код.
• Ние користиме GitLab-CI за системска интеграција.

Извештајот се состои од два дела.

Првиот дел ќе ви каже како да го стартувате Docker на машините на програмерите.

Вториот дел ќе зборува за тоа како да комуницирате со GitLab, како ги извршуваме тестовите и како да се префрлиме на Staging.

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

Ова е минимален пример за датотека со докер-компонирање. Во овој случај, покажуваме дека постои врска помеѓу два контејнери. Ова е директно во услугата за база на податоци и веб-услугата. Нашите веб-апликации во повеќето случаи бараат некаква база на податоци како заднина за складирање податоци. Бидејќи користиме MySQL, примерот е со MySQL - но ништо не не спречува да користиме некоја друга база на податоци (PostgreSQL, Redis).

Ја земаме сликата MySQL 5.7.14 без промени од официјалниот извор од центарот на Docker. Сликата што е одговорна за нашата веб-апликација ја собираме од тековниот директориум. За време на првото лансирање, тој собира слика за нас. Потоа ја извршува командата што ја извршуваме овде. Ако се вратиме назад, ќе видиме дека командата за лансирање е дефинирана преку Puma. Пума е услуга напишана во Руби. Во вториот случај ние прескокнуваме. Оваа команда може да биде произволна во зависност од нашите потреби или задачи.

Ние, исто така, опишуваме дека треба да ја препратиме портата на нашата машина-домаќин на развивачите од 3000 до 3000 контејнерска порта. Ова се прави автоматски користејќи iptables и сопствен механизам, кој е директно вграден во Docker.

Програмерот може, како и досега, да пристапи до која било достапна IP адреса, на пример, 127.0.0.1 локална или надворешна IP адреса на машината.

Последната линија вели дека веб-контејнерот зависи од db контејнерот. Кога ќе го повикаме веб-контејнерот да се стартува, docker-compose прво ќе ја стартува базата на податоци за нас. Веќе по почетокот на базата на податоци (всушност, по лансирањето на контејнерот! Ова не гарантира подготвеност на базата на податоци) таа ќе ја стартува нашата апликација, нашиот заднина.

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

Што ни дава користењето на докеризација на базата на податоци на проект? Ја снимаме верзијата MySQL за сите програмери. Ова ви овозможува да избегнете некои грешки што може да се појават кога верзиите се разминуваат, кога се менуваат синтаксата, конфигурацијата и стандардните поставки. Ова ви овозможува да наведете заедничко име на домаќин за базата на податоци, најава, лозинка. Се оддалечуваме од зоолошката градина на имиња и конфликти во конфигурациските датотеки што постоеле порано.

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

Docker ви овозможува да користите Python, Ruby, NodeJS, PHP толкувач на саканата верзија. Се ослободуваме од потребата да користиме некој вид менаџер на верзии. Претходно, за Ruby се користеше пакет вртежи во минута, што ви овозможи да ја промените верзијата во зависност од проектот. Благодарение на контејнерот Docker, ова исто така ви овозможува непречено да го мигрирате кодот и да го верзијата заедно со зависностите. Немаме проблем да ја разбереме верзијата и на толкувачот и на кодот. За да ја ажурирате верзијата, треба да го спуштите стариот сад и да го подигнете новиот контејнер. Ако нешто тргне наопаку, можеме да го спуштиме новиот сад, да го подигнеме стариот сад.

По изградбата на сликата, контејнерите и во развој и во производство ќе бидат исти. Ова е особено точно за големи инсталации.

На Frontend користиме JavaScipt и NodeJS.

Сега го имаме нашиот последен проект на ReacJS. Програмерот лансираше сè во контејнерот и го разви со помош на вчитување на топло.

Следно, задачата за составување JavaScipt е лансирана и статички составениот код се испраќа преку nginx, заштедувајќи ресурси.

Овде дадов дијаграм на нашиот последен проект.

Кои проблеми ги решивте? Имавме потреба да изградиме систем со кој мобилните уреди комуницираат. Тие добиваат податоци. Една од можностите е да испраќате push известувања на овој уред.

Што направивме за ова?

Апликацијата ја поделивме на следните компоненти: административен дел во JS, заднина што работи преку интерфејс REST под Ruby on Rails. Заднината е во интеракција со базата на податоци. Резултатот што се генерира му се дава на клиентот. Администраторскиот панел е во интеракција со задниот дел и базата на податоци преку интерфејс REST.

Имавме потреба и да испраќаме Push известувања. Пред ова имавме проект во кој беше имплементиран механизам кој беше одговорен за доставување известувања до мобилните платформи.

Ја развивме следнава шема: операторот од прелистувачот комуницира со администраторскиот панел, административниот панел комуницира со задниот дел, задачата е да испраќа известувања за Push.

Push известувањата комуницираат со друга компонента што е имплементирана во NodeJS.

Редиците се градат и известувањата се испраќаат според сопствен механизам.

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

Истото но во бројки. Повторната употреба на кодот е важна овде.

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

Во тоа време ја користевме верзијата 4 на NodeJS. Сега (во 2017 година - забелешка на уредникот) во нашите најнови случувања ја користиме верзијата 7 на NodeJS. Нема проблем во новите компоненти за вклучување на нови верзии на библиотеки.

Доколку е потребно, можете да ја рефакторирате и подигнете верзијата NodeJS на услугата за известување Push.

И ако можеме да ја одржиме компатибилноста со API, тогаш ќе биде можно да ја замениме со други проекти што биле користени претходно.

Што ви е потребно за да додадете Docker? Додаваме Dockerfile во нашето складиште, кое ги опишува потребните зависности. Во овој пример, компонентите се поделени логично. Ова е минималниот комплет за развивач на заднина.

Кога креираме нов проект, креираме Dockerfile и го опишуваме потребниот екосистем (Python, Ruby, NodeJS). Во docker-compose, ја опишува потребната зависност - базата на податоци. Опишуваме дека ни треба база на податоци за таква и таква верзија, за складирање податоци таму и таму.

Ние користиме посебен трет контејнер со nginx за да служиме статична содржина. Можно е да прикачувате слики. Заднината ги става во претходно подготвен волумен, кој исто така е монтиран во контејнер со nginx, кој обезбедува статички податоци.

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

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

Со цел да го стартуваме сето ова, создадовме друго складиште наречено dockerized-app. Во моментов користиме повеќе складишта за секоја компонента. Тие едноставно се логички различни - во GitLab изгледа како папка, но на машината на развивачот изгледа како папка за одреден проект. Едно ниво подолу се компонентите што ќе се комбинираат.

Ова е пример за содржината на dockerized-app. Овде поставуваме и директориум Docker, во кој ги пополнуваме конфигурациите потребни за интеракциите на сите компоненти. Постои README.md кој накратко опишува како да го започнете проектот.

Овде применивме две датотеки со докер-компонирање. Ова е направено за да може да се лансира во фази. Кога развивачот работи со кернелот, не му требаат известувања за Push, тој едноставно ја стартува датотеката за составување docker и, соодветно, ресурсите се зачувуваат.

Доколку има потреба од интеграција со Push известувањата, тогаш се стартуваат 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, можеме да кажеме дека треба да поставиме празна лозинка за docker за root на MySQL или што и да сакаме.

Постои опција за креирање случајна лозинка. Ние велиме дека ни треба корисник, треба да поставиме лозинка за корисникот и треба да создадеме база на податоци.

Во нашите проекти, малку го обединивме Dockerfile, кој е одговорен за иницијализација. Таму го приспособивме на нашите потреби за едноставно да ги прошириме корисничките права што ги користи апликацијата. Ова овозможи едноставно да се создаде база на податоци од конзолата за апликации во иднина. Руби апликациите имаат команди за креирање, менување и бришење бази на податоци.

Ова е пример за тоа како изгледа одредена верзија на MySQL на github.com. Можете да го отворите Dockerfile и да видите како се одвива инсталацијата таму.

docker-endpoint.sh скрипта одговорна за влезната точка. За време на почетната иницијализација, потребни се некои подготвителни дејства и сите овие дејства се вклучени во скриптата за иницијализација.

Да преминеме на вториот дел.

Се префрливме на gitlab за складирање на изворните кодови. Ова е прилично моќен систем кој има визуелен интерфејс.

Една од компонентите на Gitlab е Gitlab CI. Тоа ви овозможува да опишете серија команди кои последователно ќе се користат за организирање систем за испорака на код или за извршување на автоматско тестирање.

Извештај за Gitlab CI 2 https://goo.gl/uohKjI - Извештајот од клубот Руби Русија е доста детален и може да ве интересира.

Сега ќе погледнеме што е потребно за да се активира Gitlab CI. За да го стартуваме Gitlab CI, само треба да ја ставиме датотеката .gitlab-ci.yml во коренот на проектот.

Овде опишуваме дека сакаме да извршиме низа состојби како што се тест, распоредување.

Извршуваме скрипти кои директно ја повикуваат изградбата на docker-compose на нашата апликација. Ова е пример за само задниот дел.

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

Ако скриптите се правилно извршени и не враќаат код за грешка, тогаш системот продолжува во втората фаза на распоредување.

Фазата на распоредување моментално е имплементирана за постановка. Не организиравме рестартирање без прекини.

Насилно ги гасиме сите контејнери, а потоа повторно ги креваме сите контејнери собрани во првата фаза при тестирањето.

Ајде да ги извршиме миграциите на базата на податоци што беа напишани од развивачите за тековната променлива околина.

Има забелешка дека ова треба да се примени само на главната гранка.

Не работи кога менувате други гранки.

Можно е да се организираат пуштања по гранки.

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

Оваа алатка е напишана на Golang. Тоа е една датотека како што е вообичаено во светот на Голанг, која не бара никакви зависности.

При стартување го регистрираме Gitlab Runner.

Го добиваме клучот во веб-интерфејсот на Gitlab.

Потоа ја повикуваме командата за иницијализација на командната линија.

Конфигурирање на Gitlab Runner во режим на дијалог (Shell, Docker, VirtualBox, SSH)

Кодот на Gitlab Runner ќе се извршува при секое извршување во зависност од поставката .gitlab-ci.yml.

Како визуелно изгледа во Gitlab во веб-интерфејсот. По поврзувањето на GItlab CI, имаме знаме што покажува во каква состојба е изградбата во моментот.

Гледаме дека пред 4 минути е направена обврска која ги поминала сите тестови и не направила никакви проблеми.

Можеме подетално да ги разгледаме градбите. Овде гледаме дека веќе поминале две држави. Статусот на тестирање и статусот на распоредување при поставување.

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

Вака изгледа приказната за нашиот производ. Гледаме дека имало успешни обиди. Кога се поднесуваат тестовите, тие не се префрлаат на следниот чекор и кодот за фаза не се ажурира.

Кои проблеми ги решивме при инсценирањето кога го имплементиравме docker? Нашиот систем се состои од компоненти и требаше да ги рестартираме само некои од компонентите што беа ажурирани во складиштето, а не целиот систем.

За да го направите ова, моравме да одвоиме сè во посебни папки.

Откако го направивме ова, имавме проблем со фактот дека Docker-compose создава сопствен мрежен простор за секоја папка и не ги гледа компонентите на својот сосед.

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

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

Следниот проблем е поделбата на сцената помеѓу неколку проекти.

Бидејќи за сето ова да изгледа убаво и што е можно поблиску до производството, добро е да се користи портата 80 или 443, која се користи насекаде во WEB.

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

Gitlab ви овозможува да лансирате неколку дистрибуирани Gitlab Runners, кои едноставно ќе ги преземат сите задачи една по една во хаотичен редослед и ќе ги извршуваат.

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

Го преместивме nginx-proxy во посебна скрипта за лансирање и ги напишавме мрежите на сите проекти во него.

Нашиот проект има една мрежа, а балансерот има неколку мрежи засновани на имиња на проекти. Може дополнително да се прокси со имиња на домени.

Нашите барања доаѓаат преку доменот на портата 80 и се решаваат на група контејнери што го опслужуваат овој домен.

Какви други проблеми имаше? Ова е она што сите контејнери стандардно работат како root. Ова е коренот нееднаков корен домаќин на системот.

Меѓутоа, ако го внесете контејнерот, тој ќе биде root и датотеката што ја создаваме во овој контејнер добива root права.

Ако некој програмер влегол во контејнерот и направил некои команди таму што генерирале датотеки, а потоа го напуштил контејнерот, тогаш во неговиот работен директориум има датотека до која нема пристап.

Како може ова да се реши? Можете да додадете корисници кои ќе бидат во контејнерот.

Кои проблеми се појавија кога го додадовме корисникот?

Кога креирате корисник, ID на групата (UID) и кориснички ID (GID) често не се совпаѓаат.

За да го решиме овој проблем во контејнерот користиме корисници со ID 1000.

Во нашиот случај, ова се совпадна со фактот дека скоро сите програмери користат Ubuntu OS. И во Ubuntu OS првиот корисник има ID 1000.

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

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

Некои од проблемите што ги решивме можеби веќе се решени со стандардни средства.

Навистина сакам да продолжам понатаму и да преминам директно на оркестрација.

Еден пример е вградениот механизам на Docker наречен Docker Swarm, кој излегува од кутијата. Би сакал да лансира нешто во производство врз основа на технологијата Docker Swarm.

Контејнерите за мрестење го прават незгодно работењето со трупци. Сега трупците се изолирани. Тие се расфрлани во контејнери. Една од задачите е да се направи удобен пристап до дневниците преку веб-интерфејс.

Извор: www.habr.com