Здраво свима! Моје име је Павел Агалетски. Радим као вођа тима у тиму који развија Ламода систем испоруке. 2018. године сам говорио на конференцији ХигхЛоад++, а данас бих желео да представим транскрипт свог извештаја.

Моја тема је посвећена искуству наше компаније у примени система и услуга у различитим окружењима. Почевши од наших праисторијских времена, када смо све системе постављали у обичне виртуелне сервере, завршавајући постепеним преласком са Номада на примену у Кубернетес. Рећи ћу вам зашто смо то урадили и какве смо проблеме имали у том процесу.

Примена апликација на ВМ

Почнимо са чињеницом да су пре 3 године сви системи и услуге компаније били распоређени на обичне виртуелне сервере. Технички, то је било организовано тако да је сав код за наше системе био ускладиштен и састављен коришћењем аутоматских алата за склапање, користећи јенкинс. Користећи Ансибле, уведен је из нашег система контроле верзија на виртуелне сервере. Штавише, сваки систем који је наша компанија имала био је распоређен на најмање 2 сервера: један на глави, други на репу. Ова два система су била апсолутно идентична један другом по свим својим подешавањима, снази, конфигурацији итд. Једина разлика између њих била је у томе што је глава примала кориснички саобраћај, док реп никада није примао кориснички саобраћај.

за шта је то било?

Када смо имплементирали нова издања наше апликације, желели смо да обезбедимо неометано увођење, односно без приметних последица за кориснике. Ово је постигнуто захваљујући чињеници да је следеће компајлирано издање које користи Ансибле избачено до краја. Тамо су људи који су били укључени у имплементацију могли да провере и да се увере да је све у реду: све метрике, секције и апликације раде; покренуте су потребне скрипте. Тек пошто су се уверили да је све у реду, саобраћај је пребачен. Почео је да иде на сервер који је претходно био реп. А онај који је раније био глава остао је без корисничког саобраћаја, а на њему је и даље била претходна верзија наше апликације.

Тако да је било неприметно за кориснике. Зато што је пребацивање тренутно, пошто је једноставно пребацивање балансера. Можете врло лако да се вратите на претходну верзију једноставним пребацивањем балансера назад. Такође смо могли да проверимо да ли је апликација способна за производњу чак и пре него што је примила кориснички саобраћај, што је било прилично згодно.

Које смо предности у свему томе видели?

1. Пре свега, довољно је само ради. Сви разумеју како функционише таква шема постављања, јер се већина људи икада поставила на обичне виртуелне сервере.
2. Ово је довољно поуздано, пошто је технологија примене једноставна, тестирана од стране хиљада компанија. Милиони сервера су распоређени на овај начин. Тешко је нешто сломити.
3. И коначно смо могли да добијемо атомска распоређивања. Примене које се дешавају истовремено за кориснике, без приметне фазе пребацивања између старе верзије и нове.

Али у свему томе смо видели и неколико недостатака:

1. Поред производног окружења, развојног окружења, постоје и друга окружења. На пример, ка и предпродукција. У то време имали смо много сервера и око 60 сервиса. Из тог разлога је било неопходно за сваку услугу одржавајте најновију верзију за њу Виртуелна машина. Штавише, ако желите да ажурирате библиотеке или инсталирате нове зависности, то морате да урадите у свим окружењима. Такође сте морали да синхронизујете време када ћете применити следећу нову верзију ваше апликације са временом када девопс изврши неопходна подешавања окружења. У овом случају, лако је доћи у ситуацију да ће наше окружење бити нешто другачије у свим срединама одједном. На пример, у КА окружењу ће постојати неке верзије библиотека, ау производном окружењу ће постојати различите, што ће довести до проблема.
2. Потешкоће при ажурирању зависности Ваша Пријава. То не зависи од вас, већ од другог тима. Наиме, од девопс тима који одржава сервере. Морате им дати одговарајући задатак и опис онога што желите да урадите.
3. Тада смо хтели и да поделимо велике велике монолите које смо имали у засебне мале службе, пошто смо схватали да ће их бити све више. Тада смо их већ имали више од 100. За сваку нову услугу било је потребно направити посебну нову виртуелну машину, коју је такође требало одржавати и имплементирати. Осим тога, не треба вам један аутомобил, већ најмање два. Уз све ово је и КА окружење. Ово узрокује проблеме и отежава вам да изградите и покренете нове системе. сложен, скуп и дуготрајан процес.

Због тога смо одлучили да би било згодније да пређемо са постављања обичних виртуелних машина на примену наших апликација у доцкер контејнеру. Ако имате доцкер, потребан вам је систем који може покренути апликацију у кластеру, пошто не можете само да подигнете контејнер. Обично желите да пратите колико је контејнера подигнуто тако да се аутоматски подижу. Из тог разлога, морали смо да изаберемо контролни систем.

Дуго смо размишљали који бисмо могли да узмемо. Чињеница је да је у то време овај стек за примену на обичним виртуелним серверима био донекле застарео, јер нису имали најновије верзије оперативних система. У неком тренутку је постојао чак и ФрееБСД, који није био баш згодан за подршку. Схватили смо да морамо да пређемо на Доцкер што је пре могуће. Наши девопси су погледали своје постојеће искуство са различитим решењима и изабрали систем као што је Номад.

Пребаците се на Номад

Номад је производ компаније ХасхиЦорп. Познати су и по својим другим решењима:

"конзул" је алат за откривање услуга.

"Тераформ" - систем за управљање серверима који вам омогућава да их конфигуришете кроз конфигурацију, такозвани инфраструктура-као-код.

"скитница" омогућава вам да примените виртуелне машине локално или у облаку преко одређених конфигурационих датотека.

Номад је у то време изгледао као прилично једноставно решење на које се може брзо пребацити без промене целокупне инфраструктуре. Поред тога, прилично је лако научити. Зато смо га изабрали као систем филтрације за наш контејнер.

Шта вам је потребно да поставите свој систем на Номад?

1. Пре свега вам треба доцкер имаге Ваша Пријава. Морате да га направите и поставите у спремиште доцкер слика. У нашем случају, ово је артефактура - систем који вам омогућава да у њега гурнете разне артефакте различитих врста. Може да складишти архиве, доцкер слике, ПХП пакете композитора, НПМ пакете и тако даље.
2. Такође потребно конфигурациони фајл, који ће рећи Номаду шта, где и у којој количини желите да распоредите.

Када говоримо о Номаду, он користи језик ХЦЛ као формат датотеке информација, што је скраћеница за ХасхиЦорп конфигурациони језик. Ово је суперскуп Иамл-а који вам омогућава да опишете своју услугу номадским терминима.

Омогућава вам да кажете колико контејнера желите да примените, из којих слика да им пренесете различите параметре током примене. Дакле, овај фајл дајете Номаду, а он у складу са њим покреће контејнере у производњу.

У нашем случају смо схватили да једноставно писање апсолутно идентичних ХЦЛ датотека за сваку услугу не би било баш згодно, јер постоји много услуга и понекад желите да их ажурирате. Дешава се да се једна услуга не примењује у једној инстанци, већ у низу различитих. На пример, један од система које имамо у производњи има више од 100 инстанци у производњи. Покрећу се од истих слика, али се разликују по конфигурационим поставкама и конфигурационим датотекама.

Због тога смо одлучили да би нам било згодно да све наше конфигурационе датотеке за примену чувамо у једном заједничком спремишту. На овај начин су били видљиви: били су лаки за одржавање и могли смо да видимо које системе имамо. Ако је потребно, такође је лако нешто ажурирати или променити. Додавање новог система такође није тешко - само треба да креирате конфигурациону датотеку унутар новог директоријума. Унутар њега се налазе следеће датотеке: сервице.хцл, који садржи опис нашег сервиса, и неке енв фајлове који омогућавају да се конфигурише управо овај сервис, који се примењује у производњи.

Међутим, неки од наших система су распоређени у производњи не у једној копији, већ у неколико одједном. Због тога смо одлучили да би нам било згодно да складиштимо не конфигурације у њиховом чистом облику, већ њихов шаблонски облик. И ми смо изабрали џиња 2. У овом формату чувамо и конфигурације самог сервиса и енв датотеке потребне за њега.

Поред тога, у спремиште смо поставили скрипту за имплементацију заједничку за све пројекте, која вам омогућава да покренете и примените своју услугу у продукцији, у жељено окружење, у жељени циљ. У случају када смо нашу ХЦЛ конфигурацију претворили у шаблон, онда је ХЦЛ датотека, која је раније била обична Номад конфигурација, у овом случају почела да изгледа мало другачије.

То јест, заменили смо неке променљиве локације конфигурације са уметнутим варијаблама које су преузете из енв датотека или других извора. Поред тога, добили смо прилику да динамички прикупљамо ХЦЛ фајлове, односно можемо користити не само обичне променљиве уметања. Пошто јиња подржава петље и услове, тамо такође можете креирати конфигурационе датотеке, које се мењају у зависности од тога где тачно постављате своје апликације.

На пример, желите да примените своју услугу у претпродукцији и производњи. Рецимо да у предпродукцији не желите да покрећете црон скрипте, већ само желите да видите услугу на посебном домену да бисте били сигурни да функционише. За свакога ко примењује услугу, процес изгледа веома једноставан и транспарентан. Све што треба да урадите је да покренете датотеку деплои.сх, наведете који сервис желите да примените и на који циљ. На пример, желите да поставите одређени систем у Русију, Белорусију или Казахстан. Да бисте то урадили, једноставно промените један од параметара и имаћете исправну конфигурациону датотеку.

Када је услуга Номад већ распоређена на ваш кластер, изгледа овако.

Прво, потребна вам је нека врста балансера споља, који ће примати сав кориснички саобраћај. Радиће заједно са Конзулом и из њега сазнати где, на ком чвору, на којој ИП адреси се налази одређена услуга која одговара одређеном имену домена. Услуге у Конзулу долазе од самог Номада. Пошто се ради о производима исте компаније, они су прилично повезани једни са другима. Можемо рећи да Номад ван кутије може да региструје све сервисе покренуте у њему унутар Цонсул-а.

Када ваш фронт-енд балансатор оптерећења зна на коју услугу да пошаље саобраћај, он га прослеђује у одговарајући контејнер или више контејнера који одговарају вашој апликацији. Наравно, потребно је размишљати и о сигурности. Иако све услуге раде на истим виртуелним машинама у контејнерима, то обично захтева спречавање слободног приступа било којој услузи било којој другој. То смо постигли сегментацијом. Сваки сервис је покренут у сопственој виртуелној мрежи, на којој су прописана правила рутирања и правила за дозвољавање/одбијање приступа другим системима и сервисима. Могу се налазити и унутар овог кластера и изван њега. На пример, ако желите да спречите да се услуга повеже са одређеном базом података, то се може урадити сегментацијом на нивоу мреже. То јест, чак ни грешком, не можете случајно да се повежете из тестног окружења на вашу производну базу података.

Колико нас је кадровски коштала транзиција?

Прелазак целе компаније на Номад трајао је отприлике 5-6 месеци. Кретали смо се од услуге до услуге, али прилично брзим темпом. Сваки тим је морао да направи сопствене контејнере за услуге.

Усвојили смо такав приступ да је сваки тим независно одговоран за доцкер слике својих система. ДевОпс обезбеђује општу инфраструктуру неопходну за примену, односно подршку за сам кластер, подршку за ЦИ систем и тако даље. И тада смо имали више од 60 система премештених у Номад, што је износило око 2 хиљаде контејнера.

Девопс је одговоран за општу инфраструктуру свега што се односи на имплементацију и сервере. А сваки развојни тим је, заузврат, одговоран за имплементацију контејнера за свој специфични систем, пошто је тим тај који зна шта му је генерално потребно у одређеном контејнеру.

Разлози за напуштање Номада

Које смо предности добили преласком на примену користећи Номад и Доцкер, између осталог?

1. Ми обезбедили једнаке услове за све средине. У развоју, КА окружењу, предпродукцији, производњи, користе се исте слике контејнера, са истим зависностима. Сходно томе, практично немате никакве шансе да оно што ће завршити у производњи није оно што сте претходно тестирали локално или у свом тестном окружењу.
2. Такође смо установили да је то довољно лако додати нову услугу. Са тачке гледишта примене, сваки нови систем се покреће веома једноставно. Само идите у спремиште које чува конфигурације, додајте још једну конфигурацију за ваш систем тамо и све је спремно. Можете да примените свој систем у производњу без икаквих додатних напора од стране девопс-а.
3. Све конфигурационих датотека у једном заједничком спремишту испоставило се да је на прегледу. У време када смо постављали наше системе користећи виртуелне сервере, користили смо Ансибле, у коме су конфигурације биле у истом спремишту. Међутим, за већину програмера ово је било мало теже радити. Овде је обим конфигурација и кода који морате да додате да бисте применили услугу постао много мањи. Поред тога, девопс-у је веома лако да га поправи или промени. У случају преласка, на пример, на нову верзију Номада, они могу узети и масовно ажурирати све оперативне датотеке које се налазе на истом месту.

Али такође смо наишли на неколико недостатака:

Испоставило се да смо није могао постићи беспрекорну примену у случају Номада. Приликом постављања контејнера под различитим условима, могло би се испоставити да ради, а Номад га је доживљавао као контејнер спреман да прими саобраћај. Ово се догодило пре него што је апликација унутар њега уопште имала прилику да се покрене. Из тог разлога, систем је за кратко време почео да производи 500 грешака, јер је саобраћај почео да иде ка контејнеру који још није био спреман да га прихвати.

Наишли смо на неке по мочварама. Најзначајнија грешка је та што Номад не рукује добро великим кластером ако имате много система и контејнера. Када желите да уклоните један од сервера који је укључен у Номад кластер ради одржавања, постоји прилично велика вероватноћа да се кластер неће осећати добро и да ће се распасти. Неки контејнери могу, на пример, да падну и да се не подигну – то ће вас касније много коштати ако се сви ваши производни системи налазе у кластеру којим управља Номад.

Зато смо одлучили да размислимо о томе где да идемо даље. У том тренутку смо постали много свеснији шта желимо да постигнемо. Наиме: желимо поузданост, мало више функција него што нуди Номад и зрелији, стабилнији систем.

С тим у вези, наш избор је пао на Кубернетес као најпопуларнију платформу за покретање кластера. Поготово с обзиром да је величина и број наших контејнера био довољно велики. За такве сврхе, чинило се да је Кубернетес најпогоднији систем који можемо погледати.

Прелазак на Кубернетес

Рећи ћу вам мало о основним концептима Кубернетеса и по чему се разликују од Номада.

Пре свега, најосновнији концепт у Кубернетесу је концепт под. Махуна је група од једног или више контејнера који увек раде заједно. И увек раде као стриктно на једној виртуелној машини. Они су доступни једни другима преко ИП 127.0.0.1 на различитим портовима.

Претпоставимо да имате ПХП апликацију која се састоји од нгинк и пхп-фпм - класична шема. Највероватније ћете желети да нгинк и пхп-фпм контејнере увек држите заједно. Кубернетес вам омогућава да то постигнете тако што ћете их описати као један заједнички под. То је управо оно што нисмо могли да добијемо са Номадом.

Други концепт је развој. Чињеница је да је сама махуна ефемерна ствар, она почиње и нестаје. Да ли желите прво да поништите све своје претходне контејнере, а затим да покренете нове верзије одједном, или желите да их постепено уводите? Ово је процес за који је одговоран концепт примене. Описује како постављате своје подове, у којој количини и како да их ажурирате.

Трећи концепт је сервис. Ваша услуга је заправо ваш систем, који прима део саобраћаја, а затим га прослеђује једном или више модула који одговарају вашој услузи. Односно, омогућава вам да кажете да сав долазни саобраћај ка тој и тој услузи са таквим и таквим именом мора бити послат на ове специфичне подове. И истовремено вам омогућава балансирање саобраћаја. То јест, можете покренути два под-а своје апликације, а сав долазни саобраћај ће бити равномерно избалансиран између под-ова који се односе на ову услугу.

И четврти основни концепт је Улаз. Ово је услуга која ради на Кубернетес кластеру. Делује као спољни балансатор оптерећења који преузима све захтеве. Користећи Кубернетес АПИ, Ингресс може да одреди где ови захтеви треба да буду послати. Штавише, он то ради веома флексибилно. Можете рећи да се сви захтеви овом хосту и таквим и таквим УРЛ-овима шаљу овој услузи. И ови захтеви који долазе на овај хост и на другу УРЛ адресу се шаљу на другу услугу.

Најхладнија ствар са становишта некога ко развија апликацију је то што можете сами да управљате свиме. Подешавањем конфигурације Ингресс, можете послати сав саобраћај који долази до тог и таквог АПИ-ја у засебне контејнере написане, на пример, у Го. Али овај саобраћај, који долази на исти домен, али на другу УРЛ адресу, треба послати у контејнере написане у ПХП-у, где има пуно логике, али нису баш брзи.

Ако упоредимо све ове концепте са Номадом, можемо рећи да су прва три концепта сви заједно Служба. А последњи концепт је одсутан у самом Номаду. Користили смо спољни балансер као такав: то може бити хапроки, нгинк, нгинк+, итд. У случају коцке, не морате посебно уводити овај додатни концепт. Међутим, ако погледате Ингресс интерно, он је или нгинк, хапроки или траефик, али је на неки начин уграђен у Кубернетес.

Сви концепти које сам описао су, у ствари, ресурси који постоје унутар Кубернетес кластера. За њихово описивање у коцки користи се иамл формат, који је читљивији и познатији од ХЦЛ датотека у случају Номада. Али структурно описују исту ствар у случају, на пример, под. Кажу – хоћу да тамо распоредим такве и такве махуне, са таквим и таквим сликама, у таквим и таквим количинама.

Поред тога, схватили смо да не желимо да креирамо сваки појединачни ресурс ручно: имплементацију, услуге, Ингресс, итд. Уместо тога, желели смо да опишемо сваки наш систем у смислу Кубернетеса током примене, тако да не бисмо морали ручно да поново креирамо све неопходне зависности од ресурса у правом редоследу. Хелм је изабран као систем који нам је то омогућио.

Основни појмови у Хелму

Хелм је менаџер пакета за Кубернетес. Веома је слично томе како функционишу менаџери пакета у програмским језицима. Они вам омогућавају да складиштите услугу која се састоји од, на пример, деплоимент нгинк, деплоимент пхп-фпм, цонфиг фор Ингресс, цонфигмапс (ово је ентитет који вам омогућава да поставите енв и друге параметре за ваш систем) у облику тзв. звани графикони. Истовремено Хелм ради на врху Кубернетеса. Односно, ово није нека врста система који стоји по страни, већ само још један сервис покренут унутар коцке. Са њим комуницирате преко његовог АПИ-ја преко команде на конзоли. Његова погодност и лепота је у томе што чак и ако се кормило поквари или га уклоните из кластера, ваше услуге неће нестати, пошто кормило у суштини служи само за покретање система. Сам Кубернетес је тада одговоран за перформансе и стање услуга.

То смо и ми схватили шаблонизација, на шта смо претходно били приморани да урадимо сами увођењем јиња у наше конфигурације, једна је од главних карактеристика кормила. Све конфигурације које креирате за своје системе се чувају у Хелм-у у облику шаблона, мало сличних јиња-у, али, у ствари, користећи шаблоне Го језика, у којем је написан хелм, попут Кубернетеса.

Хелм нам додаје још неколико концепата.

Графикон - ово је опис ваше услуге. У другим менаџерима пакета то би се звало пакет, пакет или нешто слично. Овде се то зове графикон.

Вредности су променљиве које желите да користите да направите своје конфигурације из шаблона.

Отпустите. Сваки пут када се услуга која се примењује помоћу хелм-а прима инкременталну верзију издања. Хелм се сећа каква је била конфигурација услуге током претходног издања, издања пре тога, итд. Стога, ако требате да вратите назад, само покрените команду повратног позива хелм, указујући је на претходну верзију издања. Чак и ако одговарајућа конфигурација у вашем спремишту није доступна у време враћања, хелм ће и даље запамтити шта је то био и вратиће ваш систем на стање у којем је био у претходном издању.

У случају када користимо хелм, обичне конфигурације за Кубернетес такође се претварају у шаблоне у којима је могуће користити променљиве, функције и применити условне исказе. На овај начин можете прикупити конфигурацију своје услуге у зависности од окружења.

У пракси смо одлучили да радимо ствари мало другачије него што смо радили са Номадом. Ако су у Номаду и конфигурације за примену и н-варијабле које су биле потребне за примену нашег сервиса биле ускладиштене у једном спремишту, овде смо одлучили да их поделимо у два одвојена спремишта. Репозиторијум „деплои” чува само н-варијабле потребних за примену, а „хелм” спремиште чува конфигурације или графиконе.

Шта нам је ово дало?

Упркос чињеници да не складиштимо никакве заиста осетљиве податке у самим конфигурационим датотекама. На пример, лозинке за базе података. Оне се чувају као тајне у Кубернетес-у, али ипак, тамо још увек постоје одређене ствари којима не желимо да свима дамо приступ. Стога је приступ „деплои“ спремишту ограниченији, а „хелм“ спремиште једноставно садржи опис услуге. Из тог разлога, може му безбедно приступити шири круг људи.

Пошто имамо не само производну, већ и друга окружења, захваљујући овом раздвајању можемо поново да користимо наше кормиларне карте за имплементацију услуга не само у производњу, већ и, на пример, у окружење обезбеђења квалитета. Чак и да их примените локално користећи Миникубе - ово је ствар за локално покретање Кубернетеса.

Унутар сваког спремишта оставили смо поделу на засебне директоријуме за сваку услугу. Односно, унутар сваког директоријума постоје шаблони који се односе на одговарајући графикон и који описују ресурсе који треба да буду распоређени да би се покренуо наш систем. Оставили смо само енв-ове у "деплои" спремишту. У овом случају, нисмо користили шаблонирање користећи јиња, јер сам хелм обезбеђује шаблонирање из кутије - ово је једна од његових главних функција.

Оставили смо скрипту за примену - деплои.сх, која поједностављује и стандардизује покретање за примену помоћу кормила. Дакле, за свакога ко жели да се примени, интерфејс за примену изгледа потпуно исто као и када се примењује преко Номада. Исти деплои.сх, назив вашег сервиса и где желите да га примените. Ово доводи до унутрашњег покретања кормила. Он, заузврат, прикупља конфигурације из шаблона, убацује потребне датотеке са вредностима у њих, затим их поставља, покрећући их у Кубернетес.

Налази

Чини се да је Кубернетес услуга сложенија од Номада.

Овде одлазни саобраћај долази у Ингресс. Ово је само предњи контролер, који преузима све захтеве и потом их шаље сервисима који одговарају подацима захтева. Одређује их на основу конфигурација које су део описа ваше апликације у кормилу и које су програмери сами поставили. Сервис шаље захтеве својим подовима, односно одређеним контејнерима, балансирајући долазни саобраћај између свих контејнера који припадају овој услузи. И, наравно, не треба заборавити да нигде не треба да идемо од безбедности на нивоу мреже. Стога сегментација функционише у Кубернетес кластеру, који се заснива на означавању. Све услуге имају одређене ознаке на које су повезана права приступа услуга одређеним екстерним/интерним ресурсима унутар или изван кластера.

Док смо вршили транзицију, видели смо да Кубернетес има све могућности Номада, које смо претходно користили, а такође смо додали много нових ствари. Може се проширити преко додатака, а заправо кроз прилагођене типове ресурса. То јест, имате прилику не само да користите нешто што долази са Кубернетес-ом из кутије, већ да креирате сопствени ресурс и сервис који ће читати ваш ресурс. Ово вам даје додатне опције да проширите свој систем без потребе да поново инсталирате Кубернетес и без потребе за модификацијама.

Пример такве употребе је Прометхеус, који ради унутар нашег Кубернетес кластера. Да би он почео да прикупља метрику од одређене услуге, потребно је да у опис услуге додамо додатни тип ресурса, такозвани сервисни монитор. Прометхеус, због чињенице да може да чита прилагођени тип ресурса када се покрене у Кубернетесу, аутоматски почиње да прикупља метрике из новог система. Прилично је згодно.

Прво постављање на Кубернетес било је у марту 2018. И за то време никада нисмо имали никаквих проблема са тим. Ради прилично стабилно без значајних грешака. Поред тога, можемо га даље проширити. Данас имамо довољно могућности које има, и веома нам се свиђа темпо развоја Кубернетеса. Тренутно се у Кубернетесу налази више од 3000 контејнера. Кластер заузима неколико чворова. Истовремено је услужан, стабилан и веома управљив.

Извор: ввв.хабр.цом