Rakenduste arendamine ja Blue-Green tellimine, tuginedes The Twelve-Factor App metoodikale koos php ja docker'i näidetega

Alustuseks natuke teooriat. Mis on The Twelve-Factor App?

Lihtsalt öeldes on see dokument, mis on mõeldud SaaS rakenduste arendamise lihtsustamiseks, aidates arendajatel ja DevOps inseneridel teadlikuks saada probleemidest ja praktikatest, millega nad sageli kokku puutuvad modernsete rakenduste arendamisel.

Dokument on koostatud Heroku platvormi arendajate poolt.

Kaksteistfaktorit metoodikat (The Twelve-Factor App) saab rakendada mis tahes programmeerimiskeeles kirjutatud rakendustele, kasutades kõiki kombinatsioone välishaldusteenustest (backing services) (andmebaasid, sõnumijärjekorrad, vahemälu jne).

Lühidalt metoodika aluseks olevatest teguritest:

1. Koodibaas – Üks koodibaas, mis on jälgitav versioonikontrollis – mitmed juurutamised
2. Sõltuvused – Delegeerige ja isoleerige sõltuvused selgelt
3. Konfiguratsioon – Salvestage konfigureerimine töötamisaja keskkonnas
4. Välishaldusteenused (Backing Services) – Peate käsitlema välishaldusteenuseid (backing services) ühendatavate ressurssidena
5. Kogumine, vabastamine, täitmine – Eraldage kogumise ja täitmise etapid rangelt
6. Protsessid – Käitage rakendust kui ühte või mitut olekuta protsessi (stateless)
7. Pordiseondumine (Port binding) – Eksportige teenuseid portide seondumise kaudu
8. Paralleelsus – Skaleerige rakendust protsesside kaudu
9. Utiliseeritavus (Disposability) – Maximeerige usaldusväärsust kiire käivitamise ja korrektse sulgemisega
10. Rakenduse arenduse/operatsiooni pariteet – Hoidke arenduse, vahepealse ja tootmisjuurutuse keskkonnad võimalikult sarnased
11. Logimine (Logs) – Käsitlege logi kui sündmuste voogu
12. Haldusülesanded – Täitke haldus-/korrashoiuülesanded ühekordsete protsesside kaudu

Rohkem teavet 12 teguri kohta leiate järgmistes allikates:

• Ametlik originaalallikas — kindlasti lugeda
• Artikkel Habr. Kaksteistfaktori rakendus — The Twelve-Factor App — ametlik tõlge
• Artikkel Habr. 7 puuduvat tegurit 12 Factor App lähenemises — värske pilk 12 tegurile, et neid täiustada.

Mis on Blue-Green tellimine?

Blue-Green tellimine on rakenduse tarnimise meetod production nii, et lõppkasutaja ei näe oma nägemuses mingeid muutusi. Teisisõnu, rakenduse juurutamine nulliga seisaku.

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

• Alustuseks on 2 füüsilist serverit, millel on täiesti sama kood, rakendus, projekt ja seal on ruuter (koormuse tasakaalustaja).
• Ruuter suunab algselt kõik päringud ühele serveritest (alfa).
• Kui tuleb aeg uuesti versioon välja anda, uuendatakse kogu projekt teisel serveril (sinine), mis ei saada sellel hetkel mingeid päringuid.
• Pärast seda, kui kood on sinisel serveril täielikult uuendatud, antakse ruuterile käsk lülituda rohelisele . Tundub, et sinine server.
• Nüüd näevad kõik kliendid koodi tööd siniselt servereid.
• Mingil hetkel alfa server teenib varukoopiana, kui juurutus peaks ebaõnnestuma, ja probleemide korral suunab ruuter kasutajate voolu tagasi sinine serverisse, kus on vana stabiilne versioon, samas kui uus kood saadetakse edasi täiendamiseks ja testimiseks. alfa Ja protsessi lõpus uuendatakse samuti
• serverit. Ja pärast selle uuendamist suunab ruuter päringute voolu tagasi alfa See kõik näeb välja väga hästi ja esialgu ei tohiks sellega mingeid probleeme olla. alfa server.

Kuid kuna me elame kaasaegses maailmas, ei sobi füüsiline lülitus, nagu klassikalises skeemis, meile. Teave, palun, kinnitage hetkeks, me naaseme selle juurde hiljem.
Halvad ja head nõuanded

: Allpool on näidatud utiliidid / meetodoloogiad, mida kasutan mina, saate kasutada mingeid alternatiive, millel on sarnased funktsioonid.

MärkusSuurem osa näidetest kattub mingil määral veebiarendusega (üllatus, üllatus), PHP ja Dockeriga.

Alltoodud punktides on lihtne praktiline kirjeldus, kuidas tegureid teatud näidetes kasutada, kui soovite rohkem teooriat selle teema kohta, vaadake ülal linke originaalallikasse.

1. Koodibaas

Kasutage FTP-d ja FileZillat, et üles laadida faile serveritesse üksikisikena, ärge hoidke koodi kusagil mujal peale tootmisserveri.

Projektis peab alati olema ühtne koodibaas, see tähendab, et kogu kood tuleb ühest allikast.

Projektis peaks alati olema ühtne koodibaas, see tähendab, et kogu kood tuleb ühest kohast. Git hoidlast. Serverid (production, staging, test1, test2 …) kasutavad koodi ühise hoidla harudest. Nii saavutame koodi järjepidevuse.

2. Sõltuvused

Laadige kõik raamatukogud kaustadena otse projekti juurkausta. Uuendusi tehke lihtsalt uue koodi üleslaadimisega praeguse versiooni kausta. Paigaldage kõik vajalikud utiliidid otse hostiserverisse, kus töötab veel 20 teenust.

Projekt peab alati sisaldama selgelt mõistetavat sõltuvuste nimekirja (sõltuvuste alla mõistan ka keskkonda). Kõik sõltuvused peavad olema selgelt määratletud ja isoleeritud.
Näiteks võtame Composer ja Docker.

Composer — paketihaldur, mis võimaldab PHP raamatukogude installimist. Composer võimaldab täpselt või mitte täpselt määrata versioone ning neid selgelt määratleda. Serveril võib olla 20 erinevat projekti ja igal ühel neist on isiklik paketihaldus ja raamatukogud, mis ei sõltu üksteisest.

Docker — utiliit, mis võimaldab määrata ja isoleerida keskkonda, kus rakendus töötab. Vastavalt, nagu ka composeriga, saame paremini määratleda, millega rakendus töötab. Valida teatud versioon PHP-st, paigaldada ainult projekti töötamiseks vajalikud paketid, mitte midagi liigset lisamata. Ja mis kõige tähtsam, mitte segada hostiserveri ja teiste projektide pakette ja keskkonda. See tähendab, et kõik serveris töötavad projektid Docker'i kaudu võivad kasutada täiesti erinevaid pakette ja täiesti erinevat keskkonda.

3. Konfiguratsioon

Hoia konfiguraatoreid konstantidena otse koodis. Erinevad konstantid testserveri jaoks, erinevad tootmise jaoks. Siduge rakenduse töö keskkonna järgi otse projekti ärilogikas if else konstruktsioonide abil.

Konfiguratsioonid — see on ainus, millega projekti rakendused (deployment) peaksid eristuma. Ideaalis peaks konfiguratsioon edastatama keskkonnamuutujate (env vars) kaudu.

Seega isegi kui hoiate mitu konfigureerimisfaili .config.prod .config.local ja nimetate need deployimise hetkel ümber .config (peamine konfig, millest rakendus andmeid loeb) - see ei ole õige lähenemine, kuna antud juhul on konfigureerimise teave kõigile rakenduse arendajatele kergesti kättesaadav ja tootmiserveri andmed võivad olla ohustatud. Kõik konfigureerimised peavad olema salvestatud otse töödegevussüsteemi (CI/CD) ja genereeritud erinevate keskkondade jaoks erinevate väärtustega, mis on vajalikud konkreetse keskkonna jaoks just deployimise hetkel.

4. Kolmandad teenused (Backing Services)

Seotage tugevalt keskkonnaga, kasutage erinevaid ühendusi samadele teenustele teatud keskkondades.

Tegelikult kattub see punkt tugevalt konfigureerimispunktiga, kuna ilma selle punktita ei ole võimalik luua korralikke konfigureerimisandmeid ja üldse võimalust konfigureerimist ei ole.

Kõik ühendused väliste teenustega, nagu järjekorra serverid, andmebaasid, vahemälu teenused, peavad olema ühtsed nii kohalikus keskkonnas kui ka välises / tootmis keskkonnas. Teisisõnu, ma võin igal hetkel ühenduse stringi muutes asendada päringud andmebaas #1 andmebaas #2-ga ilma rakenduskoodi muutmata. Või et mitte liiga kaugele minna, näiteks tuleb see, et teenuse skaleerimisel ei pea te täiendava vahemälu serveri jaoks ühendust mingil erilisel viisil näitama.

5. Kogumine, väljaandmine, täitmine

Olge serveris ainult lõppversiooniga kood, ilma võimaluseta tagasi relisi tagasi pöörduda. Ärge täitke kettaruumi. Kes arvab, et võib tootmisse lasta viga sisaldava koodi, see on halb programmeerija!

Kõik deployimise etapid peavad olema omavahel eraldatud.

Olge võimalus tagasi pöörduda. Tehke väljaanded, hoides kiirelt juurdepääsetavaid vanu koopiaid rakendusest (juba koostatud ja valmis lahinguks), et vigade korral taastada vana versioon. Seega tinglikult on olemas kaust releases ja kaust current, ja pärast edukat deploy’d ja koostamist seondub kaust current symbolilise lingiga uue väljaandega, mis asub sees releases tinglikult versiooninumbri nimega.

Siin tuletame meelde Blue-Green deploymente, mis võimaldab mitte ainult koodi vahel vahetada, vaid ka vahetada kõiki ressursse ja isegi keskkondi tagasi kerimise võimalusega.

6. Protsessid

Hoidke rakenduse olekuandmeid otse rakenduses enda sees. Kasutage rakenduse mälu seansse. Kasutage võimalikult palju teenuste vahel jagatavaid andmeid. Siduge ennast sellega, et rakendusel võib olla ainult üks protsess ja ärge lubage skaleerimist.

Seoste osas hoidke andmeid ainult kolmandate osapoolte hallatavas vahemälus (memcached, redis), nii et isegi kui teil on käimas 20 rakenduse protsessi, võib ükskõik milline neist vahemälu poole pöördudes jätkata tööd kliendiga samas olekus, milles kasutaja rakendusega töötas teises protsessis. Sellise lähenemisega töötab kõik sujuvalt ja ilma probleemideta andmete juurde pääsemisel, olenemata sellest, kui palju kolmandate osapoolte teenuseid kasutate.

7. Portide sidumine (Port binding)

Kolmandate osapoolte teenuseid peab tundma ainult veebiserver. Veel parem on tõsta kolmandate osapoolte teenuseid otse veebiserveris üles. Näiteks nagu PHP moodul Apache's.
KÕIK teie teenused peavad olema üksteisele kergesti kättesaadavad, helistades mõnele aadressile ja pordile (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), see tähendab, et nginxist pääsen nii php-fpm'ile kui postgres'ile, ning php-fpm'ist postgres'ile ja nginx'ile, ning üldiselt saan iga teenuse kaudu juurde pääseda teisele teenusele. Niisiis, teenuse elujõud ei sõltu teisest teenusest.

8. Paralellism

Töötage ühe protsessiga, et mitmed protsessid üksteisega hästi ei sobiks!

Jätke skaleerimise võimalus. Docker Swarm sobib selleks suurepäraselt.
Docker Swarm on tööriist, mis võimaldab luua ja hallata konteinerikliastreid nii erinevate masinate vahel kui ka palju konteinerite ühe masina peal.

Kasutades swarm'i, saan määrata, kui palju ressursse ma iga protsessi jaoks eraldan ja kui palju sama teenuse protsesse ma käitan, ning sisemine tasakaalustaja, võttes andmeid määratud portilt, suunab need automaatselt protsessidele. Seega, nähes, et serveri koormus on kasvanud, võin lisada rohkem protsesse, vähendades seeläbi teatud protsesside koormust.

9. Utiliseeritavus (Disposability)

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

Iga protsess ja teenus võivad olla igal ajal välja lülitatud ning see ei tohiks mõjutada teisi teenuseid (jutt ei ole sellest, et teenus ei ole kergesti teistele teenustele kätte saadav, vaid et teine teenus ei lülitu välja selle taga). Kõik protsessid peaksid lõpetama pehmelt, nii et nende lõpetamisel ei kahjustata andmeid ja järgmine kord, kui süsteem sisse lülitub, töötab see korrektselt. Seega ei tohi isegi eriolukordade lõpetamisel andmed kannatada, (siia sobib tehingute mehhanism, andmebaasi päringud töötavad ainult gruppide kaupa ja kui ükski päring grupi seest ei õnnestunud või õnnestus vea tõttu, siis ei soorita tegelikult ühtegi teist päringut grupist).

10. Arenduse/töö rakenduse paaritunne

Prodaktsioon, stseen ja kohalik versioon rakendusest peaksid olema erinevad. Prodaktsioonis on meil raamistik Yii Lite, aga kohalikult Yii, et tootmisprotsess käiks kiiremini!

Tegelikult peaks kõik juurutamised ja koodiga töötamine toimuma peaaegu identsetes keskkondades (jutt ei ole füüsilisest riistvarast). Samuti peab igal arendaja töötajal olema võimalus vajadusel kood produktsioonis juurutada, mitte mingil erikoolitatud devops osakonnal, mis vaid erilise võime tõttu suudab rakenduse produktsioonis üles tõsta.

Selles aitab meid samuti Docker. Kui kõik eelnevad punktid on täidetud, toob Docker keskkonna juurutamise protsessi nii tootmises kui ka kohalikul masinal ühe-kahte käsu sisestamiseni.

11. Logimine (Logs)

Kirjutame logid failidesse ja andmebaasi! Failide ja andmebaasi logisid ei puhastata. Ostame lihtsalt 9000 Petabaiti kõvaketta ja on kõik.

Kõiki logisid tuleks käsitleda kui sündmuste voogu. Rakendus ei tohi logide töötlemisega tegeleda. Logid peaksid kas ilmuma stdout-sse või olema saadetavad protokolli kaudu nagu udp, et rakendusele ei tekiks logide töötlemisest probleeme. Selle jaoks sobib väga hästi graylog. Graylog, mis võtab vastu kõik logid udp kaudu (selle protokolli puhul ei ole vajalik oodata kinnitust paketi edukast vastuvõtmisest), ei sega rakendust mingil viisil ning tegeleb ainult logide struktureerimise ja töötlemisega. Rakenduse loogika ei muutu sarnaste lähenemiste kasutamise korral.

12. Administratiivsed ülesanded

Andmete, andmebaasi jne värskendamiseks kasutage eraldi loodud lõpp-punkti API-s, mille kahe korda järjestikune täitmine võib põhjustada andmete dubleerimist. Kuid te ei ole ju lollid, et vajutada kaks korda, ega me vajame migreerimisi.

Kõik administratiivsed ülesanded peavad toimuma samas keskkonnas nagu kogu kood, versioonide tasemel. See tähendab, et kui me peame andmebaasi struktuuri muutma, siis me ei tee seda käsitsi, muutes veergude nimesid ja lisades uusi visuaalsete andmebaasi haldustööriistade kaudu. Selliste asjade jaoks loome eraldi skriptid — migreerimised, mis teostatakse kõikjal ja kõigis keskkondades sama tulemuse saavutamiseks. Kõikide teiste ülesannete jaoks, näiteks projekti andmete täitmiseks, tuleks rakendada sarnaseid meetodoloogiaid.

PHP, Laravel, Laradock, Docker-Compose näidisrakendus

P.S. Kõik näited on tehtud MacOS-il. Suurem osa neist sobib ka Linuxile. Windowsi kasutajad, palun andke andeks, aga ma ei ole Windowsiga pikka aega töötanud.

Kujutame ette olukorda, kus meie PC-s ei ole ühtegi PHP versiooni ega üldse midagi.
Paigaldame dockerit ja docker-compose'i uusimad versioonid. (seda saab leida internetist)

docker -v &&
docker-compose -v

1. Paigaldame Laradock

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

Laradocki kohta võin öelda, et see on väga hea asi, milles on kogutud palju konteinerit ja abivahendeid. Kuid kasutada Laradocki tootmisversioonis muutmata kujul — ma ei soovitaks selle ülemäärasuse tõttu. Paremini on luua oma konteinerid, tuginedes Laradocki näidetele, sest niimoodi on optimeerimine võimalik, kuna keegi ei vaja kõike, mis seal on, korraga.

2. Konfigureerime Laradocki oma rakenduse tööde jaoks.

cd laradock &&
cp env-example .env

2.1. Avame habr kataloog (vanemapakk, kuhu laradock on kloonitud) mõnes redaktoris. (Minu puhul PHPStorm)

Nendel etappidel paneme ainult projekti nime.

2.2. Käivitame workspace'i pildi. (Teie puhul pildid ehitatakse mõnda aega)
Workspace on spetsiaalselt ette valmistatud pilt raamistiku jaoks arendaja nime alt.

Siseneme konteinerisse järgmise abil

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

2.3. Installime Laravel'i

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

2.4. Pärast installimist kontrollime, kas projekti kataloog on loodud, ja lõpetame compose'i.

ls
exit
docker-compose down

2.5. Naaseme tagasi PHPStormi ning seame õigesti teed meie laravel rakenduse .env failis.

3. Lisame kogu koodi Git-i.

Selleks loome GitHubis (või kusagil mujal) repositooriumi. 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 # siia tuleb teie repo link
git push -u origin master
git status

Kontrollime, kas kõik on korras.

Mugavuse huvides soovitan kasutada mõnda 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 avatud.

docker-compose up -d nginx php-fpm

Seega koosneb meie projekt 3 eraldi teenusest:

• nginx — veebiserver
• php-fpm — php veebiserverilt saadud päringute vastuvõtmiseks
• workspace — php arendaja jaoks

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

1. Koodibaas — kogu kood asub ühes repositooriumis (väike märkus: võib-olla oleks õigem tuua docker laraveli projekti, kuid see ei ole põhimõtteline).

2. Sõltuvused — Kõik meie sõltuvused on selgelt kirjas application/composer.json failis ja igas konteineri Dockerfile'is.

3. Välishaldusteenused (Backing Services) — Iga teenus (php-fpm, nginx, workspace) elab oma elu ning on väljastpoolt ühendatud, ja kui töötame ühe teenusega, ei mõjuta see teist.

4. Protsessid — iga teenus on üks protsess. Iga teenus ei hoia sisemist seisundit.

5. Pordiseondumine (Port binding)

docker ps

Nagu näeme, on iga teenus käivitunud oma porti peal ja on saadaval kõigile muudele teenustele.

6. Paralleelsus

Docker võimaldab meil tõsta mitu protsessi sama teenuse jaoks automaatse koormuse tasakaalustamisega nende vahel.

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

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

Nagu me näeme, on php-fpm konteinerite koopiad loodud. Me ei pea selle konteineri töös midagi muutma. Jätkame selle poole pöördumist porti 9000 kaudu, samal ajal kui Docker reguleerib meie jaoks koormust konteinerite vahel.

7. Utiliseeritavus (Disposability) — iga konteinerit saab katkestada ilma teistele kahju tekitamata. Kaugjuhtimine või konteineri taaskäivitamine ei mõjuta rakenduse toimimist järgnevatel käivitustel. Iga konteinerit saab ka igal ajal üles tõsta.

8. Rakenduse arenduse/operatsiooni 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 samal Dockeril.

9. Logimine (Logs) — kõik logid nendes konteinerites voolavad otse ja on nähtavad Dockeri konsoolis. (selles juhtumis, tegelikult võib see teiste isetehtud konteinerite puhul olla erinev, kui te sellele ei mõtle)

 docker-compose logs -f

Kuid siin on probleem selles, et PHP ja Nginxi vaikeseaded salvestavad samuti logid faili. 12 teguri nõuete järgimiseks on vajalik Saadaval on Firefox 121. Uued omadused: Toetatakse Waylandit. logide salvestamine faili iga konteineri eraldi seadistustes.

Docker pakub ka võimalust suunata logid mitte ainult stdout'i, vaid ka sellistesse asjadesse nagu graylog, millest rääkisin varem. Ja graylogi sees saame logidega teha igasuguseid toiminguid, ilma et meie rakendus seda märkaks.

10. Haldusülesanded — kõik haldusülesanded lahendab Laravel, kasutades artisan tööriista täpselt nii, nagu 12-faktori rakenduse loojaid sooviks.

Näitena näitan, kuidas mõned käsud täidetakse.
Siseneme konteinerisse.

 
docker-compose exec workspace bash
php artisan list

Nüüd saame kasutada mingeid käske. (pange tähele, et me ei ole andmebaasi ja vahemälu seadistanud, seega ei toimi pooled käsud korrektselt, kuna need on mõeldud vahemälu ja andmebaasiga töötamiseks).

11. Konfiguratsioonid ja 12. Kogumine, vabastamine, täitmine

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

Lühidalt öeldes põhineb kontseptsioon CI/CD süsteemidel nagu Jenkinsile ja Gitlab CI. N nii selles kui ka teises saab seada keskkonna spetsiifilisi keskkonnamuutujate väärtusi. Seetõttu täidetakse selle korralduse punkt Seadistuste.

Ja punkt seoses Kogumine, vabastamine, täitmine lahendatakse mõlema utiliidi sisseehitatud funktsioonide abil nimega Pipeline.

Pipeline võimaldab jagada deploimentprotsessi mitmeks etapiks, eraldades ehitamise, vabastamise ja teostamise faasid. Samuti saate Pipeline'is luua varukoopiaid ja tegelikult teha mida iganes. See on tööriist, millel on piiramatu potentsiaal.

Rakenduse kood asub Github.
Ärge unustage submodule algatada, kui kloonite seda hoidlat.

P.S.: Kõiki neid lähenemisviise saab kasutada ka muude utiliitide ja programmeerimiskeeltega. Peamine on, et sisu ei erineks.

Allikas: habr.com