Arenduse ja testimise protsess Dockeris ja GitLab CI-s

Soovin tutvustada Alexander Sigatšovi ettekande analüüsi ettevõttest Inventos "Arenduse ja testimise protsess Dockeris + GitLab CI-s"

Need, kes just alustavad Docker + GitLab CI arenduse ja testimise protsessi rakendamist, küsivad sageli põhiküsimusi. Kust alustada? Kuidas korraldada? Kuidas teste teha?

See ettekande on hea, kuna see struktureeritult räägib arenduse ja testimise protsessist Dockerit ja GitLab CI-d kasutades. Ettekande originaal on aastast 2017. Olen kindel, et selle ettekande kaudu on võimalik omandada põhialuseid, metoodikat, ideed ja kasutuskogemust.

Huvitav, palun vaata edasi.

Minu nimi on Alexander Sigatšov. Töötan ettevõttes Inventos. Räägin oma kogemusest Dockerit kasutades ja sellest, kuidas me seda järk-järgult oma projektides rakendame.

Ettekande teema: Arendusprotsess Dockerit ja GitLab CI-d kasutades.

See on minu teine ettekande Dockerist. Esimese ettekande ajal kasutasime Dockerit ainult arenduses arendajate masinates. Töötajate arv, kes Dockerit kasutasid, oli umbes 2-3 inimest. Aja jooksul oleme omandanud kogemusi ja liikunud natuke edasi. Lingid meie esimene ettekande.

Mida käsitletakse selles ettekandes? Jagame kogemusi, mida komistuskive oleme kohanud ja kuidas oleme probleeme lahendanud. See ei ole alati olnud ilus, kuid võimaldas edasi liikuda.

Meie moto: dockerige kõik, mida meie käed ulatuvad.

Milliseid probleeme lahendame?

Kui ettevõttes on mitu meeskonda, on programmeerija jagatud ressurss. On etappe, kus programmeerija tõmmatakse ühe projektist välja ja antakse mõneks ajaks teise projekti.

Et programmeerija saaks kiiresti sisse elada, peab ta allalaadima projekti lähtekoodi ja võimalikult kiiresti käivitama keskkonna, mis võimaldab tal edasi liikuda, lahendades antud projekti ülesandeid.

Tavaliselt, kui alustada nullist, on projekti dokumentatsioon napp. Teave seadistamise kohta on ainult vanadel töötajatel. Töötajad seadistavad oma töökoha iseseisvalt ühe kuni kahe päeva jooksul. Selle protsessi kiirendamiseks rakendasime Dockeri.

Järgmine põhjus on seadete standardiseerimine arenduses. Minu kogemuse järgi on arendajad alati algatusvõimelised. Igas viiendas juhtumis kasutatakse kohandatud domeeni, näiteks vasya.dev. Kõrval istub naaber Pjotr, kellel on domeen petya.dev. Nad arendavad veebisaiti või mõnda süsteemi komponenti, kasutades seda domeeninime.

Kui süsteem laienevad ja need domeeninimid hakkavad sattuma seadistustesse, siis tekib arenduse keskkondade konflikt ja veebisaidi tee kirjutatakse ümber.

Sama juhtub andmebaasi seadistustega. Keegi ei mõtle turvalisusele ja töötab tühja root-parooliga. Kellegi installimise ajal nõudis MySQL parooli ja see osutus 123. Sage on see, et andmebaasi konfi muudeti pidevalt arendaja commit'i põhjal. Keegi parandas, keegi ei parandanud konfi. Oli nutikusi, kus me tõime mõne testkonfi välja. .gitignore ja iga arendaja pidi andmebaasi installima. See raskendas protsessi alustamist. Lisaks sellele tuleb meeles pidada ka andmebaasi. Andmebaas tuleb initsialiseerida, tuleb määrata parool, määrata kasutaja, luua tabel ja nii edasi.

Veel üks probleem on erinevad raamatukogude versioonid. Sageli juhtub, et arendaja töötab erinevate projektidega. On Legacy projekt, mida alustati viis aastat tagasi (2017. aastast — toim. märkus). Alustamisel kasutati MySQL 5.5. On ka kaasaegseid projekte, kus püüame rakendada juba uuemaid MySQL versioone, näiteks 5.7 või vanemaid (2017. aastal — toim. märkus).

Kes töötab MySQL-iga, teab, et need raamatukogud kaasnevad sõltuvustega. On üsna problemaatiline käivitada kahte andmebaasi korraga. Vähemalt vanade klientide ühendamine uue andmebaasiga on keeruline. See tekitab omakorda mitmeid probleeme.

Järgmine probleem tekib siis, kui arendaja töötab kohalikes keskkondades. Ta kasutab kohalikke ressursse, kohalikke faile ja kohalikku RAM-i. Kõik interaktsioonid probleemide lahendamise hetkel toimuvad selle raames, et see töötab ühel seadmel. Näiteks võib tuua olukorra, kus meie tootmises on 3 tagapoolte serverit, kuid arendaja salvestab failid juurkatalooge ja Nginx võtab failid sealt vastamiseks. Kui selline kood jõuab tootmisse, on fail siiski kohal vaid ühel kolmest serverist.

Praegu areneb mikroteenuste suund. Kui jagame oma suured rakendused väiksemate komponentideks, mis omavahel suhtlevad. See võimaldab valida tehnoloogiad vastavalt konkreetsele ülesande kogumile. Samuti võimaldab see jagada tööd ja vastutuse valdkondi arendajate vahel.

Frontend-arendaja, arendades JavaScripti, ei mõjuta tagapoolt. Tagapoolte arendaja omakorda arendab, meie puhul, Ruby on Rails'i ja ei sega frontend'i. Suhtlus toimub API kaudu.

Boonusena kasutades suutsime Dockeriga ära kasutada ressursse Stagingus. Iga projekt nõudis oma eripärast tingituna spetsiifilisi seadistusi. Füüsiliselt tuli kas eraldada igaühele virtuaalserver või seada need eraldi, või jagada mõni muutuv keskkond, mille tõttu projektide üksteisega sõltuvalt teegiversioonidest suhtlemine mõjutas.

Tööriistad. Mida me kasutame?

• Otseselt ise Dockerit. Dockerfile'is määratakse ühe rakenduse sõltuvused.
• Docker-compose on kombinatsioon, mis ühendab mitmeid meie Docker rakendusi.
• GitLabit kasutame lähtekoodi hoidmiseks.
• GitLab-CI't kasutame süsteemseks integreerimiseks.

Ettekanne koosneb kahest osast.

Esimene osa räägib sellest, kuidas käivitasime Dockerit arendajate masinates.

Teine osa räägib, kuidas suhelda GitLabiga, kuidas käivitame teste ja kuidas viime Stagingusse.

Docker — see tehnoloogia, mis võimaldab (kasutades deklareerivat lähenemist) kirjeldada vajalikke komponente. See on näidis Dockerfile'ist. Siin kuulutame, et me pärime ametlikust Docker-pildist Ruby: 2.3.0. See sisaldab installitud Ruby versiooni 2.3. Me installime vajalikud ehitusraamatukogud ja NodeJS. Kirjeldame, et loome katalooge. /appMäärame katalooge app töökaustaks. Selle katalooge paigutame vajaliku minimaalset Gemfile'i ja Gemfile.lock'i. Seejärel täidame projektide koostamise, mis installivad sõltuvused, mis on selle pildi jaoks vajalikud. Näitame, et konteiner on valmis kuulama välisel pordil 3000. Viimane käsk on käsk, mis käivitab meie rakenduse. Kui me käivitame projekti, siis rakendus püüab töötada ja käivitab antud käsu.

See on minimaalne näide docker-compose failist. Antud juhul näitame, kuidas ühendatakse kahte konteinerit: andmebaasi teenus ja veebi teenus. Meie veebi rakendused vajavad peamiselt andmete salvestamiseks mingit andmebaasi. Kuna kasutame MySQL-i, toome näite MySQL-i pealt, kuid pole midagi takistada ka mõne teise andmebaasi (PostgreSQL, Redis) kasutamisel.

Võtame ametlikust allikast Docker hub-ist MySQL 5.7.14 pildi ilma muudatusteta. Pilt, mis vastutab meie veebi rakenduse eest, kogume käesolevast kataloogist. Esimese käivitamise ajal loob see meile pildi. Pärast seda käivitab käsu, mida siin täidame. Kui läheme tagasi, näeme, et käivitamise käsk on määratud Puma kaudu. Puma on Ruby-s kirjutatud teenus. Teises puhul üle kirjutame. See käsk võib olla suvaline, sõltuvalt meie vajadustest või ülesannetest.

Kirjeldame ka, et tuleb edastada port meie arendaja host-masinas, mis on 3000 ja konteineri 3000 port. See toimub automaatselt iptables'i ja Dockerisse sisseehitatud mehhanismi abil.

Arendaja saab nagu varem pöörduda mis tahes saadaval oleva IP-aadressi poole, näiteks 127.0.0.1 kohaliku või välist IP-aadressi poole.

Viimane rida ütleb, et web konteiner sõltub db konteinerist. Kui kutsume üles web konteineri käivitamist, käivitab docker-compose eelnevalt meie andmebaasi. Andmebaasi käivitamine (tegelikult pärast konteineri käivitamist! Andmebaasi valmidust see ei garanteeri) käivitab meie rakenduse, meie backend'i.

See võimaldab vältida vigu, kui andmebaas ei ole käivitatud, ja aitab säästa ressursse, kui peatame andmebaasi konteineri, vabastades seeläbi ressursid teiste projektide jaoks.

Mida me saame projekti andmebaasi dockeriseerimisega. Me fikseerime kõigile arendajatele MySQL versiooni. See aitab vältida mõningaid vigu, mis võivad tekkida versioonide lahknevuse tõttu, kui muutub süntaks, konfiguratsioon või vaike seadistused. See võimaldab määrata ühised hostname, login ja password andmebaasi jaoks. Loodame loobuda varasemast konfigureerimist failide nimetuste segadusest ja konfliktidest.

Meil on võimalus kasutada arenduskeskkonnas optimeeritumat seadistust, mis erineb vaikeseadistusest. MySQL on vaikimisi seadistatud nõrkade masinate jaoks ja selle jõudlus on algselt väga madal.

Docker võimaldab kasutada vajalikku versiooni Python, Ruby, NodeJS, PHP tõlgendajat. Me vabaneme vajadusest kasutada mingit versioonihaldurit. Varem kasutasime Ruby jaoks rpm-paketti, mis võimaldas muuta versiooni vastavalt projektile. See võimaldab Docker-konteineri kaudu sujuvalt migreerida koodi ja versioonida seda koos sõltuvustega. Meil ei teki probleemi teada, milline on nii tõlgendaja kui ka koodi versioon. Versiooniuuendamiseks tuleb vana konteiner peatada ja uus konteiner üles tõsta. Kui midagi läheb valesti, saame uue konteineri peatada ja vana konteineri taas üles tõsta.

Pärast pildi koostamist on konteinerid nii arenduses kui tootmises identsed. See on eriti oluline suurte paigaldiste korral.

Frondendis kasutame JavaScripti ja NodeJS-i.

Meie viimane projekt on praegu ReacJS-is. Arendaja käivitas kõik konteinerid ja töötas kuumlaadimisega.

See rikas JavaScript'i ülesanne ja koondatud kood antakse nginx'i kaudu edasi, säästes ressursse.

Siin on meie viimane projekti skeem.

Milliseid ülesandeid lahendasime? Meil oli vajalik luua süsteem, millega suhtlevad mobiilseadmed. Need saavad andmeid. Üks võimalus on saata push-teateid sellesse seadmesse.

Mida me selleks tegime?

Jagasime rakenduse sellisteks komponentideks nagu: administraatori osa JS'is, backend, mis töötab REST-liidese kaudu Ruby on Rails'is. Backend suhtleb andmebaasiga. Tulemused, mis genereeritakse, antakse kliendile. Administraator ja backend suhtlevad ja andmebaas REST-liidese kaudu.

Samuti oli meil vajadus saata Push-teateid. Enne seda oli meil projekt, kus oli rakendatud mehhanism, mis vastutas teadete edastamise eest mobiilplatvormidele.

Me töötasime välja sellise skeemi: operaator brauserist suhtleb administraatori osaga, administraator suhtleb backend'iga, seatakse ülesanne saata Push-teateid.

Push-teated suhtlevad teise komponendiga, mis on rakendatud NodeJS'is.

Oote järjekorrad ja edasine teavitamise mehhanism toimib selle järgi.

Siin on joonistatud kaks andmebaasi. Hetkel kasutame me Dockerit, et hallata 2 iseseisvat andmebaasi, mis ei ole omavahel seotud. Ainus seos on see, et neil on ühine virtuaalne võrk, samas kui füüsilised andmed on salvestatud arendaja masina erinevatesse kataloogidesse.

Sama asi, kuid numbritega. Siin on koodide taaskasutamine oluline.

Kui varem rääkisime koodide taaskasutamisest raamatukogudena, siis antud näites meie teenus, mis vastutab Push-teavituste eest, taaskasutatakse täieliku serverina. See pakub API-d. Ja meie uus arendus suhtleb sellega.

Sel hetkel kasutasime me NodeJS versiooni 4. Praegu (2017. aastal — märkus toimetajalt) kasutame me uutes arendustes NodeJS versiooni 7. Uutes komponentides ei ole probleemiks kasutada uusi raamatukogude versioone.

Vajadusel saab läbi viia refaktoreerimise ja tõsta NodeJS versiooni Push-teavituste teenuses.

Ja kui suudame säilitada API ühilduvuse, saame selle asendada teiste projektidega, millega oleme varem töötanud.

Mida on vaja, et lisada Docker? Lisame meie hoidlasse Dockerfile'i, mis kirjeldab vajalikke sõltuvusi. Antud näites on komponendid jagatud loogika järgi. See on minimaalne komplekt backend-arendajale.

Uue projekti loomisel loome Dockerfile'i, kirjeldame vajalikku ökosüsteemi (Python, Ruby, NodeJS). Docker-compose'is kirjeldame vajalike sõltuvuste — andmebaasi. Kirjeldame, et vajame andmebaasi teatud versioonis, andmete salvestamiseks seal ja seal.

Kasutame staatika edastamiseks eraldi kolmandat konteinerit nginx'iga. On ette nähtud piltide laadimise võimalus. Backend paigutab need juba ette valmistatud mahutisse, mis on samuti monteeritud nginx'iga konteinerisse, mis edastab staatikat.

Nginx'i ja mysql'i konfiguratsiooni hoidmiseks lisasime kausta Docker, kus hoiame vajalikke konfiguratsioone. Kui arendaja teeb git clone'i hoidlast oma arvutisse, on tal juba projekt valmis kohalikuks arendamiseks. Küsimust ei teki, millist porti või milliseid seadeid rakendada.

Edasi on meil mitu komponenti: admin, inform-API, push-teavitused.

Selle kõike käivitamiseks oleme loonud veel ühe reposti, mille nimeks panime dockerized-app. Praegu kasutame mitu reposti igale komponendile. Need erinevad lihtsalt loogiliselt — GitLabis näeb see välja nagu kaust, ja arendaja seadmes on see konkreetse projekti kaust. Madalamal tasemel asuvad komponendid, mis saavad ühenduda.

See on just dockerized-app sisu näide. Toome siia ka Docker katalooge, kuhu täidame konfiguratsioonid, mis on vajalikud kõigi komponentide vaheliseks suhtlemiseks. Seal on README.md, kus on lühidalt seletatud, kuidas projekti käivitada.

Siin oleme kasutanud kahte docker-compose faili. See on tehtud selleks, et arendaja saaks seda käitada samm-sammult. Kui arendaja töötab põhikomplektiga ja Push-teavitusi ei vaja, käivitab ta lihtsalt docker-compose faili, säästes seeläbi ressursse.

Kui on vaja integreerida Push-teavitusi, siis käivitub docker-compose.yaml ja docker-compose-push.yaml.

Kuna docker-compose.yaml ja docker-compose-push.yaml asuvad kaustas, luuakse automaatselt ühine virtuaalne võrk.

Komponentide kirjeldus. See on ulatuslikum fail, mis vastutab komponentide kogumise eest. Mis siin tähelepanuväärne? Siin me tutvustame tasakaalustajat.

See on valmis Docker-pilt, kus töötab nginx ja rakendus, mis kuulab Docker soket. Dünaamiliselt, konteinerite sisse- ja väljalülitamise käigus, genereeritakse nginx konfiguraatsioon uuesti. Komponentidega suhtlemine toimub kolmanda tasandi domeeninimede kaudu.

Arenduskeskkonnas kasutame domeeni .dev — api.informer.dev. Rakendused domeeniga .dev on arendaja kohalikul masinal kergesti ligipääsetavad.

Seejärel edastatakse konfiguraatsioonid iga projekti juurde ja käivitatakse kõik projektid koos samal ajal.

Kui joonistada graafiliselt, siis klient on meie brauser või mõni muu tööriist, millega me esitame taotlusi tasakaalustajale.

Tasakaalustaja määrab domeeninime kaudu, millise konteineriga ühendust võtta.

See võib olla nginx, mis edastab JS administraatoreid. See võib olla nginx, mis edastab API-d või staatilisi faile, mida nginx edastab piltide allalaadimisel.

Kavas on nähtav, et konteinerid on ühendatud virtuaalsesse võrku ja peidetud proksi taha.

Arendaja masinasse on võimalik konteinerile juurde pääseda, tundes IP-d, kuid me ei kasuta seda põhimõtteliselt. Otsese juurdepääsu vajadusi praktiliselt ei esine.

Millist näidet peaks vaatama, et oma rakendust dockeriseerida? Minu arvates on ametlik MySQL docker pilt hea näide.

See on piisavalt keeruline. Seal on palju versioone. Kuid selle funktsionaalsus katab mitmeid vajadusi, mis võivad arenguprotsessis tekkida. Kui kulutate aega ja mõistate, kuidas kõik see omavahel toimib, siis arvan, et iseseisvas rakenduses teil probleeme ei teki.

Hub.docker.com lehelt leiate tavaliselt lingid github.com-ile, kus on toodud toored andmed, mille põhjal saate ise pildi kokku panna.

Edasi, selles repos on olemas skript docker-endpoint.sh, mis vastutab esialgse initsialiseerimise ja rakenduse käivitamise edasise töötlemise eest.

Selles näites on samuti olemas seadistusvõimalus keskkonnamuutujate kaudu. Määrates keskkonnamuutujat kas üksiku konteineri käivitamisel või docker-compose'i kaudu, saame öelda, et peame seadma MySQL-i root-kasutajale tühja parooli või mõne muu, mille soovime.

On võimalus luua juhuslik parool. Ütleme, et vajame kasutajat, peame kasutajale parooli seadma ja looma andmebaasi.

Oma projektides oleme natuke ühtlustanud Dockerfile'i, mis vastutab initsialiseerimise eest. Oleme selle oma vajadustele vastavaks muutnud, et lihtsalt laiendada rakenduse kasutaja õigusi. See võimaldas hiljem lihtsalt luua andmebaasi rakenduse konsolist. Ruby rakendustes on käsk andmebaaside loomise, muutmise ja kustutamise jaoks.

See on näide sellest, kuidas konkreetne MySQL-i versioon välja näeb github.com-is. Dockerfile'i saab avada ja vaadata, kuidas seal installimine toimub.

docker-endpoint.sh skript, mis vastutab sisenemispunkti eest. Algse seadistamise käigus on vajalikud teatud ettevalmistustegevused ja kõik need tegevused on koondatud just algatusskripti.

Liigume teise osa juurde.

Allikakoodide salvestamiseks oleme läinud gitlabi. See on piisavalt võimas süsteem, millel on visuaalne liides.

Üks Gitlabi komponente on Gitlab CI. See võimaldab kirjeldada käske, mis hiljem kasutatakse koodide tarnesüsteemi korraldamiseks või automaatsete testide käivitamiseks.

Gitlab CI ettekannet 2 https://goo.gl/uohKjI — ettekanne Ruby Russia klubist — piisavalt põhjalik ja võib-olla huvitab see teid.

Praegu vaatame, mida on vaja, et aktiveerida Gitlab CI. Gitlab CI käivitamiseks piisab, kui panna projekti juure faili .gitlab-ci.yml.

Siin kirjeldame, mida soovime teha testimise ja juurutamise sarnaste olekute järjestuses.

Käivitame skripte, mis kutsuvad esile docker-compose'i meie rakenduse koostamise. See on näiteks backend.

Seejärel ütleme, et on vajalik migratsioonide käitamine andmebaasi muutmiseks ja testide läbiviimine.

Kui skriptid töötavad korrektselt ja ei tagasta viga, siis läheb süsteem vastavalt teise etappi.

Deploy-etapp on hetkel rakendatud staging-platvormil. Me ei ole korraldanud katkestusteta sõltumatut taaskäivitust.

Sundime kõik konteinerid kinni ja tõstame need seejärel uuesti üles, kasutades esimeses etapis testimiseks kokku pandud konteinerite pilte.

Käivitame jooksva muutujate keskkonna andmebaasi migreerimised, mille on kirjutanud arendajad.

On märk, et seda tuleks rakendada ainult haru 'master' puhul.

Teiste harude puhul ei toimu tõstmist.

On võimalik korraldada versioonide tõstmisi harude järgi.

Selle edasise korraldamiseks peame installima GitLab Runneri.

See utiliit on kirjutatud Golangis. See on ühekordne fail, nagu Golangi maailmas tavaline, mis ei vaja ühtegi sõltuvust.

Käivitamisel registreerime GitLab Runneri.

Saame GitLabi veebiliideses võtme.

Seejärel kutsume esile algatamise käsu käsurealt.

Konfigureerime GitLab Runneri dialoogirežiimis (Shell, Docker, VirtualBox, SSH).

Kood GitLab Runneris käivitub iga commit'i korral sõltuvalt .gitlab-ci.yml seadistusest.

Kuidas see Gitlabis veebiliideses visuaalselt välja näeb. Pärast Gitlab CI ühendamist ilmub meile lipp, mis näitab, millises olekus praegu build on.

Näeme, et 4 minutit tagasi tehti commit, mis läbis kõik testid ja ei tekitanud probleeme.

Saame lähemalt vaadata build'e. Siit näeme, et oleme läbinud kaks etappi: testimise etapp ja deploy etapp staging'is.

Kui klõpsame konkreetse build'i peal, näeme seal konsooliväljundit käskudest, mis käidi vastavalt .gitlab-ci.yml failile.

Selline on meie toote ajalugu. Näeme, et oleme olnud edukaid katseid. Kui testid nurjusid, siis järgmisse etappi ei liikuda ja koodi staging'is ei uuendata.

Milliseid ülesandeid lahendasime staging'is dockerit rakendades? Meie süsteem koosneb komponentidest ja meil tekkis vajadus taaskäivitada ainult osi komponentidest, mis olid repostos uuendatud, mitte kogu süsteemi korraga.

Selleks pidime kõik eraldi kaustadesse jaotama.

Pärast seda, kui olime selle teinud, tekkis meil probleem, et Docker-compose loob iga kausta jaoks oma võrgu, mistõttu ei näe komponentide naabrid.

Kuna selle ületamiseks lõime me võrgu Dockeris käsitsi. Docker-compose'is määrasime, et see projekt kasutaks seda võrku.

Seega näeb iga komponent, mis käivitatakse selle võrguga, teisi komponente süsteemi erinevates osades.

Järgmine probleem on staging'i jagamine mitme projekti vahel.

Kuna kõik see peaks välja nägema ilus ja olema võimalikult lähedal tootmisversioonile, on parem kasutada porti 80 või 443, mida kasutatakse laialdaselt veebis.

Kuidas me selle lahendasime? Määrasime ühe Gitlab Runner'i kõikidele suurtele projektidele.

Gitlab võimaldab käivitada mitu jaotatud Gitlab Runner'it, mis lihtsalt järjekorras ja kaootiliselt võtavad kõik ülesanded ja täidavad need.

Et meil ei tekiks segadust, piirasime meie projektide grupi ühe Gitlab Runner'iga, mis meie mahud arvestades töötab probleemideta.

Me tõstsime nginx-proxy eraldi käivitusskripti ja määrasime sinna kõigi projektide võrgud.

Meie projektil on üks võrk, samas kui koormuse tasakaalustaja haldab mitmeid võrke projektinimede järgi. See suudab domeeninimede alusel edasi proksida.

Meie päringud tulevad domeeni kaudu porti 80 ja suunatakse konteinerigruppi, mis teenindab seda domeeni.

Millised probleemid veel ilmnesid? Probleemiks on see, et vaikimisi töötavad kõik konteinerid kasutaja root all. See root ei ole võrreldav süsteemi root-hosti omaga.

Kuna aga konteinerisse sisenedes on tegemist rootiga, saavad seal loodud failid root õigused.

Kui arendaja siseneb konteinerisse ja käivitab seal käske, mis loovad faile, ja seejärel konteinerist väljub, siis tema töökaustas on fail, millele tal pole juurdepääsu.

Kuidas saaksime seda lahendada? Saame lisada kasutajaid, kes töötavad konteineris.

Millised probleemid tekkisid, kui lisasime kasutaja?

Kasutaja loomisel katsetame tihti, et grupi ID (UID) ja kasutaja ID (GID) ei kattu.

Selle probleemi lahendamiseks kasutame konteineris kasutajaid, kelle ID on 1000.

Meie puhul kattus see sellega, et praktiliselt kõik arendajad kasutavad Ubuntu operatsioonisüsteemi. Ubuntu operatsioonisüsteemis on esimesel kasutajal ID 1000.

Millised on meie plaanid?

Korrata dokumentatsiooni Docker kohta. Projekt areneb aktiivselt, dokumentatsioon muutub. Andmed, mis saadi kaks-kolm kuud tagasi, muutuvad aeglaselt vananenuks.

Mõned probleemid, millega me tegelesime, on tõenäoliselt juba lahendatud tavapäraste vahenditega.

On nii raske edasi liikuda ja minna otse orkestreerimise juurde.

Üks näide on Dockeri sisse ehitatud mehhanism nimega Docker Swarm, mis on juba välja pakutud. Tahaks käivitada midagi tootmises, mis põhineb Docker Swarm tehnoloogial.

Konteinerite genereerimine teeb logide haldamise ebamugavaks. Praegu on logid isoleeritud. Need on hajutatud konteinerite vahel. Üks ülesanne on tagada mugav juurdepääs logidele veebivahendi kaudu.

Allikas: habr.com