Predlažem da pročitate transkript izvješća Alexandera Sigacheva iz Inventosa "Proces razvoja i testiranja s Docker + Gitlab CI"
Oni koji tek počinju implementirati proces razvoja i testiranja temeljen na Docker + Gitlab CI često postavljaju osnovna pitanja. Gdje početi? Kako organizirati? Kako testirati?
Ovo je izvješće dobro jer na strukturiran način govori o procesu razvoja i testiranja pomoću Dockera i Gitlaba CI. Samo izvješće je iz 2017. godine. Mislim da iz ovog izvješća možete naučiti osnove, metodologiju, ideju, iskustvo korištenja.
Koga briga neka pod mačku.
Moje ime je Alexander Sigachev. Radim za Inventos. Ispričat ću vam svoje iskustvo korištenja Dockera i kako ga postupno implementiramo na projekte u tvrtki.
Tema prezentacije: Proces razvoja pomoću Dockera i Gitlab CI.
Ovo je moj drugi govor o Dockeru. U vrijeme prvog izvješća koristili smo samo Docker u razvoju na strojevima za razvojne programere. Broj zaposlenika koji su koristili Docker bio je oko 2-3 osobe. Postupno se stjecalo iskustvo i krenulo se malo dalje. Link na naš .
Što će biti u ovom izvješću? Podijelit ćemo svoje iskustvo o tome koje smo grablje prikupili, koje probleme smo riješili. Nije svugdje bilo lijepo, ali se moglo ići dalje.
Naš moto je: pričvrstiti sve što nam padne pod ruku.
Koje probleme rješavamo?
Kada postoji nekoliko timova u tvrtki, programer je zajednički resurs. Postoje faze kada se programer izvuče iz jednog projekta i da na neko vrijeme drugom projektu.
Kako bi programer to brzo razumio, potrebno je preuzeti izvorni kod projekta i pokrenuti okruženje što je prije moguće, što će mu omogućiti daljnje rješavanje problematike ovog projekta.
Obično, ako krenete od nule, tada je malo dokumentacije u projektu. Informacije o postavljanju dostupne su samo oldtajmerima. Zaposlenici sami postavljaju svoje radno mjesto u roku od jednog ili dva dana. Da bismo ovo ubrzali, koristili smo Docker.
Sljedeći razlog je standardizacija postavki u Razvoju. Po mom iskustvu, programeri uvijek preuzimaju inicijativu. U svakom petom slučaju upisuje se prilagođena domena, na primjer, vasya.dev. Pokraj njega sjedi njegov susjed Petya, čija je domena petya.dev. Oni razvijaju web stranicu ili neku komponentu sustava koristeći ovaj naziv domene.
Kada sustav raste i ti nazivi domena počnu ulaziti u konfiguracije, dolazi do sukoba razvojnog okruženja i putanja stranice se prepisuje.
Isto se događa s postavkama baze podataka. Netko se ne zamara sigurnošću i radi s praznom root lozinkom. U fazi instalacije, MySQL je od nekoga tražio lozinku i ispostavilo se da je lozinka 123. Često se događa da se konfiguracija baze podataka stalno mijenja ovisno o obvezama programera. Netko je ispravio, netko nije ispravio konfiguraciju. Bilo je trikova kada smo izvadili neku vrstu testne konfiguracije .gitignore a svaki je programer morao instalirati bazu podataka. To je otežavalo početak. Potrebno je, između ostalog, zapamtiti i bazu podataka. Baza mora biti inicijalizirana, mora se unijeti lozinka, mora se registrirati korisnik, mora se napraviti tablica i tako dalje.
Drugi problem su različite verzije biblioteka. Često se događa da programer radi s različitim projektima. Postoji projekt Legacy koji je krenuo prije pet godina (od 2017. - nap. ur.). U vrijeme lansiranja, počeli smo s MySQL 5.5. Postoje i moderniji projekti u kojima pokušavamo implementirati modernije verzije MySQL-a, na primjer, 5.7 ili starije (2017. - nap. ur.)
Svatko tko radi s MySQL zna da te biblioteke sa sobom donose ovisnosti. Prilično je problematično voditi 2 baze zajedno. Barem je stare klijente problematično povezati s novom bazom podataka. To zauzvrat stvara nekoliko problema.
Sljedeći problem je kada programer radi na lokalnom računalu, on koristi lokalne resurse, lokalne datoteke, lokalni RAM. Sva interakcija u trenutku razvoja rješenja problema odvija se u okviru činjenice da radi na jednom stroju. Primjer je kada imamo pozadinske poslužitelje u Production 3, a programer sprema datoteke u korijenski direktorij i odatle nginx uzima datoteke da odgovori na zahtjev. Kada takav kod uđe u Production, ispada da je datoteka prisutna na jednom od 3 poslužitelja.
Sada se razvija smjer mikroservisa. Kada naše velike aplikacije podijelimo na neke male komponente koje međusobno djeluju. To vam omogućuje odabir tehnologija za određeni niz zadataka. Također vam omogućuje dijeljenje posla i odgovornosti između programera.
Frondend-developer, koji razvija na JS-u, nema gotovo nikakav utjecaj na Backend. Pozadinski programer, zauzvrat, razvija, u našem slučaju, Ruby on Rails i ne ometa Frondend. Interakcija se izvodi pomoću API-ja.
Kao bonus, uz pomoć Dockera, uspjeli smo reciklirati resurse na Stagingu. Svaki projekt je zbog svoje specifičnosti zahtijevao određena podešavanja. Fizički je bilo potrebno dodijeliti ili virtualni poslužitelj i zasebno ih konfigurirati ili dijeliti neku vrstu varijabilnog okruženja i projekti su mogli, ovisno o verziji knjižnica, utjecati jedni na druge.
Alati. Što koristimo?
- Sam Docker. Dockerfile opisuje ovisnosti jedne aplikacije.
- Docker-compose je paket koji okuplja nekoliko naših Docker aplikacija.
- Koristimo GitLab za pohranu izvornog koda.
- Za integraciju sustava koristimo GitLab-CI.
Izvještaj se sastoji od dva dijela.
Prvi dio će govoriti o tome kako je Docker pokrenut na strojevima programera.
Drugi dio će govoriti o tome kako komunicirati s GitLabom, kako izvodimo testove i kako se uvodimo u Staging.
Docker je tehnologija koja omogućuje (koristeći deklarativni pristup) opisivanje potrebnih komponenti. Ovo je primjer Docker datoteke. Ovdje izjavljujemo da nasljeđujemo službeni Ruby:2.3.0 Docker image. Sadrži instaliranu verziju Ruby 2.3. Instaliramo potrebne biblioteke za izgradnju i NodeJS. Opisujemo da stvaramo imenik /app. Postavite direktorij aplikacije kao radni direktorij. U ovaj direktorij postavljamo potrebni minimalni Gemfile i Gemfile.lock. Zatim gradimo projekte koji instaliraju ovu sliku ovisnosti. Naznačujemo da će spremnik biti spreman za slušanje na vanjskom portu 3000. Zadnja naredba je naredba koja izravno pokreće našu aplikaciju. Ako izvršimo naredbu za pokretanje projekta, aplikacija će se pokušati pokrenuti i pokrenuti navedenu naredbu.
Ovo je minimalan primjer docker-compose datoteke. U ovom slučaju pokazujemo da postoji veza između dva spremnika. Ovo je izravno u uslugu baze podataka i web uslugu. Naše web aplikacije u većini slučajeva zahtijevaju neku vrstu baze podataka kao backend za pohranu podataka. Budući da koristimo MySQL, primjer je s MySQL - ali ništa nas ne sprječava da koristimo i neku drugu bazu podataka (PostgreSQL, Redis).
Iz službenog izvora iz Docker huba preuzimamo sliku MySQL 5.7.14 bez promjena. Prikupljamo sliku koja je odgovorna za našu web aplikaciju iz trenutnog imenika. Prikuplja sliku za nas tijekom prvog pokretanja. Zatim pokreće naredbu koju ovdje izvršavamo. Ako se vratimo, vidjet ćemo da je definirana naredba za pokretanje putem Pume. Puma je usluga napisana u Rubyju. U drugom slučaju poništavamo. Ova naredba može biti proizvoljna ovisno o našim potrebama ili zadacima.
Također opisujemo da moramo proslijediti port na našem glavnom računalu razvojnog programera s 3000 na 3000 na portu spremnika. To se radi automatski koristeći iptables i njegov mehanizam, koji je izravno ugrađen u Docker.
Programer također može, kao i prije, pristupiti bilo kojoj dostupnoj IP adresi, na primjer, 127.0.0.1 je lokalna ili vanjska IP adresa stroja.
Zadnji redak kaže da web spremnik ovisi o db spremniku. Kada pozovemo početak web spremnika, docker-compose će prvo pokrenuti bazu podataka za nas. Već pri pokretanju baze podataka (zapravo, nakon pokretanja spremnika! To ne jamči spremnost baze podataka) pokrenut će se aplikacija, naš backend.
Time se izbjegavaju pogreške kada se baza podataka ne pokrene i štede resursi kada zaustavimo spremnik baze podataka, čime se oslobađaju resursi za druge projekte.
Što nam daje korištenje dokerizacije baze podataka na projektu. Popravljamo verziju MySQL-a za sve programere. Time se izbjegavaju neke pogreške koje se mogu pojaviti kada se verzije razlikuju, kada se promijeni sintaksa, konfiguracija, zadane postavke. To vam omogućuje da odredite zajednički naziv hosta za bazu podataka, prijavu, lozinku. Udaljavamo se od zoološkog vrta imena i sukoba u konfiguracijskim datotekama koje smo imali ranije.
Imamo priliku koristiti optimalniju konfiguraciju za razvojno okruženje, koja će se razlikovati od zadane. MySQL je prema zadanim postavkama konfiguriran za slabe strojeve i njegova izvedba izvan kutije je vrlo loša.
Docker omogućuje korištenje Python, Ruby, NodeJS, PHP interpretera željene verzije. Oslobađamo se potrebe za korištenjem neke vrste upravitelja verzija. Prethodno je Ruby koristio rpm paket koji vam je omogućavao promjenu verzije ovisno o projektu. Također omogućuje, zahvaljujući Docker spremniku, glatku migraciju koda i njegovu verziju zajedno sa ovisnostima. Nemamo problema s razumijevanjem verzije tumača i koda. Za ažuriranje verzije, spustite stari spremnik i podignite novi spremnik. Ako je nešto pošlo po zlu, možemo spustiti novi kontejner, podignuti stari kontejner.
Nakon izgradnje slike, spremnici u razvoju i proizvodnji bit će isti. To posebno vrijedi za velike instalacije.
Na Frontendu koristimo JavaScipt i NodeJS.
Sada imamo zadnji projekt na ReacJS. Programer je pokrenuo sve u spremniku i razvio koristeći vruće ponovno učitavanje.
Zatim se pokreće zadatak sklapanja JavaScipta, a kod kompajliran u statiku daje se putem nginx resursa za spremanje.
Ovdje sam dao shemu našeg posljednjeg projekta.
Koji su zadaci riješeni? Imali smo potrebu izgraditi sustav s kojim mobilni uređaji komuniciraju. Oni primaju podatke. Jedna od mogućnosti je slanje push obavijesti na ovaj uređaj.
Što smo učinili za ovo?
U aplikaciju smo podijelili komponente kao što su: administrativni dio na JS-u, backend, koji radi preko REST sučelja pod Ruby on Rails. Pozadina je u interakciji s bazom podataka. Rezultat koji se generira daje se klijentu. Administratorska ploča komunicira s pozadinom i bazom podataka putem REST sučelja.
Također smo imali potrebu slati push obavijesti. Prije toga smo imali projekt koji je implementirao mehanizam koji je zadužen za dostavu obavijesti mobilnim platformama.
Razvili smo sljedeću shemu: operater iz preglednika komunicira s administrativnom pločom, administrativna ploča komunicira s pozadinom, zadatak je slanje Push obavijesti.
Push obavijesti komuniciraju s drugom komponentom koja je implementirana u NodeJS.
Izgrađuju se redovi čekanja i zatim se šalju obavijesti prema njihovom mehanizmu.
Ovdje su nacrtane dvije baze podataka. Trenutno uz pomoć Dockera koristimo 2 nezavisne baze podataka koje međusobno nisu ni na koji način povezane. Osim toga, imaju zajedničku virtualnu mrežu, a fizički podaci pohranjuju se u različite direktorije na stroju programera.
Isto ali u brojkama. Ovdje je važna ponovna upotreba koda.
Ako smo ranije govorili o ponovnoj upotrebi koda u obliku biblioteka, onda se u ovom primjeru naša usluga koja odgovara na Push obavijesti ponovno koristi kao potpuni poslužitelj. Pruža API. A naš novi razvoj već je u interakciji s njim.
U to vrijeme koristili smo verziju 4 NodeJS-a. Sada (u 2017. - napomena ur.) u novijim razvojima koristimo verziju 7 NodeJS-a. Nema problema u novim komponentama uključiti nove verzije biblioteka.
Ako je potrebno, možete refaktorirati i podići verziju NodeJS iz usluge Push obavijesti.
A ako možemo održati kompatibilnost API-ja, tada će ga biti moguće zamijeniti drugim projektima koji su se prethodno koristili.
Što vam je potrebno za dodavanje Dockera? U naše spremište dodajemo Dockerfile koji opisuje potrebne ovisnosti. U ovom primjeru, komponente su raščlanjene logično. Ovo je minimalni skup pozadinskog programera.
Prilikom izrade novog projekta kreiramo Dockerfile, opisujemo željeni ekosustav (Python, Ruby, NodeJS). U docker-compose opisuje potrebnu ovisnost - bazu podataka. Opisujemo da trebamo bazu podataka takve i takve verzije, pohranjujemo podatke tamo i tamo.
Koristimo zaseban treći spremnik s nginxom za posluživanje statike. Moguće je uploadati slike. Backend ih stavlja u unaprijed pripremljeni volumen, koji je također montiran u kontejner s nginxom, koji daje statiku.
Za pohranjivanje nginx, mysql konfiguracije dodali smo mapu Docker u koju spremamo potrebne konfiguracije. Kada programer napravi git klon repozitorija na svom stroju, on već ima projekt spreman za lokalni razvoj. Nema pitanja koji priključak ili koje postavke primijeniti.
Dalje, imamo nekoliko komponenti: admin, inform-API, push obavijesti.
Kako bismo pokrenuli sve ovo, napravili smo još jedan repozitorij, koji smo nazvali dockerized-app. Trenutno koristimo nekoliko repozitorija prije svake komponente. Oni se samo logički razlikuju - u GitLabu to izgleda kao mapa, ali na stroju programera kao mapa za određeni projekt. Jednu razinu niže su komponente koje će se kombinirati.
Ovo je samo primjer sadržaja dockerized-app. Ovdje donosimo i Docker direktorij u kojem ispunjavamo konfiguracije potrebne za interakcije svih komponenti. Postoji README.md koji ukratko opisuje kako pokrenuti projekt.
Ovdje smo primijenili dvije docker-compose datoteke. To se radi kako bi se moglo trčati u koracima. Kada programer radi s jezgrom, ne trebaju mu push obavijesti, on jednostavno pokreće docker-compose datoteku i, sukladno tome, resurs se sprema.
Ako postoji potreba za integracijom s push obavijestima, tada se pokreću docker-compose.yaml i docker-compose-push.yaml.
Budući da su docker-compose.yaml i docker-compose-push.yaml u mapi, automatski se stvara jedna virtualna mreža.
Opis komponenti. Ovo je naprednija datoteka koja je odgovorna za prikupljanje komponenti. Što je ovdje izvanredno? Ovdje predstavljamo komponentu balansera.
Ovo je gotova Docker slika koja pokreće nginx i aplikaciju koja sluša na Docker socketu. Dinamički, kako se spremnici uključuju i isključuju, on regenerira nginx konfiguraciju. Distribuiramo rukovanje komponentama po nazivima domena treće razine.
Za razvojno okruženje koristimo .dev domenu - api.informer.dev. Aplikacije s domenom .dev dostupne su na lokalnom računalu razvojnog programera.
Nadalje, konfiguracije se prenose u svaki projekt i svi se projekti pokreću zajedno u isto vrijeme.
Grafički ispada da je klijent naš preglednik ili neki alat pomoću kojeg postavljamo zahtjeve balanseru.
Balanser imena domene određuje koji spremnik treba kontaktirati.
To može biti nginx, koji daje administratoru JS. To može biti nginx, koji daje API, ili statičke datoteke, koje se daju nginxu u obliku učitavanja slika.
Dijagram pokazuje da su spremnici povezani virtualnom mrežom i skriveni iza proxyja.
Na stroju razvojnog programera možete pristupiti spremniku znajući IP, ali mi to u načelu ne koristimo. Praktički nema potrebe za izravnim pristupom.
Koji primjer pogledati da biste dockerizirali svoju aplikaciju? Po mom mišljenju, dobar primjer je službena docker slika za MySQL.
Prilično je izazovno. Postoji mnogo verzija. Ali njegova funkcionalnost omogućuje pokrivanje mnogih potreba koje se mogu pojaviti u procesu daljnjeg razvoja. Ako potrošite vrijeme i shvatite kako sve to djeluje, onda mislim da nećete imati problema u samostalnoj implementaciji.
Hub.docker.com obično sadrži veze na github.com, koji sadrži neobrađene podatke izravno iz kojih možete sami izgraditi sliku.
Dalje u ovom repozitoriju nalazi se skripta docker-endpoint.sh, koja je odgovorna za početnu inicijalizaciju i za daljnju obradu pokretanja aplikacije.
Također u ovom primjeru postoji mogućnost konfiguriranja pomoću varijabli okruženja. Definiranjem varijable okruženja prilikom pokretanja jednog spremnika ili kroz docker-compose, možemo reći da moramo postaviti praznu lozinku za docker za rootanje na MySQL-u ili što god želimo.
Postoji mogućnost stvaranja nasumične lozinke. Kažemo da trebamo korisnika, moramo postaviti lozinku za korisnika i moramo napraviti bazu podataka.
U našim projektima malo smo unificirali Dockerfile koji je odgovoran za inicijalizaciju. Tu smo to ispravili prema našim potrebama da bude samo proširenje korisničkih prava koje aplikacija koristi. To nam je omogućilo da kasnije jednostavno stvorimo bazu podataka iz aplikacijske konzole. Ruby aplikacije imaju naredbu za stvaranje, modificiranje i brisanje baza podataka.
Ovo je primjer kako izgleda određena verzija MySQL-a na github.com. Možete otvoriti Dockerfile i tamo vidjeti kako se odvija instalacija.
docker-endpoint.sh je skripta odgovorna za ulaznu točku. Tijekom početne inicijalizacije potrebni su neki pripremni koraci, a sve te radnje se izvode samo u inicijalizacijskoj skripti.
Prijeđimo na drugi dio.
Kako bismo pohranili izvorne kodove, prebacili smo se na gitlab. Ovo je prilično moćan sustav koji ima vizualno sučelje.
Jedna od komponenti Gitlaba je Gitlab CI. Omogućuje vam da opišete niz naredbi koje će se kasnije koristiti za organiziranje sustava isporuke koda ili pokretanje automatskog testiranja.
Gitlab CI 2 razgovor - izvješće kluba Ruby Russia - dosta detaljno i možda će vas zainteresirati.
Sada ćemo pogledati što je potrebno za aktivaciju Gitlab CI. Kako bismo pokrenuli Gitlab CI, samo trebamo staviti .gitlab-ci.yml datoteku u root projekta.
Ovdje opisujemo da želimo izvršiti niz stanja poput testa, implementacije.
Izvršavamo skripte koje izravno pozivaju docker-compose za izradu naše aplikacije. Ovo je samo primjer pozadine.
Dalje, kažemo da je potrebno pokrenuti migracije za promjenu baze podataka i pokretanje testova.
Ako se skripte izvode ispravno i ne vraćaju kod pogreške, tada, u skladu s tim, sustav prelazi na drugu fazu implementacije.
Faza implementacije trenutno je implementirana za prikazivanje. Nismo organizirali ponovno pokretanje bez zastoja.
Prisilno gasimo sve spremnike, a zatim ponovno podižemo sve spremnike prikupljene u prvoj fazi testiranja.
Za trenutnu varijablu okruženja izvodimo migracije baze podataka koje su napisali programeri.
Postoji napomena da se ovo odnosi samo na glavnu granu.
Ne izvršava se promjena drugih grana.
Moguće je organizirati rolloute po granama.
Da bismo ovo dodatno organizirali, moramo instalirati Gitlab Runner.
Ovaj uslužni program napisan je na golang jeziku. To je jedna datoteka, kao što je uobičajeno u Golang svijetu, koja ne zahtijeva nikakve ovisnosti.
Prilikom pokretanja registriramo Gitlab Runner.
Ključ dobivamo u Gitlab web sučelju.
Zatim pozivamo naredbu za inicijalizaciju na naredbenom retku.
Postavite Gitlab Runner interaktivno (Shell, Docker, VirtualBox, SSH)
Kod na Gitlab Runneru izvršit će se pri svakom urezivanju, ovisno o postavci .gitlab-ci.yml.
Kako to vizualno izgleda u Gitlabu u web sučelju. Nakon što smo povezali GItlab CI, imamo zastavicu koja pokazuje stanje build-a u trenutnom trenutku.
Vidimo da je commit napravljen prije 4 minute, koji je prošao sve testove i nije uzrokovao nikakve probleme.
Možemo pobliže pogledati građevine. Ovdje vidimo da su već prošla dva stanja. Status testiranja i status implementacije na pozornici.
Ako kliknemo na određenu verziju, pojavit će se konzolni izlaz naredbi koje su pokrenute u procesu prema .gitlab-ci.yml.
Ovako izgleda naša povijest proizvoda. Vidimo da je bilo uspješnih pokušaja. Kada se testovi dostave, ne nastavlja se na sljedeći korak i kod za provođenje se ne ažurira.
Koje smo zadatke rješavali na pozornici kada smo implementirali docker? Naš sustav se sastoji od komponenti i imali smo potrebu restartovati samo dio komponenti koje su ažurirane u repozitoriju, a ne cijeli sustav.
Da bismo to učinili, morali smo sve razbiti u zasebne mape.
Nakon što smo to napravili, imali smo problem s činjenicom da Docker-compose stvara vlastiti mrežni prostor za svakog tatu i ne vidi susjedove komponente.
Kako bismo se snašli, ručno smo izradili mrežu u Dockeru. U Docker-composeu je pisalo da koristite takvu mrežu za ovaj projekt.
Dakle, svaka komponenta koja počinje ovom mrežom vidi komponente u drugim dijelovima sustava.
Sljedeći problem je podjela inscenacije na više projekata.
Pošto da bi sve ovo izgledalo lijepo i što bliže produkciji, dobro je koristiti port 80 ili 443 koji se koristi svugdje u WEB-u.
Kako smo to riješili? Dodijelili smo jedan Gitlab Runner svim većim projektima.
Gitlab vam omogućuje pokretanje nekoliko distribuiranih Gitlab Runner-a, koji će jednostavno preuzeti sve zadatke redom na kaotičan način i pokrenuti ih.
Kako ne bismo imali kuću, ograničili smo grupu naših projekata na jedan Gitlab Runner, koji se bez problema nosi s našim volumenima.
Premjestili smo nginx-proxy u zasebnu skriptu za pokretanje i dodali rešetke za sve projekte u njoj.
Naš projekt ima jednu rešetku, a balanser ima nekoliko mreža po nazivima projekata. Može proxy dalje po imenima domena.
Naši zahtjevi dolaze kroz domenu na priključku 80 i rješavaju se u grupu spremnika koja opslužuje ovu domenu.
Kojih je još problema bilo? To je ono što svi spremnici po zadanom pokreću kao root. Ovo je root različit od root hosta sustava.
Međutim, ako uđete u spremnik, bit će root i datoteka koju napravimo u tom spremniku dobiva root prava.
Ako je programer ušao u spremnik i tamo napravio neke naredbe koje generiraju datoteke, a zatim napustio spremnik, tada ima datoteku u svom radnom direktoriju kojoj nema pristup.
Kako se to može riješiti? Možete dodati korisnike koji će biti u spremniku.
Koji su problemi nastali kada smo dodali korisnika?
Prilikom kreiranja korisnika često nemamo isti ID grupe (UID) i ID korisnika (GID).
Za rješavanje ovog problema u kontejneru koristimo korisnike s ID 1000.
U našem slučaju to se poklopilo s činjenicom da gotovo svi programeri koriste Ubuntu OS. A na Ubuntuu, prvi korisnik ima ID 1000.
Imamo li planove?
Pročitajte dokumentaciju Dockera. Projekt se aktivno razvija, dokumentacija se mijenja. Podaci koji su pristigli prije dva-tri mjeseca već polako zastarijevaju.
Neki od problema koje smo riješili vrlo su vjerojatno već riješeni standardnim sredstvima.
Stoga želim ići dalje i prijeći izravno na orkestraciju.
Jedan od primjera je Dockerov ugrađeni mehanizam nazvan Docker Swarm, koji se isporučuje odmah nakon isporuke. Želim pokrenuti nešto u proizvodnji temeljeno na tehnologiji Docker Swarm.
Spremnici za mrijest čine neugodnim rad s trupcima. Sada su trupci izolirani. Razbacani su po kontejnerima. Jedan od zadataka je omogućiti jednostavan pristup zapisnicima putem web sučelja.
Izvor: www.habr.com