🥇5 принципа на здравия разум за създаване на cloud-native приложения

„Облачни“ (cloud native) приложения са създадени специално за работа в облачни инфраструктури. Обикновено те се изграждат като набор от слабо свързани микросервизи, опаковани в контейнери, които от своя страна се управляват от облачна платформа. Такива приложения по подразбиране са готови за повреди, което означава, че функционират надеждно и се мащабират дори при сериозни откази на инфраструктурно ниво. Обратната страна на монетата са наборите от ограничения (контракти), които облачната платформа налага на контейнерните приложения, за да може да ги управлява в автоматичен режим.

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

Принципи на проектиране на софтуер

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

KISS (Keep it simple, stupid) – не усложнявайте;
DRY (Don’t repeat yourself) – не се повтаряйте;
YAGNI (You aren’t gonna need it) – не създавайте неща, от които нямате непосредствена нужда;
SoC (Separation of concerns) – разделяйте отговорностите.

Както се вижда, тези принципи не задават конкретни правила, а принадлежат към категорията на така наречените здравразумни разсъждения, основани на практическия опит, които споделят много разработчици и на които те редовно се позовават.
Освен това, съществува SOLID – набор от първите пет принципа на обектно-ориентираното програмиране и проектиране, формулирани от Робърт Мартин. SOLID включва обобщени и отворени за интерпретация взаимодопълващи принципи, които – ако се прилагат в комбинация – помагат за създаването на по-качествени софтуерни системи и по-добро поддържане на тях в дългосрочен план.

Принципите на SOLID принадлежат на сферата на ООП и се формулират на езика на понятия и концепции като класове, интерфейси и наследяване. Analogично, за облачните приложения също могат да бъдат формулирани принципи за разработка, само че основният елемент тук няма да бъде клас, а контейнер. Следвайки тези принципи, могат да се създават контейнерни приложения, които по-добре отговарят на целите и задачите на облачните платформи като Kubernetes.

Облачно-ориентирани контейнери: подход на Red Hat

Днес в контейнерите може относително лесно да бъде опаковано почти всяко приложение. Но за да се автоматизират и оркестрират приложенията ефективно в рамките на облачна платформа като Kubernetes, е необходимо да се приложат допълнителни усилия.
Основата за изложените по-долу идеи е методологията The Twelve-Factor App и множество други изследвания по различни аспекти на създаването на уеб приложения, от управление на изходния код до модели за мащабиране. Описваните принципи се отнасят само за разработката на контейнерни приложения, изградени на базата на микросервизи и предназначени за облачни платформи като Kubernetes. Основният елемент в нашите разсъждения е образът на контейнера, а под целевата среда за изпълнение на контейнерите разбираме платформата за оркестрация на контейнери. Целта на предложените принципи е да се създават контейнери, за които на повечето платформи за оркестрация може да се автоматизират задачи по управлението (scheduling – избор на хост за стартиране на инстанция на контейнера), мащабиране и мониторинг. Принципите се излагат в произволен ред.

Принцип на единствената задача (Single Concern Principle, SCP)

Този принцип в много отношения наподобява принципа на единствената отговорност (Single Responsibility Principle, SRP), който е част от набора SOLID и гласи, че всеки обект трябва да има една задължителност, и тази задължителност трябва да бъде напълно инкапсулирана в класа. Същността на SRP е, че всяка задължителност е причина за промени, а класът трябва да има една единствена причина за промяна.

В SCP вместо термина „отговорност“ (responsibility) използваме термина „задача“ (concern), за да посочим по-високо ниво на абстракция и по-широка цел на контейнера в сравнение с ООП клас. И ако целта на SRP е да имате само една причина за изменения, то зад SCP стои желанието да се разширят възможностите за повторно използване и замяна на контейнерите. Следвайки SRP и създавайки контейнер, който решава една единствена задача и прави това по функционално завършен начин, увеличавате шансовете за повторно използване на имиджа на този контейнер в различни контексти на приложението.

Принципът SCP гласи, че всеки контейнер трябва да решава една единствена задача и да го прави добре. Освен това, SCP в света на контейнерите се постига по-лесно, отколкото SRP в света на ООП, тъй като контейнерите обикновено изпълняват един единствен процес, а през по-голямата част от времето този процес решава една единствена задача.

Ако някой контейнерен микросервис трябва да решава едновременно няколко задачи, той може да бъде разделен на однозадачни контейнери и да бъдат обединени в рамките на един pod (единица за разгръщане на контейнерна платформа) с помощта на шаблони sidecar и init контейнери. Освен това, SCP улеснява замяната на стар контейнер (например, уеб сървър или брокер на съобщения) с нов, който решава същата задача, но предлага разширена функционалност или по-добра мащабируемост.

Принципът за удобство на мониторинга (High Observability Principle, HOP)

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

На практика контейнерното приложение трябва поне да има API за различни видове проверки на състоянието: тестове за активност (liveness) и тестове за готовност (readiness). Ако приложението претендира за повече, трябва да предоставя и други средства за контрол на своето състояние. Например, регистриране на важни събития чрез STDERR и STDOUT за агрегация на логове с помощта на Fluentd, Logstash и други подобни инструменти. И също така интеграция с библиотеки за трасировка и събиране на метрики като OpenTracing, Prometheus и т.н.

Общо взето, приложението все още може да се разглежда като „черна кутия“, но трябва да бъде снабдено с всички API, които платформата изисква, за да може да го наблюдава и управлява по най-добрия начин.

Принцип на съвместимост с жизнения цикъл (Life-cycle Conformance Principle, LCP)

LCP е антитеза на HOP. Докато HOP твърди, че контейнерът трябва да предоставя на платформата API интерфейси за четене, LCP изисква от приложението да възприема информация от платформата. Контейнерът не само трябва да получава събития, но и да се адаптира, т.е. да реагира на тях. Оттук и названието на принципа, който може да се разглежда като изискване за предоставяне на на платформата API интерфейси за запис.

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

Очевидно е, че някои събития са по-важни от други. Например, ако приложението не понася добре аварийно прекратяване на работата, то е задължено да приема съобщения signal: terminate (SIGTERM) и колкото се може по-бързо да инициира собствената си процедура за прекратяване, за да успее преди да получи signal: kill (SIGKILL), който следва след SIGTERM.

Освен това, за жизнения цикъл на приложението могат да бъдат важни събития като PostStart и PreStop. Например, след стартирането приложението може да изисква определено време за 'разгряване', преди да може да отговаря на заявки. Или приложението трябва по някакъв специален начин да освобождава ресурси при закриването си.

Принцип на неизменност на контейнерния образ (Image Immutability Principle, IIP)

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

Целта на IIP е да предотврати създаването на отделни контейнерни образи за различни среди на изпълнение и да използва навсякъде един и същ образ, заедно с подходяща конфигурация за конкретната среда. Спазването на този принцип позволява да се реализират важни практики от гледна точка на автоматизацията на облачните системи, като откат (roll-back) и накат (roll-forward) на обновленията на приложението.

Принцип на еднократност на процесите (Process Disposability Principle, PDP)

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

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

Една от практиките, която помага за реализирането на този принцип, е създаването на малки по размер контейнери. Облачните среди могат автоматично да избират хост за стартиране на екземпляр на контейнера, така че колкото по-малък е размерът на контейнера, толкова по-бързо ще се стартира – той просто ще бъде копиран по-бързо в целевия хост през мрежата.

Принцип на самообезпеченост (Self-containment Principle, S-CP)

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

Изключенията се правят само за конфигурации, които варират от среда на среда и трябва да се предоставят на етапа на изпълнение, например чрез Kubernetes ConfigMap.

Приложението може да включва няколко контейнеризирани компонента, например отделен контейнер за СУБД в състава на контейнерно уеб приложение. Според принципа S-CP, тези контейнери не трябва да се комбинират в един, а трябва да се направи така, че контейнерът за СУБД да съдържа всичко необходимо за работата на базата данни, а контейнерът на уеб приложението – всичко необходимо за работата на уеб приложението, като например уеб сървър. В резултат на това, по време на изпълнението контейнерът на уеб приложението ще зависи от контейнера за СУБД и ще се свързва с него при необходимост.

Принцип на ограничаването на етапа на изпълнение (Runtime Confinement Principle, RCP)

Принципът S-CP определя как трябва да бъде изградена контейнерът и какво трябва да съдържа бинарният файл на образа. Но контейнерът не е просто "черна кутия", която има само една характеристика – размер на файла. По време на изпълнението контейнерът придобива и други измерения: обем на използваната памет, време на процесора и други системни ресурси.

И тук принципът RCP е полезен, съгласно който контейнерът трябва да декомпресира изискванията си за системни ресурси и да ги предаде на платформата. Имайки ресурсни профили на всеки контейнер (колко ресурси ЦП, памет, мрежа и дискова система му трябват), платформата може оптимално да извършва управление и автоматично мащабиране, да управлява ИТ-ресурсите и да поддържа SLA нива за контейнерите.

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

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

Следва да отбележим, че освен тези общи принципи, ще ви трябват и допълнителни напреднали методи и техники за работа с контейнери. Освен това, имаме няколко кратки препоръки, които имат по-конкретен характер и трябва да се прилагат (или не) в зависимост от ситуацията:

Опитайте се да намалите размера на образите: изтривайте времеви файлове и не инсталирайте ненужни пакети – колкото по-малък е размерът на контейнера, толкова по-бързо се изгражда и копира в целевия хост по мрежата.
Ориентирайте се към произволни User-ID: не използвайте командата sudo или специални userid за стартиране на вашите контейнери.
Маркирайте важните портове: номерата на портовете могат да бъдат зададени и по време на изпълнение, но е по-добре да ги посочите с командата EXPOSE – на другите хора и програми ще бъде по-лесно да използват вашите образи.
Съхранявайте постоянни данни на томове: данните, които трябва да останат след унищожаването на контейнера, трябва да бъдат записвани на томове.
Определете метаданни на образа: етикетите, таговете и анотациите улесняват използването на образите – другите разработчици ще ви бъдат благодарни.
Синхронизирайте хоста и образите: за някои контейнерни приложения е необходимо синхронизирането на контейнера с хоста по определени атрибути, като време или идентификатор на машината.
В заключение споделяме шаблони и най-добри практики, които ще помогнат за по-ефективното прилагане на изброените по-горе принципи:
www.slideshare.net/luebken/container-patterns
docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices
docs.projectatomic.io/container-best-practices
docs.openshift.com/enterprise/3.0/creating_images/guidelines.html
www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf
leanpub.com/k8spatterns
12factor.net