Filloni me 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 zhvilluesit dhe inxhinierët DevOps të jenë të vetëdijshëm për praktikat dhe problemet që hasen shpesh në zhvillimin e aplikacioneve moderne.
Dokumenti është krijuar 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ë programimi dhe që përdorin çdo kombinim shërbimesh të jashtme (backing services) (baza të dhënash, radhë mesazhesh, memoria në cache, etj.).
Me shkurt për faktorët mbi të cilët bazohet kjo metodologji:
- Kodi i bazĂ«s â NjĂ« bazĂ« kodi, e ndjekur nĂ« sistemin e kontrollit tĂ« versioneve, â shumĂ« shpĂ«rndarje
- VarĂ«sitĂ« â Deklaroni qartĂ« dhe izolojini varĂ«sitĂ«
- Konfigurimi â Ruani konfigurimin nĂ« ambientin e ekzekutimit
- ShĂ«rbimet e jashtme (Backing Services) â Trajtoni shĂ«rbimet e jashtme (backing services) si burime tĂ« lidhura
- NdĂ«rtimi, lĂ«shimi, ekzekutimi â Ndani nĂ« mĂ«nyrĂ« strikte fazat e ndĂ«rtimit dhe tĂ« ekzekutimit
- Proceset â Ekzekutoni aplikacionin si njĂ« ose disa procese pa gjendje tĂ« brendshme (stateless)
- Lidhja e porteve (Port binding) â Eksportoni shĂ«rbimet pĂ«rmes lidhjes sĂ« porteve
- Paralelizmi â ShkallĂ«zoni aplikacionin me ndihmĂ«n e proceseve
- BashkĂ«punueshmĂ«ria (Disposability) â Maksimizoni besueshmĂ«rinĂ« me njĂ« fillim tĂ« shpejtĂ« dhe njĂ« pĂ«rfundim korrekt
- Barazia e zhvillimit/ekzekutimit tĂ« aplikacionit â Mbani ambientet e zhvillimit, lĂ«shimit pĂ«r ndihmĂ« (staging) dhe lĂ«shimit nĂ« prodhim (production) sa mĂ« tĂ« ngjashme
- Diengimi (Logs) â Shikoni regjistrin si njĂ« rrjedhĂ« ngjarjesh
- Detyrat e adminstrimit â Kryeni detyrat e administratĂ«s/menaxhimit me procese tĂ« pĂ«rkohshme
Më shumë informacion mbi 12 faktorët mund të merrni nga burimet e mëposhtme:
- â patjetĂ«r pĂ«r t'u lexuar
- â pĂ«rkthimi zyrtar
- â njĂ« pamje 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 të dorëzuar aplikacionin në production një mënyrë që klienti i fundit nuk sheh asnjë ndryshim nga ana e tij. Me fjalë të tjera, ndalesa e aplikacionit me zero downtime.
Skema klasike e BG Deploy duket siç është e paraqitur në imazhin më poshtë.
- Në fillim ka 2 serverë fizikë me kod, aplikacion dhe projekt të njëjta, dhe ka një router (balancues).
- Routeri fillimisht drejton të gjitha kërkesat në njërin nga serverët (e gjelbër).
- Në momentin që nevojitet të bëhet një lëshim tjetër, e gjithë projekti përditësohet në serverin tjetër (e blu), i cili në atë moment nuk po përpunon asnjë kërkesë.
- Pas përditësimit të kodit në serverin e blugj routeri merr urdhërin për të kaluar nga në e blu server.
- jeshil Tani të gjithë klientët shohin rezultatin e punës së kodit nga Kryejnë sulme celulare.
- blugu e gjelbër Për një kohë, e blu serveri shërben si një kopje rezervë në rast të dështimit të lëshimit në e gjelbër server dhe në rast të dështimeve dhe defekteve, routeri kalon fluksin e përdoruesve përsëri në
- serverin e versionit të vjetër dhe stabil, dhe kodi i ri dërgohet për rishikim dhe testim. e gjelbër Dhe në fund të procesit, gjithashtu përditësohet e gjelbër server.
serveri. Pas përditësimit të tij, routeri kthen fluksin e kërkesave përsëri në
Të gjitha këto duken shumë mirë dhe në pamje të parë nuk duhet të kenë asnjë problem.
Por ngaqë jetojmë në një botë moderne, opsioni i kalimit fizik siç është i paraqitur në skemën klasike nuk na përshtatet. Ruani informacionin për tani, ne do të kthehemi te ai më vonë.
Shënim ligjorKëshilla të mira dhe të këqija
: Në shembujt më poshtë janë shfaqur utilitat/methodologjitë që unë përdor, mund të përdorni çdo alternativë që ka funksione të ngjashme.
Shumica e shembujve do të përfshijnë në një mënyrë ose tjetër zhvillimin e uebit (kjo ishte befasia), me PHP dhe Docker.
Në pikat më poshtë, do të jepet një përshkrim të thjeshtë praktik mbi përdorimin e faktorëve në shembuj të caktuar, nëse dëshironi të merrni më shumë teori në lidhje me këtë temë, referojuni lidhjeve më sipër për burimin.
1. Kodi i bazës
Përdorni FTP dhe FileZilla për të ngarkuar skedarët në serverë një nga një, mos e ruani kodin askund tjetër veçse në serverin e produksionit. Git Në projekt gjithmonë duhet të ketë një bazë kodi të vetme, që do të thotë se e gjithë kodi vjen nga një
repozit. ServerĂ«t (prodhim, skenim, test1, test2 âŠ) pĂ«rdorin kod nga degĂ«t e njĂ« repo zyrtar tĂ« pĂ«rbashkĂ«t. KĂ«shtu arrijmĂ« konsistencĂ« tĂ« kodit.
Descargoni të gjithë bibliotekat në dosje drejtpërdrejt në rrënjën e projektit. Bëni përditësimet thjesht duke transferuar kodin e ri në dosjen me versionin aktual të bibliotekës. Instaloni të gjitha utilitat e nevojshme drejtpërdrejt në serverin e hostit ku funksionojnë edhe 20 shërbime të tjera.
Projekti gjithmonë duhet të ketë një listë të qartë të varësive (nën varësi po ashtu kuptoj edhe mjedisin). Të gjitha varësitë duhet të jenë të përcaktuara qartë dhe të izoluara.
Si një shembull, le të marrim Composer dhe Docker.
Composer â njĂ« menaxher paketa, i cili lejon instalimin e bibliotekave nĂ« PHP. Composer ofron mundĂ«sinĂ« pĂ«r tĂ« pĂ«rcaktuar versionet nĂ« mĂ«nyrĂ« tĂ« rreptĂ« ose jo, dhe pĂ«r t'i pĂ«rcaktuar ato qartĂ«. NĂ« server mund tĂ« ketĂ« 20 projekte tĂ« ndryshme dhe secili do tĂ« ketĂ« listĂ«n e tij personale tĂ« paketave dhe bibliotekave, e cila nuk varet nga tĂ« tjerĂ«t.
Docker â njĂ« utilitet qĂ« lejon pĂ«rcaktimin dhe izolimin e mjedisit nĂ« tĂ« cilin do tĂ« funkcionalizojĂ« aplikacioni. SidoqoftĂ«, ashtu si me composer, por mĂ« thellĂ«sisht, ne mund tĂ« pĂ«rcaktojmĂ« me çfarĂ« punon aplikacioni. TĂ« zgjedhim njĂ« version tĂ« caktuar tĂ« PHP, tĂ« instalojmĂ« vetĂ«m paketat e nevojshme pĂ«r funksionimin e projektit, pa shtuar asgjĂ« tĂ« tepĂ«rt. MĂ« e rĂ«ndĂ«sishmja, tĂ« mos ndĂ«rthuren me paketa dhe mjedisin e makinĂ«s pritĂ«se dhe projekteve tĂ« tjera. KĂ«shtu, tĂ« gjitha projektet nĂ« server qĂ« funksionojnĂ« pĂ«rmes Docker, mund tĂ« pĂ«rdorin çdo set paketash dhe njĂ« mjedis tĂ«rĂ«sisht tĂ« ndryshĂ«m.
3. Konfigurimi
Ruani konfigurimet si konstanta drejtpërdrejt në kod. Konstanta të veçanta për serverin e testimit, të veçanta për prodhimin. Lidheni funksionimin e aplikacionit në varësi të mjedisit drejtpërdrejt në logjikën biznesore të projektit, duke përdorur struktura if else.
Konfigurimet â janĂ« e vetmja gjĂ« qĂ« duhet tĂ« ndryshojĂ« nĂ« implementimet e projektit. NĂ« mĂ«nyrĂ« ideale, konfigurimet duhet tĂ« kalohen pĂ«rmes variablve tĂ« mjedisit (env vars).
Pra, edhe nĂ«se do tĂ« ruani disa skedarĂ« konfigurimi .config.prod .config.local dhe t'i rindĂ«rroni ato gjatĂ« implementimit nĂ« .config (konfiguroja kryesore nga e cila aplikacioni lexon tĂ« dhĂ«nat) â kjo do tĂ« ishte njĂ« qasje e gabuar, pasi nĂ« kĂ«tĂ« rast informacioni nga konfigurimet do tĂ« ishte i arritshĂ«m pĂ«r tĂ« gjithĂ« zhvilluesit e aplikacionit, dhe tĂ« dhĂ«nat nga serveri i prodhimit do tĂ« ishin tĂ« komprometuar. TĂ« gjitha konfigurimet duhet tĂ« ruhen direkte nĂ« sistemin e implementimit (CI/CD) dhe tĂ« gjenerohen pĂ«r mjedise tĂ« ndryshme me vlera tĂ« ndryshme tĂ« nevojshme pĂ«r mjedisin specifik pikĂ«risht nĂ« momentin e implementimit.
4. Shërbimet e Jashtme (Backing Services)
Krijoni një lidhje të ngushtë me mjedisin, përdorni lidhje të ndryshme për shërbime të njëjta në mjedise të caktuara.
Në të vërtetë, ky pikë lidhet shumë me pikën mbi konfigurimet, pasi pa këtë pikë nuk do të jetë e mundur të krijoni të dhëna normale konfigurimi dhe në fakt mundësia e konfigurimit do të shuhen.
Të gjitha lidhjet me shërbime të jashtme, si serverat e radhës, bazat e të dhënave, shërbimet e keqitjes, duhet të jenë të njësuara si për mjedisin lokal, ashtu edhe për atë prodhuese. Me fjalë të tjera, në çdo moment unë mundem, duke ndryshuar një varg lidhjeje, të zëvendësoj referencat në bazën #1 me bazën #2 pa ndryshuar kodin e aplikacionit. Ose duke shkuar më tej, si një shembull do të ishte e mjaftueshme që gjatë shtrirjes së shërbimit, të mos keni nevojë të specifikoni lidhjen në ndonjë mënyrë të veçantë për një server shtesë të keqitjes.
5. Ndërtimi, lëshimi, ekzekutimi
Keni vetëm versionin përfundimtar të kodit në server, pa mundësi për të rikthyer lëshimin prapa. Mos e mbushni hapësirën e diskut. Ai që mendon se mund të dërgojë kodin në prodhim me një gabim, është një programues i keq!
Të gjitha fazat e implementimit duhet të ndahen nga njëra-tjetra.
Keni mundësi të riktheheni. Bëni lëshime duke ruajtur kopje të veçanta të aplikacionit (të ndërtuara tashmë dhe gati për përdorim), në mënyrë që në rast gabimesh të riktheni versionin e vjetër. Pra, ndryshe, ekziston 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 brenda releases me një emër të lëshimit.
Këtu ne kujtojmë mbi Blue-Green deployment, i cili lejon jo vetëm kalimin ndërmjet kodit, por gjithashtu kalimin ndërmjet të gjitha burimeve dhe mjediseve me mundësinë për të rikthyer gjithçka prapa.
6. Proceset
Ruani të dhënat e gjendjeve të aplikacionit drejtpërdrejt në aplikacionin vetë. Përdorni seanca në memorinë operative të aplikacionit. Përdorni sa më shumë që të jetë e mundur të ndara midis shërbimeve të jashtme. Lidheni se aplikacioni mund të ketë vetëm një proces dhe mos lejoni mundësinë e shtrirjes.
Në lidhje me seancat, ruhuni të dhënat vetëm në cache të kontrolluar nga shërbime të jashtme (memcached, redis), në këtë mënyrë, edhe nëse keni 20 procese aplikacioni të aktivizuara, çdo njëra prej tyre, duke kërkuar në cache, do të jetë në gjendje të vazhdojë të punojë me klientin në të njëjtin gjendje në të cilën përdoruesi ishte duke punuar me aplikacionin në procesin tjetër. Me këtë qasje, sa më shumë kopje shërbimesh të jashtme të përdorni, gjithçka do të funksionojë pa shqetësime dhe pa probleme në aksesin e të dhënave.
7. Lidhet porti (Port binding)
Vetëm serveri web duhet të dijë si të punojë me shërbimet e jashtme. Ose është më mirë t'i ngriheni shërbimet e jashtme drejtpërdrejt brenda serverit web. Për shembull, si një modul PHP në Apache.
Të gjitha shërbimet tuaja duhet të jenë të aksesueshme njëra nga tjetra duke u referuar në ndonjë adresë dhe port (localhost:5432, localhost:3000, nginx:80, php-fpm:9000), domethënë nga nginx mund të aksesoj php-fpm-në, si dhe postgres-in, dhe nga php-fpm mund të aksesoj postgres-in dhe nginx-in dhe në fakt nga çdo shërbim mund të aksesoj shërbimin tjetër. Në këtë mënyrë, jetësia e një shërbimi nuk është e varur nga jetësia e një shërbimi tjetër.
8. Paralelizmi
Punoni me një proces, sepse ndryshe ndonjëherë disa procese nuk do të arrijnë të bashkëpunojnë!
Lini mundësinë për t'u shkallëzuar. Docker Swarm është një zgjidhje e shkëlqyer për këtë.
Docker Swarm është një mjet për krijimin dhe menaxhimin e klasterëve të kontejnerëve si midis makinave të ndryshme ashtu edhe shumë kontejnerëve në një makinë.
Duke përdorur swarm, unë mund të përcaktoj se sa burime do të alokoj për çdo proces dhe sa procese të njëjtës shërbim do të aktivizoj, dhe balancuesi i brendshëm, duke pranuar të dhëna në një port të caktuar, do t'i proksojë automatikisht ato në proceset. Kështu, duke parë se ngarkesa në server ka rritur, unë mund të shtoj më shumë procese, duke zvogëluar kështu ngarkesën në procese të caktuara.
9. Eliminimi (Disposability)
Mos përdorni radhë për të punuar me procese dhe të dhëna. Vrasja e një procesi duhet të ndikojë në funksionimin e tërë 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 (nĂ« fakt nuk po flasim pĂ«r atĂ« se njĂ« shĂ«rbim do tĂ« jetĂ« i paaksesueshĂ«m pĂ«r njĂ« shĂ«rbim tjetĂ«r, por pĂ«r atĂ« se njĂ« shĂ«rbim tjetĂ«r nuk duhet tĂ« mbyllet pas kĂ«tij). TĂ« gjithĂ« proceset duhet tĂ« mbyllen butĂ«, nĂ« mĂ«nyrĂ« qĂ« gjatĂ« pĂ«rfundimit tĂ« tyre tĂ« mos dĂ«mtohen tĂ« dhĂ«nat dhe kur tĂ« ndizet pĂ«rsĂ«ri, sistemi tĂ« fillojĂ« tĂ« funksionojĂ« siç duhet. DomethĂ«nĂ«, edhe nĂ« rastin e njĂ« ndalimi tĂ« papritur, tĂ« dhĂ«nat nuk duhet tĂ« dĂ«mtohen (nĂ« kĂ«tĂ« rast do tĂ« ishte e dobishme mekanizmi i transaksioneve, kĂ«rkesat nĂ« db punojnĂ« vetĂ«m nĂ« grupe, dhe nĂ«se ndonjĂ« kĂ«rkesĂ« nga grupi nuk Ă«shtĂ« realizuar ose Ă«shtĂ« realizuar me gabim, asnjĂ« kĂ«rkesĂ« tjetĂ«r nga grupi nuk realizohet realisht).
10. Barazia e zhvillimit për aplikacionin
Produksioni, staging dhe versioni lokal i aplikacionit duhet të jenë të ndryshëm. Në prodhim kemi framework-un Yii Lite, ndërsa lokal kemi Yii, që të punojë më shpejt në prodhim!
Në të vërtetë, të gjitha lançimet dhe puna me kodin duhet të jenë pothuajse në një ambient identik (në fakt nuk po flasim për harduerin fizik). Gjithashtu, lançimi i kodit në prodhim, sipas nevojës, duhet të jetë në gjendje ta bëjë çdo staf i zhvillimit, dhe jo ndonjë departament i devops i trajnuar veçanërisht, i cili vetëm për shkak të një fuqie të veçantë mund të ngrejë aplikacionin në prodhim.
Këtu gjithashtu na ndihmon Docker. Duke respektuar të gjitha pikat e mëparshme, përdorimi i docker-it do ta çojë procesin e ngritjes të ambientit si në prodhim ashtu edhe në makinë lokale deri në ekzekutimin e një ose dy komandave.
11. Regjistrimi (Logs)
Regjistrat shkruhen në skedarë dhe db! Skedarët dhe db nga regjistrat nuk pastrohen. Thjesht blej një hard disk të 9000 Petabyte dhe e lamë atë.
Të gjitha regjistrat duhet të shqyrtohen si një fluks ngjarjesh. Aplikacioni vetë nuk duhet të merret me përpunimin e regjistrave. Regjistrat duhet të jepen ose në stdout, ose të dërgohen përmes një protokolli të tillë si udp, në mënyrë që puna me regjistrat të mos krijojë probleme për aplikacionin. Për këtë, graylog është një zgjedhje e shkëlqyer. Graylog-pranimi i të gjitha regjistrave përmes udp (me këtë protokoll nuk kërkohet të pritet përgjigje për pranimin e suksesshëm të pakos) nuk e pengon aplikacionin në asnjë mënyrë dhe merret vetëm me strukturimin dhe përpunimin e regjistrave. Logjika e aplikacionit nuk ndryshon për të punuar me këto qasje.
12. Detyrat e administratës
Për përditësimin e të dhënave, db etj, përdorni një endpoint të krijuar veçmas në api, ekzekutimi i të cilit dy herë radhazi do të shkaktojë që gjithçka mund të duplikatohet. Por ju nuk jeni të budall, nuk do të klikoni dy herë, dhe migrimet nuk na duhen.
TĂ« gjitha detyrat e administratĂ«s duhet tĂ« kryhen nĂ« tĂ« njĂ«jtĂ«n mjedis siç Ă«shtĂ« gjithĂ« kodi, nĂ« nivelin e çrelease. KĂ«shtu, nĂ«se na nevojitet 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Ă« vegle vizuale menaxhimi tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave. PĂ«r kĂ«to gjĂ«ra ne krijojmĂ« skripte tĂ« veçanta â migrime, tĂ« cilat kryhen nĂ« tĂ« gjithĂ« mjediset njĂ«soj me njĂ« rezultat tĂ« pĂ«rgjithshĂ«m dhe tĂ« qartĂ«. PĂ«r tĂ« gjitha detyrat e tjera, si pĂ«rmbushja e projektit me tĂ« dhĂ«na, duhet tĂ« aplikohet metodologji tĂ« ngjashme.
Shembulli i implementimit në PHP, Laravel, Laradock, Docker-Compose
P.S Të gjitha shembujt janë bërë në MacOS. Një pjesë e madhe do të përshtatet gjithashtu për Linux. Përdorues të Windows, më falni, por nuk kam punuar me Windows prej një kohë të gjatë.
Të imagjinojmë një situatë ku në PC-në tonë nuk është instaluar asnjë version i PHP dhe përgjithësisht nuk ka asgjë.
Instalojmë docker dhe docker-compose versionet më të fundit. (kjo mund të gjendet në internet)
docker -v &&
docker-compose -v
1. Instalojmë
git clone https://github.com/Laradock/laradock.git &&
ls
NĂ« lidhje me Laradock, do tĂ« them se Ă«shtĂ« njĂ« gjĂ« shumĂ« e shkĂ«lqyer, ku janĂ« grumbulluar shumĂ« kontejnerĂ« dhe mjete ndihmĂ«se. Por tĂ« pĂ«rdorĂ«sh Laradock nĂ« mĂ«nyrĂ« tĂ« tillĂ« pa modifikime nĂ« prodhim â nuk do ta rekomandoja pĂ«r shkak tĂ« tepricĂ«s sĂ« tij. MĂ« mirĂ« tĂ« krijosh kontejnerĂ«t e tu, duke u mbĂ«shtetur nĂ« shembujt nĂ« Laradock, kĂ«shtu do tĂ« ketĂ« mĂ« shumĂ« optimizim, pasi askujt nuk i nevojitet gjithçka qĂ« atje Ă«shtĂ« njĂ«kohĂ«sisht.
2. Konfigurojmë Laradock për të punuar me aplikacionin tonë.
cd laradock &&
cp env-example .env
2.1. Hapim katalogun habr (folderi prind në të cilin është klonuar laradock) në ndonjë editor. (Në rastin tim, PHPStorm)
Në këtë etapë vetëm vendosim emrin e projektit.
2.2. Nisni imazhin e punës. (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 ana e zhvilluesit.
Kalojmë brenda kontejnerit me anë të
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 e mbyllim compose.
ls
exit
docker-compose down
2.5. Kthehemi përsëri në PHPStorm dhe vendosim rrugën e saktë deri te aplikacioni ynë laravel në skedarin .env.
3. Shtojmë gjithë kodin në Git.
Për këtë krijojmë një depo në Github (ose kudo tjetër). Të kalojmë në terminal në drejtorinë habr dhe të 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 depo tuaj
git push -u origin master
git status
Kontrollojmë nëse gjithçka është në rregull.
Për lehtësinë, rekomandoj të përdorësh ndonjë ndërfaqe vizuale për Git, në rastin tim është . (këtu është një lidhje referuese)
4. Nisim!
Para fillimit, sigurohuni që në portet 80 dhe 443 nuk ka asgjë të varur.
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 pranimin e kĂ«rkesave nga serveri web
- workspace â php pĂ«r zhvilluesit
Në këtë moment ne arritëm të krijojmë një aplikacion në përputhje me, tashmë 4 nga 12, saktësisht:
1. Kodi i bazĂ«s â gjithĂ« kodi ndodhet nĂ« njĂ« depo (njĂ« shĂ«nim i vogĂ«l: ndoshta do tĂ« ishte e saktĂ« tĂ« sillnim docker brenda projektit laravel, por kjo nuk Ă«shtĂ« parĂ«sore).
2. VarĂ«sitĂ« â TĂ« gjitha varĂ«sitĂ« tona janĂ« tĂ« shkruara qartĂ« nĂ« application/composer.json dhe nĂ« çdo Dockerfile tĂ« çdo kontejneri.
3. ShĂ«rbimet e jashtme (Backing Services) â Ădo shĂ«rbim (php-fom, nignx, workspace) jeton jetĂ«n e tij dhe Ă«shtĂ« i lidhur nga jashtĂ«, dhe gjatĂ« punĂ«s me njĂ« shĂ«rbim, tjetri nuk do tĂ« prekĂ«t.
4. Proceset â çdo shĂ«rbim Ă«shtĂ« njĂ« proces. Ădo shĂ«rbim nuk ruan njĂ« gjendje tĂ« brendshme.
5. Lidhja e porteve (Port binding)
docker ps
Siç e shohim, çdo shërbim është nisur në portin e tij të veçantë dhe është i aksesueshëm për të gjitha shërbimet e tjera.
6. Paralelizmi
Docker na lejon të ngremë disa procese të të njëjtëve shërbime me balancim automatik të ngarkesës mes tyre.
ShkĂ«putim kontejnerĂ«t dhe i nisnim pĂ«rsĂ«ri me flamurin âscale
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Siç e shohim, janë krijuar kopje për kontejnerin php-fpm. Ne në punë me këtë kontejner nuk na nevojitet të ndryshojmë asgjë. Po ashtu vazhdojmë të lidhemi me të në portin 9000, ndërsa Docker rregullon ngarkesën mes kontejnerëve.
7. BashkĂ«punueshmĂ«ria (Disposability) â çdo kontejner mund tĂ« mbyllet pa dĂ«mtuar tĂ« tjerĂ«t. Ndalesa ose rinisja e njĂ« kontejneri nuk do tĂ« ndikojĂ« nĂ« funksionimin e aplikacionit nĂ« nisjet e ardhshme. Ădo kontejner gjithashtu mund tĂ« ngrihet nĂ« çdo moment.
8. Barazia e zhvillimit/ekzekutimit tĂ« aplikacionit â tĂ« gjitha mjediset tona janĂ« identike. Duke nisur sistemin nĂ« serverin nĂ« prodhim nuk do tĂ« duhet tĂ« ndryshoni asgjĂ« nĂ« komandat tuaja. E gjithĂ« kjo do tĂ« bazohet saktĂ«sisht nĂ« Docker.
9. Diengimi (Logs) â tĂ« gjithĂ« loget nĂ« kĂ«to kontejnerĂ« dalin nĂ« rrjedhĂ« dhe janĂ« tĂ« dukshme nĂ« konsolĂ«n e Docker. (nĂ« kĂ«tĂ« rast, realisht, me kontejnerĂ« tĂ« tjerĂ« tĂ« krijuar nga vete mund tĂ« mos jetĂ« ashtu nĂ«se nuk kujdeseni pĂ«r kĂ«tĂ«)
docker-compose logs -f 
Porosinë, ka një problem të tillë që vlerat e Parazgjedhura në PHP dhe Nginx gjithashtu regjistronin log-et në skedar. Për t'u përputhur me 12 faktorët, është e nevojshme diskonekt regjistrimi i log-eve në skedar në konfigurimet e çdo kontejneri veç e veç.
Igjithashtu Docker ofron mundësinë për të drejtuar log-et jo vetëm në stdout, por edhe në gjëra si graylog, për të cilin kam folur më lart. Dhe brenda graylog, mund të operojmë me log-et si të duam dhe aplikacioni ynë nuk do ta vërejë këtë.
10. Detyrat e adminstrimit â tĂ« gjitha detyrat e administratĂ«s zgjidhen nga laravel falĂ« mjetit artisan ashtu siç do tĂ« donin krijuesit e aplikacioneve 12-faktoreshe.
Si shembull, do të tregoj se si ekzekutohen disa komanda.
Hyjmë në kontejner.
docker-compose exec workspace bash
php artisan list
Tani mund të përdorim çdo komandë. (vëreni se nuk kemi konfiguruar bazën e të dhënave dhe cache-in, kështu që gjysma e komandave nuk do të ekzekutohet siç duhet, sepse ato janë të destinuara për të punuar me cache-in dhe databazën).
11. Konfigurimet dhe 12. Ndërtimi, lëshimi, ekzekutimi
Këtë pjesë doja t'ia kushtoja Blue-Green Deployment, por doli se ishte shumë e gjerë për këtë artikull. Për këtë do të shkruaj një artikull të veçantë.
Në dy fjalë, koncepti ndërtohet mbi sistemet CI/CD të tipit Jenkins dhe Gitlab CI. Në të dyja mund të caktohen variabla të ambientit të lidhura me ambientin specifik. Përkatësisht, në këtë rast do të përmbushen kërkesat me Konfigurimet.
Dhe pika për Ndërtimi, lëshimi, ekzekutimi zgjidhet nga funksionet e ndërtuara në të dy mjetet me emrin Pipeline.
Pipeline lejon ndarjen e procesit të depoymentit në shumë etapa, duke ndarë fazat e ndërtimit, lëshimit dhe ekzekutimit. Gjithashtu në Pipeline, do të keni mundësinë të krijoni backup-e dhe madje edhe çdo gjë tjetër. Ky mjet ka potencial të pakufishëm.
Kodi i aplikacionit është në .
Mos harroni të inicializoni submodule gjatë klonimit të këtij depoziti.
P.S.: Të gjitha këto qasje mund të përdoren me çdo mjete dhe gjuhë programimi tjetër. Gjëja kryesore është që thelbi të mos ndryshojë.
Burimi: habr.com
