Una, isang maliit na teorya. Anong nangyari ?
Sa madaling salita, ang dokumentong ito ay idinisenyo upang pasimplehin ang pagbuo ng mga SaaS application, na tumutulong sa pamamagitan ng pagpapaalam sa mga developer at DevOps engineer tungkol sa mga problema at kasanayan na kadalasang nararanasan sa pagbuo ng mga modernong application.
Ang dokumento ay nilikha ng mga developer ng Heroku platform.
Ang Twelve-Factor App ay maaaring ilapat sa mga application na nakasulat sa anumang programming language at gamit ang anumang kumbinasyon ng mga backing services (mga database, message queues, cache, atbp.).
Maikling tungkol sa mga salik kung saan nakabatay ang pamamaraang ito:
- Codebase β Isang codebase na sinusubaybayan sa version control β maramihang deployment
- Dependencies β Tahasang ideklara at ihiwalay ang mga dependency
- Configuration - I-save ang configuration sa runtime
- Mga Serbisyo sa Pag-backup β Isaalang-alang ang mga serbisyo sa pagsuporta bilang mga mapagkukunan ng plug-in
- Bumuo, bitawan, tumakbo β Mahigpit na paghiwalayin ang mga yugto ng pagpupulong at pagpapatupad
- Ang mga proseso β Patakbuhin ang application bilang isa o higit pang stateless na proseso
- Port binding β I-export ang mga serbisyo sa pamamagitan ng port binding
- Kumpetensya β I-scale ang iyong aplikasyon gamit ang mga proseso
- Disposability β I-maximize ang pagiging maaasahan sa mabilis na pagsisimula at malinis na pagsara
- Pag-unlad ng aplikasyon/pagkakapareho ng operasyon β Panatilihin ang iyong pag-unlad, pagtatanghal, at mga kapaligiran ng produksyon na magkatulad hangga't maaari
- Pagtotroso β Tingnan ang log bilang isang stream ng mga kaganapan
- Mga gawain sa pangangasiwa β Magsagawa ng mga gawain sa pangangasiwa/pamamahala gamit ang mga ad hoc na proseso
Makakakuha ka ng higit pang impormasyon tungkol sa 12 salik mula sa mga sumusunod na mapagkukunan:
- - kailangang basahin
- β opisyal na pagsasalin
- - isang sariwang pagtingin sa 12 mga kadahilanan na may layuning pahusayin ang mga ito.
Ano ang Blue-Green deployment?
Ang Blue-Green deployment ay isang paraan ng paghahatid ng application sa produksyon sa paraang hindi nakikita ng end client ang anumang pagbabago sa kanyang bahagi. Sa madaling salita, ang pag-deploy ng application na may zero downtime.
Ang klasikong BG Deploy scheme ay kamukha ng ipinapakita sa larawan sa ibaba.
- Sa simula mayroong 2 pisikal na server na may ganap na parehong code, application, proyekto, at mayroong isang router (balancer).
- Ang router sa una ay nagdidirekta sa lahat ng mga kahilingan sa isa sa mga server (berde).
- Sa sandaling kailangan mong ilabas muli, ang buong proyekto ay na-update sa isa pang server (asul), na kasalukuyang hindi nagpoproseso ng anumang mga kahilingan.
- Matapos i-on ang code bughaw Ang server ay ganap na na-update, ang router ay binibigyan ng isang utos upang lumipat mula sa berde sa asul server.
- Ngayon ang lahat ng mga kliyente ay nakikita ang resulta ng code na tumatakbo sa asul server.
- Para sa ilang oras, berde ang server ay nagsisilbing isang backup na kopya sa kaso ng hindi matagumpay na pag-deploy sa asul server at sa kaso ng pagkabigo at mga bug, inililipat ng router ang daloy ng gumagamit pabalik sa berde server na may lumang stable na bersyon, at ang bagong code ay ipinadala para sa rebisyon at pagsubok.
- At sa dulo ng proseso, ito ay ina-update sa parehong paraan berde server. At pagkatapos itong i-update, ibabalik ng router ang daloy ng kahilingan pabalik berde server.
Ang lahat ng ito ay mukhang napakahusay at sa unang tingin ay hindi dapat magkaroon ng anumang mga problema dito.
Ngunit dahil nakatira tayo sa modernong mundo, ang opsyon na may pisikal na paglipat tulad ng ipinahiwatig sa klasikal na pamamaraan ay hindi angkop sa amin. Itala ang impormasyon sa ngayon, babalikan namin ito mamaya.
Masama at magandang payo
Pagtanggi sa pananagutan: Ang mga halimbawa sa ibaba ay nagpapakita ng mga kagamitan/pamamaraan na aking ginagamit, maaari mong gamitin ang anumang mga alternatibo na may katulad na mga function.
Karamihan sa mga halimbawa ay sa isang paraan o iba pang bumalandra sa web development (ito ay isang sorpresa), sa PHP at Docker.
Ang mga talata sa ibaba ay nagbibigay ng isang simpleng praktikal na paglalarawan ng paggamit ng mga salik gamit ang mga partikular na halimbawa; kung gusto mong makakuha ng higit pang teorya sa paksang ito, sundin ang mga link sa itaas sa orihinal na pinagmulan.
1. Codebase
Gamitin ang FTP at FileZilla upang mag-upload ng mga file sa mga server nang paisa-isa, huwag iimbak ang code kahit saan maliban sa production server.
Ang proyekto ay dapat palaging may isang solong code base, iyon ay, lahat ng code ay nagmula sa isa pumunta imbakan. Ang mga server (production, staging, test1, test2...) ay gumagamit ng code mula sa mga sangay ng isang karaniwang repository. Sa ganitong paraan nakakamit namin ang pagkakapare-pareho ng code.
2. Dependencies
I-download ang lahat ng mga aklatan sa mga folder nang direkta sa ugat ng proyekto. Gumawa ng mga update sa pamamagitan lamang ng paglilipat ng bagong code sa folder na may kasalukuyang bersyon ng library. Direktang i-install ang lahat ng kinakailangang utility sa host server kung saan 20 pang serbisyo ang tumatakbo.
Ang isang proyekto ay dapat palaging may malinaw na nauunawaan na listahan ng mga dependencies (sa pamamagitan ng mga dependency ang ibig kong sabihin ay ang kapaligiran). Ang lahat ng mga dependency ay dapat na tahasang tinukoy at ihiwalay.
Kunin natin bilang isang halimbawa kompositor ΠΈ Manggagawa sa pantalan.
kompositor β isang package manager na nagbibigay-daan sa iyong mag-install ng mga library sa PHP. Binibigyang-daan ka ng kompositor na tukuyin ang mga bersyon nang mahigpit o maluwag, at tahasang tukuyin ang mga ito. Maaaring mayroong 20 iba't ibang proyekto sa server at bawat isa ay magkakaroon ng personal na listahan ng mga pakete at aklatan na independyente sa isa.
Manggagawa sa pantalan β isang utility na nagbibigay-daan sa iyong tukuyin at ihiwalay ang kapaligiran kung saan tatakbo ang application. Alinsunod dito, tulad ng sa kompositor, ngunit mas lubusan, matutukoy natin kung saan gumagana ang application. Pumili ng isang partikular na bersyon ng PHP, i-install lamang ang mga pakete na kailangan para gumana ang proyekto, nang hindi nagdaragdag ng anumang karagdagang bagay. At ang pinakamahalaga, nang hindi nakakasagabal sa mga pakete at kapaligiran ng host machine at iba pang mga proyekto. Iyon ay, ang lahat ng mga proyekto sa server na tumatakbo sa pamamagitan ng Docker ay maaaring gumamit ng ganap na anumang hanay ng mga pakete at isang ganap na naiibang kapaligiran.
3. Configuration
I-store ang mga config bilang mga constant nang direkta sa code. Paghiwalayin ang mga constant para sa test server, hiwalay para sa produksyon. Itali ang pagpapatakbo ng application depende sa kapaligiran nang direkta sa lohika ng negosyo ng proyekto gamit ang if else constructs.
Mga Configuration - ito ang tanging paraan na dapat magkaiba ang mga deployment ng proyekto. Sa isip, ang mga pagsasaayos ay dapat ipasa sa mga variable ng kapaligiran (env vars).
Iyon ay, kahit na mag-imbak ka ng ilang mga configuration file .config.prod .config.local at palitan ang pangalan ng mga ito sa oras ng pag-deploy sa .config (ang pangunahing config kung saan nagbabasa ng data ang application) - hindi ito ang tamang diskarte, dahil sa kasong ito, ang impormasyon mula sa mga configuration ay magiging available sa publiko sa lahat ng mga developer ng application at ang data mula sa production server ay makokompromiso. Ang lahat ng mga configuration ay dapat na naka-imbak nang direkta sa deployment system (CI/CD) at binuo para sa iba't ibang mga kapaligiran na may iba't ibang mga halaga na kinakailangan para sa isang partikular na kapaligiran sa oras ng pag-deploy.
4. Mga Serbisyo ng Third Party
Mahigpit na nakatali sa kapaligiran, gumamit ng iba't ibang koneksyon para sa parehong mga serbisyo sa ilang partikular na kapaligiran.
Sa katunayan, ang puntong ito ay malakas na nagsasapawan sa punto tungkol sa mga pagsasaayos, dahil kung wala ang puntong ito, ang normal na data ng pagsasaayos ay hindi magagawa at, sa pangkalahatan, ang kakayahang mag-configure ay mawawala sa wala.
Ang lahat ng koneksyon sa mga panlabas na serbisyo, tulad ng mga queue server, database, caching services, ay dapat na pareho para sa parehong lokal na kapaligiran at ang third-party / production environment. Sa madaling salita, anumang oras, sa pamamagitan ng pagpapalit ng string ng koneksyon, maaari kong palitan ang mga tawag sa base #1 ng base #2 nang hindi binabago ang application code. O, sa hinaharap, bilang isang halimbawa, kapag nag-scale ng serbisyo, hindi mo na kailangang tukuyin ang koneksyon sa anumang espesyal na paraan para sa isang karagdagang cache server.
5. Bumuo, bitawan, isagawa
Magkaroon lamang ng huling bersyon ng code sa server, na walang pagkakataong maibalik ang paglabas. Hindi na kailangang punan ang espasyo sa disk. Ang sinumang nag-iisip na maaari nilang ilabas ang code sa produksyon nang may error ay isang masamang programmer!
Ang lahat ng mga yugto ng pag-deploy ay dapat na ihiwalay sa isa't isa.
Magkaroon ng pagkakataong gumulong pabalik. Gumawa ng mga release gamit ang mga lumang kopya ng application (na-assemble na at handa na para sa labanan) na naka-save sa mabilis na pag-access, upang sa kaso ng mga error maaari mong ibalik ang lumang bersyon. Iyon ay, kondisyon na mayroong isang folder release at folder kasalukuyan, at pagkatapos ng matagumpay na pag-deploy at pag-assemble ng folder kasalukuyan naka-link sa pamamagitan ng simbolikong link sa bagong release na nasa loob release na may karaniwang pangalan ng release number.
Dito namin naaalala ang Blue-Green deployment, na nagbibigay-daan sa iyong hindi lamang magpalipat-lipat sa pagitan ng code, kundi pati na rin upang lumipat sa pagitan ng lahat ng mapagkukunan at maging sa mga kapaligiran na may kakayahang ibalik ang lahat.
6. Mga proseso
Direktang mag-imbak ng data ng estado ng application sa loob mismo ng application. Gumamit ng mga session sa RAM ng application mismo. Gumamit ng mas maraming pagbabahagi sa pagitan ng mga serbisyo ng third-party hangga't maaari. Umasa sa katotohanan na ang aplikasyon ay maaari lamang magkaroon ng isang proseso at hindi pinapayagan ang pag-scale.
Tungkol sa mga session, mag-imbak lamang ng data sa isang cache na kinokontrol ng mga third-party na serbisyo (memcached, redis), kaya kahit na mayroon kang 20 na proseso ng application na tumatakbo, alinman sa mga ito, na na-access ang cache, ay magagawang magpatuloy sa pakikipagtulungan sa kliyente sa ang parehong estado kung saan nagtatrabaho ang user sa application sa ibang proseso. Sa diskarteng ito, lumalabas na kahit gaano karaming mga kopya ng mga serbisyo ng third-party ang iyong ginagamit, lahat ay gagana nang normal at walang mga problema sa pag-access sa data.
7. Port binding
Ang web server lang ang dapat alam kung paano magtrabaho sa mga serbisyo ng third-party. O mas mabuti pa, i-install ang mga serbisyo ng third-party nang direkta sa loob ng web server. Halimbawa, bilang isang PHP module sa Apache.
Ang lahat ng iyong mga serbisyo ay dapat na ma-access sa isa't isa sa pamamagitan ng pag-access sa ilang address at port (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), iyon ay, mula sa nginx maaari kong ma-access ang parehong php-fpm at sa postgres, at mula sa php-fpm hanggang sa mga postgres at nginx at talagang mula sa bawat serbisyo ay maaari kong ma-access ang isa pang serbisyo. Sa ganitong paraan, hindi nakatali ang viability ng isang serbisyo sa viability ng isa pang serbisyo.
8. Paralelismo
Magtrabaho sa isang proseso, kung hindi, maraming mga proseso ang hindi makakasundo sa isa't isa!
Mag-iwan ng silid para sa pag-scale. Ang docker swarm ay mahusay para dito.
Ang Docker Swarm ay isang tool para sa paglikha at pamamahala ng mga kumpol ng mga container sa pagitan ng magkaibang machine at isang grupo ng mga container sa iisang machine.
Gamit ang kuyog, matutukoy ko kung gaano karaming mga mapagkukunan ang aking ilalaan sa bawat proseso at kung gaano karaming mga proseso ng parehong serbisyo ang aking ilulunsad, at ang panloob na tagabalanse, na tumatanggap ng data sa isang naibigay na port, ay awtomatikong i-proxy ito sa mga proseso. Kaya, nakikita na ang pag-load sa server ay tumaas, maaari akong magdagdag ng higit pang mga proseso, sa gayon ay binabawasan ang pag-load sa ilang mga proseso.
9. Disposability
Huwag gumamit ng mga pila upang gumana sa mga proseso at data. Ang pagpatay sa isang proseso ay dapat makaapekto sa buong aplikasyon. Kung ang isang serbisyo ay bumaba, lahat ay bumaba.
Ang bawat proseso at serbisyo ay maaaring i-off anumang oras at hindi ito dapat makaapekto sa iba pang mga serbisyo (siyempre, hindi ito nangangahulugan na ang serbisyo ay magiging hindi magagamit para sa isa pang serbisyo, ngunit ang isa pang serbisyo ay hindi mag-o-off pagkatapos ng isang ito). Ang lahat ng mga proseso ay dapat na wakasan nang maganda, upang kapag ang mga ito ay natapos, walang data na masisira at ang system ay gagana nang tama sa susunod na pag-on mo ito. Iyon ay, kahit na sa kaganapan ng isang emergency na pagwawakas, ang data ay hindi dapat masira (ang mekanismo ng transaksyon ay angkop dito, ang mga query sa database ay gumagana lamang sa mga grupo, at kung hindi bababa sa isang query mula sa grupo ang nabigo o naisakatuparan sa isang error, at pagkatapos ay walang ibang query mula sa pangkat na sa huli ay nabigo sa katunayan).
10. Pag-unlad ng aplikasyon/parity ng operasyon
Ang produksyon, pagtatanghal at lokal na bersyon ng application ay dapat na iba. Sa produksyon ginagamit namin ang Yii Lite framework, at lokal na Yii, para mas mabilis itong gumana sa produksyon!
Sa katotohanan, ang lahat ng mga deployment at gumagana sa code ay dapat na nasa halos magkaparehong kapaligiran (hindi namin pinag-uusapan ang tungkol sa pisikal na hardware). Gayundin, ang sinumang empleyado sa pag-unlad ay dapat na makapag-deploy ng code sa produksyon kung kinakailangan, at hindi ang ilang espesyal na sinanay na departamento ng devops, na dahil lamang sa espesyal na lakas ay maaaring iangat ang aplikasyon sa produksyon.
Tinutulungan din kami ng Docker dito. Kung ang lahat ng mga naunang punto ay sinusunod, ang paggamit ng docker ay magdadala sa proseso ng pag-deploy ng kapaligiran kapwa sa produksyon at sa lokal na makina sa pagpasok ng isa o dalawang command.
11. Mga tala
Nagsusulat kami ng mga log sa mga file at database! Hindi namin nililinis ang mga file at database mula sa mga log. Bumili na lang tayo ng hard drive na may 9000 Peta bytes at ayos lang.
Ang lahat ng mga log ay dapat ituring bilang isang stream ng mga kaganapan. Ang application mismo ay hindi dapat kasangkot sa pagproseso ng mga log. Ang mga log ay dapat na output sa alinman sa stdout o ipinadala sa pamamagitan ng isang protocol tulad ng udp, upang ang pagtatrabaho sa mga log ay hindi lumikha ng anumang mga problema para sa application. ang graylog ay mabuti para dito. Ang pagtanggap ng Graylog ng lahat ng mga log sa pamamagitan ng udp (ang protocol na ito ay hindi nangangailangan ng paghihintay para sa isang tugon tungkol sa matagumpay na pagtanggap ng packet) ay hindi nakakasagabal sa application sa anumang paraan at tumatalakay lamang sa pag-istruktura at pagproseso ng mga log. Ang lohika ng aplikasyon ay hindi nagbabago upang gumana sa mga ganitong paraan.
12. Mga gawain sa pangangasiwa
Upang mag-update ng data, mga database, atbp., gumamit ng hiwalay na ginawang endpoint sa API, ang pagpapatupad nito nang 2 beses nang sunud-sunod ay magreresulta sa lahat ng pagdodoble. Ngunit hindi ka tanga, hindi ka magki-click nang dalawang beses, at hindi namin kailangan ng paglipat.
Ang lahat ng mga gawain sa pangangasiwa ay dapat gawin sa parehong kapaligiran tulad ng lahat ng code, sa antas ng paglabas. Iyon ay, kung kailangan nating baguhin ang istraktura ng database, hindi natin gagawin ito nang manu-mano sa pamamagitan ng pagpapalit ng mga pangalan ng mga column at pagdaragdag ng mga bago sa pamamagitan ng ilang visual na tool sa pamamahala ng database. Para sa mga ganoong bagay, gumagawa kami ng hiwalay na mga script - mga paglilipat, na isinasagawa sa lahat ng dako at sa lahat ng kapaligiran sa parehong paraan na may karaniwan at nauunawaan na resulta. Para sa lahat ng iba pang mga gawain, tulad ng pagpuno sa proyekto ng data, ang mga katulad na pamamaraan ay dapat gamitin.
Halimbawang pagpapatupad sa PHP, Laravel, Laradock, Docker-Compose
PS Lahat ng mga halimbawa ay ginawa sa MacOS. Karamihan sa kanila ay angkop din para sa Linux. Mga gumagamit ng Windows, patawarin mo ako, ngunit hindi ako nagtatrabaho sa Windows nang mahabang panahon.
Isipin natin ang isang sitwasyon kung saan wala kaming anumang bersyon ng PHP na naka-install sa aming PC at wala talaga.
I-install ang pinakabagong bersyon ng docker at docker-compose. (ito ay matatagpuan sa Internet)
docker -v &&
docker-compose -v
1. Ilagay
git clone https://github.com/Laradock/laradock.git &&
ls
Tungkol sa Laradock, sasabihin ko na ito ay isang napaka-cool na bagay, na naglalaman ng maraming mga lalagyan at mga pantulong na bagay. Ngunit hindi ko inirerekumenda ang paggamit ng Laradock nang walang mga pagbabago sa produksyon dahil sa kalabisan nito. Mas mainam na lumikha ng iyong sariling mga lalagyan batay sa mga halimbawa sa Laradock, ito ay magiging mas ma-optimize, dahil walang nangangailangan ng lahat ng bagay na naroroon nang sabay-sabay.
2. I-configure ang Laradock upang patakbuhin ang aming application.
cd laradock &&
cp env-example .env
2.1. Buksan ang direktoryo ng habr (ang folder ng magulang kung saan naka-clone ang laradock) sa ilang editor. (Sa aking PHPStorm case)
Sa yugtong ito, binibigyan lang namin ng pangalan ang proyekto.
2.2. Ilunsad ang larawan ng workspace. (Sa iyong kaso, ang mga larawan ay magtatagal upang mabuo)
Ang workspace ay isang espesyal na inihandang larawan para sa pagtatrabaho sa framework sa ngalan ng developer.
Pumasok kami sa loob ng lalagyan gamit
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Pag-install ng Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. Pagkatapos ng pag-install, sinusuri namin kung ang direktoryo na may proyekto ay nalikha at pumatay ng mag-compose.
ls
exit
docker-compose down
2.5. Bumalik tayo sa PHPStorm at itakda ang tamang landas sa aming laravel application sa .env file.
3. Idagdag ang lahat ng code sa Git.
Para magawa ito, gagawa kami ng repository sa Github (o kahit saan pa). Pumunta tayo sa direktoryo ng habr sa terminal at isagawa ang sumusunod na code.
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
Tingnan natin kung maayos ang lahat.
Para sa kaginhawahan, inirerekumenda ko ang paggamit ng ilang visual na interface para sa Git, sa aking kaso ito . (narito ang isang referral link)
4. Ilunsad natin!
Bago magsimula, tiyaking walang nakasabit sa mga port 80 at 443.
docker-compose up -d nginx php-fpm
Kaya, ang aming proyekto ay binubuo ng 3 magkahiwalay na serbisyo:
- nginx - web server
- php-fpm - php para sa pagtanggap ng mga kahilingan mula sa isang web server
- workspace - php para sa mga developer
Sa ngayon, nakamit namin na nakagawa kami ng isang application na nakakatugon sa 4 na puntos sa 12, lalo na:
1. Codebase β lahat ng code ay nasa isang repositoryo (maliit na tala: maaaring tama na magdagdag ng docker sa loob ng proyekto ng laravel, ngunit hindi ito mahalaga).
2. Dependencies - Lahat ng aming mga dependency ay tahasang nakasulat sa application/composer.json at sa bawat Dockerfile ng bawat container.
3. Mga Serbisyo sa Pag-backup β Ang bawat isa sa mga serbisyo (php-fom, nignx, workspace) ay nabubuhay sa sarili nitong buhay at konektado mula sa labas at kapag nagtatrabaho sa isang serbisyo, ang isa ay hindi maaapektuhan.
4. Ang mga proseso β bawat serbisyo ay isang proseso. Ang bawat isa sa mga serbisyo ay hindi nagpapanatili ng panloob na estado.
5. Port binding
docker ps
Tulad ng nakikita natin, ang bawat serbisyo ay tumatakbo sa sarili nitong port at naa-access sa lahat ng iba pang serbisyo.
6. Kumpetensya
Nagbibigay-daan sa amin ang Docker na mag-spawn ng maraming proseso ng parehong mga serbisyo na may awtomatikong pagbabalanse ng pag-load sa pagitan ng mga ito.
Itigil natin ang mga lalagyan at patakbuhin ang mga ito sa bandila --scale
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Tulad ng nakikita natin, ang mga kopya ay ginawa ng php-fpm container. Hindi namin kailangang baguhin ang anumang bagay sa pagtatrabaho sa container na ito. Patuloy din namin itong ina-access sa port 9000, at kinokontrol ng Docker ang pagkarga sa pagitan ng mga container para sa amin.
7. Disposability - ang bawat lalagyan ay maaaring patayin nang hindi sinasaktan ang isa. Ang paghinto o pag-restart ng container ay hindi makakaapekto sa pagpapatakbo ng application sa mga susunod na paglulunsad. Ang bawat lalagyan ay maaari ding buhatin anumang oras.
8. Pag-unlad ng aplikasyon/pagkakapareho ng operasyon - lahat ng ating kapaligiran ay pareho. Sa pamamagitan ng pagpapatakbo ng system sa isang server sa produksyon, hindi mo na kailangang baguhin ang anuman sa iyong mga utos. Ang lahat ay ibabatay sa Docker sa parehong paraan.
9. Pagtotroso β lahat ng log sa mga container na ito ay napupunta sa stream at makikita sa Docker console. (sa kasong ito, sa katunayan, sa iba pang gawang bahay na lalagyan, maaaring hindi ito mangyayari kung hindi mo ito aalagaan)
docker-compose logs -f
Ngunit mayroong isang catch na ang mga Default na halaga sa PHP at Nginx ay nagsusulat din ng mga log sa isang file. Upang matugunan ang 12 mga kadahilanan, ito ay kinakailangan huwag paganahin pagsusulat ng mga log sa isang file sa mga configuration ng bawat container nang hiwalay.
Nagbibigay din ang Docker ng kakayahang magpadala ng mga log hindi lamang sa stdout, kundi pati na rin sa mga bagay tulad ng graylog, na binanggit ko sa itaas. At sa loob ng graylog, maaari naming patakbuhin ang mga log ayon sa gusto namin at hindi ito mapapansin ng aming aplikasyon sa anumang paraan.
10. Mga gawain sa pangangasiwa β lahat ng mga gawain sa pangangasiwa ay nalutas sa pamamagitan ng laravel salamat sa artisan tool na eksakto kung paano gusto ng mga tagalikha ng 12 factor application.
Bilang halimbawa, ipapakita ko kung paano isinasagawa ang ilang mga utos.
Pumunta kami sa lalagyan.
docker-compose exec workspace bash
php artisan list
Ngayon ay maaari na nating gamitin ang anumang utos. (pakitandaan na hindi namin na-configure ang database at cache, kaya kalahati ng mga command ay hindi maisasakatuparan ng tama, dahil ang mga ito ay idinisenyo upang gumana sa cache at database).
11. Mga Configuration at 12. Bumuo, bitawan, tumakbo
Nais kong ialay ang bahaging ito sa Blue-Green Deployment, ngunit ito ay naging masyadong malawak para sa artikulong ito. Magsusulat ako ng isang hiwalay na artikulo tungkol dito.
Sa madaling sabi, ang konsepto ay batay sa mga sistema ng CI/CD tulad ng Jenkins ΠΈ Gitlab CI. Sa pareho, maaari kang magtakda ng mga variable ng kapaligiran na nauugnay sa isang partikular na kapaligiran. Alinsunod dito, sa sitwasyong ito, matutupad ang punto c Mga pagsasaayos.
At ang punto tungkol sa Bumuo, bitawan, tumakbo ay nalutas sa pamamagitan ng mga built-in na function na may pangalan Padaanin sa tubo.
Padaanin sa tubo ay nagbibigay-daan sa iyo na hatiin ang proseso ng pag-deploy sa maraming yugto, na i-highlight ang mga yugto ng pagpupulong, paglabas at pagpapatupad. Gayundin sa Pipeline, maaari kang lumikha ng mga backup, at sa katunayan kahit ano. Ito ay isang tool na may walang limitasyong potensyal.
Ang application code ay nasa .
Huwag kalimutang simulan ang submodule kapag nag-clone ng repositoryong ito.
PS: Ang lahat ng mga pamamaraang ito ay maaaring gamitin sa anumang iba pang mga utility at programming language. Ang pangunahing bagay ay ang kakanyahan ay hindi naiiba.
Pinagmulan: www.habr.com