Здравейте всички! Казвам се Павел Агалецки. Работя като ръководител на екип, който разработва системата за доставка Lamoda. През 2018 г. говорих на конференцията HighLoad ++ и днес искам да представя препис на моя доклад.

Моята тема е посветена на опита на нашата компания в внедряването на системи и услуги в различни среди. Започвайки от нашите праисторически времена, когато внедрихме всички системи в обикновени виртуални сървъри, завършвайки с постепенен преход от внедряване на Nomad към Kubernetes. Ще ви кажа защо го направихме и какви проблеми имахме в процеса.

Разположете приложения във VM

Да започнем с факта, че преди 3 години всички системи и услуги на компанията бяха разположени на обикновени виртуални сървъри. Технически беше организиран по такъв начин, че целият код на нашите системи да лежи и да се сглобява с помощта на инструменти за автоматично сглобяване, използвайки jenkins. С помощта на Ansible той вече беше разгърнат от нашата система за контрол на версиите към виртуални сървъри. В същото време всяка система, която беше в нашата компания, беше разположена на поне 2 сървъра: един от тях - на главата, вторият - на опашката. Тези две системи бяха абсолютно идентични една с друга във всичките си настройки, мощност, конфигурация и т.н. Единствената разлика между тях е, че главата получава потребителски трафик, докато опашката никога не получава потребителски трафик за себе си.

Защо беше направено това?

Когато внедрихме нови версии на нашето приложение, искахме да осигурим възможност за безпроблемно внедряване, тоест без забележими последствия за потребителите. Това беше постигнато благодарение на факта, че следващото компилирано издание, използващо Ansible, беше пуснато до края. Там хората, участвали в внедряването, можеха да проверят и да се уверят, че всичко е наред: всички показатели, секции и приложения работят; необходимите скриптове се стартират. Едва след като се убедиха, че всичко е наред, движението се превключи. Той започна да ходи на сървъра, който беше опашка преди. И този, който преди това беше главата, остана без потребителски трафик, докато с предишната версия на нашето приложение беше налична на него.

Така че беше безпроблемно за потребителите. Тъй като превключването е мигновено, тъй като това е просто превключване на балансьор. Много е лесно да се върнете към предишната версия, като просто превключите обратно балансира. Можехме също да се уверим, че приложението е готово за производство дори преди потребителският трафик да отиде към него, което беше доста удобно.

Какви добродетели виждаме във всичко това?

1. Първо, това е достатъчно просто работи. Всеки разбира как работи такава схема за разполагане, защото повечето хора някога са разполагали на обикновени виртуални сървъри.
2. Това е достатъчно надеждно, тъй като технологията за внедряване е проста, тествана от хиляди компании. Милиони сървъри се разполагат по този начин. Трудно е да счупиш нещо.
3. И най-накрая можехме да получим атомни разполагания. Внедрявания, които се случват едновременно за потребителите, без забележим етап на превключване между старата версия и новата.

Но във всичко това видяхме и няколко недостатъка:

1. В допълнение към производствената среда, средата за разработка, има и други среди. Например, qa и предпроизводство. По това време имахме много сървъри и около 60 услуги. Поради тази причина трябваше за всяка услуга поддържайте най-новата версия за нея виртуална машина. Освен това, ако искате да актуализирате библиотеки или да инсталирате нови зависимости, трябва да направите това във всички среди. Също така беше необходимо да синхронизирате времето, когато ще внедрите следващата нова версия на вашето приложение с времето, когато devops изпълнява необходимите настройки на средата. В този случай е лесно да попаднем в ситуация, в която нашата среда ще бъде малко по-различна наведнъж във всички среди подред. Например в QA среда ще има едни версии на библиотеки, а в производствена – други, което ще доведе до проблеми.
2. Трудност при актуализиране на зависимости Вашето приложение. Не зависи от теб, а от другия отбор. А именно от екипа на devops, който поддържа сървърите. Трябва да им дадете подходяща задача и да опишете какво искате да направите.
3. По това време също искахме да разделим големите големи монолити, които имахме, на отделни малки услуги, тъй като разбрахме, че ще има все повече и повече от тях. По това време вече имахме повече от 100. За всяка нова услуга беше необходимо да се създаде отделна нова виртуална машина, която също трябваше да бъде обслужвана и внедрявана. Освен това ви трябва не една кола, а поне две. Към всичко това се добавя QA среда. Това създава проблеми и затруднява изграждането и стартирането на нови системи. сложен, скъп и продължителен процес.

Затова решихме, че би било по-удобно да преминем от внедряване на обикновени виртуални машини към разполагане на нашите приложения в докер контейнер. Ако имате докер, имате нужда от система, която може да изпълнява приложението в клъстер, тъй като не можете просто да повдигнете контейнер просто така. Обикновено искате да следите колко контейнера са повдигнати, така че да се повдигат автоматично. Поради тази причина трябваше да изберем система за управление.

Дълго мислихме кой да вземем. Факт е, че по това време този стек за разполагане на обикновени виртуални сървъри беше малко остарял, тъй като нямаше най-новите версии на операционните системи. В един момент дори имаше FreeBSD, което не беше много удобно за поддръжка. Разбрахме, че трябва да мигрираме към docker възможно най-скоро. Нашите devops разгледаха техния опит с различни решения и избраха система като Nomad.

Преминаване към Nomad

Nomad е продукт на HashiCorp. Те са известни и с другите си решения:

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

"Тераформ" - система за управление на сървъри, която ви позволява да ги конфигурирате чрез конфигурация, така наречената инфраструктура като код.

"скитник" ви позволява да разгръщате виртуални машини локално или в облака чрез специфични конфигурационни файлове.

По това време Nomad изглеждаше като доста просто решение, към което може бързо да се премине, без да се променя цялата инфраструктура. В допълнение, той е доста лесен за научаване. Ето защо го избрахме като филтрираща система за нашия контейнер.

Какво ви е необходимо, за да внедрите вашата система в Nomad?

1. На първо място, трябва докер изображение Вашето приложение. Трябва да го изградите и да го поставите в хранилището на докер изображения. В нашия случай това е артефакт - система, която ви позволява да пъхате в нея различни артефакти от различен тип. Може да съхранява архиви, докер изображения, PHP пакети за композиране, NPM пакети и т.н.
2. Също така е необходимо конфигурационен файл, който ще каже на Nomad какво, къде и в какво количество искате да разположите.

Когато говорим за Nomad, той използва езика HCL като информационен файлов формат, което означава Конфигурационен език на HashiCorp. Това е надмножество на Yaml, което ви позволява да опишете услугата си с термини на Nomad.

Тя ви позволява да кажете колко контейнера искате да разположите, от кои изображения да прехвърлите различни параметри към тях по време на разгръщането. Така че подавате този файл на Nomad и той стартира контейнери към продукцията според него.

В нашия случай разбрахме, че просто писането на абсолютно еднакви, идентични HCL файлове за всяка услуга няма да е много удобно, защото има много услуги и понякога искате да ги актуализирате. Случва се една услуга да бъде внедрена не в един екземпляр, а в множество различни. Например една от системите, които имаме в производство, има над 100 екземпляра в производство. Те работят от едни и същи изображения, но се различават по конфигурационните настройки и конфигурационните файлове.

Затова решихме, че ще бъде удобно за нас да съхраняваме всички наши конфигурационни файлове за внедряване в едно общо хранилище. По този начин те станаха видими: бяха лесни за поддръжка и можеше да се види какви системи имаме. Ако е необходимо, също така е лесно да актуализирате или промените нещо. Добавянето на нова система също не е трудно - просто добавете конфигурационен файл в новата директория. Вътре в него има файлове: service.hcl, който съдържа описание на нашата услуга и някои env файлове, които позволяват тази услуга, която е внедрена в производство, да бъде конфигурирана.

Някои от нашите системи обаче се внедряват в производство не в едно копие, а в няколко наведнъж. Затова решихме, че ще ни е удобно да съхраняваме не конфигурации в чистата им форма, а тяхната шаблонна форма. И като език за шаблони, който избрахме джинджа 2. В този формат съхраняваме както конфигурациите на самата услуга, така и необходимите за нея env файлове.

В допълнение, ние поставихме в хранилището скрипт за внедряване, който е общ за всички проекти, което ви позволява да стартирате и внедрите услугата си в производство, в правилната среда, в правилната цел. В случая, когато превърнахме нашата HCL конфигурация в шаблон, тогава HCL файлът, който преди това беше обичайната конфигурация на Nomad, в този случай започна да изглежда малко по-различно.

Тоест, заменихме някои променливи за местоположение на конфигурацията с вмъкнати променливи, които са взети от env файлове или други източници. Освен това получихме възможността да събираме HCL файлове динамично, тоест можем да използваме не само обикновени вмъквания на променливи. Тъй като jinja поддържа цикли и условия, можете също да създавате конфигурационни файлове там, които се променят в зависимост от това къде точно разгръщате вашите приложения.

Например искате да внедрите услугата си в предпроизводство и производство. Да кажем, че в предварителната продукция не искате да изпълнявате cron скриптове, а просто искате да видите услугата на отделен домейн, за да сте сигурни, че работи. За всеки, който внедрява услуга, процесът е много прост и прозрачен. Достатъчно е да изпълните файла deploy.sh, да посочите коя услуга искате да внедрите и към коя цел. Например искате да разположите някаква система в Русия, Беларус или Казахстан. За да направите това, просто променете един от параметрите и ще имате правилния конфигурационен файл.

Когато услугата Nomad вече е внедрена във вашия клъстер, тя изглежда така.

Като начало имате нужда от външен балансьор на натоварването, който ще поеме целия потребителски трафик в себе си. Той ще работи заедно с Consul и ще научава от него къде, на кой възел, на какъв IP адрес се намира дадена услуга, която отговаря на конкретно име на домейн. Услугите в Consul идват от самия Nomad. Тъй като това са продукти на една и съща компания, те са добре свързани. Можем да кажем, че извън кутията Nomad може да регистрира всички услуги, стартирани в него, в Consul.

След като вашият външен балансьор знае към коя услуга да изпрати трафик, той го пренасочва към подходящия контейнер или множество контейнери, които съответстват на вашето приложение. Естествено е необходимо да се мисли и за безопасността. Въпреки че всички услуги работят на едни и същи виртуални машини в контейнери, това обикновено изисква всяка услуга да бъде отказан свободен достъп до всяка друга. Постигнахме това чрез сегментиране. Всяка услуга беше стартирана в собствена виртуална мрежа, на която бяха написани правила за маршрутизиране и правила за разрешаване / отказ на достъп до други системи и услуги. Те могат да бъдат както вътре в този клъстер, така и извън него. Например, ако искате да попречите на дадена услуга да се свързва с определена база данни, това може да стане чрез сегментиране на ниво мрежа. Тоест, дори и по погрешка, не можете случайно да се свържете от тестовата среда към вашата производствена база.

Колко ни струва преходът като кадри?

Приблизително 5-6 месеца отне преходът на цялата компания към Nomad. Преместихме услуга по услуга, но с доста бързи темпове. Всеки отбор трябваше да създаде свои собствени сервизни контейнери.

Възприехме такъв подход, че всеки екип е отговорен за докер изображенията на своите системи независимо. Devops, от друга страна, осигурява общата инфраструктура, необходима за внедряване, тоест поддръжка за самия клъстер, поддръжка за CI системата и т.н. И по това време имахме повече от 60 системи, преместени в Nomad, което се оказа около 2 хиляди контейнера.

DevOps отговаря за цялостната инфраструктура на всичко, свързано с внедряването, със сървъри. И всеки екип за разработка, от своя страна, е отговорен за внедряването на контейнери за тяхната конкретна система, тъй като екипът знае от какво обикновено се нуждае в конкретен контейнер.

Причини за напускане на Nomad

Какви предимства получихме, като преминахме към внедряване, използвайки също Nomad и docker?

1. Ние осигурени равни условия за всички среди. При разработката, QA-средата, предпроизводството, производството се използват едни и същи изображения на контейнери, със същите зависимости. Съответно, нямате практически никакъв шанс нещо различно от това, което сте тествали преди това локално или в тестова среда, да се появи в производството.
2. Ние също установихме, че е достатъчно лесно добавяне на нова услуга. Всички нови системи по отношение на внедряването се стартират много лесно. Достатъчно е да отидете в хранилището, което съхранява конфигурациите, да добавите следващата конфигурация за вашата система там и сте готови. Можете да внедрите вашата система в производство без допълнителни усилия от devops.
3. всички конфигурационни файлове в едно общо хранилище се оказа в процес на проверка. В момента, в който разположихме системите си с помощта на виртуални сървъри, използвахме Ansible, в който конфигурациите бяха в същото хранилище. За повечето разработчици обаче това беше малко по-трудно за работа. Тук обемът от конфигурации и код, които трябва да добавите, за да внедрите услугата, е станал много по-малък. Освен това за devops е много лесно да го поправите или промените. В случай на преходи, например, към нова версия на Nomad, те могат да вземат и масово да актуализират всички операционни файлове, разположени на едно и също място.

Но също така срещнахме няколко недостатъка:

Оказа се, че ние не успя да постигне безпроблемно внедряване в случая с Nomad. При разгръщане на контейнери от различни условия може да се окаже, че се е оказало работещо и Nomad го е възприел като контейнер, готов да получи трафик. Това се случи дори преди приложението в него да има време да стартира. Поради тази причина системата започна да издава 500 грешки за кратко време, защото трафикът започна да отива към контейнера, който все още не беше готов да го приеме.

Срещали сме някои край блатата. Най-същественият бъг е, че Nomad не се справя много добре с голям клъстер, ако имате много системи и контейнери. Когато искате да извадите един от сървърите, който е включен в клъстера Nomad за поддръжка, има доста голяма вероятност клъстерът да не се чувства много добре и да се разпадне. Някои контейнери може например да паднат и да не се издигнат - това ще ви струва много по-късно, ако всичките ви производствени системи са разположени в клъстер, управляван от Nomad.

Затова решихме да помислим къде да отидем след това. По това време станахме много по-наясно какво искаме да постигнем. А именно: искаме надеждност, малко повече функции, отколкото предоставя Nomad, и по-зряла, по-стабилна система.

В тази връзка нашият избор падна върху Kubernetes като най-популярната платформа за стартиране на клъстери. Особено като се има предвид, че размерът и броят на нашите контейнери беше достатъчно голям. За такива цели Kubernetes изглеждаше най-подходящата система от тези, които можехме да разгледаме.

Преход към Kubernetes

Ще ви разкажа малко за основните концепции на Kubernetes и как се различават от Nomad.

На първо място, най-основната концепция в Kubernetes е концепцията за pod. Шушулка е група от един или повече контейнери, които винаги започват заедно. И те работят сякаш винаги строго на една и съща виртуална машина. Те са достъпни един за друг чрез IP адрес 127.0.0.1 на различни портове.

Да приемем, че имате PHP приложение, което се състои от nginx и php-fpm - класическият модел. Най-вероятно ще искате контейнерите nginx и php-fpm винаги да са заедно. Kubernetes ви позволява да постигнете това, като ги описвате като една обща капсула. Точно това не можахме да получим с Nomad.

Втората концепция е внедряване. Въпросът е, че самата капсула е ефимерно нещо, започва и изчезва. Независимо дали искате първо да унищожите всичките си предишни контейнери и след това веднага да стартирате нови версии, или искате да ги внедрите постепенно - това е точно концепцията за внедряване, която е отговорна за този процес. Той описва как разгръщате своите подове, колко и как да ги актуализирате.

Третата концепция е обслужване. Вашата услуга всъщност е вашата система, която приема малко трафик и след това го насочва към един или повече подове, съответстващи на вашата услуга. Тоест, позволява ви да кажете, че целият входящ трафик към такава и такава услуга с такова и такова име трябва да бъде изпратен до тези конкретни подове. И в същото време ви осигурява балансиране на трафика. Това означава, че можете да стартирате две групи от вашето приложение и целият входящ трафик ще бъде равномерно балансиран между групите, свързани с тази услуга.

И четвъртата основна концепция - Влизане. Това е услуга, която работи на клъстер Kubernetes. Той действа като външен балансьор на натоварването, който поема всички заявки. Използвайки Kubernetes API, Ingress може да определи къде трябва да бъдат изпратени тези заявки. Освен това той прави това много гъвкаво. Можете да кажете, че всички заявки към този хост и такъв и такъв URL се изпращат към тази услуга. И тези заявки, идващи до този хост и до друг URL, се изпращат до друга услуга.

Най-якото нещо от гледна точка на някой, който разработва приложение, е, че можете да управлявате всичко това сами. Като зададете конфигурацията на Ingress, можете да изпратите целия трафик, идващ към такъв и такъв API, към отделни контейнери, регистрирани, например, в Go. Но този трафик, който идва към същия домейн, но към различен URL, се изпраща към контейнери, написани на PHP, където има много логика, но не са много бързи.

Ако сравним всички тези концепции с Nomad, можем да кажем, че първите три концепции са заедно услуга. И последната концепция отсъства в самия Nomad. Като него използвахме външен балансьор: може да бъде haproxy, nginx, nginx+ и т.н. В случай на куб не е необходимо да въвеждате тази допълнителна концепция отделно. Въпреки това, ако погледнете Ingress вътрешно, той е или nginx, haproxy или traefik, но нещо като вграден в Kubernetes.

Всички концепции, които описах, всъщност са ресурси, които съществуват в клъстер на Kubernetes. За да ги опише в куба, се използва формат yaml, който е по-четлив и познат от HCL файловете в случая на Nomad. Но структурно те описват едно и също нещо в случая на подс. Те казват - искам да разположа там такива и такива капсули, с такива и такива изображения, в такива и такива количества.

Освен това разбрахме, че не искаме да създаваме ръчно всеки отделен ресурс: внедряване, услуги, Ingress и т.н. Вместо това искахме да опишем всяка наша система от гледна точка на Kubernetes по време на внедряването, така че да не се налага да пресъздаваме ръчно всички необходими зависимости на ресурсите в правилния ред. Helm беше избран като такава система, която ни позволи да направим това.

Основни понятия в Helm

Шлемът е мениджър на пакети за Kubernetes. Това е много подобно на това как работят мениджърите на пакети в езиците за програмиране. Те ви позволяват да съхранявате услуга, състояща се от, например, разгръщане на nginx, разгръщане на php-fpm, конфигурация за Ingress, configmaps (това е обект, който ви позволява да задавате env и други параметри за вашата система) под формата на така- наречени диаграми. В същото време Хелм работи върху Kubernetes. Тоест, това не е някаква система, която стои настрана, а просто друга услуга, работеща вътре в куба. Вие взаимодействате с него чрез неговия API чрез конзолна команда. Неговото удобство и чар е, че дори ако helm се счупи или го премахнете от клъстера, вашите услуги няма да изчезнат, тъй като helm по същество служи само за стартиране на системата. Самата Kubernetes носи допълнителна отговорност за здравето и състоянието на услугите.

Това също го разбрахме шаблониране, което преди това бяхме принудени да направим сами чрез въвеждане на jinja в нашите конфигурации, е една от основните характеристики на helm. Всички конфигурации, които създавате за вашите системи, се съхраняват в helm под формата на шаблони, малко подобни на jinja, но всъщност използвайки шаблоните на езика Go, на който е написан helm, като Kubernetes.

Helm ни добавя още няколко допълнителни концепции.

Графика е описание на вашата услуга. В други мениджъри на пакети ще се нарича пакет, пакет или нещо подобно. Тук се нарича диаграма.

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

Освободете. Всеки път, когато услуга, която се внедрява с helm, получава допълнителна версия на изданието. Helm помни каква беше конфигурацията на услугата за предишната версия, предходната година и т.н. Следователно, ако трябва да се върнете назад, просто изпълнете командата за обратно извикване на кормилото, като я насочите към предишната версия на изданието. Дори ако съответната конфигурация във вашето хранилище не е налична по време на връщането назад, helm пак ще запомни какво е било и ще върне вашата система до състоянието, в което е била в предишната версия.

В случай, че използваме helm, обичайните конфигурации за Kubernetes също се превръщат в шаблони, в които е възможно да се използват променливи, функции и да се прилагат условни изрази. По този начин можете да съберете конфигурацията на вашата услуга в зависимост от средата.

На практика решихме да направим нещата малко по-различно, отколкото направихме с Nomad. Ако Nomad съхранява както конфигурации за внедряване, така и n-променливи, които са необходими за внедряване на нашата услуга в едно хранилище, тогава тук решихме да ги разделим на две отделни хранилища. Хранилището "deploy" съхранява само n-променливите, необходими за внедряване, докато хранилището "helm" съхранява конфигурации или диаграми.

Какво ни даде?

Въпреки факта, че ние не съхраняваме наистина чувствителни данни в самите конфигурационни файлове. Например пароли за бази данни. Те се съхраняват като тайни в Kubernetes, но въпреки това все още има отделни неща, които не искаме да даваме достъп на всички подред. Поради това достъпът до хранилището "deploy" е по-ограничен, а хранилището "helm" съдържа само описание на услугата. Поради тази причина може да бъде предоставен безопасен достъп на по-голям кръг от хора.

Тъй като имаме не само производство, но и други среди, благодарение на това разделяне, можем да използваме повторно нашите диаграми за управление, за да внедрим услуги не само в производството, но също така, например, в QA среда. Дори да ги разположите локално с помощта на Миникубе - това е такова нещо за локално стартиране на Kubernetes.

Във всяко хранилище оставихме разделение на отделни директории за всяка услуга. Тоест във всяка директория има шаблони, свързани със съответната диаграма и описващи ресурсите, които трябва да бъдат внедрени, за да работи нашата система. Оставихме само envs в хранилището за „разгръщане“. В този случай не използвахме шаблониране с помощта на jinja, тъй като самият helm предоставя шаблониране извън кутията - това е една от основните му функции.

Оставихме скрипта за внедряване - deploy.sh, който опростява и стандартизира стартирането за внедряване с помощта на helm. По този начин, за всеки, който иска да внедри, интерфейсът за внедряване изглежда точно както беше в случай на внедряване чрез Nomad. Същият deploy.sh, името на вашата услуга и къде искате да я внедрите. Това кара кормилото да работи вътрешно. Той от своя страна събира конфигурации от шаблони, замества необходимите файлове със стойности в тях, след което ги разполага, стартирайки ги в Kubernetes.

Данни

Услугата Kubernetes изглежда по-сложна от Nomad.

Тук изходящият трафик идва към Ingress. Това е само предният контролер, който поема всички заявки и впоследствие ги изпраща към услугите, съответстващи на данните за заявката. Той ги определя въз основа на конфигурации, които са част от описанието на вашето приложение в helm и които разработчиците задават сами. Услугата изпраща заявки до своите подове, тоест специфични контейнери, като балансира входящия трафик между всички контейнери, които принадлежат на тази услуга. И, разбира се, не трябва да забравяме, че не трябва да се отклоняваме от сигурността на ниво мрежа. Следователно сегментирането работи в клъстер на Kubernetes, който се основава на маркиране. Всички услуги имат определени тагове, към които са свързани правата за достъп на услугите до определени външни/вътрешни ресурси в или извън клъстера.

Докато преминавахме, видяхме, че Kubernetes има всички функции на Nomad, които сме използвали досега, и също така добавя много нови неща. Може да се разшири чрез плъгини и всъщност чрез потребителски типове ресурси. Това означава, че имате възможност не само да използвате нещо, което идва с Kubernetes извън кутията, но и да създадете свой собствен ресурс и услуга, която ще чете вашия ресурс. Това ви дава повече опции за разширяване на вашата система, без да се налага да преинсталирате Kubernetes и без да се налага да правите промени.

Пример за такова използване е Prometheus, който изпълняваме в клъстер на Kubernetes. За да започне да събира метрики от определена услуга, трябва да добавим допълнителен тип ресурс към описанието на услугата, така наречената услуга за наблюдение. Prometheus, поради факта, че може да чете, стартиран в Kubernetes, персонализиран тип ресурс, автоматично започва да събира метрики от новата система. Достатъчно удобно е.

Първото внедряване, което направихме в Kubernetes, беше през март 2018 г. И през това време никога не сме имали проблеми с него. Работи доста стабилно без значителни грешки. Освен това можем да го разширим допълнително. Към днешна дата имаме достатъчно от възможностите, които има, и наистина харесваме темпото на развитие на Kubernetes. В момента повече от 3000 контейнера са в Kubernetes. Клъстерът заема няколко възела. В същото време е обслужваем, стабилен и много контролируем.

Източник: www.habr.com