Rakenduste arendamine ja Blue-Green deployment, tuginedes The Twelve-Factor App metoodikale, koos näidetega php ja dockeris.

Alguses natuke teooriat. Mis on Kaksteistfaktoriline rakendus?

Lihtsate sõnadega, see dokument on mõeldud SaaS rakenduste arendamise lihtsustamiseks, aidates arendajaid ja DevOps insenere probleemide ja praktikatega, mis on sageli esinenud kaasaegsete rakenduste arendamisel.

Dokument on koostatud Heroku platvormi arendajate poolt.

Kaksteistfaktoriline metodoloogia (The Twelve-Factor App) on rakendatav mis tahes programmeerimiskeeles kirjutatud rakendustele ja erinevatele kolmandate osapoolte teenuste kombinatsioonidele (backing services) (andmebaasid, sõnumijärjekorrad, vahemälu jne).

Lühidalt metodoloogia aluseks olevatest teguritest:

1. Koodibaas – Üks koodibaas, mida hallatakse versioonihaldussüsteemis – mitu rakendust
2. Sõltuvused – Tehke sõltuvused selgelt teatavaks ja isoleerige need
3. Konfiguratsioon – Hoidke konfigureerimine käitamisrežiimis
4. Kolmandate osapoolte teenused (Backing Services) – Kaaluge kolmandate osapoolte teenuseid (backing services) ühendatavate ressurssidena
5. Kogumine, väljalase, täitmine – Rangelt eristage kogumise ja täitmise etappe
6. Protsessid – Käivitage rakendus kui üks või mitu seisundit mittehoidvat protsessi (stateless)
7. Portide sidumine (Port binding) – Ekspordige teenuseid portide sidumise kaudu
8. Paralleelsus – Skaalake rakendust protsesside abil
9. Utiliseeritavus (Disposability) – Maksimeerige usaldusväärsust kiire käivitamise ja korrektse lõpetamise abil
10. Rakenduse arendamise/operatiivsete tingimuste pariteet – Hoidke arenduse, vahepealse juurutamise (staging) ja tootmise (production) keskkonnad maksimaalselt sarnased
11. Logimine (Logs) – Vaadake logi kui sündmuste voogu
12. Haldusülesanded – Tehke haldus-/juhtimisülesandeid ühekordsete protsesside kaudu

Rohkem teavet 12 teguri kohta leiate järgmistest allikatest:

• Ametlik allikas — kohustuslik lugemine
• Artikkel habr'il. Kaksteist tegurit — The Twelve-Factor App — ametlik tõlge
• Artikkel habr'il. 7 puuduvat tegurit 12 Factor App lähenemises — värske vaade 12 tegurile nende täiustamise eesmärgil.

Mis on Blue-Green juurutamine?

Blue-Green juurutamine on viis rakenduse tarnimiseks tootmisse nii, et lõppkasutaja ei näe oma küljelt mingeid muudatusi. Teisisõnu, rakenduse juurutamine nulliga seisaku.

Klassikaline BG Deploy skeem näeb välja nagu alloleval pildil.

• Alguses on 2 füüsilist serverit, millel on täpselt sama kood, rakendus, projekt ja seal on ruuter (tasakaalustaja).
• Ruuter suunab algselt kõik päringud ühe serveri peale (roheline).
• Hetkel, kui on vaja taas välja anda, värskendatakse kogu projekt teisele serverile (sinine), mis praegu ei töötle mingeid päringuid.
• Pärast seda, kui kood on sinises serveris täielikult värskendatud, antakse ruuterile käsk vahetada roheliselt järgnevaga sinine serverilt.
• Nüüd näevad kõik kliendid koodi tööd sinisest serverist.
• Mõnda aega, roheline server toimib varukoopiana, kui juurutamine ebaõnnestub sinine serverisse ja ebaõnnestumise korral, ruuter suunab kasutajate voolu tagasi roheline serverisse vana stabiilse versiooniga, samas kui uus kood saadetakse täiendavaks töötlemiseks ja testimiseks.
• Ja protsessi lõpuks värskendatakse samuti roheline server. Ja pärast selle uuendamist suunab ruuter päringute voogu tagasi roheline serverilt.

See kõik näeb välja väga hea ja esmapilgul ei tohiks sellega olla mingeid probleeme.
Kuid kuna elame tänapäeva maailmas, siis füüsilise lülitamise variant, nagu on näidatud klassikalises scheemis, ei sobi meile. Salvestage teave hetkel, me tuleme selle juurde hiljem tagasi.

Halvad ja head nõuanded

Märkus: Allpool on toodud tööriistad / metoodikad, mida kasutan mina, saate kasutada mistahes alternatiive, mis omavad sarnaseid funktsioone.

Enamik näiteid kattub sel või teisel viisil veebiarendusega (see on üllatus), PHP ja Dockeriga.

Allpool on lihtne praktiline kirjeldus faktorite kasutamisest teatud näidetes; kui soovite selle teema kohta rohkem teooriat, viidake kõrgemal linkidele esialgsele allikale.

1. Koodibaas

Kasutage FTP-d ja FileZillat, laadides faile serveritesse üksikute kaupa, ärge hoidke koodi kusagil mujal kui tootmisserveris.

Projektis peab alati olema ühtne koodibaas, mis tähendab, et kogu kood tuleb ühest allikast. Git repositoorium. Serverid (tootmine, etapp, test1, test2 …) kasutavad koodi ühest ühest repositooriumist. Nii saavutame koodi järjepidevuse.

2. Sõltuvused

Laadige kõik raamatukogud kaustades otse projekti juurese. Uuendusi tehke lihtsalt uue koodi kopeerimisega praeguse versiooni raamatukogu kausta. Paigaldage kõik vajalikud utiliidid otse hostiserverisse, kus töötab veel 20 teenust.

Projekt peab alati olema selgelt arusaadav sõltuvuste loetelu (sõltuvustena mõistan ma ka keskkonda). Kõik sõltuvused peavad olema selgelt määratletud ja isoleeritud.
Näitena võtame Composer ja Docker.

Composer — pakihaldur, mis võimaldab PHP raamatukogusid installida. Composer võimaldab täpselt või mitte täpselt versioone määrata ja neid selgelt kindlaks teha. Serveris võib olla 20 erinevat projekti ja igal ühel on oma isiklik paketide ja raamatukogude loetelu, mis ei sõltu teistest.

Docker — utiliit, mis võimaldab määrata ja isoleerida keskkonda, kus rakendus töötab. Nii nagu composeriga, saame nüüd veelgi tõhusamalt määrata, millega rakendus töötab. Valida kindel PHP versioon, paigaldada ainult projekti tööks vajalikud paketid, lisamata midagi üleliigset. Ja mis kõige tähtsam, mitte kattuda hostimasina ja teiste projektide pakettide ning keskkonnaga. See tähendab, et kõik serveris töötavad Dockeris projektid saavad kasutada absoluutselt igasuguseid pakette ja täiesti erinevat keskkonda.

3. Konfigureerimine

Salvestage konfigureerimised konstantide kaudu otse koodis. Eraldi konstantid testserveri jaoks, eraldi tootmisserveri jaoks. Siduge rakenduse töö sõltuvus keskkonnast otse projekti äri loogikas, kasutades if else konstruktsioone.

Konfiguratsioonid — on ainus, mille poolest projektide kasutuselevõtud (deployment) peaksid erinema. Ideaalis tuleks konfiguratsioonid edastada keskkonnamuutujate (env vars) kaudu.

Isegi kui hoiate mitut konfiguratsioonifaili .config.prod .config.local ja nimetate need juurutamise hetkel ümber .config-iks (peamine konfiguraaf, millest rakendus andmeid loeb) — see pole õige lähenemine, sest sellisel juhul on konfiguratsioonide teave kõigile rakenduse arendajatele kergesti kätte saadav ning tootmisserveri andmed võivad olla ülekantavad. Kõik konfiguratsioonid peaksid olema salvestatud otse juurutussüsteemi (CI/CD) ja genereeritud erinevate keskkondade jaoks erinevate väärtustega, mis on konkreetses keskkonnas vajalikud juurutamise hetkel.

4. Kolmandate osapoolte teenused (Backing Services)

Siduge rangelt keskkonnaga, kasutage erinevaid ühendusi samadele teenustele teatud keskkondades.

Tegelikult kattub see punkt tugevalt konfiguratsioonide punktiga, kuna ilma selle punktita ei ole võimalik luua korralikke konfiguratsioonandmeid ja üldse konfigureerimise võimalus kaob.

Kõik ühendused välistesse teenustesse, nagu järjekorraserverid, andmebaasid, vahemäluteenused, peaksid olema ühtsed nii kohaliku keskkonna kui ka välise / tootmiskeskkonna jaoks. Teisisõnu, ma võin igal hetkel muuda ühendusstringi, asendades juurdepääsu andmebaasile #1 andmebaasiga #2 ilma rakenduskoodi muutmata. Näiteks, kui teenust skaleeritakse, ei pea te eriliselt seadma ühendust lisavarustuse vahemäluga.

5. Kogumine, vabastamine, täitmine

Serveris peaks olema ainult koodi lõppversioon, ilma võimaluseta tagasi minna varasemale vabastusele. Ärge külvake ketta ruumi. Kes arvab, et võib viga sisaldava koodi tootmisse saata, pole hea programmeerija!

Kõik juurutamisetapid peaksid olema omavahel eraldatud.

Olge võimalus tagasi minna. Tehke vabastusi, hoides kiire juurdepääsuga vanu rakenduste koopiaid (juba kokku pandud ja lahinguks valmis), et vajadusel vana versioon taastada. Nii et tinglikult on olemas kaust releases ja kaust current, ja pärast edukat juurutamist ja kogumist kaust current seondub uue väljaande sümboolse lingiga, mis asub sees releases tingimusliku nimega väljaande numbrit.

Siin tuleme me tagasi Blue-Green deployment'i juurde, mis võimaldab mitte ainult vahetada koodi vahel, vaid ka vahetada kõiki ressursse ja isegi keskkondi, võimaldades kõik tagasi tagasi pöörata.

6. Protsessid

Hoidke rakenduse olekud otse rakenduses. Kasutage rakenduse enda RAM-i seansse. Kasutage nii palju jagatavaid ressursse kui võimalik. Oletage, et rakendusel võib olla ainult üks protsess ja vältige skaleerimise võimalust.

Seoses sessioonidega salvestage andmeid ainult kolmandate osapoolte hallatavasse vahemälu (memcached, redis). Sel viisil, isegi kui teil on käivitatud 20 rakenduse protsessi, saab ükskõik milline neist, pöördudes vahemälu poole, jätkata kliendiga töötamist samas olekus, milles kasutaja oli, töötades rakenduses teises protsessis. Sellise lähenemise korral toimivad kõik kolmandate osapoolte teenused probleemideta, olenemata nende koopiate arvust.

7. Pordide sidumine (Port binding)

Ainult veebiserver peaks teadma, kuidas kolmandate osapoolte teenustega töötada. Veel parem on tõsta kolmandate osapoolte teenused otse veebiserveri sisse, näiteks nagu PHP moodul Apache's.
Kõik teie teenused peaksid olema omavahel kergesti kättesaadavad, pöördudes mingisuguse aadressi ja pordi poole (localgost:5432, localhost:3000, nginx:80, php-fpm:9000). See tähendab, et nginx-is saan ma juurde pääseda nii php-fpm-ile kui postgres'ile, php-fpm-ist postgres'ile ja nginx'ile ning igast teenusest saan ma pöörduda teise teenuse poole. Nii jääb teenuse elujõud sõltumatuks teise teenuse elujõudest.

8. Paralleelsus

Töötage ühe protsessiga, et vältida mitme protsessi koostöötlemise probleeme!

Jätke võimalus skaleerimiseks. Docker Swarm sobib selleks suurepäraselt.
Docker Swarm on tööriist konteineri klastrite loomiseks ja haldamiseks erinevate masinate vahel või paljude konteinerite korraldamiseks ühel masinal.

Swarm'i kasutades saan määrata, kui palju ressursse eraldan igale protsessile ja kui palju sama teenuse protsesse käitama hakkan, ning sisemine koormuse tasakaalustaja, mis võtab andmeid määratud sadamast, suunab need automaatselt protsessidele. Nii et kui näen, et serveri koormus on kasvanud, saan lisada rohkem protsesse, vähendades seeläbi teatud protsesside koormust.

9. Hävitamisvõime (Disposability)

Ärge kasutage järjekordi protsesside ja andmete töötlemiseks. Ühe protsessi tapmine peaks mõjutama kogu rakenduse tööd. Kui üks teenus kukub, kukub kogu süsteem.

Iga protsess ja teenus võivad igal hetkel välja lülitada, ilma et see mõjutaks teisi teenuseid (loomulikult ei ole mõte selles, et teenus on millegipärast teisele teenusele kergesti kätte saadav, vaid et teine teenus ei lülitu koos sellega välja). Kõik protsessid peaksid lõpetama sujuvalt, nii et nende lõpetamine ei kahjusta andmeid ja süsteem töötab järgmisel sisselülitamisel korralikult. Seega ei tohiks isegi kriitilise katkestamise korral andmed kahjustada minna (siin sobib tehingumehhanism, kus andmebaasi päringud toimivad ainult gruppidena; kui ükski päring grupist ei toimi või toimib vea korral, siis ei toimu tegelikult ka ühtegi teist päringut grupist).

10. Rakenduse arendamise/töö pariteet

Toodang, etapp ja rakenduse kohalik versioon peavad olema erinevad. Toode kasutab Yii Lite raamistikku, kohapeal aga Yii, et tootmine töötaks sujuvamalt!

Tegelikult peaks kõik koodide juurutamised ja töötamine toimuma peaaegu identses keskkonnas (ei räägita füüsilisest riistvarast). Samuti peaks iga arendusmeeskonna liige suutma koodi vajadusel toota, mitte mingisugune spetsiaalselt koolitatud devops osakond, mis suudab rakendust tootmises tõsta ainult tänu erioskusele.

Sellega aitab meid ka Docker. Kui järgime kõiki eelnevaid punkte, vähendab docker keskkonna juurutamise protsessi nii tootmises kui ka kohalikul masinal ühe-kahte käsku sisestamiseni.

11. Logimine (Logs)

Logid kirjutame failidesse ja andmebaasi! Failidest ja andmebaasist logisid ei puhasta. Ostame lihtsalt 9000 petabaiti kõvaketta ja kõik.

Logis tuleb käsitleda kui sündmuste voogu. Rakendus ei tohi tegeleda logide töötlemisega. Logid peaksid olema kas stdout'is või saadetud protokolli nagu udp kaudu, et logide töötlemine ei tekitaks rakenduses probleeme. Selleks sobib hästi graylog. Graylog, mis võtab kõik logid vastu udp kaudu (selle protokolli puhul ei pea ootama kinnitust pakettide edastamise kohta), ei sega rakendust ja tegeleb ainult logide struktureerimise ja töötlemisega. Rakenduse loogika ei muutu, kui kasutatakse selliseid lähenemisviise.

12. Administreerimise ülesanded

Andmete, andmebaasi jne uuendamiseks kasutage eraldi loodud lõpp-punkti API-s, mille täitmine kaks korda järjest toob kaasa võimaliku dubleerimise. Kuid te ju ei ole tobedad, et vajutada seda kaks korda, ja migratsioonid pole meile vajalikud.

Kõik haldamise ülesanded peaksid toimuma samas keskkonnas kui kogu kood, väljaande tasemel. See tähendab, et kui peame andmebaasi struktuuri muutma, ei tee me seda käsitsi, muutes veergude nimesid ja lisades uusi mõne visuaalse andmebaasi haldustööriista kaudu. Selliste asjade jaoks loome eraldi skriptid — migratsioonid, mis käivitatakse igal pool ja kõigis keskkondades ühtlaselt ja arusaadava tulemusega. Kõigi teiste ülesannete puhul, nagu projekti andmetega täitmine, tuleb rakendada sarnaseid metoodikaid.

PHP, Laravel, Laradock, Docker-Compose'i rakenduse näide

P.S. Kõik näited tehti MacOS-is. Enamik sobib ka Linuxile. Windowsi kasutajad, palun vabandage, aga ma pole pikka aega Windowsiga töötanud.

Kujutame ette olukorda, kus meie PC-l ei ole installitud ühtegi PHP versiooni ja tegelikult ei ole seal midagi.
Paigaldame docker ja docker-compose uusimad versioonid. (seda saab internetist leida)

docker -v && 
docker-compose -v

1. Paigaldame Laradock

git clone https://github.com/Laradock/laradock.git && 
ls

Laradock on tõesti suurepärane platvorm, kus on kogutud palju konteinerite ja abivahendeid. Kuid ma ei soovitaks kasutada Laradock'i tootmisrežiimis ilma muudatusteta, kuna see on liialt mahukas. Paremini on luua oma konteinerid tuginedes Laradock'i näidetele, mis võimaldab rohkem optimeerimist, sest kõike sealset korraga keegi ei vaja.

2. Konfigureerime Laradock'i meie rakenduse tööks.

cd laradock && 
cp env-example .env

2.1. Ava habr kataloog (ülemine kaust, kuhu laradock klooniti) mõne redigeerija abil. (Minu puhul on see PHPStorm)

Sel hetkel määrame ainult projekti nime.

2.2. Käivitame workspace'i konteineri. (Teie juhtumi puhul hakkavad pildid mõnda aega ehitama)
Workspace on spetsiaalselt ettevalmistatud pilt arendaja poolt raamistiku kasutamiseks.

Siseneme konteinerisse järgmise käsuga

docker-compose up -d workspace && 
docker-compose exec workspace bash

2.3. Paigaldame Laravel'i

composer create-project --prefer-dist laravel/laravel application

2.4. Pärast paigaldamist kontrollime, kas projektikaust on loodud, ja peatame compose'i.

ls
exit
docker-compose down

2.5. Oleme tagasi PHPStormis ja seadistame meie laravel rakenduse õiged teed .env failis.

3. Lisame kogu koodi Git'i.

Selleks loome Githubis (või mõnes muus kohas) hoidla. Liigume terminalis habr katalooge ja täidame järgmise koodi.

echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "esimene commit"
git remote add origin git@github.com:nzulfigarov/habr-12factor.git # siin on link teie hoidlasse
git push -u origin master
git status

Kontrollime, kas kõik on korras.

Mugavuse huvides soovitan kasutada mingit visuaalset liidest Git’i jaoks, minu puhul on see GitKraken. (siin on suunamislink)

4. Käivitame!

Enne käivitamist veenduge, et 80 ja 443 pordil ei oleks midagi üles riputatud.

docker-compose up -d nginx php-fpm

Seega meie projekt koosneb 3 eraldi teenusest:

• nginx — veebiserver
• php-fpm — php, et vastu võtta päringuid veebiserverilt
• workspace — php arendajale

Praeguseks hetkeks oleme saavutanud, et oleme loonud rakenduse, mis vastab juba 4 punktile 12-st, nimelt:

1. Koodibaas — kõik kood on ühes hoidlas (väike märkuse koht: võib-olla oleks õigem tuua docker laraveli projekti sisse, kuid see ei ole põhimõtteliselt oluline).

2. Sõltuvused — Kõik meie sõltuvused on selgelt määratletud failis application/composer.json ja iga konteineri Dockerfile'is.

3. Kolmandate osapoolte teenused (Backing Services) — Iga teenus (php-fpm, nginx, workspace) elab oma elu ja on väliselt ühendatud; töötades ühe teenusega, ei mõjuta see teisi.

4. Protsessid — Iga teenus on üks protsess. Iga teenus ei säilita sisesetstate.

5. Portide sidumine (Port binding)

docker ps

Kuidas näeme, on iga teenus üles seatud oma porti ja on ligipääsetav kõigile teistele teenustele.

6. Paralleelsus

Docker võimaldab meil tõsta mitu protsessi samadest teenustest automaatse koormuse tasakaalustamisega nende vahel.

Lõpetame konteinerid ja käivitame need lipu kaudu —scale

docker-compose down && 
docker-compose up -d --scale php-fpm=3 nginx php-fpm

Kuidas näeme, on php-fpm konteineril loodud koopiad. Me ei pea selle konteineri töö käigus midagi muutma. Jätkame temaga ühendust porti 9000 kaudu, samas kui Docker reguleerib meie eest koormust konteinerite vahel.

7. Utiliseeritavus (Disposability) — iga konteineri saab lõpetada teisele kahju tegemata. Kêtesed või taaskäivitamine konteiner ei mõjuta rakenduse tööd järgmiste käivituste ajal. Iga konteinerit saab samuti igal ajal tõsta.

8. Rakenduse arendamise/operatiivsete tingimuste pariteet — kõik meie keskkonnad on ühesugused. Kui käitate süsteemi serveris tootmises, ei pea te oma käskudes midagi muutma. Kõik põhineb täpselt Dockeril.

9. Logimine (Logs) — kõik logid nendes konteinerites suunduvad voogu ja on nähtavad Dockeri konsoolis. (antud juhul, tegelikult, teiste isetehtud konteinerite puhul võib see olla erinev, kui te ei hoolitse selle eest)

 docker-compose logs -f

Aga siin on probleem, et PHP ja Nginxi vaikeseaded kirjutavad samuti logisid faili. 12-faktori põhimõttete järgimiseks on vajalik välja lülitada logide kirjutamine faili iga konteineri konfiguratsioonis eraldi.

Samuti pakub docker võimalust suunata logid mitte ainult stdouti, vaid ka sellistesse asjadesse nagu graylog, millest ma eelpool rääkisin. Graylogis saame logidega operatiivida kuidas iganes soovime ja meie rakendus ei märka seda.

10. Haldusülesanded — kõik haldusülesanded lahendab Laravel tänu artisan tööriistale just nii, nagu 12-faktori rakenduse loojaid soovisid.

Näitena näitan, kuidas teostatakse mõned käsklused.
Siseneme konteinerisse.

 
docker-compose exec workspace bash
php artisan list

Nüüd saame kasutada igat käsku. (pange tähele, et me ei ole andmebaasi ja vahemälu seadistanud, mistõttu poolest käskudest ei tööta õigesti, kuna need on mõeldud tööks vahemälu ja andmebaasiga).

11. Konfiguratsioonid ja 12. Kogumine, väljalase, täitmine

Selle osa tahan pühendada Blue-Green Deployment'ile, kuid see osutus selle artikli jaoks liiga ulatuslikuks. Kirjutan sellest eraldi artiklis.

Lühidalt öeldes põhineb kontseptsioon CI/CD süsteemidel nagu Jenkins ja Gitlab CI. Nii selles kui ka teises saab seada keskkonnaga seotud keskkonnamuutujad. Vastavalt sellele toimub punktide täitmine Konfiguratsioonidega.

Ja punkt, mis puudutab Kogumine, väljalase, täitmine lahendatakse mõlemas utiliidis sisseehitatud funktsioonidega, mida nimetatakse Pipeline.

Pipeline mis võimaldab jagada deploymendi protsessi mitmeks etapiks, tuues esile ehituse, välja andmise ja täitmise etapid. Samuti saate Pipeline'is luua varukoopiaid ja teha üldiselt kõike. See tööriist omab piiramatu potentsiaali.

Rakenduse kood asub Github.
Ärge unustage submodule kloonimisel initsialiseerida.

P.S.: Tooted, mis puudutavad neid lähenemisi, on rakendatavad ka teiste utiliidide ja programmeerimiskeeltega. Peaasi, et sisu ei erineks.

Allikas: habr.com