Fillimish, pak teori. ĂfarĂ« Ă«shtĂ« ?
Me fjalë të thjeshta, ky është një dokument që ka për qëllim të thjeshtojë zhvillimin e aplikacioneve SaaS, duke ndihmuar ata që informon zhvilluesit dhe inxhinierët DevOps për problemet dhe praktikat që shpesh hasen në zhvillimin e aplikacioneve moderne.
Dokumenti është formuar nga zhvilluesit e platformës Heroku.
Metodologjia e dymbëdhjetë faktorëve (The Twelve-Factor App) mund të aplikohet për aplikacione të shkruara në çdo gjuhë programuese dhe që përdorin çdo kombinim të shërbimeve të jashtme (backing services) (baza të dhënash, radhë mesazhesh, cache etj.).
Në shkurt, për faktorët mbi të cilët ndëstohet kjo metodologji:
- Baza e kodit â NjĂ« bazĂ« kodimi, e ndjekur nĂ« sistemin e kontrollit tĂ« versioneve â shumĂ« shpĂ«rndarje
- VarĂ«sitĂ« â Deklaroni dhe izoloni qartĂ« varĂ«sitĂ«
- Konfigurimi â Ruani konfigurimin nĂ« mjedisin e ekzekutimit
- ShĂ«rbimet e jashtme (Backing Services) â Merrni shĂ«rbimet e jashtme (backing services) si burime tĂ« lidhura
- NdĂ«rtimi, lĂ«shimi, ekzekutimi â Ndani me rigoroze fazat e ndĂ«rtimit dhe ekzekutimit
- Proceset â Ekzekutoni aplikacionin si njĂ« ose disa procese pa ruajtur gjendjen e brendshme (stateless)
- Pengimi i porteve (Port binding) â Ekspozoni shĂ«rbimet pĂ«rmes pengimit tĂ« porteve
- Paralelizmi â ShkallĂ«zoni aplikacionin me procese
- ShkallĂ«zueshmĂ«ria (Disposability) â Maksimizoni besueshmĂ«rinĂ« me nisje tĂ« shpejtĂ« dhe pĂ«rfundime tĂ« sakta
- Pariteti i zhvillimit/punĂ«s sĂ« aplikacionit â Mbani mjediset e zhvillimit, shpĂ«rndarjes pĂ«r provĂ« (staging) dhe shpĂ«rndarjes nĂ« prodhim (production) sa mĂ« tĂ« ngjashme
- Regjistrimi (Logs) â Konsideroni regjistrimin si njĂ« rrjedhĂ« eventesh
- Detyrat e administratĂ«s â Kryeni detyrat e administratĂ«s/me menaxhimin pĂ«rmes proceseve njĂ«herĂ«sh
Më shumë informacion mbi 12 faktorët mund të merrni nga këto burime:
- â i domosdoshĂ«m pĂ«r t'u lexuar
- â pĂ«rkthimi zyrtar
- â njĂ« pĂ«rmbledhje e re mbi 12 faktorĂ«t me qĂ«llim pĂ«rmirĂ«simin e tyre.
ĂfarĂ« Ă«shtĂ« Blue-Green deployment?
Blue-Green deployment është një mënyrë për shpërndarjen e aplikacionit në production kështu që klienti përfundimtar nuk sheh asnjë ndryshim nga ana e tij. Në fjalë të tjera, implementimi i aplikacionit me zero ndërprerje.
Schema tradicionale BG Deploy duket ashtu siç është e treguar në imazhin më poshtë.
- Në fillim ka 2 servera fizikë me të njëjtin kod, aplikacion, projekt, dhe ka një router (balancues).
- Routeri fillimisht drejton të gjitha kërkesat në njërin prej serverëve (e blu).
- Në momentin kur është e nevojshme të bëni sërish një publikim, e gjithë projekti përmirësohet në serverin tjetër (alfa), i cili në atë moment nuk po përpunon asnjë kërkesë.
- Pasi kodi në serverin e kaltër është përmirësuar plotësisht, routeri merr udhëzimin për të kaluar nga i gjelbër në alfa server.
- Tani të gjithë klientët shikojnë rezultatin e punës së kodit nga i kaltër të serverit fizik.
- Një kohë të caktuar, e blu serveri shërben si një rezervë për rastin e dështimit të publikimit në alfa server dhe në rast dështimi dhe gabimesh, routeri kthen fluksin e përdoruesve përsëri në e blu serverin me versionin e vjetër stabil, dhe kodi i ri dërgohet për përmirësim dhe testim.
- Dhe në fund të procesit, po ashtu përmirësohet e blu serveri. Dhe pas përmirësimit të tij, routeri kthen fluksin e kërkesave përsëri në e blu server.
Kjo duket shumë mirë dhe në shikim të parë nuk duhet të ketë asnjë problem me të.
Por pasi që jetojmë në një botë moderne, opsioni i kalimit fizik ashtu siç tregohet në shëmën tradicionale nuk na përshtatet. Regjistroni informacionin tani, ne do të kthehemi tek ai më vonë.
Këshilla të këqija dhe të mira
Kufizimi: Në shembujt më poshtë janë shënuar utilitetet / metodologjitë që unë përdor, ju mund të përdorni çdo alternativë tjetër me funksione të ngjashme.
Pjesa më e madhe e shembujve do të hasë ndonjëherë me zhvillimin web (kjo është e papritur), me PHP dhe Docker.
Në pikat më poshtë jepet një përshkrim praktik i përdorimit të faktorëve në shembuj të caktuar, nëse dëshironi një teori më të thellë rreth këtij subjekti, referojuni lidhjeve më lart për burimin origjinal.
1. Baza e kodit
Përdorni FTP dhe FileZilla duke ngarkuar skedarët në serverë një nga një, mos e ruani kodin askund përveçse në serverin e prodhimit.
Në projekt duhet të ketë gjithmonë një bazë të vetme kodimi, domethënë, e gjithë kodi vjen nga një vend. Git repozitoreve. Serverët (production, staging, test1, test2 ...) përdorin kodin nga deget e një repo të përbashkët. Në këtë mënyrë arrijmë konsistencën e kodit.
2. Varësitë
Shkarkoni të gjitha bibliotekat në dosje direkt në rrënjën e projektit. Bëni përditësimet duke transferuar thjesht kodin e ri në dosjen me versionin aktual të bibliotekës. Instaloni të gjitha utilitarët direkt në serverin ku funksionojnë edhe 20 shërbime të tjera.
Projekti gjithmonë duhet të ketë një listë të qartë dhe të kuptueshme të varësive (nën varësi mendoj gjithashtu dhe ambientin). Të gjitha varësitë duhet të jenë të përcaktuara qartë dhe të izoluara.
Si një shembull do të marrim Composer dhe Docker.
Composer â menaxherin e paketave qĂ« lejon tĂ« instaloni bibliotekat nĂ« PHP. Composer jep mundĂ«sinĂ« tĂ« tregoni versionet nĂ« mĂ«nyrĂ« strikte ose jo strikte dhe tâi pĂ«rcaktoni ato qartĂ«. NĂ« server mund tĂ« ketĂ« 20 projekte tĂ« ndryshme dhe çdo njĂ«ri do tĂ« ketĂ« listĂ«n e vet tĂ« pakove dhe bibliotekave qĂ« nuk varen nga njĂ«ri-tjetri.
Docker â utilitarin qĂ« lejon tĂ« pĂ«rcaktoni dhe izoloni ambientin nĂ« tĂ« cilin do tĂ« punojĂ« aplikacioni. NĂ« pĂ«rputhje me tĂ« njĂ«jtĂ«n logjikĂ« si me composer, por mĂ« thelbĂ«sisht, ne mund tĂ« pĂ«rcaktojmĂ« me çfarĂ« punon aplikacioni. Zgjidhni njĂ« version specifik tĂ« PHP, instaloni vetĂ«m paketat e nevojshme pĂ«r funksionimin e projektit, pa shtuar asgjĂ« tĂ« tepĂ«rt. Dhe mĂ« e rĂ«ndĂ«sishmja, pa u ndĂ«rprerĂ« me paketat dhe ambientin e makinerisĂ« pritĂ«se dhe projekteve tĂ« tjera. Pra, tĂ« gjitha projektet nĂ« server qĂ« funksionojnĂ« pĂ«rmes Docker-it, mund tĂ« pĂ«rdorin njĂ« set tĂ« çdo hapĂ«sire pakash dhe njĂ« ambient krejtĂ«sisht tĂ« ndryshĂ«m.
3. Konfigurimi
Ruani konfigurimet si konstanta drejtpërdrejt në kod. Konstanta të veçanta për serverin testues, të veçanta për prodhimin. Lidheni punën e aplikacionit në varësi të ambientit drejtpërdrejt në logjikën biznesore të projektit duke përdorur konstrukte if else.
Konfigurimet â kjo Ă«shtĂ« e vetmja gjĂ« me tĂ« cilĂ«n duhet tĂ« ndryshojnĂ« zbatimet e projektit (deployment). NĂ« mĂ«nyrĂ« ideale, konfigurimet duhet tĂ« transmetohen pĂ«rmes variablave tĂ« ambientit (env vars).
Pra ndaj, edhe nĂ«se do tĂ« ruani disa skedarĂ« konfigurimi .config.prod .config.local dhe do t'i rinominoni ata nĂ« momentin e implementimit nĂ« .config (konfigura kryesore nga e cila aplikacioni lexon tĂ« dhĂ«nat) â ky do tĂ« ishte njĂ« qasje e gabuar, pasi nĂ« kĂ«tĂ« rast informacioni nga konfigurimet do tĂ« ishte i qasshĂ«m pĂ«r tĂ« gjithĂ« zhvilluesit e aplikacionit dhe tĂ« dhĂ«nat nga serveri i prodhimit do tĂ« kompromitoheshin. TĂ« gjitha konfigurimet duhet tĂ« ruhen drejtpĂ«rdrejt nĂ« sistemin e implementimit (CI/CD) dhe tĂ« gjenerohen pĂ«r ambjente tĂ« ndryshme me vlera tĂ« ndryshme tĂ« nevojshme pĂ«r ambjentin specifik pikĂ«risht nĂ« momentin e implementimit.
4. Shërbime të jashtme (Backing Services)
Zgjidhni fort ambjentin, përdorni lidhje të ndryshme për të njëjtat shërbime në ambjente të caktuara.
Në të vërtetë, ky pikë fort e kryqëzon me pikën mbi konfigurimet, sepse pa këtë pikë, nuk është e mundur të krijoni të dhëna të mirë për konfigurim dhe mundësia e konfigurimit do të humbasë krejtësisht.
Të gjitha lidhjet me shërbime të jashtme, si serverat e radhës, bazat e të dhënave, shërbimet e caching duhet të jenë të njëjta si për ambjentin lokal ashtu edhe për ambjentin e jashtëm / prodhimit. Në fjalë të tjera, në çdo moment unë mund ta ndryshoj vargun e lidhjes për të zëvendësuar referencat nga baza #1 në bazën #2 pa ndryshuar kodin e aplikacionit. Ose duke shkuar më përpara, si një shembull, kjo do të ishte e përshtatshme në rast të shkallëzimit të shërbimit, nuk do t'ju duhet të jepni një lidhje të veçantë për serverin e shtesë të cache.
5. Ndërtimi, lëshimi, ekzekutimi
Keni në server vetëm versionin përfundimtar të kodit, pa mundësi për të kthyer lëshimin përsëri. Nuk duhet të bllokoni hapësirën e disqet. Kush mendon se mund të dërgojë kod në prodhim me një gabim, është një programues i keq!
Të gjitha fazat e implementimit duhet të ndahen nga njëra-tjetra.
Keni mundësinë të ktheheni prapa. Bëni lëshime duke ruajtur në mënyrë të shpejtë kopje të vjetra të aplikacionit (të ndërtuara dhe gati për luftë), në mënyrë që në rast gabimesh të riktheni versionin e vjetër. Pra, në një mënyrë të caktuar ka një dosje releases dhe një dosje current, dhe pas një implementimi dhe ndërtimi të suksesshëm, dosja current lidhet me një lidhje simbolike me lëshimin e ri që ndodhet brenda releases me një emër të mundshëm numrin e lëshimit.
Këtu na kujtohet për Blue-Green deployment, i cili lejon jo vetëm kalimin mes kodit, por gjithashtu edhe kalimin mes të gjitha burimeve dhe madje edhe ambienteve me mundësinë për ta rikthyer gjithçka mbrapsht.
6. Proceset
Ruani të dhënat e gjendjeve të aplikacionit direkt në vetë aplikacionin. Përdorni sesionet në memorjen operuese të aplikacionit. Përdorni sa më shumë të dhëna të ndara ndërmjet shërbimeve të jashtme. Kufizohuni me faktin se aplikacioni mund të ketë vetëm një proces dhe mos lejoni mundësinë e shkallëzimit.
Sa i përket sesioneve, ruani të dhënat vetëm në cache të kontrolluar nga shërbime të jashtme (memcached, redis), kështu që, edhe nëse keni 20 procese të aplikacionit të nisura, çdokush prej tyre duke kontaktuar në cache mund të vazhdojë të punojë me klientin në të njëjtin gjendje që përdoruesi ishte duke punuar me aplikacionin në një proces tjetër. Me këtë qasje, pavarësisht sa kopje shërbimesh të jashtme përdorni, gjithçka do të funksionojë në mënyrë normale dhe pa probleme me aksesin në të dhëna.
7. Ndërprerja e porteve (Port binding)
Vetëm serveri i internetit duhet të dijë se si të punojë me shërbimet e jashtme. Në të vërtetë, është më mirë t'i ngrehësh shërbimet e jashtme brenda serverit të internetit. Për shembull, si një modul PHP në Apache.
Të gjitha shërbimet tuaja duhet të jenë të qasshme njëra-tjetrës përmes kontaktit me një adresë dhe port (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), do të thotë se nga nginx mund të kem qasje si në php-fpm ashtu edhe në postgres, dhe nga php-fpm në postgres dhe nginx, dhe në përfundim nga çdo shërbim mund të ketë qasje në një shërbim tjetër. Kështu, vitaliteti i shërbimit nuk është i varur nga vitaliteti i shërbimit tjetër.
8. Paralelizmi
Puna me një proces, ndryshe disa procese nuk do të mund të bien dakord me njëri-tjetrin!
Lini mundësinë për shkallëzim. Docker swarm është i përsosur për këtë.
Docker Swarm është një mjet për krijimin dhe menaxhimin e grupeve të kontejnerëve si midis makinave të ndryshme ashtu edhe një grumbulli kontejnerësh në një makinë.
Duke përdorimi i swarm, unë mund të përcaktoj se sa burime do të ndaj për çdo proces dhe sa procese të një shërbimi të njëjtë do të startoj, ndërsa balancuesi i brendshëm, duke marrë të dhënat në portin e caktuar, automatikisht do t'i proksizojë ato te proceset. Kështu, duke vërejtur që ngarkesa në server u rrit, unë mund të shtoj më shumë procese, duke ulur kështu ngarkesën në procese të caktuara.
9. Shfrytëzueshmëria (Disposability)
Mos përdorni rradha për të punuar me procese dhe të dhëna. Vrasja e një procesi duhet të ndikojë në funksionimin e gjithë aplikacionit. Nëse një shërbim bie - gjithçka bie.
Ădo proces dhe shĂ«rbim mund tĂ« fiket nĂ« çdo moment dhe kjo nuk duhet tĂ« ndikojĂ« nĂ« shĂ«rbimet e tjera (nuk flasim kĂ«tu pĂ«r çështjen qĂ« shĂ«rbimi do tĂ« jetĂ« i paqasshĂ«m pĂ«r shĂ«rbimin tjetĂ«r, por pĂ«r atĂ« qĂ« shĂ«rbimi tjetĂ«r nuk do tĂ« fiket pas kĂ«tij). TĂ« gjithĂ« proceset duhet tĂ« pĂ«rfundojnĂ« butĂ«sisht, nĂ« mĂ«nyrĂ« qĂ« gjatĂ« pĂ«rfundimit tĂ« mos humbasin tĂ« dhĂ«nat dhe nĂ« aktivizimin e ardhshĂ«m, sistemi tĂ« funksionojĂ« siç duhet. Pra, edhe nĂ« rast tĂ« njĂ« pĂ«rfundimi emergjent, tĂ« dhĂ«nat nuk duhet tĂ« dĂ«mtohen (kĂ«tu do tĂ« ishte e pĂ«rshtatshme mekanizmi i transaksioneve, kĂ«rkesat nĂ« db punojnĂ« vetĂ«m nĂ« grupe, dhe nĂ«se ndonjĂ« kĂ«rkesĂ« nga grupi nuk Ă«shtĂ« ekzekutuar ose Ă«shtĂ« ekzekutuar me gabim, atĂ«herĂ« asnjĂ« kĂ«rkesĂ« tjetĂ«r nga grupi nuk ekzekutohet nĂ« realitet).
10. Pariteti i zhvillimit/punës së aplikacionit
Produksioni, staging dhe versione lokale e aplikacionit duhet të jenë të ndryshme. Në prodhim kemi framework-un Yii Lite, ndërsa lokalisht Yii, që të funksionojë më shpejt në prodhim!
Në fakt, të gjitha deploymentet dhe puna me kodin duhet të jenë pothuajse në një ambient identik (nuk bëhet fjalë për harduerin fizik). Po ashtu, për të deploy në prodhim në rast nevoje, duhet të jetë në gjendje të bëjë çdo punonjës i zhvillimit, jo ndonjë departament i veçantë devops, që vetëm falë ndonjë fuqie të veçantë mund të ngritë aplikacionin në prodhim.
Në këtë na ndihmon gjithashtu Docker. Duke respektuar të gjithë pikat e mëparshme, përdorimi i docker-it do ta sjellë procesin e vendosjes së ambientit si në prodhim ashtu edhe në makinën lokale deri në futjen e një ose dy komandave.
11. Regjistrimi (Logs)
Regjistrat shkruhen në skedarë dhe db! Skedarët dhe db për regjistrat nuk pastrohen. Do të blejmë thjesht një hard disk me 9000 Petabyte dhe është në rregull.
Të gjitha logjët duhet të konsiderohen si një rrjedhë ngjarjesh. Aplikacioni nuk duhet të merret me përpunimin e logjeve. Logjet duhet të dërgohen ose në stdout, ose të transmetohen përmes një protokolli si udp, në mënyrë që përdorimi i logjeve nga aplikacioni të mos krijojë asnjë problem. Për këtë, graylog është një zgjedhje e shkëlqyer. Graylog, duke pranuar të gjitha logjet përmes udp (me këtë protokoll nuk është e nevojshme të presësh një përgjigje për pranimin e suksesshëm të paketës), nuk pengon aplikacionin në asnjë mënyrë dhe merret vetëm me strukturimin dhe përpunimin e logjeve. Logjika e aplikacionit nuk ndryshon për të punuar me qasje të tilla.
12. Detyrat e administratës
Për të përditësuar të dhënat, bazën e të dhënave, etj., përdorni një endpoint të krijuar veçmas në API, ekzekutimi i të cilit dy herë radhazi do të çojë në dëmtimin e të dhënave tuaja. Por ju nuk jeni budallenj, nuk do të klikoni dy herë, dhe migrimet nuk na nevojiten.
TĂ« gjitha detyrat e administratĂ«s duhet tĂ« ekzekutohen nĂ« tĂ« njĂ«jtĂ«n mjedis si gjithĂ« kodi, nĂ« nivelin e lĂ«shimeve. Pra, nĂ«se na duhet tĂ« ndryshojmĂ« strukturĂ«n e bazĂ«s sĂ« tĂ« dhĂ«nave, ne nuk do ta bĂ«jmĂ« kĂ«tĂ« manualisht duke ndryshuar emrat e kolonave dhe duke shtuar tĂ« reja pĂ«rmes ndonjĂ« mjeti vizual tĂ« menaxhimit tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave. PĂ«r gjĂ«ra tĂ« tilla, ne krijojmĂ« skripte tĂ« veçanta â migrime, qĂ« pĂ«rfundohen nĂ« çdo ambient dhe tĂ« gjitha nĂ« tĂ« njĂ«jtĂ«n mĂ«nyrĂ« me njĂ« rezultat tĂ« qartĂ« dhe tĂ« kuptueshĂ«m. PĂ«r tĂ« gjitha detyrat e tjera, si mbushja e projektit me tĂ« dhĂ«na, duhen aplikuar metodologji tĂ« ngjashme.
Shembulli i implementimit në PHP, Laravel, Laradock, Docker-Compose
P.S Të gjitha shembujt u bënë në MacOS. Pjesa më e madhe do të përshtatet dhe për Linux. Përdoruesit e Windows, më falni, por nuk kam punuar me Windows prej një kohë.
Imagjinoni një situatë ku në PC-në tonë nuk është instaluar asnjë version PHP dhe asgjë tjetër.
Instalojmë docker dhe docker-compose versionet më të fundit. (këtë mund ta gjeni në internet)
docker -v &&
docker-compose -v
1. Instaloni
git clone https://github.com/Laradock/laradock.git &&
ls
NĂ« lidhje me Laradock do tĂ« them qĂ« Ă«shtĂ« njĂ« gjĂ« shumĂ« e shkĂ«lqyer, ku janĂ« mbledhur shumĂ« kontejnerĂ« dhe gjĂ«ra ndihmĂ«se. Por ta pĂ«rdorni Laradock si tĂ« tillĂ« pa modifikime nĂ« prodhim â nuk do ta rekomandoja pĂ«r shkak tĂ« tepricĂ«s sĂ« tij. MĂ« mirĂ« Ă«shtĂ« tĂ« krijoni kontejnerĂ«t tuaj duke u mbĂ«shtetur nĂ« shembujt nĂ« Laradock, kĂ«shtu do tĂ« ketĂ« mĂ« shumĂ« optimizim, pasi askujt nuk i nevojiten gjithçka qĂ« ka atje njĂ«kohĂ«sisht.
2. Konfiguroni Laradock për të punuar me aplikacionin tonë.
cd laradock &&
cp env-example .env
2.1. Hapim katalogun habr (folderi prindor ku është klonuar laradock) në ndonjë editor. (Në rastin tim PHPStorm)
Në këtë fazë vendosim vetëm emrin e projektit.
2.2. Aktivizojmë imazhin workspace. (Në rastin tuaj imazhet do të ndërtohen për njëfarë kohe)
Workspace është një imazh i përgatitur posaçërisht për të punuar me framework-un nga perspektiva e zhvilluesit.
Hyrim brenda kontejnerit me ndihmën e
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Instalojmë Laravel
composer create-project --prefer-dist laravel/laravel application 
2.4. Pas instalimit kontrollojmë nëse është krijuar direktoria me projektin, dhe ndalojmë compose.
ls
exit
docker-compose down
2.5. Kthehemi në PHPStorm dhe vendosim rrugën e saktë për aplikacionin tonë laravel në skedarin .env.
3. Shtojmë të gjithë kodin në Git.
Për këtë krijojmë një depo në Github (ose diku tjetër). Shkëmbejmë në terminal në direktorinë habr dhe ekzekutojmë kodin e mëposhtëm.
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 # këtu do të jetë lidhja për repos tuaj
git push -u origin master
git status
Kontrollojmë nëse gjithçka është në rregull.
Për lehtësinë tuaj rekomandoj të përdorni ndonjë ndërfaqe vizuale për Git, në rastin tim kjo është . (këtu është lidhja referuese)
4. Aktivizoni!
Para aktivizimit sigurohuni që në portet 80 dhe 443 nuk ka asgjë të përfshirë.
docker-compose up -d nginx php-fpm 
Kështu projekti ynë përbëhet nga 3 shërbime të veçanta:
- nginx â serveri web
- php-fpm â php pĂ«r trajtimin e kĂ«rkesave nga serveri web
- workspace â php pĂ«r zhvilluesin
Derisa kemi arritur të krijojmë një aplikacion në përputhje, tashmë 4 pika nga 12, në veçanti:
1. Baza e kodit â i gjithĂ« kodi ndodhet nĂ« njĂ« depo (njĂ« vĂ«rejtje e vogĂ«l: ndoshta Ă«shtĂ« mĂ« e saktĂ« tĂ« futur docker brenda projektit laravel, por kjo nuk Ă«shtĂ« thelbĂ«sore).
2. VarĂ«sitĂ« â TĂ« gjitha varĂ«sitĂ« tona janĂ« shprehur qartĂ« nĂ« application/composer.json dhe nĂ« çdo Dockerfile tĂ« çdo kontejneri.
3. ShĂ«rbimet e jashtme (Backing Services) â Ădo shĂ«rbim (php-fom, nginx, workspace) jeton jetĂ«n e tij dhe lidhet nga jashtĂ« dhe gjatĂ« punĂ«s me njĂ« shĂ«rbim, tjetri nuk do tĂ« preket.
4. Proceset â çdo shĂ«rbim Ă«shtĂ« njĂ« proces i vetĂ«m. Ădo shĂ«rbim nuk ruan gjendjen e brendshme.
5. Pengimi i porteve (Port binding)
docker ps
Siç e shohim, çdo shërbim është aktivizuar në portin e tij të vet dhe është i aksesueshëm për të gjitha shërbimet e tjera.
6. Paralelizmi
Docker na lejon të ngritnim disa procese të të njëjtëve shërbime me balancimin automatik të ngarkesës ndërmjet tyre.
TĂ« ndalim kontejnerĂ«t dhe t'i aktivizojmĂ« ata pĂ«rmes flag âscale
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Si e shpesh, kontenieri php-fpm ka krijuar kopje. Ne punën me këtë kontenier nuk na nevojitet të ndryshojmë asgjë. Ne vazhdojmë ta përdorim atë në portin 9000, ndërsa Docker rregullon ngarkesën midis kontenierëve për ne.
7. ShkallĂ«zueshmĂ«ria (Disposability) â çdo kontenier mund tĂ« ndalet pa dĂ«mtuar tjetrin. Ndalesa ose rithemelimi i kontenierit nuk do tĂ« ndikojnĂ« nĂ« funksionimin e aplikacionit gjatĂ« startimeve tĂ« ardhshme. Ădo kontenier gjithashtu mund tĂ« ngrihet nĂ« çdo kohĂ«.
8. Pariteti i zhvillimit/punĂ«s sĂ« aplikacionit â tĂ« gjitha ambientet tona janĂ« tĂ« njĂ«jta. Duke e nisur sistemin nĂ« server nĂ« prodhim, nuk do t'ju duhet tĂ« ndryshoni asgjĂ« nĂ« komandat tuaja. TĂ« gjitha do tĂ« bazohen pikĂ«risht nĂ« Docker.
9. Regjistrimi (Logs) â tĂ« gjitha log-et nĂ« kĂ«to kontenierĂ« dalin dhe janĂ« tĂ« dukshme nĂ« konsolĂ«n Docker. (nĂ« kĂ«tĂ« rast, nĂ« tĂ« vĂ«rtetĂ«, me kontenierĂ« tĂ« dhĂ«nĂ« vetĂ«, mund tĂ« mos ndodhin kĂ«shtu nĂ«se nuk kujdeseni pĂ«r kĂ«tĂ«)
docker-compose logs -f 
Por, ka një problem se vlerat e paracaktuara në PHP dhe Nginx gjithashtu regjistrojnë log-et në skedarin. Për t'iu përmbajtur 12 faktorëve, është e nevojshme ndalon regjistrimi i log-eve në skedar në konfigurimet e çdo konteneri veçmas.
Docker gjithashtu ofron mundësinë për të rediagatuar log-et jo vetëm në stdout, por edhe në gjëra si graylog për të cilin flas më lart. Dhe brenda graylog, mund të operojmë me log-et si të duam dhe aplikacioni ynë nuk do ta vërehet këtë.
10. Detyrat e administratĂ«s â tĂ« gjitha detyrat e administratĂ«s zgjidhen nga laravel falĂ« mjetit artisan pikĂ«risht ashtu siç do tĂ« dĂ«shironin krijuesit e aplikacioneve 12 faktorĂ«she.
Siç e tregoj si shembull, shohim si ekzekutohen disa komanda.
Hyni në kontenier.
docker-compose exec workspace bash
php artisan list
Tani mund të përdorim çdo komandë. (kini parasysh që ne nuk e kemi konfiguruar bazën e të dhënave dhe cache-n, kështu që gjysma e komandave nuk do të funksionojë siç duhet, pasi ato janë të destinuara për të punuar me cache-n dhe bazën e të dhënave).
11. Konfigurimet dhe 12. Ndërtimi, lëshimi, ekzekutimi
Këtë pjesë doja ta dedikoj për Blue-Green Deployment, por kjo u tregua tepër e gjerë për këtë artikull. Për këtë do të shkruaj një artikull të veçantë.
Në dy fjalë, koncepti ndërtoset mbi sistemet CI/CD si Jenkins dhe Gitlab CI. Në të dyja mund të vendosen variablat e mjedisit të lidhura me ambientin specifik. Ndërkohë, në një skenar të tillë, do të zbatohet pika me Konfigurimet.
Dhe pika për Ndërtimi, lëshimi, ekzekutimi zgjidhet përmes funksioneve të integruara në të dy utilitetet me emrin Pipeline.
Pipeline lejon të ndash në shumë etapa procesin e deploy-imit, duke ndarë fazat e ndërtimit, lëshimit dhe ekzekutimit. Po ashtu në Pipeline, do të keni mundësi të krijoni backup-e, madje edhe gjithçka tjetër. Ky mjet ka potencial të pafund.
Kodi i aplikacionit ndodhet në .
Mos harroni të inicializoni submodule gjatë klonimit të këtij repository.
P.S.: Të gjitha këto qasje mund të përdoren me çdo utilitar tjetër dhe gjuhë programimi. E rëndësishme është që thelbi të mos ndryshojë.
Burimi: habr.com
