Proponi di leghje a trascrizione di u rapportu di Alexander Sigachev da Inventos "Processu di sviluppu è di prova cù Docker + Gitlab CI"
Quelli chì sò appena cuminciati à implementà u prucessu di sviluppu è di prova basatu nantu à Docker + Gitlab CI ponu spessu dumande basi. Induve principià ? Cumu urganizà? Cumu pruvà?
Stu rapportu hè bonu perchè parla in una manera strutturata di u prucessu di sviluppu è di prova cù Docker è Gitlab CI. U rapportu stessu hè di 2017. Pensu chì da stu rapportu pudete amparà i principii, metodulugia, idea, sperienza di usu.
Quale importa, per piacè sottu à u ghjattu.
Mi chjamu Alexander Sigachev. U travagliu per Inventos. Vi diceraghju di a mo sperienza d'utilizà Docker è cumu implementemu gradualmente in i prughjetti in a cumpagnia.
Tema di presentazione: Prucessu di sviluppu cù Docker è Gitlab CI.
Questa hè a mo seconda discussione nantu à Docker. À u mumentu di u primu rapportu, avemu usatu solu Docker in Sviluppu nantu à e macchine di sviluppatore. U numaru di l'impiegati chì anu utilizatu Docker era di circa 2-3 persone. À pocu à pocu, l'esperienza hè stata acquistata è andemu un pocu più. Link à u nostru .
Chì serà in stu rapportu? Avemu da sparte a nostra sperienza nantu à quale rake avemu cullatu, chì prublemi avemu risoltu. Micca in ogni locu era bellu, ma permessu di passà.
U nostru mottu hè: dock tuttu ciò chì pudemu mette in manu.
Chì prublemi risolvemu ?
Quandu ci sò parechje squadre in una cumpagnia, u programatore hè una risorsa cumuna. Ci sò tappe quandu un programatore hè tiratu fora di un prughjettu è datu per qualchì tempu à un altru prughjettu.
Per chì u programatore capisce rapidamente, hà bisognu di scaricà u codice fonte di u prugettu è di lancià l'ambiente u più prestu pussibule, chì li permetterà di passà più per risolve i prublemi di stu prughjettu.
Di solitu, si principia da zero, allora ci hè pocu documentazione in u prugettu. L'infurmazioni nantu à cumu si stallanu sò dispunibuli solu per i vechji. L'impiegati stallanu u so postu di travagliu per sè stessu in unu o dui ghjorni. Per accelerà questu, avemu usatu Docker.
U mutivu prossimu hè a standardizazione di i paràmetri in u Sviluppu. In a mo sperienza, i sviluppatori sempre piglianu l'iniziativa. In ogni quintu casu, un duminiu persunalizatu hè inseritu, per esempiu, vasya.dev. Seduta accantu à ellu hè u so vicinu Petya, chì u duminiu hè petya.dev. Sviluppanu un situ web o qualchì cumpunente di u sistema utilizendu stu nome di duminiu.
Quandu u sistema cresce è questi nomi di duminiu cumincianu à entre in cunfigurazioni, un cunflittu di l'ambiente di Sviluppu nasce è a strada di u situ hè riscritta.
U stessu passa cù i paràmetri di basa di dati. Qualchissia ùn si preoccupa micca di a sicurità è travaglia cù una password di root vacante. In u stadiu di a stallazione, MySQL hà dumandatu à qualchissia per una password è a password hè stata 123. Succede spessu chì a cunfigurazione di a basa di dati hè cambiatu constantemente secondu l'impegnu di u sviluppatore. Qualchissia hà currettu, qualcunu ùn hà micca currettu a cunfigurazione. Ci sò stati trucchi quandu avemu pigliatu un tipu di cunfigurazione di prova .gitignore è ogni sviluppatore avia da installà a basa di dati. Questu hà fattu difficiule di principià. Hè necessariu, frà altri cose, di ricurdà di a basa di dati. A basa di dati deve esse inizializzata, una password deve esse inserita, un utilizatore deve esse registratu, una tavola deve esse creata, è cusì.
Un altru prublema hè e diverse versioni di biblioteche. Spessu succede chì un sviluppatore travaglia cù diversi prughjetti. Ci hè un prughjettu Legacy chì hà iniziatu cinque anni fà (da 2017 - ed. nota). À u mumentu di u lanciu, avemu principiatu cù MySQL 5.5. Ci hè ancu prughjetti muderni induve pruvemu à implementà versioni più muderni di MySQL, per esempiu, 5.7 o più vechje (in 2017 - ed. nota)
Qualchidunu chì travaglia cù MySQL sapi chì queste biblioteche portanu dependenzii cun elli. Hè piuttostu problematicu di gestisce 2 basi inseme. Almenu, i vechji clienti sò problematiche per cunnette à a nova basa di dati. Questu à u turnu crea parechji prublemi.
U prublema dopu hè quandu un sviluppatore travaglia nantu à una macchina locale, usa risorse lucali, schedarii lucali, RAM locale. Ogni interazzione à u mumentu di sviluppà una suluzione à i prublemi hè realizatu in u quadru di u fattu chì travaglia nantu à una macchina. Un esempiu hè quandu avemu servitori backend in Produzione 3, è u sviluppatore salva i schedari in u cartulare radicale è da quì nginx piglia i schedari per risponde à a dumanda. Quandu un tali codice entra in Produzzione, si trova chì u schedariu hè presente nantu à unu di i servitori 3.
A direzzione di i microservizi si sviluppa avà. Quandu avemu dividitu i nostri grandi applicazioni in qualchi picculi cumpunenti chì interagisce cù l'altri. Questu permette di selezziunà e tecnulugia per una pila specifica di tarei. Hè ancu permette di sparte u travagliu è e responsabilità trà i sviluppatori.
Frondend-sviluppatore, sviluppatu nantu à JS, ùn hà quasi nisuna influenza nantu à Backend. U sviluppatore backend, à u turnu, sviluppa, in u nostru casu, Ruby on Rails è ùn interferiscenu micca cù Frondend. L'interazzione hè realizata cù l'API.
Cum'è un bonus, cù l'aiutu di Docker, pudemu riciclà risorse nantu à Staging. Ogni prughjettu, per via di e so specificità, necessitava certi paràmetri. Fisicamente, era necessariu d'assignà un servitore virtuale è cunfigurà per separatamente, o di sparte un tipu d'ambiente variabile è i prughjetti puderanu, secondu a versione di e biblioteche, influenzà l'altri.
Strumenti. Chì avemu aduprà?
- Docker stessu. U Dockerfile descrive e dipendenze di una sola applicazione.
- Docker-compose hè un bundle chì riunisce alcune di e nostre applicazioni Docker.
- Utilizemu GitLab per almacenà u codice fonte.
- Utilizemu GitLab-CI per l'integrazione di u sistema.
U rapportu hè custituitu di dui parti.
A prima parte parlerà di cumu Docker hè stata eseguita nantu à e macchine di sviluppatori.
A seconda parte parlerà di cumu interagisce cù GitLab, cumu eseguimu e teste è cumu stendemu à Staging.
Docker hè una tecnulugia chì permette (aduprendu un approcciu dichjarazione) per discrìviri i cumpunenti necessarii. Questu hè un esempiu di Dockerfile. Quì dichjaremu chì eredimu da l'imagine ufficiale Ruby: 2.3.0 Docker. Contene a versione Ruby 2.3 installata. Installemu e librerie di custruzzione necessarie è NodeJS. Descrivemu chì avemu creatu un repertoriu /app. Pone u cartulare di l'app cum'è u cartulare di travagliu. In questu repertoriu pusemu u minimu minimu Gemfile è Gemfile.lock. Dopu custruimu i prughjetti chì stallanu sta maghjina di dependenza. Indicà chì u cuntinuu serà prontu à sente à u portu esternu 3000. L'ultimu cumandamentu hè u cumandamentu chì lancia direttamente a nostra applicazione. Se eseguimu u cumandamentu di iniziu di u prughjettu, l'applicazione pruverà à eseguisce è eseguisce u cumandamentu specificatu.
Questu hè un esempiu minimu di un schedariu docker-compose. In questu casu, dimustramu chì ci hè una cunnessione trà dui cuntenituri. Questu hè direttamente in u serviziu di basa di dati è u serviziu web. E nostre applicazioni web in a maiò parte di i casi necessitanu un tipu di basa di dati cum'è backend per almacenà dati. Siccomu usemu MySQL, l'esempiu hè cù MySQL - ma nunda ùn ci impedisce di utilizà una altra basa di dati (PostgreSQL, Redis).
Pigliemu da a fonte ufficiale da u Docker hub l'imaghjini di MySQL 5.7.14 senza cambiamenti. Cullemu l'imaghjini chì hè rispunsevule per a nostra applicazione web da u repertoriu attuale. Raccoglie una maghjina per noi durante u primu lanciu. Allora corre u cumandimu chì eseguimu quì. Se vulteremu, videremu chì u cumandamentu di lanciamentu via Puma hè statu definitu. Puma hè un serviziu scrittu in Ruby. In u sicondu casu, annunziemu. Stu cumandamentu pò esse arbitrariu sicondu i nostri bisogni o compiti.
Descrivemu ancu chì avemu bisognu di rinvià un portu nantu à a nostra macchina d'ospiti di sviluppatore da 3000 à 3000 nantu à u portu di u containeru. Questu hè fattu automaticamente cù iptables è u so mecanismu, chì hè direttamente incrustatu in Docker.
U sviluppatore pò ancu, cum'è prima, accede à qualsiasi indirizzu IP dispunibule, per esempiu, 127.0.0.1 hè l'indirizzu IP locale o esternu di a macchina.
L'ultima linea dice chì u cuntinuu web dipende da u cuntinuu db. Quandu chjamemu l'iniziu di u cuntinuu web, docker-compose hà da principià a basa di dati per noi. Digià à u principiu di a basa di dati (in fatti, dopu à u lanciamentu di u cuntinuu! Questu ùn guarantisci micca a prontezza di a basa di dati) lanciarà l'applicazione, u nostru backend.
Questu evita l'errore quandu a basa di dati ùn hè micca purtata è salve risorse quandu si ferma u containeru di a basa di dati, liberendu cusì risorse per altri prughjetti.
Ciò chì ci dà l'usu di dockerization di basa di dati nantu à u prugettu. Fixemu a versione di MySQL per tutti i sviluppatori. Questu evita alcuni errori chì ponu accade quandu e versioni divergenu, quandu a sintassi, a cunfigurazione, i paràmetri predeterminati cambianu. Questu permette di specificà un hostname cumuni per a basa di dati, login, password. Avemu alluntanati da u zoo di nomi è cunflitti in i schedarii di cunfigurazione chì avemu avutu prima.
Avemu l'uppurtunità di utilizà una cunfigurazione più ottima per l'ambienti di Sviluppu, chì differiscerà da u predeterminatu. MySQL hè cunfiguratu per e macchine debuli per difettu è u so rendimentu fora di a scatula hè assai poviru.
Docker permette di utilizà l'interprete Python, Ruby, NodeJS, PHP di a versione desiderata. Ci sguassate di a necessità di utilizà un tipu di gestore di versione. Precedentemente, Ruby hà utilizatu un pacchettu rpm chì vi permette di cambià a versione secondu u prugettu. Permette ancu, grazia à u cuntinuu Docker, di migrerà u codice è a versione inseme cù dipendenze. Ùn avemu micca prublema per capiscenu a versione di l'interprete è di u codice. Per aghjurnà a versione, calate u vechju cuntainer è alza u novu containeru. Se qualcosa andò male, pudemu calà u novu containeru, elevà u vechju containeru.
Dopu avè custruitu l'imaghjini, i cuntenituri in u Sviluppu è a Produzione seranu listessi. Questu hè soprattuttu veru per grandi installazioni.
In Frontend usemu JavaScipt è NodeJS.
Avà avemu l'ultimu prughjettu nantu à ReacJS. U sviluppatore hà currettu tuttu in u containeru è hà sviluppatu usendu hot-reload.
In seguitu, u compitu di assemblea JavaScipt hè lanciatu è u codice compilatu in statics hè datu per mezu di risorse di salvezza nginx.
Quì aghju datu u schema di u nostru ultimu prughjettu.
Chì travaglii sò stati risolti ? Avemu avutu bisognu di custruisce un sistema cù quale i dispositi mobili interagiscenu. Ricevenu dati. Una pussibilità hè di mandà notificazioni push à stu dispusitivu.
Chì avemu fattu per questu?
Avemu divisu in l'applicazione cumpunenti cum'è: a parte admin in JS, u backend, chì travaglia attraversu l'interfaccia REST sottu Ruby on Rails. U backend interagisce cù a basa di dati. U risultatu chì hè generatu hè datu à u cliente. U panel admin interagisce cù u backend è a basa di dati via l'interfaccia REST.
Avemu avutu ancu bisognu di mandà notificazioni push. Prima di quessa, avemu avutu un prughjettu chì implementava un mecanismu chì hè rispunsevule per furnisce notificazioni à e plataforme mobili.
Avemu sviluppatu u schema seguente: un operatore da u navigatore interagisce cù u pannellu di amministratore, u pannellu di amministratore interagisce cù u backend, u compitu hè di mandà notificazioni Push.
Push notifications interagisce cù un altru cumpunente chì hè implementatu in NodeJS.
Queues sò custruiti è dopu notificazioni sò mandati secondu u so mecanismu.
Dui basa di dati sò tracciati quì. À u mumentu, cù l'aiutu di Docker, usemu 2 basa di dati indipendenti chì ùn sò micca ligati l'un à l'altru in ogni modu. Inoltre, anu una reta virtuale cumuna, è e dati fisichi sò guardati in cartulari diffirenti nantu à a macchina di u sviluppatore.
U listessu ma in numeri. Questu hè induve a reutilizazione di u codice hè impurtante.
Se prima avemu parlatu di riutilizà u codice in forma di biblioteche, allora in questu esempiu, u nostru serviziu chì risponde à e notificazioni Push hè reutilizatu cum'è un servitore cumpletu. Fornisce una API. È u nostru novu sviluppu interagisce digià cun ellu.
À quellu tempu, avemu usatu a versione 4 di NodeJS. Avà (in 2017 - ed. nota) in i sviluppi recenti usemu a versione 7 di NodeJS. Ùn ci hè micca prublema in novi cumpunenti per involucrà novi versioni di biblioteche.
Se necessariu, pudete refactor è elevà a versione NodeJS da u serviziu di notificazione Push.
È se pudemu mantene a cumpatibilità API, allora serà pussibule rimpiazzà cù altri prughjetti chì sò stati utilizati prima.
Chì avete bisognu di aghjunghje Docker? Aghjunghjemu un Dockerfile à u nostru repository, chì descrive e dipendenze necessarie. In questu esempiu, i cumpunenti sò spartuti logicamente. Questu hè u settore minimu di un sviluppatore backend.
Quandu creanu un novu prughjettu, creamu un Dockerfile, descrive l'ecosistema desideratu (Python, Ruby, NodeJS). In docker-compose, descrive a dependenza necessaria - a basa di dati. Avemu discrittu chì avemu bisognu di una basa di dati di tale è una tale versione, almacenà dati quì è quì.
Utilizemu un terzu containeru separatu cù nginx per serve static. Hè pussibule cullà ritratti. Backend li mette in un voluminu pre-preparatu, chì hè ancu muntatu in un cuntinuu cù nginx, chì dà u static.
Per almacenà u nginx, a cunfigurazione di mysql, avemu aghjustatu un cartulare Docker in quale guardemu i cunfigurazioni necessarii. Quandu un sviluppatore faci un git clone di un repository in a so macchina, hà digià un prughjettu prontu per u sviluppu lucale. Ùn ci hè micca dubbitu chì portu o chì paràmetri applicà.
Dopu, avemu parechji cumpunenti: admin, inform-API, push notifications.
Per principià tuttu questu, avemu creatu un altru repository, chì avemu chjamatu dockerized-app. À u mumentu avemu aduprà parechji repository prima di ogni cumpunente. Sò solu logicamente diffirenti - in GitLab pare un cartulare, ma nantu à a macchina di u sviluppatore, un cartulare per un prughjettu specificu. Un livellu sottu sò i cumpunenti chì saranu cumminati.
Questu hè un esempiu di solu u cuntenutu di dockerized-app. Purtemu ancu u repertoriu Docker quì, in quale compie e cunfigurazioni necessarie per l'interazzione di tutti i cumpunenti. Ci hè un README.md chì descrive brevemente cumu eseguisce u prugettu.
Quì avemu applicatu dui schedarii docker-compose. Questu hè fattu per pudè curriri in passi. Quandu un sviluppatore travaglia cù u core, ùn hà micca bisognu di notificazioni push, simpricimenti lancia un schedariu docker-compose è, per quessa, a risorsa hè salvata.
Se ci hè bisognu di integrà cù notificazioni push, allora docker-compose.yaml è docker-compose-push.yaml sò lanciati.
Siccomu docker-compose.yaml è docker-compose-push.yaml sò in un cartulare, una sola reta virtuale hè automaticamente creata.
Descrizzione di cumpunenti. Questu hè un schedariu più avanzatu chì hè rispunsevule per a cullizzioni di cumpunenti. Chì ci hè rimarchevule quì? Quì avemu introduttu u cumpunente balancer.
Questa hè una maghjina Docker pronta chì esegue nginx è una applicazione chì ascolta nantu à u socket Docker. Dinamicu, cum'è i cuntenituri sò attivati è disattivati, rigenera a cunfigurazione nginx. Distribuemu a gestione di cumpunenti per nomi di duminiu di terzu livellu.
Per l'ambiente di Sviluppu, usemu u duminiu .dev - api.informer.dev. L'applicazioni cù un duminiu .dev sò dispunibuli nantu à a macchina lucale di u sviluppatore.
In più, i cunfigurazioni sò trasferiti à ogni prughjettu è tutti i prughjetti sò lanciati inseme à u stessu tempu.
Graficamenti, risulta chì u cliente hè u nostru navigatore o qualchì strumentu cù quale facemu dumande à u balancer.
L'equilibriu di u nome di duminiu determina quale cuntainer à cuntattà.
Pò esse nginx, chì dà l'admin JS. Questu pò esse nginx, chì dà l'API, o schedarii statichi, chì sò dati à nginx in forma di uploads d'imaghjini.
U diagramma mostra chì i cuntenituri sò cunnessi da una reta virtuale è oculati daretu à un proxy.
In a macchina di u sviluppatore, pudete accede à u cuntinuu sapendu l'IP, ma in principiu ùn avemu micca aduprà questu. Ùn ci hè praticamente micca bisognu di accessu direttu.
Qualessu esempiu per fighjà per dockerize a vostra applicazione? In u mo parè, un bon esempiu hè l'imagine ufficiale di docker per MySQL.
Hè abbastanza sfida. Ci sò parechje versioni. Ma a so funziunalità vi permette di copre parechji bisogni chì ponu esse in u prucessu di più sviluppu. Se passate u tempu è capisce cumu tuttu interagisce, allora pensu chì ùn avete micca prublemi in l'autoimplementazione.
Hub.docker.com di solitu cuntene ligami à github.com, chì cuntene dati prima direttamente da quale pudete custruisce l'imaghjini sè stessu.
In più in questu repository ci hè un script docker-endpoint.sh, chì hè rispunsevule per l'inizializazione iniziale è per un ulteriore prucessu di u lanciu di l'applicazione.
Ancu in questu esempiu, ci hè a capacità di cunfigurà usendu variabili di l'ambiente. Definisce una variabile di l'ambiente quandu eseguisce un cuntainer unicu o attraversu docker-compose, pudemu dì chì avemu bisognu di stabilisce una password viota per docker per rootà in MySQL o ciò chì vulemu.
Ci hè una opzione per creà una password aleatoria. Dicemu chì avemu bisognu di un utilizatore, avemu bisognu di stabilisce una password per l'utilizatore, è avemu bisognu di creà una basa di dati.
In i nostri prughjetti, avemu pocu unificatu u Dockerfile, chì hè rispunsevule per l'inizializazione. Quì l'avemu currettu à i nostri bisogni per fà solu una estensione di i diritti di l'utilizatori chì l'applicazione usa. Questu ci hà permessu di creà una basa di dati da a cunsola di l'applicazione più tardi. L'applicazioni Ruby anu un cumandamentu per creà, mudificà è sguassà basa di dati.
Questu hè un esempiu di ciò chì pare una versione specifica di MySQL in github.com. Pudete apre u Dockerfile è vede cumu si passa a stallazione.
docker-endpoint.sh hè u script rispunsevuli di u puntu di entrata. Durante l'inizializazione iniziale, alcuni passi di preparazione sò richiesti, è tutte queste azzioni sò pigliate solu in u script d'inizializazione.
Passemu à a seconda parte.
Per almacenà i codici fonte, avemu cambiatu à gitlab. Questu hè un sistema abbastanza putente chì hà una interfaccia visuale.
Unu di i cumpunenti di Gitlab hè Gitlab CI. Permette di discrìviri una sequenza di cumandamenti chì dopu seranu utilizati per urganizà un sistema di spedizione di codice o eseguite teste automatiche.
Gitlab CI 2 talk - rapportu da u club Ruby Russia - abbastanza detallatu è forse vi interessarà.
Avà guardemu ciò chì hè necessariu per attivà Gitlab CI. Per inizià Gitlab CI, avemu bisognu di mette u schedariu .gitlab-ci.yml in a radica di u prugettu.
Quì avemu discrittu chì vulemu eseguisce una sequenza di stati cum'è una prova, implementà.
Eseguimu scripts chì chjamanu direttamente docker-compose per custruisce a nostra applicazione. Questu hè solu un esempiu di backend.
Dopu, dicemu chì hè necessariu di eseguisce migrazioni per cambià a basa di dati è eseguite testi.
Se i scripts sò eseguiti currettamente è ùn torna micca un codice d'errore, u sistema procede à a seconda tappa di a implementazione.
A tappa di implementazione hè attualmente implementata per staging. Ùn avemu micca urganizatu un riavviu zero-downtime.
Spegnemu per forza tutti i cuntenituri, è poi suscitamu tutti i cuntenituri di novu, cullati in a prima tappa durante a prova.
Eseguimu per a variabile di l'ambiente attuale e migrazioni di basa di dati chì sò state scritte da i sviluppatori.
Ci hè una nota chì questu hè appiicatu solu à u ramu maestru.
Quandu cambià altre rami ùn hè micca eseguitu.
Hè pussibule urganizà rollouts per rami.
Per urganizà questu più, avemu bisognu di installà Gitlab Runner.
Questa utilità hè scritta in Golang. Hè un schedariu unicu, cum'è cumunu in u mondu Golang, chì ùn hà micca bisognu di dipendenze.
À l'iniziu, registremu u Gitlab Runner.
Avemu a chjave in l'interfaccia web di Gitlab.
Allora chjamemu u cumandamentu di inizializazione in a linea di cummanda.
Configurate Gitlab Runner in modu interattivu (Shell, Docker, VirtualBox, SSH)
U codice nantu à Gitlab Runner eseguirà nantu à ogni cummit, secondu u paràmetru .gitlab-ci.yml.
Cumu vede visualmente in Gitlab in l'interfaccia web. Dopu avè cunnessu GItlab CI, avemu una bandiera chì mostra u statu di a custruzzione in u mumentu.
Avemu vistu chì un impegnu hè statu fattu 4 minuti fà, chì hà passatu tutte e teste è ùn hà micca causatu prublemi.
Pudemu guardà più attente à e custruzzioni. Quì avemu vistu chì dui stati sò digià passatu. Status di prova è statu di implementazione in staging.
Se clicchemu nantu à una custruzzione specifica, allora ci sarà un output di cunsola di i cumandamenti chì sò stati eseguiti in u prucessu secondu .gitlab-ci.yml.
Questu hè ciò chì a nostra storia di produttu pare. Avemu vistu chì ci sò stati tentativi riesciuti. Quandu i testi sò sottumessi, ùn passa micca à u passu prossimu è u codice di staging ùn hè micca aghjurnatu.
Chì travaglii avemu risoltu nantu à staging quandu avemu implementatu docker? U nostru sistema hè custituitu da cumpunenti è avemu avutu bisognu di riavvia, solu una parte di i cumpunenti chì sò stati aghjurnati in u repository, è micca tuttu u sistema.
Per fà questu, avemu avutu a smash tuttu in cartulare separati.
Dopu avemu fattu questu, avemu avutu un prublema cù u fattu chì Docker-compose crea u so propiu spaziu di rete per ogni babbu è ùn vede micca i cumpunenti di u vicinu.
Per fà u circondu, avemu creatu a reta in Docker manualmente. Hè statu scrittu in Docker-compose chì utilizate una rete cusì per stu prughjettu.
Cusì, ogni cumpunente chì principia cù questa maglia vede cumpunenti in altre parti di u sistema.
U prossimu prublema hè di sparte a messa in scena in parechji prughjetti.
Perchè per tuttu questu per vede bellu è u più vicinu à a pruduzzione, hè bonu per aduprà u portu 80 o 443, chì hè utilizatu in ogni locu in u WEB.
Cumu l'avemu risolta ? Avemu assignatu un Gitlab Runner à tutti i prughjetti maiò.
Gitlab vi permette di eseguisce parechji Gitlab Runners distribuiti, chì solu piglià tutte e tarei à turnu in una manera caòtica è eseguisce.
Perchè ùn avemu micca una casa, avemu limitatu u gruppu di i nostri prughjetti à un Gitlab Runner, chì copre senza prublemi cù i nostri volumi.
Avemu spustatu nginx-proxy in un script di startup separatu è aghjustatu griglie per tutti i prughjetti in questu.
U nostru prughjettu hà una griglia, è u balancer hà parechje griglie per nomi di prughjettu. Puderà più proxy per nomi di duminiu.
E nostre dumande venenu attraversu u duminiu nantu à u portu 80 è sò risolti in un gruppu di cuntainer chì serve stu duminiu.
Chì ci eranu altri prublemi ? Questu hè ciò chì tutti i cuntenituri funzionanu cum'è root per difettu. Questa hè a radica ineguale à l'ospite radicale di u sistema.
In ogni casu, se entre in u cuntinuu, serà root è u schedariu chì avemu creatu in questu cuntinuu riceve diritti di root.
Se u sviluppatore hà intrutu in u cuntinuu è hà fattu alcuni cumandamenti chì generanu schedarii, poi abbandunò u cuntinuu, allora hà un schedariu in u so repertoriu di travagliu chì ùn hà micca accessu.
Cumu pò esse risolta? Pudete aghjunghje utilizatori chì saranu in u cuntinuu.
Chì prublemi sò stati quandu avemu aghjustatu l'utilizatore?
Quandu creanu un utilizatore, spessu ùn avemu micca u stessu ID di gruppu (UID) è ID d'utilizatore (GID).
Per risolve stu prublema in u cuntinuu, usemu utilizatori cù ID 1000.
In u nostru casu, questu coincide cù u fattu chì quasi tutti i sviluppatori utilizanu Ubuntu OS. È in Ubuntu, u primu utilizatore hà un ID di 1000.
Avemu piani ?
Leghjite a documentazione di Docker. U prughjettu si sviluppa attivamente, a documentazione hè cambiata. I dati chì sò stati ricivuti dui o trè mesi fà sò digià lentamente diventendu obsoleti.
Qualchidunu di i prublemi chì avemu risoltu sò forse digià risolti per mezu standard.
Allora vogliu andà più luntanu digià per andà direttamente à l'orchestrazione.
Un esempiu hè u mecanismu integratu di Docker chjamatu Docker Swarm, chì esce da a scatula. Vogliu eseguisce qualcosa in produzzione basatu nantu à a tecnulugia Docker Swarm.
I cuntenituri di spawning rende inconveniente per travaglià cù i logs. Avà i logs sò isolati. Sò spargugliati in cuntenituri. Unu di i compiti hè di fà un accessu còmuda à i logs attraversu l'interfaccia web.
Source: www.habr.com