Блогубузду техникалык директорубуздун акыркы сөзүнө негизделген басылмалардан баштайбыз (Дмитрий Столяров). Алардын баары 2016-жылы ар кандай кесиптик иш-чараларда болуп, DevOps жана Docker темасына арналган. Badoo кеңсесинде Docker Moscow жолугушуусунан бир видео, биз буга чейин эле бар сайтта. Жаңылары баяндамалардын маңызын чагылдырган макалалар менен коштолот. Ошентип…
31-майда конференцияда , Фестивалдын алкагында өтүп жаткан “Орус Интернет технологиялары” (RIT++ 2016), “Үзгүлтүксүз жайылтуу жана жайылтуу” бөлүмү “Докер менен үзгүлтүксүз жеткирүүнүн мыкты тажрыйбалары” баяндамасы менен ачылды. Анда Docker жана башка Open Source өнүмдөрүн колдонуу менен Үзгүлтүксүз жеткирүү (CD) процессин куруу боюнча мыкты тажрыйбалар жалпыланган жана системалаштырылган. Биз өндүрүштө бул чечимдер менен иштейбиз, бул бизге практикалык тажрыйбага таянууга мүмкүндүк берет.
Эгер сизде бир саат өткөрүүгө мүмкүнчүлүк болсо , толугу менен көрүүнү сунуштайбыз. Болбосо, төмөндө текст түрүндө негизги кыскача болуп саналат.
Docker менен үзгүлтүксүз жеткирүү
төмөндө үзгүлтүксүз жеткирүү биз окуялардын чынжырын түшүнөбүз, анын натыйжасында Git репозиторийинен колдонмо коду алгач өндүрүшкө келип, андан кийин архивде аяктайт. Ал мындай көрүнөт: Git → Build → Test → Release → Operate.
Отчеттун көпчүлүк бөлүгү куруу стадиясына (колдонмо жыйындысы) арналган жана чыгарылуучу жана иштей турган темалар кыскача козголот. Биз аларды чечүүгө мүмкүндүк берүүчү көйгөйлөр жана моделдер жөнүндө сүйлөшөбүз жана бул калыптардын конкреттүү ишке ашырылышы ар кандай болушу мүмкүн.
Эмне үчүн Докер бул жерде керек? Бул Open Source куралынын контекстинде Үзгүлтүксүз жеткирүү практикасы жөнүндө сөз кылууну бекеринен чечкен жокпуз. Бүтүндөй отчет аны колдонууга арналса да, тиркеменин кодун жайылтуунун негизги үлгүсүн карап чыгууда көптөгөн себептер ачыкка чыгат.
Негизги жайылтуу үлгүсү
Ошентип, биз тиркеменин жаңы версияларын чыгарганда, албетте, биз туш болобуз токтоп калуу маселеси, өндүрүш серверин которуу учурунда түзүлгөн. Тиркеменин эски версиясынан жаңысына трафик дароо өзгөрө албайт: адегенде жаңы версия ийгиликтүү жүктөлүп тим болбостон, ошондой эле "жылытылып" (б.а., суроо-талаптарды тейлөөгө толугу менен даяр) болушу керек.
Ошентип, бир нече убакытка чейин тиркеменин эки версиясы (эски жана жаңы) бир убакта иштейт. Бул автоматтык түрдө алып келет жалпы ресурстук конфликт: тармак, файл системасы, IPC ж.б. Docker менен бул көйгөй тиркеменин ар кандай версияларын өзүнчө контейнерлерде иштетүү менен оңой чечилет, алар үчүн бир эле хосттун (сервер/виртуалдык машина) ичинде ресурстун изоляциясы кепилденет. Албетте, сиз кандайдыр бир трюктар менен такыр изоляциясыз кете аласыз, бирок даяр жана ыңгайлуу курал болсо, анда карама-каршы себеп бар - ага көңүл бурбоо.
Контейнеризация жайгаштырылганда башка көптөгөн артыкчылыктарды берет. Ар кандай колдонмо көз каранды конкреттүү версия (же версия диапазону) котормочу, модулдардын/кеңейтүүлөрдүн болушу ж.б., ошондой эле алардын версиялары. Жана бул түздөн-түз аткарылуучу чөйрөгө гана эмес, ошондой эле бүт айлана-чөйрөгө, анын ичинде системалык программалык камсыздоо жана анын версиясы (колдонулган Linux бөлүштүрүүгө чейин). Контейнерлерде тиркеме коду гана эмес, ошондой эле алдын ала орнотулган тутумдук жана керектүү версиялардын колдонмо программалары камтылгандыктан, сиз көз карандылык менен байланышкан көйгөйлөрдү унута аласыз.
Жалпылап көрөлү негизги жайылтуу үлгүсү төмөнкү факторлорду эске алуу менен жаңы версиялар:
- Алгач, колдонмонун эски версиясы биринчи контейнерде иштейт.
- Жаңы версия андан кийин жайылып, экинчи идишке "жылытылат". Белгилей кетчү нерсе, бул жаңы версиянын өзү жаңыртылган тиркеме кодун гана эмес, ошондой эле анын ар кандай көз карандылыктарын, ошондой эле системанын компоненттерин (мисалы, OpenSSL жаңы версиясын же бүтүндөй бөлүштүрүүнү) камтышы мүмкүн.
- Жаңы версия сурамдарды тейлөөгө толук даяр болгондо, трафик биринчи контейнерден экинчисине өтөт.
- Эски версия азыр токтотулушу мүмкүн.
Колдонмонун ар кандай версияларын өзүнчө контейнерлерде жайгаштыруунун мындай ыкмасы дагы бир ыңгайлуулукту камсыз кылат - тез артка кайтаруу эски версияга (анткени, трафикти керектүү контейнерге которуу жетиштүү).
Акыркы биринчи сунуш капитан да күнөө таба албаган нерседей угулат: "[Docker менен үзгүлтүксүз жеткирүүнү уюштурууда] Docker колдонуңуз [жана ал эмне берерин түшүнүү]" Эсиңизде болсун, бул ар бир маселени чече турган күмүш ок эмес, эң сонун пайдубалды камсыз кылуучу курал.
Кайра жаралуу
"Кайра жаралуу" деп биз тиркемелерди иштетүүдө пайда болгон көйгөйлөрдүн жалпыланган жыйындысын түшүнөбүз. Биз мындай учурлар жөнүндө сөз болуп жатат:
- Сапат бөлүмү тарабынан коюлган сценарийлер өндүрүштө так чыгарылууга тийиш.
- Тиркемелер ар кандай репозиторий күзгүлөрүнүн пакеттерин ала турган серверлерде жарыяланат (убакыттын өтүшү менен алар жаңыртылып, орнотулган тиркемелердин версиялары менен бирге).
- "Баары мен үчүн жергиликтүү иштейт!" (...жана иштеп чыгуучуларга өндүрүшкө уруксат берилбейт.)
- Сиз эски (архивделген) версиясында бир нерсени текшеришиңиз керек.
- ...
Алардын жалпы маани-маңызы колдонулган чөйрөлөрдүн толук шайкештигин (ошондой эле адамдык фактордун жоктугунан) талап кылат. Кайталанууга кантип кепилдик бере алабыз? Docker сүрөттөрүн жасаңыз Git кодунун негизинде, анан аларды каалаган тапшырма үчүн колдонуңуз: тесттик сайттарда, өндүрүштө, программисттердин локалдык машиналарында... Ошол эле учурда аткарылган аракеттерди минималдаштыруу маанилүү. после сүрөттү чогултуу: ал канчалык жөнөкөй болсо, каталар ошончолук азыраак болот.
Инфраструктура бул код
Эгерде инфраструктуралык талаптар (сервердик программалык камсыздоонун болушу, анын версиясы ж.б.) формалдаштырылбаса жана “программаланбаса”, анда ар кандай тиркеменин жаңыртууларынын жайылуусу каргашалуу кесепеттерге алып келиши мүмкүн. Мисалы, сахналаштырууда сиз PHP 7.0ге өткөнсүз жана ошого жараша кодду кайра жазгансыз - анда анын эски PHP (5.5) менен өндүрүштө пайда болушу, албетте, кимдир бирөөнү таң калтырат. Котормочунун версиясындагы чоң өзгөрүүнү унута албайсыз, бирок "шайтан майда-чүйдөсүнө чейин": күтүлбөгөн нерсе кандайдыр бир көз карандылыктын кичине жаңырылышында болушу мүмкүн.
Бул көйгөйдү чечүүнүн ыкмасы катары белгилүү IaC (Инфраструктура код катары, "инфраструктура код катары") жана колдонмо коду менен бирге инфраструктура талаптарын сактоону камтыйт. Аны колдонуу менен, иштеп чыгуучулар жана DevOps адистери бир эле Git тиркеме репозиторийинде иштей алышат, бирок анын ар кандай бөлүктөрүндө. Бул коддон Gitте Docker сүрөтү түзүлөт, анда тиркеме инфраструктуранын бардык өзгөчөлүктөрүн эске алуу менен жайгаштырылат. Жөнөкөй сөз менен айтканда, сүрөттөрдү чогултуу үчүн скрипттер (эрежелер) баштапкы код менен бир репозиторийде болушу керек жана биригиши керек.
Көп катмарлуу колдонмо архитектурасында - мисалы, Docker контейнеринин ичинде иштеп жаткан тиркеменин алдында турган nginx бар - Докер сүрөттөрү ар бир катмар үчүн Git кодунан түзүлүшү керек. Андан кийин биринчи сүрөт котормочу жана башка "жакын" көз карандылыктары бар тиркемени камтыйт, ал эми экинчи сүрөттө nginxтин өйдө агымы камтылат.
Докер сүрөттөрү, Git менен байланыш
Биз Gitтен чогултулган бардык Docker сүрөттөрүн эки категорияга бөлөбүз: убактылуу жана чыгаруу. Убактылуу сүрөттөр Гиттеги филиалдын аты менен тегтелген, кийинки милдеттенменин үстүнөн жазылышы мүмкүн жана алдын ала көрүү үчүн гана чыгарылат (өндүрүш үчүн эмес). Бул алардын релиздерден негизги айырмасы: аларда кайсы конкреттүү милдеттенме бар экенин эч качан биле албайсыз.
Убактылуу сүрөттөрдү чогултуунун мааниси бар: мастер бутак (сиз автоматтык түрдө мастердин учурдагы версиясын көрүү үчүн өзүнчө сайтка чыга аласыз), релиздери бар бутактар, конкреттүү инновациялардын бутактары.
Убактылуу сүрөттөрдү алдын ала көрүү өндүрүшкө которуу зарылдыгы келип чыккандан кийин, иштеп чыгуучулар белгилүү бир тег коюшат. Тег боюнча автоматтык түрдө чогултулат сүрөттү чыгаруу (анын теги Gitтеги тегге туура келет) жана сахнага чыгарылат. Ал сапат бөлүмү тарабынан ийгиликтүү текшерилсе, ал өндүрүшкө кетет.
dapper
Сүрөттөлгөн нерселердин бардыгы (программа, сүрөт чогултуу, кийинки тейлөө) Bash скрипттерин жана башка "импровизацияланган" куралдарды колдонуу менен өз алдынча ишке ашырылышы мүмкүн. Бирок, эгерде сиз муну кылсаңыз, анда кандайдыр бир учурда ишке ашыруу чоң татаалдыкка жана начар контролдукка алып келет. Муну түшүнүп, биз CI/CD түзүү үчүн өзүбүздүн атайын Workflow утилитабызды түзүүгө келдик - dapper.
Анын баштапкы коду Ruby тилинде жазылган, ачык булак жана жарыяланган . Тилекке каршы, документация учурда куралдын эң алсыз жери болуп саналат, бирок биз анын үстүндө иштеп жатабыз. Ал эми биз дап бир нече жолу жазып, айтып беребиз, анткени... Биз чын жүрөктөн анын мүмкүнчүлүктөрүн бүт кызыкдар коомчулук менен бөлүшүүнү күтө албайбыз, бирок ошол эле учурда өзүңүздүн маселелериңизди жөнөтүңүз жана суроо-талаптарыңызды жөнөтүңүз жана/же GitHub боюнча долбоордун өнүгүшүнө көз салыңыз.
Жаңыланган 13-август, 2019-жыл: учурда долбоор dapper деп өзгөртүлгөн , анын коду Go-до толугу менен кайра жазылган жана анын документтери кыйла жакшыртылган.
Kubernetes
Дагы бир даяр Open Source куралы, ал буга чейин кесиптик чөйрөдө олуттуу таанылган Kubernetes, Докер башкаруу кластери. Докерде курулган долбоорлорду иштетүүдө аны колдонуу темасы отчеттун алкагына кирбейт, ошондуктан презентация кээ бир кызыктуу өзгөчөлүктөргө сереп салуу менен чектелет.
Ишке чыгаруу үчүн, Kubernetes сунуш кылат:
- даярдыгын текшерүү — тиркеменин жаңы версиясынын даярдыгын текшерүү (ага трафикти которуу үчүн);
- прокатка жаңыртуу - контейнерлердин кластериндеги сүрөттөрдү ырааттуу жаңыртуу (өчүрүү, жаңыртуу, ишке киргизүүгө даярдоо, трафикти алмаштыруу);
- синхрондук жаңыртуу - кластердеги сүрөттү башка ыкма менен жаңылоо: адегенде контейнерлердин жарымында, андан кийин калганында;
- canary релиздери - аномалияларды көзөмөлдөө үчүн чектелген (аз) сандагы контейнерлерде жаңы сүрөттү ишке киргизүү.
Үзгүлтүксүз жеткирүү жаңы версиянын чыгарылышы гана болбогондуктан, Kubernetes инфраструктураны кийинки тейлөө үчүн бир катар мүмкүнчүлүктөргө ээ: бардык контейнерлер үчүн орнотулган мониторинг жана журналдарды каттоо, автоматтык масштабдоо ж. процесстериңизде ишке ашыруу.
Акыркы сунуштар
- Docker колдонуңуз.
- Бардык муктаждыктарыңыз үчүн колдонмолордун Docker сүрөттөрүн түзүңүз.
- “Инфраструктура – бул код” принцибин карманыңыз.
- Gitти Docker менен байланыштырыңыз.
- Тартуу тартибин жөнгө салыңыз.
- Даяр платформаны колдонуңуз (Кубернетес же башка).
Видеолор жана слайддар
Спектаклден видео (бир саатка жакын) (отчеттун өзү 5-мүнөттөн башталат - ушул учурдан баштап ойноо үчүн шилтемени басыңыз).
Докладдын презентациясы:
PS
Биздин блогдогу тема боюнча башка баяндамалар:
- «» (Дмитрий Столяров; 27-жылдын 2019-майында DevOpsConfде);
- «» (Дмитрий Столяров; 8-жылдын 2018-ноябрында HighLoad++ боюнча);
- «» (Дмитрий Столяров; 7-жылдын 2017-ноябрында HighLoad++ боюнча);
- «» (Дмитрий Столяров; 6-жылдын 2017-июнунда RootConf сайтында).
Source: www.habr.com