Najprv trocha teórie. Čo sa stalo ?
Jednoducho povedané, tento dokument je navrhnutý tak, aby zjednodušil vývoj aplikácií SaaS a pomohol tým, že informuje vývojárov a inžinierov DevOps o problémoch a postupoch, s ktorými sa najčastejšie stretávame pri vývoji moderných aplikácií.
Dokument vytvorili vývojári platformy Heroku.
Aplikáciu Twelve-Factor App možno použiť na aplikácie napísané v akomkoľvek programovacom jazyku a pomocou ľubovoľnej kombinácie podporných služieb (databázy, fronty správ, vyrovnávacie pamäte atď.).
Stručne o faktoroch, na ktorých je založená táto metodika:
- zdrojový kód – Jedna kódová základňa sledovaná v správe verzií – viaceré nasadenia
- Závislosti – Explicitne deklarujte a izolujte závislosti
- konfigurácia – Uložte konfiguráciu za behu
- Zálohovacie služby – Zvážte podporné služby ako prostriedky zásuvných modulov
- Stavať, uvoľňovať, bežať – Prísne oddeľte fázy montáže a realizácie
- procesy – Spustite aplikáciu ako jeden alebo viac bezstavových procesov
- Portová väzba – Exportné služby prostredníctvom viazania prístavov
- rovnobežnosť – Škálujte svoju aplikáciu pomocou procesov
- Jednorazovosť – Maximalizujte spoľahlivosť rýchlym spustením a čistým vypnutím
- Parita vývoja/prevádzky aplikácie – Udržujte svoje vývojové, pracovné a produkčné prostredie čo najpodobnejšie
- Ťažba dreva – Zobrazte denník ako prúd udalostí
- Administratívne úlohy – Vykonávať úlohy správy/riadenia pomocou procesov ad hoc
Viac informácií o týchto 12 faktoroch môžete získať z nasledujúcich zdrojov:
- - povinné čítanie
- — úradný preklad
- - nový pohľad na 12 faktorov s cieľom zlepšiť ich.
Čo je modro-zelené nasadenie?
Modro-zelené nasadenie je spôsob doručenia aplikácie výroba takým spôsobom, aby koncový klient nevidel žiadne zmeny z jeho strany. Inými slovami, nasadenie aplikácie s nulou prestoje.
Klasická schéma BG Deploy vyzerá ako na obrázku nižšie.
- Na začiatku sú 2 fyzické servery s úplne rovnakým kódom, aplikáciou, projektom a je tu router (balancer).
- Smerovač na začiatku nasmeruje všetky požiadavky na jeden zo serverov (zelená).
- V momente, keď potrebujete vydať znovu, celý projekt sa aktualizuje na inom serveri (modrý), ktorá momentálne nevybavuje žiadne žiadosti.
- Po zapnutí kódu Modrá server je úplne aktualizovaný, router dostane príkaz na prepnutie zelená na modrý serverov.
- Teraz všetci klienti vidia výsledok spusteného kódu modrý server.
- Po určitú dobu, zelená server slúži ako záložná kópia v prípade neúspešného nasadenia na modrý server a v prípade zlyhania a chýb smerovač prepne tok používateľov späť na zelená server so starou stabilnou verziou a nový kód sa odošle na revíziu a testovanie.
- A na konci procesu sa aktualizuje rovnakým spôsobom zelená server. A po jej aktualizácii router prepne tok požiadaviek späť na zelená serverov.
Všetko to vyzerá veľmi dobre a na prvý pohľad by s tým nemali byť žiadne problémy.
Ale keďže žijeme v modernom svete, možnosť s fyzickým prepínaním, ako je uvedené v klasickej schéme, nám nevyhovuje. Informáciu si zatiaľ zapíšte, vrátime sa k nej neskôr.
Zlé a dobré rady
Vylúčenie zodpovednosti: Nižšie uvedené príklady ukazujú nástroje/metodológie, ktoré používam, môžete použiť úplne akékoľvek alternatívy s podobnými funkciami.
Väčšina príkladov sa tak či onak prelína s vývojom webu (to je prekvapenie), s PHP a Dockerom.
Nižšie uvedené odseky poskytujú jednoduchý praktický popis použitia faktorov pomocou konkrétnych príkladov; ak chcete získať viac teórie na túto tému, prejdite na vyššie uvedené odkazy na pôvodný zdroj.
1. Kódová základňa
Použite FTP a FileZilla na nahrávanie súborov na servery jeden po druhom, neukladajte kód nikde inde ako na produkčnom serveri.
Projekt by mal mať vždy jeden základ kódu, to znamená, že celý kód pochádza z jedného ísť Úložisko. Servery (production, staging, test1, test2...) používajú kód z vetiev jedného spoločného úložiska. Týmto spôsobom dosiahneme konzistenciu kódu.
2. Závislosti
Stiahnite si všetky knižnice v priečinkoch priamo do koreňového adresára projektu. Vykonajte aktualizácie jednoducho prenesením nového kódu do priečinka s aktuálnou verziou knižnice. Nainštalujte všetky potrebné nástroje priamo na hostiteľský server, kde beží ďalších 20 služieb.
Projekt by mal mať vždy jasne zrozumiteľný zoznam závislostí (závislosťami myslím aj prostredie). Všetky závislosti musia byť explicitne definované a izolované.
Vezmime si ako príklad Skladať и prístavný robotník.
Skladať — správca balíkov, ktorý vám umožňuje inštalovať knižnice v PHP. Composer vám umožňuje špecifikovať verzie striktne alebo voľne a explicitne ich definovať. Na serveri môže byť 20 rôznych projektov a každý bude mať osobný zoznam balíkov a knižníc nezávislý na druhom.
prístavný robotník — pomôcka, ktorá vám umožňuje definovať a izolovať prostredie, v ktorom bude aplikácia bežať. Podľa toho, rovnako ako u skladateľa, ale dôkladnejšie, vieme určiť, s čím aplikácia pracuje. Vyberte si konkrétnu verziu PHP, nainštalujte iba balíčky potrebné na fungovanie projektu, bez pridávania čohokoľvek navyše. A čo je najdôležitejšie, bez zasahovania do balíčkov a prostredia hostiteľského stroja a iných projektov. To znamená, že všetky projekty na serveri bežiace cez Docker môžu používať absolútne akúkoľvek sadu balíkov a úplne odlišné prostredie.
3. Konfigurácia
Uložte konfigurácie ako konštanty priamo v kóde. Samostatné konštanty pre testovací server, samostatné pre produkciu. Previažte fungovanie aplikácie v závislosti od prostredia priamo v obchodnej logike projektu pomocou konštrukcií if else.
Konfigurácie - len týmto spôsobom by sa nasadenia projektov mali líšiť. V ideálnom prípade by sa konfigurácie mali prenášať cez premenné prostredia (env vars).
To znamená, že aj keď uložíte niekoľko konfiguračných súborov .config.prod .config.local a premenujete ich v čase nasadenia na .config (hlavná konfigurácia, z ktorej aplikácia načítava dáta) – nebude to správny prístup, keďže v tomto prípade budú informácie z konfigurácií verejne dostupné všetkým vývojárom aplikácií a dáta z produkčného servera budú kompromitované. Všetky konfigurácie musia byť uložené priamo v systéme nasadenia (CI/CD) a generované pre rôzne prostredia s rôznymi hodnotami potrebnými pre konkrétne prostredie v čase nasadenia.
4. Služby tretích strán
Buďte striktne viazaní na prostredie, používajte rôzne pripojenia pre rovnaké služby v určitých prostrediach.
V skutočnosti sa tento bod silne prekrýva s bodom o konfiguráciách, pretože bez tohto bodu nie je možné vytvoriť normálne konfiguračné údaje a vo všeobecnosti možnosť konfigurácie klesne na nulu.
Všetky pripojenia k externým službám, ako sú frontové servery, databázy, služby ukladania do vyrovnávacej pamäte, musia byť rovnaké pre lokálne prostredie aj produkčné prostredie tretích strán. Inými slovami, kedykoľvek, zmenou pripájacieho reťazca, môžem nahradiť volania základne #1 základňou #2 bez zmeny kódu aplikácie. Alebo, keď sa pozrieme dopredu, napríklad pri škálovaní služby, nebudete musieť špecifikovať pripojenie žiadnym špeciálnym spôsobom pre ďalší server vyrovnávacej pamäte.
5. Stavať, uvoľňovať, vykonávať
Majte na serveri iba konečnú verziu kódu bez možnosti vrátiť vydanie späť. Nie je potrebné zapĺňať miesto na disku. Každý, kto si myslí, že môže uvoľniť kód do výroby s chybou, je zlý programátor!
Všetky fázy nasadenia musia byť od seba oddelené.
Mať šancu vrátiť sa späť. Urobte vydania so starými kópiami aplikácie (už zostavené a pripravené na boj) uloženými v rýchlom prístupe, aby ste v prípade chýb mohli obnoviť starú verziu. To znamená, že podmienečne existuje priečinok správy a priečinok prúda po úspešnom nasadení a zostavení priečinka prúd prepojené symbolickým odkazom na nové vydanie, ktoré sa nachádza vo vnútri správy s konvenčným názvom čísla vydania.
Tu si pamätáme nasadenie Blue-Green, ktoré vám umožňuje nielen prepínať medzi kódom, ale aj prepínať medzi všetkými zdrojmi a dokonca aj prostrediami s možnosťou vrátiť všetko späť.
6. Procesy
Ukladajte údaje o stave aplikácie priamo v samotnej aplikácii. Použite relácie v pamäti RAM samotnej aplikácie. Využite čo najviac zdieľania medzi službami tretích strán. Držte sa toho, že aplikácia môže mať iba jeden proces a neumožňuje škálovanie.
Pokiaľ ide o relácie, údaje ukladajte iba do vyrovnávacej pamäte riadenej službami tretích strán (memcached, redis), takže aj keď máte spustených 20 aplikačných procesov, ktorýkoľvek z nich po prístupe do vyrovnávacej pamäte bude môcť pokračovať v práci s klientom v rovnaký stav, v akom používateľ pracoval s aplikáciou v inom procese. S týmto prístupom sa ukazuje, že bez ohľadu na to, koľko kópií služieb tretích strán používate, všetko bude fungovať normálne a bez problémov s prístupom k údajom.
7. Portová väzba
Iba webový server by mal vedieť, ako pracovať so službami tretích strán. Alebo ešte lepšie, nainštalujte služby tretích strán priamo na webový server. Napríklad ako modul PHP v Apache.
Všetky vaše služby musia byť navzájom prístupné prostredníctvom prístupu k nejakej adrese a portu (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), to znamená, že z nginx mám prístup k php-fpm aj k postgres a z php-fpm na postgres a nginx a vlastne z každej služby mám prístup k inej službe. Týmto spôsobom nie je životaschopnosť služby viazaná na životaschopnosť inej služby.
8. Paralelnosť
Pracujte s jedným procesom, inak sa niekoľko procesov nebude môcť navzájom zladiť!
Nechajte priestor na škálovanie. Docker swarm je na to skvelý.
Docker Swarm je nástroj na vytváranie a správu zhlukov kontajnerov medzi rôznymi strojmi a množstvom kontajnerov na rovnakom stroji.
Pomocou swarmu môžem určiť, koľko zdrojov pridelím jednotlivým procesom a koľko procesov tej istej služby spustím, a interný balancer, prijímajúci dáta na danom porte, ich automaticky proxy procesom. Keď vidím, že zaťaženie servera sa zvýšilo, môžem pridať ďalšie procesy, čím sa zníži zaťaženie určitých procesov.
9. Jednorazovosť
Na prácu s procesmi a údajmi nepoužívajte fronty. Zabitie jedného procesu by malo ovplyvniť celú aplikáciu. Ak vypadne jedna služba, pokazí sa všetko.
Každý proces a službu je možné kedykoľvek vypnúť a nemalo by to mať vplyv na ostatné služby (samozrejme to neznamená, že služba bude nedostupná pre inú službu, ale že po tejto sa iná služba nevypne). Všetky procesy musia byť ukončené s gráciou, aby pri ich ukončení nedošlo k poškodeniu dát a pri ďalšom zapnutí systém fungoval správne. To znamená, že ani v prípade núdzového ukončenia by nemalo dôjsť k poškodeniu údajov (tu je vhodný transakčný mechanizmus, dotazy v databáze fungujú len v skupinách a ak aspoň jeden dotaz zo skupiny zlyhá alebo sa vykoná s chyba, potom žiadny ďalší dotaz zo skupiny nakoniec v skutočnosti zlyhá).
10. Parita vývoja/prevádzky aplikácie
Produkcia, inscenácia a lokálna verzia aplikácie musia byť odlišné. Vo výrobe používame rámec Yii Lite a lokálne Yii, takže vo výrobe funguje rýchlejšie!
Reálne by všetky nasadenia a práca s kódom mali byť v takmer identickom prostredí (nehovoríme o fyzickom hardvéri). Taktiež by mal vedieť kód nasadiť do výroby v prípade potreby každý vývojový zamestnanec a nie nejaké špeciálne vyškolené devops oddelenie, ktoré len vďaka špeciálnej sile dokáže pozdvihnúť aplikáciu do produkcie.
Pomáha nám v tom aj Docker. Ak sú dodržané všetky predchádzajúce body, použitie dockeru privedie proces nasadenia prostredia na produkciu aj na lokálny počítač k zadávaniu jedného alebo dvoch príkazov.
11. Záznamy
Zapisujeme protokoly do súborov a databáz! Nečistíme súbory a databázy z protokolov. Kúpme si pevný disk s 9000 bajtami Peta a je to v poriadku.
Všetky záznamy by sa mali považovať za sled udalostí. Samotná aplikácia by sa nemala podieľať na spracovaní protokolov. Protokoly by sa mali odosielať buď do stdout alebo odosielať prostredníctvom protokolu, ako je udp, aby práca s protokolmi nevytvárala pre aplikáciu žiadne problémy. graylog je na to dobrý. Graylog prijímanie všetkých logov cez udp (tento protokol nevyžaduje čakanie na odpoveď o úspešnom prijatí paketu) nijako nezasahuje do aplikácie a zaoberá sa len štruktúrovaním a spracovaním logov. Aplikačná logika sa pre prácu s takýmito prístupmi nemení.
12. Administratívne úlohy
Ak chcete aktualizovať údaje, databázy atď., použite samostatne vytvorený koncový bod v rozhraní API. Ak ho spustíte 2-krát za sebou, všetko sa duplikuje. Ale nie ste hlúpi, dvakrát nekliknete a nepotrebujeme migráciu.
Všetky úlohy správy by sa mali vykonávať v rovnakom prostredí ako všetok kód na úrovni vydania. To znamená, že ak potrebujeme zmeniť štruktúru databázy, tak to neurobíme manuálne zmenou názvov stĺpcov a pridávaním nových cez nejaké vizuálne nástroje na správu databázy. Na takéto veci vytvárame samostatné skripty – migrácie, ktoré sa vykonávajú všade a vo všetkých prostrediach rovnako so spoločným a zrozumiteľným výsledkom. Pre všetky ostatné úlohy, ako je naplnenie projektu údajmi, by sa mali použiť podobné metodiky.
Príklad implementácie v PHP, Laravel, Laradock, Docker-Compose
PS Všetky príklady boli vytvorené na MacOS. Väčšina z nich je vhodná aj pre Linux. Používatelia systému Windows, odpustite mi, ale so systémom Windows som dlho nepracoval.
Predstavme si situáciu, že na našom PC nemáme nainštalovanú žiadnu verziu PHP a vôbec nič.
Nainštalujte najnovšie verzie docker a docker-compose. (dá sa to nájsť na internete)
docker -v &&
docker-compose -v
1. Dáme
git clone https://github.com/Laradock/laradock.git &&
ls
K Laradocku poviem, že je to veľmi vychytená vec, ktorá obsahuje veľa nádobiek a pomocných vecí. Ale používať Laradock ako taký bez úprav vo výrobe by som neodporúčal kvôli jeho redundancii. Je lepšie vytvárať si vlastné kontajnery na základe príkladov v Laradocku, bude to oveľa optimalizovanejšie, pretože nikto nepotrebuje všetko, čo je tam súčasne.
2. Nakonfigurujte Laradock na spustenie našej aplikácie.
cd laradock &&
cp env-example .env
2.1. Otvor si v nejakom editore adresár habr (nadradený priečinok, do ktorého sa klonuje laradock). (V mojom prípade PHPStorm)
V tejto fáze dávame projektu iba názov.
2.2. Spustite obrázok pracovného priestoru. (Vo vašom prípade bude vytvorenie obrázkov nejaký čas trvať)
Workspace je špeciálne pripravený obrázok na prácu s rámcom v mene vývojára.
Vchádzame do kontajnera pomocou
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Inštalácia Laravelu
composer create-project --prefer-dist laravel/laravel application
2.4. Po inštalácii skontrolujeme, či je adresár s projektom vytvorený a zabijeme kompose.
ls
exit
docker-compose down
2.5. Vráťme sa k PHPStormu a v súbore .env nastavíme správnu cestu k našej laravel aplikácii.
3. Pridajte celý kód do Gitu.
Aby sme to urobili, vytvoríme úložisko na Github (alebo kdekoľvek inde). Poďme do adresára habr v termináli a vykonajte nasledujúci kód.
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
Skontrolujeme, či je všetko v poriadku.
Pre pohodlie odporúčam použiť nejaké vizuálne rozhranie pre Git, v mojom prípade je to tak . (tu je odkaz na sprostredkovanie)
4. Poďme na štart!
Pred spustením sa uistite, že na portoch 80 a 443 nič nevisí.
docker-compose up -d nginx php-fpm
Náš projekt teda pozostáva z 3 samostatných služieb:
- nginx - webový server
- php-fpm - php na prijímanie požiadaviek z webového servera
- pracovný priestor - php pre vývojárov
Momentálne sme dosiahli, že sme vytvorili aplikáciu, ktorá spĺňa 4 body z 12, a to:
1. zdrojový kód — celý kód je v jednom úložisku (malá poznámka: môže byť správne pridať docker do projektu laravel, ale to nie je dôležité).
2. Závislosti - Všetky naše závislosti sú výslovne napísané v súbore application/composer.json a v každom súbore Docker každého kontajnera.
3. Zálohovacie služby — Každá zo služieb (php-fom, nignx, workspace) si žije vlastným životom a je prepojená zvonku a pri práci s jednou službou sa to druhej neovplyvní.
4. procesy — každá služba je jeden proces. Každá zo služieb si neudržiava interný stav.
5. Portová väzba
docker ps
Ako vidíme, každá služba beží na svojom vlastnom porte a je prístupná všetkým ostatným službám.
6. rovnobežnosť
Docker nám umožňuje vytvoriť viacero procesov rovnakých služieb s automatickým vyrovnávaním zaťaženia medzi nimi.
Zastavme kontajnery a prebehneme ich cez vlajku --stupnica
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Ako vidíme, boli vytvorené kópie kontajnera php-fpm. Na práci s týmto kontajnerom nemusíme nič meniť. Naďalej k nemu pristupujeme aj na porte 9000 a Docker za nás reguluje zaťaženie medzi kontajnermi.
7. Jednorazovosť - každý kontajner môže byť zabitý bez poškodenia druhého. Zastavenie alebo reštart kontajnera neovplyvní fungovanie aplikácie počas nasledujúcich spustení. Každý kontajner je tiež možné kedykoľvek zdvihnúť.
8. Parita vývoja/prevádzky aplikácie - všetky naše prostredia sú rovnaké. Spustením systému na serveri vo výrobe nebudete musieť nič meniť vo svojich príkazoch. Všetko bude založené na Dockerovi rovnakým spôsobom.
9. Ťažba dreva — všetky denníky v týchto kontajneroch idú do streamu a sú viditeľné v konzole Docker. (v tomto prípade v skutočnosti pri iných domácich nádobách to tak nemusí byť, ak sa o to nestaráte)
docker-compose logs -f
Existuje však háčik v tom, že predvolené hodnoty v PHP a Nginx tiež zapisujú protokoly do súboru. Na splnenie 12 faktorov je to nevyhnutné vypnutie zapisovanie protokolov do súboru v konfiguráciách každého kontajnera samostatne.
Docker tiež poskytuje možnosť odosielať protokoly nielen na stdout, ale aj na také veci, ako je graylog, ktorý som spomenul vyššie. A vo vnútri graylogu môžeme prevádzkovať protokoly, ako sa nám zachce a naša aplikácia si to nijako nevšimne.
10. Administratívne úlohy — všetky administratívne úlohy rieši laravel vďaka remeselníckemu nástroju presne tak, ako by si to tvorcovia aplikácie 12 faktorov želali.
Ako príklad ukážem, ako sa vykonávajú niektoré príkazy.
Ideme do kontajnera.
docker-compose exec workspace bash
php artisan list
Teraz môžeme použiť ľubovoľný príkaz. (upozorňujeme, že sme nekonfigurovali databázu a vyrovnávaciu pamäť, takže polovica príkazov sa nevykoná správne, pretože sú navrhnuté na prácu s vyrovnávacou pamäťou a databázou).
11. Konfigurácie a 12 XNUMX. Stavať, uvoľňovať, bežať
Túto časť som chcel venovať Modro-zelenému nasadeniu, ale ukázalo sa, že je na tento článok príliš obšírna. O tom napíšem samostatný článok.
Stručne povedané, koncept je založený na systémoch CI/CD, ako je napr Jenkins и Gitlab CI. V oboch môžete nastaviť premenné prostredia spojené s konkrétnym prostredím. Podľa toho bude v tejto situácii bod c splnený Konfigurácie.
A pointa o Stavať, uvoľňovať, bežať je riešený vstavanými funkciami s názvom Potrubie.
Potrubie umožňuje rozdeliť proces nasadenia do mnohých etáp so zvýraznením fáz montáže, uvoľnenia a realizácie. Aj v Pipeline môžete vytvárať zálohy a vlastne čokoľvek. Toto je nástroj s neobmedzeným potenciálom.
Kód aplikácie je na .
Pri klonovaní tohto úložiska nezabudnite inicializovať submodul.
PS: Všetky tieto prístupy možno použiť s akýmikoľvek inými nástrojmi a programovacími jazykmi. Hlavná vec je, že podstata sa nelíši.
Zdroj: hab.com