Баарына салам! Менин атым Павел Агалетский. Мен Lamoda жеткирүү системасын иштеп чыгуучу топтун жетекчиси болуп иштейм. 2018-жылы мен HighLoad++ конференциясында сөз сүйлөдүм, бүгүн мен өзүмдүн баяндамамдын стенограммасын сунуштагым келет.

Менин темам ар кандай чөйрөлөргө системаларды жана кызматтарды жайылтуу боюнча биздин компаниянын тажрыйбасына арналган. Биздин тарыхка чейинки доорлордон баштап, биз бардык системаларды кадимки виртуалдык серверлерге жайгаштырганыбыздан баштап, акырындык менен Nomadдан Кубернетестеги жайылтууга өтүү менен аяктаган. Мен муну эмне үчүн жасаганыбызды жана бул процессте кандай көйгөйлөр бар экенин айтып берем.

Колдонмолорду VMге жайылтуу

3 жыл мурун компаниянын бардык тутумдары жана кызматтары кадимки виртуалдык серверлерге орнотулганынан баштайлы. Техникалык жактан алганда, биздин системалар үчүн бардык коддор Женкиндерди колдонуу менен автоматтык чогултуу куралдары менен сакталган жана чогултулгандай уюштурулган. Ansible колдонуп, ал биздин версияны башкаруу тутумубуздан виртуалдык серверлерге чыгарылды. Мындан тышкары, биздин компанияда болгон ар бир система жок дегенде 2 серверге орнотулган: алардын бири башында, экинчиси куйрукта. Бул эки система бардык орнотуулары, күчү, конфигурациясы ж.б.у.с. боюнча бири-бирине таптакыр окшош болгон. Алардын ортосундагы бир гана айырмасы, баш колдонуучу трафигин алган, ал эми куйрук эч качан колдонуучу трафигин алган эмес.

Бул эмне үчүн жасалган?

Колдонмобуздун жаңы релиздерин жайгаштырганыбызда, биз үзгүлтүксүз жайылтууну, башкача айтканда, колдонуучулар үчүн байкаларлык кесепеттерди камсыз кылууну кааладык. Бул Ansible аркылуу кийинки компиляцияланган релиздин акырына чейин чыгарылышынын аркасында жетишилди. Ал жерде жайылтууга катышкан адамдар баары жакшы экенин текшерип, текшере алышат: бардык метрикалар, бөлүмдөр жана тиркемелер иштеп жатат; зарыл сценарийлер ишке киргизилди. Баары жайында экенине ынангандан кийин гана жол кыймылы алмаштырылды. Бул мурун куйрук болгон серверге бара баштады. Ал эми буга чейин баш болуп, колдонуучунун трафиги жок калган, ошол эле учурда биздин тиркеменин мурунку версиясы бар.

Ошентип, ал колдонуучулар үчүн кемчиликсиз болду. Анткени которуштуруу көз ирмемде болот, анткени ал жөн эле балансизаторду алмаштырат. Жөн гана балансташтыргычты кайра алмаштыруу менен мурунку версияга оңой кайтсаңыз болот. Биз ошондой эле колдонмо колдонуучу трафигин алганга чейин эле өндүрүшкө жөндөмдүү экенин текшере алганбыз, бул абдан ыңгайлуу болгон.

Мунун бардыгынан кандай артыкчылыктарды көрдүк?

1. Биринчиден, бул жетиштүү ал жөн гана иштейт. Мындай жайгаштыруу схемасы кандайча иштээрин ар бир адам түшүнөт, анткени көпчүлүк адамдар кадимки виртуалдык серверлерге жайгаштырышкан.
2. Бул жетиштүү ишенимдүү, жайылтуу технологиясы жөнөкөй болгондуктан, миңдеген компаниялар тарабынан сыналган. Миллиондогон серверлер ушундай жол менен жайгаштырылат. Бир нерсени бузуу кыйын.
3. Анан акыры биз ала алдык атомдук жайгаштыруу. Эски версия менен жаңы версиянын ортосунда өтүүнүн байкаларлык баскычы жок, колдонуучулар үчүн бир эле учурда пайда болгон жайылтуулар.

Бирок биз мунун баарында бир нече кемчиликтерди да көрдүк:

1. Өндүрүштүк чөйрөдөн, өнүгүү чөйрөсүнөн тышкары, башка чөйрөлөр бар. Мисалы, qa жана preproduction. Ал кезде бизде көптөгөн серверлер жана 60ка жакын сервистер бар болчу. Ушул себептен улам зарыл болгон ар бир кызмат үчүн, анын акыркы нускасын сактап виртуалдык машина. Андан тышкары, эгер сиз китепканаларды жаңырткыңыз келсе же жаңы көз карандылыкты орноткуңуз келсе, муну бардык чөйрөдө жасашыңыз керек. Сиз ошондой эле колдонмоңуздун кийинки жаңы версиясын орното турган убакытты devops керектүү чөйрө жөндөөлөрүн аткарган убакыт менен синхрондоштурууңуз керек болчу. Бул учурда, биздин чөйрө бир эле учурда бардык чөйрөдө бир аз башкача боло турган кырдаалга кирүү оңой. Мисалы, QA чөйрөсүндө китепканалардын кээ бир версиялары болот, ал эми өндүрүш чөйрөсүндө ар кандай болот, бул көйгөйлөргө алып келет.
2. Көз карандылыкты жаңыртуу кыйынчылыгы арызыңыз. Бул сизден эмес, башка командадан көз каранды. Тактап айтканда, серверлерди тейлеген devops командасынан. Сиз аларга тиешелүү тапшырманы жана эмне кылгыңыз келгенин сүрөттөшүңүз керек.
3. Ошол кезде биз дагы колубуздагы чоң чоң монолиттерди өзүнчө майда кызматтарга бөлгүбүз келген, анткени алар көбөйө турганын түшүнгөнбүз. Ал убакта бизде алардын 100дөн ашууну бар болчу.Ар бир жаңы кызмат үчүн өзүнчө жаңы виртуалдык машинаны түзүү керек болчу, аны да кармап туруу жана жайылтуу керек болчу. Мындан тышкары, бир эмес, эки машина керек. Мунун баарына QA чөйрөсү кошулду. Бул көйгөйлөрдү жаратат жана жаңы системаларды курууну жана иштетүүнү кыйындатат. татаал, кымбат жана узак процесс.

Ошондуктан, биз кадимки виртуалдык машиналарды жайгаштыруудан биздин тиркемелерди докер контейнеринде жайгаштырууга өтүү ыңгайлуу болот деп чечтик. Эгер сизде докер бар болсо, анда сизге контейнерди жөн эле көтөрө албагандыктан, колдонмону кластерде иштете турган система керек. Адатта, сиз канча контейнер көтөрүлгөнүнө көз салгыңыз келет, алар автоматтык түрдө көтөрүлөт. Ушул себептен улам биз башкаруу системасын тандап алышыбыз керек болчу.

Кайсынысын алсак экен деп көпкө ойлондук. Чындыгында, ошол кезде кадимки виртуалдык серверлерде бул жайгаштыруу стек бир аз эскирген, анткени аларда операциялык системалардын акыркы версиялары жок болчу. Кайсы бир убакта, атүгүл FreeBSD да бар болчу, ал колдоо үчүн анчалык деле ыңгайлуу эмес. Биз мүмкүн болушунча тезирээк докерге көчүшүбүз керек экенин түшүндүк. Биздин девоптор ар кандай чечимдер менен болгон тажрыйбасын карап чыгышты жана Nomad сыяктуу системаны тандап алышты.

Nomad'ка өтүү

Nomad - HashiCorp компаниясынын продуктусу. Алар ошондой эле башка чечимдери менен белгилүү:

"Консул" кызмат табуу үчүн курал болуп саналат.

"Терраформа" - серверлерди башкаруу тутуму, аларды конфигурациялоо аркылуу конфигурациялоого мүмкүндүк берет, инфраструктура-код деп аталган.

"Бомж" конкреттүү конфигурация файлдары аркылуу виртуалдык машиналарды жергиликтүү же булутта жайгаштырууга мүмкүндүк берет.

Ошол убакта Nomad бүт инфраструктураны өзгөртпөстөн тез эле өтүүгө боло турган жөнөкөй чечим сыяктуу көрүнгөн. Мындан тышкары, аны үйрөнүү абдан жеңил. Ошондуктан биз аны контейнерибиз үчүн фильтрациялоо системасы катары тандап алдык.

Сиздин системаңызды Nomad'га жайылтуу үчүн сизге эмне керек?

1. Биринчи кезекте сизге керек докер сүрөтү арызыңыз. Сиз аны куруп, докер сүрөт репозиторийине жайгаштырышыңыз керек. Биздин учурда, бул артефактура - ар кандай типтеги ар кандай артефакттарды ага түртүүгө мүмкүндүк берген система. Ал архивдерди, докер сүрөттөрүн, композитордун PHP пакеттерин, NPM пакеттерин жана башкаларды сактай алат.
2. Ошондой эле керек тарам билэ, бул Nomadге эмнени, кайда жана кандай көлөмдө жайгаштыргыңыз келгенин айтып берет.

Биз Nomad жөнүндө сөз кылганда, ал HCL тилин өзүнүн маалымат файл форматы катары колдонот HashiCorp конфигурация тили. Бул сиздин кызматыңызды Nomad терминдеринде сүрөттөп берүүгө мүмкүндүк берген Yaml супер топтому.

Бул сизге канча контейнерди жайгаштыргыңыз келгенин, аларды жайгаштыруу учурунда кайсы сүрөттөрдөн ар кандай параметрлерди өткөрүүгө мүмкүнчүлүк берет. Ошентип, сиз бул файлды Nomadга бересиз жана ал контейнерлерди ага ылайык өндүрүшкө киргизет.

Биздин учурда, биз ар бир кызмат үчүн таптакыр окшош HCL файлдарын жазуу абдан ыңгайлуу эмес экенин түшүндүк, анткени кызматтар көп жана кээде сиз аларды жаңырткыңыз келет. Бир кызмат бир инстанцияда эмес, ар түрдүү кызматтарда орнотулат. Мисалы, бизде өндүрүштө болгон системалардын биринде өндүрүштө 100дөн ашык нуска бар. Алар бир эле сүрөттөрдөн иштейт, бирок конфигурация орнотуулары жана конфигурация файлдары боюнча айырмаланат.

Ошондуктан, биз жайылтуу үчүн бардык конфигурация файлдарын бир жалпы репозиторийде сактоо бизге ыңгайлуу болот деп чечтик. Ушундай жол менен алар көрүндү: аларды тейлөө оңой жана бизде кандай системалар бар экенин көрө алдык. Зарыл болсо, бир нерсени жаңыртуу же өзгөртүү оңой. Жаңы системаны кошуу да кыйын эмес – жөн гана жаңы каталогдун ичинде конфигурация файлын түзүшүңүз керек. Анын ичинде төмөнкү файлдар бар: биздин кызматтын сүрөттөлүшүн камтыган service.hcl жана өндүрүштө жайылтылган ушул кызматты конфигурациялоого мүмкүндүк берген кээ бир env файлдары.

Бирок, биздин кээ бир системалар өндүрүшкө бир нускада эмес, бир эле учурда бир нече нускада жайгаштырылган. Ошондуктан, биз конфигурацияларды таза түрүндө эмес, калыптуу түрдө сактоо бизге ыңгайлуу болот деп чечтик. А биз тандадык жинжа 2. Бул форматта биз кызматтын конфигурацияларын да, ага керектүү env файлдарын да сактайбыз.

Мындан тышкары, биз репозиторийге бардык долбоорлор үчүн жалпы жайылтуу сценарийин жайгаштырдык, ал сизге кызматыңызды өндүрүшкө, керектүү чөйрөгө, керектүү максатка киргизүүгө жана жайылтууга мүмкүндүк берет. HCL конфигурациясын шаблонго айландырган учурда, мурда кадимки Nomad конфигурациясы болгон HCL файлы бул учурда бир аз башкача көрүнө баштады.

Башкача айтканда, биз конфигурациялоонун айрым өзгөрмөлөрүн env файлдарынан же башка булактардан алынган кыстарылган өзгөрмөлөр менен алмаштырдык. Мындан тышкары, биз динамикалык HCL файлдарын чогултуу мүмкүнчүлүгүнө ээ болдук, башкача айтканда, биз жөнөкөй өзгөрмө киргизүүлөрдү гана эмес, колдоно алабыз. Джиндя циклдерди жана шарттарды колдогондуктан, сиз ошол жерде конфигурация файлдарын түзө аласыз, алар тиркемелериңизди так кайда жайгаштырганыңызга жараша өзгөрөт.

Мисалы, сиз кызматыңызды өндүрүшкө жана өндүрүшкө жайылткыңыз келет. Алдын ала өндүрүштө сиз cron скрипттерин иштеткиңиз келбейт, бирок анын иштеп жатканын текшерүү үчүн кызматты өзүнчө доменде көргүңүз келет дейли. Кызматты жайылткандар үчүн процесс абдан жөнөкөй жана ачык көрүнөт. Болгону deploy.sh файлын аткарып, кайсы кызматты жайылткыңыз келгенин жана кайсы максатты көздөй турганын көрсөтүңүз. Мисалы, сиз Россияга, Белоруссияга же Казакстанга белгилүү бир системаны жайгаштыргыңыз келет. Бул үчүн, жөн гана параметрлердин бирин өзгөртүңүз, ошондо сизде туура конфигурация файлы болот.

Nomad кызматы сиздин кластериңизге мурунтан эле орнотулганда, мындай көрүнөт.

Биринчиден, сизге бардык колдонуучу трафигин ала турган сыртта кандайдыр бир баланстоочу керек. Ал Консул менен биргелешип иштеп, андан кайсыл жерде, кайсы түйүндө, кайсы IP даректе белгилүү бир домендик атка дал келген конкреттүү кызмат жайгашканын аныктайт. Консулдагы кызматтарды Nomad өзүнөн алат. Бул бир эле компаниянын продуктылары болгондуктан, алар бири-бири менен абдан байланыштуу. Nomad кутудан чыгып, андагы ачылган бардык кызматтарды Консулдун ичинде каттай алат деп айта алабыз.

Сиздин алдыңкы жүк баланстоочуңуз трафикти кайсы кызматка жөнөтүү керектигин билгенден кийин, аны тиешелүү контейнерге же колдонмоңузга дал келген бир нече контейнерге багыттайт. Албетте, коопсуздук жөнүндө да ойлонуу керек. Бардык кызматтар контейнерлерде бир эле виртуалдык машиналарда иштегенине карабастан, бул, адатта, кандайдыр бир кызматтан башкасына эркин кирүүнү алдын алууну талап кылат. Биз буга сегменттөө аркылуу жетиштик. Ар бир кызмат өзүнүн виртуалдык тармагында ишке киргизилген, анда башка системаларга жана кызматтарга кирүүгө уруксат берүү/баш тартуу эрежелери жана маршруттоо эрежелери белгиленген. Алар бул кластердин ичинде да, анын сыртында да жайгашышы мүмкүн. Мисалы, эгер сиз кызматтын белгилүү бир маалымат базасына туташуусунун алдын алгыңыз келсе, бул тармак деңгээлиндеги сегментация аркылуу жасалышы мүмкүн. Башкача айтканда, ката болсо да, сиз кокусунан сыноо чөйрөсүнөн өндүрүш маалымат базасына туташа албайсыз.

Өткөөл мезгил бизге адам ресурстары жагынан канча чыгым болду?

Бүтүндөй компаниянын Nomadка өтүшү болжол менен 5-6 айга созулду. Биз тейлөө боюнча көчүп, бирок бир кыйла тез темп менен. Ар бир команда кызматтар үчүн өз контейнерлерин түзүшү керек болчу.

Биз ар бир команда өз системаларынын докер сүрөттөрү үчүн өз алдынча жооп бере тургандай мамилени кабыл алдык. Devops жайылтуу үчүн зарыл болгон жалпы инфраструктураны камсыз кылат, башкача айтканда, кластердин өзүн колдоо, CI системасын колдоо жана башкалар. Ал эми ошол кезде бизде Nomadга 60тан ашык система көчүрүлгөн, бул 2 миңдей контейнерди түзгөн.

Devops жайылтууга жана серверлерге тиешелүү бардык нерселердин жалпы инфраструктурасы үчүн жооптуу. Жана ар бир иштеп чыгуу командасы, өз кезегинде, анын белгилүү бир тутумуна контейнерлерди ишке ашыруу үчүн жооптуу, анткени ал жалпысынан белгилүү бир контейнерде эмнеге муктаж экенин билген команда.

Nomadтан баш тартуунун себептери

Башкалардын арасында Nomad жана докерди колдонуу менен жайылтууга өтүү менен кандай артыкчылыктарга ээ болдук?

1. биз бирдей шарттарды камсыз кылган бардык чөйрөлөр үчүн. Иштеп чыгууда, QA чөйрөсүндө, өндүрүшкө чейинки, өндүрүштө, ошол эле көз карандылыктар менен бирдей контейнер сүрөттөрү колдонулат. Демек, сизде өндүрүштө бүтө турган нерсе мурда жергиликтүү же сыноо чөйрөңүздө сынап көргөн нерсе эмес экенине дээрлик эч кандай мүмкүнчүлүгүңүз жок.
2. Биз дагы жетишээрлик деп таптык жаңы кызматты кошуу оңой. Жайгаштыруу көз карашынан алганда, ар кандай жаңы системалар өтө жөнөкөй ишке киргизилет. Жөн гана конфигурацияларды сактаган репозиторийге барыңыз, ал жерде тутумуңуз үчүн башка конфигурацияны кошуңуз, ошондо баары даяр. Сиз devops тарабынан эч кандай кошумча аракетсиз эле системаңызды өндүрүшкө орното аласыз.
3. бардык конфигурация файлдары бир жалпы репозиторийде кароодо болуп чыкты. Виртуалдык серверлерди колдонуу менен системаларыбызды орноткон учурда биз конфигурациялары бир репозиторийде турган Ansible колдондук. Бирок, көпчүлүк иштеп чыгуучулар үчүн бул менен иштөө бир аз кыйыныраак болду. Бул жерде кызматты жайылтуу үчүн кошуу керек болгон конфигурациялардын жана коддун көлөмү бир топ азайып калды. Мындан тышкары, аны оңдоо же өзгөртүү devops үчүн абдан оңой. Мисалы, Nomadтын жаңы версиясына өтүү учурунда, алар бир жерде жайгашкан бардык операциялык файлдарды алып, жапырт жаңырта алышат.

Бирок биз бир нече кемчиликтерге да туш болдук:

Көрсө, биз үзгүлтүксүз жайылтууга жетише алган жок Nomad учурда. Контейнерлерди ар кандай шарттарда жайып жатканда, ал иштеп жаткан болуп чыгышы мүмкүн жана Nomad аны трафикти кабыл алууга даяр контейнер катары кабыл алды. Бул анын ичиндеги тиркеме ишке киргизүү мүмкүнчүлүгүнө ээ боло электе болгон. Ушул себептен улам, система кыска убакыттын ичинде 500 ката чыгара баштады, анткени трафик аны кабыл алууга даяр эмес контейнерге бара баштады.

Кээ бирлерине жолуктук саздар тарабынан. Эң маанилүү мүчүлүштүк, эгер сизде көптөгөн системалар жана контейнерлер болсо, Nomad чоң кластерди жакшы иштете албайт. Сиз Nomad кластерине киргизилген серверлердин бирин тейлөө үчүн алып салгыңыз келгенде, кластер өзүн жакшы сезбей, ыдырап кетүү ыктымалдыгы жогору. Кээ бир контейнерлер, мисалы, түшүп, көтөрүлбөй калышы мүмкүн - эгерде сиздин бардык өндүрүштүк системаларыңыз Nomad тарабынан башкарылган кластерде жайгашса, бул сизге кийинчерээк кымбатка турат.

Ошентип, биз мындан ары кайда барышыбыз керектигин ойлонууну чечтик. Ошол учурда биз эмнеге жетүүнү каалап жатканыбызды көбүрөөк түшүнүп калдык. Тактап айтканда: биз ишенимдүүлүктү, Nomad камсыз кылгандан бир аз көбүрөөк функцияларды жана жетилген, туруктуураак системаны каалайбыз.

Бул жагынан алганда, биздин тандоо кластерлерди ишке киргизүү үчүн эң популярдуу платформа катары Кубернетеске түштү. Айрыкча биздин контейнерлердин көлөмү жана саны жетиштүү чоң болгонун эске алсак. Мындай максаттар үчүн Kubernetes биз карай турган эң ылайыктуу система болуп көрүндү.

Kubernetesке өтүү

Мен сизге Кубернетестин негизги түшүнүктөрү жана алардын Nomadдан кандайча айырмаланары жөнүндө бир аз айтып берем.

Биринчиден, Кубернетестеги эң негизги түшүнүк - бул pod концепциясы. Гадылбек ар дайым чогуу иштеген бир же бир нече контейнерлердин тобу. Жана алар дайыма бир виртуалдык машинада иштегендей иштешет. Алар ар кандай порттордо IP 127.0.0.1 аркылуу бири-бирине жеткиликтүү.

Сизде nginx жана php-fpm - классикалык схемадан турган PHP тиркемеңиз бар деп коёлу. Кыязы, сиз nginx жана php-fpm контейнерлерин ар дайым чогуу кармап тургуңуз келет. Kubernetes сизге аларды бир жалпы подъезд катары сүрөттөп, буга жетүүгө мүмкүндүк берет. Дал ушуну биз Nomad менен ала алган жокпуз.

Экинчи түшүнүк жайылтуу. Чындыгында, кабык өзү убактылуу нерсе, ал башталат жана жок болот. Адегенде бардык мурунку контейнерлериңизди өлтүрүп, анан жаңы версияларды бир заматта ишке киргизгиңиз келеби же аларды акырындык менен чыгаргыңыз келеби? Бул жайылтуу концепциясы жооптуу болгон процесс. Ал сиз өзүңүздүн капчыктарыңызды кантип жайгаштыраарыңыз, канча көлөмдө жана аларды кантип жаңыртуу керек экенин сүрөттөйт.

Үчүнчү түшүнүк кызмат. Сиздин кызмат чындыгында сиздин тутумуңуз болуп саналат, ал бир аз трафикти кабыл алып, андан кийин аны кызматыңызга ылайыктуу бир же бир нече подрядга жөнөтөт. Башкача айтканда, бул тигил же бул кызматка келген бардык трафикти тигил же бул ат менен ушул конкреттүү подкасттарга жөнөтүү керек деп айтууга мүмкүндүк берет. Жана ошол эле учурда ал сизге трафиктин тең салмактуулугун камсыз кылат. Башкача айтканда, сиз өзүңүздүн тиркемеңиздин эки капчыгын ишке киргизе аласыз жана бардык келген трафик ушул кызматка тиешелүү подколор ортосунда бирдей тең салмакта болот.

Ал эми төртүнчү негизги түшүнүк өтүшү. Бул Kubernetes кластеринде иштеген кызмат. Ал бардык суроо-талаптарды кабыл алган тышкы жүк балансынын ролун аткарат. Kubernetes API колдонуп, Ingress бул сурамдар кайда жөнөтүлүшү керек экенин аныктай алат. Анын үстүнө, ал муну абдан ийкемдүү кылат. Сиз бул хостко бардык суроо-талаптар ушул кызматка жөнөтүлөт деп айта аласыз. Жана бул хостко жана башка URL дарегине келген бул сурамдар башка кызматка жөнөтүлөт.

Тиркемени иштеп чыккан адамдын көз карашы боюнча эң сонун нерсе, мунун баарын өзүңүз башкара аласыз. Ingress конфигурациясын орнотуу менен, сиз мындай жана мындай APIге келген бардык трафикти, мисалы, Go ичинде жазылган өзүнчө контейнерлерге жөнөтө аласыз. Бирок бул трафик, ошол эле доменге келип, бирок башка URL дарегине келип, PHPде жазылган контейнерлерге жөнөтүлүшү керек, ал жерде логика көп, бирок алар өтө тез эмес.

Бул түшүнүктөрдүн баарын Көчмөн менен салыштырсак, биринчи үч түшүнүк бардыгы чогуу Кызмат деп айта алабыз. Ал эми акыркы түшүнүк Көчмөндүн өзүндө жок. Биз тышкы баланстоочуну колдондук: ал haproxy, nginx, nginx+ жана башкалар болушу мүмкүн. Куб үчүн бул кошумча түшүнүктү өзүнчө киргизүүнүн кереги жок. Бирок, эгер сиз Ingressди ички жактан карасаңыз, ал nginx, haproxy же траефик, бирок Кубернетеске орнотулган.

Мен сүрөттөгөн бардык түшүнүктөр, чынында, Kubernetes кластеринде бар ресурстар. Аларды куб менен сыпаттоо үчүн, Nomad файлындагы HCL файлдарына караганда окула турган жана тааныш болгон yaml форматы колдонулат. Бирок структуралык жактан алар бир эле нерсени сүрөттөйт, мисалы, pod. Алар мындай дешет: - Мен ал жерде баланча, баланча сүрөт менен, баланча көлөмдө жайгаштыргым келет.

Мындан тышкары, биз ар бир жеке ресурсту кол менен түзүүнү каалабаганыбызды түшүндүк: жайгаштыруу, кызматтар, кириш ж.б. Анын ордуна, биз бардык керектүү ресурстук көз карандылыктарды туура тартипте кол менен кайра жаратып албашыбыз үчүн, жайылтуу учурунда ар бир тутумубузду Кубернетес жагынан сүрөттөгүбүз келди. Бизге муну жасоого мүмкүндүк берген система катары Helm тандалган.

Helmдеги негизги түшүнүктөр

Руль пакет менеджери Kubernetes үчүн. Бул программалоо тилдериндеги пакет менеджерлеринин иштешине абдан окшош. Алар сизге, мисалы, жайгаштыруу nginx, жайылтуу php-fpm, Ingress үчүн конфигурация, конфигматика (бул сиздин тутумуңуз үчүн env жана башка параметрлерди коюуга мүмкүндүк берүүчү объект) турган кызматты сактоого мүмкүндүк берет. диаграммалар деп аталат. Ошол эле учурда Helm Кубернетестин үстүндө жүрөт. Башкача айтканда, бул четте турган кандайдыр бир система эмес, кубдун ичинде ишке киргизилген дагы бир кызмат. Сиз аны менен анын API аркылуу консолдук команда аркылуу өз ара аракеттенесиз. Анын ынгайлуулугу жана кооздугу – руль сынып калса же аны кластерден алып салсаңыз да, сиздин кызматтарыңыз жоголбойт, анткени руль негизинен системаны ишке киргизүү үчүн гана кызмат кылат. Андан кийин Kubernetes өзү кызматтардын иштеши жана абалы үчүн жооп берет.

Муну биз да түшүндүк шаблондооКонфигурацияларыбызга жиндяны киргизүү менен биз өзүбүз жасоого мажбур болгонбуз, бул рулдун негизги өзгөчөлүктөрүнүн бири. Системаларыңыз үчүн түзгөн бардык конфигурациялар штурвалда калыптар түрүндө сакталат, жинджага бир аз окшош, бирок, чындыгында, Kubernetes сыяктуу рул жазылган Go тилинин шаблондорун колдонуу менен.

Helm биз үчүн дагы бир нече түшүнүктөрдү кошот.

Чарт - бул сиздин кызматыңыздын сүрөттөлүшү. Башка пакет менеджерлеринде ал пакет, таңгак же ушул сыяктуу бир нерсе деп аталат. Бул жерде ал диаграмма деп аталат.

баалары конфигурацияларыңызды калыптардан куруу үчүн колдонгуңуз келген өзгөрмөлөр.

чыгаруу. Ар бир жолу рулдун жардамы менен орнотулган кызмат релиздин кошумча версиясын алат. Helm мурунку релиздеги кызмат конфигурациясы кандай болгонун, ага чейинки релизди жана башкаларды эстейт. Ошондуктан, артка кайтуу керек болсо, жөн гана мурунку релиз версиясына көрсөтүп, рулга кайра чалуу буйругун иштетиңиз. Сиздин репозиторийиңиздеги тиешелүү конфигурация артка кайтаруу учурунда жок болсо дагы, руль анын эмне болгонун эстеп калат жана тутумуңузду мурунку релиздеги абалына кайтарат.

Биз рулду колдонгон учурда, Kubernetes үчүн кадимки конфигурациялар да өзгөрмөлөрдү, функцияларды колдонууга жана шарттуу билдирүүлөрдү колдонууга мүмкүн болгон калыптарга айланат. Ушундай жол менен сиз чөйрөгө жараша кызмат конфигурацияңызды чогулта аласыз.

Иш жүзүндө биз Nomad менен болгонго караганда бир аз башкачараак кылып көрүүнү чечтик. Эгерде Nomadде биздин кызматты жайылтуу үчүн зарыл болгон жайгаштыруу конфигурациялары жана n-өзгөрмөлөр бир репозиторийде сакталса, бул жерде биз аларды эки өзүнчө репозиторийге бөлүүнү чечтик. "Орнотуу" репозиторийинде жайылтуу үчүн зарыл болгон n өзгөрмөлөрү гана сакталат, ал эми "рулду" репозиторийде конфигурациялар же диаграммалар сакталат.

Бул бизге эмне берди?

Биз конфигурация файлдарында чындап эле купуя маалыматтарды сактабаганыбызга карабастан. Мисалы, маалымат базаларына сырсөздөр. Алар Kubernetes сыр катары сакталат, бирок, ошентсе да, ал жерде дагы эле кээ бир нерселер бар, биз баарына жеткиликтүүлүктү каалабайбыз. Ошондуктан, "жайгаштыруу" репозиторийине кирүү чектелген, ал эми "рулду" репозиторий жөн гана кызматтын сүрөттөмөсүн камтыйт. Ушул себептен улам, ага адамдардын кеңири чөйрөсү коопсуз кире алат.

Бизде өндүрүш гана эмес, башка чөйрөлөр да бар болгондуктан, бул бөлүнүүнүн аркасында биз кызматтарды өндүрүшкө гана эмес, ошондой эле, мисалы, QA чөйрөсүнө жайылтуу үчүн руль диаграммаларыбызды кайра колдоно алабыз. Ал тургай, аларды колдонуу менен жергиликтүү жайгаштыруу үчүн Minikube - бул Kubernetes'ти жергиликтүү иштетүү үчүн бир нерсе.

Ар бир репозиторийдин ичинде биз ар бир кызмат үчүн өзүнчө каталогдорго бөлүм калтырдык. Башкача айтканда, ар бир каталогдун ичинде тиешелүү диаграммага тиешелүү калыптар бар жана биздин системаны ишке киргизүү үчүн колдонулушу керек болгон ресурстарды сүрөттөгөн. Биз "жайгаштыруу" репозиторийинде энвдерди гана калтырдык. Бул учурда, биз жиндяны колдонуу менен шаблонду колдонгон жокпуз, анткени helm өзү кутудан сыртка калыптандырууну камсыз кылат - бул анын негизги функцияларынын бири.

Биз жайылтуу скриптин калтырдык - deploy.sh, ал рулдун жардамы менен жайылтуу үчүн ишке киргизүүнү жөнөкөйлөштүрөт жана стандартташтырат. Ошентип, жайылтууну каалагандар үчүн жайылтуу интерфейси Nomad аркылуу жайылтуудагыдай эле көрүнөт. Ошол эле deploy.sh, кызматыңыздын аталышы жана аны кайда жайгаштыргыңыз келгени. Бул рулдун ички ишке киришине себеп болот. Ал, өз кезегинде, шаблондордон конфигурацияларды чогултат, аларга керектүү баалуулуктар файлдарын киргизет, андан кийин аларды Kubernetesке ишке киргизет.

табылгалары

Kubernetes кызматы Nomadга караганда татаалыраак окшойт.

Бул жерде чыгуучу трафик Ингресске келет. Бул жөн гана алдыңкы контроллер, ал бардык суроо-талаптарды кабыл алат жана андан кийин аларды суроо-талаптын маалыматтарына ылайыктуу кызматтарга жөнөтөт. Ал аларды рульдеги колдонмоңуздун сыпаттамасынын бир бөлүгү болгон жана иштеп чыгуучулар өздөрү орноткон конфигурациялардын негизинде аныктайт. Кызмат суроо-талаптарды өзүнүн поддонуна, башкача айтканда, конкреттүү контейнерлерге жөнөтөт, бул кызматка тиешелүү болгон бардык контейнерлердин ортосундагы келген трафикти тең салмактайт. Анан, албетте, биз тармак деңгээлинде коопсуздуктан эч жакка барбашыбыз керек экенин унутпашыбыз керек. Демек, сегменттөө тегге негизделген Kubernetes кластеринде иштейт. Бардык кызматтарда белгилүү бир тегдер бар, аларга кызматтардын кластердин ичиндеги же сыртындагы белгилүү тышкы/ички ресурстарга кирүү укуктары байланышкан.

Өткөөл мезгилде биз Kubernetesте биз мурда колдонгон Nomadдын бардык мүмкүнчүлүктөрү бар экенин, ошондой эле көптөгөн жаңы нерселерди кошконун көрдүк. Аны плагиндер аркылуу жана чындыгында колдонуучу ресурстун түрлөрү аркылуу кеңейтүүгө болот. Башкача айтканда, сизде Kubernetes менен келген нерсени жөн гана колдонуу эмес, сиздин ресурсуңузду окуй турган өз ресурсуңузду жана кызматыңызды түзүү мүмкүнчүлүгүңүз бар. Бул сизге Kubernetesти кайра орнотпостон жана өзгөртүүлөрдү талап кылбастан тутумуңузду кеңейтүү үчүн кошумча мүмкүнчүлүктөрдү берет.

Мындай колдонуунун мисалы - Prometheus, ал биздин Kubernetes кластерибиздин ичинде иштейт. Ал белгилүү бир кызматтын көрсөткүчтөрүн чогулта башташы үчүн, кызматтын сүрөттөмөсүнө ресурстун кошумча түрүн, кызматтын монитору деп аталганын кошуубуз керек. Prometheus, Kubernetesте ишке киргизилгенде ыңгайлаштырылган ресурс түрүн окуй алгандыктан, жаңы системадан метрикаларды автоматтык түрдө чогулта баштайт. Бул абдан ыңгайлуу.

Кубернетеске биринчи жайгаштыруу 2018-жылдын март айында болгон. Жана бул убакыттын ичинде биз аны менен эч кандай кыйынчылыктарды башынан өткөргөн жокпуз. Ал олуттуу мүчүлүштүктөрсүз туруктуу иштейт. Мындан тышкары, биз аны дагы кеңейте алабыз. Бүгүн бизде анын мүмкүнчүлүктөрү жетиштүү жана бизге Кубернетестин өнүгүү темпи абдан жагат. Учурда Кубернетесте 3000ден ашык контейнер бар. Кластер бир нече түйүндөрдү ээлейт. Ошол эле учурда, ал тейлөөгө жөндөмдүү, туруктуу жана абдан көзөмөлдөнөт.

Source: www.habr.com