5 принципи на здрав разум за градење апликации на облакот

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

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

Принципи за дизајн на софтвер

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

• KISS (Чувајте го едноставно, глупаво) - не го комплицирајте;
• СУВА (Не се повторувај) - не се повторувај;
• ЈАГНИ (Нема да ви треба) - не создавајте нешто што не е веднаш потребно;
• СПЦ Поделба на грижи – споделете ги одговорностите.

Како што можете да видите, овие принципи не поставуваат никакви конкретни правила, туку припаѓаат на категоријата таканаречени размислувања за здрав разум засновани на практично искуство, кои ги споделуваат многу програмери и на кои тие редовно се повикуваат.
Покрај тоа, постои СОЛИД – Збир од првите пет принципи на објектно-ориентирано програмирање и дизајн, формулирани од Роберт Мартин. SOLID вклучува широки, отворени, комплементарни принципи кои - кога се применуваат заедно - помагаат да се создадат подобри софтверски системи и подобро да се одржуваат на долг рок.

Принципите SOLID припаѓаат на полето на OOP и се формулирани на јазикот на такви концепти и концепти како класи, интерфејси и наследување. По аналогија, развојните принципи може да се формулираат и за облак апликации, само основниот елемент овде нема да биде класа, туку контејнер. Следејќи ги овие принципи, можете да креирате контејнеризирани апликации кои подобро ги исполнуваат целите и задачите на облак платформите како Kubernetes.

Контејнери од облакот: пристапот на Red Hat

Денес, речиси секоја апликација може релативно лесно да се спакува во контејнери. Но, за апликациите да бидат ефективно автоматизирани и оркестрирани во облак платформа како Kubernetes, потребен е дополнителен напор.
Основата за идеите наведени подолу беше методологијата Апликацијата Twelve-Factor и многу други работи на различни аспекти на градење веб-апликации, од управување со изворниот код до модели на скалирање. Опишаните принципи важат само за развој на контејнеризирани апликации кои се изградени на врвот на микросервисите и дизајнирани за облак платформи како што е Kubernetes. Основниот елемент во нашата дискусија е сликата на контејнерот, а целното време на траење на контејнерот е платформата за оркестрација на контејнерот. Целта на предложените принципи е да се создадат контејнери за кои задачите за распоред, скалирање и следење може да се автоматизираат на повеќето платформи за оркестрација. Принципите се претставени без посебен редослед.

Принцип на единствена грижа (SCP)

Овој принцип на многу начини е сличен на принципот на единствена одговорност. СРП), кој е дел од множеството SOLID и вели дека секој објект мора да има една одговорност и таа одговорност мора да биде целосно инкапсулирана во класа. Поентата на SRP е дека секоја одговорност е причина за промена, а класата мора да има една и само една причина за промена.

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

Принципот на SCP вели дека секој контејнер треба да реши еден единствен проблем и да го направи тоа добро. Згора на тоа, SCP во светот на контејнерите е полесно да се постигне од SRP во светот на OOP, бидејќи контејнерите обично извршуваат еден единствен процес, а најчесто овој процес решава една единствена задача.

Ако микросервисот за контејнер мора да реши неколку проблеми одеднаш, тогаш може да се подели на контејнери со една задача и да се комбинира во една подлога (единица за распоредување на платформата за контејнер) со помош на шаблони за странични и иницијални контејнери. Дополнително, 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 е да спречи создавање на посебни слики од контејнери за различни опкружувања за извршување и да ја користи истата слика насекаде заедно со соодветната конфигурација специфична за околината. Следењето на овој принцип ви овозможува да имплементирате такви важни практики од гледна точка на автоматизација на облак системите како враќање назад и превртување на ажурирањата на апликациите.

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

Една од најважните карактеристики на контејнер е неговата минливост: примерок од контејнер лесно се создава и лесно се уништува, така што може лесно да се замени со друг примерок во секое време. Може да има многу причини за таква замена: неуспех на тест за услужливост, скалирање на апликацијата, трансфер на друг домаќин, исцрпување на ресурсите на платформата или други ситуации.

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

Една практика што помага да се имплементира овој принцип е да се одржуваат мали контејнери. Облачните околини можат автоматски да избираат домаќин на кој ќе стартува примерок од контејнер, така што колку е помал контејнерот, толку побрзо ќе стартува - едноставно побрзо ќе се копира на целниот домаќин преку мрежата.

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

Според овој принцип, во фазата на склопување, сите потребни компоненти се вклучени во контејнерот. Контејнерот треба да биде изграден врз претпоставката дека системот има само чисто кернел на Линукс, па сите потребни дополнителни библиотеки треба да се стават во самиот контејнер. Исто така, треба да содржи работи како што се времето на работа за соодветниот програмски јазик, платформата на апликацијата (доколку е потребно) и други зависности што ќе бидат потребни додека работи апликацијата за контејнер.

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

Апликацијата може да вклучува неколку контејнеризирани компоненти, на пример, посебен DBMS контејнер во веб-апликација со контејнери. Според принципот S-CP, овие контејнери не треба да се комбинираат во едно, туку треба да се направат така што контејнерот DBMS содржи се што е потребно за функционирање на базата на податоци, а контејнерот за веб-апликации содржи се што е потребно за работа на веб. апликација, истиот веб-сервер. Како резултат на тоа, за време на извршувањето, контејнерот за веб-апликација ќе зависи од контејнерот DBMS и ќе пристапи до него по потреба.

Принцип на затворање за време на траење (RCP)

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

И тука ни доаѓа принципот RCP, според кој контејнерот мора да ги обезглави своите барања за системските ресурси и да ги пренесе на платформата. Со ресурсните профили на секој контејнер (колку ресурси на процесорот, меморијата, мрежата и дискот му се потребни), платформата може оптимално да врши закажување и автоматско скалирање, да управува со ИТ капацитетот и да ги одржува нивоата на SLA за контејнерите.

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

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

Забележете дека покрај овие општи принципи, ќе ви требаат и дополнителни напредни методи и техники за работа со контејнери. Дополнително, имаме неколку кратки препораки кои се поконкретни и треба да се применуваат (или да не се применуваат) во зависност од ситуацијата:

• Обидете се да ја намалите големината на сликите: избришете ги привремените датотеки и не инсталирајте непотребни пакети - колку е помала големината на контејнерот, толку побрзо се составува и се копира на целниот домаќин преку мрежата.
• Фокусирајте се на произволни кориснички идентификатори: не користете ја командата sudo или некој посебен корисничкиид за да ги стартувате вашите контејнери.
• Обележете важни порти: можете да поставите броеви на порти при извршување, но подобро е да ги наведете со помош на командата EXPOSE - тоа ќе им олесни на другите луѓе и програми да ги користат вашите слики.
• Чувајте постојани податоци за томови: Податоците што треба да останат по уништувањето на контејнерот треба да се запишат во томови.
• Напишете метаподатоци за слики: ознаките, етикетите и прибелешките ја олеснуваат употребата на сликите - другите програмери ќе ви се заблагодарат.
• Синхронизирајте домаќин и слики: некои контејнеризирани апликации бараат контејнерот да се синхронизира со домаќинот на одредени атрибути, како што се времето или ID на машината.
• Како заклучок, споделуваме шаблони и најдобри практики кои ќе ви помогнат поефикасно да ги имплементирате принципите наведени погоре:
  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:XNUMX часот

Што ќе научите:

• Непроменлив Red Hat Enterprise Linux CoreOS
• Услужна мрежа OpenShift
• Рамка на операторот
• Книтивна рамка

Извор: www.habr.com