În primul rând, o mică teorie. Ce s-a întâmplat ?
Cu cuvinte simple, acest document este conceput pentru a simplifica dezvoltarea aplicațiilor SaaS, ajutând prin informarea dezvoltatorilor și inginerilor DevOps despre problemele și practicile care sunt cel mai des întâlnite în dezvoltarea aplicațiilor moderne.
Documentul a fost creat de dezvoltatorii platformei Heroku.
Aplicația Twelve-Factor poate fi aplicată aplicațiilor scrise în orice limbaj de programare și utilizând orice combinație de servicii de backup (baze de date, cozi de mesaje, cache etc.).
Pe scurt despre factorii pe care se bazează această metodologie:
- Baza de cod – O bază de cod urmărită în controlul versiunilor – implementări multiple
- Dependențe – Declarați și izolați în mod explicit dependențele
- configurație – Salvați configurația în timpul de execuție
- Servicii de suport – Luați în considerare serviciile de sprijin ca resurse plug-in
- Construiește, eliberează, alergă – Separați strict etapele de asamblare și execuție
- Procesele – Rulați aplicația ca unul sau mai multe procese fără stat
- Legarea porturilor – Servicii de export prin legarea porturilor
- paralelism – Scalați aplicația utilizând procese
- Disponibilitate – Maximizați fiabilitatea cu pornire rapidă și oprire curată
- Paritate dezvoltare/operare aplicație – Mențineți mediile de dezvoltare, punere în scenă și producție cât mai asemănătoare
- Logare – Vizualizați jurnalul ca un flux de evenimente
- Sarcini de administrare – Efectuează sarcini de administrare/management folosind procese ad-hoc
Puteți obține mai multe informații despre cei 12 factori din următoarele resurse:
- - o lectura obligatorie
- - traducere oficială
- - o privire nouă asupra celor 12 factori cu scopul de a-i îmbunătăți.
Ce este implementarea Blue-Green?
Implementarea Blue-Green este o metodă de livrare a unei aplicații către producere în așa fel încât clientul final să nu vadă nicio modificare din partea sa. Cu alte cuvinte, implementarea unei aplicații cu zero nefuncționare.
Schema clasică BG Deploy arată ca cea prezentată în imaginea de mai jos.
- La început sunt 2 servere fizice cu absolut același cod, aplicație, proiect și există un router (balancer).
- Routerul direcționează inițial toate cererile către unul dintre servere (verde).
- În momentul în care trebuie să eliberați din nou, întregul proiect este actualizat pe alt server (albastru), care în prezent nu procesează nicio solicitare.
- După ce codul este pornit albastru serverul este complet actualizat, routerul primește o comandă de la care să comute verde pe albastru Server.
- Acum toți clienții văd rezultatul codului care rulează albastru Server.
- De ceva timp, verde serverul servește ca copie de rezervă în caz de implementare nereușită la albastru server și în caz de defecțiuni și erori, routerul comută înapoi fluxul utilizatorului verde server cu vechea versiune stabilă, iar noul cod este trimis pentru revizuire și testare.
- Și la sfârșitul procesului, acesta este actualizat în același mod verde Server. Și după actualizarea acestuia, routerul comută înapoi fluxul de cereri verde Server.
Totul arată foarte bine și la prima vedere nu ar trebui să fie probleme cu el.
Dar, din moment ce trăim în lumea modernă, opțiunea cu comutare fizică, așa cum este indicată în schema clasică, nu ni se potrivește. Înregistrați informațiile deocamdată, vom reveni la ele mai târziu.
Sfaturi bune și rele
Declinare a responsabilităţii: Exemplele de mai jos arata utilitatile/metodologiile pe care le folosesc, puteti folosi absolut orice alternative cu functii similare.
Majoritatea exemplelor se vor intersecta într-un fel sau altul cu dezvoltarea web (aceasta este o surpriză), cu PHP și Docker.
Paragrafele de mai jos oferă o descriere practică simplă a utilizării factorilor folosind exemple specifice; dacă doriți să obțineți mai multă teorie pe acest subiect, urmați linkurile de mai sus către sursa originală.
1. Baza de cod
Utilizați FTP și FileZilla pentru a încărca fișiere pe servere pe rând, nu stocați codul în altă parte decât pe serverul de producție.
Proiectul ar trebui să aibă întotdeauna o singură bază de cod, adică tot codul provine dintr-o singură bază merge repertoriu. Serverele (producție, staging, test1, test2...) folosesc cod din ramurile unui singur depozit comun. În acest fel obținem consistența codului.
2. Dependenţe
Descărcați toate bibliotecile din foldere direct la rădăcina proiectului. Faceți actualizări pur și simplu transferând noul cod în folderul cu versiunea curentă a bibliotecii. Instalați toate utilitățile necesare direct pe serverul gazdă unde rulează încă 20 de servicii.
Un proiect ar trebui să aibă întotdeauna o listă clar de înțeles de dependențe (prin dependențe mă refer și la mediu). Toate dependențele trebuie să fie definite și izolate în mod explicit.
Să luăm ca exemplu Compozitor и Docher.
Compozitor — un manager de pachete care vă permite să instalați biblioteci în PHP. Composer vă permite să specificați versiunile strict sau vag și să le definiți în mod explicit. Pot exista 20 de proiecte diferite pe server și fiecare va avea o listă personală de pachete și biblioteci, independent de celălalt.
Docher — un utilitar care vă permite să definiți și să izolați mediul în care va rula aplicația. În consecință, la fel ca și în cazul compozitorului, dar mai amănunțit, putem determina cu ce funcționează aplicația. Selectați o anumită versiune de PHP, instalați doar pachetele necesare pentru ca proiectul să funcționeze, fără a adăuga nimic în plus. Și cel mai important, fără a interfera cu pachetele și mediul mașinii gazdă și alte proiecte. Adică, toate proiectele de pe serverul care rulează prin Docker pot folosi absolut orice set de pachete și un mediu complet diferit.
3. Configurare
Stocați configurațiile ca constante direct în cod. Constante separate pentru serverul de testare, separate pentru producție. Legați funcționarea aplicației în funcție de mediu direct în logica de afaceri a proiectului folosind if else constructes.
Configurații - acesta este singurul mod în care implementările proiectelor ar trebui să difere. În mod ideal, configurațiile ar trebui să fie transmise prin variabilele de mediu (env vars).
Adică, chiar dacă stocați mai multe fișiere de configurare .config.prod .config.local și le redenumiți în momentul implementării în .config (configurația principală din care aplicația citește datele) - aceasta nu va fi abordarea potrivită, deoarece în acest caz, informațiile din configurații vor fi disponibile public pentru toți dezvoltatorii de aplicații, iar datele de pe serverul de producție vor fi compromise. Toate configurațiile trebuie să fie stocate direct în sistemul de implementare (CI/CD) și generate pentru diferite medii cu valori diferite necesare pentru un anumit mediu în momentul implementării.
4. Servicii ale terților
Fii strict legat de mediu, folosește conexiuni diferite pentru aceleași servicii în anumite medii.
De fapt, acest punct se suprapune puternic cu punctul despre configurații, deoarece fără acest punct, datele de configurare normale nu pot fi făcute și, în general, capacitatea de configurare va scădea la nimic.
Toate conexiunile la serviciile externe, cum ar fi serverele de coadă, bazele de date, serviciile de cache, trebuie să fie aceleași atât pentru mediul local, cât și pentru mediul terț/de producție. Cu alte cuvinte, în orice moment, prin schimbarea șirului de conexiune, pot înlocui apelurile către baza #1 cu baza #2 fără a schimba codul aplicației. Sau, privind în viitor, de exemplu, atunci când scalați serviciul, nu va trebui să specificați conexiunea într-un mod special pentru un server cache suplimentar.
5. Construiți, eliberați, executați
Aveți doar versiunea finală a codului pe server, fără șansa de a anula lansarea. Nu este nevoie să umpleți spațiu pe disc. Oricine crede că poate lansa codul în producție cu o eroare este un programator prost!
Toate etapele de implementare trebuie separate unele de altele.
Aveți șansa de a reveni. Faceți lansări cu copii vechi ale aplicației (deja asamblate și gata de luptă) salvate în acces rapid, astfel încât în caz de erori să puteți restaura versiunea veche. Adică, condiționat există un folder Comunicate și folder curent, iar după implementarea și asamblarea cu succes folderul curent legate printr-o legătură simbolică cu noua versiune care se află înăuntru Comunicate cu denumirea convențională a numărului de lansare.
Aici ne amintim de implementarea Blue-Green, care vă permite nu numai să comutați între cod, ci și să comutați între toate resursele și chiar mediile cu posibilitatea de a derula totul înapoi.
6. Procese
Stocați datele despre starea aplicației direct în cadrul aplicației în sine. Utilizați sesiuni în memoria RAM a aplicației în sine. Utilizați cât mai mult posibil partajare între servicii terțe. Bazați-vă pe faptul că aplicația poate avea un singur proces și nu permite scalarea.
În ceea ce privește sesiunile, stocați datele doar într-un cache controlat de servicii terțe (memcached, redis), deci chiar dacă aveți 20 de procese de aplicație în rulare, oricare dintre ele, având accesat cache-ul, va putea continua să lucreze cu clientul în aceeași stare în care utilizatorul lucra cu aplicația într-un alt proces. Cu această abordare, se dovedește că indiferent de câte copii ale serviciilor terță parte utilizați, totul va funcționa normal și fără probleme cu accesul la date.
7. Legarea portului
Doar serverul web ar trebui să știe cum să lucreze cu servicii terțe. Sau mai bine, instalați servicii terțe direct în interiorul serverului web. De exemplu, ca modul PHP în Apache.
Toate serviciile dumneavoastră trebuie să fie accesibile unul altuia prin acces la o anumită adresă și port (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), adică din nginx pot accesa atât php-fpm, cât și la postgres, și de la php-fpm la postgres și nginx și de fapt din fiecare serviciu pot accesa un alt serviciu. Astfel, viabilitatea unui serviciu nu este legată de viabilitatea altui serviciu.
8. Paralelism
Lucrați cu un singur proces, altfel mai multe procese nu se vor putea înțelege între ele!
Lăsați loc pentru scalare. Docker roi este grozav pentru asta.
Docker Swarm este un instrument pentru crearea și gestionarea clusterelor de containere atât între diferite mașini, cât și a unui grup de containere pe aceeași mașină.
Folosind swarm, pot determina câte resurse voi aloca fiecărui proces și câte procese ale aceluiași serviciu voi lansa, iar echilibratorul intern, primind date pe un anumit port, le va trimite automat către procese. Astfel, văzând că sarcina pe server a crescut, pot adăuga mai multe procese, reducând astfel încărcătura pe anumite procese.
9. Disponibilitate
Nu utilizați cozi pentru a lucra cu procese și date. Omoarea unui proces ar trebui să afecteze întreaga aplicație. Dacă un serviciu scade, totul se defectează.
Fiecare proces și serviciu poate fi oprit în orice moment și acest lucru nu ar trebui să afecteze alte servicii (desigur, acest lucru nu înseamnă că serviciul va fi indisponibil pentru un alt serviciu, dar că un alt serviciu nu se va opri după acesta). Toate procesele trebuie să fie încheiate cu grație, astfel încât, atunci când sunt terminate, nicio dată nu va fi deteriorată și sistemul va funcționa corect data viitoare când îl porniți. Adică, chiar și în cazul unei încetări de urgență, datele nu ar trebui să fie deteriorate (mecanismul tranzacției este potrivit aici, interogările din baza de date funcționează numai în grupuri și dacă cel puțin o interogare din grup eșuează sau este executată cu un eroare, atunci nicio altă interogare din grup nu reușește în cele din urmă).
10. Dezvoltarea aplicației/paritatea operațională
Producția, punerea în scenă și versiunea locală a aplicației trebuie să fie diferite. În producție folosim framework-ul Yii Lite, iar local Yii, astfel încât să funcționeze mai repede în producție!
În realitate, toate implementările și lucrul cu cod ar trebui să fie într-un mediu aproape identic (nu vorbim despre hardware fizic). De asemenea, orice angajat de dezvoltare ar trebui să poată implementa codul în producție, dacă este necesar, și nu un departament de devops special instruit, care numai datorită puterii speciale poate ridica aplicația în producție.
Docker ne ajută și cu asta. Dacă sunt respectate toate punctele anterioare, utilizarea docker va aduce procesul de implementare a mediului atât în producție, cât și pe mașina locală la introducerea uneia sau două comenzi.
11. Bușteni
Scriem jurnalele în fișiere și baze de date! Nu curățăm fișierele și bazele de date din jurnale. Să cumpărăm un hard disk cu 9000 Peta octeți și e în regulă.
Toate jurnalele trebuie considerate ca un flux de evenimente. Aplicația în sine nu ar trebui să fie implicată în procesarea jurnalelor. Jurnalele ar trebui să fie scoase fie către stdout, fie trimise printr-un protocol precum udp, astfel încât lucrul cu jurnalele să nu creeze probleme pentru aplicație. Graylog este bun pentru asta. Graylog care primește toate jurnalele prin udp (acest protocol nu necesită așteptarea unui răspuns despre recepția cu succes a pachetului) nu interferează în niciun fel cu aplicația și se ocupă doar de structurarea și procesarea jurnalelor. Logica aplicației nu se modifică pentru a funcționa cu astfel de abordări.
12. Sarcini de administrare
Pentru a actualiza datele, bazele de date etc., utilizați un punct final creat separat în API, executarea acestuia de 2 ori la rând va duce la duplicarea tuturor. Dar nu ești prost, nu vei da clic de două ori și nu avem nevoie de migrare.
Toate sarcinile de administrare ar trebui să fie efectuate în același mediu ca tot codul, la nivel de lansare. Adică, dacă trebuie să schimbăm structura bazei de date, atunci nu o vom face manual, schimbând numele coloanelor și adăugând altele noi prin intermediul unor instrumente vizuale de gestionare a bazei de date. Pentru astfel de lucruri, creăm scripturi separate - migrații, care sunt executate peste tot și în toate mediile în același mod, cu un rezultat comun și ușor de înțeles. Pentru toate celelalte sarcini, cum ar fi completarea proiectului cu date, ar trebui utilizate metodologii similare.
Exemplu de implementare în PHP, Laravel, Laradock, Docker-Compose
PS Toate exemplele au fost făcute pe MacOS. Cele mai multe dintre ele sunt potrivite și pentru Linux. Utilizatori Windows, scuzați-mă, dar nu am mai lucrat cu Windows de mult timp.
Să ne imaginăm o situație în care nu avem nicio versiune de PHP instalată pe computerul nostru și nimic deloc.
Instalați cele mai recente versiuni de docker și docker-compose. (acesta poate fi găsit pe internet)
docker -v &&
docker-compose -v
1. Pune
git clone https://github.com/Laradock/laradock.git &&
ls
În ceea ce privește Laradock, o să spun că este un lucru foarte tare, care conține o mulțime de containere și lucruri auxiliare. Dar nu aș recomanda utilizarea Laradock ca atare fără modificări în producție din cauza redundanței sale. Este mai bine să vă creați propriile containere pe baza exemplelor din Laradock, acest lucru va fi mult mai optimizat, deoarece nimeni nu are nevoie de tot ce este acolo în același timp.
2. Configurați Laradock pentru a rula aplicația noastră.
cd laradock &&
cp env-example .env
2.1. Deschideți directorul habr (dosarul părinte în care este clonat laradock) într-un editor. (În cazul meu PHPStorm)
În această etapă, dăm doar un nume proiectului.
2.2. Lansați imaginea spațiului de lucru. (În cazul dvs., realizarea imaginilor va dura ceva timp)
Spațiul de lucru este o imagine special pregătită pentru a lucra cu cadrul în numele dezvoltatorului.
Intrăm în interiorul recipientului folosind
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Instalarea Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. După instalare, verificăm dacă directorul cu proiectul a fost creat și kill compose.
ls
exit
docker-compose down
2.5. Să revenim la PHPStorm și să setăm calea corectă către aplicația noastră laravel în fișierul .env.
3. Adăugați tot codul la Git.
Pentru a face acest lucru, vom crea un depozit pe Github (sau oriunde altundeva). Să mergem la directorul habr din terminal și să executăm următorul cod.
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
Să verificăm dacă totul este în ordine.
Pentru comoditate, recomand să folosiți o interfață vizuală pentru Git, în cazul meu este . (aici este un link de recomandare)
4. Hai să lansăm!
Înainte de a începe, asigurați-vă că nimic nu este atârnat pe porturile 80 și 443.
docker-compose up -d nginx php-fpm
Astfel, proiectul nostru constă din 3 servicii separate:
- nginx - server web
- php-fpm - php pentru primirea cererilor de la un server web
- spațiu de lucru - php pentru dezvoltatori
În acest moment, am reușit să creăm o aplicație care întrunește 4 puncte din 12 și anume:
1. Baza de cod — tot codul este într-un singur depozit (notă mică: ar putea fi corect să adăugați docker în proiectul laravel, dar acest lucru nu este important).
2. Dependențe - Toate dependențele noastre sunt scrise explicit în application/composer.json și în fiecare Dockerfile al fiecărui container.
3. Servicii de suport — Fiecare dintre servicii (php-fom, nignx, workspace) își trăiește propria viață și este conectat din exterior, iar atunci când lucrează cu un serviciu, celălalt nu va fi afectat.
4. Procesele — fiecare serviciu este un proces. Fiecare dintre servicii nu menține starea internă.
5. Legarea porturilor
docker ps
După cum putem vedea, fiecare serviciu rulează pe propriul său port și este accesibil tuturor celorlalte servicii.
6. paralelism
Docker ne permite să generăm mai multe procese ale acelorași servicii cu echilibrarea automată a sarcinii între ele.
Să oprim containerele și să le trecem prin steag --scară
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
După cum putem vedea, au fost create copii ale containerului php-fpm. Nu trebuie să schimbăm nimic în lucrul cu acest container. De asemenea, continuăm să îl accesăm pe portul 9000, iar Docker reglementează încărcarea dintre containere pentru noi.
7. Disponibilitate - fiecare recipient poate fi ucis fără a-l răni pe celălalt. Oprirea sau repornirea containerului nu va afecta funcționarea aplicației în timpul lansărilor ulterioare. Fiecare container poate fi ridicat oricând.
8. Paritate dezvoltare/operare aplicație - toate mediile noastre sunt la fel. Prin rularea sistemului pe un server în producție, nu va trebui să schimbați nimic în comenzile dvs. Totul se va baza pe Docker în același mod.
9. Logare — toate jurnalele din aceste containere sunt transmise în flux și sunt vizibile în consola Docker. (în acest caz, de fapt, cu alte recipiente de casă, acesta poate să nu fie cazul dacă nu aveți grijă de el)
docker-compose logs -f
Dar există o captură în care valorile implicite din PHP și Nginx scriu, de asemenea, jurnalele într-un fișier. Pentru a îndeplini cei 12 factori, este necesar întrerupe scrierea jurnalelor într-un fișier în configurațiile fiecărui container separat.
Docker oferă, de asemenea, capacitatea de a trimite jurnalele nu doar către stdout, ci și către lucruri precum graylog, despre care am menționat mai sus. Și în interiorul graylog, putem opera jurnalele după bunul plac și aplicația noastră nu va observa acest lucru în niciun fel.
10. Sarcini de administrare — toate sarcinile de administrare sunt rezolvate de laravel datorită instrumentului artizanal exact așa cum și-ar dori creatorii aplicației cu 12 factori.
Ca exemplu, voi arăta cum sunt executate unele comenzi.
Intrăm în container.
docker-compose exec workspace bash
php artisan list
Acum putem folosi orice comandă. (vă rugăm să rețineți că nu am configurat baza de date și cache-ul, așa că jumătate din comenzi nu vor fi executate corect, deoarece sunt concepute pentru a funcționa cu cache-ul și baza de date).
11. Configurații și 12. Construiește, eliberează, alergă
Am vrut să dedic această parte implementării Blue-Green, dar s-a dovedit a fi prea extinsă pentru acest articol. Voi scrie un articol separat despre asta.
Pe scurt, conceptul se bazează pe sisteme CI/CD, cum ar fi Jenkins и Gitlab CI. În ambele, puteți seta variabile de mediu asociate unui anumit mediu. În consecință, în această situație, punctul c va fi îndeplinit Configurații.
Iar ideea despre Construiește, eliberează, alergă se rezolvă prin funcții încorporate cu numele Conductă.
Conductă vă permite să împărțiți procesul de implementare în mai multe etape, evidențiind etapele de asamblare, eliberare și execuție. De asemenea, în Pipeline, puteți crea copii de rezervă și, într-adevăr, orice. Acesta este un instrument cu un potențial nelimitat.
Codul aplicației este la .
Nu uitați să inițializați submodulul când clonați acest depozit.
PS: Toate aceste abordări pot fi utilizate cu orice alte utilitare și limbaje de programare. Principalul lucru este că esența nu diferă.
Sursa: www.habr.com