Počnimo s malo teorije. Šta se desilo ?
Jednostavnim riječima, ovaj dokument je dizajniran da pojednostavi razvoj SaaS aplikacija, pomaže programerima i DevOps inženjerima da budu svjesni problema i praksi na koje se najčešće susreću u razvoju modernih aplikacija.
Dokument su kreirali programeri Heroku platforme.
Metodologija aplikacije dvanaest faktora može se primijeniti na aplikacije napisane na bilo kojem programskom jeziku i korištenjem bilo koje kombinacije pomoćnih usluga trećih strana (baze podataka, redovi poruka, keš memorije, itd.).
Ukratko o samim faktorima na kojima se zasniva ova metodologija:
- Codebase – Jedna kodna baza praćena izvorom – više implementacija
- Zavisnosti – Eksplicitno deklarisati i izolovati zavisnosti
- Konfiguracija – Sačuvajte konfiguraciju u toku rada
- Usluge trećih strana (Usluge podrške) – Tretirajte prateće usluge kao resurse koji se mogu priključiti
- Napravi, pusti, pokreni – Strogo odvojene faze izgradnje i pokretanja
- Procesi - Pokrenite aplikaciju kao jedan ili više procesa bez državljanstva
- Port binding – Izvoz usluga putem povezivanja porta
- Paralelizam – Skalirajte svoju aplikaciju s procesima
- Jednokratna upotreba – Maksimizirajte pouzdanost uz brzo pokretanje i elegantno gašenje
- Paritet razvoja aplikacija/operacije – Održavajte razvojno, scensko i proizvodno okruženje što sličnijim
- Logging - Tretirajte dnevnik kao tok događaja
- Poslovi administracije – Obavljanje zadataka administracije/upravljanja jednokratnim procesima
Za više informacija o 12 faktora, pogledajte sljedeće resurse:
- - obavezno pročitati
- - službeni prevod
- — novi pogled na 12 faktora kako bismo ih poboljšali.
Šta je plavo-zelena implementacija?
Plavo-zelena implementacija je način za isporuku aplikacije proizvodnja na način da krajnji klijent ne vidi nikakve promjene sa svoje strane. Drugim riječima, implementacija aplikacije sa nulom vreme zastoja.
Klasična šema BG Deploy izgleda kao na slici ispod.
- Na startu su 2 fizička servera sa potpuno istim kodom, aplikacijom, projektom, a tu je i ruter (balanser).
- Ruter inicijalno usmjerava sve zahtjeve na jedan od servera (zeleno).
- U trenutku kada trebate ponovo napraviti izdanje, cijeli projekat se ažurira na drugom serveru (plavo), koji trenutno ne obrađuje nijedan zahtjev.
- Nakon koda za plava server je potpuno ažuriran, ruteru je data naredba za prebacivanje zeleno na plavo server.
- Sada svi klijenti vide rezultat koda sa plavo server.
- neko vrijeme, zeleno server služi kao rezervna kopija u slučaju neuspješnog postavljanja na plavo server iu slučaju kvara i grešaka, ruter vraća korisnički tok zeleno server sa starom stabilnom verzijom, a novi kod se šalje na reviziju i testiranje.
- I na kraju procesa ažurira se na isti način zeleno server. I nakon ažuriranja, ruter se vraća na tok zahtjeva zeleno server.
Sve izgleda jako dobro i na prvi pogled ne bi trebalo biti nikakvih problema s tim.
Ali budući da živimo u modernom svijetu, opcija s fizičkim prebacivanjem, kako je naznačeno u klasičnoj shemi, ne odgovara nam. Zabilježite informacije za sada, na njih ćemo se vratiti kasnije.
Loš i dobar savjet
odricanje: Primjeri ispod pokazuju uslužne programe / metodologije koje koristim, možete koristiti apsolutno sve alternative sa sličnim funkcijama.
Većina primjera će se nekako ukrštati s web razvojem (kakvo iznenađenje), s PHP-om i Dockerom.
U pasusima ispod nalazi se jednostavan praktičan opis upotrebe faktora na određenim primjerima, ako želite dobiti više teorije o ovoj temi, pogledajte linkove iznad do originalnog izvora.
1. Codebase
Koristite FTP i FileZilla za otpremanje datoteka na servere jedan po jedan, nemojte pohranjivati kod nigdje osim na proizvodnom serveru.
Projekat uvijek treba imati jednu bazu koda, odnosno sav kod dolazi iz jednog ići spremište. Serveri (proizvodni, scenski, test1, test2 ...) koriste kod iz grana jednog zajedničkog spremišta. Tako postižemo konzistentnost koda.
2. Zavisnosti
Preuzmite sve biblioteke u fasciklama direktno u koren projekta. Ažurirajte jednostavno prenošenjem novog koda u fasciklu sa trenutnom verzijom biblioteke. Stavite sve potrebne uslužne programe direktno na host server gdje radi još 20 servisa.
Projekat uvek treba da ima jasno razumljivu listu zavisnosti (pod zavisnostima mislim i na okruženje). Sve zavisnosti moraju biti eksplicitno definisane i izolovane.
Kao primjer, uzmimo kompozitor и doker.
kompozitor - menadžer paketa koji vam omogućava da instalirate biblioteke u PHP-u. Composer vam daje mogućnost da striktno ili ne striktno specificirate verzije i da ih eksplicitno definirate. Na serveru može biti 20 različitih projekata, a svaki će imati privatnu listu paketa i biblioteka neovisno o drugom.
doker - uslužni program koji vam omogućava da definirate i izolujete okruženje u kojem će aplikacija raditi. Shodno tome, baš kao i sa composer-om, ali detaljnije, možemo odrediti s čime aplikacija radi. Odaberite određenu verziju PHP-a, instalirajte samo pakete neophodne za rad projekta, bez dodavanja bilo čega dodatnog. I što je najvažnije, bez uplitanja u pakete i okruženje glavnog računala i druge projekte. Odnosno, svi projekti na serveru koji rade kroz Docker mogu koristiti apsolutno bilo koji skup paketa i potpuno različita okruženja.
3. Konfiguracija
Čuvajte konfiguracije kao konstante direktno u kodu. Odvojene konstante za test server, odvojene za proizvodnju. Povežite rad aplikacije u zavisnosti od okruženja direktno u poslovnu logiku projekta koristeći if else konstrukcije.
Konfiguracije - ovo je jedina stvar koja bi se trebala razlikovati u implementaciji projekta (deployment). U idealnom slučaju, konfiguracije bi trebale biti proslijeđene kroz varijable okruženja (env vars).
Odnosno, čak i ako pohranite nekoliko konfiguracijskih datoteka .config.prod .config.local i preimenujete ih u vrijeme implementacije u .config (glavna konfiguracija iz koje aplikacija čita podatke) - ovo neće biti pravi pristup, jer u ovom slučaju će informacije iz konfiguracija biti javno dostupne svim programerima aplikacija i podaci sa proizvodnog servera će biti ugroženi. Sve konfiguracije moraju biti pohranjene direktno u sustavu za implementaciju (CI/CD) i generirane za različita okruženja s različitim vrijednostima potrebnim za određeno okruženje u trenutku implementacije.
4. Usluge trećih strana (Usluge podrške)
Čvrsto se povežite sa okruženjem, koristite različite veze za iste usluge u određenim okruženjima.
Zapravo, ova stavka je snažno ukrštana sa stavkom o konfiguracijama, jer bez prisustva ove stavke ne mogu se napraviti normalni konfiguracijski podaci i, općenito, mogućnost konfiguriranja će nestati.
Sve veze sa eksternim servisima kao što su serveri čekanja, baze podataka, usluge keširanja moraju biti iste i za lokalno okruženje i za okruženje treće strane/proizvodno okruženje. Drugim riječima, u bilo kojem trenutku mogu promijeniti niz veze da zamijenim pozive bazi #1 bazom #2 bez promjene koda aplikacije. Ili, gledajući unaprijed, na primjer, kada skalirate uslugu, ne morate naznačiti vezu na neki poseban način za dodatni keš server.
5. Napravi, pusti, pokreni
Zadržite samo konačnu verziju koda na serveru, bez šanse da vratite izdanje. Nema potrebe za popunjavanjem prostora na disku. Ko misli da može da pusti kod u proizvodnju sa greškom je loš programer!
Sve faze implementacije treba da budu odvojene jedna od druge.
Imajte priliku da se vratite. Napravite izdanja sa brzim pristupom starim kopijama aplikacije (već sastavljenim i spremnim za bitku), kako biste vratili staru verziju u slučaju grešaka. Odnosno, uslovno postoji folder izdaje i folder struja, a nakon uspješnog postavljanja i sklapanja, folder struja je povezan sa simboličkom vezom na novo izdanje koje se nalazi unutra izdaje sa uslovnim nazivom broja izdanja.
Ovdje se sjećamo Blue-Green implementacije, koja vam omogućava ne samo prebacivanje između koda, već i prebacivanje između svih resursa, pa čak i okruženja uz mogućnost da sve vratite.
6. Procesi
Pohranite podatke o stanju aplikacije direktno u samoj aplikaciji. Koristite sesije u RAM-u same aplikacije. Koristite što je više moguće podijeljeno između usluga trećih strana. Vezati na činjenicu da aplikacija može imati samo jedan proces i ne dozvoljava skaliranje.
Što se tiče sesija, pohranjujte podatke samo u predmemoriju koju kontroliraju usluge treće strane (memcached, redis), pa čak i ako imate pokrenutih 20 procesa aplikacije, bilo koji od njih koji pristupa kešu će moći nastaviti raditi s klijentom u istom stanju u kojoj je korisnik radio sa aplikacijom u drugom procesu. Ovakvim pristupom ispada da bez obzira koliko kopija usluga trećih strana koristite, sve će raditi ispravno i bez problema s pristupom podacima.
7. Port binding
Samo web server treba da zna kako da radi sa uslugama trećih strana. I bolje je općenito podizati usluge trećih strana direktno unutar web servera. Na primjer, kao PHP modul u Apacheu.
Svi vaši servisi moraju biti dostupni jedni drugima putem poziva na neku adresu i port (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), odnosno iz nginx-a mogu pristupiti i php-fpm i postgres, i sa php-fpm na postgres i nginx, i sa svake same usluge, mogu pristupiti drugom servisu. Dakle, zdravlje usluge nije vezano za zdravlje druge usluge.
8. Paralelizam
Radite s jednim procesom, a onda odjednom nekoliko procesa neće moći da se slažu jedan s drugim!
Ostavite opciju za skaliranje. Docker roj je odličan za ovo.
Docker Swarm je alat za kreiranje i upravljanje klasterima kontejnera između različitih mašina i gomile kontejnera na istoj mašini.
Koristeći roj, mogu odrediti koliko resursa ću dodijeliti za svaki proces i koliko procesa istog servisa ću pokrenuti, a interni balanser, koji prima podatke na datom portu, automatski će ih proxy procesima. Dakle, s obzirom da je opterećenje na serveru povećano, mogu dodati još procesa, čime se smanjuje opterećenje na određenim procesima.
9. Jednokratna upotreba
Nemojte koristiti redove za rad s procesima i podacima. Gašenje jednog procesa trebalo bi da utiče na rad cele aplikacije. Ako jedna usluga pokvari, sve će propasti.
Svaki proces i usluga se može isključiti u bilo koje vrijeme i to ne bi trebalo utjecati na druge servise (naravno, ne radi se o tome da će servis biti nedostupan drugom servisu, već da se drugi servis neće isključiti nakon ovog) . Sve procese treba prekinuti lagano, tako da kada se završe, to neće utjecati na podatke i da će sistem raditi ispravno sljedeći put kada se uključi. Odnosno, čak ni u slučaju prekida, podaci ne bi trebali biti pogođeni (mehanizam transakcije je ovdje prikladan, upiti bazi podataka rade samo u grupama, a ako barem jedan upit iz grupe nije uspio ili je izvršen s greškom , tada se nijedan drugi upit iz grupe na kraju zapravo ne izvršava).
10. Paritet razvoja aplikacija/operacije
Proizvodnja, faza i lokalna verzija aplikacije moraju se razlikovati. U proizvodnji imamo Yii Lite framework, a lokalno Yii, tako da radi brže u proizvodnji!
U stvarnosti, sve implementacije i rad sa kodom treba da budu u gotovo identičnom okruženju (ne govorimo o fizičkom hardveru). Također, svaki razvojni zaposlenik bi trebao biti u mogućnosti da implementira kod u produkciju ako je potrebno, a ne neko posebno obučeno devops odjeljenje, koje samo zbog posebne snage može podići aplikaciju u produkciji.
Docker nam također pomaže u tome. U skladu sa svim prethodnim tačkama, korišćenje docker-a će dovesti do procesa implementacije okruženja i na proizvodnoj i na lokalnoj mašini do unosa jedne ili dve komande.
11. Sječa (Dnevnici)
Pišemo logove u fajlove i bazu podataka! Ne čistimo datoteke i baze podataka iz dnevnika. Hajde da samo kupimo hard disk za 9000 Peta bajtova i normi.
Sve evidencije treba posmatrati kao tok događaja. Sama aplikacija ne treba da se bavi obradom dnevnika. Dnevnici bi se trebali izdati ili na stdout ili poslati preko protokola kao što je udp, tako da aplikacija ne stvara probleme sa evidencijama. Graylog dobro radi za ovo. Graylog prihvata sve zapise putem udp-a (ovaj protokol ne zahtijeva čekanje odgovora o uspješnom prijemu paketa) ni na koji način ne ometa aplikaciju i samo je uključen u strukturiranje i obradu dnevnika. Logika aplikacije se ne mijenja da bi radila s ovim pristupima.
12. Poslovi administracije
Za ažuriranje podataka, baze podataka itd., koristite posebno kreiranu krajnju točku u api-ju, čije će izvršenje 2 puta za redom dovesti do činjenice da se sve može duplicirati umjesto vas. Ali niste budale, nećete kliknuti 2 puta i ne trebaju nam migracije.
Svi administrativni zadaci moraju se izvoditi u istom okruženju kao i sav kod, na razini izdanja. Odnosno, ako trebamo promijeniti strukturu baze podataka, onda to nećemo raditi ručno mijenjajući nazive kolona i dodajući nove putem neke vrste vizualnih alata za upravljanje bazom podataka. Za takve stvari kreiramo zasebne skripte - migracije koje se izvode svuda i u svim okruženjima sa istim zajedničkim i razumljivim rezultatom. Za sve ostale zadatke, kao što je popunjavanje projekta podacima, treba primijeniti slične metodologije.
Primjer implementacije u PHP, Laravel, Laradock, Docker-Compose
PS Svi primjeri su napravljeni na MacOS-u. Većina će raditi i za Linux. Izvinite, korisnici Windows-a, ali nisam dugo radio sa Windows-om.
Zamislite situaciju da na našem računaru nemamo instaliranu nijednu verziju PHP-a i ništa.
Instalirajte najnovije verzije docker-a i docker-compose. (ovo se može naći na internetu)
docker -v &&
docker-compose -v
1. Stavili smo
git clone https://github.com/Laradock/laradock.git &&
ls
Što se tiče Laradocka, reći ću da je ovo vrlo kul stvar, u kojoj se skuplja puno kontejnera i pomoćnih stvari. Ali koristiti Laradock kao takav bez modifikacija u proizvodnji - ne bih ga preporučio zbog njegove suvišnosti. Bolje je kreirati svoje kontejnere na osnovu primjera u Laradock-u, tako da će biti mnogo optimizacije, jer nikome nije potrebno sve što postoji u isto vrijeme.
2. Konfiguriranje Laradocka za rad naše aplikacije.
cd laradock &&
cp env-example .env
2.1. Otvorite habr direktorij (nadređeni folder u koji je kloniran laradock) u bilo kojem uređivaču. (U mom PHPStorm slučaju)
U ovoj fazi stavljamo samo naziv projekta.
2.2. Pokrećemo sliku radnog prostora. (U vašem slučaju, slike će se razvijati neko vrijeme)
Radni prostor je posebno pripremljena slika za rad sa okvirom u ime programera.
Uđite u kontejner sa
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Instaliranje Laravela
composer create-project --prefer-dist laravel/laravel application
2.4. Nakon instalacije, provjeravamo da li je direktorij sa projektom kreiran i ukidamo compose.
ls
exit
docker-compose down
2.5. Vraćamo se na PHPStorm i postavljamo ispravnu putanju do naše laravel aplikacije u .env datoteci.
3. Dodajte sav kod u Git.
Da bismo to učinili, kreirat ćemo spremište na Githubu (ili bilo gdje drugdje). Idemo u direktorij habr u terminalu i izvršimo sljedeći kod.
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
Provjeravamo da li je sve u redu.
Radi praktičnosti, preporučujem da koristite neku vrstu vizuelnog interfejsa za Git, u mom slučaju ovo jeste . (link za preporuke ovdje)
4. Pokreni!
Prije početka, uvjerite se da ništa ne visi na portovima 80 i 443.
docker-compose up -d nginx php-fpm
Dakle, naš projekat se sastoji od 3 odvojene usluge:
- nginx - web server
- php-fpm - php za primanje zahtjeva sa web servera
- radni prostor - php za programere
Trenutno smo postigli da smo kreirali aplikaciju koja odgovara 4 tačke od 12, i to:
1. Codebase - sav kod je u jednom spremištu (mala napomena: možda je ispravno uneti docker unutar laravel projekta, ali to nije važno).
2. Zavisnosti - Sve naše zavisnosti su eksplicitno napisane u application/composer.json iu svakom Dockerfileu svakog kontejnera.
3. Usluge trećih strana (Usluge podrške) - Svaki od servisa (php-fom, nigx, workspace) živi svoj život i povezan je spolja i kada se radi sa jednim servisom, drugi neće biti pogođen.
4. Procesi Svaka usluga je jedan proces. Svaka usluga ne pohranjuje interno stanje.
5. Port binding
docker ps
Kao što vidimo, svaki servis radi na svom portu i dostupan je svim ostalim servisima.
6. Paralelizam
Docker nam omogućava da pokrenemo više procesa istih usluga sa automatskim balansiranjem opterećenja između njih.
Zaustavite kontejnere i započnite ih zastavicom --skala
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Kao što vidimo, php-fpm kontejner ima kopije. Ne moramo ništa mijenjati u radu sa ovim kontejnerom. Takođe nastavljamo da mu pristupamo na portu 9000, a Docker za nas reguliše opterećenje između kontejnera.
7. Jednokratna upotreba - svaki kontejner može biti ubijen bez povrede drugog. Zaustavljanje ili ponovno pokretanje kontejnera neće utjecati na rad aplikacije pri narednim pokretanjima. Svaki kontejner se također može podići u bilo koje vrijeme.
8. Paritet razvoja aplikacija/operacije Sva naša okruženja su ista. Pokretanjem sistema na serveru u proizvodnji, ne morate ništa mijenjati u svojim naredbama. Sve će biti bazirano na Dockeru na isti način.
9. Logging - svi zapisi u ovim kontejnerima idu u tok i vidljivi su u Docker konzoli. (u ovom slučaju, zapravo, s drugim domaćim posudama, možda neće biti slučaj ako ne vodite računa o tome)
docker-compose logs -f
Ali, postoji kvaka u tome što zadane vrijednosti u PHP-u i Nginx-u također pišu dnevnike u datoteku. Da biste ispunili 12 faktora, trebate prekinuti vezu pisanje dnevnika u datoteku u konfiguracijama svakog kontejnera posebno.
Docker takođe pruža mogućnost slanja dnevnika ne samo na stdout, već i na stvari poput sivog dnevnika, koje sam spomenuo gore. A unutar graylog-a, možemo raditi s logovima kako želimo i naša aplikacija to neće primijetiti ni na koji način.
10. Poslovi administracije - svi administrativni zadaci su riješeni laravelom zahvaljujući zanatskom alatu upravo onako kako bi kreatori 12 faktorske aplikacije željeli.
Kao primjer, pokazat ću kako se neke komande izvršavaju.
Idemo u kontejner.
docker-compose exec workspace bash
php artisan list
Sada možemo koristiti bilo koju komandu. (Napominjemo da nismo podesili bazu podataka i keš memoriju, tako da polovina komandi neće biti ispravno izvršena, jer su dizajnirane da rade sa kešom i bazom podataka).
11. Konfiguracije i 12. Napravi, pusti, pokreni
Htio sam ovaj dio posvetiti plavo-zelenoj implementaciji, ali se pokazalo da je previše detaljan za ovaj članak. O tome ću napisati poseban članak.
Ukratko, koncept je baziran na CI/CD sistemima kao što su Jenkins и Gitlab CI. U oba, možete postaviti varijable okruženja povezane sa određenim okruženjem. Shodno tome, u ovom scenariju, tačka c Konfiguracije.
I poenta o tome Napravi, pusti, pokreni riješeno ugrađenim funkcijama u oba pomoćna programa pod nazivom cjevovod.
cjevovod omogućava vam da podijelite proces implementacije u više faza, naglašavajući faze sklapanja, puštanja i izvršenja. Također u Pipeline-u možete kreirati sigurnosne kopije, i zaista bilo šta. Ovaj alat ima neograničen potencijal.
Kôd aplikacije je uključen .
Ne zaboravite da inicijalizirate podmodul kada klonirate ovo spremište.
PS: Svi ovi pristupi se mogu koristiti sa bilo kojim drugim uslužnim programima i programskim jezicima. Glavna stvar je da se suština ne razlikuje.
izvor: www.habr.com