Arendamise ja testimise protsess Dockeris ja GitLab CI-s

Soovitan tutvuda Aleksandr Sigachevi aruande tõlgendusega Inventosest „Arenduse ja testimise protsess Docker + Gitlab CI'ga“

Need, kes alles hakkavad rakendama arenduse ja testimise protsessi Docker + Gitlab CI baasil, küsivad sageli põhiküsimusi. Kust alustada? Kuidas korraldada? Kuidas testida?

See aruanne on hea, kuna struktureeritult räägib arenduse ja testimise protsessist Docker'i ja Gitlab CI kasutamisel. Aruanne on aastast 2017. Ma arvan, et sellest arutelust saab algteadmisi, metoodikat, mõtteid ja kogemusi.

Kellele see huvi pakub, palun lugege edasi.

Minu nimi on Aleksandr Sigachev. Töödan ettevõttes Inventos. Jagame oma kogemusi Docker'i kasutamisest ja kuidas me seda järk-järgult meie projektides rakendame.

Aruande teema: Arenduse protsess Docker'i ja Gitlab CI kasutamisega.

See on minu teine aruanne Docker'ist. Esimese aruande ajal kasutasime Docker'it ainult arenduses arendajate masinates. Meie töötajate hulk, kes Docker'it kasutas, oli umbes 2-3 inimest. Aja jooksul oleme meie kogemusi kogunud ja pisut edasi liikunud. Link meie esimesele aruandele.

Mida see aruanne sisaldab? Jagame oma kogemust selle kohta, milliseid takistusi kohtasime ja kuidas probleeme lahendasime. See ei olnud alati ilus, kuid võimaldas meil edasi liikuda.

Meie moto: dockerige kõik, mille teeme.

Milliseid probleeme lahendame?

Kui ettevõttes on mitu meeskonda, siis on programmeerija jagatud ressurss. On etappe, kus programmeerija tõstetakse ühest projektist välja ja antakse mingiks ajaks teise projekti.

Kuna programmeerija peab kiiresti sisse elama, 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 alustatakse nullist, on projektides vähe dokumentatsiooni. Teave seadistuste kohta on ainult vanade töötajate käes. Töötajad seadistavad oma töökoha iseseisvalt ühe kuni kahe päevaga. Selle kiirendamiseks kasutasime Docker'it.

Järgmiseks põhjuseks on arenduse seadistuste standardiseerimine. Oma kogemuse põhjal on arendajad alati algatusvõimelised. Iga viienda juhtumi puhul kasutatakse kohandatud domeeni, näiteks vasya.dev. Tema kõrval istub Peeter, kellel on domeen petya.dev. Nad arendavad veebilehte või mõnda süsteemi komponenti kasutades seda domeeninime.

Kui süsteem suureneb ja need domeeninimed hakkavad ilmuma seadistustes, siis tekib konflikt arenduskeskkondade vahel ning saidi tee kirjutatakse üle.

Sama juhtub ka andmebaasi seadistustega. Keegi ei mõtle turvalisusele ja töötab tühja root-parooliga. Kusagil nõudis MySQL paigaldamise käigus parooli ja parool osutus 123-ks. Tihti juhtub, et andmebaasi konfiguratsioon muutub pidevalt arendaja commit'ide sõltuvalt. Keegi parandas, keegi ei parandanud konfiguratsiooni. Oli viise, kuidas me viisime mingi testkonfiguratsiooni välja .gitignore ja iga arendaja pidi andmebaasi paigaldama. See keeruliseks muudab käivitamisprotsessi. Peab lisaks kõikidele muudele asjadele meeles pidama ka andmebaasi. Andmebaas tuleb initsialiseerida, peab määrama parooli, peab määrama kasutaja, looma tabeli ja nii edasi.

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

Kes töötab MySQL-iga, teab, et need raamatukogud tõmbavad kaasa sõltuvusi. Kahe andmebaasi samaaegne käivitamine on üsna probleemne. Eriti vanade klientide ühendamine uue andmebaasiga on keeruline. See omakorda tekitab mitmeid probleeme.

Järgmine probleem on see, et kui arendaja töötab kohaliku masinaga, kasutab ta kohalikke ressursse, kohalikke faile, kohalikku RAM-i. Kõik suhtlemine toimub lahenduste arendamise ajal raames, et see töötab ühel masinal. Näiteks võib tuua olukorra, kus meil on tootmises 3 back-end serverit, kuid arendaja salvestab failid juurkatalooge ja sealt nginx võtab faile, et vastata päringutele. Kui selline kood läheb tootmisesse, siis selgub, et fail on olemas ainult ühes kolmest serverist.

Praegu areneb mikroteenuste suund. Kui jagame oma suured rakendused väiksemateks komponentideks, mis omavahel suhtlevad. See võimaldab valida konkreetse tehnoloogiakogumi jaoks sobivad tehnoloogiad. Samuti võimaldab see jagada töö ja vastutuse arendajate vahel.

Frontend-arendaja, töötades JS-ga, ei mõjuta praktiselt Backend'i. Backend-arendaja omakorda töötab meie puhul Ruby on Railsiga ega sega Frontendi. Suhtlemine toimub API abil.

Boonusena suutsime Dockerit kasutades optimeerida ressursse Stagingus. Iga projekt nõudis oma spetsiifilisuse tõttu teatud seadistusi. Füüsiliselt pidi kas eraldama igaühele virtuaalse serveri ja need eraldi seadistama, või jagama mingit muutuvkeskkonda, sest projektid võisid sõltuvalt teekide versioonidest üksteisega lõimuda.

Tööriistad. Mida me kasutame?

• Otse Docker ise. Dockerfile'is kirjeldatakse ühe rakenduse sõltuvusi.
• Docker-compose — see on sidumine, mis ühendab mitu meie Docker rakendust.
• GitLab'i kasutame lähtekoodi hoidmiseks.
• GitLab-CI kasutame süsteemsete integratsioonide jaoks.

Ettekanne koosneb kahest osast.

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

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

Docker on tehnoloogia, mis võimaldab (kasutades deklaratiivset lähenemist) kirjeldada vajalikke komponente. See on näide Dockerfile'ist. Siin kuulutame välja, et pärime ametlikult Docker-images Ruby:2.3.0. See sisaldab endas installitud Ruby versiooni 2.3. Me installime vajalikud raamistikud ja NodeJS. Kirjeldame, et loome katalooge. /appMäärame katalooge app töökataloogiks. Sellest kataloogist paneme vajalikud minimaalsed Gemfile ja Gemfile.lock. Seejärel täidame projektide kogumise, mis installivad need sõltuvused. Märgime, et konteiner on valmis kuulama välisel pordil 3000. Viimane käsk — see on käsk, mis otseselt käivitab meie rakenduse. Kui me täidame projekti käivitamise käsku, siis rakendus üritab käivituda ja jätkab määratud käsu täitmist.

See on minimaalne näide docker-compose failist. Antud juhul näitame, kuidas on ühendatud kaks konteinerit. Need on andmebaasi teenus ja veebi teenus. Meie veebi rakendused vajavad enamasti andmete salvestamiseks mingit andmebaasi. Kuna kasutame MySQL-i, on see näide MySQL-ist — kuid pole midagi, mis takistaks kasutada mõnda muud andmebaasi (PostgreSQL, Redis).

Me võtame ametlikest allikatest Docker Hub-ist MySQL 5.7.14 kuva muutumatult. Kuvat, mis vastutab meie veebi rakenduse eest, kogume hetke kataloogist. See kogub meile pildi esmakordsel käivitamisel. Pärast seda käivitab käsku, mille me siin täidame. Kui tagasi vaatame, näeme, et käivitamise käsk on määratletud Puma abil. Puma on teenus, mis on kirjutatud Ruby keeles. Teisel juhul üledefineerime. See käsk võib olla omaväärne sõltuvalt meie vajadustest või ülesannetest.

Kaasajame ka, et meie arendaja hostmasinas tuleb edastada port 3000 konteineri porti 3000. See toimub automaatselt iptables'i abil ja Dockerisse sisseehitatud mehanismiga.

Arendaja võib nagu varem pöörduda igasuguste võimalike IP-aadresside poole, näiteks kohaliku 127.0.0.1 või masina välise IP-aadressi poole.

Viimane rida ütleb, et veebi konteiner sõltub andmebaasi konteinerist. Kui me kutsume veebi konteineri käivitama, käivitab docker-compose enne andmebaasi konteineri. Andmebaasi käivitamisel (tegelikult konteineri käivitamise järel! Andmebaasi valmisolek ei ole garanteeritud) käivitab see meile rakenduse, meie backend-i.

See aitab vältida vigu, kui andmebaas ei ole ülesse seatud, ja säästa ressursse, kui peatame andmebaasi konteineri, vabastades sellega ressursse teiste projektide jaoks.

Mida annab meile andmebaasi dockeriseerimine projektis. Me fikseerime kõikide arendajate jaoks MySQL versiooni. See aitab vältida mõningaid vigu, mis võivad esineda versioonide erinevuse tõttu, kui süntaks, konfiguratsioon ja vaikeseaded muutuvad. See võimaldab meil määrata ühiselt andmebaasi hostname'i, kasutajanime ja parooli. Me eemaldume varasemast konfigureerimisfailide purustamisasust ja konfliktidest.

Meil on võimalus kasutada arenduskeskkonnale optimeeritud konfiguratsiooni, mis erineb vaikeseadistusest. Vaikimisi on MySQL seadistatud nõrgemale riistvarale ja selle jõudlus on algselt väga madal.

Docker võimaldab kasutada vajalikku Python, Ruby, NodeJS, PHP versiooni. Vabanevad vajadusest kasutada mingeid versioonihaldureid. Varem kasutasime Ruby jaoks rpm-paketti, mis võimaldas versiooni muuta projekti järgi. Samuti võimaldab Docker-konteiner sujuvat koodi migreerimist ja versioonimise koos sõltuvustega. Meil ei teki probleeme, et mõista versiooni nii interpreteerijalt kui ka koodilt. Versiooni uuendamiseks tuleb vana konteiner peatada ja uus konteiner käivitada. Kui midagi läheb valesti, saame uue konteineri peatada ja vana konteineri käivitada.

Pärast pildi koostamist on konteinerid nii arendus- kui ka tootmises samad. See on eriti oluline suuremate paigalduste puhul.

Esipaneelil kasutame JavaScipti ja NodeJS-i.

Meie viimane projekt on ReacJS-i peal. Arendaja käivitas kõik konteinerid ja töötas välja, kasutades kuumlaadimist.

Seejärel käivitub JavaScipti koostamisülesanne ja staatiline kood edastatakse läbi nginx-i, säästes ressursse.

Siin on toodud skeem meie viimasest projektist.

Milliseid ülesandeid lahendasime? Meil oli vajalik ehitada süsteem, millega suhtlevad mobiilseadmed. Need saavad andmeid. Üks võimalusi on saata push-teateid sellele seadmele.

Mida me selleks tegime?

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

Meil oli ka vajadus saata push-teateid. Enne seda oli meil projekt, kus oli rakendatud mehhanism, mis vastutab teadete edastamise eest mobiilplatvormidele.

Me välja töötasime sellise skeemi: operaator brauserist suhtleb administraatoriga, administraator suhtleb backendiga, seatakse ülesanne saata push-teateid.

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

Seonelad tärkavad järjekorrad ja edastamine toimub oma mehhanismi kaudu.

Siin on kujutatud kahte andmebaasi. Praegu kasutame Dockerit kaht sõltumatut andmebaasi, mis ei ole omavahel seotud. Seejuures on neil ühine virtuaalvõrk, samas hoiustatakse füüsilisi andmeid arendaja masina erinevates kataloogides.

Sama asi aga numbrites. Siin on oluline koodi taaskasutamine.

Kui varem rääkisime koodi taaskasutamisest raamatukogudena, siis antud näites kasutatakse meie teenust, mis vastutab Push-teatiste eest, täismahus serverina. See pakub API-d. Ja selle kaudu suheldakse meie uue arendusega.

Sel ajal kasutasime NodeJS versiooni 4. Praegu (2017. aasta — toimetuse märkus) uutes arendustes kasutame versiooni 7. Uute komponentide puhul ei ole probleeme uute raamatukogude versioonide kasutamisega.

Vajadusel saab teostada refaktooringut ja tõsta NodeJS versiooni Push-teatiste teenusele.

Kui suudame säilitada API ühilduvuse, saame seda asendada teistes projektides, mida varem kasutati.

Mida on vaja, et lisada Docker? Lisame meie reposse Dockerfile, mis kirjeldab vajalikud sõltuvused. Antud näites on komponendid jagatud loogika alusel. See on minimaalne komplekt backend-arendajale.

Uue projekti loomisel loome Dockerfile'i, kirjeldame vajaliku ökosüsteemi (Python, Ruby, NodeJS). Docker-compose'is kirjeldame vajaliku sõltuvuse — andmebaasi. Kirjeldame, et on vajalik andmebaas sellise versiooniga, andmed hoitakse seal-seal.

Kasutame staatika edastamiseks eraldi kolmandat konteinerit koos nginx-iga. On ette nähtud võimalus piltide üleslaadimiseks. Backend paneb need eelnevalt ettevalmistatud mahtudesse, mis on samuti ühendatud nginx konteinerisse, mis edastab staatikat.

Nginxi ja mysql konfi jaoks lisasime kausta Docker, kus hoiame vajalikke konfi faile. Kui arendaja kloonib repot enda masinasse, on tal juba projekt, mis on valmis kohalikuks arendamiseks. Ei ole küsimust, millist porti või milliseid seadistusi rakendada.

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

Selleks, et kõik käivitada, lõime veel ühe repo, mille nimetasime dockerized-app. Praegu kasutame mitut repositooriumi iga komponendi jaoks. Need erinevad lihtsalt loogiliselt — GitLabis näeb see välja nagu kaust, ja arendaja masinas on see kaust konkreetse projekti jaoks. Madalamal tasemel asuvad komponendid, mis ühenduvad.

See on näide dockerized-app'i sisust. Toome siia välja ka Docker'i katalooge, kuhu täidame konfiguratsioonid, mis on vajalikud kõigi komponentide vaheliseks suhtlemiseks. Olemas on README.md, kus on lühidalt kirjas, kuidas projekti käivitada.

Siin rakendasime kahte docker-compose faili. See on tehtud selleks, et saaksime käivitada astmeliselt. Kui arendaja töötab põhikoosluses, ei vaja ta Push-teateid, siis käivitab ta lihtsalt docker-compose faili ja vastavalt sellele kulusid hoitakse kokku.

Kui on vajadus integreerimiseks Push-teated, siis käivitatakse 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 põhjalikum fail, mis vastutab komponentide kogumise eest. Mis siin on tähelepanuväärne? Siin tutvustame komponendi tasakaalustajat.

See on valmis Docker'i pilt, milles käivitatakse nginx ja rakendus, mis kuulab Docker socket'i. Dünaamiliselt, konteinerite sisse- ja väljalülitamise ajal, genereerib uuesti nginx'i konfiguraator. Komponentidega suhtlemine jagatakse kolmanda taseme domeeninimede kaupa.

Arenduskeskkonna jaoks kasutame .dev domeeni — api.informer.dev. Rakendused domeeniga .dev on arendaja kohaliku masina peal ligipääsetavad.

Edasi edastatakse konfiguratsioonid iga projekti juurde ja kõiki projekte käivitatakse samal ajal koos.

Kui joonistada graafikaliselt, siis klient on meie brauser või mõni tööriist, millega teeme päringud tasakaalustajale.

Tasakaalustaja määrab domeeninime järgi, millise konteineri poole pöörduda.

See võib olla nginx, mis edastab JS haldustarkvara. See võib olla nginx, mis edastab API-d või staatilisi faile, mida edastatakse nginx'i kaudu piltide laadimise näol.

Skeemilt on näha, et konteinerid on ühendatud virtuaalsesse võrku ja peidetud proxy taha.

Arenduskeskkonnas saab konteinerisse pääseda, teades IP-aadressi, kuid me ei kasuta seda põhimõtteliselt. Otseühenduse vajadus ei tekki peaaegu kunagi.

Milliseid näiteid vaadata, et oma rakendus dockerisse panna? Minu arvates on hea näide ametlik MySQL docker pilt.

See on piisavalt keeruline. Seal on palju versioone. Kuid selle funktsionaalsus katab mitmeid vajadusi, mis võivad tekkida edasise arendamise käigus. Kui investeerite aega ja mõistate, kuidas see kõik omavahel toimib, siis ei tohiks teil iseseisva rakendamisega probleeme tekkida.

Hub.docker.com-is on tavaliselt lingid github.com-ile, kus on antud toored andmed, mille põhjal saab ise pildi koguda.

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

Samuti on selles näites olemas võimalus konfigureerida keskkonnamuutujate abil. Määrates keskkonnamuutuja, kui käitate ühte konteinerit või kasutate docker-compose'i, saate öelda, et peame määrama MySQL-i root kasutajale tühja parooli või mõne muu, mille soovime.

On võimalus luua juhuslik parool. Ütleme, et meil on vajalik kasutaja, peame kasutajale parooli seadma ja andmebaasi looma.

Oma projektides oleme veidi ühtlustanud Dockerfile'i, mis vastutab initsialiseerimise eest. Oleme seda oma vajadustele kohandanud, et teha lihtsalt kasutaja õiguste laiendamine, mida rakendus kasutab. See võimaldas hiljem lihtsalt rakenduse konsoolist andmebaasi luua. Ruby rakendustes on olemas käsk andmebaaside loomiseks, muutmiseks ja kustutamiseks.

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

Docker-endpoint.sh on skript, mis vastutab sisenemispunkti eest. Algse initsialiseerimise ajal on vajalikud teatud ettevalmistavad toimingud ning kõik need toimingud on just kokku võetud initsialiseerimise skripti.

Liigume teise osa juurde.

Koodi hoidmiseks oleme üle läinud gitlabile. See on piisavalt võimas süsteem, millel on visuaalne liides.

Üks GitLabi komponente on GitLab CI. See võimaldab kirjeldada käsukäike, mida hiljem kasutatakse koodi edastamise või automaatsete testide käivitamise korraldamiseks.

Ettekande teema: GitLab CI 2 https://goo.gl/uohKjI — ettekande Ruby Russia klubi kohta — see on piisavalt põhjalik ja võib teid huvitada.

Nüüd vaatame, mida on vaja GitLab CI aktiveerimiseks. GitLab CI käivitamiseks piisab, kui panna projekti juurkausta fail .gitlab-ci.yml.

Siin kirjeldame, mida me soovime teha tüüpi testide ja juurutuste järjekorra.

Käivitame skriptid, mis käivitavad otse docker-compose'i meie rakenduse koostamiseks. See on näide tagaplaanist.

Seejärel ütleme, et on vajalik käivitada andmebaasi migratsioonid ja teostada testid.

Kui skriptid käivitatakse korras ega tagasta tõrke koodi, jätkab süsteem vastavalt teise juurutuse etapi juurde.

Juurutuse etapp on hetkel rakendatud stagingule. Me ei ole organiseerinud katkestusteta taaskäivitust.

Katsume kõik konteinerid välja lülitada ja seejärel käivitame kõik konteinerid uuesti, mis on testimise esimesel etapil ehitatud.

Käivitame juba praeguses muutuvates keskkondades andmebaasi migratsioonid, mille on kirjutanud arendajad.

On märge, et seda tuleks rakendada ainult master harule.

Teiste harude muutmisest ei teostata.

On võimalik korraldada versioonide juurutusi harude kaupa.

Kuna seda korraldada, peame installima GitLab Runneri.

See utiliit on kirjutatud Go-s. See on ühe failiga, nagu Go maailmas tavaks, milleks ei ole vaja mingeid sõltuvusi.

Käivitamisel registreerime GitLab Runneri.

Saame GitLabi veebiliideses võtme.

Seejärel kutsume välja initsialiseerimise käsu käsurealt.

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

Kood GitLab Runneri peal käivitub igal commitil sõltuvalt .gitlab-ci.yml seadistustest.

Nii see visuaalselt välja näeb GitLabis veebiliideses. Pärast GitLab CI ühendamist ilmub meil lipp, mis näitab, millises seisus on praegu ehitus.

Me näeme, et 4 minutit tagasi tehti commit, mis läbis kõik testid ja ei põhjustanud probleeme.

Me saame vaadata konstruktsioonide üle lähemalt. Siin näeme, et oleme läbinud kaks olekut. Testimise olek ja staging'u olek.

Kui me klikime konkreetsele konstruktioonile, siis seal on konsooliväljund käsudest, mis käidi protsessi jooksul vastavalt .gitlab-ci.yml.

Nii näeb välja meie toote ajalugu. Näeme, et on olnud edukaid katseid. Kui testid ebaõnnestuvad, siis järgmisse sammu ei liikuda ja kood staging'il ei uuene.

Millised ülesanded me lahendasime staging'il, kui juurutame dockerit? Meie süsteem koosneb komponentidest ja meil tekkis vajadus käivitada ainult need komponendid, mis olid repozitooriumis uuendatud, mitte kogu süsteemi korraga.

Sellega seoses pidime kõik eraldi kaustadesse jagama.

Pärast seda, kui me seda tegime, tekkis meil probleem, et Docker-compose loob iga kausta jaoks oma võrguruumi ja ei näe naabrite komponente.

Selle ärahoidmiseks lõime käsitsi Dockeris võrgu. Docker-compose'is määrasime, et selle projekti jaoks kasutatakse seda võrku.

Nii näeb iga komponent, mis käivitub koos selle võrguga, teisi süsteemi komponente.

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

Et see kõik näeks kena ja võimalikult tootmisvägagi sarnane välja, on hea kasutada 80 või 443 porti, mida kasutatakse veebis laialdaselt.

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

Gitlab võimaldab käivitada mitmeid jaotatud Gitlab Runner'e, mis lihtsalt kordamööda võtavad kõik ülesanded ja töötlevad neid.

Et meil ei tekiks segadust, piirates meie projektide gruppi ühe Gitlab Runner'iga, mis meie mahtude juures töötab probleemideta.

Me viisime nginx-proxy eraldi käivitusskripti ja määrasime selles kõikide projektide võrgud.

Meie projektil on üks võrk, samas kui koormuse tasakaalustaja omab mitu võrku projektide nimede järgi. Ta võib domeeninimede järgi edasi suunata.

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

Millised olid veel probleemid? See, et vaikimisi käivad kõik konteinerid root kasutajana. See root ei ole võrreldav süsteemi hosti root'iga.

Kuid kui siseneda konteinerisse, on see root ja fail, mille me selles konteineris loome, saab root õigused.

Kui arendaja on konteinerisse sisenenud ja teinud seal mingeid käske, mis genereerivad faile, ning seejärel konteinerist välja läinud, siis oma töökaustas tal on fail, millele tal ei ole juurdepääsu.

Kuidas seda lahendada? Saame lisada kasutajaid, kes on konteineris.

Millised probleemid tekkisid, kui me kasutasime kasutajat?

Kasutaja loomisel ei vaste sageli grupi ID (UID) ja kasutaja ID (GID).

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

Meie juhul vastas see sellele, et enamus arendajatest kasutab Ubuntu operatsioonisüsteemi. Ubuntu OS-is on esimesel kasutajal ID 1000.

Millised on meie plaanid?

Lugeda läbi Docker'i dokumentatsioon. Projekt areneb aktiivselt, dokumentatsioon muutub. Teated, mis saadi kaks-kolm kuud tagasi, hakkavad juba aeglaselt aeguma.

Osad probleemid, millega me tegelesime, on tõenäoliselt juba lahendatud standardsete vahenditega.

Tahaks väga edasi liikuda ja minna otseselt orkestreerimise juurde.

Üks näide on Dockerisse sisse ehitatud mehhanism nimega Docker Swarm, mis on pakitud koos. Tahaksin käivitada midagi tootmises Docker Swarmi tehnoloogia baasil.

Konteinerite genereerimine muudab logide töötamise ebamugavaks. Praegu on logid isoleeritud. Need on hajutatud konteinerite vahel. Üks ülesanne on teha logide mugav juurdepääs veebiliidese kaudu.

Allikas: habr.com