Së pari, një teori e vogël. Cfare ndodhi ?
Me fjalë të thjeshta, ky dokument është krijuar për të thjeshtuar zhvillimin e aplikacioneve SaaS, duke ndihmuar duke informuar zhvilluesit dhe inxhinierët e DevOps për problemet dhe praktikat që hasen më shpesh në zhvillimin e aplikacioneve moderne.
Dokumenti u krijua nga zhvilluesit e platformës Heroku.
Aplikacioni Twelve-Factor mund të aplikohet për aplikacionet e shkruara në çdo gjuhë programimi dhe duke përdorur çdo kombinim të shërbimeve mbështetëse (bazat e të dhënave, radhët e mesazheve, cache, etj.).
Shkurtimisht për faktorët mbi të cilët bazohet kjo metodologji:
- Baza e kodeve – Një bazë kodesh e gjurmuar në kontrollin e versionit – vendosje të shumta
- varësitë – Deklaroni dhe izoloni në mënyrë të qartë varësitë
- konfiguracion – Ruani konfigurimin në kohën e ekzekutimit
- Shërbimet Mbështetëse – Konsideroni shërbimet mbështetëse si burime shtesë
- Ndërto, lësho, vrapo – Ndani rreptësisht fazat e montimit dhe ekzekutimit
- proceset – Ekzekutoni aplikacionin si një ose më shumë procese pa shtetësi
- Lidhja e portit – Shërbimet e eksportit nëpërmjet lidhjes së portit
- Paralelizëm – Shkalloni aplikacionin tuaj duke përdorur procese
- disponueshmëria – Maksimizoni besueshmërinë me nisjen e shpejtë dhe mbylljen e pastër
- Pariteti i zhvillimit/operimit të aplikacionit – Mbani mjediset tuaja të zhvillimit, inskenimit dhe prodhimit sa më të ngjashëm që të jetë e mundur
- Prerjet – Shikoni regjistrin si një rrjedhë ngjarjesh
- Detyrat e administratës – Kryen detyra administrimi/menaxhimi duke përdorur procese ad hoc
Ju mund të merrni më shumë informacion rreth 12 faktorëve nga burimet e mëposhtme:
- - duhet lexuar
- - përkthim zyrtar
- - një vështrim i ri i 12 faktorëve me qëllim përmirësimin e tyre.
Çfarë është vendosja Blu-Green?
Vendosja blu-jeshile është një metodë e dorëzimit të një aplikacioni në prodhim në mënyrë të tillë që klienti përfundimtar të mos shohë ndonjë ndryshim nga ana e tij. Me fjalë të tjera, vendosja e një aplikacioni me zero kohë joproduktive.
Skema klasike BG Deploy duket si ajo e treguar në imazhin më poshtë.
- Në fillim ka 2 serverë fizikë me absolutisht të njëjtin kod, aplikacion, projekt dhe ka një ruter (balancues).
- Ruteri fillimisht i drejton të gjitha kërkesat në një nga serverët (зеленый).
- Në momentin kur duhet të lëshoni përsëri, i gjithë projekti përditësohet në një server tjetër (синий), i cili aktualisht nuk po përpunon asnjë kërkesë.
- Pasi kodi është aktivizuar blu serveri është përditësuar plotësisht, ruterit i jepet një komandë për të kaluar nga e gjelbër mbi синий server.
- Tani të gjithë klientët shohin rezultatin e ekzekutimit të kodit me të blu server.
- Për disa kohë, зеленый serveri shërben si një kopje rezervë në rast të vendosjes së pasuksesshme në синий server dhe në rast dështimi dhe defektesh, ruteri e kthen përsëri rrjedhën e përdoruesit зеленый server me versionin e vjetër stabil dhe kodi i ri dërgohet për rishikim dhe testim.
- Dhe në fund të procesit, ai përditësohet në të njëjtën mënyrë зеленый server. Dhe pas përditësimit të tij, ruteri e kthen përsëri rrjedhën e kërkesës зеленый server.
Gjithçka duket shumë mirë dhe në shikim të parë nuk duhet të ketë asnjë problem me të.
Por meqenëse jetojmë në botën moderne, opsioni me ndërrimin fizik siç tregohet në skemën klasike nuk na përshtatet. Regjistroni informacionin tani për tani, ne do t'i kthehemi më vonë.
Këshilla e keqe dhe e mirë
Mohim përgjegjësie: Shembujt më poshtë tregojnë shërbimet/metodologjitë që përdor unë, ju mund të përdorni absolutisht çdo alternativë me funksione të ngjashme.
Shumica e shembujve në një mënyrë ose në një tjetër kryqëzohen me zhvillimin e uebit (kjo është një surprizë), me PHP dhe Docker.
Paragrafët e mëposhtëm ofrojnë një përshkrim të thjeshtë praktik të përdorimit të faktorëve duke përdorur shembuj specifikë; nëse doni të merrni më shumë teori mbi këtë temë, ndiqni lidhjet e mësipërme me burimin origjinal.
1. Baza e kodeve
Përdorni FTP dhe FileZilla për të ngarkuar skedarë në serverë një nga një, mos e ruani kodin askund tjetër përveçse në serverin e prodhimit.
Projekti duhet të ketë gjithmonë një bazë të vetme kodi, domethënë, i gjithë kodi vjen nga një git depo. Serverët (prodhimi, vendosja në skenë, testi1, testi2...) përdorin kodin nga degët e një depoje 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ësime thjesht duke transferuar kodin e ri në dosjen me versionin aktual të bibliotekës. Instaloni të gjitha shërbimet e nevojshme direkt në serverin pritës ku po funksionojnë edhe 20 shërbime të tjera.
Një projekt duhet të ketë gjithmonë një listë të qartë të kuptueshme të varësive (me varësi nënkuptoj edhe mjedisin). Të gjitha varësitë duhet të përcaktohen dhe të izolohen në mënyrë eksplicite.
Le të marrim si shembull Kompozitor и prerës.
Kompozitor — një menaxher paketash që ju lejon të instaloni bibliotekat në PHP. Kompozitori ju lejon të specifikoni versionet në mënyrë rigoroze ose të lirshme dhe t'i përcaktoni ato në mënyrë eksplicite. Mund të ketë 20 projekte të ndryshme në server dhe secili do të ketë një listë personale paketash dhe bibliotekash të pavarura nga tjetra.
prerës — një mjet që ju lejon të përcaktoni dhe izoloni mjedisin në të cilin do të ekzekutohet aplikacioni. Prandaj, ashtu si me kompozitorin, por në mënyrë më të plotë, ne mund të përcaktojmë se me çfarë funksionon aplikacioni. Zgjidhni një version specifik të PHP, instaloni vetëm paketat e nevojshme për funksionimin e projektit, pa shtuar asgjë shtesë. Dhe më e rëndësishmja, pa ndërhyrë në paketat dhe mjedisin e makinës pritës dhe projekteve të tjera. Kjo do të thotë, të gjitha projektet në server që funksionojnë përmes Docker mund të përdorin absolutisht çdo grup paketash dhe një mjedis krejtësisht të ndryshëm.
3. Konfigurimi
Ruani konfigurimet si konstante direkt në kod. Konstante të ndara për serverin e testimit, të ndara për prodhim. Lidhni funksionimin e aplikacionit në varësi të mjedisit drejtpërdrejt në logjikën e biznesit të projektit duke përdorur if other constructs.
Konfigurimet - kjo është e vetmja mënyrë që vendosjet e projektit duhet të ndryshojnë. Në mënyrë ideale, konfigurimet duhet të kalohen përmes variablave të mjedisit (env vars).
Kjo do të thotë, edhe nëse ruani disa skedarë konfigurimi .config.prod .config.local dhe i riemërtoni në momentin e vendosjes në .config (konfigurimi kryesor nga i cili aplikacioni lexon të dhënat) - kjo nuk do të jetë qasja e duhur, pasi në këtë rast informacioni nga konfigurimet do të jetë i disponueshëm publikisht për të gjithë zhvilluesit e aplikacioneve dhe të dhënat nga serveri i prodhimit do të rrezikohen. Të gjitha konfigurimet duhet të ruhen direkt në sistemin e vendosjes (CI/CD) dhe të gjenerohen për mjedise të ndryshme me vlera të ndryshme të nevojshme për një mjedis specifik në momentin e vendosjes.
4. Shërbimet e palëve të treta
Jini rreptësisht të lidhur me mjedisin, përdorni lidhje të ndryshme për të njëjtat shërbime në mjedise të caktuara.
Në fakt, kjo pikë përputhet fort me pikën rreth konfigurimeve, pasi pa këtë pikë, të dhënat normale të konfigurimit nuk mund të bëhen dhe, në përgjithësi, aftësia për të konfiguruar do të bjerë në asgjë.
Të gjitha lidhjet me shërbimet e jashtme, të tilla si serverët e radhës, bazat e të dhënave, shërbimet e memorizimit, duhet të jenë të njëjta si për mjedisin lokal ashtu edhe për mjedisin e palëve të treta / prodhimit. Me fjalë të tjera, në çdo kohë, duke ndryshuar vargun e lidhjes, unë mund të zëvendësoj thirrjet në bazën #1 me bazën #2 pa ndryshuar kodin e aplikacionit. Ose, duke parë përpara, si shembull, kur shkallëzoni shërbimin, nuk do t'ju duhet të specifikoni lidhjen në ndonjë mënyrë të veçantë për një server shtesë cache.
5. Ndërtoni, lëshoni, ekzekutoni
Keni vetëm versionin përfundimtar të kodit në server, pa asnjë shans për të rikthyer lëshimin. Nuk ka nevojë të mbushni hapësirën në disk. Kushdo që mendon se mund të lëshojë kodin në prodhim me një gabim është një programues i keq!
Të gjitha fazat e vendosjes duhet të ndahen nga njëra-tjetra.
Keni një shans për t'u rikthyer. Bëni lëshime me kopje të vjetra të aplikacionit (tashmë të montuara dhe të gatshme për betejë) të ruajtura në akses të shpejtë, në mënyrë që në rast gabimesh të mund të rivendosni versionin e vjetër. Kjo do të thotë, me kusht ekziston një dosje njoftime dhe dosje aktual, dhe pas vendosjes dhe montimit të suksesshëm të dosjes aktual e lidhur me një lidhje simbolike me publikimin e ri që gjendet brenda njoftime me emrin konvencional të numrit të lëshimit.
Këtu kujtojmë vendosjen Blue-Green, e cila ju lejon jo vetëm të kaloni midis kodit, por gjithashtu të kaloni midis të gjitha burimeve dhe madje edhe mjediseve me aftësinë për të rikthyer gjithçka.
6. Proceset
Ruani të dhënat e gjendjes së aplikacionit direkt brenda vetë aplikacionit. Përdorni sesione në RAM-in e vetë aplikacionit. Përdorni sa më shumë ndarje midis shërbimeve të palëve të treta që të jetë e mundur. Mbështetuni në faktin se aplikacioni mund të ketë vetëm një proces dhe nuk lejon shkallëzim.
Për sa i përket sesioneve, ruani të dhënat vetëm në një cache të kontrolluar nga shërbimet e palëve të treta (memcached, redis), kështu që edhe nëse keni 20 procese aplikimi në ekzekutim, secili prej tyre, pasi të ketë hyrë në cache, do të jetë në gjendje të vazhdojë të punojë me klientin në e njëjta gjendje në të cilën përdoruesi punonte me aplikacionin në një proces tjetër. Me këtë qasje, rezulton se pa marrë parasysh sa kopje të shërbimeve të palëve të treta përdorni, gjithçka do të funksionojë normalisht dhe pa probleme me aksesin në të dhëna.
7. Lidhja e portit
Vetëm serveri në internet duhet të dijë se si të punojë me shërbimet e palëve të treta. Ose më mirë akoma, instaloni shërbime të palëve të treta direkt brenda serverit të uebit. Për shembull, si një modul PHP në Apache.
Të gjitha shërbimet tuaja duhet të jenë të aksesueshme për njëri-tjetrin përmes aksesit në një adresë dhe port (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), domethënë, nga nginx unë mund të qasem në php-fpm dhe në postgres, dhe nga php-fpm te postgres dhe nginx dhe në fakt nga çdo shërbim mund të aksesoj një shërbim tjetër. Në këtë mënyrë, qëndrueshmëria e një shërbimi nuk është e lidhur me qëndrueshmërinë e një shërbimi tjetër.
8. Paralelizmi
Punoni me një proces, përndryshe disa procese nuk do të jenë në gjendje të shkojnë mirë me njëri-tjetrin!
Lini vend për shkallëzim. Swarm Docker është i shkëlqyeshëm 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ë grupi kontejnerësh në të njëjtën makinë.
Duke përdorur swarm, unë mund të përcaktoj se sa burime do t'i ndaj çdo procesi dhe sa procese të të njëjtit shërbim do të nis, dhe balancuesi i brendshëm, duke marrë të dhëna në një port të caktuar, do t'i përcaktojë automatikisht ato në procese. Kështu, duke parë që ngarkesa në server është rritur, unë mund të shtoj më shumë procese, duke ulur kështu ngarkesën në procese të caktuara.
9. Disponueshmëria
Mos përdorni radhë për të punuar me procese dhe të dhëna. Vrasja e një procesi duhet të ndikojë në të gjithë aplikacionin. Nëse një shërbim bie, gjithçka ulet.
Çdo proces dhe shërbim mund të çaktivizohet në çdo kohë dhe kjo nuk duhet të ndikojë në shërbimet e tjera (natyrisht, kjo nuk do të thotë që shërbimi nuk do të jetë i disponueshëm për një shërbim tjetër, por që një shërbim tjetër nuk do të fiket pas këtij). Të gjitha proceset duhet të ndërpriten me hijeshi, në mënyrë që kur të ndërpriten, të mos dëmtohen të dhëna dhe sistemi të funksionojë siç duhet herën tjetër që ta ndizni. Kjo do të thotë, edhe në rast të një përfundimi urgjent, të dhënat nuk duhet të dëmtohen (mekanizmi i transaksionit është i përshtatshëm këtu, pyetjet në bazën e të dhënave funksionojnë vetëm në grupe, dhe nëse të paktën një pyetje nga grupi dështon ose ekzekutohet me një gabim, atëherë asnjë pyetje tjetër nga grupi përfundimisht dështon në fakt).
10. Pariteti i zhvillimit/operimit të aplikacionit
Prodhimi, vënia në skenë dhe versioni lokal i aplikacionit duhet të jenë të ndryshme. Në prodhim ne përdorim kornizën Yii Lite, dhe në vend Yii, në mënyrë që të funksionojë më shpejt në prodhim!
Në realitet, të gjitha vendosjet dhe puna me kod duhet të jenë pothuajse në një mjedis identik (nuk po flasim për pajisje fizike). Gjithashtu, çdo punonjës zhvillimi duhet të jetë në gjendje të vendosë kodin në prodhim nëse është e nevojshme, dhe jo ndonjë departament devops i trajnuar posaçërisht, i cili vetëm falë forcës së veçantë mund ta ngrejë aplikacionin në prodhim.
Docker gjithashtu na ndihmon me këtë. Nëse respektohen të gjitha pikat e mëparshme, përdorimi i dokerit do të sjellë procesin e vendosjes së mjedisit si në prodhim ashtu edhe në makinën lokale në futjen e një ose dy komandave.
11. Shkrime
Ne shkruajmë regjistra në skedarë dhe baza të të dhënave! Ne nuk pastrojmë skedarët dhe bazat e të dhënave nga regjistrat. Le të blejmë një hard disk me 9000 bajt Peta dhe kjo është në rregull.
Të gjitha regjistrat duhet të konsiderohen si një rrjedhë ngjarjesh. Vetë aplikacioni nuk duhet të përfshihet në përpunimin e regjistrave. Regjistrat duhet të dalin ose në stdout ose të dërgohen nëpërmjet një protokolli si udp, në mënyrë që puna me regjistrat të mos krijojë ndonjë problem për aplikacionin. graylog është i mirë për këtë. Graylog që merr të gjitha regjistrat përmes udp (ky protokoll nuk kërkon pritjen e një përgjigjeje për marrjen me sukses të paketës) nuk ndërhyn në asnjë mënyrë në aplikacion dhe merret vetëm me strukturimin dhe përpunimin e regjistrave. Logjika e aplikimit nuk ndryshon për të punuar me qasje të tilla.
12. Detyrat e administrimit
Për të përditësuar të dhënat, bazat e të dhënave, etj., përdorni një pikë përfundimtare të krijuar veçmas në API, duke e ekzekutuar atë 2 herë radhazi do të rezultojë në dyfishimin e çdo gjëje. Por ju nuk jeni budallenj, nuk do të klikoni dy herë dhe ne nuk kemi nevojë për migrim.
Të gjitha detyrat e administrimit duhet të kryhen në të njëjtin mjedis si të gjithë kodet, në nivelin e lëshimit. Kjo do të thotë, nëse duhet të ndryshojmë strukturën e bazës së të dhënave, atëherë nuk do ta bëjmë atë manualisht duke ndryshuar emrat e kolonave dhe duke shtuar të reja përmes disa mjeteve vizuale të menaxhimit të bazës së të dhënave. Për gjëra të tilla ne krijojmë skripta të veçanta - migrime, të cilat ekzekutohen kudo dhe në të gjitha mjediset në të njëjtën mënyrë me një rezultat të përbashkët dhe të kuptueshëm. Për të gjitha detyrat e tjera, si mbushja e projektit me të dhëna, duhet të përdoren metodologji të ngjashme.
Shembull zbatimi në PHP, Laravel, Laradock, Docker-Compose
PS Të gjithë shembujt janë bërë në MacOS. Shumica e tyre janë gjithashtu të përshtatshme për Linux. Përdoruesit e Windows, më falni, por unë nuk kam punuar me Windows për një kohë të gjatë.
Le të imagjinojmë një situatë ku nuk kemi asnjë version të PHP të instaluar në kompjuterin tonë dhe asgjë fare.
Instaloni versionet më të fundit të docker dhe docker-compose. (kjo mund të gjendet në internet)
docker -v &&
docker-compose -v
1. Vendos
git clone https://github.com/Laradock/laradock.git &&
ls
Përsa i përket Laradock-ut, do të them se është një gjë shumë e lezetshme, e cila përmban shumë kontejnerë dhe gjëra ndihmëse. Por unë nuk do të rekomandoja përdorimin e Laradock si të tillë pa modifikime në prodhim për shkak të tepricës së tij. Është më mirë të krijoni kontejnerët tuaj bazuar në shembuj në Laradock, kjo do të jetë shumë më e optimizuar, sepse askush nuk ka nevojë për gjithçka që është atje në të njëjtën kohë.
2. Konfiguro Laradock për të ekzekutuar aplikacionin tonë.
cd laradock &&
cp env-example .env
2.1. Hapni direktorinë habr (dosja mëmë në të cilën klonohet laradock) në një redaktues. (Në rastin tim PHPStorm)
Në këtë fazë ne i japim vetëm një emër projektit.
2.2. Hapni imazhin e hapësirës së punës. (Në rastin tuaj, imazhet do të kërkojnë pak kohë për t'u ndërtuar)
Hapësira e punës është një imazh i përgatitur posaçërisht për të punuar me kornizën në emër të zhvilluesit.
Ne futemi brenda në enë duke përdorur
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Instalimi i Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. Pas instalimit, kontrollojmë nëse drejtoria me projektin është krijuar dhe vrasim kompozimin.
ls
exit
docker-compose down
2.5. Le të kthehemi te PHPStorm dhe të vendosim rrugën e duhur për aplikacionin tonë laravel në skedarin .env.
3. Shtoni të gjithë kodin në Git.
Për ta bërë këtë, ne do të krijojmë një depo në Github (ose kudo tjetër). Le të shkojmë te drejtoria habr në terminal 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 [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
Le të kontrollojmë nëse gjithçka është në rregull.
Për lehtësi, unë rekomandoj të përdorni një ndërfaqe vizuale për Git, në rastin tim është . (këtu është një lidhje referimi)
4. Le të nisim!
Para se të filloni, sigurohuni që asgjë të mos varet në portat 80 dhe 443.
docker-compose up -d nginx php-fpm
Kështu, projekti ynë përbëhet nga 3 shërbime të veçanta:
- nginx - server në internet
- php-fpm - php për marrjen e kërkesave nga një server në internet
- hapësira e punës - php për zhvilluesit
Për momentin, ne kemi arritur që kemi krijuar një aplikacion që plotëson 4 pikë nga 12, përkatësisht:
1. Baza e kodeve — i gjithë kodi është në një depo (shënim i vogël: mund të jetë e saktë të shtoni docker brenda projektit laravel, por kjo nuk është e rëndësishme).
2. varësitë - Të gjitha varësitë tona janë të shkruara në mënyrë eksplicite në application/composer.json dhe në çdo Dockerfile të çdo kontejneri.
3. Shërbimet Mbështetëse — Secili prej shërbimeve (php-fom, nignx, hapësira e punës) jeton jetën e vet dhe është i lidhur nga jashtë dhe kur punon me një shërbim, tjetri nuk do të ndikohet.
4. proceset — çdo shërbim është një proces. Secili prej shërbimeve nuk ruan gjendjen e brendshme.
5. Lidhja e portit
docker ps
Siç mund ta shohim, çdo shërbim funksionon në portin e vet dhe është i aksesueshëm për të gjitha shërbimet e tjera.
6. Paralelizëm
Docker na lejon të krijojmë procese të shumta të të njëjtave shërbime me balancim automatik të ngarkesës midis tyre.
Le të ndalojmë kontejnerët dhe t'i kalojmë nëpër flamur -- shkallë
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Siç mund ta shohim, janë krijuar kopje të kontejnerit php-fpm. Nuk kemi nevojë të ndryshojmë asgjë në punën me këtë enë. Ne gjithashtu vazhdojmë ta aksesojmë atë në portin 9000 dhe Docker rregullon ngarkesën midis kontejnerëve për ne.
7. disponueshmëria - çdo enë mund të vritet pa dëmtuar tjetrin. Ndalimi ose rinisja e kontejnerit nuk do të ndikojë në funksionimin e aplikacionit gjatë nisjeve të mëvonshme. Çdo enë gjithashtu mund të ngrihet në çdo kohë.
8. Pariteti i zhvillimit/operimit të aplikacionit - të gjitha mjediset tona janë të njëjta. Duke ekzekutuar sistemin në një server në prodhim, nuk do t'ju duhet të ndryshoni asgjë në komandat tuaja. Gjithçka do të bazohet në Docker në të njëjtën mënyrë.
9. Prerjet — të gjitha regjistrat në këto kontejnerë shkojnë në transmetim dhe janë të dukshëm në tastierën Docker. (në këtë rast, në fakt, me kontejnerë të tjerë të bërë vetë, kjo mund të mos ndodhë nëse nuk kujdeseni për të)
docker-compose logs -f
Por ka një kapje në atë që vlerat e paracaktuara në PHP dhe Nginx gjithashtu shkruajnë regjistrat në një skedar. Për të përmbushur 12 faktorët, është e nevojshme pres shkrimi i regjistrave në një skedar në konfigurimet e secilit kontejner veç e veç.
Docker ofron gjithashtu mundësinë për të dërguar regjistra jo vetëm për stdout, por edhe për gjëra të tilla si graylog, që përmenda më lart. Dhe brenda graylog, ne mund t'i përdorim regjistrat sipas dëshirës dhe aplikacioni ynë nuk do ta vërejë këtë në asnjë mënyrë.
10. Detyrat e administratës — të gjitha detyrat e administrimit zgjidhen nga laravel falë veglës artizanale pikërisht ashtu siç do të dëshironin krijuesit e aplikacionit 12 faktor.
Si shembull, unë do të tregoj se si ekzekutohen disa komanda.
Ne futemi në enë.
docker-compose exec workspace bash
php artisan list
Tani mund të përdorim çdo komandë. (ju lutemi vini re se ne nuk e konfiguruam bazën e të dhënave dhe cache, kështu që gjysma e komandave nuk do të ekzekutohen siç duhet, sepse ato janë krijuar për të punuar me cache dhe bazën e të dhënave).
11. Konfigurimet dhe 12. Ndërto, lësho, vrapo
Doja t'ia kushtoja këtë pjesë Vendosjes Blu-Green, por doli të ishte shumë e gjerë për këtë artikull. Unë do të shkruaj një artikull të veçantë për këtë.
Me pak fjalë, koncepti bazohet në sistemet CI/CD si Jenkins и Gitlab CI. Në të dyja, ju mund të vendosni variabla mjedisore të lidhura me një mjedis specifik. Prandaj, në këtë situatë, pika c do të plotësohet Konfigurimet.
Dhe pika rreth Ndërto, lësho, vrapo zgjidhet nga funksionet e integruara me emrin Gazsjellës.
Gazsjellës ju lejon të ndani procesin e vendosjes në shumë faza, duke theksuar fazat e montimit, lëshimit dhe ekzekutimit. Gjithashtu në Pipeline, ju mund të krijoni kopje rezervë, dhe në të vërtetë çdo gjë. Ky është një mjet me potencial të pakufishëm.
Kodi i aplikimit është në .
Mos harroni të inicializoni nënmodulin kur klononi këtë depo.
PS: Të gjitha këto qasje mund të përdoren me çdo shërbim tjetër dhe gjuhë programimi. Gjëja kryesore është se thelbi nuk ndryshon.
Burimi: www.habr.com