Kami sa True Engineering ay nag-set up ng proseso para sa tuluy-tuloy na paghahatid ng mga update sa mga server ng customer at gustong ibahagi ang karanasang ito.
Upang magsimula, bumuo kami ng online na system para sa customer at inilagay ito sa sarili naming cluster ng Kubernetes. Ngayon ang aming high-load na solusyon ay lumipat na sa platform ng customer, kung saan nag-set up kami ng ganap na awtomatikong proseso ng Continuous Deployment. Dahil dito, pinabilis namin ang time-to-market - ang paghahatid ng mga pagbabago sa kapaligiran ng produkto.
Sa artikulong ito ay pag-uusapan natin ang lahat ng mga yugto ng proseso ng Continuous Deployment (CD) o paghahatid ng mga update sa platform ng customer:
- Paano nagsisimula ang prosesong ito?
- pag-synchronize sa Git repository ng customer,
- pagpupulong ng backend at frontend,
- awtomatikong pag-deploy ng application sa isang pagsubok na kapaligiran,
- awtomatikong deployment sa Prod.
Ibabahagi namin ang mga detalye ng pag-setup sa daan.
1. Simulan ang CD
Nagsisimula ang Continuous Deployment sa pagtulak ng developer ng mga pagbabago sa release branch ng aming Git repository.
Ang aming application ay tumatakbo sa isang microservice architecture at lahat ng mga bahagi nito ay naka-imbak sa isang repository. Salamat dito, ang lahat ng mga microservice ay kinokolekta at na-install, kahit na ang isa sa mga ito ay nagbago.
Inayos namin ang trabaho sa pamamagitan ng isang repository para sa ilang kadahilanan:
- Dali ng pag-unlad - ang application ay aktibong umuunlad, kaya maaari mong gamitin ang lahat ng code nang sabay-sabay.
- Isang pipeline ng CI/CD na ginagarantiyahan na ang application bilang isang sistema ay pumasa sa lahat ng pagsubok at inihahatid sa kapaligiran ng produksyon ng customer.
- Inaalis namin ang pagkalito sa mga bersyon - hindi namin kailangang mag-imbak ng mapa ng mga bersyon ng microservice at ilarawan ang configuration nito para sa bawat microservice sa mga script ng Helm.
2. Pag-synchronize sa Git repository ng source code ng customer
Ang mga pagbabagong ginawa ay awtomatikong naka-synchronize sa Git repository ng customer. Doon ang pagpupulong ng aplikasyon ay na-configure, na inilunsad pagkatapos i-update ang sangay, at pag-deploy sa pagpapatuloy. Ang parehong mga proseso ay nagmula sa kanilang kapaligiran mula sa isang Git repository.
Hindi kami direktang makakapagtrabaho sa repository ng customer dahil kailangan namin ng sarili naming kapaligiran para sa pag-develop at pagsubok. Ginagamit namin ang aming Git repository para sa mga layuning ito - ito ay naka-synchronize sa kanilang Git repository. Sa sandaling mag-post ang isang developer ng mga pagbabago sa naaangkop na sangay ng aming repository, agad na itinutulak ng GitLab ang mga pagbabagong ito sa customer.
Pagkatapos nito kailangan mong gawin ang pagpupulong. Binubuo ito ng ilang yugto: backend at frontend assembly, pagsubok at paghahatid sa produksyon.
3. Pag-assemble ng backend at frontend
Ang pagbuo ng backend at frontend ay dalawang magkatulad na gawain na ginagawa sa GitLab Runner system. Ang orihinal na configuration ng assembly nito ay matatagpuan sa parehong repositoryo.
.
Kinukuha ng GitLab Runner ang code mula sa kinakailangang repository, tinitipon ito gamit ang Java application build command at ipinapadala ito sa Docker registry. Dito tinitipon namin ang backend at frontend, kumuha ng mga larawan ng Docker, na inilalagay namin sa isang repositoryo sa panig ng customer. Upang pamahalaan ang mga imahe ng Docker na ginagamit namin .
Isina-synchronize namin ang mga bersyon ng aming mga larawan sa bersyon ng release na ipa-publish sa Docker. Para sa maayos na operasyon, gumawa kami ng ilang mga pagsasaayos:
1. Hindi itinayong muli ang mga lalagyan sa pagitan ng kapaligiran ng pagsubok at kapaligiran ng produksyon. Gumawa kami ng mga parametrization para gumana ang parehong container sa lahat ng setting, variable ng environment, at serbisyo pareho sa environment ng pagsubok at sa produksyon nang hindi muling itinatayo.
2. Upang i-update ang isang application sa pamamagitan ng Helm, dapat mong tukuyin ang bersyon nito. Binubuo namin ang backend, frontend at ina-update ang application - ito ay tatlong magkakaibang gawain, kaya mahalagang gamitin ang parehong bersyon ng application sa lahat ng dako. Para sa gawaing ito, gumagamit kami ng data mula sa kasaysayan ng Git, dahil ang aming K8S cluster configuration at mga application ay nasa parehong Git repository.
Nakukuha namin ang bersyon ng application mula sa mga resulta ng pagpapatupad ng command
git describe --tags --abbrev=7.
4. Awtomatikong pag-deploy ng lahat ng pagbabago sa kapaligiran ng pagsubok (UAT)
Ang susunod na hakbang sa build script na ito ay awtomatikong i-update ang K8S cluster. Nangyayari ito sa kondisyon na ang buong application ay binuo at ang lahat ng artifact ay nai-publish sa Docker Registry. Pagkatapos nito, magsisimula ang pag-update sa kapaligiran ng pagsubok.
Sinimulan nang gamitin ang pag-update ng cluster . Kung, bilang isang resulta, ang isang bagay ay hindi napunta ayon sa plano, awtomatiko at independiyenteng ibabalik ng Helm ang lahat ng mga pagbabago nito. Ang kanyang trabaho ay hindi kailangang kontrolin.
Nagbibigay kami ng K8S cluster configuration kasama ng assembly. Samakatuwid, ang susunod na hakbang ay i-update ito: configMaps, deployment, serbisyo, lihim at anumang iba pang configuration ng K8S na binago namin.
Ang Helm ay nagpapatakbo ng isang RollOut na update ng mismong application sa kapaligiran ng pagsubok. Bago i-deploy ang application sa produksyon. Ginagawa ito upang manu-manong masubukan ng mga user ang mga feature ng negosyo na inilalagay namin sa kapaligiran ng pagsubok.
5. Awtomatikong pag-deploy ng lahat ng pagbabago sa Prod
Para mag-deploy ng update sa production environment, kailangan mo lang mag-click ng isang button sa GitLab - at ang mga container ay ihahatid kaagad sa production environment.
Ang parehong application ay maaaring gumana sa iba't ibang mga kapaligiran-pagsubok at produksyon-nang walang muling pagtatayo. Ginagamit namin ang parehong mga artifact nang hindi binabago ang anumang bagay sa application, at itinakda namin ang mga parameter sa labas.
Ang flexible parameterization ng mga setting ng application ay depende sa kapaligiran kung saan isasagawa ang application. Inilipat namin ang lahat ng mga setting ng kapaligiran sa labas: ang lahat ay na-parameter sa pamamagitan ng configuration ng K8S at Helm na mga parameter. Kapag nag-deploy ang Helm ng assembly sa environment ng pagsubok, ilalapat dito ang mga setting ng pagsubok, at ilalapat ang mga setting ng produkto sa kapaligiran ng produksyon.
Ang pinakamahirap na bagay ay ang pag-parameter ng lahat ng ginamit na serbisyo at variable na umaasa sa kapaligiran, at isalin ang mga ito sa mga variable ng kapaligiran at paglalarawan-configuration ng mga parameter ng kapaligiran para sa Helm.
Gumagamit ang mga setting ng application ng mga variable ng kapaligiran. Nakatakda ang kanilang mga halaga sa mga container gamit ang K8S configmap, na naka-template gamit ang mga template ng Go. Halimbawa, ang pagtatakda ng environment variable sa domain name ay maaaring gawin tulad nito:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env β iniimbak ng variable na ito ang pangalan ng kapaligiran (prod, stage, UAT).
.Values.app.properties.app_external_domain β sa variable na ito itinakda namin ang gustong domain sa .Values.yaml file
Kapag nag-a-update ng application, gumagawa ang Helm ng configmap.yaml na file mula sa mga template at pinupunan ang value ng APP_EXTERNAL_DOMAIN ng gustong value depende sa kapaligiran kung saan magsisimula ang pag-update ng application. Nakatakda na ang variable na ito sa container. Maaari itong ma-access mula sa application, kaya ang bawat environment ng application ay magkakaroon ng ibang halaga para sa variable na ito.
Kamakailan lamang, lumitaw ang suporta ng K8S sa Spring Cloud, kabilang ang pagtatrabaho sa configMaps: . Habang ang proyekto ay aktibong umuunlad at nagbabago nang radikal, hindi natin ito magagamit sa produksyon. Ngunit aktibong sinusubaybayan namin ang kundisyon nito at ginagamit ito sa mga configuration ng DEV. Sa sandaling mag-stabilize ito, lilipat tayo mula sa paggamit ng mga variable ng kapaligiran dito.
Sa kabuuan
Kaya, ang Continuous Deployment ay na-configure at gumagana. Ang lahat ng mga update ay nangyayari sa isang keystroke. Ang paghahatid ng mga pagbabago sa kapaligiran ng produkto ay awtomatiko. At, mahalaga, hindi pinipigilan ng mga pag-update ang system.
Mga plano sa hinaharap: awtomatikong paglilipat ng database
Naisip namin ang tungkol sa pag-upgrade ng database at ang posibilidad na ibalik ang mga pagbabagong ito. Pagkatapos ng lahat, dalawang magkaibang bersyon ng application ang tumatakbo sa parehong oras: ang luma ay tumatakbo, at ang bago ay pataas. At isasara lang namin ang luma kapag sigurado kaming gumagana ang bagong bersyon. Ang paglilipat ng database ay dapat magpapahintulot sa iyo na magtrabaho kasama ang parehong mga bersyon ng application.
Samakatuwid, hindi natin basta-basta mababago ang pangalan ng column o iba pang data. Ngunit maaari tayong lumikha ng bagong column, kumopya ng data mula sa lumang column papunta dito at magsulat ng mga trigger na, kapag ina-update ang data, ay sabay-sabay na kokopya at ia-update ito sa isa pang column. At pagkatapos ng matagumpay na pag-deploy ng bagong bersyon ng application, pagkatapos ng post launch support period, magagawa naming tanggalin ang lumang column at ang trigger na naging hindi na kailangan.
Kung ang bagong bersyon ng application ay hindi gumana nang tama, maaari kaming bumalik sa nakaraang bersyon, kasama ang nakaraang bersyon ng database. Sa madaling salita, ang aming mga pagbabago ay magbibigay-daan sa iyo upang gumana nang sabay-sabay sa ilang mga bersyon ng application.
Plano naming i-automate ang paglilipat ng database sa pamamagitan ng trabahong K8S, isama ito sa proseso ng CD. At talagang ibabahagi namin ang karanasang ito sa HabrΓ©.
Pinagmulan: www.habr.com