Iminumungkahi kong basahin mo ang transcript ng ulat ni Alexander Sigachev mula sa Inventos "Proseso ng pag-unlad at pagsubok kasama ang Docker + Gitlab CI"
Ang mga nagsisimula pa lamang na ipatupad ang proseso ng pagbuo at pagsubok batay sa Docker + Gitlab CI ay madalas na nagtatanong ng mga pangunahing katanungan. Saan magsisimula? Paano mag-organisa? Paano mag test?
Maganda ang ulat na ito dahil nagsasalita ito sa isang structured na paraan tungkol sa proseso ng pag-develop at pagsubok gamit ang Docker at Gitlab CI. Ang ulat mismo ay mula sa 2017. Sa tingin ko, mula sa ulat na ito maaari mong makuha ang mga pangunahing kaalaman, pamamaraan, ideya, at karanasan sa paggamit.
Para sa sinumang interesado, mangyaring tingnan ang pusa.
Ang pangalan ko ay Alexander Sigachev. Nagtatrabaho ako sa Inventos. Sasabihin ko sa iyo ang tungkol sa aking karanasan sa paggamit ng Docker at kung paano namin ito unti-unting ipinapatupad sa mga proyekto sa kumpanya.
Paksa ng ulat: Proseso ng pag-develop gamit ang Docker at Gitlab CI.
Ito ang aking pangalawang pag-uusap tungkol sa Docker. Sa panahon ng unang ulat, ginamit lang namin ang Docker sa Development sa mga developer machine. Ang bilang ng mga empleyado na gumamit ng Docker ay humigit-kumulang 2-3 tao. Unti-unti, natamo ang karanasan at lumayo pa kami ng kaunti. Link sa aming .
Ano ang magiging ulat na ito? Ibabahagi namin ang aming karanasan tungkol sa kung ano ang mga rake na aming nakolekta, kung anong mga problema ang aming nalutas. Ito ay hindi maganda sa lahat ng dako, ngunit ito ay nagpapahintulot sa amin na magpatuloy.
Ang aming motto: i-dockerize ang lahat ng aming mga kamay.
Anong mga problema ang ating nilulutas?
Kapag ang isang kumpanya ay may ilang mga koponan, ang programmer ay isang nakabahaging mapagkukunan. May mga yugto kapag ang isang programmer ay na-pull out sa isang proyekto at ibinigay sa isa pang proyekto sa loob ng ilang panahon.
Upang mabilis na maunawaan ng isang programmer, kailangan niyang i-download ang source code ng proyekto at ilunsad ang isang kapaligiran nang mabilis hangga't maaari, na magbibigay-daan sa kanya upang higit pang sumulong sa paglutas ng mga problema ng proyektong ito.
Karaniwan, kung magsisimula ka mula sa simula, mayroong maliit na dokumentasyon sa proyekto. Tanging mga lumang-timer lang ang may impormasyon kung paano ito i-set up. Ang mga empleyado ay nag-set up ng kanilang lugar ng trabaho nang mag-isa sa isa o dalawang araw. Upang mapabilis ito, ginamit namin ang Docker.
Ang susunod na dahilan ay ang standardisasyon ng mga setting sa Development. Sa aking karanasan, palaging nagkukusa ang mga developer. Sa bawat ikalimang kaso, isang custom na domain ang ipinasok, halimbawa vasya.dev. Nakaupo sa tabi ko ang aking kapitbahay na si Petya, na ang domain ay petya.dev. Bumubuo sila ng website o ilang bahagi ng system gamit ang domain name na ito.
Kapag lumaki ang system at nagsimulang maisama ang mga domain name na ito sa pagsasaayos, lumitaw ang isang salungatan sa mga kapaligiran ng Pag-unlad at muling isinulat ang landas ng site.
Ang parehong bagay ay nangyayari sa mga setting ng database. Ang ilang mga tao ay hindi nag-abala sa seguridad at nagtatrabaho sa isang walang laman na root password. Sa yugto ng pag-install, humingi ng password ang MySQL sa isang tao at ang password ay naging 123. Madalas na nangyayari na ang database config ay patuloy na nagbabago depende sa commit ng developer. May nag correct, may hindi nag correct ng config. May mga trick kapag naglagay kami ng ilang pagsubok na config .gitignore at kailangang i-install ng bawat developer ang database. Ginawa nitong mas mahirap ang panimulang proseso. Sa iba pang mga bagay, kailangan mong tandaan ang tungkol sa database. Ang database ay dapat na masimulan, ang isang password ay dapat na nakarehistro, ang isang user ay dapat na nakarehistro, ang isang sign ay dapat na nilikha, at iba pa.
Ang isa pang problema ay ang iba't ibang bersyon ng mga aklatan. Madalas na nangyayari na ang isang developer ay gumagana sa iba't ibang mga proyekto. Mayroong isang Legacy project, na nagsimula limang taon na ang nakakaraan (mula 2017 - tala ng editor). Sa simula nagsimula kami sa MySQL 5.5. Mayroon ding mga modernong proyekto kung saan sinusubukan naming ipatupad ang mas modernong bersyon ng MySQL, halimbawa 5.7 o mas matanda (sa 2017 - tala ng editor)
Alam ng sinumang nagtatrabaho sa MySQL na ang mga aklatang ito ay may mga dependency. Medyo may problemang magpatakbo ng 2 database nang magkasama. Hindi bababa sa, ito ay may problemang ikonekta ang mga lumang kliyente sa bagong database. Ito naman ay nagdudulot ng maraming problema.
Ang susunod na problema ay kapag ang isang developer ay gumagana sa isang lokal na makina, siya ay gumagamit ng mga lokal na mapagkukunan, mga lokal na file, lokal na RAM. Ang lahat ng pakikipag-ugnayan sa oras ng pagbuo ng isang solusyon sa mga problema ay isinasagawa sa loob ng balangkas ng katotohanan na ito ay gumagana sa isang makina. Ang isang halimbawa ay kapag mayroon kaming mga backend server sa Production 3, at ang developer ay nagse-save ng mga file sa root directory at mula doon ay kinukuha ng nginx ang mga file upang tumugon sa kahilingan. Kapag nakapasok ang naturang code sa Production, lumalabas na ang file ay nasa isa sa 3 server.
Ang direksyon ng mga microservice ay kasalukuyang umuunlad. Kapag hinati namin ang aming malalaking application sa ilang maliliit na bahagi na nakikipag-ugnayan sa isa't isa. Binibigyang-daan ka nitong pumili ng mga teknolohiya para sa isang partikular na stack ng gawain. Pinapayagan ka nitong hatiin ang trabaho at lugar ng responsibilidad sa pagitan ng mga developer.
Ang isang frontend developer, na umuunlad sa JS, ay halos walang impluwensya sa backend. Ang developer ng backend, sa turn, ay bubuo, sa aming kaso, si Ruby on Rails at hindi nakikialam sa Frondend. Ginagawa ang pakikipag-ugnayan gamit ang API.
Bilang isang bonus, gamit ang Docker, nakapag-recycle kami ng mga mapagkukunan sa Staging. Ang bawat proyekto, dahil sa mga detalye nito, ay nangangailangan ng ilang mga setting. Sa pisikal, kinakailangang maglaan ng alinman sa isang virtual na server at i-configure ang mga ito nang hiwalay, o hatiin ang ilang uri ng variable na kapaligiran at ang mga proyekto ay maaaring makaimpluwensya sa isa't isa, depende sa bersyon ng mga aklatan.
Mga gamit. Ano ang gamit natin?
- Docker mismo. Inilalarawan ng Dockerfile ang mga dependencies ng isang application.
- Ang Docker-compose ay isang bundle na pinagsasama-sama ang ilan sa aming mga application ng Docker.
- Ginagamit namin ang GitLab upang mag-imbak ng source code.
- Ginagamit namin ang GitLab-CI para sa pagsasama ng system.
Ang ulat ay binubuo ng dalawang bahagi.
Sasabihin sa iyo ng unang bahagi kung paano patakbuhin ang Docker sa mga makina ng mga developer.
Ang ikalawang bahagi ay pag-uusapan kung paano makipag-ugnayan sa GitLab, kung paano kami nagpapatakbo ng mga pagsubok at kung paano kami lalabas sa Staging.
Ang Docker ay isang teknolohiya na nagbibigay-daan (gamit ang isang deklaratibong diskarte) na ilarawan ang mga kinakailangang bahagi. Ito ay isang halimbawa ng Dockerfile. Dito ipinapahayag namin na nagmana kami mula sa opisyal na imahe ng Docker ng Ruby:2.3.0. Naglalaman ito ng Ruby na bersyon 2.3 na naka-install. Ini-install namin ang mga kinakailangang aklatan ng pagpupulong at NodeJS. Inilalarawan namin na gumagawa kami ng isang direktoryo /app. Itinalaga namin ang direktoryo ng app bilang gumaganang direktoryo. Sa direktoryong ito inilalagay namin ang kinakailangang minimum na Gemfile at Gemfile.lock. Pagkatapos ay bumuo kami ng mga proyektong nag-i-install ng dependency na larawang ito. Ipinapahiwatig namin na ang lalagyan ay handang makinig sa panlabas na port 3000. Ang huling command ay ang command na direktang naglulunsad ng aming application. Kung ipapatupad natin ang project run command, susubukan ng application na patakbuhin at patakbuhin ang tinukoy na command.
Ito ay isang minimal na halimbawa ng isang docker-compose file. Sa kasong ito, ipinapakita namin na mayroong koneksyon sa pagitan ng dalawang lalagyan. Direkta ito sa serbisyo ng database at serbisyo sa web. Ang aming mga web application sa karamihan ng mga kaso ay nangangailangan ng ilang uri ng database bilang backend para sa pag-iimbak ng data. Dahil gumagamit kami ng MySQL, ang halimbawa ay sa MySQL - ngunit walang pumipigil sa amin na gumamit ng iba pang database (PostgreSQL, Redis).
Kinukuha namin ang MySQL 5.7.14 na imahe nang walang mga pagbabago mula sa opisyal na pinagmulan mula sa Docker hub. Kinokolekta namin ang imahe na responsable para sa aming web application mula sa kasalukuyang direktoryo. Sa unang paglulunsad, nangongolekta siya ng imahe para sa amin. Pagkatapos ay pinapatakbo nito ang utos na ipinapatupad namin dito. Kung babalik tayo, makikita natin na ang utos ng paglunsad ay tinukoy sa pamamagitan ng Puma. Ang Puma ay isang serbisyong nakasulat sa Ruby. Sa pangalawang kaso, na-override namin. Ang utos na ito ay maaaring maging arbitrary depende sa ating mga pangangailangan o gawain.
Inilalarawan din namin na kailangan naming ipasa ang port sa aming developer host machine mula 3000 hanggang 3000 container port. Awtomatikong ginagawa ito gamit ang mga iptable at sarili nitong mekanismo, na direktang naka-embed sa Docker.
Maaaring ma-access ng developer, tulad ng dati, ang anumang magagamit na IP address, halimbawa, 127.0.0.1 lokal o panlabas na IP address ng makina.
Ang huling linya ay nagsasabi na ang web container ay nakadepende sa db container. Kapag tinawag namin ang lalagyan ng web para ilunsad, ilulunsad muna ng docker-compose ang database para sa amin. Sa simula na ng database (sa katunayan, pagkatapos ng paglulunsad ng lalagyan! Hindi nito ginagarantiyahan ang pagiging handa ng database) ilulunsad nito ang aming aplikasyon, ang aming backend.
Nagbibigay-daan ito sa amin na maiwasan ang mga error kapag wala ang database at nagbibigay-daan sa amin na mag-save ng mga mapagkukunan kapag itinigil namin ang lalagyan ng database, at sa gayon ay mapapalaya ang mga mapagkukunan para sa iba pang mga proyekto.
Ano ang ibinibigay sa atin ng paggamit ng database dockerization sa isang proyekto? Itinatala namin ang bersyon ng MySQL para sa lahat ng mga developer. Nagbibigay-daan ito sa iyo na maiwasan ang ilang mga error na maaaring mangyari kapag nag-iba ang mga bersyon, kapag nagbago ang syntax, configuration, at default na mga setting. Pinapayagan ka nitong tukuyin ang isang karaniwang hostname para sa database, pag-login, password. Lumalayo na kami sa zoo ng mga pangalan at salungatan sa mga config file na umiral noon.
Mayroon kaming pagkakataong gumamit ng mas pinakamainam na config para sa Development environment, na mag-iiba mula sa default. Ang MySQL ay na-configure bilang default para sa mga mahihinang makina at ang pagganap nito sa labas ng kahon ay napakababa.
Pinapayagan ka ng Docker na gamitin ang Python, Ruby, NodeJS, PHP interpreter ng nais na bersyon. Inaalis namin ang pangangailangang gumamit ng ilang uri ng tagapamahala ng bersyon. Noong nakaraan, isang rpm package ang ginamit para kay Ruby, na nagpapahintulot sa iyong baguhin ang bersyon depende sa proyekto. Salamat sa lalagyan ng Docker, nagbibigay-daan din ito sa iyo na maayos na mag-migrate ng code at bersyon nito kasama ng mga dependency. Wala kaming problema sa pag-unawa sa bersyon ng parehong interpreter at code. Para i-update ang bersyon, kailangan mong ibaba ang lumang container at itaas ang bagong container. Kung may mali, maaari nating ibaba ang bagong lalagyan, itaas ang lumang lalagyan.
Pagkatapos buuin ang imahe, ang mga lalagyan sa Development at Production ay magiging pareho. Ito ay totoo lalo na para sa malalaking pag-install.
Sa Frontend ginagamit namin ang JavaScipt at NodeJS.
Ngayon ay mayroon na tayong huling proyekto sa ReacJS. Inilunsad ng developer ang lahat sa container at binuo gamit ang hot-reload.
Susunod, ang gawain ng pag-assemble ng JavaScipt ay inilunsad at ang statically assembled code ay ipinadala sa pamamagitan ng nginx, pag-save ng mga mapagkukunan.
Dito ay nagbigay ako ng diagram ng aming pinakabagong proyekto.
Anong mga problema ang nalutas mo? Kailangan naming bumuo ng isang sistema kung saan nakikipag-ugnayan ang mga mobile device. Nakatanggap sila ng data. Isa sa mga posibilidad ay magpadala ng mga push notification sa device na ito.
Ano ang nagawa natin para dito?
Hinati namin ang application sa mga sumusunod na bahagi: isang bahagi ng admin sa JS, isang backend na gumagana sa pamamagitan ng REST interface sa ilalim ng Ruby on Rails. Nakikipag-ugnayan ang backend sa database. Ang resulta na nabuo ay ibinibigay sa kliyente. Nakikipag-ugnayan ang admin panel sa backend at database sa pamamagitan ng REST interface.
Kailangan din naming magpadala ng mga Push notification. Bago ito, mayroon kaming proyekto kung saan ipinatupad ang isang mekanismo na responsable sa paghahatid ng mga abiso sa mga mobile platform.
Binuo namin ang sumusunod na scheme: ang operator mula sa browser ay nakikipag-ugnayan sa admin panel, ang admin panel ay nakikipag-ugnayan sa backend, ang gawain ay magpadala ng mga Push notification.
Ang mga push notification ay nakikipag-ugnayan sa isa pang bahagi na ipinapatupad sa NodeJS.
Binuo ang mga pila at ipinapadala ang mga abiso ayon sa kanilang sariling mekanismo.
Dalawang database ang iginuhit dito. Sa kasalukuyan, gamit ang Docker, gumagamit kami ng 2 independiyenteng database na hindi konektado sa isa't isa. Bilang karagdagan sa katotohanan na mayroon silang isang karaniwang virtual network, at ang pisikal na data ay naka-imbak sa iba't ibang mga direktoryo sa makina ng developer.
Ang parehong bagay ngunit sa mga numero. Ang muling paggamit ng code ay mahalaga dito.
Kung mas maaga ay napag-usapan natin ang tungkol sa muling paggamit ng code sa anyo ng mga aklatan, kung gayon sa halimbawang ito ang aming serbisyo, na tumutugon sa mga Push notification, ay muling ginagamit bilang isang kumpletong server. Nagbibigay ito ng API. At ang aming bagong pag-unlad ay nakikipag-ugnayan dito.
Sa oras na iyon ay gumagamit kami ng bersyon 4 ng NodeJS. Ngayon (sa 2017 - tala ng editor) sa aming pinakabagong mga pag-unlad ay ginagamit namin ang bersyon 7 ng NodeJS. Walang problema sa mga bagong bahagi na may kinalaman sa mga bagong bersyon ng mga aklatan.
Kung kinakailangan, maaari mong i-refactor at itaas ang bersyon ng NodeJS ng serbisyo ng Push notification.
At kung mapapanatili natin ang pagiging tugma ng API, posible itong palitan ng iba pang mga proyektong ginamit dati.
Ano ang kailangan mong idagdag sa Docker? Nagdaragdag kami ng Dockerfile sa aming repository, na naglalarawan ng mga kinakailangang dependencies. Sa halimbawang ito, lohikal na hinati ang mga bahagi. Ito ang pinakamababang kit para sa isang backend developer.
Kapag gumagawa ng bagong proyekto, gumagawa kami ng Dockerfile at inilalarawan ang kinakailangang ecosystem (Python, Ruby, NodeJS). Sa docker-compose, inilalarawan nito ang kinakailangang dependency - ang database. Inilalarawan namin na kailangan namin ng database ng ganito at ganoong bersyon, upang mag-imbak ng data doon at doon.
Gumagamit kami ng hiwalay na ikatlong lalagyan na may nginx para maghatid ng static na content. Posibleng mag-upload ng mga larawan. Inilalagay ng backend ang mga ito sa isang pre-prepared volume, na naka-mount din sa isang container na may nginx, na nagbibigay ng static na data.
Upang maimbak ang nginx at mysql configuration, nagdagdag kami ng Docker folder kung saan iniimbak namin ang mga kinakailangang config. Kapag ang isang developer ay gumawa ng git clone ng isang repository sa kanyang makina, mayroon na siyang proyektong handa para sa lokal na pag-unlad. Walang tanong tungkol sa kung aling port o kung aling mga setting ang ilalapat.
Susunod, mayroon kaming ilang bahagi: admin, info-API, push notification.
Upang mailunsad ang lahat ng ito, gumawa kami ng isa pang repository na tinatawag na dockerized-app. Kasalukuyan kaming gumagamit ng maramihang mga repository para sa bawat bahagi. Ang mga ito ay lohikal na naiiba - sa GitLab ay mukhang isang folder, ngunit sa makina ng developer ay mukhang isang folder para sa isang partikular na proyekto. Ang isang antas sa ibaba ay ang mga sangkap na pagsasama-samahin.
Ito ay isang halimbawa ng mga nilalaman ng dockerized-app. Naglalagay din kami ng direktoryo ng Docker dito, kung saan pinupunan namin ang mga configuration na kinakailangan para sa mga pakikipag-ugnayan ng lahat ng mga bahagi. Mayroong README.md na maikling naglalarawan kung paano ilunsad ang proyekto.
Dito naglapat kami ng dalawang docker-compose file. Ginagawa ito upang makapaglunsad ng mga yugto. Kapag gumagana ang isang developer sa kernel, hindi niya kailangan ng mga Push notification, inilulunsad lang niya ang docker-compose file at, nang naaayon, nai-save ang mga mapagkukunan.
Kung may pangangailangan para sa pagsasama sa mga Push notification, ilulunsad ang docker-compose.yaml at docker-compose-push.yaml.
Dahil ang docker-compose.yaml at docker-compose-push.yaml ay nasa folder, isang virtual network ang awtomatikong nagagawa.
Paglalarawan ng mga bahagi. Ito ay isang mas advanced na file na responsable para sa pagkolekta ng mga bahagi. Ano ang kapansin-pansin dito? Dito ipinakilala namin ang bahagi ng balancer.
Ito ay isang handa na Docker na imahe na nagpapatakbo ng nginx at isang application na nakikinig sa Docker socket. Dynamic, habang ang mga container ay naka-on at naka-off, ang nginx config ay muling nabuo. Ibinahagi namin ang pangangasiwa ng mga bahagi gamit ang mga pangalan ng domain sa ikatlong antas.
Para sa Development environment ginagamit namin ang .dev domain - api.informer.dev. Available ang mga application na may .dev domain sa lokal na makina ng developer.
Pagkatapos ang mga config ay inililipat sa bawat proyekto at lahat ng mga proyekto ay inilunsad nang sabay-sabay.
Kung ilarawan namin ito nang grapiko, lumalabas na ang kliyente ay ang aming browser o ilang uri ng tool kung saan kami humihiling sa balancer.
Tinutukoy ng balancer kung aling container ang kailangang i-access batay sa domain name.
Ito ay maaaring nginx, na nagbibigay ng JS sa admin panel. Magagawa ito ng nginx, na nagbibigay ng API, o mga static na file, na ibinibigay ng nginx sa anyo ng paglo-load ng mga imahe.
Ipinapakita ng diagram na ang mga container ay konektado sa isang virtual network at nakatago sa likod ng isang proxy.
Sa makina ng developer, maaari mong ma-access ang lalagyan na alam ang IP, ngunit sa prinsipyo hindi namin ito ginagamit. Halos hindi na kailangan ng direktang kontak.
Anong halimbawa ang dapat kong tingnan upang i-dockerize ang aking aplikasyon? Sa aking opinyon, ang isang magandang halimbawa ay ang opisyal na docker na imahe para sa MySQL.
Ito ay medyo kumplikado. Mayroong maraming mga bersyon. Ngunit ang pag-andar nito ay nagpapahintulot sa iyo na masakop ang maraming mga pangangailangan na maaaring lumitaw sa proseso ng karagdagang pag-unlad. Kung maglalaan ka ng oras at nauunawaan kung paano nakikipag-ugnayan ang lahat, sa palagay ko hindi ka magkakaroon ng anumang mga problema sa pagpapatupad nito sa iyong sarili.
Ang Hub.docker.com ay karaniwang naglalaman ng mga link patungo sa github.com, kung saan direktang ibinibigay ang raw data kung saan maaari kang bumuo ng isang imahe nang mag-isa.
Karagdagan sa repositoryong ito ay mayroong isang script docker-endpoint.sh, na responsable para sa paunang pagsisimula at karagdagang pagproseso ng paglulunsad ng application.
Gayundin sa halimbawang ito mayroong posibilidad ng pagsasaayos gamit ang mga variable ng kapaligiran. Sa pamamagitan ng pagtukoy ng environment variable kapag nagpapatakbo ng isang container o sa pamamagitan ng docker-compose, masasabi nating kailangan nating magtakda ng walang laman na password para sa docker para sa root sa MySQL o anumang gusto natin.
Mayroong isang pagpipilian upang lumikha ng isang random na password. Sinasabi namin na kailangan namin ng user, kailangan naming magtakda ng password para sa user, at kailangan naming lumikha ng database.
Sa aming mga proyekto, bahagyang pinag-isa namin ang Dockerfile, na responsable para sa pagsisimula. Doon ay inayos namin ito sa aming mga pangangailangan upang palawakin lamang ang mga karapatan ng gumagamit na ginagamit ng application. Ginawa nitong posible na gumawa lamang ng database mula sa application console sa hinaharap. Ang mga application ng Ruby ay may mga utos para sa paglikha, pagbabago, at pagtanggal ng mga database.
Ito ay isang halimbawa ng kung ano ang hitsura ng isang partikular na bersyon ng MySQL sa github.com. Maaari mong buksan ang Dockerfile at makita kung paano nagaganap ang pag-install doon.
docker-endpoint.sh script na responsable para sa entry point. Sa panahon ng paunang pagsisimula, kinakailangan ang ilang pagkilos sa paghahanda at ang lahat ng pagkilos na ito ay kasama sa script ng pagsisimula.
Lumipat tayo sa ikalawang bahagi.
Lumipat kami sa gitlab para mag-imbak ng mga source code. Ito ay isang medyo malakas na sistema na may visual na interface.
Ang isa sa mga bahagi ng Gitlab ay ang Gitlab CI. Binibigyang-daan ka nitong ilarawan ang isang serye ng mga utos na pagkatapos ay gagamitin upang ayusin ang isang sistema ng paghahatid ng code o magpatakbo ng awtomatikong pagsubok.
Ulat sa Gitlab CI 2 β ang ulat mula sa Ruby Russia club ay medyo detalyado at maaaring maging interesado sa iyo.
Ngayon ay titingnan natin kung ano ang kinakailangan upang maisaaktibo ang Gitlab CI. Upang mailunsad ang Gitlab CI, kailangan lang nating ilagay ang .gitlab-ci.yml file sa ugat ng proyekto.
Dito namin inilalarawan na gusto naming magsagawa ng isang pagkakasunud-sunod ng mga estado tulad ng pagsubok, pag-deploy.
Nagpapatupad kami ng mga script na direktang tumatawag sa docker-compose build ng aming application. Ito ay isang halimbawa ng backend lamang.
Susunod na sinasabi namin na kinakailangan na magpatakbo ng mga paglilipat upang baguhin ang database at magpatakbo ng mga pagsubok.
Kung ang mga script ay naisakatuparan nang tama at hindi nagbabalik ng error code, pagkatapos ay magpapatuloy ang system sa ikalawang yugto ng pag-deploy.
Ang yugto ng pag-deploy ay kasalukuyang ipinapatupad para sa pagtatanghal. Hindi kami nag-ayos ng walang-downtime na pag-restart.
Pinilit naming pinapatay ang lahat ng mga lalagyan, at pagkatapos ay itinaas namin muli ang lahat ng mga lalagyan, na nakolekta sa unang yugto sa panahon ng pagsubok.
Patakbuhin natin ang mga paglilipat ng database na isinulat ng mga developer para sa kasalukuyang variable na kapaligiran.
May tala na dapat lang itong ilapat sa master branch.
Hindi gumagana kapag nagpapalit ng ibang branch.
Posibleng ayusin ang mga rollout sa mga sangay.
Para maayos pa ito, kailangan nating i-install ang Gitlab Runner.
Ang utility na ito ay nakasulat sa Golang. Ito ay isang solong file na karaniwan sa mundo ng Golang, na hindi nangangailangan ng anumang mga dependency.
Sa pagsisimula, inirehistro namin ang Gitlab Runner.
Natanggap namin ang susi sa Gitlab web interface.
Pagkatapos ay tinatawag namin ang initialization command sa command line.
Pag-configure ng Gitlab Runner sa dialog mode (Shell, Docker, VirtualBox, SSH)
Ang code sa Gitlab Runner ay isasagawa sa bawat commit depende sa .gitlab-ci.yml na setting.
Kung paano ito nakikita sa Gitlab sa web interface. Pagkatapos ikonekta ang GItlab CI, mayroon kaming flag na nagpapakita kung ano ang estado ng build sa ngayon.
Nakita namin na 4 na minuto ang nakalipas isang commit ang ginawa na nakapasa sa lahat ng pagsubok at hindi nagdulot ng anumang problema.
Maaari nating tingnan ang mga build nang mas detalyado. Dito makikita natin na dalawang estado na ang lumipas. Testing status at deployment status sa staging.
Kung mag-click kami sa isang partikular na build, magkakaroon ng console output ng mga command na inilunsad sa proseso ayon sa .gitlab-ci.yml.
Ito ang hitsura ng kwento ng aming produkto. Nakita natin na may mga matagumpay na pagtatangka. Kapag isinumite ang mga pagsusulit, hindi sila lilipat sa susunod na hakbang at hindi na-update ang staging code.
Anong mga problema ang nalutas namin sa pagtatanghal noong ipinatupad namin ang docker? Ang aming system ay binubuo ng mga bahagi at kailangan naming i-restart ang ilan lang sa mga bahagi na na-update sa repositoryo, at hindi ang buong system.
Upang gawin ito, kailangan naming paghiwalayin ang lahat sa magkakahiwalay na mga folder.
Pagkatapos naming gawin ito, nagkaroon kami ng problema sa katotohanan na ang Docker-compose ay lumilikha ng sarili nitong puwang sa network para sa bawat folder at hindi nakikita ang mga bahagi ng kapitbahay nito.
Upang makalibot, ginawa namin nang manu-mano ang network sa Docker. Sa Docker-compose ito ay isinulat na dapat mong gamitin ang naturang network para sa proyektong ito.
Kaya, ang bawat bahagi na nagsisimula sa mesh na ito ay nakakakita ng mga bahagi sa ibang bahagi ng system.
Ang susunod na problema ay ang paghahati ng pagtatanghal sa pagitan ng ilang mga proyekto.
Dahil para sa lahat ng ito upang magmukhang maganda at mas malapit hangga't maaari sa produksyon, mainam na gumamit ng port 80 o 443, na ginagamit saanman sa WEB.
Paano natin ito nalutas? Nagtalaga kami ng isang Gitlab Runner sa lahat ng malalaking proyekto.
Binibigyang-daan ka ng Gitlab na maglunsad ng ilang ibinahagi na Gitlab Runners, na kukuha ng lahat ng mga gawain nang paisa-isa sa isang magulong pagkakasunud-sunod at patakbuhin ang mga ito.
Upang maiwasan ang mga problema sa bahay, nilimitahan namin ang pangkat ng aming mga proyekto sa isang Gitlab Runner, na nakakayanan ang aming mga volume nang walang problema.
Inilipat namin ang nginx-proxy sa isang hiwalay na script ng paglulunsad at isinulat ang mga grid ng lahat ng mga proyekto sa loob nito.
Ang aming proyekto ay may isang grid, at ang balancer ay may ilang mga grids batay sa mga pangalan ng proyekto. Maaari itong mag-proxy nang higit pa sa pamamagitan ng mga pangalan ng domain.
Dumating ang aming mga kahilingan sa domain sa port 80 at naresolba sa isang pangkat ng mga container na nagsisilbi sa domain na ito.
Ano ang iba pang mga problema doon? Ito ang pinapatakbo ng lahat ng container bilang root bilang default. Ito ang root na hindi pantay na root host ng system.
Gayunpaman, kung ilalagay mo ang lalagyan, ito ay magiging ugat at ang file na ginawa namin sa lalagyan na ito ay tumatanggap ng mga karapatan sa ugat.
Kung ang isang developer ay pumasok sa lalagyan at gumawa ng ilang mga utos doon na nakabuo ng mga file, pagkatapos ay umalis sa lalagyan, pagkatapos ay sa kanyang gumaganang direktoryo ay mayroon siyang isang file kung saan wala siyang access.
Paano ito mareresolba? Maaari kang magdagdag ng mga user na nasa container.
Anong mga problema ang lumitaw noong idinagdag namin ang user?
Kapag gumagawa ng user, madalas na hindi magkatugma ang group ID (UID) at user ID (GID).
Upang malutas ang problemang ito sa container, gumagamit kami ng mga user na may ID 1000.
Sa aming kaso, ito ay kasabay ng katotohanan na halos lahat ng mga developer ay gumagamit ng Ubuntu OS. At sa Ubuntu OS ang unang user ay may ID 1000.
May plano ba tayo?
Muling basahin ang dokumentasyon ng Docker. Ang proyekto ay aktibong umuunlad, ang dokumentasyon ay nagbabago. Ang data na nakuha dalawa o tatlong buwan na ang nakalipas ay dahan-dahang nagiging luma na.
Ang ilan sa mga problemang nalutas natin ay maaaring nalutas na sa pamamagitan ng karaniwang paraan.
Gusto ko talagang mag-move on at direktang lumipat sa orkestrasyon.
Ang isang halimbawa ay ang built-in na mekanismo ng Docker na tinatawag na Docker Swarm, na lumabas sa kahon. Gusto kong maglunsad ng isang bagay sa produksyon batay sa teknolohiya ng Docker Swarm.
Ang mga spawning container ay ginagawang hindi maginhawa ang pagtatrabaho sa mga log. Ngayon ang mga log ay nakahiwalay. Ang mga ito ay nakakalat sa mga lalagyan. Ang isa sa mga gawain ay ang gumawa ng maginhawang pag-access sa mga log sa pamamagitan ng isang web interface.
Pinagmulan: www.habr.com