Nejprve trocha teorie. Co se stalo ?
Jednoduše řečeno, tento dokument je navržen tak, aby zjednodušil vývoj aplikací SaaS a pomohl tím, že informuje vývojáře a inženýry DevOps o problémech a postupech, se kterými se při vývoji moderních aplikací nejčastěji setkávají.
Dokument vytvořili vývojáři platformy Heroku.
Aplikaci Twelve-Factor App lze aplikovat na aplikace napsané v jakémkoli programovacím jazyce a využívající libovolnou kombinaci podpůrných služeb (databáze, fronty zpráv, mezipaměti atd.).
Stručně o faktorech, na kterých je tato metodika založena:
- Codebase – Jedna kódová základna sledovaná ve správě verzí – více nasazení
- Závislosti – Explicitně deklarujte a izolujte závislosti
- Konfigurace – Uložte konfiguraci za běhu
- Podpůrné služby – Zvažte podpůrné služby jako prostředky plug-in
- Stavět, uvolnit, spustit – Striktně oddělte fázi montáže a provádění
- Procesy – Spusťte aplikaci jako jeden nebo více bezstavových procesů
- Portová vazba – Exportní služby prostřednictvím vazby portů
- Rovnoběžnost – Škálujte svou aplikaci pomocí procesů
- Jednorázová – Maximalizujte spolehlivost díky rychlému spuštění a čistému vypínání
- Parita vývoje/provozu aplikace – Udržujte své vývojové, pracovní a produkční prostředí co nejpodobnější
- Protokolování – Zobrazit protokol jako proud událostí
- Administrativní úkoly – Provádějte úkoly správy/správy pomocí procesů ad hoc
Další informace o těchto 12 faktorech můžete získat z následujících zdrojů:
- - povinná četba
- — úřední překlad
- - nový pohled na 12 faktorů s cílem je zlepšit.
Co je modro-zelené nasazení?
Modro-zelené nasazení je způsob doručení aplikace výroba tak, aby koncový klient neviděl žádné změny z jeho strany. Jinými slovy, nasazení aplikace s nulou prostoje.
Klasické schéma nasazení BG vypadá jako na obrázku níže.
- Na začátku jsou 2 fyzické servery s naprosto stejným kódem, aplikací, projektem a je tam router (balancer).
- Router zpočátku směruje všechny požadavky na jeden ze serverů (zelená).
- V okamžiku, kdy potřebujete znovu vydat, je celý projekt aktualizován na jiném serveru (modrý), která v současné době nezpracovává žádné požadavky.
- Po zapnutí kódu modrý server je kompletně aktualizován, router dostane příkaz k přepnutí zelená na modrý server.
- Nyní všichni klienti vidí výsledek spuštěného kódu modrá server.
- Po určitou dobu, zelená server slouží jako záložní kopie v případě neúspěšného nasazení do modrý server a v případě selhání a chyb router přepne uživatelský tok zpět na zelená server se starou stabilní verzí a nový kód je odeslán k revizi a testování.
- A na konci procesu se aktualizuje stejným způsobem zelená server. A po jeho aktualizaci router přepne tok požadavku zpět na zelená server.
Všechno to vypadá velmi dobře a na první pohled by s tím neměl být žádný problém.
Ale protože žijeme v moderním světě, možnost s fyzickým přepínáním, jak je uvedeno v klasickém schématu, nám nevyhovuje. Informace si zatím zaznamenejte, vrátíme se k nim později.
Špatná a dobrá rada
Odmítnutí odpovědnosti: Níže uvedené příklady ukazují nástroje/metodiky, které používám, můžete použít naprosto jakékoli alternativy s podobnými funkcemi.
Většina příkladů se tak či onak protne s vývojem webu (to je překvapení), s PHP a Dockerem.
Níže uvedené odstavce poskytují jednoduchý praktický popis použití faktorů na konkrétních příkladech, pokud chcete získat více teorie na toto téma, přejděte na výše uvedené odkazy na původní zdroj.
1. Kódová základna
Použijte FTP a FileZilla k nahrávání souborů na servery jeden po druhém, neukládejte kód jinde než na produkčním serveru.
Projekt by měl mít vždy jeden kódový základ, to znamená, že veškerý kód pochází z jednoho Git úložiště. Servery (production, staging, test1, test2...) používají kód z větví jednoho společného úložiště. Tímto způsobem dosáhneme konzistence kódu.
2. Závislosti
Stáhněte si všechny knihovny ve složkách přímo do kořenového adresáře projektu. Proveďte aktualizace jednoduše přenesením nového kódu do složky s aktuální verzí knihovny. Nainstalujte všechny potřebné nástroje přímo na hostitelský server, kde běží dalších 20 služeb.
Projekt by měl mít vždy jasně srozumitelný seznam závislostí (závislostmi myslím i prostředí). Všechny závislosti musí být explicitně definovány a izolovány.
Vezměme si to jako příklad Hudební Skladatel и přístavní dělník.
Hudební Skladatel — správce balíčků, který umožňuje instalovat knihovny v PHP. Composer vám umožňuje specifikovat verze přísně nebo volně a explicitně je definovat. Na serveru může být 20 různých projektů a každý bude mít osobní seznam balíčků a knihoven nezávislý na druhém.
přístavní dělník — nástroj, který umožňuje definovat a izolovat prostředí, ve kterém bude aplikace běžet. Podle toho, stejně jako u skladatele, ale důkladněji, můžeme určit, s čím aplikace pracuje. Vyberte konkrétní verzi PHP, nainstalujte pouze balíčky nezbytné pro fungování projektu, aniž byste přidávali cokoli navíc. A co je nejdůležitější, bez zasahování do balíčků a prostředí hostitelského stroje a dalších projektů. To znamená, že všechny projekty na serveru běžící přes Docker mohou používat naprosto jakoukoli sadu balíčků a zcela odlišné prostředí.
3. Konfigurace
Ukládejte konfigurace jako konstanty přímo v kódu. Samostatné konstanty pro testovací server, samostatné pro produkci. Svažte provoz aplikace v závislosti na prostředí přímo v obchodní logice projektu pomocí konstrukcí if else.
Konfigurace - pouze tímto způsobem by se nasazení projektu mělo lišit. V ideálním případě by konfigurace měly být předány prostřednictvím proměnných prostředí (env vars).
To znamená, že i když uložíte několik konfiguračních souborů .config.prod .config.local a přejmenujete je v době nasazení na .config (hlavní konfigurace, ze které aplikace čte data) – nebude to správný přístup, protože v tomto případě budou informace z konfigurací veřejně dostupné všem vývojářům aplikací a data z produkčního serveru budou ohrožena. Všechny konfigurace musí být uloženy přímo v systému nasazení (CI/CD) a generovány pro různá prostředí s různými hodnotami nezbytnými pro konkrétní prostředí v době nasazení.
4. Služby třetích stran
Buďte striktně svázáni s prostředím, používejte různá připojení pro stejné služby v určitých prostředích.
Ve skutečnosti se tento bod silně překrývá s bodem o konfiguracích, protože bez tohoto bodu nelze vytvořit normální konfigurační data a obecně schopnost konfigurovat klesne na nulu.
Všechna připojení k externím službám, jako jsou frontové servery, databáze, služby ukládání do mezipaměti, musí být stejná jak pro místní prostředí, tak pro prostředí třetí strany / produkční prostředí. Jinými slovy, kdykoli mohu změnou připojovacího řetězce nahradit volání základny #1 základnou #2 bez změny kódu aplikace. Nebo, když se podíváme do budoucna, například při škálování služby, nebudete muset specifikovat připojení žádným zvláštním způsobem pro další cache server.
5. Sestavte, uvolněte, proveďte
Mít na serveru pouze konečnou verzi kódu, bez šance vydání vrátit zpět. Není třeba zaplňovat místo na disku. Každý, kdo si myslí, že může uvolnit kód do výroby s chybou, je špatný programátor!
Všechny fáze nasazení musí být od sebe odděleny.
Mít šanci vrátit se zpět. Vydávejte verze se starými kopiemi aplikace (již sestavenými a připravenými k boji) uloženými v rychlém přístupu, abyste v případě chyb mohli obnovit starou verzi. To znamená, že podmínečně existuje složka релизы a složku prouda po úspěšném nasazení a sestavení složky proud propojeno symbolickým odkazem na nové vydání, které se nachází uvnitř релизы s konvenčním názvem čísla vydání.
Zde si pamatujeme nasazení Blue-Green, které umožňuje nejen přepínat mezi kódem, ale také přepínat mezi všemi prostředky a dokonce i prostředími s možností vrátit vše zpět.
6. Procesy
Ukládejte data o stavu aplikace přímo v samotné aplikaci. Používejte relace v paměti RAM samotné aplikace. Využijte co nejvíce sdílení mezi službami třetích stran. Spolehněte se na to, že aplikace může mít pouze jeden proces a neumožňují škálování.
Pokud jde o relace, ukládejte data pouze do mezipaměti řízené službami třetích stran (memcached, redis), takže i když máte spuštěno 20 aplikačních procesů, kterýkoli z nich po přístupu do mezipaměti bude moci pokračovat v práci s klientem v stejný stav, ve kterém uživatel pracoval s aplikací v jiném procesu. S tímto přístupem se ukazuje, že bez ohledu na to, kolik kopií služeb třetích stran používáte, vše bude fungovat normálně a bez problémů s přístupem k datům.
7. Vazba portu
Pouze webový server by měl vědět, jak pracovat se službami třetích stran. Nebo ještě lépe, nainstalujte služby třetích stran přímo na webový server. Například jako modul PHP v Apache.
Všechny vaše služby musí být vzájemně přístupné prostřednictvím přístupu k nějaké adrese a portu (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), to znamená, že z nginx mohu přistupovat jak k php-fpm, tak k postgres a od php-fpm po postgres a nginx a vlastně z každé služby mám přístup k jiné službě. Tímto způsobem není životaschopnost služby vázána na životaschopnost jiné služby.
8. Paralelnost
Pracujte s jedním procesem, jinak se několik procesů nebude moci shodnout!
Nechte prostor pro změnu měřítka. Docker swarm je na to skvělý.
Docker Swarm je nástroj pro vytváření a správu klastrů kontejnerů jak mezi různými stroji, tak hromadou kontejnerů na stejném stroji.
Pomocí swarmu mohu určit, kolik zdrojů přidělím každému procesu a kolik procesů stejné služby spustím, a interní balancer, přijímající data na daném portu, je automaticky přidělí procesům. Když vidím, že se zatížení serveru zvýšilo, mohu přidat další procesy, čímž snížím zatížení určitých procesů.
9. Jednorázové použití
Pro práci s procesy a daty nepoužívejte fronty. Zabití jednoho procesu by mělo ovlivnit celou aplikaci. Pokud vypadne jedna služba, pokazí se všechno.
Každý proces a službu lze kdykoliv vypnout a nemělo by to mít vliv na ostatní služby (samozřejmě to neznamená, že služba bude nedostupná pro jinou službu, ale že se po této další služba nevypne). Všechny procesy musí být ukončeny s grácií, aby při jejich ukončení nedošlo k poškození dat a při příštím zapnutí systém fungoval správně. To znamená, že ani v případě nouzového ukončení by nemělo dojít k poškození dat (zde je vhodný transakční mechanismus, dotazy v databázi fungují pouze ve skupinách a pokud alespoň jeden dotaz ze skupiny selže nebo je proveden s chyba, pak žádný další dotaz ze skupiny nakonec ve skutečnosti selže).
10. Parita vývoje/provozu aplikací
Produkce, staging a lokální verze aplikace se musí lišit. Ve výrobě používáme framework Yii Lite a lokálně Yii, aby to ve výrobě fungovalo rychleji!
Reálně by všechna nasazení a práce s kódem měla být v téměř identickém prostředí (nemluvíme o fyzickém hardwaru). Kód by měl v případě potřeby nasadit do výroby také každý vývojový zaměstnanec a ne nějaké speciálně vyškolené oddělení devops, které jen díky speciální síle dokáže aplikaci pozvednout do výroby.
S tím nám pomáhá i Docker. Pokud jsou dodrženy všechny předchozí body, použití dockeru přivede proces nasazení prostředí jak na produkční, tak na lokální počítač k zadání jednoho nebo dvou příkazů.
11. Protokoly
Zapisujeme protokoly do souborů a databází! Nečistíme soubory a databáze z protokolů. Pojďme si koupit pevný disk s 9000 Peta bajty a je to v pořádku.
Všechny protokoly by měly být považovány za proud událostí. Samotná aplikace by se neměla podílet na zpracování protokolů. Protokoly by měly být odesílány buď na stdout, nebo by měly být odesílány prostřednictvím protokolu, jako je udp, aby práce s protokoly nezpůsobovala aplikaci žádné problémy. graylog je na to dobrý. Graylog přijímání všech logů přes udp (tento protokol nevyžaduje čekání na odpověď o úspěšném přijetí paketu) nijak nezasahuje do aplikace a zabývá se pouze strukturováním a zpracováním logů. Aplikační logika se pro práci s takovými přístupy nemění.
12. Administrativní úkoly
Chcete-li aktualizovat data, databáze atd., použijte samostatně vytvořený koncový bod v rozhraní API, jeho spuštění 2krát za sebou způsobí, že vše bude duplikováno. Ale nejste hloupí, dvakrát nekliknete a migraci nepotřebujeme.
Všechny úlohy správy by měly být prováděny ve stejném prostředí jako veškerý kód na úrovni vydání. To znamená, že pokud potřebujeme změnit strukturu databáze, tak to nebudeme dělat ručně změnou názvů sloupců a přidáním nových přes nějaké vizuální nástroje pro správu databáze. Pro takové věci vytváříme samostatné skripty – migrace, které se provádějí všude a ve všech prostředích stejně se společným a srozumitelným výsledkem. Pro všechny ostatní úkoly, jako je naplnění projektu daty, by měly být použity podobné metodiky.
Příklad implementace v PHP, Laravel, Laradock, Docker-Compose
PS Všechny příklady byly vytvořeny na MacOS. Většina z nich je vhodná i pro Linux. Uživatelé Windows, odpusťte mi, ale s Windows jsem dlouho nepracoval.
Představme si situaci, že na PC nemáme nainstalovanou žádnou verzi PHP a vůbec nic.
Nainstalujte nejnovější verze dockeru a docker-compose. (to se dá najít na internetu)
docker -v &&
docker-compose -v
1. Položte
git clone https://github.com/Laradock/laradock.git &&
ls
Ohledně Laradocku řeknu, že je to hodně super věc, která obsahuje spoustu nádob a pomocných věcí. Laradock jako takový bych ale bez úprav ve výrobě nedoporučoval kvůli jeho redundanci. Je lepší vytvářet si vlastní kontejnery na základě příkladů v Laradocku, bude to mnohem více optimalizované, protože nikdo nepotřebuje vše, co je tam současně.
2. Nakonfigurujte Laradock pro spuštění naší aplikace.
cd laradock &&
cp env-example .env
2.1. Otevřete v nějakém editoru adresář habr (nadřazená složka, do které je laradock naklonován). (V mém případě PHPStorm)
V této fázi projekt pouze pojmenujeme.
2.2. Spusťte obrázek pracovního prostoru. (Ve vašem případě bude vytvoření obrázků nějakou dobu trvat)
Workspace je speciálně připravený obrázek pro práci s frameworkem jménem vývojáře.
Do kontejneru vstupujeme pomocí
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Instalace Laravelu
composer create-project --prefer-dist laravel/laravel application
2.4. Po instalaci zkontrolujeme, zda byl vytvořen adresář s projektem a kill compose.
ls
exit
docker-compose down
2.5. Vraťme se k PHPStormu a v souboru .env nastavíme správnou cestu k naší aplikaci laravel.
3. Přidejte veškerý kód do Gitu.
Za tímto účelem vytvoříme úložiště na Githubu (nebo kdekoli jinde). Pojďme do adresáře habr v terminálu a spusťte následující 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
Zkontrolujeme, zda je vše v pořádku.
Pro pohodlí doporučuji použít nějaké vizuální rozhraní pro Git, v mém případě to je . (zde je odkaz na doporučení)
4. Startujeme!
Před spuštěním se ujistěte, že na portech 80 a 443 nic nevisí.
docker-compose up -d nginx php-fpm
Náš projekt se tedy skládá ze 3 samostatných služeb:
- nginx - webový server
- php-fpm - php pro příjem požadavků z webového serveru
- pracovní prostor - php pro vývojáře
V tuto chvíli jsme dosáhli toho, že jsme vytvořili aplikaci, která splňuje 4 body z 12, a to:
1. Codebase — veškerý kód je v jednom úložišti (malá poznámka: může být správné přidat docker do projektu laravel, ale to není důležité).
2. Závislosti - Všechny naše závislosti jsou explicitně zapsány v application/composer.json a v každém Dockerfile každého kontejneru.
3. Podpůrné služby — Každá ze služeb (php-fom, nignx, workspace) žije svým vlastním životem a je připojena zvenčí a při práci s jednou službou nebude ovlivněna druhá.
4. Procesy — každá služba je jeden proces. Každá ze služeb neudržuje vnitřní stav.
5. Portová vazba
docker ps
Jak vidíme, každá služba běží na svém vlastním portu a je přístupná všem ostatním službám.
6. Rovnoběžnost
Docker nám umožňuje vytvářet více procesů stejných služeb s automatickým vyvažováním zátěže mezi nimi.
Zastavme kontejnery a projeďme je vlajkou --měřítko
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Jak vidíme, byly vytvořeny kopie kontejneru php-fpm. Na práci s tímto kontejnerem nemusíme nic měnit. I nadále k němu přistupujeme na portu 9000 a Docker za nás reguluje zatížení mezi kontejnery.
7. Jednorázová - každý kontejner může být zabit bez poškození druhého. Zastavení nebo restartování kontejneru neovlivní provoz aplikace během následujících spouštění. Každý kontejner lze také kdykoli zvednout.
8. Parita vývoje/provozu aplikace - všechna naše prostředí jsou stejná. Spuštěním systému na serveru ve výrobě nebudete muset ve svých příkazech nic měnit. Vše bude založeno na Dockeru stejným způsobem.
9. Protokolování — všechny protokoly v těchto kontejnerech jdou do streamu a jsou viditelné v konzole Docker. (v tomto případě ve skutečnosti u jiných domácích nádob tomu tak nemusí být, pokud se o ně nestaráte)
docker-compose logs -f
Existuje však háček v tom, že výchozí hodnoty v PHP a Nginx také zapisují protokoly do souboru. Pro splnění 12 faktorů je to nutné deaktivovat zápis logů do souboru v konfiguracích každého kontejneru zvlášť.
Docker také poskytuje možnost posílat protokoly nejen na stdout, ale také na takové věci, jako je graylog, o kterém jsem se zmínil výše. A uvnitř graylogu můžeme s logy pracovat, jak chceme a naše aplikace si toho nijak nevšimne.
10. Administrativní úkoly — všechny administrativní úkony řeší laravel díky artisan tool přesně tak, jak by si tvůrci 12faktorové aplikace přáli.
Jako příklad uvedu, jak se provádějí některé příkazy.
Jdeme do kontejneru.
docker-compose exec workspace bash
php artisan list
Nyní můžeme použít libovolný příkaz. (upozorňujeme, že jsme nekonfigurovali databázi a mezipaměť, takže polovina příkazů nebude provedena správně, protože jsou navrženy pro práci s mezipamětí a databází).
11. Konfigurace a 12. Stavět, uvolnit, spustit
Tento díl jsem chtěl věnovat Blue-Green Deployment, ale ukázalo se, že je pro tento článek příliš obsáhlý. O tom napíšu samostatný článek.
Stručně řečeno, koncept je založen na systémech CI/CD jako Jenkins и Gitlab CI. V obou můžete nastavit proměnné prostředí spojené s konkrétním prostředím. Podle toho bude v této situaci bod c splněn Konfigurace.
A pointa o Stavět, uvolnit, spustit je řešeno vestavěnými funkcemi s názvem Potrubí.
Potrubí umožňuje rozdělit proces nasazení do mnoha fází se zvýrazněním fází sestavení, vydání a provedení. Také v Pipeline můžete vytvářet zálohy a vlastně cokoli. Jedná se o nástroj s neomezeným potenciálem.
Kód aplikace je na .
Při klonování tohoto úložiště nezapomeňte inicializovat submodul.
PS: Všechny tyto přístupy lze použít s jakýmikoli jinými nástroji a programovacími jazyky. Hlavní věc je, že podstata se neliší.
Zdroj: www.habr.com