«Воблачна-арыентаваныя» (cloud native) або проста «хмарныя» прыкладанні ствараюцца спецыяльна для працы ў хмарных інфраструктурах. Звычайна яны будуюцца як набор слаба звязаных мікрасэрвісаў, упакаваных у кантэйнеры, якія, у сваю чаргу кіруюцца хмарнай платформай. Такія прыкладанні па змаўчанні гатовыя да збояў, а значыць надзейна працуюць і маштабуюцца нават пры сур'ёзных адмовах інфраструктурнага ўзроўню. Адваротны бок медаля - наборы абмежаванняў (кантракты), якія хмарная платформа накладвае на кантэйнерныя прыкладанні, каб мець магчымасць кіраваць імі ў аўтаматычным рэжыме.
Выдатна ўсведамляючы неабходнасць і важнасць пераходу на хмарныя прыкладанні, многія арганізацыі ўсё яшчэ не ведаюць, з чаго пачаць. У гэтым пасце мы разгледзім шэраг прынцыпаў, захаванне якіх пры распрацоўцы кантэйнерных прыкладанняў дазволіць рэалізаваць патэнцыял хмарных платформаў і дамагчыся надзейнай працы і маштабаванні прыкладанняў нават пры сур'ёзных адмовах на ўзроўні ІТ-інфраструктуры. Канчатковая мэта выкладзеных тут прынцыпаў - навучыцца ствараць прыкладанні, якія могуць аўтаматычна кіравацца хмарнымі платформамі, такімі як Kubernetes.
Прынцыпы праектавання праграмнага забеспячэння
У свеце праграмавання пад прынцыпамі разумеюцца даволі агульныя правілы, якія неабходна выконваць пры распрацоўцы ПЗ. Іх можна ўжываць пры працы з любой мовай праграмавання. У кожнага прынцыпу ёсць свае мэты, прыладай дасягнення якіх звычайна служаць шаблоны і практыкі. Таксама існуе шэраг фундаментальных прынцыпаў стварэння якаснага софту, з якіх выцякаюць усе астатнія. Прывядзем прыклады фундаментальных прынцыпаў:
- (Keep it simple, stupid) - не ўскладняць;
- (Don't repeat yourself) - не паўтарацца;
- (You aren't gonna need it) - не ствараць тое, у чым няма непасрэднай патрэбы;
- (Separation of concerns) - падзяляць адказнасці.
Як бачна, гэтыя прынцыпы не задаюць ніякіх канкрэтных правілаў, а адносяцца да разраду так званых меркаванняў здаровага сэнсу на аснове практычнага вопыту, якія падзяляюць многія распрацоўшчыкі і на якія яны ж рэгулярна спасылаюцца.
Акрамя таго, існуе – набор з першых пяці прынцыпаў аб'ектна-арыентаванага праграмавання і праектавання, сфармуляваных Робертам Марцінам. SOLID уключае ў сябе абагульненыя і адкрытыя для трактоўкі ўзаемадапаўняльныя прынцыпы, якія - калі ўжываць іх у комплексе - дапамагаюць ствараць больш якасныя праграмныя сістэмы і лепш падтрымліваць іх у доўгатэрміновай перспектыве.
Прынцыпы SOLID адносяцца да сферы ААП і фармулююцца на мове такіх паняццяў і канцэпцый, як класы, інтэрфейсы і ўспадкоўванне. Па аналогіі, для хмарных прыкладанняў таксама можна сфармуляваць прынцыпы распрацоўкі, толькі базавым элементам тут будзе не клас, а кантэйнер. Прытрымліваючыся гэтым прынцыпам, можна ствараць кантэйнерныя прыкладанні, якія лепш адказваюць мэтам і задачам хмарных платформаў накшталт Kubernetes.
Воблачна-арыентаваныя кантэйнеры: падыход Red Hat
Сёння ў кантэйнеры можна адносна лёгка спакаваць практычна любое прыкладанне. Але для таго, каб прыкладанні эфектыўна аўтаматызаваліся і аркестраваліся ў рамках хмарнай платформы тыпу Kubernetes, патрабуецца прыкласці дадатковыя намаганні.
Асновай для выкладзеных ніжэй ідэй паслужыла метадалогія і мноства іншых прац па розных аспектах стварэння вэб-прыкладанняў, ад кіравання зыходным кодам да мадэляў маштабавання. Апісваныя прынцыпы адносяцца толькі да распрацоўкі кантэйнерных прыкладанняў, якія пабудаваны на аснове мікрасэрвісаў і прызначаны для хмарных платформаў, такіх як Kubernetes. Базавым элементам у нашых развагах служыць выява кантэйнера, а пад мэтавым асяроддзем выканання кантэйнераў разумеецца платформа аркестрацыі кантэйнераў. Мэта прапанаваных прынцыпаў складаецца ў тым, каб ствараць кантэйнеры, для якіх на большасці платформаў аркестрацыі можна аўтаматызаваць задачы дыспетчарызацыі (scheduling - выбар хаста для запуску асобніка кантэйнера), маштабавання і маніторынгу. Прынцыпы выкладаюцца ў адвольным парадку.
Прынцып адзінай задачы (Single Concern Principle, SCP)
Гэты прынцып шмат у чым падобны на прынцып адзінай адказнасці (Single Responsibility Principle, ), які ўваходзіць у набор 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 - іншым людзям і праграмам будзе прасцей выкарыстоўваць вашыя вобразы.
- Захоўвайце пастаянныя дадзеныя на тамах: дадзеныя, якія павінны застацца пасля знішчэння кантэйнера, варта запісваць на тамы.
- Прапісвайце метададзеныя выявы: тэгі, пазнакі і анатацыі палягчаюць выкарыстанне выяў - іншыя распрацоўнікі будуць вам удзячныя.
- Сінхранізуйце хост і выявы: для некаторых кантэйнерных прыкладанняў патрабуецца сінхранізацыі кантэйнера з хастом па пэўных атрыбутах, такім як час або ідэнтыфікатар машыны.
- У заключэнне дзелімся шаблонамі і лепшымі практыкамі, якія дапамогуць больш эфектыўна рэалізаваць пералічаныя вышэй прынцыпы:
11 чэрвеня ў 11.00
Што вы даведаецеся:
- Immutable Red Hat Enterprise Linux CoreOS
- OpenShift service mesh
- Operator framework
- Knative framework
Крыніца: habr.com