Predlažem da pročitate transkript izveštaja Aleksandra Sigačeva iz Inventosa "Proces razvoja i testiranja sa Docker + Gitlab CI"
Oni koji tek počinju da implementiraju proces razvoja i testiranja zasnovanog na Docker + Gitlab CI često postavljaju osnovna pitanja. Gdje početi? Kako organizirati? Kako testirati?
Ovaj izvještaj je dobar jer na strukturiran način govori o procesu razvoja i testiranja koristeći Docker i Gitlab CI. Sam izvještaj je iz 2017. Mislim da iz ovog izvještaja možete naučiti osnove, metodologiju, ideju, iskustvo korištenja.
Koga briga, molim pod mačku.
Moje ime je Aleksandar Sigačev. Radim za Inventos. Reći ću vam o svom iskustvu korištenja Dockera i kako ga postepeno implementiramo na projekte u kompaniji.
Tema prezentacije: Razvojni proces koristeći Docker i Gitlab CI.
Ovo je moj drugi razgovor o Dockeru. U vrijeme prvog izvještaja koristili smo samo Docker u razvoju na mašinama za programere. Broj zaposlenih koji su koristili Docker je bio oko 2-3 osobe. Postepeno se sticalo iskustvo i krenuli smo malo dalje. Link na naše .
Šta će biti u ovom izvještaju? Podijelit ćemo svoja iskustva o tome koje smo grablje prikupili, koje smo probleme riješili. Nije svuda bilo lepo, ali je bilo dozvoljeno da se krene dalje.
Naš moto je: pričvrstite sve što nam dođe pod ruku.
Koje probleme rješavamo?
Kada u kompaniji postoji nekoliko timova, programer je zajednički resurs. Postoje faze kada se programer izvlači iz jednog projekta i daje neko vrijeme drugom projektu.
Da bi programer brzo shvatio, potrebno je da preuzme izvorni kod projekta i što prije pokrene okruženje, što će mu omogućiti dalje rješavanje problema ovog projekta.
Obično, ako krenete od nule, onda u projektu ima malo dokumentacije. Informacije o načinu postavljanja dostupne su samo oldtajmerima. Zaposleni sami postavljaju svoje radno mjesto za jedan ili dva dana. Da bismo ovo ubrzali, koristili smo Docker.
Sljedeći razlog je standardizacija postavki u Razvoju. Prema mom iskustvu, programeri uvijek preuzimaju inicijativu. U svakom petom slučaju upisuje se prilagođena domena, na primjer vasya.dev. Pored njega sjedi njegova susjeda Petya, čiji je domen petya.dev. Oni razvijaju web stranicu ili neku komponentu sistema koristeći ovo ime domene.
Kada sistem raste i ovi nazivi domena počnu da ulaze u konfiguracije, tada nastaje konflikt razvojnog okruženja i putanja sajta se prepisuje.
Isto se dešava i sa postavkama baze podataka. Neko se ne zamara sa sigurnošću i radi sa praznom root lozinkom. U fazi instalacije, MySQL je od nekoga tražio lozinku i ispostavilo se da je lozinka 123. Često se dešava da se konfiguracija baze podataka stalno mijenja u zavisnosti od urezivanja programera. Neko je ispravio, neko nije ispravio konfiguraciju. Bilo je trikova kada smo izvadili nekakvu testnu konfiguraciju .gitignore i svaki programer je morao da instalira bazu podataka. To je otežalo početak. Potrebno je, između ostalog, zapamtiti i bazu podataka. Baza podataka mora biti inicijalizirana, mora se unijeti lozinka, mora biti registriran korisnik, mora se kreirati tabela itd.
Drugi problem su različite verzije biblioteka. Često se dešava da programer radi sa različitim projektima. Postoji projekat Legacy koji je započet prije pet godina (od 2017. - prim. red.). U trenutku lansiranja, počeli smo sa MySQL 5.5. Postoje i moderni projekti u kojima pokušavamo implementirati modernije verzije MySQL-a, na primjer, 5.7 ili starije (2017. - prim. ur.)
Svako ko radi sa MySQL zna da ove biblioteke sa sobom nose zavisnosti. Prilično je problematično voditi 2 baze zajedno. U najmanju ruku, stari klijenti su problematični za povezivanje na novu bazu podataka. To zauzvrat stvara nekoliko problema.
Sljedeći problem je kada programer radi na lokalnom stroju, on koristi lokalne resurse, lokalne datoteke, lokalnu RAM memoriju. Sva interakcija u trenutku razvijanja rješenja problema odvija se u okviru činjenice da radi na jednoj mašini. Primjer je kada imamo pozadinske servere u produkciji 3, a programer sprema datoteke u korijenski direktorij i odatle nginx preuzima datoteke da odgovori na zahtjev. Kada takav kod uđe u produkciju, ispostavlja se da je fajl prisutan na jednom od 3 servera.
Smjer mikroservisa se sada razvija. Kada naše velike aplikacije podijelimo na neke male komponente koje međusobno djeluju. Ovo vam omogućava da odaberete tehnologije za određeni skup zadataka. Takođe vam omogućava da podelite posao i odgovornosti između programera.
Frondend-developer, koji se razvija na JS-u, nema skoro nikakav uticaj na Backend. Backend 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ć Docker-a, uspjeli smo reciklirati resurse na Staging-u. Svaki projekat je, zbog svojih specifičnosti, zahtevao određena podešavanja. Fizički je bilo potrebno ili dodijeliti virtuelni server i konfigurirati ga zasebno, ili dijeliti neku vrstu varijabilnog okruženja i projekti bi, ovisno o verziji biblioteka, mogli utjecati jedni na druge.
Alati. Šta koristimo?
- Docker sam. Dockerfile opisuje zavisnosti jedne aplikacije.
- Docker-compose je paket koji objedinjuje nekoliko naših Docker aplikacija.
- Mi koristimo GitLab za pohranjivanje izvornog koda.
- Za sistemsku integraciju koristimo GitLab-CI.
Izvještaj se sastoji iz dva dijela.
Prvi dio će govoriti o tome kako je Docker pokrenut na mašinama programera.
Drugi dio će govoriti o tome kako komunicirati sa GitLabom, kako izvodimo testove i kako prelazimo na Staging.
Docker je tehnologija koja omogućava (koristeći deklarativni pristup) opisivanje potrebnih komponenti. Ovo je primjer Dockerfile-a. Ovdje izjavljujemo da smo naslijedili zvaničnu Ruby:2.3.0 Docker sliku. Sadrži instaliran Ruby verziju 2.3. Instaliramo potrebne build biblioteke i NodeJS. Opisujemo da kreiramo direktorij /app. Postavite direktorij aplikacije kao radni direktorij. U ovaj direktorij postavljamo potrebni minimalni Gemfile i Gemfile.lock. Zatim gradimo projekte koji instaliraju ovu sliku zavisnosti. Naznačavamo da će kontejner biti spreman za slušanje na vanjskom portu 3000. Posljednja komanda je komanda koja direktno pokreće našu aplikaciju. Ako izvršimo naredbu za pokretanje projekta, aplikacija će pokušati pokrenuti i pokrenuti navedenu naredbu.
Ovo je minimalni primjer datoteke docker-compose. U ovom slučaju pokazujemo da postoji veza između dva kontejnera. Ovo je direktno u servisu baze podataka i web servisu. Naše web aplikacije u većini slučajeva zahtijevaju neku vrstu baze podataka kao backend za pohranjivanje podataka. Pošto koristimo MySQL, primjer je sa MySQL - ali ništa nas ne sprječava da koristimo neku drugu bazu podataka (PostgreSQL, Redis).
Uzimamo iz zvaničnog izvora iz Docker huba sliku MySQL 5.7.14 bez promjena. Sliku koja je odgovorna za našu web aplikaciju prikupljamo iz trenutnog direktorija. Prikuplja sliku za nas prilikom prvog lansiranja. Zatim pokreće naredbu koju ovdje izvršavamo. Ako se vratimo, vidjet ćemo da je definirana komanda za lansiranje preko Pume. Puma je servis napisan u Ruby-u. U drugom slučaju, poništavamo. Ova naredba može biti proizvoljna ovisno o našim potrebama ili zadacima.
Također opisujemo da trebamo proslijediti port na našem host stroju programera sa 3000 na 3000 na portu kontejnera. Ovo se radi automatski koristeći iptables i njegov mehanizam, koji je direktno ugrađen u Docker.
Programer takođe može, kao i ranije, pristupiti bilo kojoj dostupnoj IP adresi, na primer, 127.0.0.1 je lokalna ili eksterna IP adresa mašine.
Zadnji red kaže da web kontejner ovisi o db kontejneru. Kada pozovemo početak web kontejnera, docker-compose će prvo pokrenuti bazu podataka umjesto nas. Već na početku baze podataka (u stvari, nakon pokretanja kontejnera! Ovo ne garantuje spremnost baze podataka) će pokrenuti aplikaciju, naš backend.
Ovo izbjegava greške kada baza podataka nije pokrenuta i štedi resurse kada zaustavimo kontejner baze podataka, čime se oslobađaju resursi za druge projekte.
Što nam daje korištenje dockerizacije baze podataka na projektu. Popravljamo verziju MySQL-a za sve programere. Ovo izbjegava neke greške koje se mogu pojaviti kada se verzije razlikuju, kada se sintaksa, konfiguracija, zadane postavke mijenjaju. Ovo vam omogućava da odredite zajedničko ime hosta za bazu podataka, prijavu, lozinku. Udaljavamo se od zoološkog vrta imena i sukoba u konfiguracijskim datotekama koje smo imali ranije.
Imamo priliku da koristimo optimalniju konfiguraciju za razvojno okruženje, koja će se razlikovati od zadane. MySQL je podrazumevano konfigurisan za slabe mašine i njegove performanse iz kutije su veoma loše.
Docker vam omogućava da koristite Python, Ruby, NodeJS, PHP interpreter željene verzije. Riješili smo se potrebe da koristimo neku vrstu upravitelja verzija. Ranije je Ruby koristio rpm paket koji vam je omogućavao da promijenite verziju ovisno o projektu. Takođe omogućava, zahvaljujući Docker kontejneru, nesmetanu migraciju koda i njegovu verziju zajedno sa zavisnostima. Nemamo problema s razumijevanjem verzije i tumača i koda. Da ažurirate verziju, spustite stari kontejner i podignite novi kontejner. Ako nešto pođe po zlu, možemo spustiti novi kontejner, podići stari kontejner.
Nakon izgradnje imidža, kontejneri u razvoju i proizvodnji će biti isti. Ovo se posebno odnosi na velike instalacije.
Na Frontendu koristimo JavaScipt i NodeJS.
Sada imamo posljednji projekat na ReacJS-u. Programer je pokrenuo sve u kontejneru i razvio koristeći vruće ponovno učitavanje.
Zatim se pokreće JavaScipt montažni zadatak i kod kompajliran u statiku se daje kroz nginx resurse za uštedu.
Ovdje sam dao shemu našeg posljednjeg projekta.
Koji su zadaci riješeni? Imali smo potrebu da izgradimo sistem sa kojim mobilni uređaji komuniciraju. Oni primaju podatke. Jedna od mogućnosti je slanje push obavijesti na ovaj uređaj.
Šta smo uradili za ovo?
U aplikaciju smo podijelili komponente kao što su: admin dio na JS-u, backend, koji radi preko REST interfejsa pod Ruby on Rails. Pozadina je u interakciji sa bazom podataka. Rezultat koji se generiše daje se klijentu. Administrativni panel komunicira sa pozadinom i bazom podataka preko REST interfejsa.
Također smo imali potrebu slati push obavijesti. Prije toga smo imali projekat koji je implementirao mehanizam koji je odgovoran za dostavljanje obavijesti mobilnim platformama.
Razvili smo sljedeću shemu: operater iz pretraživača komunicira sa admin panelom, admin panel je u interakciji sa pozadinom, zadatak je slanje Push obavijesti.
Push obavijesti su u interakciji s drugom komponentom koja je implementirana u NodeJS.
Redovi se grade, a zatim se šalju obavijesti prema njihovom mehanizmu.
Ovdje su nacrtane dvije baze podataka. Trenutno, uz pomoć Docker-a, koristimo 2 nezavisne baze podataka koje nisu ni na koji način povezane jedna s drugom. Osim toga, imaju zajedničku virtuelnu mrežu, a fizički podaci se pohranjuju 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 ponovo koristi kao potpuni server. 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. - prim. ur.) u novijim razvojima koristimo verziju 7 NodeJS-a. Nema problema u novim komponentama koje uključuju nove verzije biblioteka.
Ako je potrebno, možete refaktorirati i podići NodeJS verziju iz usluge Push obavijesti.
A ako možemo održati API kompatibilnost, tada će biti moguće zamijeniti ga drugim projektima koji su prethodno korišteni.
Šta vam je potrebno da dodate Docker? U naše spremište dodajemo Dockerfile, koji opisuje potrebne zavisnosti. U ovom primjeru, komponente su logično raščlanjene. Ovo je minimalni set backend programera.
Prilikom kreiranja novog projekta kreiramo Dockerfile, opisujemo željeni ekosistem (Python, Ruby, NodeJS). U docker-compose, on opisuje neophodnu zavisnost - bazu podataka. Opisujemo da nam je potrebna baza podataka te i takve verzije, pohraniti podatke tamo i tamo.
Koristimo poseban treći kontejner sa nginxom za posluživanje statike. Moguće je učitavanje slika. Backend ih stavlja u unapred pripremljenu zapreminu, koja je takođe montirana u kontejner sa nginxom, koji daje statičnost.
Da bismo pohranili nginx, mysql konfiguraciju, dodali smo Docker folder u koji pohranjujemo potrebne konfiguracije. Kada programer napravi git klon repozitorija na svojoj mašini, on već ima projekat spreman za lokalni razvoj. Nema pitanja koji port ili koja podešavanja primijeniti.
Zatim imamo nekoliko komponenti: admin, inform-API, push notifikacije.
Kako bismo sve ovo pokrenuli, kreirali smo još jedno spremište, koje smo nazvali dockerized-app. Trenutno koristimo nekoliko spremišta prije svake komponente. Oni su samo logički različiti - u GitLabu to izgleda kao folder, ali na mašini programera, folder za određeni projekat. Jedan nivo niže su komponente koje će biti kombinovane.
Ovo je primjer samo sadržaja dockerized-app. Ovdje također donosimo Docker direktorij u koji popunjavamo konfiguracije potrebne za interakciju svih komponenti. Postoji README.md koji ukratko opisuje kako pokrenuti projekat.
Ovdje smo primijenili dva docker-compose fajla. Ovo se radi kako bi se moglo trčati u koracima. Kada programer radi s jezgrom, ne trebaju mu push obavijesti, on jednostavno pokreće datoteku docker-compose i, u skladu s tim, resurs se čuva.
Ako postoji potreba za integracijom s push obavijestima, tada se pokreću docker-compose.yaml i docker-compose-push.yaml.
Pošto su docker-compose.yaml i docker-compose-push.yaml u fascikli, automatski se kreira jedna virtuelna mreža.
Opis komponenti. Ovo je napredniji fajl koji je odgovoran za prikupljanje komponenti. Šta je tu izuzetno? Ovdje predstavljamo komponentu balansera.
Ovo je gotova Docker slika koja pokreće nginx i aplikaciju koja sluša na Docker socketu. Dinamičan, kako se kontejneri uključuju i isključuju, regenerira nginx konfiguraciju. Rukovanje komponentama distribuiramo po imenima domena trećeg nivoa.
Za razvojno okruženje koristimo .dev domen - api.informer.dev. Aplikacije sa .dev domenom dostupne su na lokalnom stroju programera.
Nadalje, konfiguracije se prenose na svaki projekat i svi projekti se pokreću zajedno u isto vrijeme.
Grafički se ispostavlja da je klijent naš pretraživač ili neki alat pomoću kojeg postavljamo zahtjeve balanseru.
Balanser imena domena određuje koji kontejner 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 nginx-u daju u obliku otpremanja slika.
Dijagram pokazuje da su kontejneri povezani virtuelnom mrežom i skriveni iza proxyja.
Na mašini programera možete pristupiti kontejneru znajući IP, ali mi to u principu ne koristimo. Praktično nema potrebe za direktnim pristupom.
Koji primjer pogledati za dockerizaciju vaše aplikacije? Po mom mišljenju, dobar primjer je zvanična docker slika za MySQL.
To je prilično izazovno. Postoji mnogo verzija. Ali njegova funkcionalnost vam omogućava da pokrijete mnoge potrebe koje se mogu pojaviti u procesu daljeg razvoja. Ako provedete vrijeme i shvatite kako sve to djeluje, onda mislim da nećete imati problema u samoprovođenju.
Hub.docker.com obično sadrži veze do github.com, koji sadrži sirove podatke direktno iz kojih možete sami napraviti sliku.
Dalje u ovom spremištu nalazi se docker-endpoint.sh skripta, koja je odgovorna za početnu inicijalizaciju i za dalju obradu pokretanja aplikacije.
Također u ovom primjeru postoji mogućnost konfigurisanja pomoću varijabli okruženja. Definiranjem varijable okruženja prilikom pokretanja jednog kontejnera ili putem docker-compose, možemo reći da moramo postaviti praznu lozinku za docker za root na MySQL-u ili kako god želimo.
Postoji mogućnost kreiranja nasumične lozinke. Kažemo da nam treba korisnik, trebamo postaviti lozinku za korisnika i trebamo kreirati bazu podataka.
U našim projektima smo malo unificirali Dockerfile, koji je odgovoran za inicijalizaciju. Tamo smo ga ispravili prema našim potrebama da bude samo proširenje korisničkih prava koje aplikacija koristi. Ovo nam je omogućilo da kasnije jednostavno kreiramo bazu podataka iz konzole aplikacije. Ruby aplikacije imaju naredbu za kreiranje, modificiranje i brisanje baza podataka.
Ovo je primjer kako određena verzija MySQL-a izgleda na github.com. Možete otvoriti Dockerfile i vidjeti kako se tamo odvija instalacija.
docker-endpoint.sh je skripta odgovorna za ulaznu tačku. Tokom početne inicijalizacije, potrebni su neki pripremni koraci, a sve ove radnje se izvode samo u skripti za inicijalizaciju.
Pređimo na drugi dio.
Da bismo pohranili izvorne kodove, prešli smo na gitlab. Ovo je prilično moćan sistem koji ima vizuelni interfejs.
Jedna od komponenti Gitlaba je Gitlab CI. Omogućava vam da opišete niz naredbi koje će se kasnije koristiti za organiziranje sistema za isporuku koda ili pokretanje automatskog testiranja.
Gitlab CI 2 razgovor - izvještaj iz kluba Ruby Russia - prilično detaljan i možda će vas zanimati.
Sada ćemo pogledati šta je potrebno da bi se aktivirao Gitlab CI. Da bismo pokrenuli Gitlab CI, samo trebamo staviti datoteku .gitlab-ci.yml u korijen projekta.
Ovdje opisujemo da želimo izvršiti niz stanja kao što je test, implementacija.
Izvršavamo skripte koje direktno pozivaju docker-compose da bismo napravili našu aplikaciju. Ovo je samo backend primjer.
Zatim kažemo da je potrebno pokrenuti migracije za promjenu baze podataka i pokrenuti testove.
Ako su skripte ispravno izvršene i ne vrate kod greške, tada sistem prelazi na drugu fazu implementacije.
Faza implementacije je trenutno implementirana za fazu. Nismo organizirali ponovno pokretanje bez zastoja.
Nasilno gasimo sve kontejnere, a zatim ponovo podižemo sve kontejnere, prikupljene u prvoj fazi tokom testiranja.
Pokrećemo za trenutnu varijablu okruženja migracije baze podataka koje su napisali programeri.
Postoji napomena da se ovo odnosi samo na glavnu granu.
Prilikom promjene drugih grana se ne izvršava.
Moguće je organizirati uvođenje po poslovnicama.
Da bismo ovo dodatno organizirali, moramo instalirati Gitlab Runner.
Ovaj uslužni program je napisan na Golangu. To je jedan fajl, kao što je uobičajeno u svijetu Golang, koji ne zahtijeva nikakve ovisnosti.
Prilikom pokretanja, registrujemo Gitlab Runner.
Dobijamo ključ u Gitlab web interfejsu.
Zatim pozivamo naredbu za inicijalizaciju na komandnoj liniji.
Postavite Gitlab Runner interaktivno (Shell, Docker, VirtualBox, SSH)
Kod na Gitlab Runner-u će se izvršiti pri svakom urezivanju, ovisno o .gitlab-ci.yml postavci.
Kako to izgleda vizuelno u Gitlabu u web interfejsu. Nakon što smo povezali GItlab CI, imamo zastavicu koja pokazuje trenutno stanje build-a.
Vidimo da je urezivanje napravljeno prije 4 minute, koje je prošlo sve testove i nije izazvalo nikakve probleme.
Možemo detaljnije pogledati gradnje. Ovdje vidimo da su dvije države već prošle. Status testiranja i status implementacije na fazi.
Ako kliknemo na određeni build, onda će se na konzoli pojaviti izlaz naredbi koje su pokrenute u procesu prema .gitlab-ci.yml.
Ovako izgleda naša istorija proizvoda. Vidimo da je bilo uspješnih pokušaja. Kada se podnose testovi, ne prelazi se na sljedeći korak i kod se ne ažurira.
Koje smo zadatke rješavali na stagingu kada smo implementirali docker? Naš sistem se sastoji od komponenti i imali smo potrebu da restartujemo, samo dio komponenti koje su ažurirane u spremištu, a ne cijeli sistem.
Da bismo to uradili, morali smo sve razbiti u zasebne fascikle.
Nakon što smo to uradili, imali smo problem sa činjenicom da Docker-compose kreira sopstveni mrežni prostor za svakog tatu i ne vidi komšijske komponente.
Da bismo se mogli zaobići, kreirali smo mrežu u Dockeru ručno. U Docker-compose je napisano da takvu mrežu koristite za ovaj projekat.
Dakle, svaka komponenta koja počinje ovom mrežom vidi komponente u drugim dijelovima sistema.
Sljedeće pitanje je podjela staža na više projekata.
Kako bi sve ovo izgledalo lijepo i što bliže produkciji, dobro je koristiti port 80 ili 443 koji se koristi svuda na WEB-u.
Kako smo to riješili? Dodijelili smo jednog Gitlab Runnera za sve veće projekte.
Gitlab vam omogućava da pokrenete nekoliko distribuiranih Gitlab Runnera, koji će jednostavno preuzeti sve zadatke redom na haotičan način i pokrenuti ih.
Da ne bismo imali kuću, ograničili smo grupu naših projekata na jedan Gitlab Runner, koji se bez problema nosi sa našim volumenima.
Premjestili smo nginx-proxy u zasebnu skriptu za pokretanje i dodali rešetke za sve projekte u njoj.
Naš projekat ima jednu mrežu, a balanser ima nekoliko mreža po nazivima projekta. Može dalje proxy putem imena domena.
Naši zahtjevi dolaze preko domene na portu 80 i rješavaju se u grupu kontejnera koja opslužuje ovu domenu.
Koji su još problemi postojali? Ovo je ono što svi kontejneri pokreću kao root po defaultu. Ovo je root nejednak sa root hostom sistema.
Međutim, ako uđete u kontejner, on će biti root i datoteka koju kreiramo u ovom kontejneru dobija root prava.
Ako je programer ušao u kontejner i tamo napravio neke komande koje generišu fajlove, a zatim napustio kontejner, tada ima fajl u svom radnom direktorijumu kojem nema pristup.
Kako se to može riješiti? Možete dodati korisnike koji će biti u kontejneru.
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 sa ID 1000.
U našem slučaju, to se poklopilo sa činjenicom da gotovo svi programeri koriste Ubuntu OS. A na Ubuntuu, prvi korisnik ima ID od 1000.
Imamo li planove?
Pročitajte Docker dokumentaciju. Projekt se aktivno razvija, dokumentacija se mijenja. Podaci koji su dobijeni prije dva-tri mjeseca već polako zastarevaju.
Neki od problema koje smo riješili su vrlo vjerojatno već riješeni standardnim sredstvima.
Tako da želim da idem dalje da bih prešao direktno na orkestraciju.
Jedan primjer je Dockerov ugrađeni mehanizam pod nazivom Docker Swarm, koji dolazi iz kutije. Želim pokrenuti nešto u proizvodnji bazirano na Docker Swarm tehnologiji.
Kontejneri za mriješćenje čine nezgodnim rad s trupcima. Sada su trupci izolirani. Rasuti su po kontejnerima. Jedan od zadataka je da se omogući zgodan pristup evidenciji putem web sučelja.
izvor: www.habr.com