Процес развоја и тестирања са Доцкер и Гитлаб ЦИ

Предлажем да прочитате транскрипт извештаја Александра Сигачева из Инвентоса „Процес развоја и тестирања са Доцкер + Гитлаб ЦИ“

Они који тек почињу да имплементирају процес развоја и тестирања заснованог на Доцкер + Гитлаб ЦИ често постављају основна питања. Где да почнем? Како организовати? Како тестирати?

Овај извештај је добар јер на структуиран начин говори о процесу развоја и тестирања користећи Доцкер и Гитлаб ЦИ. Сам извештај је из 2017. године. Мислим да из овог извештаја можете извући основе, методологију, идеју и искуство коришћења.

Кога брига, молим под мачку.

Моје име је Александар Сигачев. Радим за Инвентос. Рећи ћу вам о свом искуству коришћења Доцкер-а и како га постепено примењујемо на пројектима у компанији.

Тема извештаја: Развојни процес користећи Доцкер и Гитлаб ЦИ.

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

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

Наш мото: докеризујте све што нам дође под руку.

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

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

Да би програмер брзо разумео, потребно је да преузме изворни код пројекта и што пре покрене окружење које ће му омогућити да даље напредује у решавању проблема овог пројекта.

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

Следећи разлог је стандардизација подешавања у Развоју. По мом искуству, програмери увек преузимају иницијативу. У сваком петом случају се уноси прилагођени домен, на пример васиа.дев. Поред мене седи мој комшија Петја, чији је домен петиа.дев. Они развијају веб локацију или неку системску компоненту користећи ово име домена.

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

Иста ствар се дешава са подешавањима базе података. Неки људи се не замарају безбедношћу и раде са празном роот лозинком. У фази инсталације, МиСКЛ је од некога тражио лозинку и испоставило се да је лозинка 123. Често се дешава да се конфигурација базе података стално мења у зависности од урезивања програмера. Неко је исправио, неко није исправио конфигурацију. Било је трикова када смо убацили неке тестне конфигурације .gitignore а сваки програмер је морао да инсталира базу података. То је отежало почетак процеса. Између осталог, морате запамтити о бази података. База података мора бити иницијализована, лозинка мора бити регистрована, корисник мора бити регистрован, мора се креирати знак итд.

Други проблем су различите верзије библиотека. Често се дешава да програмер ради на различитим пројектима. Постоји пројекат Легаци, који је започео пре пет година (од 2017. – прим. уредника). На почетку смо почели са МиСКЛ 5.5. Постоје и савремени пројекти у којима покушавамо да имплементирамо модерније верзије МиСКЛ-а, на пример 5.7 или старије (2017. године – прим. уредника)

Свако ко ради са МиСКЛ зна да ове библиотеке носе зависности. Прилично је проблематично покренути 2 базе података заједно. У најмању руку, проблематично је повезати старе клијенте са новом базом података. Ово заузврат доводи до неколико проблема.

Следећи проблем је када програмер ради на локалној машини, он користи локалне ресурсе, локалне датотеке, локалну РАМ меморију. Сва интеракција у време развијања решења проблема се одвија у оквиру чињенице да ради на једној машини. Пример би био када имамо позадинске сервере у продукцији 3, а програмер чува датотеке у основном директоријуму и одатле нгинк преузима датотеке да одговори на захтев. Када такав код уђе у продукцију, испоставља се да је датотека присутна на једном од 3 сервера.

Правац микросервиса се тренутно развија. Када поделимо наше велике апликације на неке мале компоненте које међусобно делују. Ово вам омогућава да изаберете технологије за одређени скуп задатака. Ово вам такође омогућава да поделите посао и област одговорности између програмера.

Фронтенд програмер, који се развија у ЈС-у, практично нема утицаја на позадину. Позадински програмер, заузврат, развија, у нашем случају, Руби он Раилс и не омета Фронденд. Интеракција се врши помоћу АПИ-ја.

Као бонус, користећи Доцкер, могли смо да рециклирамо ресурсе на Стагинг-у. Сваки пројекат је, због својих специфичности, захтевао одређена подешавања. Физички, било је потребно или доделити виртуелни сервер и конфигурисати га засебно, или поделити неку врсту променљивог окружења и пројекти би могли да утичу једни на друге, у зависности од верзије библиотека.

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

• Сам Доцкер. Доцкерфиле описује зависности једне апликације.
• Доцкер-цомпосе је скуп који обједињује неколико наших Доцкер апликација.
• Ми користимо ГитЛаб за складиштење изворног кода.
• Користимо ГитЛаб-ЦИ за системску интеграцију.

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

Први део ће вам рећи како да покренете Доцкер на машинама програмера.

Други део ће говорити о томе како да комуницирамо са ГитЛаб-ом, како покрећемо тестове и како прелазимо на Стагинг.

Доцкер је технологија која омогућава (користећи декларативни приступ) да опише неопходне компоненте. Ово је пример Доцкерфиле-а. Овде изјављујемо да смо наследили званичну Доцкер слику Руби:2.3.0. Садржи инсталирану Руби верзију 2.3. Инсталирамо потребне библиотеке асемблера и НодеЈС. Описујемо да креирамо директоријум /app. Додељујемо директоријум апликације као радни директоријум. У овај директоријум постављамо потребан минимум Гемфиле и Гемфиле.лоцк. Затим градимо пројекте који инсталирају ову слику зависности. Назначавамо да ће контејнер бити спреман за слушање на екстерном порту 3000. Последња команда је команда која директно покреће нашу апликацију. Ако извршимо наредбу за покретање пројекта, апликација ће покушати да покрене и покрене наведену команду.

Ово је минимални пример датотеке доцкер-цомпосе. У овом случају показујемо да постоји веза између два контејнера. Ово је директно у сервису базе података и веб сервису. Наше веб апликације у већини случајева захтевају неку врсту базе података као позадину за складиштење података. Пошто користимо МиСКЛ, пример је са МиСКЛ - али ништа нас не спречава да користимо неку другу базу података (ПостгреСКЛ, Редис).

Ми преузимамо слику МиСКЛ 5.7.14 без промена из званичног извора из Доцкер чворишта. Сакупљамо слику која је одговорна за нашу веб апликацију из тренутног директоријума. Током првог лансирања, он прикупља слику за нас. Затим покреће команду коју ми овде извршавамо. Ако се вратимо, видећемо да је команда за лансирање дефинисана преко Пуме. Пума је сервис написан у Руби-у. У другом случају поништавамо. Ова команда може бити произвољна у зависности од наших потреба или задатака.

Такође описујемо да треба да проследимо порт на нашој хост машини за програмере са 3000 на 3000 порт контејнера. Ово се ради аутоматски користећи иптаблес и сопствени механизам, који је директно уграђен у Доцкер.

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

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

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

Шта нам даје коришћење докеризације базе података на пројекту? Снимамо МиСКЛ верзију за све програмере. Ово вам омогућава да избегнете неке грешке које се могу појавити када се верзије разликују, када се промене синтакса, конфигурација и подразумевана подешавања. Ово вам омогућава да наведете заједничко име хоста за базу података, пријаву, лозинку. Удаљавамо се од зоолошког врта имена и сукоба у конфигурационим датотекама који су постојали раније.

Имамо прилику да користимо оптималнију конфигурацију за развојно окружење, која ће се разликовати од подразумеване. МиСКЛ је подразумевано конфигурисан за слабе машине и његове перформансе из кутије су веома ниске.

Доцкер вам омогућава да користите Питхон, Руби, НодеЈС, ПХП интерпретер жељене верзије. Ослобађамо се потребе да користимо неку врсту менаџера верзија. Раније се за Руби користио рпм пакет, који вам је омогућавао да промените верзију у зависности од пројекта. Захваљујући Доцкер контејнеру, ово вам такође омогућава да глатко мигрирате код и верзију заједно са зависностима. Немамо проблема да разумемо верзију и тумача и кода. Да бисте ажурирали верзију, потребно је да спустите стари контејнер и подигнете нови контејнер. Ако нешто крене наопако, можемо спустити нови контејнер, подићи стари контејнер.

Након изградње имиџа, ​​контејнери у развоју и производњи ће бити исти. Ово посебно важи за велике инсталације.

На Фронтенд-у користимо ЈаваСципт и НодеЈС.

Сада имамо наш последњи пројекат на РеацЈС-у. Програмер је покренуо све што је било у контејнеру и развио помоћу врућег поновног пуњења.

Затим се покреће задатак састављања ЈаваСципт-а и статички састављен код се шаље преко нгинк-а, штедећи ресурсе.

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

Које проблеме сте решили? Имали смо потребу да изградимо систем са којим мобилни уређаји комуницирају. Они примају податке. Једна од могућности је слање пусх обавештења на овај уређај.

Шта смо урадили за ово?

Апликацију смо поделили на следеће компоненте: администраторски део у ЈС-у, бацкенд који ради преко РЕСТ интерфејса под Руби он Раилс. Бацкенд је у интеракцији са базом података. Резултат који се генерише даје се клијенту. Административни панел комуницира са позадином и базом података преко РЕСТ интерфејса.

Такође смо имали потребу да шаљемо Пусх обавештења. Пре овога смо имали пројекат у коме је имплементиран механизам који је био задужен за достављање обавештења мобилним платформама.

Развили смо следећу шему: оператер из претраживача је у интеракцији са админ панелом, админ панел је у интеракцији са позадином, задатак је да шаље Пусх обавештења.

Пусх обавештења су у интеракцији са другом компонентом која је имплементирана у НодеЈС.

Редови се граде и обавештења се шаљу према сопственом механизму.

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

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

Ако смо раније говорили о поновном коришћењу кода у облику библиотека, онда се у овом примеру наш сервис, који одговара на Пусх обавештења, поново користи као комплетан сервер. Пружа АПИ. И наш нови развој је у интеракцији са њим.

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

Ако је потребно, можете рефакторисати и подићи НодеЈС верзију услуге Пусх обавештења.

А ако можемо да одржимо компатибилност АПИ-ја, онда ће бити могуће да је заменимо другим пројектима који су раније коришћени.

Шта треба да додате Доцкер? У наше спремиште додајемо Доцкерфиле, који описује неопходне зависности. У овом примеру, компоненте су подељене логички. Ово је минимални комплет за бацкенд програмера.

Када креирамо нови пројекат, креирамо Доцкерфиле и описујемо жељени екосистем (Питхон, Руби, НодеЈС). У доцкер-цомпосе описује неопходну зависност – базу података. Описујемо да нам је потребна база података те и такве верзије, да ту и тамо чувамо податке.

Користимо посебан трећи контејнер са нгинк-ом за послуживање статичког садржаја. Могуће је учитавање слика. Бацкенд их ставља у унапред припремљени волумен, који је такође монтиран у контејнер са нгинк-ом, који обезбеђује статичке податке.

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

Следеће имамо неколико компоненти: админ, инфо-АПИ, пусх обавештења.

Да бисмо све ово покренули, направили смо још једно спремиште под називом доцкеризед-апп. Тренутно користимо више спремишта за сваку компоненту. Они су једноставно логички различити - у ГитЛаб-у изгледа као фасцикла, али на машини програмера изгледа као фасцикла за одређени пројекат. Један ниво испод су компоненте које ће бити комбиноване.

Ово је пример садржаја доцкеризед-апп. Овде такође постављамо Доцкер директоријум у који попуњавамо конфигурације потребне за интеракцију свих компоненти. Постоји РЕАДМЕ.мд који укратко описује како да покренете пројекат.

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

Ако постоји потреба за интеграцијом са Пусх обавештењима, онда се покрећу доцкер-цомпосе.иамл и доцкер-цомпосе-пусх.иамл.

Пошто се доцкер-цомпосе.иамл и доцкер-цомпосе-пусх.иамл налазе у фасцикли, аутоматски се креира једна виртуелна мрежа.

Опис компоненти. Ово је напреднија датотека која је одговорна за прикупљање компоненти. Шта је овде изузетно? Овде представљамо компоненту балансера.

Ово је готова Доцкер слика која покреће нгинк и апликацију која слуша Доцкер соцкет. Динамички, како се контејнери укључују и искључују, нгинк конфигурација се регенерише. Ми дистрибуирамо руковање компонентама користећи имена домена трећег нивоа.

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

Затим се конфигурације преносе на сваки пројекат и сви пројекти се покрећу заједно у исто време.

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

Балансер одређује ком контејнеру треба приступити на основу имена домена.

Ово би могао бити нгинк, који обезбеђује ЈС администраторском панелу. Ово може да уради нгинк, који обезбеђује АПИ, или статичке датотеке које нгинк обезбеђује у облику учитавања слика.

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

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

Који пример треба да погледам да докеризујем своју апликацију? По мом мишљењу, добар пример је званична доцкер слика за МиСКЛ.

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

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

Даље у овом спремишту постоји скрипта доцкер-ендпоинт.сх, која је одговорна за почетну иницијализацију и даљу обраду покретања апликације.

Такође у овом примеру постоји могућност конфигурисања помоћу променљивих окружења. Дефинисањем променљиве окружења приликом покретања једног контејнера или преко доцкер-цомпосе, можемо рећи да морамо да поставимо празну лозинку за доцкер за роот на МиСКЛ или шта год желимо.

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

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

Ово је пример како одређена верзија МиСКЛ-а изгледа на гитхуб.цом. Можете отворити Доцкерфиле и видети како се инсталација одвија тамо.

доцкер-ендпоинт.сх скрипта одговорна за улазну тачку. Током почетне иницијализације, потребне су неке припремне радње и све ове акције су укључене у скрипту за иницијализацију.

Пређимо на други део.

Прешли смо на гитлаб да чувамо изворне кодове. Ово је прилично моћан систем који има визуелни интерфејс.

Једна од Гитлаб компоненти је Гитлаб ЦИ. Омогућава вам да опишете низ команди које ће се касније користити за организовање система за испоруку кода или за покретање аутоматског тестирања.

Извештај о Гитлаб ЦИ 2 https://goo.gl/uohKjI — извештај клуба Руби Руссиа је прилично детаљан и можда ће вас занимати.

Сада ћемо погледати шта је потребно да се активира Гитлаб ЦИ. Да бисмо покренули Гитлаб ЦИ, само треба да ставимо датотеку .гитлаб-ци.имл у корен пројекта.

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

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

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

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

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

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

Хајде да покренемо миграције базе података које су написали програмери за тренутно променљиво окружење.

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

Не ради када мењате друге гране.

Могуће је организовати развлачење дуж грана.

Да бисмо ово даље организовали, морамо да инсталирамо Гитлаб Руннер.

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

Приликом покретања региструјемо Гитлаб Руннер.

Добијамо кључ у Гитлаб веб интерфејсу.

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

Конфигурисање Гитлаб Руннер-а у режиму дијалога (Схелл, Доцкер, ВиртуалБок, ССХ)

Код на Гитлаб Руннер-у ће се извршити при сваком урезивању у зависности од .гитлаб-ци.имл подешавања.

Како то визуелно изгледа у Гитлабу у веб интерфејсу. Након повезивања ГИтлаб ЦИ, имамо заставицу која показује у каквом је стању буилд у овом тренутку.

Видимо да је пре 4 минута направљен урезивање који је прошао све тестове и није правио проблеме.

Можемо детаљније погледати градње. Овде видимо да су две државе већ прошле. Статус тестирања и статус имплементације на фази.

Ако кликнемо на одређени буилд, појавиће се излаз на конзоли команди које су покренуте у процесу према .гитлаб-ци.имл.

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

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

Да бисмо то урадили, морали смо све да раздвојимо у засебне фасцикле.

Након што смо то урадили, имали смо проблем са чињеницом да Доцкер-цомпосе креира сопствени мрежни простор за сваку фасциклу и не види компоненте свог суседа.

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

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

Следећи проблем је подела упризорења између неколико пројеката.

Како би све ово изгледало лепо и што ближе продукцији, добро је користити порт 80 или 443 који се користи свуда у ВЕБ-у.

Како смо ово решили? Свим великим пројектима смо доделили један Гитлаб Руннер.

Гитлаб вам омогућава да покренете неколико дистрибуираних Гитлаб Руннер-а, који ће једноставно преузети све задатке један по један у хаотичном редоследу и покренути их.

Да бисмо избегли кућне проблеме, ограничили смо групу наших пројеката на један Гитлаб Руннер, који се без проблема носи са нашим обимима.

Преместили смо нгинк-проки у засебну скрипту за покретање и написали мреже свих пројеката у њој.

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

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

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

Међутим, ако уђете у контејнер, он ће бити роот и датотека коју креирамо у овом контејнеру добија роот права.

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

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

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

Када креирате корисника, ИД групе (УИД) и кориснички ИД (ГИД) се често не поклапају.

За решавање овог проблема у контејнеру користимо кориснике са ИД 1000.

У нашем случају, то се поклопило са чињеницом да скоро сви програмери користе Убунту ОС. А у Убунту ОС-у први корисник има ИД 1000.

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

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

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

Заиста желим да идем даље и пређем директно на оркестрацију.

Један пример је Доцкер-ов уграђени механизам под називом Доцкер Сварм, који долази из кутије. Желео бих да покренем нешто у производњи засновано на Доцкер Сварм технологији.

Контејнери за мријест чине рад са трупцима незгодним. Сада су трупци изоловани. Расути су по контејнерима. Један од задатака је да се омогући погодан приступ евиденцијама преко веб интерфејса.

Извор: ввв.хабр.цом