Биз True Engineering компаниясында кардарлардын серверлерине жаңыртууларды үзгүлтүксүз жеткирүү процессин орноттук жана бул тажрыйбаны бөлүшкүбүз келет.
Баштоо үчүн, биз кардар үчүн онлайн тутумун иштеп чыктык жана аны өзүбүздүн Kubernetes кластерибизге орноттук. Азыр биздин жогорку жүктөөчү чечимибиз кардардын платформасына өттү, ал үчүн биз толук автоматтык Үзгүлтүксүз жайылтуу процессин орноттук. Мунун аркасында биз рынокко чыгууну тездеттик - продукт чөйрөсүнө өзгөртүүлөрдү жеткирүү.
Бул макалада биз үзгүлтүксүз жайылтуу (CD) процессинин бардык этаптары же кардардын платформасына жаңыртууларды жеткирүү жөнүндө сүйлөшөбүз:
- Бул процесс кантип башталат?
- кардардын Git репозиторий менен синхрондоштуруу,
- backend жана frontend жыйындысы,
- сыноо чөйрөсүндө автоматтык тиркемени жайылтуу,
- Продко автоматтык түрдө жайгаштыруу.
Орнотуу чоо-жайын жолдо бөлүшөбүз.
1. CDди баштаңыз
Үзгүлтүксүз жайгаштыруу иштеп чыгуучунун Git репозиторийибиздин релиз бутагына өзгөртүүлөрдү киргизүү менен башталат.
Биздин тиркеме микросервис архитектурасында иштейт жана анын бардык компоненттери бир репозиторийде сакталат. Мунун аркасында, алардын бири өзгөргөн болсо да, бардык микросервистер чогултулуп, орнотулат.
Биз бир нече себептерден улам бир репозиторий аркылуу ишти уюштурдук:
- Иштеп чыгуунун жөнөкөйлүгү - тиркеме жигердүү өнүгүп жатат, ошондуктан сиз бир эле учурда бардык код менен иштей аласыз.
- Колдонмонун бирдиктүү система катары бардык сыноолордон өтүп, кардардын өндүрүш чөйрөсүнө жеткирилишин кепилдеген бирдиктүү CI/CD түтүгү.
- Биз версиялардагы башаламандыкты жок кылабыз – микросервис версияларынын картасын сактап, Helm скрипттеринде ар бир микросервис үчүн анын конфигурациясын сүрөттөп берүүнүн кажети жок.
2. Кардардын баштапкы кодун Git репозиторий менен синхрондоштуруу
Киргизилген өзгөртүүлөр кардардын Git репозиторийине автоматтык түрдө шайкештирилет. Ал жерде тиркеменин жыйындысы конфигурацияланат, ал филиалды жаңырткандан кийин ишке киргизилет жана улантууга жайылтылат. Эки процесс тең Git репозиторийинен келип чыгат.
Биз кардардын репозиторийлери менен түздөн-түз иштей албайбыз, анткени иштеп чыгуу жана сыноо үчүн өзүбүздүн чөйрөбүз керек. Бул максаттар үчүн биз Git репозиторийибизди колдонобуз - ал алардын Git репозиторийлери менен синхрондолуп турат. Иштеп чыгуучу биздин репозиторийдин тиешелүү бутагына өзгөртүүлөрдү киргизээри менен, GitLab дароо бул өзгөртүүлөрдү кардарга түртөт.
Андан кийин сиз чогултуу керек. Ал бир нече этаптан турат: backend жана frontend монтаждоо, сыноо жана өндүрүшкө жеткирүү.
3. Арткы жана алдыңкы бөлүктөрдү чогултуу
Backend жана frontend куруу - GitLab Runner тутумунда аткарылуучу эки параллелдүү тапшырма. Анын баштапкы конфигурациясы ошол эле репозиторийде жайгашкан.
.
GitLab Runner талап кылынган репозиторийден кодду алып, аны Java тиркемесин түзүү буйругу менен чогултат жана аны Docker реестрине жөнөтөт. Бул жерде биз backend жана frontend чогултабыз, Docker сүрөттөрүн алабыз, аларды кардардын тарабындагы репозиторийге салабыз. Docker сүрөттөрүн башкаруу үчүн биз колдонобуз .
Сүрөттөрүбүздүн версияларын Dockerде жарыялана турган релиз версиясы менен синхронизациялайбыз. Ыңгайсыз иштөө үчүн биз бир нече түзөтүүлөрдү жасадык:
1. Контейнерлер сыноо чөйрөсү менен өндүрүш чөйрөсүнүн ортосунда кайра курулбайт. Биз бир эле контейнер бардык орнотуулар, чөйрө өзгөрмөлөрү жана кызматтар менен сыноо чөйрөсүндө да, өндүрүштө да кайра куруусуз иштей алышы үчүн параметризацияларды жасадык.
2. Helm аркылуу тиркемени жаңыртуу үчүн анын версиясын көрсөтүү керек. Биз тиркемени backend, frontend курабыз жана жаңыртабыз - бул үч башка тапшырма, ошондуктан бардык жерде тиркеменин бирдей версиясын колдонуу маанилүү. Бул тапшырма үчүн биз Git тарыхындагы маалыматтарды колдонобуз, анткени биздин K8S кластердик конфигурациябыз жана тиркемелерибиз бир эле Git репозиторийинде.
Колдонмонун версиясын буйруктун аткарылышынын натыйжаларынан алабыз
git describe --tags --abbrev=7.
4. Сыноо чөйрөсүндөгү бардык өзгөртүүлөрдү автоматтык түрдө жайылтуу (UAT)
Бул куруу скриптинин кийинки кадамы K8S кластерин автоматтык түрдө жаңыртуу. Бул колдонмо толугу менен курулган жана бардык артефакттар Докер реестрине жарыяланган шартта болот. Андан кийин, сыноо чөйрөсүн жаңыртуу башталат.
Кластердин жаңыртуусу колдонула баштады . Натыйжада, бир нерсе планга ылайык болбой калса, Helm автоматтык түрдө жана өз алдынча бардык өзгөртүүлөрдү артка кайтарат. Анын ишин көзөмөлдөөнүн кереги жок.
Биз жыйын менен бирге K8S кластер конфигурациясын камсыздайбыз. Ошондуктан, кийинки кадам - аны жаңыртуу: configMaps, жайылтуулар, кызматтар, сырлар жана биз өзгөрткөн башка K8S конфигурациялары.
Helm андан кийин сыноо чөйрөсүндө колдонмонун RollOut жаңыртуусун иштетет. Колдонмо өндүрүшкө киргизилгенге чейин. Бул колдонуучулар биз сыноо чөйрөсүнө киргизген бизнес функцияларын кол менен сынай алышы үчүн жасалат.
5. Продукцияга бардык өзгөртүүлөрдү автоматтык түрдө жайылтуу
Өндүрүш чөйрөсүнө жаңыртууну жайылтуу үчүн, сиз жөн гана GitLabдагы бир баскычты басышыңыз керек - жана контейнерлер дароо өндүрүш чөйрөсүнө жеткирилет.
Бир эле тиркеме ар кандай чөйрөдө — сыноодо жана өндүрүштө — кайра куруусуз иштей алат. Биз ошол эле артефакттарды тиркемеде эч нерсени өзгөртпөстөн колдонобуз жана параметрлерди сырттан орнотобуз.
Колдонмонун жөндөөлөрүнүн ийкемдүү параметрлери тиркеме аткарыла турган чөйрөгө жараша болот. Биз бардык чөйрө жөндөөлөрүн сыртка жылдырдык: баары K8S конфигурациясы жана Helm параметрлери аркылуу параметрленген. Helm монтажды сыноо чөйрөсүнө жайгаштырганда, сыноо жөндөөлөрү ага колдонулат, ал эми продукт орнотуулары өндүрүш чөйрөсүнө колдонулат.
Эң кыйыны – айлана-чөйрөгө көз каранды болгон бардык колдонулган кызматтарды жана өзгөрмөлөрдү параметрлештирүү жана аларды чөйрөнүн өзгөрмөлөрүнө жана Helm үчүн чөйрөнүн параметрлеринин сыпаттама-конфигурацияларына которуу.
Колдонмонун жөндөөлөрү чөйрө өзгөрмөлөрүн колдонот. Алардын баалуулуктары Go шаблондору аркылуу калыпка салынган K8S конфигмасынын жардамы менен контейнерлерде орнотулган. Мисалы, домендик аталышка чөйрө өзгөрмөсүн орнотуу төмөнкүдөй жасалышы мүмкүн:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – бул өзгөрмө чөйрөнүн атын сактайт (прод, стадия, UAT).
.Values.app.properties.app_external_domain – бул өзгөрмө биз .Values.yaml файлында каалаган доменди койду
Тиркемени жаңыртып жатканда, Helm шаблондордон configmap.yaml файлын түзөт жана APP_EXTERNAL_DOMAIN маанисин колдонмо жаңыртуу башталган чөйрөгө жараша керектүү мааниге толтурат. Бул өзгөрмө контейнерде мурунтан эле коюлган. Ага колдонмодон кирүүгө болот, андыктан ар бир колдонмо чөйрөсү бул өзгөрмө үчүн башка мааниге ээ болот.
Салыштырмалуу жакында, K8S колдоосу Spring Cloud'та пайда болду, анын ичинде configMaps менен иштөө: . Долбоор активдүү өнүгүп, түп-тамырынан бери өзгөрүп жаткан кезде биз аны өндүрүштө колдоно албайбыз. Бирок биз анын абалына активдүү көз салып, DEV конфигурацияларында колдонобуз. Ал турукташтырылгандан кийин, биз чөйрө өзгөрмөлөрүн колдонуудан ага өтөбүз.
жалпы
Ошентип, Үзгүлтүксүз жайылтуу конфигурацияланган жана иштеп жатат. Бардык жаңыртуулар бир баскыч басуу менен ишке ашат. Продукт чөйрөсүнө өзгөртүүлөрдү жеткирүү автоматтык түрдө. Жана эң негизгиси, жаңыртуулар системаны токтотпойт.
Келечектеги пландар: маалымат базасын автоматтык түрдө көчүрүү
Биз маалымат базасын жаңыртуу жана бул өзгөртүүлөрдү артка кайтаруу мүмкүнчүлүгү жөнүндө ойлондук. Анткени, тиркеменин эки башка версиясы бир эле учурда иштеп жатат: эскиси иштеп жатат, жаңысы иштеп жатат. Ал эми жаңы версиясы иштей турганына ишенсек гана эскисин өчүрөбүз. Маалымат базасын көчүрүү колдонмонун эки версиясы менен иштөөгө мүмкүндүк бериши керек.
Ошондуктан, биз тилкенин атын же башка маалыматтарды жөн эле өзгөртө албайбыз. Бирок биз жаңы тилке түзүп, ага эски тилкеден маалыматтарды көчүрө алабыз жана маалыматтарды жаңыртып жатканда, аны бир эле учурда башка тилкеге көчүрүп жана жаңылай турган триггерлерди жаза алабыз. Тиркеменин жаңы версиясы ийгиликтүү орнотулгандан кийин, ишке киргизүүдөн кийинки колдоо мезгилинен кийин биз эски тилкени жана керексиз болуп калган триггерди жок кыла алабыз.
Эгерде тиркеменин жаңы версиясы туура иштебесе, биз мурунку версияга, анын ичинде базанын мурунку версиясына кайта алабыз. Кыскасы, биздин өзгөртүүлөр сизге бир эле учурда колдонмонун бир нече версиялары менен иштөөгө мүмкүндүк берет.
Биз K8S жумушу аркылуу маалымат базасын миграциялоону автоматташтыруу, аны CD процессине интеграциялоону пландаштырып жатабыз. Жана биз бул тажрыйбаны Habréде сөзсүз бөлүшөбүз.
Source: www.habr.com