5 принципа на здравия разум за изграждане на облачни приложения

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

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

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

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

• KISS (Keep it simple, stupid) – не го усложнявайте;
• DRY (Не се повтаряйте) - не се повтаряйте;
• YAGNI (Няма да ви трябва) - не създавайте нещо, което не е незабавно необходимо;
• SoC Разделяне на грижите – споделяне на отговорностите.

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

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

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

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

Принцип на единния проблем (SCP)

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

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

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

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

Принцип на висока наблюдаемост (HOP)

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

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

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

Принцип на съответствие на жизнения цикъл (LCP)

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

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

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

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

Принципът на неизменността на изображението (IIP)

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

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

Принцип на еднократна употреба (PDP)

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

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

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

Принцип на самозадържане (S-CP)

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

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

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

Принцип на ограничение по време на изпълнение (RCP)

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

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

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

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

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

• Опитайте се да намалите размера на изображенията: изтрийте временните файлове и не инсталирайте ненужни пакети - колкото по-малък е размерът на контейнера, толкова по-бързо се сглобява и копира на целевия хост по мрежата.
• Съсредоточете се върху произволни потребителски идентификатори: не използвайте командата sudo или друг специален потребителски идентификатор за стартиране на вашите контейнери.
• Маркиране на важни портове: Можете да зададете номера на портове по време на изпълнение, но е по-добре да ги посочите с помощта на командата 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

Уебинар за новата версия на OpenShift Container Platform – 4
На 11 юни от 11.00 ч

Какво ще научите:

• Неизменна Red Hat Enterprise Linux CoreOS
• Сервизна мрежа OpenShift
• Рамка на оператора
• Knative рамка

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