Прапаную азнаёміцца з расшыфроўкай дакладу Аляксандра Сігачова з Inventos «Працэс распрацоўкі і тэставанні з Docker + Gitlab CI»
Тыя, хто толькі пачынае ўкараняць працэс распрацоўкі і тэставанні на базе Docker + Gitlab CI часта пытаюцца базавыя пытанні. З чаго пачаць? Як арганізаваць? Як тэсціраваць?
Гэты даклад добры тым, што структуравана распавядае аб працэсе распрацоўкі і тэсціраванні з выкарыстаннем Docker і Gitlab CI. Сам даклад 2017 года. Думаю што з гэтага дакладу можна запазычыць асновы, метадалогію, ідэю, досвед выкарыстання.
Каму цікава, прашу пад кат.
Мяне клічуць Аляксандр Сігачоў. Працую ў кампаніі Inventos. Распавяду аб сваім досведзе выкарыстання Docker і аб тым як яго патроху ўкараняем на праектах у кампаніі.
Тэма даклада: Працэс распрацоўкі з выкарыстаннем Docker і Gitlab CI.
Гэта мой другі даклад пра Docker. На момант першага дакладу мы выкарыстоўвалі Docker толькі ў Development на машынах распрацоўшчыкаў. Колькасць супрацоўнікаў, якія выкарыстоўвалі Docker, было каля 2-3 чалавек. Паступова быў назапашаны досвед і мы крыху прасунуліся далей. Спасылка на наш .
Што будзе ў гэтым дакладзе? Мы падзелімся досведам аб тым якія граблі сабралі, якія праблемы як вырашылі. Не ўсюды гэта было прыгожа, але дазволіла рушыць далей.
Наш дэвіз: дакерызуй усё, да чаго даходзяць нашы рукі.
Якія праблемы развязальны?
Калі ў кампаніі некалькі каманд, то праграміст з'яўляецца шараным рэсурсам. Бываюць этапы калі праграміста выдзіраюць з аднаго праекта і даюць на нейкі час у іншы праект.
Каб праграміст хутка ўнік яму неабходна спампаваць зыходны код праекта і як мага хутчэй запусціць асяроддзе, якая дазволіць яму далей прасоўвацца вырашаючы задачы дадзенага праекта.
Звычайна, калі пачынаць з нуля, то дакументацыі ў праекце вядзецца мала. Інфармацыя аб тым, як наладзіць, ёсць толькі ў старажылаў. Самастойна супрацоўнікі настройваюць сваё працоўнае месца за адзін-два дні. Каб гэта паскорыць, мы прымянілі Docker.
Наступны чыннік – гэта стандартызацыі налад у Development. На маю вопыту, распрацоўшчыкі заўсёды праяўляюць ініцыятыву. У кожным пятым выпадку ўводзіцца кастамным дамен, напрыклад vasya.dev. Побач сядзіць сусед Пеця, у якога дамен petya.dev. Яны распрацоўваюць сайт або нейкі кампанент сістэмы, выкарыстоўваючы гэтае даменнае імя.
Калі сістэма разрастаецца і гэтыя даменныя імёны пачынаюць трапляць у канфігурацыі, тое ўзнікае канфлікт Development асяродкаў і перапісваецца шлях сайта.
Тое ж самае адбываецца з настройкамі базы дадзеных. Хтосьці не затлумляецца бяспекай і працуе з пустым паролем root. У кагосьці на этапе ўсталёўкі MySQL запатрабаваў пароль і пароль апынуўся адзін 123. Часта здараецца, што канфіг базы дадзеных увесь час змяняўся ў залежнасці ад commit распрацоўніка. Нехта паправіў, нехта не паправіў канфіг. Былі хітрыкі, калі мы выносілі нейкі тэставы канфіг у .gitignore і кожны распрацоўшчык павінен быў усталёўваць базу дадзеных. Гэта ўскладняла працэс старту. Трэба таксама памятаць пра базу дадзеных. Базу даных трэба ініцыялізаваць, трэба прапісаць пароль, трэба прапісаць карыстальніка, стварыць таблічку і гэтак далей.
Яшчэ адна з праблем - гэта розныя версіі бібліятэк. Часта бывае, што распрацоўшчык працуе з рознымі праектамі. Ёсць Legacy праект, які пачыналі пяць гадоў таму (ад 2017 года — заўв. рэд.). У момант старту стартавалі з MySQL 5.5. Ёсць і сучасныя праекты, дзе мы імкнемся ўкараняць ужо больш сучасныя версіі MySQL, напрыклад 5.7 або старэйшыя (у 2017 годзе — заўв. рэд.)
Той, хто працуе з MySQL ведае, што гэтыя бібліятэкі цягнуць за сабой залежнасці. Дастаткова праблематычна запусціць 2 базы разам. Прынамсі, старыя кліенты праблематычна падключыць да новай базы дадзеных. Гэта спараджае ў сваю чаргу некалькі праблем.
Наступная праблема - гэта калі распрацоўнік працуе на лакальнай машыне, ён выкарыстоўвае лакальныя рэсурсы, лакальныя файлы, лакальнае АЗП. Усё ўзаемадзеянне на момант распрацоўкі рашэння задач выконваецца ў рамках таго, што гэта працуе на адной машыне. Прыкладам можа служыць, калі ў нас у Production 3 backend-сервера, а распрацоўнік захоўвае файлы ў каранёвай каталог і адтуль nginx бярэ файлы для адказу на запыт. Калі такі код пападае ў Production, тое атрымліваецца, што файл прысутнічае на адным з 3 сервераў.
Цяпер развіваецца напрамак мікрасэрвісаў. Калі мы дзелім нашы вялікія прыкладанні на нейкія невялікія кампаненты, якія ўзаемадзейнічаюць паміж сабой. Гэта дазваляе пад пэўны стэк задач абраць тэхналогіі. Гэтак жа гэта дазваляе падзяліць працу і зону адказнасці паміж распрацоўнікамі.
Frondend-распрацоўшчык, распрацоўваючы на JS, практычна не ўплывае на Backend. Backend-распрацоўшчык у сваю чаргу распрацоўвае, у нашым выпадку, Ruby on Rails і не мяшае Frondend. Узаемадзеянне выконваецца пры дапамозе 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. У дадзеным выпадку мы паказваем, што адбываецца сувязь двух кантэйнераў. Гэта непасрэдна ў сэрвіс базы даных і сэрвіс web. Нашы web-прыкладанні ў большасці выпадках патрабуюць у якасці backend для захоўвання дадзеных нейкую базу дадзеных. Так як мы выкарыстоўваем MySQL, то прыклад з MySQL – але нішто не перашкаджае выкарыстоўваць нейкую сябру базу дадзеных (PostgreSQL, Redis).
Мы бярэм з афіцыйнай крыніцы з Docker hub выява MySQL 5.7.14 без змен. Выява, які адказвае за наша web-дадатак мы збіраем з бягучай дырэкторыі. Ён падчас першага запуску збірае нам выяву. Пасля чаго запускае каманду, якую мы тут выконваем. Калі мы вернемся назад, то ўбачым, што была вызначана каманда запуску праз Puma. Puma - сэрвіс, напісаны на Ruby. У другім выпадкам мы перавызначаем. Гэтая каманда можа быць адвольнай у залежнасці ад нашых патрэб ці задач.
Таксама мы апісваем што трэба пракінуць порт на нашай хост-машыне распрацоўшчыка з 3000 на 3000 порт кантэйнера. Гэта выконваецца аўтаматычна пры дапамозе iptables і свайго механізма, які непасрэдна закладзены ў Docker.
Распрацоўнік можа таксама па-ранейшаму звярнуцца на любы даступны IP-адрас, напрыклад, 127.0.0.1 лакальны ці вонкавы IP-адрас машыны.
Апошні радок кажа, што кантэйнер web залежыць ад кантэйнера db. Калі мы выклікаем запуск кантэйнера web папярэдне docker-compose запусціць нам базу дадзеных. Ужо па старце базы дадзеных (на самай справе - пасля запуску кантэйнера! Гатоўнасці БД гэта не гарантуе) запусціць нам прыкладанне, наш backend.
Гэта дазваляе пазбегнуць памылак, калі база дадзеных не паднятая і дазваляе эканоміць рэсурсы, калі мы спыняем кантэйнер баз дадзеных, вызваляючы гэтым сам рэсурсы пад іншыя праекты.
Што нам дае выкарыстанне дакерызацыі базы даных на праекце. Мы ва ўсіх распрацоўшчыкаў фіксуем версію MySQL. Гэта дазваляе пазбегнуць некаторых памылак, якія могуць узнікнуць пры разыходжанні версій, калі змяняецца сінтаксіс, канфігурацыя, дэфолтныя налады. Гэта дазваляе пазначыць агульныя hostname для базы дадзеных, login, password. Адыходзім ад таго заапарка імёнаў і канфліктаў у config-файлаў, якія былі раней.
Мы маем магчымасць выкарыстоўваць больш аптымальны config для Development асяроддзя, які будзе адрознівацца ад дэфолтнага. MySQL па змаўчанні настроены на слабыя машыны і яго прадукцыйнасць са скрынкі вельмі нізкая.
Docker дазваляе выкарыстоўваць інтэрпрэтатар Python, Ruby, NodeJS, PHP патрэбнай версіі. Мы пазбаўляемся неабходнасці выкарыстоўваць нейкі менеджэр версій. Раней для Ruby выкарыстоўвалі rpm-пакет, які дазваляў мяняць версію ў залежнасці ад праекту. Таксама гэта дазваляе дзякуючы Docker-кантэйнеру плаўна міграваць код і версіяваць яго разам залежнасцямі. У нас не ўзнікае праблемы зразумець версію як інтэрпрэтатара, так і кода. Для абнаўлення версіі неабходна апусціць стары кантэйнер і падняць новы кантэйнер. Калі што пайшло не так, мы можам апусціць новы кантэйнер, падняць стары кантэйнер.
Пасля зборкі выявы кантэйнеры як у Development так і ў Production будзе аднолькавымі. Гэта асабліва актуальна для вялікіх усталёвак.
На Frontend мы выкарыстоўваем JavaScipt і NodeJS.
Цяпер апошні праект у нас на ReacJS. Распрацоўнік запускаў усе кантэйнеры і распрацоўваў выкарыстоўваючы hot-reload.
Далей запускаецца задача па зборцы JavaScipt і код, сабраны ў статыку, аддаецца праз nginx эканомячы рэсурсы.
Тут я прывёў схему нашага апошняга праекту.
Якія задачы рашалі? У нас узнікла неабходнасць пабудаваць сістэму, з якой узаемадзейнічае мабільныя прылады. Яны атрымліваюць дадзеныя. Адна з магчымасцяў паслаць push-паведамлення ў дадзеную прыладу.
Што мы дзеля гэтага зрабілі?
Мы падзялілі на дадатак такія кампаненты як: адмінская частка на JS, backend, які працуе праз REST-інтэрфейс пад Ruby on Rails. Backend ўзаемадзейнічае з базай дадзеных. Вынік, які генеруецца аддаюцца кліенту. Адмінка з backend і базай дадзеных узаемадзейнічае па REST-інтэрфейсу.
Таксама ў нас была неабходнасць адпраўляць Push апавяшчэння. Да гэтага ў нас быў праект, у якім было рэалізаваны механізм, які адказвае за дастаўку апавяшчэнняў на мабільныя платформы.
Мы распрацавалі такую схему: аператар з браўзэра ўзаемадзейнічае з адмінкай, адмінка ўзаемадзейнічае з backend, ставіцца задача што трэба паслаць Push апавяшчэнні.
Push апавяшчэння ўзаемадзейнічаюць з іншым кампанентам, які рэалізаваны на NodeJS.
Будуюцца чэргі і далей ідзе па сваім механізме адпраўка апавяшчэнняў.
Тут намаляваны дзве базы даных. На бягучы момант у нас пры дапамозе Docker выкарыстоўваюцца 2 незалежныя базы дадзеных, якія ніяк не злучаны з сабой. Акрамя таго, што ў іх гэта агульная віртуальная сетка, а фізічныя дадзеныя захоўваюцца ў розных каталогах на машыне распрацоўшчыка.
Тое ж самае але ў лічбах. Тут важна перавыкарыстанне кода.
Калі раней мы казалі пра перавыкарыстанне кода ў выглядзе бібліятэк, то ў дадзеным прыкладзе наш сэрвіс, які адказвае 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 socket. Дынамічныя, па меры ўключэння і выключэнні кантэйнераў, перагенуе канфіг 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 можна сказаць што нам трэба задаць пусты пароль для docker на для root на MySQL ці альбо нейкі, які мы жадаем.
Ёсць варыянт стварыць рандомны пароль. Мы кажам што нам патрабуецца карыстач, патрабуецца ўсталяваць карыстачу пароль і патрабуецца стварыць базу дадзеных.
У сваіх праектах мы крыху ўніфікавалі Dockerfile, які адказвае за ініцыялізацыю. Там мы паправілі пад свае патрэбы зрабіць проста пашырэнне правоў карыстальніка, якую выкарыстоўвае дадатак. Гэта дазволіла ў далейшым проста стварыць базу дадзеных з кансолі дадатку. У Ruby прыкладаннях ёсць каманда стварэння, змены і выдаленні баз дадзеных.
Гэты прыклад таго, як выглядае канкрэтная версія MySQL на github.com. Dockerfile можна адкрыць і паглядзець як там адбываецца ўстаноўка.
docker-endpoint.sh скрыпт які адказвае за кропку ўваходу. Пры першаснай ініцыялізацыі патрабуюцца некаторыя дзеянні па падрыхтоўцы і ўсе гэтыя дзеянні вынесены якраз у скрыпт ініцыялізацыі.
Пераходзім да другой часткі.
Для захоўвання зыходных кодаў мы перайшлі на gitlab. Гэта дастаткова магутная сістэма, якая мае візуальны інтэрфейс.
Адзін з кампанентаў Gitlab з'яўляецца Gitlab CI. Ён дазваляе апісваць рушыць услед каманд, якія пасля будуць выкарыстоўвацца таго каб арганізаваць сістэму дастаўкі кода ці запуску аўтаматычнага тэставання.
Даклад па Gitlab CI 2 - даклад з Ruby Russia club - досыць падрабязны і магчыма ён вас зацікавіць.
Цяпер мы з вамі разгледзім што патрабуецца для таго, каб актываваць Gitlab CI. Для таго каб запусціць Gitlab CI нам дастаткова ў корань праекта пакласці файлік .gitlab-ci.yml.
Тут мы апісваем што мы жадаем выконваць паслядоўнасць станаў тыпу тэсту, дэплою.
Выконваем скрыпты, якія выклікаюць непасрэдна docker-compose зборку нашага прыкладання. Гэта прыклад якраз backend.
Далей мы кажам, што неабходна прагнаць міграцыі па змене базы дадзеных і выканаць тэсты.
Калі скрыпты выконваюцца карэктна і не вяртае код памылкі, то адпаведна сістэма пераходзіць да другой стадыі дэплою.
Стадыя дэплою на бягучы момант рэалізавана для staging. Мы не арганізоўвалі беспрастойны перазапуск.
Мы прымусова гасім усе кантэйнеры, а потым усе кантэйнеры паднімаем нанова, сабраныя на першым этапе пры тэставанні.
Праганяем ужо для бягучага пераменнага асяроддзя міграцыі баз даных, якія былі напісаны распрацоўшчыкамі.
Ёсць пазнака, што прымяняць гэта толькі для галінкі майстар.
Пры змене іншых галінак не выконваецца.
Ёсць магчымасць арганізаваць выкаткі па галінках.
Каб далей гэта арганізаваць, нам трэба ўстанавіць Gitlab Runner.
Гэта ўтыліта напісана на Golang. Яна з'яўляецца адзінкавым файлам як гэта прынята ў свеце Golang, якія не патрабуецца ніякіх залежнасцяў.
Пры запуску мы рэгіструем Gitlab Runner.
Атрымліваем у web-інтэрфейсе Gitlab ключ.
Потым выклікаем каманду ініцыялізацыі ў камандным радку.
Наладжваем Gitlab Runner у дыялогавым рэжыме (Shell, Docker, VirtualBox, SSH)
Код на Gitlab Runner будзе выконваць пры кожным каментары ў залежнасці ад налады .gitlab-ci.yml.
Як гэта візуальна выглядае ў Gitlab у web-інтэрфейсе. Пасля таго як падключылі 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.
Спараджэнне кантэйнераў робіць нязручнасць працу з логамі. Цяпер логі ізаляваныя. Яны раскіданыя па кантэйнерах. Адна з задач зрабіць зручны доступ да логаў праз web-інтэрфейс.
Крыніца: habr.com