Soovitan teil lugeda Inventose Alexander Sigachevi raporti "Arendus- ja testimisprotsess Dockeri + Gitlab CI-ga" ärakirja.
Need, kes alles alustavad Docker + Gitlab CI-l põhinevat arendus- ja testimisprotsessi juurutamist, esitavad sageli põhiküsimusi. Kust alustada? Kuidas korraldada? Kuidas testida?
See aruanne on hea, sest see räägib struktureeritult arendus- ja testimisprotsessist Dockeri ja Gitlab CI abil. Aruanne ise pärineb 2017. aastast. Arvan, et sellest aruandest saate selgeks põhitõed, metoodika, idee ja kasutuskogemuse.
Keda huvitab, palun kassi alla.
Minu nimi on Aleksander Sigachev. Töötan Inventose heaks. Räägin teile oma kogemusest Dockeri kasutamisel ja sellest, kuidas me seda järk-järgult ettevõtte projektides rakendame.
Aruande teema: Arendusprotsess Dockeri ja Gitlab CI abil.
See on minu teine jutt Dockerist. Esimese aruande ajal kasutasime Dockerit arendusseadmetes ainult arenduses. Dockerit kasutanud töötajate arv oli umbes 2-3 inimest. Tasapisi kogunes kogemusi ja liikusime veidi edasi. Link meie lehele .
Mis selles aruandes sisaldub? Jagame oma kogemusi, milliseid rehasid kogusime, milliseid probleeme lahendasime. Kõikjal ei olnud ilus, kuid see võimaldas meil edasi liikuda.
Meie moto: dokkige kõik, mis meile kätte jõuab.
Milliseid probleeme me lahendame?
Kui ettevõttel on mitu meeskonda, on programmeerija jagatud ressurss. On etappe, kus programmeerija tõmmatakse ühest projektist välja ja antakse mõneks ajaks teise projekti juurde.
Selleks, et programmeerija saaks kiiresti aru, peab ta alla laadima projekti lähtekoodi ja võimalikult kiiresti käivitama keskkonna, mis võimaldab tal selle projekti probleemide lahendamisel edasi liikuda.
Tavaliselt, kui alustada nullist, on projektis vähe dokumentatsiooni. Selle seadistamise kohta on teavet ainult vanadel inimestel. Töötajad seavad oma töökoha ise sisse ühe-kahe päevaga. Selle kiirendamiseks kasutasime Dockerit.
Järgmine põhjus on seadete standardimine arenduses. Minu kogemuse kohaselt võtavad arendajad alati initsiatiivi. Igal viiendal juhul sisestatakse kohandatud domeen, näiteks vasya.dev. Minu kõrval istub mu naaber Petya, kelle domeen on petya.dev. Nad arendavad seda domeeninime kasutades veebisaiti või mõnda süsteemikomponenti.
Kui süsteem kasvab ja neid domeeninimesid hakatakse konfiguratsiooni kaasama, tekib arenduskeskkondades konflikt ja saidi tee kirjutatakse ümber.
Sama juhtub andmebaasi sätetega. Mõned inimesed ei muretse turvalisuse pärast ja töötavad tühja juurparooliga. Installimise etapis küsis MySQL kelleltki parooli ja parooliks osutus 123. Sageli juhtub, et andmebaasi konfiguratsioon muutus pidevalt sõltuvalt arendaja kohustustest. Keegi parandas, keegi ei parandanud konfiguratsiooni. Testi konfigureerimisel oli trikke .gitignore ja iga arendaja pidi andmebaasi installima. See muutis käivitamise protsessi keerulisemaks. Muuhulgas peate meeles pidama andmebaasi. Andmebaas tuleb initsialiseerida, registreerida parool, registreerida kasutaja, luua märk jne.
Teine probleem on teekide erinevad versioonid. Tihti juhtub, et arendaja töötab erinevate projektidega. On olemas projekt Legacy, mis sai alguse viis aastat tagasi (alates 2017 – toimetaja märkus). Alguses alustasime MySQL 5.5-ga. Samuti on kaasaegseid projekte, kus proovime rakendada MySQL-i kaasaegsemaid versioone, näiteks 5.7 või vanemaid (2017. aastal - toimetaja märkus)
Kõik, kes MySQL-iga töötavad, teavad, et need teegid kannavad sõltuvusi. 2 andmebaasi koos käitamine on üsna problemaatiline. Vähemalt on problemaatiline vanade klientide ühendamine uue andmebaasiga. See omakorda tekitab mitmeid probleeme.
Järgmine probleem on see, kui arendaja töötab kohalikus masinas, kasutab ta kohalikke ressursse, kohalikke faile, kohalikku RAM-i. Kogu suhtlemine probleemide lahenduse väljatöötamise ajal toimub selle raames, et see töötab ühes masinas. Näide on see, kui meil on tootmisversioonis 3 taustaserverid ja arendaja salvestab failid juurkataloogi ja sealt võtab nginx failid päringule vastamiseks. Kui selline kood tootmisse jõuab, selgub, et fail asub ühes kolmest serverist.
Praegu areneb mikroteenuste suund. Kui jagame oma suured rakendused mõneks väikeseks komponendiks, mis omavahel suhtlevad. See võimaldab valida tehnoloogiaid konkreetse ülesandevirna jaoks. See võimaldab teil jagada ka tööd ja vastutusala arendajate vahel.
JS-is arendaval esiprogrammi arendajal pole taustaprogrammile praktiliselt mingit mõju. Taustaprogrammi arendaja omakorda arendab, meie puhul Ruby on Rails, ega sega Frondendi. Interaktsioon toimub API abil.
Boonusena saime Dockeri abil ressursse Stagingis taaskasutada. Iga projekt nõudis oma eripärast tulenevalt teatud seadistusi. Füüsiliselt oli vaja eraldada kas virtuaalserver ja need eraldi seadistada või jagada mingi muutuv keskkond ja projektid võisid üksteist mõjutada, olenevalt teekide versioonist.
Tööriistad. Mida me kasutame?
- Docker ise. Dockerfile kirjeldab ühe rakenduse sõltuvusi.
- Docker-compose on pakett, mis koondab mitu meie Dockeri rakendust.
- Lähtekoodi salvestamiseks kasutame GitLabi.
- Süsteemi integreerimiseks kasutame GitLab-CI-d.
Aruanne koosneb kahest osast.
Esimene osa räägib teile, kuidas Dockerit arendajate masinates käivitada.
Teises osas räägitakse sellest, kuidas GitLabiga suhelda, kuidas teste korraldame ja kuidas lavastamissüsteemi juurutame.
Docker on tehnoloogia, mis võimaldab (kasutades deklaratiivset lähenemist) kirjeldada vajalikke komponente. See on Dockerfile'i näide. Siin deklareerime, et pärime Ruby ametlikult Dockeri pildilt: 2.3.0. See sisaldab Ruby versiooni 2.3 installitud. Paigaldame vajalikud koosteteegid ja NodeJS. Kirjeldame, et loome kataloogi /app. Töökataloogiks määrame rakenduste kataloogi. Sellesse kataloogi asetame nõutud minimaalsed Gemfile ja Gemfile.lock. Seejärel koostame projekte, mis installivad selle sõltuvuspildi. Näitame, et konteiner on välise pordi 3000 kaudu kuulamiseks valmis. Viimane käsk on käsk, mis käivitab otse meie rakenduse. Kui käivitame projekti käitamise käsu, proovib rakendus käivitada ja käivitada määratud käsu.
See on minimaalne näide dockeri koostamise failist. Sel juhul näitame, et kahe konteineri vahel on ühendus. See on otse andmebaasiteenusesse ja veebiteenusesse. Meie veebirakendused nõuavad enamikul juhtudel andmete salvestamiseks taustaprogrammina mingit andmebaasi. Kuna me kasutame MySQL-i, siis näide on MySQL-iga – aga miski ei takista meid kasutamast mõnda muud andmebaasi (PostgreSQL, Redis).
Võtame MySQL 5.7.14 pildi ilma muudatusteta ametlikust allikast Dockeri jaoturist. Kogume praegusest kataloogist pildi, mis vastutab meie veebirakenduse eest. Esimesel käivitamisel kogub ta meile pildi. Seejärel käivitab see käsu, mida me siin täidame. Kui läheme tagasi, näeme, et käivituskäsk määrati Puma kaudu. Puma on ruby keeles kirjutatud teenus. Teisel juhul alistame. See käsk võib olla meelevaldne, sõltuvalt meie vajadustest või ülesannetest.
Samuti kirjeldame, et peame edastama oma arendaja hostmasina pordi 3000-lt 3000-le konteineripordile. Seda tehakse automaatselt, kasutades iptablesi ja oma mehhanismi, mis on otse Dockerisse manustatud.
Arendaja saab nagu varemgi juurde pääseda mis tahes saadaolevale IP-aadressile, näiteks 127.0.0.1 masina kohalikule või välisele IP-aadressile.
Viimane rida ütleb, et veebikonteiner sõltub db-konteinerist. Kui kutsume veebikonteinerit käivitama, käivitab docker-compose kõigepealt meie jaoks andmebaasi. Juba andmebaasi käivitamisel (tegelikult pärast konteineri käivitamist! See ei garanteeri andmebaasi valmisolekut) käivitab see meie rakenduse, meie taustaprogrammi.
See võimaldab meil vältida vigu, kui andmebaas ei tööta, ja säästa ressursse, kui peatame andmebaasi konteineri, vabastades seeläbi ressursse teiste projektide jaoks.
Mida andmebaasi dokkimise kasutamine projektis meile annab? Salvestame kõigi arendajate jaoks MySQL-i versiooni. See võimaldab teil vältida mõningaid vigu, mis võivad ilmneda versioonide lahknemisel, süntaksi, konfiguratsiooni ja vaikesätete muutumisel. See võimaldab määrata andmebaasi jaoks ühise hostinime, sisselogimise ja parooli. Me eemaldume varem eksisteerinud nimede ja konfliktide loomaaiast konfiguratsioonifailides.
Meil on võimalus kasutada arenduskeskkonna jaoks optimaalsemat konfiguratsiooni, mis erineb vaikeseadest. MySQL on vaikimisi konfigureeritud nõrkade masinate jaoks ja selle jõudlus on algusest peale väga madal.
Docker võimaldab kasutada soovitud versiooni Python, Ruby, NodeJS, PHP tõlke. Vabaneme vajadusest kasutada mingit versioonihaldurit. Varem kasutati Ruby jaoks rpm paketti, mis võimaldas vastavalt projektile versiooni muuta. Tänu Dockeri konteinerile võimaldab see ka koodi sujuvalt üle viia ja seda koos sõltuvustega versioonida. Meil pole probleeme nii tõlgi kui ka koodi versiooni mõistmisega. Versiooni värskendamiseks tuleb vana konteiner alla lasta ja uus konteiner üles tõsta. Kui midagi läheb valesti, saame uue konteineri alla lasta, vana konteineri tõsta.
Pärast pildi loomist on konteinerid nii arenduses kui ka tootmises samad. See kehtib eriti suurte paigalduste kohta.
Frontendis kasutame JavaScipti ja NodeJS-i.
Nüüd on meil viimane ReacJS-i projekt. Arendaja käivitas kõik konteineris olevad asjad ja arendas kuuma taaslaadimise abil.
Järgmisena käivitatakse JavaScipti kokkupanemise ülesanne ja staatiliselt kokkupandud kood saadetakse nginxi kaudu, säästes ressursse.
Siin olen esitanud meie viimase projekti diagrammi.
Milliseid probleeme lahendasite? Meil oli vajadus luua süsteem, millega mobiilseadmed suhtlevad. Nad saavad andmeid. Üks võimalus on saata sellele seadmele push-teatisi.
Mida me selle heaks teinud oleme?
Jagasime rakenduse järgmisteks komponentideks: JS-i administraatoriosa, taustaprogramm, mis töötab REST-liidese kaudu Ruby on Railsis. Taustaprogramm suhtleb andmebaasiga. Loodud tulemus antakse kliendile. Administraatori paneel suhtleb taustaprogrammi ja andmebaasiga REST-liidese kaudu.
Meil oli ka vajadus saata tõuketeateid. Enne seda oli meil projekt, milles rakendati mehhanismi, mis vastutas teadete edastamise eest mobiiliplatvormidele.
Oleme välja töötanud järgmise skeemi: brauseri operaator suhtleb administraatoripaneeliga, administraatori paneel suhtleb taustaprogrammiga, ülesandeks on saata Push-teatisi.
Tõukemärguanded suhtlevad mõne teise NodeJS-is rakendatud komponendiga.
Järjekorrad koostatakse ja teateid saadetakse vastavalt oma mehhanismile.
Siin on joonistatud kaks andmebaasi. Praegu kasutame Dockerit kasutades 2 sõltumatut andmebaasi, mis pole omavahel kuidagi seotud. Lisaks sellele, et neil on ühine virtuaalne võrk ja füüsilised andmed salvestatakse arendaja masina erinevatesse kataloogidesse.
Sama asi, aga numbrites. Siin on oluline koodi taaskasutamine.
Kui varem rääkisime koodi taaskasutamisest teekide kujul, siis selles näites on meie Push-teavitustele reageeriv teenus taaskasutatud tervikliku serverina. See pakub API-d. Ja meie uus areng suhtleb sellega.
Sel ajal kasutasime NodeJS-i versiooni 4. Nüüd (2017. aastal – toimetaja märkus) kasutame oma viimastes arendustes NodeJS-i versiooni 7. Uute komponentide puhul ei ole probleeme teekide uute versioonide kaasamisega.
Vajadusel saate Push-teavitusteenuse NodeJS-i versiooni ümber kujundada ja tõsta.
Ja kui suudame säilitada API-ühilduvuse, on võimalik see asendada teiste varem kasutatud projektidega.
Mida on vaja Dockeri lisamiseks? Lisame oma hoidlasse Dockerfile'i, mis kirjeldab vajalikke sõltuvusi. Selles näites on komponendid jagatud loogiliselt. See on minimaalne komplekt taustaarendaja jaoks.
Uue projekti loomisel loome Dockerfile'i ja kirjeldame soovitud ökosüsteemi (Python, Ruby, NodeJS). Docker-compose'is kirjeldab see vajalikku sõltuvust - andmebaasi. Kirjeldame, et vajame sellise ja sellise versiooni andmebaasi, et seal ja seal andmeid salvestada.
Staatilise sisu teenindamiseks kasutame nginxiga eraldi kolmandat konteinerit. Võimalik pilte üles laadida. Taustaprogramm paneb need eelnevalt ettevalmistatud ruumalasse, mis on samuti monteeritud konteinerisse koos nginxiga, mis pakub staatilisi andmeid.
Nginxi ja mysqli konfiguratsiooni salvestamiseks lisasime Dockeri kausta, kuhu salvestame vajalikud konfiguratsioonid. Kui arendaja teeb oma masinas hoidlast git-klooni, on tal projekt kohalikuks arendamiseks juba valmis. Pole kahtlust, millist porti või milliseid sätteid rakendada.
Järgmisena on meil mitu komponenti: administraator, info-API, tõukemärguanded.
Selle kõige käivitamiseks lõime teise hoidla nimega dockerized-app. Praegu kasutame iga komponendi jaoks mitut hoidlat. Need on lihtsalt loogiliselt erinevad - GitLabis näeb see välja nagu kaust, kuid arendaja masinas näeb see välja nagu konkreetse projekti kaust. Üks tase allpool on komponendid, mida kombineeritakse.
See on näide dockerized-app sisust. Siia paneme ka Dockeri kataloogi, kuhu täidame kõikide komponentide interaktsiooniks vajalikud konfiguratsioonid. Seal on README.md, mis kirjeldab lühidalt, kuidas projekti käivitada.
Siin oleme rakendanud kaks dockeri koostamise faili. Seda tehakse selleks, et saaks käivitada etapiviisiliselt. Kui arendaja töötab tuumaga, ei vaja ta tõukemärguandeid, ta lihtsalt käivitab dockeri koostamise faili ja vastavalt sellele salvestatakse ressursse.
Kui on vajadus tõukemärguannetega integreerida, käivitatakse docker-compose.yaml ja docker-compose-push.yaml.
Kuna kaustas on docker-compose.yaml ja docker-compose-push.yaml, luuakse automaatselt üks virtuaalne võrk.
Komponentide kirjeldus. See on keerukam fail, mis vastutab komponentide kogumise eest. Mis siin tähelepanuväärset on? Siin tutvustame tasakaalustaja komponenti.
See on valmis Dockeri pilt, mis käivitab nginxi ja rakenduse, mis kuulab Dockeri pesa. Dünaamiline, kuna konteinerite sisse- ja väljalülitamisel genereeritakse nginxi konfiguratsioon uuesti. Jaotame komponentide käsitlemist kolmanda taseme domeeninimede abil.
Arenduskeskkonna jaoks kasutame domeeni .dev - api.informer.dev. dev-domeeniga rakendused on saadaval arendaja kohalikus masinas.
Seejärel kantakse konfiguratsioonid üle igale projektile ja kõik projektid käivitatakse koos korraga.
Kui seda graafiliselt kujutada, siis selgub, et kliendiks on meie brauser või mingi tööriist, millega teeme taotlusi tasakaalustajale.
Tasakaalustaja määrab domeeninime põhjal, millisele konteinerile tuleb juurde pääseda.
See võib olla nginx, mis pakub administraatoripaneelile JS-i. Seda saab teha nginx, mis pakub API-d, või staatilised failid, mida nginx pakub piltide laadimise kujul.
Diagramm näitab, et konteinerid on ühendatud virtuaalsesse võrku ja peidetud puhverserveri taha.
Arendaja masinas pääsete konteinerile ligi IP-d teades, kuid põhimõtteliselt me seda ei kasuta. Otsest kontakti praktiliselt pole vaja.
Millist näidet peaksin vaatama oma rakenduse dokkimiseks? Minu arvates on heaks näiteks MySQL-i ametlik dockeri pilt.
See on üsna keeruline. Versioone on palju. Kuid selle funktsionaalsus võimaldab teil katta palju vajadusi, mis võivad edasise arendamise käigus tekkida. Kui võtate aega ja mõistate, kuidas see kõik omavahel toimib, siis arvan, et teil pole selle rakendamisel probleeme.
Hub.docker.com sisaldab tavaliselt linke github.com-ile, kus antakse otse algandmed, millest saate ise pildi luua.
Lisaks on selles hoidlas skript docker-endpoint.sh, mis vastutab rakenduse käivitamise esialgse lähtestamise ja edasise töötlemise eest.
Ka selles näites on konfigureerimise võimalus keskkonnamuutujate abil. Kui määratlete keskkonnamuutuja ühe konteineri käitamisel või docker-compose'i kaudu, võime öelda, et peame määrama MySQL-is või mis iganes muus kohas dockeri root jaoks tühja parooli.
On võimalus luua juhuslik parool. Me ütleme, et vajame kasutajat, peame kasutajale parooli määrama ja peame looma andmebaasi.
Oleme oma projektides veidi ühendanud Dockerfile'i, mis vastutab lähtestamise eest. Seal kohandasime seda oma vajadustega, et lihtsalt laiendada rakenduse kasutatavaid kasutajaõigusi. See võimaldas tulevikus lihtsalt rakenduskonsoolist andmebaasi luua. Ruby rakendustel on käsud andmebaaside loomiseks, muutmiseks ja kustutamiseks.
See on näide sellest, kuidas näeb välja teatud MySQL-i versioon saidil github.com. Saate avada Dockerfile'i ja vaadata, kuidas installimine seal toimub.
sisestuspunkti eest vastutav skript docker-endpoint.sh. Esialgse lähtestamise ajal on vaja mõningaid ettevalmistustoiminguid ja kõik need toimingud sisalduvad lähtestamisskriptis.
Liigume edasi teise osa juurde.
Lähtekoodide salvestamiseks läksime Gitlabile üle. See on üsna võimas süsteem, millel on visuaalne liides.
Üks Gitlabi komponentidest on Gitlab CI. See võimaldab teil kirjeldada käskude seeriat, mida hiljem kasutatakse koodi edastamise süsteemi korraldamiseks või automatiseeritud testimise käivitamiseks.
Aruanne Gitlab CI 2 kohta — Ruby Russia klubi aruanne on üsna üksikasjalik ja võib teile huvi pakkuda.
Nüüd vaatame, mida on vaja Gitlab CI aktiveerimiseks. Gitlab CI käivitamiseks peame lihtsalt panema faili .gitlab-ci.yml projekti juure.
Siin kirjeldame, et tahame läbi viia olekute jada, näiteks testimine, juurutamine.
Käivitame skripte, mis kutsuvad otse meie rakenduse docker-compose ehitust. See on näide ainult taustaprogrammist.
Järgmisena ütleme, et andmebaasi muutmiseks ja testide tegemiseks on vaja käivitada migratsioonid.
Kui skripte käivitatakse õigesti ja need ei tagasta veakoodi, liigub süsteem juurutamise teise etappi.
Kasutuselevõtu etapp on praegu rakendatud lavastuseks. Me ei korraldanud seisakuta taaskäivitamist.
Sundkustutame kõik konteinerid ja seejärel tõstame uuesti kõik konteinerid, mis on testimise käigus esimeses etapis kogutud.
Käivitame andmebaaside migratsioonid, mille arendajad kirjutasid praeguse muutujakeskkonna jaoks.
On märkus, et seda tuleks rakendada ainult põhiharu puhul.
Teiste harude vahetamisel ei tööta.
Väljalaskmisi on võimalik korraldada piki oksi.
Selle edasiseks korraldamiseks peame installima Gitlab Runneri.
See utiliit on kirjutatud Golangi keeles. See on üks fail, nagu Golangi maailmas tavaline, mis ei nõua sõltuvusi.
Käivitamisel registreerime Gitlab Runneri.
Võtme saame Gitlabi veebiliideses.
Seejärel kutsume käsurealt initsialiseerimiskäsku.
Gitlab Runneri konfigureerimine dialoogirežiimis (Shell, Docker, VirtualBox, SSH)
Gitlab Runneris olev kood käivitatakse iga sissekande korral sõltuvalt .gitlab-ci.yml sättest.
Kuidas see Gitlabis veebiliideses visuaalselt välja näeb. Pärast GItlab CI ühendamist on meil lipp, mis näitab, millises olekus ehitamine hetkel on.
Näeme, et 4 minutit tagasi tehti commit, mis läbis kõik testid ja ei tekitanud probleeme.
Saame konstruktsioone üksikasjalikumalt vaadata. Siin näeme, et kaks osariiki on juba möödas. Oleku ja juurutamise oleku testimine etapis.
Kui klõpsame konkreetsel järgul, kuvatakse protsessi käigus .gitlab-ci.yml järgi käivitatud käskude konsooliväljund.
Selline näeb välja meie toote lugu. Näeme, et on olnud edukaid katseid. Testide esitamisel need järgmisse etappi ei liigu ja lavastuskoodi ei uuendata.
Milliseid probleeme me dokkeri juurutamisel lavastuses lahendasime? Meie süsteem koosneb komponentidest ja me pidime taaskäivitama ainult mõned hoidlas värskendatud komponendid, mitte kogu süsteemi.
Selleks pidime kõik eraldi kaustadesse eraldama.
Pärast seda, kui me seda tegime, tekkis meil probleem, et Docker-compose loob iga kausta jaoks oma võrguruumi ega näe oma naabri komponente.
Liikumiseks lõime võrgu Dockeris käsitsi. Docker-compose'is oli kirjas, et sellist võrku peaksite selle projekti jaoks kasutama.
Seega näeb iga selle võrgusilmaga algav komponent komponente süsteemi teistes osades.
Järgmine probleem on lavastuse jagamine mitme projekti vahel.
Kuna selleks, et see kõik ilus ja võimalikult tootmislähedane välja näeks, on hea kasutada porti 80 või 443, mis on igal pool WEBis kasutusel.
Kuidas me selle lahendasime? Määrasime kõikidele suurprojektidele ühe Gitlab Runneri.
Gitlab võimaldab käivitada mitu hajutatud Gitlab Runnerit, mis lihtsalt võtavad kõik ülesanded ükshaaval kaootilises järjekorras ja käivitavad need.
Majaprobleemide vältimiseks piirasime oma projektide rühma ühe Gitlab Runneriga, mis saab meie mahtudega probleemideta hakkama.
Teisaldasime nginx-puhverserveri eraldi käivitusskripti ja kirjutasime sellesse kõigi projektide ruudustikud.
Meie projektil on üks ruudustik ja tasakaalustajal mitu ruudustikku, mis põhinevad projekti nimedel. See võib domeeninimede järgi edasi kasutada puhverserverit.
Meie päringud tulevad pordi 80 domeeni kaudu ja lahendatakse seda domeeni teenindavale konteinerite rühmale.
Milliseid muid probleeme oli? See on see, mida kõik konteinerid vaikimisi käitavad root kasutajana. See on süsteemi juur-ebavõrdne juurperemees.
Kui aga sisestate konteineri, on see juurfail ja fail, mille selles konteineris loome, saab juurõigused.
Kui arendaja sisenes konteinerisse ja tegi seal mingeid käske, mis genereeris faile, siis lahkus konteinerist, siis tema töökataloogis on fail, millele tal pole juurdepääsu.
Kuidas seda lahendada? Saate lisada kasutajaid, kes on konteineris.
Millised probleemid tekkisid kasutaja lisamisel?
Kasutaja loomisel ei kattu sageli grupi ID (UID) ja kasutajatunnus (GID).
Selle probleemi lahendamiseks konteineris kasutame kasutajaid ID 1000-ga.
Meie puhul langes see kokku tõsiasjaga, et peaaegu kõik arendajad kasutavad Ubuntu OS-i. Ja Ubuntu OS-is on esimesel kasutajal ID 1000.
Kas meil on plaane?
Lugege uuesti Dockeri dokumentatsiooni. Projekt areneb aktiivselt, dokumentatsioon muutub. Kaks või kolm kuud tagasi kogutud andmed on aeglaselt vananenud.
Mõned meie lahendatud probleemid võivad olla juba tavapäraste vahenditega lahendatud.
Ma tõesti tahan edasi liikuda ja minna otse orkestreerimise juurde.
Üks näide on Dockeri sisseehitatud mehhanism nimega Docker Swarm, mis tuleb karbist välja. Tahaksin midagi Docker Swarmi tehnoloogial põhinevat tootmist käivitada.
Kudemiskonteinerid muudavad palkidega töötamise ebamugavaks. Nüüd on palgid isoleeritud. Need on konteinerites laiali. Üks ülesandeid on teha veebiliidese kaudu mugav juurdepääs logidele.
Allikas: www.habr.com