Predlagam, da se seznanite z razlago poročila Aleksandra Sigačeva iz Inventosa "Postopek razvoja in testiranja z Docker + Gitlab CI"
Tisti, ki se šele začnejo uvajati v proces razvoja in testiranja na osnovi Docker + Gitlab CI, pogosto postavljajo osnovna vprašanja. Kje začeti? Kako organizirati? Kako testirati?
To poročilo je dobro, ker strukturirano opisuje proces razvoja in testiranja z uporabo Docker in Gitlab CI. Samo poročilo je iz leta 2017. Menim, da lahko iz tega poročila pridobite osnove, metodologijo, idejo in izkušnjo uporabe.
Kdor je zainteresiran, naj se preseli pod kat.
Moje ime je Aleksander Sigačev. Delam v podjetju Inventos. Povedal bom o svojih izkušnjah z uporabo Dockerja in o tem, kako ga počasi uvajamo v projekte v podjetju.
Tema poročila: Postopek razvoja z uporabo Docker in Gitlab CI.
To je moje drugo poročilo o Dockerju. Ob času prvega poročila smo Docker uporabljali le v razvoju na računalnikih razvijalcev. Število zaposlenih, ki so uporabljali Docker, je bilo približno 2-3 osebe. Postopoma so se nabrale izkušnje in precej smo napredovali. Povezava na naše .
Kaj bo v tem poročilu? Delili bomo izkušnje o tem, katere pastirje smo naleteli, kako smo reševali težave. Ni vse potekalo gladko, a je omogočilo napredek.
Naša deviza: dockeriziraj vse, kar nam pride pod roke.
Katere težave rešujemo?
Ko ima podjetje več ekip, je programer skupen vir. Obstajajo faze, ko programerja potegnemo iz enega projekta in ga za nekaj časa dodamo drugemu projektu.
Da se programer hitro usposobi, mora prenesti izvorno kodo projekta in čim hitreje zagnati okolje, ki mu bo omogočilo napredovati pri reševanju nalog tega projekta.
Običajno, če začnemo z ničle, je dokumentacije v projektu malo. Informacije o tem, kako nastaviti, ima le nekaj najstarejših. Zaposleni sami nastavljajo svoje delovno mesto v enem ali dveh dneh. Da bi to pospešili, smo uporabili Docker.
Naslednji razlog je standardizacija nastavitev v razvoju. Po mojem mnenju programerji vedno pokažejo iniciativo. V vsakem petem primeru se vnese prilagojena domena, na primer vasya.dev. Poleg sedi sosed Petja, ki ima domeno petya.dev. Razvijata spletno stran ali sestavni del sistema, pri čemer uporabljata to domeno.
Ko ko sistemă se razvija in ta domena začne vplivati na konfiguracije, se pojavi konflikt med razvojno okolje in pot spletne strani se prepiše.
Enako se dogaja s konfiguracijami podatkovne baze. Nekdo se ne obremenjuje s varnostjo in dela s praznim geslom za root. Pri nekaterih je med namestitvijo MySQL geslo dejansko zahtevano in geslo se izkaže za 123. Pogosto se zgodi, da se konfiguracija podatkovne baze nenehno spreminja glede na commit razvijalca. Nekdo je popravil, nekdo ni popravil konfiguracije. Obstajajo iznajdljivosti, ko smo testno konfiguracijo prestavili v .gitignore in vsak razvijalec je moral namestiti podatkovno bazo. To je zapletlo postopek zagona. Poleg vsega je potrebno pomniti tudi podatkovno bazo. Podatkovna baza mora biti inicializirana, potrebno je vpisati geslo, potrebno je vpisati uporabnika, ustvariti tabelo in tako naprej.
Še en problem so različne različice knjižnic. Pogosto se zgodi, da razvijalec dela na različnih projektih. Obstaja Legacy projekt, ki smo ga začeli pred petimi leti (od leta 2017 - op. red.). Ob začetku smo uporabili MySQL 5.5. Imamo pa tudi moderne projekte, kjer si prizadevamo uvesti že bolj sodobne različice MySQL, na primer 5.7 ali starejše (v letu 2017 - op. red.)
Tisti, ki dela s MySQL, ve, da te knjižnice zadržujejo odvisnosti. Zagon dveh baz skupaj je precej problematičen. Vsaj stare stranke je problematično povezati z novo podatkovno bazo. To povzroča več težav.
Naslednji problem je, ko razvijalec dela na lokalnem računalniku, uporablja lokalne vire, lokalne datoteke, lokalni RAM. Vse interakcije med razvojem rešitev se izvajajo na podlagi delovanja na enem računalniku. Primer je, ko imamo v produkciji 3 strežnike z ozadjem, razvijalec pa shranjuje datoteke v korenski imenik in od tam nginx pridobiva datoteke za odgovor na zahtevek. Ko takšna koda pride v produkcijo, se izkaže, da je datoteka prisotna le na enem od teh treh strežnikov.
Trenutno se razvija područje mikroslužbi. Kada svoja velika aplikacije dijelimo na manje komponente koje međusobno komuniciraju. To omogućava odabir tehnologija specifičnih za određenu skupinu zadataka. Također, to omogućava razdvajanje posla i odgovornosti među programerima.
Frontend programer, razvijajući u JS-u, praktički ne utječe na Backend. Backend programer, s druge strane, razvija, u našem slučaju, Ruby on Rails i ne ometa Frontend. Interakcija se odvija putem API-ja.
Kao bonus, pomoću Dockera uspjeli smo optimizirati resurse na Stagingu. Svaki projekt je zbog svoje specifičnosti zahtijevao određena podešavanja. Fizički je bilo potrebno dodijeliti ili virtuelni server i zasebno ga konfigurirati, ili dijeliti određeno varijabilno okruženje, a projekti su mogli međusobno utjecati jedni na druge ovisno o verzijama biblioteka.
Alati. Što koristimo?
- Sam Docker. U Dockerfile-u se opisuju zavisnosti jedne aplikacije.
- Docker-compose je poveznica koja spaja nekoliko naših Docker aplikacija.
- GitLab koristimo za pohranu izvornog koda.
- GitLab-CI koristimo za sistemsku integraciju.
Izvješće se sastoji od dva dijela.
Prvi dio govori o tome kako smo pokrenuli Docker na radnim stanicama programera.
Drugi dio govori o tome kako komunicirati s GitLabom, kako pokrećemo testove i kako objavljujemo na Staging.
Docker je tehnologija koja omogućava (koristeći deklarativni pristup) opisivanje neophodnih komponenti. Ovo je primjer Dockerfile-a. Ovdje objavljujemo da nasljeđujemo od službenog Docker imidža Ruby:2.3.0. On sadrži instalirani Ruby verzije 2.3. Instaliramo potrebne biblioteke za izgradnju i NodeJS. Opisujemo da kreiramo direktorij /app. Postavljamo direktorij app kao radnu direktoriju. U ovaj direktorij stavljamo potrebni minimalni Gemfile i Gemfile.lock. Zatim provodimo izgradnju projekata, koji instaliraju ovaj imidž zavisnosti. Očekujemo da će kontejner biti spreman slušati na vanjskom portu 3000. Posljednja naredba je naredba koja izravno pokreće našu aplikaciju. Ako izvršimo naredbu za pokretanje projekta, aplikacija će pokušati izvršiti i pokrenuti navedenu naredbu.
To je minimalni primjer docker-compose datoteke. U ovom slučaju prikazujemo kako se povezuju dva kontejnera. To su usluga baze podataka i web usluga. Naše web aplikacije većinom zahtijevaju neku bazu podataka kao backend za pohranu podataka. Budući da koristimo MySQL, primjer s MySQL-om — ali ništa ne sprječava korištenje neke druge baze podataka (PostgreSQL, Redis).
Uzeli smo iz službenog izvora s Docker Hub-a sliku MySQL 5.7.14 bez izmjena. Slika koja odgovara našoj web aplikaciji se sastavlja iz trenutnog direktorija. Tijekom prvog pokretanja sastavlja nam sliku. Nakon toga pokreće naredbu koju ovdje izvršavamo. Ako se vratimo unazad, vidjet ćemo da je definirana naredba pokretanja putem Pume. Puma je usluga napisana u Ruby-u. U drugom slučaju predefiniramo. Ova naredba može biti proizvoljna, ovisno o našim potrebama ili zadacima.
Također opisujemo da je potrebno proslijediti port s 3000 na našoj domaćinskoj mašini na port 3000 kontejnera. To se automatski izvršava pomoću iptables i vlastitog mehanizma koji je izravno ugrađen u Docker.
Razvijač se također može kao i ranije obratiti bilo kojem dostupnom IP adresi, na primjer, 127.0.0.1 lokalnom ili vanjskom IP adresom mašine.
Zadnji redak govori da kontejner web ovisi o kontejneru db. Kada pozovemo pokretanje kontejnera web, docker-compose prvo pokreće našu bazu podataka. Već po startu baze podataka (zapravo — nakon pokretanja kontejnera! Spremnost Baze podataka to ne jamči) pokreće nam aplikaciju, naš backend.
To omogućava izbjegavanje grešaka kada baza podataka nije podignuta i štedi resurse kada zaustavljamo kontejner baze podataka, oslobađajući time resurse za druge projekte.
Što nam daje korištenje dockerizacije baze podataka u projektu. Kod svih razvijača fiksiramo verziju MySQL-a. To pomaže izbjegavanju nekih grešaka koje mogu nastati zbog razlika u verzijama kada se mijenja sintaksa, konfiguracija, zadane postavke. To omogućuje navođenje zajedničkih hostname za bazu podataka, login, password. Odlazimo od tog zoo imena i sukoba u config datotekama koji su postojali ranije.
Imamo mogućnost korištenja optimiziranog konfiguracijskog rješenja za razvojno okruženje, koje će se razlikovati od zadane postavke. MySQL je po defaultu postavljen za slabe mašine i njegova izvedba iz kutije je vrlo niska.
Docker omogućava korištenje interpreterâ za Python, Ruby, NodeJS i PHP potrebnih verzija. Oslobađamo se potrebe korištenja upravitelja verzija. Prije smo koristili rpm paket za Ruby koji je omogućavao promjenu verzije ovisno o projektu. Također, zahvaljujući Docker kontejneru, lakše možemo migrirati kod i verzionirati ga zajedno sa zavisnostima. Nemamo problema s razumijevanjem verzije i interpretatora, kao i koda. Za ažuriranje verzije potrebno je srušiti stari kontejner i podići novi. Ako nešto pođe po zlu, možemo srušiti novi kontejner i podići stari.
Nakon izgradnje slike, kontejneri u razvoju i produkciji bit će isti. To je posebno važno za velike instalacije.
Na frontend-u koristimo JavaScript i NodeJS.
Trenutno je naš posljednji projekt na ReactJS-u. Razvijač je pokrenuo sve kontejnere i radio razvijajući uz pomoć hot-reload-a.
Nakon toga pokreće se zadatak za izgradnju JavaScript-a, a kod, sakupljen u statiku, isporučuje se putem nginx-a, štedeći resurse.
Ovdje sam prikazao shemu našeg posljednjeg projekta.
Koje smo zadatke rješavali? Imali smo potrebu za izgradnjom sustava s kojim komuniciraju mobilni uređaji. Oni primaju podatke. Jedna od opcija je slanje push obavijesti na ovaj uređaj.
Što smo za to učinili?
Podijelili smo aplikaciju u komponente kao što su: administratorski dio na JS-u, backend koji radi putem REST sučelja pod Ruby on Rails. Backend komunicira s bazom podataka. Rezultat, koji se generira, isporučuje se klijentu. Administratorski dio komunicira s backend-om i bazom podataka putem REST sučelja.
Također smo imali potrebu slati push obavijesti. Prije toga imali smo projekt u kojem je bio implementiran mehanizam koji je odgovarao za isporuku obavijesti na mobilne platforme.
Razvili smo shemu: operater iz preglednika komunicira s administratorskim sučeljem, administratorsko sučelje komunicira s backend-om, postavlja se zadatak da treba poslati push obavijesti.
Push obavijesti komuniciraju s drugim komponentom, koja je implementirana na NodeJS-u.
Čakajo se vrste in nato poteka po svojem mehanizmu pošiljanje obvestil.
Tukaj so prikazani dve podatkovni bazi. Trenutno uporabljamo 2 neodvisni podatkovni bazi prek Dockerja, ki medsebojno nista povezani. Edina povezava je, da imata skupno virtualno omrežje, fizični podatki pa so shranjeni v različnih imenikih na razvijalčevem računalniku.
Tisto isto, a v številkah. Tu je pomembno ponovno uporabiti kodo.
Če smo prej govorili o ponovni uporabi kode v obliki knjižnic, je v tem primeru naša storitev, ki odgovarja za Push obvestila, ponovno uporabljena kot popolni strežnik. Ponuja API. In z njim sodeluje naša nova razvojna rešitev.
Takrat smo uporabljali 4. različico NodeJS. Zdaj (v letu 2017 – op. ured.) v novih razvojnih projektih uporabljamo 7. različico NodeJS. Ni težav, da bi v novih komponentah uporabili nove različice knjižnic.
Po potrebi je mogoče izvesti refaktoring in dvigniti različico NodeJS pri storitvi Push obvestil.
In če bomo lahko ohranili združljivost po API-ju, ga bo mogoče zamenjati v drugih projektih, ki so bili uporabljeni prej.
Kaj potrebujemo, da dodamo Docker? Dodamo v naš repozitorij Dockerfile, ki opisuje potrebne odvisnosti. V tem primeru so komponente razdeljene po logiki. To je minimalen nabor za backend razvijalca.
Pri ustvarjanju novega projekta ustvarimo Dockerfile, opišemo potrebno ekosistem (Python, Ruby, NodeJS). V docker-compose opisujemo potrebno odvisnost – podatkovna baza. Opišemo, da potrebujemo bazo določene različice, ki shranjuje podatke na tistem in tistem mestu.
Za dostavo statike uporabljamo ločen tretji kontejner z nginx-om. Predvidena je možnost nalaganja slik. Backend jih shranjuje v vnaprej pripravljenem volumnu, ki je prav tako montiran v kontejner z nginx-om, ki dostavlja statiko.
Da bi shranili konfiguracijo nginx-a in mysql-a, smo dodali mapo Docker, v kateri shranjujemo potrebne konfiguracije. Ko razvijalec opravi git clone repozitorija na svoj računalnik, dobi projekt že pripravljen za lokalni razvoj. Ni vprašanj, kateri port ali katere nastavitve uporabiti.
Nato imamo nekaj komponent: admin, inform-API, push-obvestila.
Da bi to sve pokrenuli, stvorili smo još jedan repozitorij koji smo nazvali dockerized-app. U ovom trenutku koristimo nekoliko repozitorija za svaki komponent. Oni se logički razlikuju — u GitLabu to izgleda kao folder, a na razvojnim mašinama kao folder za konkretan projekt. Na nižem nivou se nalaze komponente koje će se objediniti.
Ovo je primer sadržaja dockerized-app. Takođe ovde iznosimo Docker katalog, u kojem popunjavamo konfiguracije potrebne za interakciju svih komponenti. Tu je README.md, u kojem je kratko opisano kako pokrenuti projekt.
Ovde smo primenili dva docker-compose fajla. To je učinjeno kako bismo imali mogućnost postupnog pokretanja. Kada developer radi sa kičmom, nije mu potrebna Push obaveštenja, on jednostavno pokreće docker-compose fajl i tako se štedi resurs.
Ako postoji potreba za integracijom sa Push obaveštenjima, tada se pokreće docker-compose.yaml i docker-compose-push.yaml.
Pošto se docker-compose.yaml i docker-compose-push.yaml nalaze u folderu, automatski se stvara jedinstvena virtuelna mreža.
Opis komponenti. Ovo je prošireni fajl koji odgovara za sastavljanje komponenti. Šta je zanimljivo ovde? Uvodimo komponent balansir.
Ovo je gotov Docker image u kojem se pokreće nginx i aplikacija koja sluša Docker socket. Dinamički, kako se uključuju i isključuju kontejneri, regeneriše se nginx konfiguracija. Obrada sa komponentama je raspoređena po domenima treće razine.
Za razvojnu sredinu koristimo .dev domen — api.informer.dev. Aplikacije na .dev domenu su dostupne na lokalnoj mašini developera.
Dalje se prosleđuju konfiguracije do svakog projekta i pokreću se svi projekti zajedno istovremeno.
Ako grafički prikažemo, klijent je naš pretraživač ili neki alat kojim obavljamo upite na balansir.
Balansir po domenskom imenu određuje kojem kontejneru treba pristupiti.
To može biti nginx koji isporučuje JS administracije. Može biti nginx koji vraća API ili statičke fajlove koje nginx isporučuje u obliku preuzimanja slika.
Na dijagramu se može videti da su kontejneri spojeni u virtuelnu mrežu i skrivene iza proxyja.
Na razvojnem stroju lahko dostopate do kontejnerja z znanjem IP, vendar tega načeloma ne uporabljamo. Neposredni dostop praktično ni potreben.
Kateri primer lahko pogledam, da dockeriziram svojo aplikacijo? Dobro izhodišče je uradna docker slika za MySQL.
To je kar zapleteno. Ima veliko različic. Vendar njegova funkcionalnost pokriva številne potrebe, ki se lahko pojavijo med nadaljnjim razvojem. Če boste porabili čas in razumeli, kako vse to deluje, mislim, da pri samostojni implementaciji ne boste imeli težav.
Na hub.docker.com običajno najdete povezave na github.com, kjer so navedeni surovi podatki, iz katerih lahko sami sestavite sliko.
Nato je v tem repozitoriju prisoten skript docker-endpoint.sh, ki je odgovoren za začetno inicializacijo in nadaljnjo obdelavo zagona aplikacije.
Ta primer prav tako omogoča konfiguracijo s pomočjo okolijskih spremenljivk. Z določitvijo okoljske spremenljivke pri zagonu posameznega kontejnerja ali prek docker-compose lahko rečemo, da moramo določiti prazen geslo za docker ali pa kakšno, ki jo želimo za root na MySQL.
Obstaja možnost ustvariti naključno geslo. Povedali bomo, da potrebujemo uporabnika, ki potrebuje geslo in potrebno je ustvariti bazo podatkov.
V svojih projektih smo nekoliko unificirali Dockerfile, ki odgovarja za inicializacijo. Tam smo prilagodili svojemu potrebam zgolj razširitev pravic uporabnika, ki ga uporablja aplikacija. To je omogočilo enostavno ustvarjanje baze podatkov iz konzole aplikacije. V Ruby aplikacijah obstaja ukaz za ustvarjanje, spreminjanje in brisanje baz podatkov.
To je primer, kako izgleda določena različica MySQL na github.com. Dockerfile lahko odprete in vidite, kako poteka namestitev.
docker-endpoint.sh je skript, ki je odgovoren za vhodno točko. Pri začetni inicializaciji so potrebni določeni postopki priprave in vsi ti postopki so pravzaprav vključeni v skript za inicializacijo.
Preidemo v drugi del.
Za shranjevanje izvorne kode smo prešli na gitlab. To je dovolj močan sistem, ki ima vizualni vmesnik.
Eden iz komponentov Gitlaba je Gitlab CI. Omogoča opisati zaporedje ukazov, ki se bodo kasneje uporabljali za organizacijo sistema dostave kode ali izvajanje samodejnega testiranja.
Poročilo o Gitlab CI 2 — poročilo z Ruby Russia kluba — dovolj podrobno in morda vas bo zanimalo.
Zdaj bomo preučili, kaj potrebujemo, da aktiviramo Gitlab CI. Da zaženemo Gitlab CI, nam zadostuje, da v koren projekta postavimo datoteko .gitlab-ci.yml.
Tukaj opisujemo, kaj želimo izvajati v zaporedju stanj, kot so testi in nameščanje.
Izvajamo skripte, ki neposredno kličo docker-compose za sestavljanje naše aplikacije. To je primer za backend.
Nato povemo, da je potrebno izvesti migracije za spremembe v bazi podatkov in izvesti teste.
Če se skripti izvajajo pravilno in ne vračajo kode napake, se sistem ustrezno preklopi na drugo fazo nameščanja.
Faza nameščanja trenutno deluje za staging. Nismo organizirali brezprekinjenega ponovnega zagon.
Prisilno ugasnemo vse kontejnerje, nato pa vse kontejnerje ponovno zagonimo, zgrajene v prvi fazi pri testiranju.
Izvajamo migracije baz podatkov, ki so jih napisali razvijalci, za trenutno spremenljivo okolje.
Obstaja opomba, da se to uporabi samo za glavno vejo.
Pri spremembah drugih vej se ne izvede.
Obstaja možnost organizirati izvedbe po vejah.
Da bi to nadalje organizirali, moramo namestiti Gitlab Runner.
To orodje je napisano v Golangu. Je enojna datoteka, kot je običajno v svetu Golanga, ki ne zahteva nobenih odvisnosti.
Ob zagonu registriramo Gitlab Runner.
V spletnem vmesniku Gitlab pridobimo ključ.
Nato kličemo ukaz za inicializacijo v ukazni vrstici.
Nastavimo Gitlab Runner v dialogovnem načinu (Shell, Docker, VirtualBox, SSH).
Koda na Gitlab Runner se bo izvajala ob vsaki commit-u, odvisno od nastavitve .gitlab-ci.yml.
Kako to vizualno izgleda v Gitlabu v spletnem vmesniku. Ko aktiviramo Gitlab CI, se pojavi zastavica, ki prikazuje, v katerem stanju je trenutno gradnja.
Vidimo, da je pred 4 minutami bil izveden commit, ki je prestal vse teste in ni povzročil težav.
Lahko se podrobneje posvetimo gradnjam. Tukaj vidimo, da sta že prešli dve stanje. Stanje testiranja in stanje implementacije na staging.
Če kliknemo na konkretno gradnjo, bomo videli izhod konzole ukazov, ki so bili izvedeni v postopku v skladu z .gitlab-ci.yml.
Tako izgleda zgodovina našega produkta. Vidimo, da so bile uspešne poskuse. Ko testi ne uspejo, naslednji korak ne preide in koda na staging se ne posodobi.
Kakšne naloge smo rešili na stagingu, ko smo uvedli docker? Naš sistem je sestavljen iz komponent in imeli smo potrebo po ponovnem zagonu le dela komponent, ki so bile posodobljene v repozitoriju, ne celotnega sistema.
Zato smo morali vse razdeliti v ločene mape.
Potem ko smo to naredili, smo naleteli na težavo, da Docker-compose ustvarja lastno omrežje za vsako mapo in ne vidi komponent soseda.
Da bi to obšli, smo ročno ustvarili omrežje v Dockerju. V Docker-compose smo zapisali, naj uporablja to omrežje za ta projekt.
Tako lahko vsaka komponenta, ki se zažene s to mrežo, vidi komponente na drugih delih sistema.
Naslednja težava je bila razdelitev staginga med več projekti.
Da bi vse to izgledalo lepo in čim bližje produkciji, je najbolje uporabiti port 80 ali 443, ki se povsod uporablja v spletu.
Kako smo to rešili? Dodelili smo enega Gitlab Runnerja vsem obsežnim projektom.
Gitlab omogoča zagon več porazdeljenih Gitlab Runnerjev, ki preprosto izmenično in naključno prevzemajo vse naloge in jih izvajajo.
Da ne bi prišlo do zmede, smo omejili skupino naših projektov na enega Gitlab Runnerja, ki ob naših obsegih brez težav obvladuje naloge.
Nginx-proxy smo izločili v ločen zagon skripta in v njem zapisali mreže vseh projektov.
Naš projekt ima eno mrežo, medtem ko obtežnik ima več mrež po imenih projektov. Lahko naprej posreduje preko domen.
Naši zahtevki prihajajo po domeni na port 80 in se razdelijo v skupino kontejnerjev, ki obravnava to domeno.
Kakšne druge težave so bile? To, da po privzetku vsi kontejnerji delujejo pod uporabnikom root. Ta root ni enak rootu gostiteljske sisteme.
Vendar, če vstopite v kontejner, bo to root, in datoteka, ki jo ustvarimo v tem kontejnerju, dobi pravice root.
Če je razvijalec vstopil v kontejner in tam izvedel kakšne ukaze, ki so ustvarili datoteke, in potem zapustil kontejner, potem v svoji delovni direktoriji ima datoteko, do katere nima dostopa.
Kako to rešiti? Lahko dodamo uporabnike, ki bodo v kontejnerju.
Kakšne težave so se pojavile, ko smo dodali uporabnika?
Pri ustvarjanju uporabnika se nam pogosto ne ujemata ID skupine (UID) in ID uporabnika (GID).
Da bi rešili ta problem, v kontejnerju uporabljamo uporabnike z ID 1000.
V našem primeru se je to ujemalo s tem, da skoraj vsi razvijalci uporabljajo operacijski sistem Ubuntu. In v sistemu Ubuntu ima prvi uporabnik ID 1000.
Kakšni so naši načrti?
Prebrati dokumentacijo o Dockerju. Projekt se aktivno razvija, dokumentacija se spreminja. Podatki, ki so bili pridobljeni pred dvemi ali tremi meseci, že počasi zastarjajo.
Del težav, ki smo jih reševali, je povsem mogoče, da je že rešen z običajnimi sredstvi.
Tako si želimo iti naprej in se neposredno preusmeriti na orkestracijo.
Eden od primerov je v Docker vgrajeni mehanizem, imenovan Docker Swarm, ki se predstavi kar iz škatle. Želim zagnati nekaj v produkciji na osnovi tehnologije Docker Swarm.
Ustvarjanje kontejnerjev otežuje delo zlogi. Sedaj so logi izolirani. Razpršeni so po kontejnerjih. Ena od nalog je zagotoviti enostaven dostop do logov preko spletnega vmesnika.
Izvor: habr.com
