Fyrst smá kenning. Hvað gerðist ?
Í einföldum orðum, þetta skjal er hannað til að einfalda þróun SaaS forrita, hjálpa með því að upplýsa þróunaraðila og DevOps verkfræðinga um vandamál og venjur sem oftast koma upp við þróun nútíma forrita.
Skjalið var búið til af hönnuðum Heroku vettvangsins.
Tólf-þátta appið er hægt að nota á forrit sem eru skrifuð á hvaða forritunarmáli sem er og nota hvaða samsetningu sem er af bakþjónustu (gagnagrunna, skilaboðaraðir, skyndiminni osfrv.).
Stuttlega um þá þætti sem þessi aðferðafræði byggir á:
- Kóðagrunnur – Einn kóðagrunnur rakinn í útgáfustýringu – margar dreifingar
- Ósjálfstæði – Lýsa skýrt yfir og einangra ósjálfstæði
- Stillingar - Vistaðu stillingar í keyrslutíma
- Stuðningsþjónusta – Íhugaðu bakþjónustu sem viðbætur
- Byggja, sleppa, hlaupa - Aðskilja samsetningar- og framkvæmdarstigið stranglega
- Ferlarnir – Keyrðu forritið sem eitt eða fleiri ríkisfangslaus ferli
- Hafnarbinding – Útflutningsþjónusta með hafnarbindingu
- Samhliða - Stækkaðu umsókn þína með því að nota ferla
- Einnotahæfni - Hámarka áreiðanleika með hraðri ræsingu og hreinni lokun
- Umsóknarþróun/rekstrarjafnvægi - Haltu þróunar-, sviðsetningar- og framleiðsluumhverfi þínu eins líkt og mögulegt er
- Skógarhögg - Skoðaðu skrána sem straum atburða
- Stjórnsýsluverkefni – Framkvæma stjórnunar-/stjórnunarverkefni með sérstökum ferlum
Þú getur fengið frekari upplýsingar um 12 þættina frá eftirfarandi úrræðum:
- - verður að lesa
- — opinber þýðing
- - ný skoðun á þáttunum 12 með það að markmiði að bæta þá.
Hvað er Blue-Green dreifing?
Blue-Green dreifing er aðferð til að afhenda forrit til framleiðslu á þann hátt að endir viðskiptavinur sjái engar breytingar af hans hálfu. Með öðrum orðum, að dreifa forriti með núlli niður í miðbæ.
Klassíska BG Deploy kerfið lítur út eins og sýnt er á myndinni hér að neðan.
- Í upphafi eru 2 líkamlegir netþjónar með nákvæmlega sama kóða, forriti, verkefni og það er leið (jafnvægi).
- Bein beinir upphaflega öllum beiðnum til eins af netþjónunum (grænt).
- Í augnablikinu þegar þú þarft að gefa út aftur, er allt verkefnið uppfært á öðrum netþjóni (blár), sem er ekki að vinna úr neinum beiðnum eins og er.
- Eftir að kóðinn er kveiktur blár miðlarinn er algjörlega uppfærður, beini er gefin skipun um að skipta úr grænt á blár miðlara.
- Nú sjá allir viðskiptavinir niðurstöðuna af kóðanum sem keyrir með blár miðlara.
- Í einhvern tíma, grænt þjónninn þjónar sem öryggisafrit ef misheppnuð dreifing á blár miðlara og ef um bilanir og villur er að ræða skiptir beininn um notendaflæði aftur í grænt miðlara með gömlu stöðugu útgáfunni og nýi kóðinn er sendur til endurskoðunar og prófunar.
- Og í lok ferlisins er það uppfært á sama hátt grænt miðlara. Og eftir að hafa uppfært það skiptir leiðin um beiðniflæðið aftur í grænt miðlara.
Þetta lítur allt mjög vel út og við fyrstu sýn ættu ekki að vera nein vandamál með það.
En þar sem við búum í nútímanum hentar valmöguleikinn með líkamlegri skiptingu eins og tilgreint er í klassíska kerfinu okkur ekki. Skráðu upplýsingarnar í bili, við komum aftur að þeim síðar.
Slæmt og gott ráð
Afneitun ábyrgðar: Dæmin hér að neðan sýna tólin/aðferðirnar sem ég nota, þú getur notað nákvæmlega hvaða val sem er með svipaðar aðgerðir.
Flest dæmin munu á einn eða annan hátt skarast við þróun vefs (þetta kemur á óvart), með PHP og Docker.
Málsgreinarnar hér að neðan veita einfalda hagnýta lýsingu á notkun þátta með sérstökum dæmum; ef þú vilt fá meiri kenningu um þetta efni skaltu fylgja tenglunum hér að ofan á upprunalegu heimildina.
1. Kóðagrunnur
Notaðu FTP og FileZilla til að hlaða upp skrám á netþjóna einn í einu, ekki geymdu kóðann annars staðar en á framleiðsluþjóninum.
Verkefnið ætti alltaf að hafa einn kóðagrunn, það er, allur kóði kemur frá einum fara geymsla. Servers (framleiðsla, sviðsetning, test1, test2...) nota kóða frá útibúum einnar sameiginlegrar geymslu. Þannig náum við samræmi í kóða.
2. Ósjálfstæði
Sæktu öll söfn í möppum beint í rót verkefnisins. Gerðu uppfærslur einfaldlega með því að flytja nýja kóðann í möppuna með núverandi útgáfu af bókasafninu. Settu upp öll nauðsynleg tól beint á hýsingarþjóninum þar sem 20 þjónustur í viðbót eru í gangi.
Verkefni ætti alltaf að hafa skýrt skiljanlegan lista yfir ósjálfstæði (með ósjálfstæði á ég líka við umhverfið). Öll ósjálfstæði verða að vera skýrt skilgreind og einangruð.
Tökum sem dæmi Semja и Docker.
Semja — pakkastjóri sem gerir þér kleift að setja upp bókasöfn í PHP. Composer gerir þér kleift að tilgreina útgáfur stranglega eða lauslega og skilgreina þær sérstaklega. Það geta verið 20 mismunandi verkefni á þjóninum og hver mun hafa persónulegan lista yfir pakka og bókasöfn óháð öðru.
Docker — tól sem gerir þér kleift að skilgreina og einangra umhverfið sem forritið mun keyra í. Í samræmi við það, rétt eins og með tónskáld, en ítarlegri, getum við ákvarðað hvað forritið virkar með. Veldu tiltekna útgáfu af PHP, settu aðeins upp þá pakka sem nauðsynlegir eru til að verkefnið virki, án þess að bæta neinu auka við. Og síðast en ekki síst, án þess að trufla pakka og umhverfi gestgjafavélarinnar og annarra verkefna. Það er, öll verkefni á þjóninum sem keyra í gegnum Docker geta notað nákvæmlega hvaða pakka sem er og allt annað umhverfi.
3. Stillingar
Geymdu stillingar sem fasta beint í kóðanum. Aðskildir fastar fyrir prófunarþjóninn, aðskildir fyrir framleiðslu. Binddu rekstur forritsins eftir umhverfinu beint í viðskiptarökfræði verkefnisins með því að nota ef annað smíðar.
Stillingar - þetta er eina leiðin sem dreifing verkefna ætti að vera mismunandi. Helst ætti að senda stillingar í gegnum umhverfisbreytur (env vars).
Það er, jafnvel þó að þú geymir nokkrar stillingarskrár .config.prod .config.local og endurnefnir þær við uppsetningu í .config (aðalstillingin sem forritið les gögn úr) - þá mun þetta ekki vera rétta aðferðin, þar sem í þessu tilviki verða upplýsingarnar úr stillingunum aðgengilegar öllum forritara og gögn frá framleiðsluþjóninum verða í hættu. Allar stillingar verða að vera geymdar beint í dreifingarkerfinu (CI/CD) og búa til fyrir mismunandi umhverfi með mismunandi gildum sem eru nauðsynleg fyrir tiltekið umhverfi á þeim tíma sem dreifingin fer fram.
4. Þjónusta þriðja aðila
Vertu stranglega bundinn við umhverfið, notaðu mismunandi tengingar fyrir sömu þjónustu í ákveðnu umhverfi.
Reyndar skarast þetta atriði mjög við punktinn um stillingar, þar sem án þessa punkts er ekki hægt að búa til eðlileg stillingargögn og almennt mun möguleikinn til að stilla niður í ekki neitt.
Allar tengingar við ytri þjónustu, svo sem biðröðþjóna, gagnagrunna, skyndiminniþjónustu, verða að vera eins fyrir bæði staðbundið umhverfi og þriðja aðila / framleiðsluumhverfi. Með öðrum orðum, hvenær sem er, með því að breyta tengistrengnum, get ég skipt út símtölum í stöð #1 fyrir stöð #2 án þess að breyta forritskóðanum. Eða, þegar þú horfir fram á við, sem dæmi, þegar þú skalar þjónustuna þarftu ekki að tilgreina tenginguna á neinn sérstakan hátt fyrir viðbótar skyndiminniþjón.
5. Byggja, sleppa, framkvæma
Hafa aðeins lokaútgáfu kóðans á þjóninum, án möguleika á að snúa útgáfunni til baka. Engin þörf á að fylla upp pláss. Allir sem halda að þeir geti gefið út kóða í framleiðslu með villu er slæmur forritari!
Öll stig dreifingar verða að vera aðskilin hvert frá öðru.
Gefðu tækifæri til að snúa aftur. Gerðu útgáfur með gömlum afritum af forritinu (þegar sett saman og tilbúið fyrir bardaga) sem vistaðar eru með skjótum aðgangi, svo að ef upp koma villur geturðu endurheimt gömlu útgáfuna. Það er, með skilyrðum, er mappa Fréttatilkynningar og möppu núverandi, og eftir vel heppnaða dreifingu og samsetningu möppunnar núverandi tengdur með táknrænni hlekk við nýju útgáfuna sem liggur inni Fréttatilkynningar með hefðbundnu nafni útgáfunúmersins.
Þetta er þar sem við minnumst Blue-Green dreifingarinnar, sem gerir þér ekki aðeins kleift að skipta á milli kóða, heldur einnig að skipta á milli allra auðlinda og jafnvel umhverfi með getu til að snúa öllu til baka.
6. Ferlar
Geymdu gögn um stöðu umsóknar beint í forritinu sjálfu. Notaðu lotur í vinnsluminni forritsins sjálfs. Notaðu eins mikla samnýtingu milli þjónustu þriðja aðila og mögulegt er. Haltu þig við þá staðreynd að forritið getur aðeins haft eitt ferli og leyfir ekki skala.
Varðandi lotur, geymdu gögn aðeins í skyndiminni sem er stjórnað af þjónustu þriðja aðila (memcached, redis), þannig að jafnvel þótt þú sért með 20 umsóknarferli í gangi, mun einhver þeirra, sem hefur fengið aðgang að skyndiminni, geta haldið áfram að vinna með biðlaranum í sama ástand og notandinn var að vinna með forritið í öðru ferli. Með þessari nálgun kemur í ljós að sama hversu mörg eintök af þjónustu þriðja aðila þú notar mun allt virka eðlilega og án vandræða með aðgang að gögnum.
7. Hafnarbinding
Aðeins vefþjónninn ætti að vita hvernig á að vinna með þjónustu þriðja aðila. Eða enn betra, settu upp þjónustu þriðja aðila beint inni á vefþjóninum. Til dæmis, sem PHP mát í Apache.
Öll þjónusta þín verður að vera aðgengileg hver annarri með aðgangi að einhverju heimilisfangi og höfn (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), það er að segja frá nginx get ég fengið aðgang að bæði php-fpm og til postgres, og frá php-fpm til postgres og nginx og í raun frá hverri þjónustu get ég fengið aðgang að annarri þjónustu. Þannig er hagkvæmni þjónustu ekki bundin við hagkvæmni annarrar þjónustu.
8. Hliðstæður
Vinna með eitt ferli, annars geta nokkrir ferlar ekki farið saman!
Skildu eftir pláss fyrir mælingu. Docker swarm er frábært fyrir þetta.
Docker Swarm er tæki til að búa til og stjórna gámaþyrpingum bæði á milli mismunandi véla og fullt af gámum á sömu vélinni.
Með því að nota swarm get ég ákvarðað hversu mörgum tilföngum ég mun úthluta til hvers ferlis og hversu mörgum ferlum sömu þjónustu ég mun ræsa, og innri jafnvægisbúnaðurinn, sem tekur á móti gögnum um tiltekna höfn, mun sjálfkrafa umboð til ferlanna. Þar sem álagið á netþjóninn hefur aukist get ég bætt við fleiri ferlum og þar með dregið úr álagi á ákveðna ferla.
9. Ráðstöfun
Ekki nota biðraðir til að vinna með ferla og gögn. Að drepa eitt ferli ætti að hafa áhrif á alla umsóknina. Ef ein þjónusta fer niður, þá fer allt niður.
Hægt er að slökkva á hverju ferli og þjónustu hvenær sem er og það ætti ekki að hafa áhrif á aðra þjónustu (það þýðir auðvitað ekki að þjónustan verði ekki tiltæk fyrir aðra þjónustu, heldur að önnur þjónusta slekkur ekki á sér eftir þessa). Ljúka verður öllum ferlum með þokkabót, þannig að þegar þeim er hætt, skemmist engin gögn og kerfið virkar rétt næst þegar þú kveikir á því. Það er, jafnvel ef um neyðaruppsögn er að ræða, ættu gögnin ekki að skemmast (viðskiptakerfið hentar hér, fyrirspurnir í gagnagrunninum virka aðeins í hópum og ef að minnsta kosti ein fyrirspurn úr hópnum mistekst eða er keyrð með villa, þá mistekst engin önnur fyrirspurn frá hópnum að lokum).
10. Umsóknarþróun/rekstrarjafnvægi
Framleiðsla, sviðsetning og staðbundin útgáfa af forritinu verður að vera öðruvísi. Í framleiðslu notum við Yii Lite ramma, og staðbundið Yii, þannig að það virkar hraðar í framleiðslu!
Í raun og veru ætti öll dreifing og vinna með kóða að vera í nánast eins umhverfi (við erum ekki að tala um líkamlegan vélbúnað). Einnig ætti hvaða þróunarstarfsmaður sem er að geta sett kóðann í framleiðslu ef þörf krefur, en ekki einhver sérþjálfuð devops deild, sem aðeins þökk sé sérstökum styrkleika getur lyft forritinu í framleiðslu.
Docker hjálpar okkur líka með þetta. Ef farið er eftir öllum fyrri atriðum mun notkun docker færa ferlið við að dreifa umhverfinu bæði í framleiðslu og á staðbundinni vél til að slá inn eina eða tvær skipanir.
11. Logs
Við skrifum logs í skrár og gagnagrunna! Við hreinsum ekki skrár og gagnagrunna úr annálum. Við skulum bara kaupa harðan disk með 9000 Peta bætum og það er allt í lagi.
Líta ætti á allar skrár sem straum atburða. Umsóknin sjálf ætti ekki að taka þátt í vinnslu annála. Logs ætti að vera framleitt annaðhvort til stdout eða sent í gegnum samskiptareglur eins og udp, svo að vinna með logs skapar ekki vandamál fyrir forritið. Graylog er góður fyrir þetta. Graylog tekur á móti öllum annálum í gegnum udp (þessi siðareglur krefst ekki að bíða eftir svari um árangursríka móttöku pakkans) truflar ekki forritið á nokkurn hátt og fjallar aðeins um uppbyggingu og vinnslu annála. Umsóknarrökfræðin breytist ekki til að vinna með slíkum aðferðum.
12. Umsýsluverkefni
Til að uppfæra gögn, gagnagrunna o.s.frv., notaðu sérstakan endapunkt í API, ef það er keyrt 2 sinnum í röð mun allt verða afritað. En þú ert ekki heimskur, þú munt ekki smella tvisvar og við þurfum ekki flutning.
Öll stjórnunarverkefni ættu að fara fram í sama umhverfi og öll kóða, á útgáfustigi. Það er, ef við þurfum að breyta uppbyggingu gagnagrunnsins, þá munum við ekki gera það handvirkt með því að breyta nöfnum dálka og bæta við nýjum í gegnum nokkur sjónræn gagnagrunnsstjórnunartæki. Fyrir slíka hluti búum við til aðskilin forskrift - flutninga, sem eru framkvæmd alls staðar og í öllum umhverfi á sama hátt með sameiginlegri og skiljanlegri niðurstöðu. Fyrir öll önnur verkefni, eins og að fylla verkefnið af gögnum, ætti að nota svipaða aðferðafræði.
Dæmi um útfærslu í PHP, Laravel, Laradock, Docker-Compose
PS Öll dæmi voru gerð á MacOS. Flestar þeirra henta líka fyrir Linux. Windows notendur, fyrirgefðu mér, en ég hef ekki unnið með Windows í langan tíma.
Við skulum ímynda okkur aðstæður þar sem við höfum enga útgáfu af PHP uppsett á tölvunni okkar og alls ekkert.
Settu upp nýjustu útgáfur af docker og docker-compose. (þetta er að finna á netinu)
docker -v &&
docker-compose -v
1. Settu
git clone https://github.com/Laradock/laradock.git &&
ls
Varðandi Laradock segi ég að það er mjög flott hlutur sem inniheldur mikið af ílátum og aukahlutum. En ég myndi ekki mæla með því að nota Laradock sem slíkan án breytinga á framleiðslu vegna offramboðs þess. Það er betra að búa til þína eigin gáma byggða á dæmum í Laradock, þetta verður mun hagstæðara, því enginn þarf allt sem er til staðar á sama tíma.
2. Stilltu Laradock til að keyra forritið okkar.
cd laradock &&
cp env-example .env
2.1. Opnaðu habr möppuna (foreldramöppuna sem laradock er klónað í) í einhverjum ritstjóra. (Í mínu PHPStorm tilfelli)
Á þessu stigi gefum við verkefninu aðeins nafn.
2.2. Ræstu mynd vinnusvæðisins. (Í þínu tilviki mun taka myndirnar nokkurn tíma að smíða)
Workspace er sérútbúin mynd til að vinna með rammann fyrir hönd framkvæmdaraðila.
Við förum inn í gáminn með því að nota
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Er að setja upp Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. Eftir uppsetningu athugum við hvort skráin með verkefninu hafi verið búin til og drepum compose.
ls
exit
docker-compose down
2.5. Við skulum fara aftur í PHPStorm og setja rétta slóð að laravel forritinu okkar í .env skránni.
3. Bættu öllum kóðanum við Git.
Til að gera þetta munum við búa til geymslu á Github (eða annars staðar). Við skulum fara í habr möppuna í flugstöðinni og keyra eftirfarandi kóða.
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
Athugum hvort allt sé í lagi.
Til þæginda mæli ég með því að nota eitthvað sjónrænt viðmót fyrir Git, í mínu tilfelli er það . (hér er tilvísunartengill)
4. Við skulum ræsa!
Áður en byrjað er skaltu ganga úr skugga um að ekkert hangi á höfnum 80 og 443.
docker-compose up -d nginx php-fpm
Þannig samanstendur verkefnið okkar af 3 aðskildum þjónustum:
- nginx - vefþjónn
- php-fpm - php til að taka á móti beiðnum frá vefþjóni
- vinnusvæði - php fyrir forritara
Í augnablikinu höfum við náð að búa til umsókn sem uppfyllir 4 stig af 12, þ.e.
1. Kóðagrunnur — allur kóðinn er í einni geymslu (lítil athugasemd: það gæti verið rétt að bæta við docker inn í laravel verkefnið, en þetta er ekki mikilvægt).
2. Ósjálfstæði - Öll ósjálfstæði okkar eru beinlínis skrifuð í application/composer.json og í hverri Dockerfile hvers íláts.
3. Stuðningsþjónusta — Hver þjónusta (php-fom, nignx, vinnusvæði) lifir sínu eigin lífi og er tengd utan frá og þegar unnið er með aðra þjónustu verður hin ekki fyrir áhrifum.
4. Ferlarnir — hver þjónusta er eitt ferli. Hver þjónusta heldur ekki innra ástandi.
5. Hafnarbinding
docker ps
Eins og við sjáum keyrir hver þjónusta á eigin höfn og er aðgengileg öllum öðrum þjónustum.
6. Samhliða
Docker gerir okkur kleift að hleypa af stað mörgum ferlum sömu þjónustu með sjálfvirkri álagsjöfnun á milli þeirra.
Stöðvum gámana og keyrum þá í gegnum fánann --kvarði
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Eins og við sjáum hafa afrit verið búin til af php-fpm gámnum. Við þurfum ekki að breyta neinu við að vinna með þennan ílát. Við höldum líka áfram að fá aðgang að því á höfn 9000 og Docker stjórnar hleðslunni á milli gáma fyrir okkur.
7. Einnotahæfni - Hægt er að drepa hvert ílát án þess að skaða hitt. Að stöðva eða endurræsa ílátið mun ekki hafa áhrif á virkni forritsins við síðari ræsingu. Einnig er hægt að lyfta hverjum gámi hvenær sem er.
8. Umsóknarþróun/rekstrarjafnvægi - allt umhverfi okkar er eins. Með því að keyra kerfið á netþjóni í framleiðslu þarftu ekki að breyta neinu í skipunum þínum. Allt verður byggt á Docker á sama hátt.
9. Skógarhögg — allar skrár í þessum gámum fara í streymi og eru sýnilegar í Docker stjórnborðinu. (í þessu tilfelli, reyndar með öðrum heimagerðum ílátum, gæti þetta ekki verið raunin ef þú sérð ekki um það)
docker-compose logs -f
En það er galli í því að sjálfgefin gildi í PHP og Nginx skrifa einnig logs í skrá. Til að mæta 12 þáttunum er það nauðsynlegt aftengja skrifa logs í skrá í stillingum hvers íláts fyrir sig.
Docker veitir einnig möguleika á að senda logs, ekki bara til stdout, heldur einnig til slíkra hluta eins og greylog, sem ég nefndi hér að ofan. Og inni í Graylog getum við stjórnað annálunum eins og við viljum og umsókn okkar mun ekki taka eftir þessu á nokkurn hátt.
10. Stjórnsýsluverkefni — öll stjórnunarverkefni eru leyst af laravel þökk sé handverkstækinu nákvæmlega eins og höfundar 12 þátta forritsins vilja.
Sem dæmi mun ég sýna hvernig sumar skipanir eru framkvæmdar.
Við förum inn í gáminn.
docker-compose exec workspace bash
php artisan list
Nú getum við notað hvaða skipun sem er. (vinsamlega athugið að við stilltum ekki gagnagrunninn og skyndiminni, þannig að helmingur skipana verður ekki keyrður rétt, vegna þess að þær eru hannaðar til að vinna með skyndiminni og gagnagrunninum).
11. Stillingar og 12. Byggja, sleppa, hlaupa
Mig langaði að tileinka þennan hluta Blue-Green Deployment, en hann reyndist vera of umfangsmikill fyrir þessa grein. Ég mun skrifa sérstaka grein um þetta.
Í hnotskurn er hugmyndin byggð á CI/CD kerfum eins og Jenkins и Gitlab CI. Í báðum er hægt að stilla umhverfisbreytur sem tengjast ákveðnu umhverfi. Samkvæmt því, í þessari stöðu, verður c-liður uppfylltur Stillingar.
Og punkturinn um Byggja, sleppa, hlaupa er leyst með innbyggðum aðgerðum með nafninu Leiðslukerfi.
Leiðslukerfi gerir þér kleift að skipta dreifingarferlinu upp í mörg stig og undirstrika stig samsetningar, útgáfu og framkvæmdar. Einnig í Pipeline geturðu búið til afrit, og raunar hvað sem er. Þetta er tæki með takmarkalausa möguleika.
Umsóknarkóði er kl .
Ekki gleyma að frumstilla undireininguna þegar þú klónar þessa geymslu.
PS: Allar þessar aðferðir er hægt að nota með öllum öðrum tólum og forritunarmálum. Aðalatriðið er að kjarninn er ekki frábrugðinn.
Heimild: www.habr.com