Predlagam, da preberete prepis poročila Aleksandra Sigačeva iz Inventosa "Proces razvoja in testiranja z Docker + Gitlab CI"
Tisti, ki šele začenjajo izvajati proces razvoja in testiranja, ki temelji na Docker + Gitlab CI, pogosto postavljajo osnovna vprašanja. Kje začeti? Kako organizirati? Kako testirati?
To poročilo je dobro, ker na strukturiran način govori o procesu razvoja in testiranja z uporabo Dockerja in Gitlab CI. Samo poročilo je iz leta 2017. Mislim, da se lahko iz tega poročila naučite osnov, metodologije, ideje, izkušenj z uporabo.
Koga briga, prosim pod kat.
Moje ime je Alexander Sigachev. Delam za Inventos. Povedal vam bom o svojih izkušnjah z uporabo Dockerja in kako ga postopoma implementiramo na projekte v podjetju.
Tema predstavitve: Razvojni proces z uporabo Docker in Gitlab CI.
To je moj drugi govor o Dockerju. V času prvega poročila smo Docker v razvoju uporabljali samo na strojih za razvijalce. Število zaposlenih, ki so uporabljali Docker, je bilo približno 2-3 ljudi. Postopoma so se nabirale izkušnje in šli smo malo naprej. Povezava do našega .
Kaj bo v tem poročilu? Delili bomo svoje izkušnje o tem, kakšne grablje smo zbrali, katere težave smo rešili. Ni bilo povsod lepo, a dovoljeno je iti naprej.
Naš moto je: priklopiti vse, kar nam pride pod roke.
Kakšne probleme rešujemo?
Ko je v podjetju več ekip, je programer skupni vir. Obstajajo faze, ko programerja izvlečejo iz enega projekta in ga za nekaj časa predajo drugemu projektu.
Da bi programer hitro razumel, mora prenesti izvorno kodo projekta in čim prej zagnati okolje, kar mu bo omogočilo nadaljnje reševanje problemov tega projekta.
Običajno, če začnete iz nič, je v projektu malo dokumentacije. Informacije o postavitvi so na voljo le starodobnikom. Zaposleni si v enem ali dveh dneh sami uredijo svoje delovno mesto. Da bi to pospešili, smo uporabili Docker.
Naslednji razlog je standardizacija nastavitev v Razvoju. Po mojih izkušnjah razvijalci vedno prevzamejo pobudo. V vsakem petem primeru je vnesena domena po meri, na primer vasya.dev. Poleg njega sedi njegov sosed Petya, katerega domena je petya.dev. S to domeno razvijejo spletno mesto ali kakšno komponento sistema.
Ko sistem raste in se ta imena domen začnejo spreminjati v konfiguracije, pride do konflikta razvojnega okolja in pot do mesta se prepiše.
Enako se zgodi z nastavitvami baze podatkov. Nekdo se ne obremenjuje z varnostjo in dela s praznim root geslom. V fazi namestitve je MySQL nekoga vprašal za geslo in izkazalo se je, da je geslo 123. Pogosto se zgodi, da se konfiguracija baze podatkov nenehno spreminja glede na zavezo razvijalca. Nekdo je popravil, nekdo ni popravil konfiguracije. Obstajali so triki, ko smo vzeli nekakšno testno konfiguracijo .gitignore in vsak razvijalec je moral namestiti bazo podatkov. Zaradi tega je bilo težko začeti. Med drugim se je treba spomniti na bazo podatkov. Baza mora biti inicializirana, vnešeno geslo, registriran uporabnik, izdelana tabela itd.
Druga težava so različne različice knjižnic. Pogosto se zgodi, da razvijalec dela z različnimi projekti. Obstaja projekt Legacy, ki se je začel pred petimi leti (od 2017 - op. ur.). V času lansiranja smo začeli z MySQL 5.5. Obstajajo tudi sodobni projekti, kjer poskušamo implementirati sodobnejše različice MySQL, na primer 5.7 ali starejše (leta 2017 - op. ur.)
Vsakdo, ki dela z MySQL, ve, da te knjižnice s seboj prinašajo odvisnosti. Precej problematično je voditi 2 bazi skupaj. Stare odjemalce je vsaj težko povezati z novo bazo podatkov. To pa ustvarja številne težave.
Naslednja težava je, ko razvijalec dela na lokalnem računalniku, uporablja lokalne vire, lokalne datoteke, lokalni RAM. Vsa interakcija v času razvoja rešitve problemov poteka v okviru dejstva, da deluje na enem stroju. Primer je, ko imamo zaledne strežnike v proizvodnji 3 in razvijalec shrani datoteke v korenski imenik in od tam nginx vzame datoteke za odgovor na zahtevo. Ko taka koda pride v produkcijo, se izkaže, da je datoteka prisotna na enem od 3 strežnikov.
Smer mikrostoritev se zdaj razvija. Ko naše velike aplikacije razdelimo na nekaj majhnih komponent, ki medsebojno delujejo. To vam omogoča, da izberete tehnologije za določen kup nalog. Omogoča tudi delitev dela in odgovornosti med razvijalci.
Frondend-razvijalec, ki razvija na JS, nima skoraj nobenega vpliva na Backend. Zaledni razvijalec pa razvija, v našem primeru, Ruby on Rails in se ne vmešava v Frondend. Interakcija poteka s pomočjo API-ja.
Kot bonus smo lahko s pomočjo Dockerja reciklirali vire na Staging. Vsak projekt je zaradi svoje specifičnosti zahteval določene nastavitve. Fizično je bilo treba bodisi dodeliti virtualni strežnik in ju konfigurirati ločeno, bodisi deliti nekakšno spremenljivo okolje in projekti bi lahko, odvisno od različice knjižnic, vplivali drug na drugega.
Orodja. Kaj uporabljamo?
- Docker sam. Dockerfile opisuje odvisnosti posamezne aplikacije.
- Docker-compose je sveženj, ki združuje nekaj naših aplikacij Docker.
- Za shranjevanje izvorne kode uporabljamo GitLab.
- Za sistemsko integracijo uporabljamo GitLab-CI.
Poročilo je sestavljeno iz dveh delov.
Prvi del bo govoril o tem, kako se je Docker izvajal na strojih razvijalcev.
Drugi del bo govoril o tem, kako komunicirati z GitLabom, kako izvajamo teste in kako se uvajamo v Staging.
Docker je tehnologija, ki omogoča (z uporabo deklarativnega pristopa) opis potrebnih komponent. To je primer datoteke Docker. Tukaj izjavljamo, da podedujemo uradno sliko Ruby:2.3.0 Docker. Vsebuje nameščen Ruby različice 2.3. Namestimo zahtevane gradbene knjižnice in NodeJS. Opisujemo, da ustvarimo imenik /app. Nastavite imenik aplikacije kot delovni imenik. V ta imenik postavimo zahtevani minimalni Gemfile in Gemfile.lock. Nato zgradimo projekte, ki namestijo to sliko odvisnosti. Označimo, da bo vsebnik pripravljen za poslušanje na zunanjih vratih 3000. Zadnji ukaz je ukaz, ki neposredno zažene našo aplikacijo. Če izvedemo ukaz za zagon projekta, bo aplikacija poskusila zagnati in zagnati navedeni ukaz.
To je minimalen primer docker-compose datoteke. V tem primeru pokažemo, da obstaja povezava med dvema vsebnikoma. To je neposredno v storitev zbirke podatkov in spletno storitev. Naše spletne aplikacije v večini primerov zahtevajo nekakšno zbirko podatkov kot zaledje za shranjevanje podatkov. Ker uporabljamo MySQL, je primer z MySQL - nič pa nam ne preprečuje, da bi uporabili tudi kakšno drugo bazo (PostgreSQL, Redis).
Iz uradnega vira iz središča Docker vzamemo sliko MySQL 5.7.14 brez sprememb. Sliko, ki je odgovorna za našo spletno aplikacijo, zbiramo iz trenutnega imenika. Med prvim zagonom nam zbere sliko. Nato zažene ukaz, ki ga izvajamo tukaj. Če se vrnemo nazaj, bomo videli, da je bil definiran ukaz za zagon prek Pume. Puma je storitev, napisana v Rubyju. V drugem primeru preglasimo. Ta ukaz je lahko poljuben glede na naše potrebe ali naloge.
Opisujemo tudi, da moramo posredovati vrata na našem gostiteljskem stroju razvijalca s 3000 na 3000 na vratih vsebnika. To se izvede samodejno z uporabo iptables in njegovega mehanizma, ki je neposredno vdelan v Docker.
Razvijalec lahko kot prej dostopa do katerega koli razpoložljivega naslova IP, na primer 127.0.0.1 je lokalni ali zunanji naslov IP naprave.
Zadnja vrstica pravi, da je spletni vsebnik odvisen od vsebnika db. Ko pokličemo začetek spletnega vsebnika, bo docker-compose namesto nas najprej zagnal bazo podatkov. Že ob zagonu baze (pravzaprav po zagonu vsebnika! To ne zagotavlja pripravljenosti baze) bo zagnala aplikacijo, naše zaledje.
S tem se izognemo napakam, ko baza podatkov ni odprta, in prihranimo vire, ko ustavimo vsebnik baze podatkov, s čimer sprostimo vire za druge projekte.
Kaj nam omogoča uporabo dokerizacije baze podatkov v projektu. Popravimo različico MySQL za vse razvijalce. S tem se izognete nekaterim napakam, ki se lahko pojavijo, ko se različice razlikujejo, ko se sintaksa, konfiguracija, privzete nastavitve spremenijo. To vam omogoča, da določite skupno ime gostitelja za bazo podatkov, prijavo in geslo. Odmikamo se od živalskega vrta imen in konfliktov v konfiguracijskih datotekah, ki smo jih imeli prej.
Imamo možnost, da uporabimo bolj optimalno konfiguracijo za razvojno okolje, ki se bo razlikovala od privzete. MySQL je privzeto konfiguriran za šibke stroje in njegova zmogljivost takoj po namestitvi je zelo slaba.
Docker omogoča uporabo tolmača Python, Ruby, NodeJS, PHP želene različice. Znebimo se potrebe po uporabi neke vrste upravitelja različic. Prej je Ruby uporabljal paket rpm, ki vam je omogočal spreminjanje različice glede na projekt. Prav tako omogoča, zahvaljujoč vsebniku Docker, gladko selitev kode in njeno različico skupaj z odvisnostmi. Brez težav razumemo različico tolmača in kode. Če želite posodobiti različico, spustite staro posodo in dvignite novo posodo. Če je šlo kaj narobe, lahko spustimo novo posodo, dvignemo staro posodo.
Po izgradnji slike bosta vsebnika v razvoju in proizvodnji enaka. To še posebej velja za velike instalacije.
Na Frontendu uporabljamo JavaScipt in NodeJS.
Zdaj imamo zadnji projekt na ReacJS. Razvijalec je zagnal vse v vsebniku in razvil z vročim ponovnim nalaganjem.
Nato se zažene naloga sestavljanja JavaScipt in koda, prevedena v statiko, je dana prek virov za shranjevanje nginx.
Tukaj sem podal shemo našega zadnjega projekta.
Katere naloge so bile rešene? Morali smo zgraditi sistem, s katerim bi mobilne naprave komunicirale. Prejemajo podatke. Ena od možnosti je pošiljanje potisnih obvestil tej napravi.
Kaj smo storili za to?
V aplikacijo smo razdelili komponente kot so: skrbniški del na JS, backend, ki deluje prek vmesnika REST pod Ruby on Rails. Zaledje komunicira z bazo podatkov. Rezultat, ki je ustvarjen, je dan stranki. Skrbniška plošča komunicira z zaledjem in bazo podatkov prek vmesnika REST.
Imeli smo tudi potrebo po pošiljanju potisnih obvestil. Pred tem smo imeli projekt, ki je implementiral mehanizem, ki je odgovoren za dostavo obvestil na mobilne platforme.
Razvili smo naslednjo shemo: operater iz brskalnika komunicira z skrbniško ploščo, skrbniška plošča komunicira z zaledjem, naloga je pošiljanje potisnih obvestil.
Potisna obvestila so v interakciji z drugo komponento, ki je implementirana v NodeJS.
Zgradijo se čakalne vrste in nato se obvestila pošljejo v skladu z njihovim mehanizmom.
Tu sta narisani dve bazi podatkov. Trenutno s pomočjo Dockerja uporabljamo 2 neodvisni bazi podatkov, ki med seboj nikakor nista povezani. Poleg tega imajo skupno navidezno omrežje, fizični podatki pa so shranjeni v različnih imenikih na stroju razvijalca.
Enako, vendar v številkah. Tukaj je pomembna ponovna uporaba kode.
Če smo prej govorili o ponovni uporabi kode v obliki knjižnic, potem je v tem primeru naša storitev, ki se odziva na potisna obvestila, ponovno uporabljena kot celoten strežnik. Ponuja API. In naš novi razvoj že sodeluje z njim.
Takrat smo uporabljali različico 4 NodeJS. Zdaj (leta 2017 - op. ur.) v nedavnem razvoju uporabljamo različico 7 NodeJS. V novih komponentah ni težav vključiti nove različice knjižnic.
Po potrebi lahko različico NodeJS preuredite in dvignete iz storitve potisnih obvestil.
In če lahko ohranimo združljivost API-ja, ga bo mogoče nadomestiti z drugimi projekti, ki so bili prej uporabljeni.
Kaj potrebujete, da dodate Docker? V naš repozitorij dodamo datoteko Dockerfile, ki opisuje potrebne odvisnosti. V tem primeru so komponente logično razčlenjene. To je minimalni nabor zalednega razvijalca.
Pri ustvarjanju novega projekta ustvarimo Dockerfile, opišemo želeni ekosistem (Python, Ruby, NodeJS). V docker-compose opisuje potrebno odvisnost - bazo podatkov. Opišemo, da potrebujemo bazo podatkov takšne in drugačne različice, shranimo podatke tam in tam.
Z nginxom uporabljamo ločen tretji vsebnik za streženje statike. Možno je naložiti slike. Backend jih postavi v vnaprej pripravljen volumen, ki je tudi montiran v kontejner z nginxom, ki daje statiko.
Za shranjevanje konfiguracije nginx, mysql smo dodali mapo Docker, v kateri hranimo potrebne konfiguracije. Ko razvijalec naredi git klon repozitorija na svojem računalniku, ima že pripravljen projekt za lokalni razvoj. Nobenega vprašanja ni, katera vrata ali nastavitve uporabiti.
Nato imamo več komponent: skrbnik, inform-API, potisna obvestila.
Da bi vse to začeli, smo ustvarili drugo skladišče, ki smo ga poimenovali dockerized-app. Trenutno uporabljamo več repozitorijev pred vsako komponento. Samo logično se razlikujeta - v GitLabu je videti kot mapa, na razvijalčevem računalniku pa kot mapa za določen projekt. Eno raven nižje so komponente, ki bodo združene.
To je samo primer vsebine dockerized-app. Sem prinesemo tudi imenik Docker, v katerega izpolnimo konfiguracije, potrebne za interakcijo vseh komponent. Obstaja README.md, ki na kratko opisuje, kako zagnati projekt.
Tukaj smo uporabili dve datoteki docker-compose. To se naredi zato, da lahko tečete v korakih. Ko razvijalec dela z jedrom, ne potrebuje potisnih obvestil, preprosto zažene datoteko docker-compose in s tem se vir shrani.
Če obstaja potreba po integraciji s potisnimi obvestili, se zaženeta docker-compose.yaml in docker-compose-push.yaml.
Ker sta docker-compose.yaml in docker-compose-push.yaml v mapi, se samodejno ustvari eno navidezno omrežje.
Opis komponent. To je naprednejša datoteka, ki je odgovorna za zbiranje komponent. Kaj je tukaj izjemnega? Tukaj predstavljamo komponento uravnoteženja.
To je že pripravljena slika Dockerja, ki poganja nginx in aplikacijo, ki posluša vtičnico Docker. Dinamično, ko se vsebniki vklapljajo in izklapljajo, regenerira konfiguracijo nginx. Ravnanje s komponentami porazdelimo po domenskih imenih tretjega nivoja.
Za razvojno okolje uporabljamo domeno .dev - api.informer.dev. Aplikacije z domeno .dev so na voljo na lokalnem računalniku razvijalca.
Nadalje se konfiguracije prenesejo v vsak projekt in vsi projekti se zaženejo hkrati.
Grafično se izkaže, da je odjemalec naš brskalnik ali kakšno orodje, s katerim postavljamo zahteve za izravnalnik.
Uravnoteževalec imen domen določi, s katerim vsebnikom se obrnete.
Lahko je nginx, ki daje adminu JS. To je lahko nginx, ki daje API, ali statične datoteke, ki so dane nginxu v obliki nalaganja slik.
Diagram prikazuje, da so vsebniki povezani z navideznim omrežjem in skriti za posrednikom.
Na stroju razvijalca lahko dostopate do vsebnika, če poznate IP, vendar tega načeloma ne uporabljamo. Neposreden dostop praktično ni potreben.
Kateri primer pogledati, da dockerizirate svojo aplikacijo? Po mojem mnenju je dober primer uradna slika dockerja za MySQL.
Je kar zahtevno. Različic je veliko. Toda njegova funkcionalnost vam omogoča, da pokrijete številne potrebe, ki se lahko pojavijo v procesu nadaljnjega razvoja. Če porabite čas in ugotovite, kako vse skupaj deluje, potem mislim, da ne boste imeli težav pri samoizvajanju.
Hub.docker.com običajno vsebuje povezave do github.com, ki vsebuje neobdelane podatke neposredno, iz katerih lahko sami sestavite sliko.
Nadalje v tem repozitoriju je skript docker-endpoint.sh, ki je odgovoren za začetno inicializacijo in nadaljnjo obdelavo zagona aplikacije.
Tudi v tem primeru je na voljo možnost konfiguracije z uporabo spremenljivk okolja. Z definiranjem spremenljivke okolja pri zagonu posameznega vsebnika ali prek docker-compose lahko rečemo, da moramo nastaviti prazno geslo za docker za rootanje na MySQL ali kar koli že želimo.
Obstaja možnost ustvarjanja naključnega gesla. Pravimo, da potrebujemo uporabnika, moramo nastaviti geslo za uporabnika in ustvariti moramo bazo podatkov.
V naših projektih smo nekoliko poenotili Dockerfile, ki skrbi za inicializacijo. Tam smo ga prilagodili našim potrebam, tako da je le razširitev uporabniških pravic, ki jih aplikacija uporablja. To nam je omogočilo, da smo pozneje preprosto ustvarili bazo podatkov iz aplikacijske konzole. Aplikacije Ruby imajo ukaz za ustvarjanje, spreminjanje in brisanje baz podatkov.
To je primer, kako izgleda določena različica MySQL na github.com. Lahko odprete Dockerfile in vidite, kako tam poteka namestitev.
docker-endpoint.sh je skript, odgovoren za vstopno točko. Med začetno inicializacijo je potrebnih nekaj pripravljalnih korakov in vsa ta dejanja se izvedejo samo v inicializacijskem skriptu.
Preidimo na drugi del.
Za shranjevanje izvornih kod smo preklopili na gitlab. To je precej zmogljiv sistem, ki ima vizualni vmesnik.
Ena od komponent Gitlaba je Gitlab CI. Omogoča vam, da opišete zaporedje ukazov, ki bodo kasneje uporabljeni za organizacijo sistema za dostavo kode ali izvajanje samodejnega testiranja.
Gitlab CI 2 pogovor - poročilo kluba Ruby Russia - precej podrobno in morda vas bo zanimalo.
Zdaj bomo pogledali, kaj je potrebno za aktiviranje Gitlab CI. Da bi zagnali Gitlab CI, moramo samo postaviti datoteko .gitlab-ci.yml v koren projekta.
Tukaj opisujemo, da želimo izvesti zaporedje stanj, kot je preizkus, uvedba.
Izvajamo skripte, ki neposredno kličejo docker-compose za izdelavo naše aplikacije. To je samo primer ozadja.
Nato rečemo, da je treba izvesti migracije, da spremenimo bazo podatkov in izvedemo teste.
Če se skripti izvedejo pravilno in ne vrnejo kode napake, sistem nadaljuje z drugo stopnjo uvajanja.
Stopnja uvajanja je trenutno implementirana za uprizarjanje. Nismo organizirali ponovnega zagona brez izpadov.
Vse posode prisilno pogasimo, nato pa ponovno dvignemo vse posode, zbrane v prvi fazi med testiranjem.
Za trenutno spremenljivko okolja izvajamo selitve baze podatkov, ki so jih napisali razvijalci.
Obstaja opomba, da to velja samo za glavno vejo.
Pri spreminjanju drugih vej se ne izvede.
Možno je organizirati uvajanja po podružnicah.
Za nadaljnje organiziranje moramo namestiti Gitlab Runner.
Ta pripomoček je napisan v jeziku Golang. To je ena datoteka, kot je običajno v svetu Golang, ki ne zahteva nobenih odvisnosti.
Ob zagonu registriramo Gitlab Runner.
Ključ dobimo v spletnem vmesniku Gitlab.
Nato v ukazni vrstici pokličemo ukaz za inicializacijo.
Nastavite Gitlab Runner interaktivno (Shell, Docker, VirtualBox, SSH)
Koda v programu Gitlab Runner se bo izvršila ob vsaki objavi, odvisno od nastavitve .gitlab-ci.yml.
Kako je vizualno videti v Gitlabu v spletnem vmesniku. Ko povežemo GItlab CI, imamo zastavico, ki prikazuje trenutno stanje gradnje.
Vidimo, da je bila pred 4 minutami narejena potrditev, ki je prestala vse teste in ni povzročila nobenih težav.
Zgradbe si lahko ogledamo pobližje. Tukaj vidimo, da sta dve državi že prešli. Stanje testiranja in stanje uvajanja pri uprizarjanju.
Če kliknemo na določeno zgradbo, bo prikazan izhod ukazov, ki so bili izvedeni v procesu v skladu z .gitlab-ci.yml.
Tako je videti naša zgodovina izdelkov. Vidimo, da so bili uspešni poskusi. Ko so oddani testi, se ne nadaljuje na naslednji korak in uprizoritvena koda se ne posodobi.
Katere naloge smo reševali na stopnji, ko smo implementirali docker? Naš sistem je sestavljen iz komponent in morali smo znova zagnati le del komponent, ki so bile posodobljene v repozitoriju, in ne celotnega sistema.
Da bi to naredili, smo morali vse razbiti v ločene mape.
Ko smo to naredili, smo imeli težavo z dejstvom, da Docker-compose ustvari svoj omrežni prostor za vsakega očka in ne vidi sosedovih komponent.
Da bi se premikali, smo ročno ustvarili omrežje v Dockerju. V Docker-compose je pisalo, da za ta projekt uporabljate takšno omrežje.
Tako vsaka komponenta, ki se začne s to mrežo, vidi komponente v drugih delih sistema.
Naslednja težava je razdelitev uprizarjanja na več projektov.
Ker da bi vse to izgledalo lepo in čim bližje produkciji, je dobro uporabiti vrata 80 ali 443, ki se uporabljajo povsod v WEB-u.
Kako smo to rešili? Vsem večjim projektom smo dodelili en Gitlab Runner.
Gitlab vam omogoča zagon več distribuiranih Gitlab Runners, ki bodo preprosto prevzeli vse naloge po vrsti na kaotičen način in jih izvajali.
Da nimamo hiše, smo skupino naših projektov omejili na en Gitlab Runner, ki se brez težav spopada z našimi volumni.
Nginx-proxy smo premaknili v ločen zagonski skript in dodali mreže za vse projekte v njem.
Naš projekt ima eno mrežo, balanser pa več mrež po imenih projektov. Nadalje lahko posreduje prek imen domen.
Naše zahteve prihajajo prek domene na vratih 80 in se razrešijo v skupino vsebnikov, ki služi tej domeni.
Katere druge težave so bile? To je tisto, kar vsi vsebniki privzeto izvajajo kot root. To je root, ki ni enak korenskemu gostitelju sistema.
Če pa vnesete vsebnik, bo ta root in datoteka, ki jo ustvarimo v tem vsebniku, postane root.
Če je razvijalec vstopil v vsebnik in tam naredil nekaj ukazov, ki generirajo datoteke, nato pa zapustil vsebnik, potem ima v svojem delovnem imeniku datoteko, do katere nima dostopa.
Kako se lahko reši? Dodate lahko uporabnike, ki bodo v vsebniku.
Kakšne težave so se pojavile, ko smo dodali uporabnika?
Pri ustvarjanju uporabnika pogosto nimamo istega ID-ja skupine (UID) in ID-ja uporabnika (GID).
Za rešitev tega problema v vsebniku uporabljamo uporabnike z ID 1000.
V našem primeru je to sovpadlo z dejstvom, da skoraj vsi razvijalci uporabljajo OS Ubuntu. V Ubuntuju ima prvi uporabnik ID 1000.
Ali imamo načrte?
Preberite dokumentacijo Dockerja. Projekt se aktivno razvija, dokumentacija se spreminja. Podatki, ki so bili prejeti pred dvema, tremi meseci, že počasi zastarajo.
Nekateri problemi, ki smo jih rešili, so zelo verjetno že rešeni s standardnimi sredstvi.
Zato želim iti dlje, da grem neposredno k orkestraciji.
Eden od primerov je Dockerjev vgrajeni mehanizem, imenovan Docker Swarm, ki prihaja takoj iz škatle. Želim zagnati nekaj v proizvodnji, ki temelji na tehnologiji Docker Swarm.
Zabojniki za drstenje otežujejo delo z hlodi. Zdaj so hlodi izolirani. Razpršeni so po posodah. Ena od nalog je omogočiti udoben dostop do dnevnikov prek spletnega vmesnika.
Vir: www.habr.com