Rakenduste arendus ja siniroheline juurutamine, mis põhineb The Twelve-Factor App metoodikal koos näidetega php-s ja dockeris

Esiteks väike teooria. Mis on juhtunud Kaheteistkümne teguri rakendus?

Lihtsamalt öeldes on see dokument loodud SaaS-i rakenduste arendamise lihtsustamiseks, aidates arendajaid ja DevOpsi insenere teavitada probleemidest ja tavadest, millega tänapäevaste rakenduste arendamisel kõige sagedamini kokku puututakse.

Dokumendi lõid Heroku platvormi arendajad.

Kaheteistkümne teguri rakendust saab rakendada rakendustele, mis on kirjutatud mis tahes programmeerimiskeeles ja kasutavad mis tahes tugiteenuste kombinatsiooni (andmebaasid, sõnumijärjekorrad, vahemälud jne).

Lühidalt teguritest, millel see metoodika põhineb:

1. Koodibaas – Üks koodibaas, mida jälgitakse versioonikontrollis – mitu juurutamist
2. Sõltuvused – Sõltuvuste selgesõnaline deklareerimine ja eraldamine
3. Konfiguratsioon - Salvestage konfiguratsioon käitusajal
4. Taustateenused – Kaaluge tugiteenuseid pistikprogrammide ressurssidena
5. Ehitage, vabastage, jookske – Eraldage rangelt montaaži- ja teostamisetapid
6. Protsessid – Käivitage rakendus ühe või mitme olekuta protsessina
7. Pordi sidumine – Eksporditeenused pordi sidumise kaudu
8. Paralleelsus – Skaleerige oma rakendust protsesside abil
9. Ühekordseks kasutamiseks - Maksimeerige töökindlus kiire käivitamise ja puhta väljalülitamisega
10. Rakenduste arendamise/operatsiooni paarsus – Hoidke oma arendus-, lavastus- ja tootmiskeskkonnad võimalikult sarnased
11. Logimine – Vaadake logi sündmuste voona
12. Haldusülesanded – täitke haldus-/haldusülesandeid, kasutades ad hoc protsesse

12 teguri kohta saate lisateavet järgmistest allikatest.

• Ametlik allikas - peab lugema
• Artikkel habr. Kaheteistkümne teguri rakendus — ametlik tõlge
• Artikkel habr. 7 puuduvat tegurit rakenduses 12 Factor - uus pilk 12 tegurile eesmärgiga neid parandada.

Mis on sinine-roheline juurutamine?

Sinine-roheline juurutus on meetod rakenduse edastamiseks tootmine selliselt, et lõppklient ei näeks omapoolseid muutusi. Teisisõnu, rakenduse juurutamine nulliga seisakuaeg.

Klassikaline BG juurutamise skeem näeb välja selline, nagu on näidatud alloleval pildil.

• Alguses on 2 füüsilist serverit absoluutselt sama koodi, rakenduse, projektiga ja olemas on ruuter (balancer).
• Algselt suunab ruuter kõik päringud ühte serveritest (roheline).
• Sel hetkel, kui peate uuesti vabastama, värskendatakse kogu projekti teises serveris (SININE ), mis praegu taotlusi ei töötle.
• Pärast koodi sisselülitamist sinine server on täielikult uuendatud, antakse ruuterile käsk lülituda roheline edasi SININE server.
• Nüüd näevad kõik kliendid töötava koodi tulemust sinine server.
• Mõnda aega, roheline server toimib varukoopiana, kui selle juurutamine ebaõnnestub SININE server ning tõrgete ja vigade korral lülitab ruuter kasutajavoo tagasi roheline serverisse vana stabiilse versiooniga ning uus kood saadetakse ülevaatamiseks ja testimiseks.
• Ja protsessi lõpus värskendatakse seda samal viisil roheline server. Ja pärast selle värskendamist lülitab ruuter päringuvoo tagasi roheline server.

Kõik tundub väga hea ja esmapilgul ei tohiks sellega probleeme tekkida.
Kuid kuna me elame kaasaegses maailmas, siis klassikalises skeemis näidatud füüsilise ümberlülitamise võimalus meile ei sobi. Salvestage teave praegu, me naaseme selle juurde hiljem.

Halb ja hea nõuanne

Vastutusest loobumine: Allolevad näited näitavad minu kasutatavaid utiliite/metoodikaid, võite kasutada absoluutselt kõiki sarnaste funktsioonidega alternatiive.

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

Allolevates lõikudes kirjeldatakse lihtsat praktilist tegurite kasutamist konkreetsete näidete abil; kui soovite selle teema kohta rohkem teooriat saada, järgige ülalolevaid linke algallikale.

1. Koodibaas

Failide ükshaaval üleslaadimiseks serveritesse kasutage FTP-d ja FileZillat, ärge salvestage koodi mujal kui tootmisserveris.

Projektil peaks alati olema üks koodibaas, see tähendab, et kogu kood pärineb ühest Git hoidla. Serverid (tootmine, lavastus, test1, test2...) kasutavad koodi ühe ühise hoidla harudest. Nii saavutame koodi järjepidevuse.

2. Sõltuvused

Laadige kõik kaustades olevad teegid alla otse projekti juure. Tehke värskendusi lihtsalt, teisaldades uue koodi teegi praeguse versiooniga kausta. Installige kõik vajalikud utiliidid otse hostserverisse, kus töötab veel 20 teenust.

Projektil peaks alati olema selgelt arusaadav sõltuvuste loetelu (sõltuvuste all pean silmas ka keskkonda). Kõik sõltuvused peavad olema selgelt määratletud ja eraldatud.
Võtame näiteks Koostama и laevalaadija.

Koostama — paketihaldur, mis võimaldab installida PHP-sse teeke. Helilooja võimaldab teil versioone rangelt või lõdvalt määrata ja need selgesõnaliselt määratleda. Serveris võib olla 20 erinevat projekti ja igaühel neist on teisest sõltumatu pakettide ja teekide isiklik loend.

laevalaadija — utiliit, mis võimaldab määrata ja eraldada keskkonna, milles rakendus töötab. Sellest lähtuvalt, nagu helilooja puhul, aga põhjalikumalt, saame määrata, millega rakendus töötab. Valige konkreetne PHP versioon, installige ainult projekti toimimiseks vajalikud paketid, ilma midagi lisamata. Ja mis kõige tähtsam, ilma peremeesmasina ja muude projektide pakette ja keskkonda segamata. See tähendab, et kõik Dockeri kaudu töötavad projektid saavad kasutada absoluutselt mis tahes pakettide komplekti ja täiesti erinevat keskkonda.

3. Konfiguratsioon

Salvestage konfiguratsioonid konstantidena otse koodis. Testserveri jaoks eraldi konstandid, tootmise jaoks eraldi. Seo rakenduse toimimine sõltuvalt keskkonnast otse projekti äriloogikasse, kasutades if else konstruktsioone.

Konfiguratsioonid - see on ainus viis, kuidas projekti kasutuselevõtt peaks erinema. Ideaalis tuleks konfiguratsioonid edastada keskkonnamuutujate (env vars) kaudu.

See tähendab, et isegi kui salvestate mitu konfiguratsioonifaili .config.prod .config.local ja nimetate need juurutamise ajal ümber konfiguratsiooniks .config (peamine konfiguratsioon, millest rakendus andmeid loeb), ei ole see õige lähenemisviis, kuna sel juhul on konfiguratsioonide teave avalikult kättesaadav kõigile rakenduste arendajatele ja tootmisserveri andmed on ohustatud. Kõik konfiguratsioonid tuleb salvestada otse juurutussüsteemi (CI/CD) ja genereerida erinevate keskkondade jaoks erinevate väärtustega, mis on juurutamise ajal konkreetse keskkonna jaoks vajalikud.

4. Kolmanda osapoole teenused

Olge keskkonnaga rangelt seotud, kasutage teatud keskkondades samade teenuste jaoks erinevaid ühendusi.

Tegelikult kattub see punkt tugevalt konfiguratsiooni puudutava punktiga, kuna ilma selle punktita ei saa teha tavalisi konfiguratsiooniandmeid ja üldiselt langeb konfigureerimise võimalus olematuks.

Kõik ühendused välisteenustega, nagu järjekorraserverid, andmebaasid, vahemäluteenused, peavad olema samad nii kohaliku keskkonna kui ka kolmanda osapoole/tootmiskeskkonna jaoks. Teisisõnu, ühendusstringi muutes saan igal ajal asendada kõned baasi nr 1 baasiga nr 2 ilma rakenduse koodi muutmata. Või tulevikku vaadates ei pea te teenuse skaleerimisel näiteks täiendava vahemäluserveri jaoks ühendust eriliselt määrama.

5. Ehitage, vabastage, teostage

Serveris peab olema ainult koodi lõplik versioon, ilma võimaluseta väljalaset tagasi pöörata. Kettaruumi pole vaja täita. Igaüks, kes arvab, et suudab veaga koodi tootmisse lasta, on halb programmeerija!

Kõik kasutuselevõtu etapid peavad olema üksteisest eraldatud.

Teil on võimalus tagasi pöörata. Tehke väljalasked rakenduse vanade koopiatega (juba kokkupandud ja lahinguvalmis), mis on salvestatud kiirjuurdepääsusse, et vigade korral saaksite vana versiooni taastada. See tähendab, et tingimuslikult on kaust releases ja kaust praegunening pärast edukat juurutamist ja kausta kokkupanemist praegune on seotud sümboolse lingiga uuele väljalasele, mis asub sees releases väljalaskenumbri tavapärase nimetusega.

Siin mäletame sini-rohelist juurutamist, mis võimaldab teil mitte ainult koodide vahel lülituda, vaid ka lülituda kõigi ressursside ja isegi keskkondade vahel koos võimalusega kõik tagasi pöörata.

6. Protsessid

Salvestage rakenduse olekuandmed otse rakenduses endas. Kasutage seansse rakenduse enda RAM-is. Kasutage võimalikult palju jagamist kolmandate osapoolte teenuste vahel. Toetuge asjaolule, et rakendusel võib olla ainult üks protsess ja see ei võimalda skaleerimist.

Seansside puhul salvestage andmeid ainult vahemällu, mida juhivad kolmandate osapoolte teenused (memcached, redis), nii et isegi kui teil on töös 20 rakendusprotsessi, saab igaüks neist pärast vahemällu juurde pääsemist jätkata kliendiga koostööd samas olekus, milles kasutaja töötas rakendusega teises protsessis. Selle lähenemisviisiga selgub, et olenemata sellest, kui palju kolmandate osapoolte teenuste koopiaid te kasutate, töötab kõik normaalselt ja andmetele juurdepääsu probleemideta.

7. Pordiköitmine

Ainult veebiserver peaks teadma, kuidas töötada kolmanda osapoole teenustega. Või veel parem, installige kolmanda osapoole teenused otse veebiserverisse. Näiteks PHP-moodulina Apache'is.
Kõik teie teenused peavad olema üksteisele juurdepääsetavad läbi juurdepääsu mõnele aadressile ja pordile (localgost: 5432, localhost: 3000, nginx: 80, php-fpm: 9000), see tähendab, et nginxist pääsen juurde nii php- fpm kui ka postgres ja php-fpm kuni postgres ja nginx ning tegelikult pääsen igast teenusest juurde teisele teenusele. Nii ei ole teenuse elujõulisus seotud mõne teise teenuse elujõulisusega.

8. Paralleelsus

Töötage ühe protsessiga, muidu ei saa mitu protsessi omavahel läbi!

Jäta ruumi skaleerimiseks. Dockeri sülem on selleks suurepärane.
Docker Swarm on tööriist konteinerite klastrite loomiseks ja haldamiseks nii erinevate masinate kui ka sama masina konteinerite hunniku vahel.

Swarmi abil saan määrata, kui palju ressursse ma igale protsessile eraldan ja mitu sama teenuse protsessi käivitan ning sisemine tasakaalustaja, saades andmeid antud pordi kohta, puhverdab selle automaatselt protsessidele. Seega, nähes, et serveri koormus on suurenenud, saan lisada protsesse juurde, vähendades seeläbi teatud protsesside koormust.

9. Ühekordseks kasutamiseks

Ärge kasutage protsesside ja andmetega töötamiseks järjekordi. Ühe protsessi tapmine peaks mõjutama kogu rakendust. Kui üks teenus kaob, läheb kõik alla.

Iga protsessi ja teenuse saab igal ajal välja lülitada ja see ei tohiks mõjutada teisi teenuseid (loomulikult ei tähenda see, et teenus ei oleks mõne teise teenuse jaoks saadaval, vaid seda, et pärast seda ei lülitu mõni teenus välja). Kõik protsessid tuleb lõpetada graatsiliselt, et nende lõpetamisel andmed ei kahjustataks ja süsteem töötaks järgmisel sisselülitamisel õigesti. See tähendab, et isegi hädaolukorra lõpetamise korral ei tohiks andmeid kahjustada (siia sobib tehingumehhanism, päringud andmebaasis töötavad ainult rühmadena ja kui vähemalt üks päring grupist ebaõnnestub või täidetakse viga, siis ükski teine ​​päring grupist lõpuks ebaõnnestub).

10. Rakenduse arendamise/operatsiooni pariteedi

Rakenduse tootmine, lavastus ja kohalik versioon peavad olema erinevad. Tootmises kasutame Yii Lite raamistikku ja kohapeal Yii, et see toimiks tootmises kiiremini!

Tegelikkuses peaksid kõik juurutused ja koodiga töötamine olema peaaegu identses keskkonnas (me ei räägi füüsilisest riistvarast). Samuti peaks vajadusel saama koodi tootmisse juurutada iga arendustöötaja, mitte mõni eriväljaõppe saanud devops osakond, mis ainult tänu erilisele tugevusele suudab rakenduse tootmisse tõsta.

Docker aitab meid ka selles. Kui järgite kõiki eelnevaid punkte, viib dockeri kasutamine keskkonna juurutamise protsessi nii tootmises kui ka kohalikus masinas ühe või kahe käsu sisestamiseni.

11. Palgid

Kirjutame logid failidesse ja andmebaasidesse! Me ei puhasta faile ja andmebaase logidest. Ostame 9000 Peta-baidiga kõvaketta ja see on korras.

Kõiki logisid tuleks käsitleda sündmuste voona. Rakendus ise ei tohiks olla seotud logide töötlemisega. Logid tuleks väljastada kas stdout-i või saata protokolli (nt udp) kaudu, et logidega töötamine ei tekitaks rakendusele probleeme. graylog sobib selleks hästi. Graylog, mis võtab kõiki logisid udp kaudu (see protokoll ei nõua vastuse ootamist paketi eduka vastuvõtmise kohta) ei sega rakendust kuidagi ja tegeleb ainult logide struktureerimise ja töötlemisega. Rakendusloogika ei muutu selliste lähenemisviisidega töötamiseks.

12. Haldusülesanded

Andmete, andmebaaside jms värskendamiseks kasutage API-s eraldi loodud lõpp-punkti, selle 2 korda järjest käivitades dubleeritakse kõik. Kuid te pole loll, te ei klõpsa kaks korda ja me ei vaja migratsiooni.

Kõik haldustoimingud tuleks teostada samas keskkonnas kui kogu kood, väljalaske tasemel. See tähendab, et kui meil on vaja muuta andmebaasi struktuuri, siis me ei tee seda käsitsi, muutes veergude nimesid ja lisades uusi läbi mõne visuaalse andmebaasihaldustööriista. Selliste asjade jaoks loome eraldi skriptid - migratsioonid, mida teostatakse kõikjal ja kõigis keskkondades ühtmoodi ühise ja arusaadava tulemusega. Kõigi muude ülesannete puhul, näiteks projekti andmetega täitmisel, tuleks kasutada sarnaseid metoodikaid.

Näidisrakendus PHP-s, Laravelis, Laradockis, Docker-Compose'is

PS Kõik näited tehti MacOS-is. Enamik neist sobib ka Linuxile. Windowsi kasutajad, andke andeks, aga ma pole Windowsiga pikka aega töötanud.

Kujutagem ette olukorda, kus meie arvutisse pole installitud ühtegi PHP versiooni ja üldse mitte midagi.
Installige dockeri ja docker-compose'i uusimad versioonid. (seda võib leida Internetist)

docker -v && 
docker-compose -v

1. Panime Laradock

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

Laradocki kohta ütlen, et see on väga lahe asi, mis sisaldab palju anumaid ja abiasju. Kuid ma ei soovitaks Laradocki kui sellist ilma tootmises muudatusteta kasutada selle koondamise tõttu. Parem on luua oma konteinerid Laradocki näidete põhjal, see on palju optimeeritum, sest keegi ei vaja kõike, mis seal on samal ajal.

2. Seadistage Laradock meie rakenduse käivitamiseks.

cd laradock && 
cp env-example .env

2.1. Avage mõnes redaktoris kataloog habr (ülemakaust, kuhu laradock kloonitakse). (Minu PHPStormi puhul)

Selles etapis anname projektile ainult nime.

2.2. Käivitage tööruumi pilt. (Teie puhul võtab piltide koostamine veidi aega)
Tööruum on spetsiaalselt ettevalmistatud pilt arendaja nimel raamistikuga töötamiseks.

Me läheme konteinerisse kasutades

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

2.3. Laraveli installimine

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

2.4. Pärast installimist kontrollime, kas projektiga kataloog on loodud ja tapame koostamise.

ls
exit
docker-compose down

2.5. Läheme tagasi PHPStormi juurde ja määrame .env-failis oma laraveli rakenduse õige tee.

3. Lisage kogu kood Giti.

Selleks loome Githubis (või mujal) hoidla. Liigume terminalis habr kataloogi ja käivitame järgmise koodi.

echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin git@github.com:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status

Kontrollime, kas kõik on korras.

Mugavuse huvides soovitan kasutada Giti jaoks mõnda visuaalset liidest, minu puhul on see nii GitKraken. (siin on viitelink)

4. Käivitame!

Enne käivitamist veenduge, et portide 80 ja 443 küljes ei ripuks midagi.

docker-compose up -d nginx php-fpm

Seega koosneb meie projekt kolmest eraldi teenusest:

• nginx - veebiserver
• php-fpm - php päringute vastuvõtmiseks veebiserverist
• tööruum - php arendajatele

Hetkel oleme saavutanud selle, et oleme loonud rakenduse, mis vastab 4 punktile 12-st, nimelt:

1. Koodibaas — kogu kood on ühes hoidlas (väike märkus: võib-olla oleks õige lisada docker laraveli projekti sisse, kuid see pole oluline).

2. Sõltuvused - Kõik meie sõltuvused on sõnaselgelt kirjas failis application/composer.json ja iga konteineri igas Dockeri failis.

3. Taustateenused — Iga teenus (php-fom, nignx, tööruum) elab oma elu ja on väljastpoolt ühendatud ning ühe teenusega töötamine ei mõjuta teist.

4. Protsessid — iga teenus on üks protsess. Iga teenus ei säilita sisemist olekut.

5. Pordi sidumine

docker ps

Nagu näeme, töötab iga teenus oma pordis ja on juurdepääsetav kõigile teistele teenustele.

6. Paralleelsus

Docker võimaldab meil luua samade teenuste mitu protsessi koos nendevahelise automaatse koormuse tasakaalustamisega.

Peatame konteinerid ja laseme need lipust läbi --kaal

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

Nagu näeme, on php-fpm konteinerist tehtud koopiad. Me ei pea selle konteineriga töötades midagi muutma. Samuti jätkame sellele juurdepääsu pordist 9000 ja Docker reguleerib meie eest konteinerite vahelist koormust.

7. Ühekordseks kasutamiseks - iga konteinerit saab tappa ilma teist kahjustamata. Konteineri peatamine või taaskäivitamine ei mõjuta rakenduse tööd järgnevate käivitamiste ajal. Iga konteinerit saab ka igal ajal tõsta.

8. Rakenduste arendamise/operatsiooni paarsus - kõik meie keskkonnad on ühesugused. Kui käivitate süsteemi tootmisserveris, ei pea te oma käskudes midagi muutma. Kõik põhineb samamoodi Dockeril.

9. Logimine — kõik nendes konteinerites olevad logid lähevad voogu ja on nähtavad Dockeri konsoolis. (Antud juhul ei pruugi see teiste omatehtud konteinerite puhul nii olla, kui te selle eest ei hoolitse)

 docker-compose logs -f

Kuid selles on konks, et PHP ja Nginxi vaikeväärtused kirjutavad faili ka logisid. 12 teguri täitmiseks on see vajalik lahti ühendada logide kirjutamine faili iga konteineri konfiguratsioonides eraldi.

Docker pakub ka võimalust saata logisid mitte ainult stdoutile, vaid ka sellistele asjadele nagu graylog, mida ma eespool mainisin. Ja halllogi sees saame logisid oma äranägemise järgi kasutada ja meie rakendus ei märka seda kuidagi.

10. Haldusülesanded — kõik haldusülesanded lahendab laravel tänu käsitöölisele tööriistale täpselt nii, nagu 12-faktorilise rakenduse loojad sooviksid.

Näitena näitan, kuidas mõnda käsku täidetakse.
Me läheme konteinerisse.

 
docker-compose exec workspace bash
php artisan list

Nüüd saame kasutada mis tahes käsku. (pange tähele, et me ei konfigureerinud andmebaasi ja vahemälu, mistõttu pooled käsud ei käivitu õigesti, kuna need on loodud töötama koos vahemälu ja andmebaasiga).

11. Konfiguratsioonid ja 12. Ehitage, vabastage, jookske

Tahtsin selle osa pühendada sinirohelisele juurutamisele, kuid see osutus selle artikli jaoks liiga mahukaks. Kirjutan selle kohta eraldi artikli.

Lühidalt öeldes põhineb kontseptsioon CI/CD süsteemidel nagu Jenkins и Gitlab CI. Mõlemas saate määrata konkreetse keskkonnaga seotud keskkonnamuutujaid. Vastavalt sellele täidetakse selles olukorras punkt c Konfiguratsioonid.

Ja point umbes Ehitage, vabastage, jookske on lahendatud nimega sisseehitatud funktsioonidega Torujuhe.

Torujuhe võimaldab jagada juurutamisprotsessi mitmeks etapiks, tuues esile kokkupaneku, vabastamise ja täitmise etapid. Ka Pipeline'is saate luua varukoopiaid ja tegelikult kõike. See on piiramatu potentsiaaliga tööriist.

Rakenduse kood asub aadressil Github.
Ärge unustage selle hoidla kloonimisel alammoodulit lähtestada.

PS: Kõiki neid lähenemisviise saab kasutada mis tahes muude utiliitide ja programmeerimiskeeltega. Peaasi, et olemus ei erine.

Allikas: www.habr.com