Cuminciamu cù una piccula teoria. Chì hè accadutu ?
In parolle simplici, stu documentu hè pensatu per simplificà u sviluppu di l'applicazioni SaaS, aiuta per fà i sviluppatori è l'ingegneri DevOps cunuscenti di i prublemi è e pratiche chì sò più spessu scontri in u sviluppu di l'applicazioni muderni.
U documentu hè statu creatu da i sviluppatori di a piattaforma Heroku.
A metodulugia App Twelve-Factor pò esse appiicata à l'applicazioni scritte in ogni lingua di prugrammazione è utilizendu qualsiasi cumminazione di servizii di supportu di terzu (base di dati, file di messagi, cache, etc.).
In breve nantu à i fatturi stessi nantu à quale sta metodulugia hè basata:
- Codebase - Una basa di codice tracciata da a fonte - implementazioni multiple
- Dipendenze - Dichjarà esplicitamente è isolà e dipendenze
- Cunfigurazione - Salvà a cunfigurazione in runtime
- Servizi di terzu parti (Servizi di sustegnu) - Tratta i servizii di sustegnu cum'è risorse pluggable
- Custruite, liberate, corre - Stadi di custruzzione è di esecuzione strettamente separati
- I prucessi - Eseguite l'applicazione cum'è unu o più prucessi senza statu
- Ubligatoriu portu - Servizii d'esportazione via u ligame portu
- Paralelisimu - Scala a vostra app cù prucessi
- Disposabilità - Massimizà l'affidabilità cù l'avviamentu veloce è l'arrestu graziosu
- Sviluppu di l'applicazioni / Operazione Parità - Mantene l'ambienti di sviluppu, di messa in scena è di produzzione u più simili pussibule
- Logging - Tratta u logu cum'è un flussu di avvenimenti
- Compiti di amministrazione - Eseguite attività di amministrazione / gestione cù prucessi una volta
Per più infurmazione nantu à i 12 fattori, vede e seguenti risorse:
- - deve leghje
- - traduzzione ufficiale
- - un novu sguardu à i 12 fattori per migliurà.
Cosa hè a implementazione Blue-Green?
A implementazione Blue-Green hè un modu per furnisce una applicazione à Pruduzzioni in tale manera chì u cliente finale ùn vede micca cambiamenti da a so parte. In altre parolle, implementà una applicazione cù zero morti.
U schema classicu BG Deploy s'assumiglia à l'imaghjini sottu.
- À u principiu, ci sò 2 servitori fisichi cù esattamente u listessu codice, applicazione, prughjettu, è ci hè un router (balancer).
- U router inizialmente dirige tutte e dumande à unu di i servitori (verde).
- À u mumentu quandu avete bisognu di fà una liberazione di novu, tuttu u prughjettu hè aghjurnatu nantu à un altru servitore (blu), chì ùn hè attualmente trattatu nisuna dumanda.
- Dopu à u codice nantu turchinu u servitore hè cumpletamente aghjurnatu, u router hè datu un cumandamentu per cambià da verde nantu blu servitore.
- Avà tutti i clienti vede u risultatu di u codice cù blu servitore.
- Per qualchì tempu, verde u servitore serve cum'è una copia di salvezza in casu di una implementazione senza successu à blu servitore è in casu di fallimentu è bugs, u router cambia u flussu di l'utilizatori verde servitore cù a vechja versione stabile, è u novu codice hè mandatu per a revisione è a prova.
- È à a fine di u prucessu, hè aghjurnatu in u listessu modu verde servitore. È dopu l'aghjurnà, u router cambia u flussu di dumanda torna à verde servitore.
Tuttu pare assai bè è à u primu sguardu ùn deve esse micca prublemi cù questu.
Ma postu chì vivemu in u mondu mudernu, l'opzione cù u cambiamentu fisicu, cum'è indicatu in u schema classicu, ùn ci cunvene micca. Registrate l'infurmazioni per avà, ci vulteremu dopu.
Cunsiglii mali è boni
Légales: L'esempii sottu mostranu l'utilità / metodulugia chì aghju utilizatu, pudete aduprà assolutamente qualsiasi alternativa cù funzioni simili.
A maiò parte di l'esempii s'interseceranu in qualchì modu cù u sviluppu web (chì sorpresa), cù PHP è Docker.
In i paragrafi sottu ci hè una descrizzione pratica simplice di l'usu di fatturi nantu à certi esempi, se vulete acquistà più teoria nantu à questu tema, riferite à i ligami sopra à a fonte originale.
1. Codebase
Aduprate FTP è FileZilla per cullà i fugliali à i servitori unu per volta, ùn guardate micca u codice in ogni locu eccettu in un servitore di produzzione.
Un prughjettu deve sempre avè una sola basa di codice, vale à dì, tuttu u codice vene da unu Git repository. I servitori (produzzione, staging, test1, test2 ...) utilizanu codice da e rami di un repository spartutu. Cusì, ghjunghjemu a coherenza di u codice.
2. Dipendenze
Scaricate tutte e librerie in cartulare direttamente à a radica di u prugettu. Fate l'aghjurnamenti solu trasfirendu u novu codice à u cartulare cù a versione attuale di a biblioteca. Mettite tutte e utilità necessarie direttamente nantu à u servitore di l'ospite induve altri servizii 20 sò in esecuzione.
U prugettu deve sempre avè una lista chjaramente comprensibile di dipendenze (per dependenzii, vogliu dì ancu l'ambiente). Tutte e dipendenze devenu esse esplicitamente definite è isolate.
Per esempiu, pigliemu cumpusituri и Docker.
cumpusituri - un gestore di pacchetti chì permette di installà biblioteche in PHP. Composer vi dà l'abilità di specificà rigurosamente o micca e versioni, è di definisce esplicitamente. Ci ponu esse 20 prughjetti diffirenti nantu à un servitore, è ognunu avarà una lista privata di pacchetti è biblioteche indipendenti di l'altru.
Docker - una utilità chì permette di definisce è isolà l'ambiente in quale l'applicazione hà da travaglià. In cunsiquenza, cum'è cù u cumpusitore, ma più accuratamente, pudemu determinà ciò chì l'applicazione travaglia. Sceglite una versione specifica di PHP, installate solu i pacchetti necessarii per u prughjettu di travaglià, senza aghjunghje nunda in più. E più impurtante, senza interferiscenu cù i pacchetti è l'ambiente di a macchina d'ospiti è altri prughjetti. Vale à dì, tutti i prughjetti nantu à u servitore chì passanu attraversu Docker ponu aduprà assolutamente qualsiasi set di pacchetti è ambienti completamente differenti.
3. Cunfigurazione
Store configs cum'è custanti ghjustu in u codice. Custanti separati per u servitore di teste, separati per a produzzione. Attaccà u travagliu di l'applicazione secondu l'ambienti direttamente in a logica cummerciale di u prugettu usendu l'altri custruzzioni.
Cunfigurazioni - questu hè l'unicu ciò chì deve differisce in a implementazione di u prugettu (implementazione). Ideale, e cunfigurazioni deve esse passate per variabili di l'ambiente (env vars).
Hè vale à dì, ancu s'è guardate parechji schedarii di cunfigurazione .config.prod .config.local è rinumateli à u mumentu di a distribuzione à .config (a cunfigurazione principale da quale l'applicazione leghje e dati) - questu ùn serà micca l'approcciu ghjustu, postu chì in questu casu, l'infurmazioni da e cunfigurazioni seranu publicamente dispunibili per tutti i sviluppatori di l'applicazioni è e dati da u servitore di produzzione seranu cumprumessi. Tutte e cunfigurazioni devenu esse almacenate direttamente in u sistema di implementazione (CI / CD) è generate per ambienti differenti cù valori differenti necessarii per un ambiente particulare à u mumentu di a implementazione.
4. Servizi di terzu (Servizi di Backing)
Attaccà duramente à l'ambiente, utilizate diverse cunnessione per i stessi servizii in certi ambienti.
In fatti, stu articulu hè fermamente intersecutu cù l'articulu di cunfigurazioni, postu chì senza a prisenza di questu articulu, i dati di cunfigurazione normale ùn ponu micca esse fatti è, in generale, a pussibilità di cunfigurazione sparirà.
Tutte e cunnessione à i servizii esterni, cum'è servitori di fila, basa di dati, servizii di caching deve esse listessi per l'ambiente lucale è l'ambiente di terzu / produzzione. In altre parolle, in ogni mumentu possu cambià a stringa di cunnessione per rimpiazzà e chjama à a basa #1 cù a basa #2 senza cambià u codice di l'applicazione. O, fighjendu avanti, per esempiu, quandu scaling u serviziu, ùn avete micca indicà a cunnessione in una manera speciale per un servitore di cache supplementu.
5. Custruite, liberate, corre
Mantene solu a versione finale di u codice nantu à u servitore, senza alcuna chance di rinvià a liberazione. Ùn ci hè bisognu di riempie u spaziu di discu. Quellu chì pensa ch'ellu pò mette u codice in pruduzzione cù un errore hè un cattivu programatore!
Tutte e fasi di implementazione deve esse siparati l'una di l'altru.
Avè a pussibilità di rinvià. Fate liberazioni cù un accessu rapidu à e vechji copie di l'applicazione (dighjà assemblate è pronte per a battaglia), per restaurà a vechja versione in casu d'errori. Questu hè, cundizionalmente ci hè un cartulare strogghi è u cartulare oghji, è dopu a implementazione successu è l'assemblea, u cartulare oghji hè assuciatu cù un ligame simbolicu à a nova versione chì si trova in l'internu strogghi cù u nome condicionale di u numeru di liberazione.
Hè quì chì ricurdemu di implementazione Blue-Green, chì vi permette micca solu di cambià trà u codice, ma ancu di cambià trà tutte e risorse è ancu l'ambienti cù a capacità di rinvià tuttu.
6. Prucessi
Almacene i dati di u statu di l'applicazione direttamente in l'applicazione stessa. Aduprate sessioni in a RAM di l'applicazione stessa. Aduprà quantu pussibule spartutu trà servizii di terzu. Tie nantu à u fattu chì l'applicazione pò avè solu un prucessu è ùn permettenu micca scaling.
In quantu à e sessioni, almacenà e dati solu in una cache cuntrullata da servizii di terze parti (memcached, redis), cusì ancu s'è vo avete 20 prucessi di applicazione in esecuzione, qualcunu d'elli accede à a cache puderà cuntinuà à travaglià cù u cliente in u stessu statu. in quale l'utilizatore hà travagliatu cù l'applicazione in un altru prucessu. Cù stu approcciu, si gira fora chì ùn importa quante copie di servizii di terzu-party vo aduprate, tuttu hà da travaglià bè è senza prublemi cù accessu à dati.
7. Ubligatoriu portu
Solu u servitore web deve sapè cumu travaglià cù servizii di terzu. È hè megliu generalmente elevà servizii di terzu in u servitore web. Per esempiu, cum'è un modulu PHP in Apache.
Tutti i vostri servizii devenu esse accessibili l'un à l'altru attraversu una chjama à qualchì indirizzu è portu (localgost: 5432, localhost: 3000, nginx: 80, php-fpm: 9000), vale à dì, da nginx possu accede sia à php-fpm sia à u portu. postgres, è da php-fpm à postgres è nginx, è da ogni serviziu stessu, possu accede à un altru serviziu. Cusì, a salute di un serviziu ùn hè micca ligata à a salute di un altru serviziu.
8. Parallelismu
Travaglià cù un prucessu, è poi di colpu parechji prucessi ùn puderanu micca ghjunghje cù l'altri!
Lasciate l'opzione di scala. Docker swarm hè grande per questu.
Docker Swarm hè un strumentu per creà è gestisce clusters di cuntenituri trà e diverse macchine è una mansa di cuntenituri nantu à a stessa macchina.
Utilizendu swarm, possu determinà quanti risorse ch'e aghju attribuitu per ogni prucessu è quanti prucessi di u stessu serviziu correraghju, è u balancer internu, chì riceve dati nantu à un portu determinatu, automaticamente proxy à i prucessi. Cusì, videndu chì a carica nantu à u servitore hà aumentatu, possu aghjunghje più prucessi, riducendu cusì a carica nantu à certi prucessi.
9. Disposabilità
Ùn aduprate micca file per travaglià cù prucessi è dati. L'uccisione di un prucessu deve influenzallu u funziunamentu di tutta l'applicazione. Se un serviziu scende, tuttu scende.
Ogni prucessu è serviziu pò esse disattivatu in ogni mumentu è questu ùn deve micca affettà altri servizii (di sicuru, questu ùn hè micca u fattu chì u serviziu serà inaccessibile à un altru serviziu, ma chì un altru serviziu ùn si spegnerà micca dopu à questu). . Tutti i prucessi duveranu esse terminati dolcemente, in modu chì quandu sò terminati, i dati ùn saranu micca affettati è u sistema funziona currettamente a prossima volta chì hè attivatu. Hè vale à dì, ancu in l'eventu di un abortu, i dati ùn deve esse micca affettatu (u mecanismu di transazzione hè adattatu quì, e dumande à a basa di dati travaglianu solu in gruppi, è se almenu una dumanda da u gruppu hà fallutu o hè stata eseguita cù un errore. , allora nisuna altra dumanda da u gruppu hè eventualmente eseguita in fattu).
10. Sviluppu Applicazioni / Operazione Parità
A produzzione, a messa in scena è a versione lucale di l'applicazione deve esse diverse. In a pruduzzione, avemu u framework Yii Lite, è in u locu Yii, perchè travaglia più veloce in a produzzione!
In realtà, tutte e implementazioni è u travagliu cù u codice deve esse in un ambiente quasi identicu (ùn parlemu micca di hardware fisicu). Inoltre, ogni impiigatu di sviluppu deve esse capaci di implementà u codice à a pruduzzione, se ne necessariu, è micca un dipartimentu di devops specialmente furmatu, chì pò solu elevà l'applicazione in a produzzione per via di forza speciale.
Docker ci aiuta ancu cù questu. Sugettu à tutti i punti precedenti, l'usu di docker porterà u prucessu di implementà l'ambiente sia in a produzzione sia in a macchina locale per inserisce unu o dui cumandamenti.
11. Logging (Logs)
Scrivemu logs à i schedari è a basa di dati! Ùn pulite micca i schedari è a basa di dati da i logs. Cumprà solu un discu duru per 9000 Peta bytes è norme.
Tutti i logs deve esse cunsideratu cum'è un flussu di avvenimenti. L'applicazione stessa ùn deve micca trattà cù u processu di logs. I logs deve esse emessu sia à stdout o mandatu nantu à un protokollu cum'è udp per chì l'applicazione ùn crea micca prublemi cù i logs. Graylog funziona bè per questu. Graylog accettà tutti i log via udp (aduprendu stu protokollu, ùn hè micca necessariu d'aspittà per una risposta nantu à a ricezione riescita di u pacchettu) ùn interferiscenu micca cù l'applicazione in ogni modu è hè solu impegnatu in a strutturazione è u processu di logs. A logica di l'applicazione ùn cambia micca per travaglià cù questi approcci.
12. Cumpete di amministrazione
Per aghjurnà e dati, basa di dati, etc., utilizate un endpoint creatu separatamente in api, l'esekzione di quale 2 volte in una fila porta à u fattu chì tuttu pò esse duplicatu per voi. Ma ùn site micca stupidu, ùn avete micca cliccà 2 volte, è ùn avemu micca bisognu di migrazioni.
Tutti i travaglii di amministrazione deve esse realizatu in u stessu ambiente cum'è tuttu u codice, à u livellu di liberazione. Vale à dì, s'ellu ci vole à cambià a struttura di a basa di dati, allora ùn a faremu micca manualmente cambiendu i nomi di e culonne è aghjunghjendu novi per mezu di qualchì tipu di strumenti di gestione di basa di dati visuale. Per tali cose, creamu script separati - migrazioni chì sò realizati in ogni locu è in tutti l'ambienti cù u listessu risultatu cumuni è comprensibile. Per tutti l'altri travaglii, cum'è a populazione di un prughjettu cù dati, metodulugia simili deve esse applicata.
Esempiu di implementazione in PHP, Laravel, Laradock, Docker-Compose
PS Tutti l'esempii sò stati fatti nantu à MacOS. A maiò parte di travaglià ancu per Linux. Scusate, utilizatori di Windows, ma ùn aghju micca travagliatu cù Windows per un bellu pezzu.
Imagine una situazione chì ùn avemu micca una versione di PHP installata nantu à u nostru PC è nunda in tuttu.
Installa l'ultime versioni di docker è docker-compose. (questu pò esse truvatu in linea)
docker -v &&
docker-compose -v
1. Avemu messu
git clone https://github.com/Laradock/laradock.git &&
ls
In quantu à Laradock, diceraghju chì questu hè una cosa assai fresca, in quale sò cullati assai cuntenituri è cose ausiliarii. Ma per aduprà Laradock cum'è tali senza mudificazioni in a produzzione - ùn l'aghju micca cunsigliatu per via di a so redundanza. Hè megliu di creà i vostri cuntenituri basatu nantu à esempi in Laradock, cusì ci sarà assai ottimisazione, perchè nimu hà bisognu di tuttu ciò chì ci hè à u stessu tempu.
2. Configurazione Laradock per a nostra applicazione per travaglià.
cd laradock &&
cp env-example .env
2.1. Aprite u repertoriu habr (u cartulare parent in quale laradock hè clonatu) in ogni editore. (In u mo casu PHPStorm)
À questu stadiu, mettemu solu u nome di u prugettu.
2.2. Lanciamu l'imaghjini di u spaziu di travagliu. (In u vostru casu, l'imaghjini custruiranu per qualchì tempu)
Workspace hè una maghjina preparata apposta per travaglià cù u quadru in nome di u sviluppatore.
Andate in u cuntinuu cù
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Installazione di Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. Dopu à a stallazione, avemu verificatu s'ellu u cartulare cù u prugettu hè statu creatu, è tumbà cumpone.
ls
exit
docker-compose down
2.5. Riturnemu à PHPStorm è stabilisce a strada curretta à a nostra applicazione laravel in u schedariu .env.
3. Aghjunghjite tuttu u codice à Git.
Per fà questu, creeremu un repository in Github (o in ogni locu). Andemu à u repertoriu habr in u terminal è eseguisce u codice seguente.
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
Avemu verificatu se tuttu hè in ordine.
Per comodità, ricumandemu di utilizà un tipu d'interfaccia visuale per Git, in u mo casu questu hè . (link di riferimentu quì)
4. Lanciate !
Prima di principià, assicuratevi chì ùn avete nunda appesu à i porti 80 è 443.
docker-compose up -d nginx php-fpm
Cusì, u nostru prughjettu hè custituitu da 3 servizii separati:
- nginx - servitore web
- php-fpm - php per riceve richieste da un servitore web
- spaziu di travagliu - php per sviluppatore
À u mumentu, avemu ottinutu chì avemu creatu una applicazione chì currisponde à 4 punti di 12, vale à dì:
1. Codebase - tuttu u codice hè in un repository (una piccula nota: pò esse ghjustu per portà docker in u prughjettu laravel, ma questu ùn hè micca impurtante).
2. Dipendenze - Tutte e nostre dipendenze sò scritte esplicitamente in application/composer.json è in ogni Dockerfile di ogni cuntainer.
3. Servizi di terzu parti (Servizi di sustegnu) - Ognunu di i servizii (php-fom, nignx, workspace) vive a so propria vita è hè cunnessu da l'esternu è quandu travaglia cù un serviziu, l'altru ùn serà micca affettatu.
4. I prucessi Ogni serviziu hè un prucessu. Ogni serviziu ùn guarda micca u statu internu.
5. Ubligatoriu portu
docker ps
Comu pudemu vede, ogni serviziu funziona nantu à u so propiu portu è hè dispunibule per tutti l'altri servizii.
6. Paralelisimu
Docker ci permette di generà parechji prucessi di i stessi servizii cù equilibriu automaticu di carica trà elli.
Stop containers è cumincianu cù una bandiera --scala
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Comu pudemu vede, u containeru php-fpm hà copie. Ùn avemu bisognu di cambià nunda in u travagliu cù stu containeru. Avemu ancu cuntinuà à accede à u portu 9000, è Docker regula a carica trà i cuntenituri per noi.
7. Disposabilità - ogni cuntainer pò esse uccisu senza dannu l'altru. Ferma o riavvia u cuntinuu ùn affetterà micca u funziunamentu di l'applicazione in i lanciamenti successivi. Ogni cuntinuu pò ancu esse elevatu in ogni mumentu.
8. Sviluppu di l'applicazioni / Operazione Parità Tutti i nostri ambienti sò listessi. Eseguendu u sistema nantu à u servitore in produzzione, ùn avete micca bisognu di cambià nunda in i vostri cumandamenti. Tuttu serà basatu annantu à Docker in u listessu modu.
9. Logging - tutti i logs in questi cuntenituri vanu à u flussu è sò visibili in a cunsola Docker. (in questu casu, in fattu, cù altri cuntenituri fatti in casa, pò esse micca u casu si ùn avete micca cura di questu)
docker-compose logs -f
Ma, ci hè una cattura in chì i valori predeterminati in PHP è Nginx scrivenu ancu logs in un schedariu. Per scuntrà i fatturi 12, avete bisognu disattivà scrive logs à un schedariu in e cunfigurazioni di ogni cuntainer separatamente.
Docker furnisce ancu a capacità di mandà logs micca solu à stdout, ma ancu à cose cum'è graylog, chì aghju citatu sopra. È à l'internu di graylog, pudemu operare cù logs cum'è ci piace è a nostra applicazione ùn hà micca nutatu questu in ogni modu.
10. Compiti di amministrazione - tutti i travaglii di amministrazione sò risolti da laravel grazia à l'uttellu artighjanali esattamente cum'è i creatori di l'applicazione di fattore 12 volenu.
Cum'è un esempiu, vi mustrarà cumu alcuni cumandamenti sò eseguiti.
Andemu in u cuntinuu.
docker-compose exec workspace bash
php artisan list
Avà pudemu usà ogni cumandamentu. (Per piacè nutate chì ùn avemu micca stallatu a basa di dati è a cache, cusì a mità di i cumandamenti ùn saranu micca eseguiti currettamente, perchè sò pensati per travaglià cù a cache è a basa di dati).
11. Cunfigurazioni è 12. Custruite, liberate, corre
Vuliu dedicà sta parte à Blue-Green Deployment, ma hè statu troppu detallatu per questu articulu. Scriveraghju un articulu separatu annantu à questu.
In poche parole, u cuncettu hè basatu annantu à i sistemi CI / CD cum'è Jenkins и Gitlab CI. In i dui, pudete stabilisce variabili di l'ambiente assuciati cù un ambiente specificu. Dunque, in questu scenariu, l'elementu c Cunfigurazioni.
È u puntu circa Custruite, liberate, corre risolta da e funzioni integrate in i dui utilità chjamati Pipeline.
Pipeline permette di dividisce u prucessu di implementazione in parechje tappe, mettendu in risaltu e tappe di assemblea, liberazione è esecuzione. Ancu in Pipeline, pudete creà backups, è veramente qualcosa. Stu strumentu hà un putenziale illimitatu.
U codice di l'applicazione hè attivatu .
Ùn vi scurdate di inizializà u sottumodulu quandu clone stu repository.
PS: Tutti questi approcci ponu esse usatu cù qualsiasi altre utilità è linguaggi di prugrammazione. A cosa principal hè chì l'essenza ùn hè micca diffirenti.
Source: www.habr.com