5 принципа здравог разума за прављење апликација заснованих на Цлоуд-у

„Природне у облаку“ или једноставно „облачне“ апликације су креиране посебно за рад у инфраструктурама облака. Обично су изграђени као скуп лабаво повезаних микросервиса упакованих у контејнере, којима заузврат управља платформа у облаку. Такве апликације су подразумевано припремљене за кварове, што значи да раде поуздано и да раде чак иу случају озбиљних кварова на нивоу инфраструктуре. Друга страна медаље су скупови ограничења (уговора) које клауд платформа намеће контејнерским апликацијама како би се њима могло аутоматски управљати.

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

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

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

• КИСС (Нека буде једноставно, глупо) – не компликујте;
• СУВ (Не понављај се) – не понављај се;
• ИАГНИ (Неће вам требати) - не стварајте нешто што вам није одмах потребно;
• СОЦ Раздвајање брига – поделите одговорности.

Као што видите, ови принципи не постављају никаква посебна правила, већ спадају у категорију такозваних здраворазумских разматрања заснованих на практичном искуству, које деле многи програмери и на које се редовно позивају.
Осим тога, постоји ЧВРСТО – Скуп од првих пет принципа објектно оријентисаног програмирања и дизајна, који је формулисао Роберт Мартин. СОЛИД укључује широке, отворене, комплементарне принципе који — када се примењују заједно — помажу у стварању бољих софтверских система и бољем одржавању на дужи рок.

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

Контејнери у клауду: Ред Хат приступ

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

Принцип једне забринутости (СЦП)

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

У СЦП-у користимо реч „забринутост” уместо речи „одговорност” да укажемо на виши ниво апстракције и ширу намену контејнера у поређењу са ООП класом. И ако је циљ СРП-а да има само један разлог за промену, онда иза СЦП-а стоји жеља да се прошири могућност поновног коришћења и замене контејнера. Праћењем СРП-а и креирањем контејнера који решава један проблем и ради то на функционално комплетан начин, повећавате шансе за поновну употребу те слике контејнера у различитим контекстима апликације.

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

Ако микросервис контејнера мора да реши неколико проблема одједном, онда се може поделити у контејнере са једним задатком и комбиновати у оквиру једног под-а (јединица за имплементацију платформе контејнера) користећи сидецар и инит шаблоне контејнера. Поред тога, СЦП олакшава замену старог контејнера (као што је веб сервер или посредник за поруке) новим који решава исти проблем, али има проширену функционалност или боље скалирање.

Принцип високе уочљивости (ХОП)

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

У пракси, контејнерска апликација треба да има, у најмању руку, АПИ за различите врсте здравствених провера: тестове животности и тестове спремности. Ако апликација тврди да ради више, мора да обезбеди друга средства за праћење свог стања. На пример, евидентирање важних догађаја преко СТДЕРР-а и СТДОУТ-а за агрегацију евиденције користећи Флуентд, Логстасх и друге сличне алате. Као и интеграција са библиотекама за праћење и прикупљање метрика, као што су ОпенТрацинг, Прометхеус, итд.

Уопштено говорећи, апликација се и даље може третирати као црна кутија, али мора имати све АПИ-је који су потребни платформи како би је пратила и управљала на најбољи могући начин.

Принцип усаглашености животног циклуса (ЛЦП)

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

Платформе имају различите типове догађаја који помажу у управљању животним циклусом контејнера. Али на самој апликацији је да одлучи које од њих да перципира и како да реагује.

Јасно је да су неки догађаји важнији од других. На пример, ако апликација не толерише добро падове, она мора прихватити сигнал: прекинути (СИГТЕРМ) поруке и покренути своју терминску рутину што је брже могуће да би ухватила сигнал: килл (СИГКИЛЛ) који долази после СИГТЕРМ.

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

Принцип непроменљивости слике (ИИП)

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

Циљ ИИП-а је да спречи стварање одвојених слика контејнера за различита окружења за извршавање и да свуда користи исту слику заједно са одговарајућом конфигурацијом специфичном за окружење. Праћење овог принципа вам омогућава да имплементирате тако важне праксе са становишта аутоматизације цлоуд система као што су враћање и враћање унапред ажурирања апликација.

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

Једна од најважнијих карактеристика контејнера је његова ефемерност: инстанцу контејнера је лако створити и лако уништити, тако да се може лако заменити другом инстанцом у било ком тренутку. Разлога за такву замену може бити много: неуспех теста употребљивости, скалирање апликације, пренос на други хост, исцрпљивање ресурса платформе или друге ситуације.

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

Једна пракса која помаже у примени овог принципа је да контејнери буду мали. Цлоуд окружења могу аутоматски да изаберу хост за покретање инстанце контејнера, тако да што је мањи контејнер, то ће се брже покренути – једноставно ће се брже копирати на циљни хост преко мреже.

Принцип самоодржавања (С-ЦП)

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

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

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

Принцип ограничавања времена рада (РЦП)

С-ЦП принцип дефинише како контејнер треба да се изгради и шта бинарна слика треба да садржи. Али контејнер није само „црна кутија“ која има само једну карактеристику - величину датотеке. Током извршавања, контејнер поприма друге димензије: количину коришћене меморије, ЦПУ време и друге системске ресурсе.

И овде добро долази принцип РЦП-а, према којем контејнер мора да обезглави своје захтеве за системским ресурсима и пренесе их на платформу. Са профилима ресурса сваког контејнера (колико ресурса ЦПУ-а, меморије, мреже и диска јој је потребно), платформа може оптимално да врши заказивање и аутоматско скалирање, управља ИТ капацитетом и одржава нивое СЛА за контејнере.

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

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

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

• Покушајте да смањите величину слика: избришите привремене датотеке и немојте инсталирати непотребне пакете – што је мањи контејнер, то се брже склапа и копира на циљни хост преко мреже.
• Фокусирајте се на произвољне корисничке ИД-ове: немојте користити команду судо или било који посебан кориснички ИД за покретање ваших контејнера.
• Означите важне портове: Можете подесити бројеве портова током извршавања, али је боље да их наведете помоћу команде ЕКСПОСЕ – то ће олакшати другим људима и програмима да користе ваше слике.
• Чувајте трајне податке на волуменима: Податке који треба да остану након уништења контејнера треба уписати у волумене.
• Пишите метаподатке слика: ознаке, ознаке и напомене чине слике лакшим за коришћење – други програмери ће вам бити захвални.
• Синхронизујте хост и слике: Неке контејнеризоване апликације захтевају да се контејнер синхронизује са хостом на одређеним атрибутима, као што су време или ИД машине.
• У закључку, делимо шаблоне и најбоље праксе које ће вам помоћи да ефикасније примените горе наведене принципе:
  ввв.слидесхаре.нет/луебкен/цонтаинер-паттернс
  доцс.доцкер.цом/енгине/усергуиде/енг-имаге/доцкерфиле_бест-працтицес
  доцс.пројецтатомиц.ио/цонтаинер-бест-працтицес
  доцс.опенсхифт.цом/ентерприсе/3.0/цреатинг_имагес/гуиделинес.хтмл
  ввв.усеник.орг/систем/филес/цонференце/хотцлоуд16/хотцлоуд16_бурнс.пдф
  леанпуб.цом/к8спаттернс
  12фацтор.нет

Вебинар о новој верзији ОпенСхифт Цонтаинер Платформ – 4
11. јуна у 11.00

Шта ћете научити:

• Непроменљиви Ред Хат Ентерприсе Линук ЦореОС
• ОпенСхифт сервисна мрежа
• Операторски оквир
• Кнативни оквир

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