Piedāvāju izlasīt Aleksandra Sigačova ziņojuma atšifrējumu no Inventos "Izstrādes un testēšanas process ar Docker + Gitlab CI"
Tie, kas tikai sāk ieviest izstrādes un testēšanas procesu, pamatojoties uz Docker + Gitlab CI, bieži uzdod pamata jautājumus. Kur sākt? Kā organizēt? Kā pārbaudīt?
Šis ziņojums ir labs, jo tajā strukturēti runāts par izstrādes un testēšanas procesu, izmantojot Docker un Gitlab CI. Pats ziņojums ir no 2017. gada. Domāju, ka no šī ziņojuma var uzzināt pamatus, metodiku, ideju, lietošanas pieredzi.
Kam tas interesē, lūdzu zem kaķa.
Mani sauc Aleksandrs Sigačovs. Es strādāju Inventos. Es jums pastāstīšu par savu Docker lietošanas pieredzi un to, kā mēs to pakāpeniski ieviešam projektos uzņēmumā.
Prezentācijas tēma: Izstrādes process, izmantojot Docker un Gitlab CI.
Šī ir mana otrā runa par Docker. Pirmā ziņojuma sagatavošanas laikā izstrādātāju iekārtās mēs izmantojām tikai Docker in Development. Darbinieku skaits, kuri izmantoja Docker, bija aptuveni 2-3 cilvēki. Pamazām pieredze tika uzkrāta un mēs pavirzāmies mazliet tālāk. Saite uz mūsu .
Kas būs šajā pārskatā? Dalīsimies pieredzē par to, kādu grābekli esam savākuši, kādas problēmas atrisinājām. Ne visur bija skaisti, bet ļāva doties tālāk.
Mūsu devīze ir: piestipriniet visu, ko varam paņemt.
Kādas problēmas mēs risinām?
Ja uzņēmumā ir vairākas komandas, programmētājs ir kopīgs resurss. Ir posmi, kad programmētāju izvelk no viena projekta un kādu laiku atdod citam projektam.
Lai programmētājs ātri saprastu, viņam pēc iespējas ātrāk jālejupielādē projekta pirmkods un jāpalaiž vide, kas ļaus viņam virzīties tālāk, risinot šī projekta problēmas.
Parasti, ja sākat no nulles, tad projektā ir maz dokumentācijas. Informācija par iestatīšanu ir pieejama tikai vecajiem lietotājiem. Darbinieki paši iekārto savu darba vietu vienas vai divu dienu laikā. Lai to paātrinātu, mēs izmantojām Docker.
Nākamais iemesls ir izstrādes iestatījumu standartizācija. Mana pieredze liecina, ka izstrādātāji vienmēr uzņemas iniciatīvu. Katrā piektajā gadījumā tiek ievadīts pielāgots domēns, piemēram, vasya.dev. Viņam blakus sēž viņa kaimiņiene Petja, kuras domēns ir petya.dev. Viņi izstrādā vietni vai kādu sistēmas komponentu, izmantojot šo domēna nosaukumu.
Kad sistēma attīstās un šie domēna nosaukumi sāk iekļūt konfigurācijās, rodas izstrādes vides konflikts un vietnes ceļš tiek pārrakstīts.
Tas pats notiek ar datu bāzes iestatījumiem. Kāds neuztraucas ar drošību un strādā ar tukšu root paroli. Instalēšanas stadijā MySQL kādam prasīja paroli, un parole izrādījās 123. Bieži gadās, ka datu bāzes konfigurācija pastāvīgi mainās atkarībā no izstrādātāja apņemšanās. Kāds izlaboja, kāds nelaboja konfigurāciju. Bija viltības, kad izņēmām kaut kādu testa konfigurāciju .gitignore un katram izstrādātājam bija jāinstalē datu bāze. Tas apgrūtināja darba sākšanu. Cita starpā ir jāatceras par datu bāzi. Jāinicializē datu bāze, jāievada parole, jāreģistrē lietotājs, jāizveido tabula utt.
Vēl viena problēma ir dažādas bibliotēku versijas. Bieži gadās, ka izstrādātājs strādā ar dažādiem projektiem. Ir Mantojuma projekts, kas sākās pirms pieciem gadiem (no 2017. gada – red. piez.). Palaišanas laikā mēs sākām ar MySQL 5.5. Ir arī moderni projekti, kuros cenšamies ieviest modernākas MySQL versijas, piemēram, 5.7 vai vecākas (2017. gadā – red. piezīme)
Ikviens, kas strādā ar MySQL, zina, ka šīs bibliotēkas rada atkarības. Ir diezgan problemātiski palaist 2 bāzes kopā. Vismaz vecajiem klientiem ir problemātiski izveidot savienojumu ar jauno datu bāzi. Tas savukārt rada vairākas problēmas.
Nākamā problēma ir tad, kad izstrādātājs strādā uz lokālas mašīnas, viņš izmanto vietējos resursus, lokālos failus, vietējo RAM. Visa mijiedarbība problēmu risinājuma izstrādes laikā tiek veikta, ņemot vērā faktu, ka tā darbojas vienā mašīnā. Piemērs ir, kad mums ir aizmugursistēmas serveri 3. ražošanas versijā, un izstrādātājs saglabā failus saknes direktorijā, un no turienes nginx ņem failus, lai atbildētu uz pieprasījumu. Kad šāds kods nonāk ražošanā, izrādās, ka fails atrodas vienā no 3 serveriem.
Šobrīd attīstās mikropakalpojumu virziens. Kad mēs sadalām savas lielās lietojumprogrammas dažos mazos komponentos, kas mijiedarbojas viens ar otru. Tas ļauj atlasīt tehnoloģijas noteiktai uzdevumu kopai. Tas arī ļauj sadalīt darbu un pienākumus starp izstrādātājiem.
Frondend izstrādātājs, kas izstrādā JS, gandrīz neietekmē Backend. Aizmugursistēmas izstrādātājs savukārt izstrādā, mūsu gadījumā, Ruby on Rails un netraucē Frondend. Mijiedarbība tiek veikta, izmantojot API.
Kā bonuss ar Docker palīdzību mēs varējām atkārtoti izmantot Staging resursus. Katram projektam savas specifikas dēļ bija nepieciešami noteikti iestatījumi. Fiziski bija nepieciešams piešķirt vai nu virtuālo serveri un tos konfigurēt atsevišķi, vai arī koplietot kaut kādu mainīgu vidi, un projekti atkarībā no bibliotēku versijas varēja ietekmēt viens otru.
Rīki. Ko mēs lietojam?
- Docker pats. Dockerfile apraksta vienas lietojumprogrammas atkarības.
- Docker-compose ir komplekts, kas apvieno dažas no mūsu Docker lietojumprogrammām.
- Mēs izmantojam GitLab, lai saglabātu pirmkodu.
- Sistēmas integrācijai mēs izmantojam GitLab-CI.
Ziņojums sastāv no divām daļām.
Pirmajā daļā tiks runāts par to, kā Docker tika darbināts izstrādātāju mašīnās.
Otrajā daļā tiks runāts par to, kā mijiedarboties ar GitLab, kā mēs veicam testus un kā mēs ieviešam Staging.
Docker ir tehnoloģija, kas ļauj (izmantojot deklaratīvu pieeju) aprakstīt nepieciešamos komponentus. Šis ir Dockerfile piemērs. Šeit mēs paziņojam, ka esam mantojuši no oficiālā Ruby:2.3.0 Docker attēla. Tajā ir instalēta Ruby versija 2.3. Mēs instalējam nepieciešamās būvju bibliotēkas un NodeJS. Mēs aprakstām, ka mēs izveidojam direktoriju /app. Iestatiet lietotņu direktoriju kā darba direktoriju. Šajā direktorijā ievietojam nepieciešamo minimālo Gemfile un Gemfile.lock. Pēc tam mēs veidojam projektus, kas instalē šo atkarības attēlu. Mēs norādām, ka konteiners būs gatavs klausīšanai ārējā portā 3000. Pēdējā komanda ir komanda, kas tieši palaiž mūsu lietojumprogrammu. Ja izpildām projekta starta komandu, lietojumprogramma mēģinās palaist un palaist norādīto komandu.
Šis ir minimāls docker-compose faila piemērs. Šajā gadījumā mēs parādām, ka starp diviem konteineriem ir savienojums. Tas ir tieši datu bāzes pakalpojumā un tīmekļa pakalpojumā. Mūsu tīmekļa lietojumprogrammām vairumā gadījumu ir nepieciešama kāda veida datubāze kā aizmugursistēma datu glabāšanai. Tā kā mēs izmantojam MySQL, piemērs ir ar MySQL, taču nekas neliedz mums izmantot kādu citu datu bāzi (PostgreSQL, Redis).
No oficiālā avota no Docker centrmezgla tiek ņemts MySQL 5.7.14 attēls bez izmaiņām. Mēs apkopojam attēlu, kas ir atbildīgs par mūsu tīmekļa lietojumprogrammu, no pašreizējā direktorija. Pirmās palaišanas laikā tas apkopo attēlu. Pēc tam tas palaiž komandu, kuru mēs šeit izpildām. Ja atgriezīsimies, mēs redzēsim, ka ir definēta palaišanas komanda, izmantojot Puma. Puma ir pakalpojums, kas rakstīts rubīnā. Otrajā gadījumā mēs ignorējam. Šī komanda var būt patvaļīga atkarībā no mūsu vajadzībām vai uzdevumiem.
Mēs arī aprakstām, ka mums ir jāpārsūta mūsu izstrādātāja resursdatora ports no 3000 līdz 3000 konteinera portā. Tas tiek darīts automātiski, izmantojot iptables un tā mehānismu, kas ir tieši iegults Docker.
Izstrādātājs tāpat kā iepriekš var piekļūt jebkurai pieejamai IP adresei, piemēram, 127.0.0.1 ir mašīnas vietējā vai ārējā IP adrese.
Pēdējā rindā teikts, ka tīmekļa konteiners ir atkarīgs no db konteinera. Kad mēs izsaucam tīmekļa konteinera sākumu, docker-compose vispirms sāks datu bāzi mūsu vietā. Jau datu bāzes sākumā (faktiski pēc konteinera palaišanas! Tas negarantē datu bāzes gatavību) tiks palaists lietojumprogramma, mūsu aizmugursistēma.
Tas ļauj izvairīties no kļūdām, kad datu bāze netiek atvērta, un ietaupa resursus, kad mēs apturam datu bāzes konteineru, tādējādi atbrīvojot resursus citiem projektiem.
Kas dod mums iespēju izmantot datu bāzes dokerizāciju projektā. Mēs labojam MySQL versiju visiem izstrādātājiem. Tas ļauj izvairīties no dažām kļūdām, kas var rasties, versijām atšķiras, mainoties sintaksei, konfigurācijai un noklusējuma iestatījumiem. Tas ļauj norādīt kopīgu resursdatora nosaukumu datubāzei, pieteikumvārdu, paroli. Mēs attālināmies no nosaukumu un konfliktu zoodārza konfigurācijas failos, kas mums bija agrāk.
Mums ir iespēja izstrādes videi izmantot optimālāku konfigurāciju, kas atšķirsies no noklusējuma. MySQL pēc noklusējuma ir konfigurēts vājām iekārtām, un tā veiktspēja ir ļoti slikta.
Docker ļauj izmantot vēlamās versijas Python, Ruby, NodeJS, PHP tulku. Mēs atbrīvojamies no nepieciešamības izmantot kaut kādu versiju pārvaldnieku. Iepriekš Ruby izmantoja rpm pakotni, kas ļāva mainīt versiju atkarībā no projekta. Tas arī ļauj, pateicoties Docker konteineram, vienmērīgi migrēt kodu un versijas to kopā ar atkarībām. Mums nav problēmu saprast gan tulka, gan koda versiju. Lai atjauninātu versiju, nolaidiet veco konteineru un paceliet jauno konteineru. Ja kaut kas nogāja greizi, varam nolaist jauno konteineru, pacelt veco konteineru.
Pēc attēla izveides gan izstrādes, gan ražošanas konteineri būs vienādi. Tas jo īpaši attiecas uz lielām instalācijām.
Frontend mēs izmantojam JavaScipt un NodeJS.
Tagad mums ir pēdējais ReacJS projekts. Izstrādātājs palaida visu konteinerā un izstrādāja, izmantojot karsto pārlādēšanu.
Pēc tam tiek palaists JavaScipt montāžas uzdevums, un kods, kas apkopots statikā, tiek dots, izmantojot nginx taupīšanas resursus.
Šeit es sniedzu mūsu pēdējā projekta shēmu.
Kādi uzdevumi tika atrisināti? Mums bija jāizveido sistēma, ar kuru mobilās ierīces mijiedarbojas. Viņi saņem datus. Viena iespēja ir nosūtīt push paziņojumus uz šo ierīci.
Ko mēs esam darījuši tā labā?
Lietojumprogrammā mēs sadalījām tādus komponentus kā: JS administratora daļa, aizmugursistēma, kas darbojas caur REST saskarni zem Ruby on Rails. Aizmugursistēma mijiedarbojas ar datu bāzi. Iegūtais rezultāts tiek nodots klientam. Administratora panelis mijiedarbojas ar aizmugursistēmu un datu bāzi, izmantojot REST interfeisu.
Mums bija arī jāsūta push paziņojumi. Pirms tam mums bija projekts, kurā tika ieviests mehānisms, kas ir atbildīgs par paziņojumu piegādi mobilajām platformām.
Mēs esam izstrādājuši šādu shēmu: pārlūkprogrammas operators mijiedarbojas ar administratora paneli, administratora panelis mijiedarbojas ar aizmuguri, uzdevums ir nosūtīt Push paziņojumus.
Push paziņojumi mijiedarbojas ar citu komponentu, kas ir ieviests NodeJS.
Tiek veidotas rindas un pēc tam tiek nosūtīti paziņojumi atbilstoši to mehānismam.
Šeit ir izveidotas divas datu bāzes. Šobrīd ar Docker palīdzību izmantojam 2 neatkarīgas datu bāzes, kas savā starpā nekādā veidā nav saistītas. Turklāt tiem ir kopīgs virtuālais tīkls, un fiziskie dati tiek glabāti dažādos direktorijās izstrādātāja mašīnā.
Tas pats, bet skaitļos. Šeit svarīga ir koda atkārtota izmantošana.
Ja iepriekš mēs runājām par koda atkārtotu izmantošanu bibliotēku veidā, tad šajā piemērā mūsu pakalpojums, kas reaģē uz Push paziņojumiem, tiek atkārtoti izmantots kā pilnīgs serveris. Tas nodrošina API. Un mūsu jaunā attīstība jau mijiedarbojas ar to.
Tajā laikā mēs izmantojām NodeJS 4. versiju. Tagad (2017. gadā – red. piezīme) jaunākajos izstrādēs mēs izmantojam NodeJS 7. versiju. Jaunos komponentos nav problēmu iesaistīt jaunas bibliotēku versijas.
Ja nepieciešams, varat pārveidot un paaugstināt NodeJS versiju no Push paziņojumu pakalpojuma.
Un, ja mēs varam saglabāt API savietojamību, tad to varēs aizstāt ar citiem projektiem, kas tika izmantoti iepriekš.
Kas nepieciešams, lai pievienotu Docker? Mēs savai krātuvei pievienojam Dockerfile, kurā ir aprakstītas nepieciešamās atkarības. Šajā piemērā komponenti ir sadalīti loģiski. Šī ir minimālā aizmugursistēmas izstrādātāja kopa.
Veidojot jaunu projektu, izveidojam Dockerfile, aprakstam vēlamo ekosistēmu (Python, Ruby, NodeJS). Programmā Docker-compose tas apraksta nepieciešamo atkarību - datu bāzi. Mēs aprakstam, ka mums ir vajadzīga tādas un tādas versijas datubāze, glabājiet datus tur un tur.
Mēs izmantojam atsevišķu trešo konteineru ar nginx, lai apkalpotu statisku. Ir iespēja augšupielādēt attēlus. Backend ievieto tos iepriekš sagatavotā sējumā, kas arī ir uzstādīts konteinerā ar nginx, kas dod statiku.
Lai saglabātu nginx, mysql konfigurāciju, mēs pievienojām Docker mapi, kurā saglabājam nepieciešamās konfigurācijas. Kad izstrādātājs savā datorā veic repozitorija git klonu, viņam jau ir vietējai attīstībai gatavs projekts. Nav šaubu, kādu portu vai kādus iestatījumus lietot.
Tālāk mums ir vairāki komponenti: administrators, inform-API, push paziņojumi.
Lai to visu sāktu, mēs izveidojām vēl vienu repozitoriju, ko nosaucām par dockerized-app. Pašlaik pirms katra komponenta mēs izmantojam vairākus repozitorijus. Tie vienkārši loģiski atšķiras – GitLab tā izskatās pēc mapes, bet izstrādātāja mašīnā – mape konkrētam projektam. Vienu līmeni zemāk ir komponenti, kas tiks apvienoti.
Šis ir tikai dockerized-app satura piemērs. Šeit mēs ienesam arī Docker direktoriju, kurā aizpildām visu komponentu mijiedarbībai nepieciešamās konfigurācijas. Ir README.md, kurā īsi aprakstīts, kā palaist projektu.
Šeit mēs esam lietojuši divus docker-compose failus. Tas tiek darīts, lai varētu skriet soļos. Kad izstrādātājs strādā ar kodolu, viņam nav nepieciešami push paziņojumi, viņš vienkārši palaiž docker-compose failu un attiecīgi tiek saglabāts resurss.
Ja ir nepieciešams integrēt ar push paziņojumiem, tiek palaists docker-compose.yaml un docker-compose-push.yaml.
Tā kā docker-compose.yaml un docker-compose-push.yaml atrodas mapē, automātiski tiek izveidots viens virtuālais tīkls.
Sastāvdaļu apraksts. Šis ir uzlabots fails, kas ir atbildīgs par komponentu vākšanu. Kas šeit ir ievērības cienīgs? Šeit mēs iepazīstinām ar balansētāja komponentu.
Šis ir gatavs Docker attēls, kurā darbojas nginx un lietojumprogramma, kas klausās Docker ligzdā. Dinamiska, jo konteineri tiek ieslēgti un izslēgti, tas atjauno nginx konfigurāciju. Mēs izplatām komponentu apstrādi ar trešā līmeņa domēna nosaukumiem.
Izstrādes videi mēs izmantojam .dev domēnu - api.informer.dev. Lietojumprogrammas ar .dev domēnu ir pieejamas izstrādātāja lokālajā datorā.
Turklāt konfigurācijas tiek pārsūtītas uz katru projektu un visi projekti tiek palaisti vienlaikus.
Grafiski izrādās, ka klients ir mūsu pārlūkprogramma vai kāds rīks, ar kuru mēs veicam pieprasījumus balansētājam.
Domēna vārda balansētājs nosaka, ar kuru konteineru sazināties.
Tas var būt nginx, kas dod administratoram JS. Tas var būt nginx, kas nodrošina API, vai statiski faili, kas tiek piešķirti nginx attēlu augšupielādes veidā.
Diagramma parāda, ka konteineri ir savienoti ar virtuālo tīklu un paslēpti aiz starpniekservera.
Izstrādātāja mašīnā jūs varat piekļūt konteineram, zinot IP, taču principā mēs to neizmantojam. Tieša piekļuve praktiski nav nepieciešama.
Kuru piemēru apskatīt, lai dokerizētu savu lietojumprogrammu? Manuprāt, labs piemērs ir oficiālais MySQL docker attēls.
Tas ir diezgan izaicinoši. Ir daudz versiju. Taču tā funkcionalitāte ļauj apmierināt daudzas vajadzības, kas var rasties turpmākās attīstības procesā. Ja jūs pavadīsit laiku un izdomāsit, kā tas viss mijiedarbojas, tad es domāju, ka jums nebūs problēmu ar pašrealizāciju.
Vietnē Hub.docker.com parasti ir saites uz vietni github.com, kas satur neapstrādātus datus, no kuriem tieši varat izveidot attēlu.
Tālāk šajā repozitorijā ir skripts docker-endpoint.sh, kas ir atbildīgs par sākotnējo inicializēšanu un lietojumprogrammas palaišanas turpmāku apstrādi.
Arī šajā piemērā ir iespēja konfigurēt, izmantojot vides mainīgos. Definējot vides mainīgo, palaižot vienu konteineru vai izmantojot docker-compose, mēs varam teikt, ka mums ir jāiestata tukša parole, lai docker varētu sakņot MySQL vai jebkurā citā vietā.
Ir iespēja izveidot nejaušu paroli. Mēs sakām, ka mums ir nepieciešams lietotājs, mums ir jāiestata lietotāja parole un jāizveido datu bāze.
Savos projektos mēs nedaudz apvienojām Dockerfile, kas ir atbildīgs par inicializāciju. Tur mēs to labojām atbilstoši savām vajadzībām, lai padarītu to tikai par lietojumprogrammas izmantoto lietotāja tiesību paplašinājumu. Tas ļāva mums vēlāk vienkārši izveidot datu bāzi no lietojumprogrammu konsoles. Ruby lietojumprogrammām ir komanda datu bāzu izveidei, modificēšanai un dzēšanai.
Šis ir piemērs tam, kā izskatās konkrēta MySQL versija vietnē github.com. Varat atvērt Dockerfile un redzēt, kā tur notiek instalēšana.
docker-endpoint.sh ir skripts, kas atbild par ieejas punktu. Sākotnējās inicializācijas laikā ir nepieciešamas dažas sagatavošanas darbības, un visas šīs darbības tiek veiktas tikai inicializācijas skriptā.
Pāriesim pie otrās daļas.
Lai saglabātu avota kodus, mēs pārgājām uz Gitlab. Šī ir diezgan jaudīga sistēma, kurai ir vizuāls interfeiss.
Viena no Gitlab sastāvdaļām ir Gitlab CI. Tas ļauj aprakstīt komandu secību, kas vēlāk tiks izmantota koda piegādes sistēmas organizēšanai vai automātiskās pārbaudes veikšanai.
Gitlab CI 2 saruna - ziņojums no Ruby Russia kluba - diezgan detalizēts un, iespējams, tas jūs interesēs.
Tagad mēs apskatīsim, kas ir nepieciešams, lai aktivizētu Gitlab CI. Lai palaistu Gitlab CI, mums vienkārši jāievieto .gitlab-ci.yml fails projekta saknē.
Šeit mēs aprakstām, ka vēlamies izpildīt stāvokļu secību, piemēram, pārbaudi, izvietošanu.
Mēs izpildām skriptus, kas tieši izsauc docker-compose, lai izveidotu mūsu lietojumprogrammu. Šis ir tikai aizmugures piemērs.
Tālāk mēs sakām, ka ir nepieciešams palaist migrāciju, lai mainītu datu bāzi un palaistu testus.
Ja skripti tiek izpildīti pareizi un neatgriež kļūdas kodu, sistēma attiecīgi pāriet uz otro izvietošanas posmu.
Izvēršanas posms pašlaik ir ieviests iestudēšanai. Mēs neorganizējām nulles dīkstāves restartēšanu.
Mēs piespiedu kārtā dzēšam visus konteinerus, un pēc tam atkal paceļam visus konteinerus, kas savākti pirmajā posmā pārbaudes laikā.
Mēs izmantojam pašreizējo vides mainīgo datu bāzes migrāciju, ko ir uzrakstījuši izstrādātāji.
Ir piezīme, ka tas attiecas tikai uz galveno filiāli.
Mainot citas filiāles, netiek izpildīts.
Ir iespējams organizēt izlaišanu pa filiālēm.
Lai to organizētu tālāk, mums jāinstalē Gitlab Runner.
Šī utilīta ir uzrakstīta Golang valodā. Tas ir viens fails, kā tas ir ierasts Golang pasaulē, un tam nav nepieciešamas nekādas atkarības.
Startējot, mēs reģistrējam Gitlab Runner.
Mēs iegūstam atslēgu Gitlab tīmekļa saskarnē.
Pēc tam komandrindā izsaucam inicializācijas komandu.
Gitlab Runner iestatīšana interaktīvi (Shell, Docker, VirtualBox, SSH)
Kods programmā Gitlab Runner tiks izpildīts katrā apņemšanās reizē atkarībā no .gitlab-ci.yml iestatījuma.
Kā tas izskatās vizuāli Gitlab tīmekļa saskarnē. Pēc tam, kad esam pievienojuši GItlab CI, mums ir karogs, kas parāda būvējuma pašreizējo stāvokli.
Redzam, ka pirms 4 minūtēm tika veikta apņemšanās, kas izturēja visus testus un nesagādāja nekādas problēmas.
Mēs varam tuvāk apskatīt būves. Šeit mēs redzam, ka divi stāvokļi jau ir pagājuši. Statusa un izvietošanas statusa testēšana iestudēšanas laikā.
Ja mēs noklikšķināsim uz konkrētas versijas, tiks parādīta konsoles izvade no komandām, kas tika izpildītas procesā saskaņā ar .gitlab-ci.yml.
Tā izskatās mūsu produktu vēsture. Redzam, ka bijuši veiksmīgi mēģinājumi. Kad testi ir iesniegti, tas netiek pāriet uz nākamo darbību un stadijas kods netiek atjaunināts.
Kādus uzdevumus mēs risinājām inscenēšanas laikā, ieviešot docker? Mūsu sistēma sastāv no komponentiem, un mums bija jārestartē tikai daļa no komponentiem, kas tika atjaunināti repozitorijā, nevis visa sistēma.
Lai to izdarītu, mums viss bija jāsadala atsevišķās mapēs.
Pēc tam, kad to izdarījām, mums radās problēma ar to, ka Docker-compose katram tētim izveido savu tīkla vietu un neredz kaimiņa komponentus.
Lai apietu, mēs izveidojām tīklu Docker manuāli. Programmā Docker-compose tika rakstīts, ka jūs izmantojat šādu tīklu šim projektam.
Tādējādi katrs komponents, kas sākas ar šo tīklu, redz komponentus citās sistēmas daļās.
Nākamā problēma ir iestudējuma sadalīšana vairākos projektos.
Tā kā, lai tas viss izskatītos skaisti un pēc iespējas tuvāk ražošanai, ir labi izmantot 80. vai 443. portu, kas tiek izmantots visur WEB.
Kā mēs to atrisinājām? Mēs esam piešķīruši vienu Gitlab Runner visiem lielākajiem projektiem.
Gitlab ļauj palaist vairākus izplatītus Gitlab Runners, kas vienkārši veiks visus uzdevumus pēc kārtas haotiskā veidā un izpildīs tos.
Lai mums nebūtu mājas, mēs ierobežojām savu projektu grupu ar vienu Gitlab Runner, kas bez problēmām tiek galā ar mūsu apjomiem.
Mēs pārvietojām nginx-proxy uz atsevišķu starta skriptu un pievienojām režģus visiem tajā esošajiem projektiem.
Mūsu projektam ir viens režģis, un balansētājam ir vairāki režģi pēc projektu nosaukumiem. To var tālāk izmantot, izmantojot domēna nosaukumus.
Mūsu pieprasījumi tiek saņemti caur domēnu portā 80 un tiek atrisināti konteineru grupā, kas apkalpo šo domēnu.
Kādas vēl problēmas bija? Tas ir tas, ko visi konteineri pēc noklusējuma darbojas kā root. Šī sakne ir nevienlīdzīga sistēmas saknes saimniekdatoram.
Tomēr, ja ievadāt konteineru, tas būs saknes statuss, un failam, ko izveidojam šajā konteinerā, tiek piešķirtas saknes tiesības.
Ja izstrādātājs iegāja konteinerā un veica dažas komandas, kas ģenerē failus, pēc tam atstāja konteineru, tad viņa darba direktorijā ir fails, kuram viņam nav piekļuves.
Kā to var atrisināt? Varat pievienot lietotājus, kuri atradīsies konteinerā.
Kādas problēmas radās, pievienojot lietotāju?
Veidojot lietotāju, mums bieži nav viens un tas pats grupas ID (UID) un lietotāja ID (GID).
Lai atrisinātu šo problēmu konteinerā, mēs izmantojam lietotājus ar ID 1000.
Mūsu gadījumā tas sakrita ar faktu, ka gandrīz visi izstrādātāji izmanto Ubuntu OS. Un Ubuntu pirmajam lietotājam ir 1000 ID.
Vai mums ir plāni?
Izlasiet Docker dokumentāciju. Projekts aktīvi attīstās, mainās dokumentācija. Dati, kas saņemti pirms diviem vai trim mēnešiem, jau pamazām noveco.
Dažas no mūsu atrisinātajām problēmām, iespējams, jau ir atrisinātas ar standarta līdzekļiem.
Tāpēc es gribu iet jau tālāk, lai dotos tieši uz orķestrēšanu.
Viens piemērs ir Docker iebūvētais mehānisms ar nosaukumu Docker Swarm, kas tiek izņemts no kastes. Es vēlos palaist kaut ko ražošanā, pamatojoties uz Docker Swarm tehnoloģiju.
Nārsta konteineri apgrūtina darbu ar baļķiem. Tagad baļķi ir izolēti. Tie ir izkaisīti pa konteineriem. Viens no uzdevumiem ir nodrošināt ērtu piekļuvi žurnāliem, izmantojot tīmekļa saskarni.
Avots: www.habr.com