Гэта першая публікацыя ў серыі матэрыялаў, прысвечаных зменам, паляпшэнням і дадаткам у будучым абнаўленні платформы Red Hat OpenShift да 4.0, якія дапамогуць падрыхтавацца да пераходу на новую версію.
З таго самага моманту як прадстаўнікі толькі яшчэ які фармаваўся супольнасці Kubernetes упершыню сабраліся ўвосень 2014 гады ў офісе Google у Сіэтле, ужо можна было сказаць, што праекту Kubernetes наканавана ў корані змяніць сучасныя падыходы да распрацоўкі і ўкараненні праграмнага забеспячэння. У той жа час публічныя пастаўшчыкі хмарных паслуг працягвалі актыўна інвеставаць у развіццё інфраструктуры і сэрвісаў, што значна палегчыла і спрасціла працу з ІТ і стварэнне софту, і зрабіла іх неверагодна даступнымі, што мала хто мог уявіць сабе яшчэ ў пачатку дзесяцігоддзя.
Зразумела, анонс кожнага новага хмарнага сэрвісу суправаджаўся шматлікімі абмеркаваннямі экспертаў у Твітары, прычым спрэчкі вяліся на самыя розныя тэмы - у тым ліку аб канцы эпохі адкрытых зыходных кодаў, аб заходзе ІТ на баку кліентаў (on-premises IT), аб непазбежнасці новай софтавай манаполіі у воблаку, і пра тое, як новая парадыгма X прыйдзе на змену ўсім астатнім парадыгмам.
Ці варта казаць, што ўсе гэтыя спрэчкі былі вельмі дурнымі.
Рэальнасць такая, што нішто нікуды не знікне, і сёння можна назіраць экспанентны рост канчатковых прадуктаў і спосабаў іх распрацоўкі, што звязана са сталым з'яўленнем новага праграмнага забеспячэння ў нашым жыцці. І нягледзячы на тое, што ўсё навокал будзе мяняцца, у той жа час па сваёй сутнасці ўсё будзе заставацца нязменным. Распрацоўнікі софту будуць па-ранейшаму пісаць код з памылкамі, інжынеры-эксплуатацыйнікі і спецыялісты па надзейнасці будуць па-ранейшаму хадзіць з пэйджарамі і атрымліваць аўтаматычныя абвесткі ў Slack, менеджэры будуць усё гэтак жа апераваць паняццямі OpEx і CapEx, і кожны раз пры ўзнікненні збою старэйшы распрацоўшчык будзе сумна ўздыхаць са словамі: «Я ж казаў»…
Што сапраўды варта было б абмеркаваць, Дык гэта тое, якія інструменты мы можам атрымаць у сваё распараджэнне, каб ствараць больш якасныя праграмныя прадукты, і як яны дазваляюць павысіць бяспеку і зрабіць распрацоўку прасцей і надзейней. З павелічэннем складанасці праектаў з'яўляюцца і новыя рызыкі, і сёння жыцці людзей настолькі залежаць ад праграмнага забеспячэння, што распрацоўшчыкі проста абавязаны імкнуцца рабіць сваю працу лепш.
Kubernetes з'яўляецца адным з такіх інструментаў. Вядзецца праца над тым, каб у рамках Red Hat OpenShift аб'яднаць яго з іншымі прыладамі і сэрвісамі ў адзіную платформу, якая дазваляла б зрабіць праграмнае забеспячэнне больш надзейным, зручным у кіраванні і бяспечным для карыстачоў.
З улікам сказанага каманда OpenShift задаецца адным простым пытаннем:
Як можна зрабіць працу з Kubernetes прасцей і зручней?
Адказ на здзіўленне відавочны:
- аўтаматызаваць складаныя моманты ў разгортванні на воблаку ці па-за воблакам;
- засяродзіцца на надзейнасці, хаваючы пры гэтым складанасць;
- працягваць пастаянную работу па выпуску простых і бяспечных абнаўленняў;
- дамагацца кантраляванасці і магчымасці аўдыту;
- імкнуцца першапачаткова забяспечваць высокую бяспеку, але не на шкоду юзабіліці.
Наступны рэліз OpenShift павінен улічваць як досвед стваральнікаў, так і досвед іншых распрацоўнікаў, у вялікіх маштабах укаранялых праграмнае забеспячэнне ў найбуйных кампаніях свету. Акрамя таго, у ім неабходна ўлічваць увесь назапашаны досвед адкрытых экасістэм, якія ляжаць сёння ў аснове сучаснага свету. Пры гэтым неабходна адмовіцца ад ранейшага менталітэту распрацоўшчыка-аматара і перайсці да новай філасофіі аўтаматызаванага будучыні. Гэта павінен быць «мост» паміж ранейшымі і новымі спосабамі разгортвання софту і цалкам выкарыстоўваць усю даступную інфраструктуру – не важна, абслугоўваецца Ці яна найбуйнейшым хмарным пастаўшчыком або запушчана на малюсенькіх сістэмах на перыферыі.
Як дабіцца такога выніку?
У Red Hat прынята доўга выконваць сумную і няўдзячную працу, каб захаваць якая сфармавалася супольнасць і не дапусціць зачыненні праектаў, у якіх кампанія прымае ўдзел. У open-source супольнасці складаецца велізарная колькасць таленавітых распрацоўнікаў, якія ствараюць самыя незвычайныя рэчы - забаўляльныя, навучальныя, якія адкрываюць новыя магчымасці і проста прыгожыя, але, зразумела, ніхто не чакае, што ўсе ўдзельнікі будуць рухацца ў адным кірунку ці будуць пераследваць агульныя мэты. Выкарыстанне гэтай энергіі, перанакіраванне яе ў патрэбнае рэчышча, часам неабходна для развіцця напрамкаў, якія былі б карысныя нашым карыстальнікам, але ў той жа час мы павінны сачыць за развіццём нашых супольнасцяў і вучыцца ў іх.
У пачатку 2018 года Red Hat набыла праект CoreOS, які меў падобныя погляды на будучыню - больш бяспечнае і надзейнае, стваранае на прынцыпах open-source. Кампанія працавала над далейшым развіццём гэтых ідэй і іх рэалізацыяй, ажыццяўляючы нашу філасофію - імкнучыся дамагчыся бяспечнай працы ўсяго праграмнага забеспячэння. Уся гэтая праца будуецца на Kubernetes, Linux, публічных аблоках, прыватных аблоках і тысячах іншых праектаў, якія ляжаць у аснове нашай сучаснай лічбавай экасістэмы.
Новы рэліз OpenShift 4 будзе зразумелым, аўтаматызаваным і больш натуральным
Платформа OpenShift будзе працаваць з самымі лепшымі і надзейнымі аперацыйнымі сістэмамі Linux, з bare-metal апаратнай падтрымкай, зручнай віртуалізацыяй, аўтаматычным праграмаваннем інфраструктуры і, зразумела, кантэйнерамі (якія па сутнасці з'яўляюцца проста выявамі Linux).
Платформа павінна быць бяспечнай з самага пачатку, але пры гэтым забяспечваць магчымасць зручных ітэрацый для распрацоўшчыкаў - гэта значыць валодаць дастатковай гнуткасцю і надзейнасцю, пры гэтым па-ранейшаму дазваляць адміністратарам ажыццяўляць аўдыт і забяспечваць зручнасць кіравання.
Яна павінна дазваляць запускаць праграмнае забеспячэнне "ў выглядзе сэрвісу", і не прыводзіць да некіравальнай разрастання інфраструктуры для аператараў.
Яна дазволіць распрацоўшчыкам засяродзіцца на стварэнні рэальных прадуктаў для карыстальнікаў і кліентаў. Не прыйдзецца прадзірацца скрозь нетры налад абсталявання і праграмнага забеспячэння, а ўсе выпадковыя ўскладненні застануцца ў мінулым.
OpenShift 4: NoOps платформа, якая не патрабуе суправаджэння
В апісваліся тыя задачы, якія дапамаглі сфармаваць бачанне кампаніі ў стаўленні OpenShift 4. У каманды стаіць задача ў максімальнай ступені спрасціць паўсядзённыя задачы па эксплуатацыі і суправаджэнні софту, зрабіць гэтыя працэсы лёгкімі і нязмушанымі – як для адмыслоўцаў, якія займаюцца ўкараненнем, так і для распрацоўнікаў. Але якім чынам можна наблізіцца да гэтай мэты? Як стварыць платформу для запуску софту, якая патрабуе мінімальнага ўмяшання? Што ўвогуле азначае NoOps у гэтым кантэксце?
Калі паспрабаваць абстрагавацца, то для распрацоўнікаў паняцця "serverless" ці "NoOps" азначаюць прылады і сэрвісы, якія дазваляюць схаваць "эксплуатацыйны" складнік або мінімізаваць гэты цяжар для распрацоўніка.
- Працуйце не з сістэмамі, а з прыкладнымі інтэрфейсамі (API).
- Не займайцеся укараненнем софту - хай замест вас гэтым займаецца правайдэр.
- Не варта брацца адразу за стварэнне вялікага фрэймворка - пачніце з напісання невялікіх фрагментаў, якія будуць выступаць у ролі "будаўнічых блокаў", старайцеся, каб гэты код працаваў з дадзенымі і падзеямі, а не з дыскамі і базамі дадзеных.
Задача, як і раней, складаецца ў тым, каб паскорыць ітэрацыі пры распрацоўцы софту, забяспечыць магчымасць для стварэння больш якасных прадуктаў, і каб пры гэтым распрацоўнік мог не перажываць аб сістэмах, на якіх запускаецца яго софт. Вопытны распрацоўшчык выдатна разумее, што калі засяродзіцца на карыстальніках, то карціна можа хутка змяніцца, таму не варта ўкладваць занадта шмат намаганняў у напісанне софту, калі ў вас няма абсалютнай упэўненасці ў яго неабходнасці.
Для спецыялістаў, занятых суправаджэннем і эксплуатацыяй, слова "NoOps" можа гучаць некалькі страшна. Але падчас зносін з інжынерамі па эксплуатацыі становіцца відавочна, што выкарыстоўваныя імі патэрны і методыкі, накіраваныя на забеспячэнне надзейнасці безадмоўнасці (Site Reliability Engineering, SRE), шмат у чым пераклікаюцца з апісанымі вышэй патэрнамі:
- Не кіруйце сістэмамі - аўтаматызуйце працэсы кіравання імі.
- Не займайцеся ўкараненнем праграмнага забеспячэння - стварайце пайплайн для яго разгортвання.
- Старайцеся не аб'ядноўваць усе вашыя сэрвісы разам і не дапускаць, каб адмова аднаго з іх прыводзіла да адмовы ўсёй сістэмы – разгрупуйце іх па ўсёй інфраструктуры, выкарыстоўваючы сродкі аўтаматызацыі, і злучайце іх, прадугледзеўшы магчымасць кантролю і назіранні.
Спецыялісты па SRE ведаюць, што нешта можа пайсці не так, і ім давядзецца адсочваць і ўстараняць праблему - таму яны аўтаматызуюць руцінную працу і загадзя вызначаюцца з дапушчальнымі адхіленнямі (error budgets), каб быць гатовымі да расстаноўкі прыярытэтаў і прыняцця рашэнняў пры ўзнікненні праблемы .
Kubernetes у OpenShift - гэта платформа, закліканая вырашыць дзве асноўныя задачы: замест таго, каб змушаць вас разбірацца з віртуальнымі машынамі або API-інтэрфейсамі балансавальнікаў нагрузкі, вядзецца праца з абстракцыямі больш высокага парадку - з працэсамі разгортвання і сэрвісамі. Замест усталёўкі софтверных агентаў можна запусціць кантэйнеры, а замест напісання ўласнага стэка маніторынгу выкарыстоўваць ужо даступныя ў платформе прылады. Такім чынам, сакрэтны інгрэдыент OpenShift 4 насамрэч не ўяўляе ніякай таямніцы - трэба проста ўзяць за аснову прынцыпы SRE і бессерверныя канцэпцыі, і давесці іх да лагічнага завяршэння, у дапамогу распрацоўнікам і інжынерам па эксплуатацыі:
- Аўтаматызаваць і стандартаваць інфраструктуру, якая выкарыстоўваецца праграмамі
- Злучыць разам працэсы разгортвання і распрацоўкі, не абмяжоўваючы пры гэтым саміх распрацоўнікаў
- Дамагчыся таго, каб запуск, аўдыт і забеспячэнне бяспекі сотага сэрвісу, функцыі, прыкладанні або цэлага стэка былі ані не складаней, чым першага.
Але ў чым жа складаецца адрозненне платформы OpenShift 4 ад яе папярэдніц і ад "стандартнага" падыходу да рашэння падобных праблем? За рахунак чаго дасягаецца маштабаванне для каманд, якія займаюцца ўкараненнем і эксплуатацыяй? За кошт таго, што кароль у гэтай сітуацыі - кластар. Такім чынам,
- Які робіцца так, каб прызначэнне кластараў было зразумелым (Дарагое воблака, гэты кластар я падняў таму, што змог)
- Машыны і аперацыйныя сістэмы існуюць для таго, каб абслугоўваць кластар (Ваша Вялікасць)
- Кіруйце станам хастоў з кластара, мінімізуйце іх перастраенні (drift).
- Для кожнага важнага элемента сістэмы неабходна нянька (механізм), якая будзе адсочваць і ўстараняць праблемы
- Збой *кожнага* аспекту або элемента сістэмы адпаведныя механізмы аднаўлення - гэта звычайная частка жыцця
- Уся інфраструктура павінна канфігуравацца з дапамогай API.
- Выкарыстоўвайце Kubernetes для запуску Kubernetes. (Так-так, гэта не памылка друку)
- Абнаўленні павінны ўсталёўвацца лёгка і нязмушана. Калі для ўсталёўкі абнаўлення патрабуецца больш аднаго кліку мышы, то, відавочна, вымы які робіцца нешта не так.
- Маніторынг і адладка любога кампанента не павінна складаць праблемы, і, адпаведна, адсочванне і складанне справаздачы па ўсёй інфраструктуры таксама павінна быць простым і зручным.
Жадаеце ўбачыць магчымасці платформы ў справе?
Папярэдняя версія OpenShift 4 стала даступная для распрацоўшчыкаў. З дапамогай простага ў выкарыстанні ўсталёўшчыка можна запусціць кластар на AWS па-над Red Had CoreOS. Каб скарыстацца папярэдняй версіяй, патрэбны толькі ўліковы запіс AWS для прадастаўлення інфраструктуры і набор уліковых запісаў для доступу да вобразаў папярэдняй версіі.
- Каб пачаць працу, перайдзіце на і націсніце "Get Started".
- Увайдзіце ў свой рахунак Red Hat (ці стварыце новы) і прытрымлівайцеся інструкцыям, каб наладзіць ваш першы кластар.
Пасля паспяховай устаноўкі, азнаёмцеся з нашымі навучальнымі матэрыяламі , Каб атрымаць больш падрабязнае ўяўленне аб сістэмах і канцэпцыях, якія робяць платформу OpenShift 4 гэтак простым і зручным інструментам для запуску Kubernetes.
Паспрабуйце новы рэліз OpenShift і падзяліцеся сваім меркаваннем. Мы імкнемся зрабіць працу з Kumbernetes максімальна даступнай і не патрабуе намаганняў - будучыня NoOps пачынаецца ўжо сёння.
А зараз увага!
на канферэнцыі 20 красавіка адзін з распрацоўшчыкаў OpenShift, Вадзім Руткоўскі правядзе майстар-клас — зламае дзесяць кластараў і прымусіць правіць. Конфа платная, але па промакодзе #RedHat зніжка 37%
Майстар клас у 17:15 - 18:15, а стэнд працуе ўвесь дзень. Футболкі, капялюшы, налепкі - як звычайна!
Зала #2
«Тут усю сістэму мяняць трэба: робім зламаныя k8s кластары разам з сертыфікаванымі слесарамі».
Крыніца: habr.com