Това е първата публикация в серия материали, посветени на промените, подобренията и допълненията в предстоящото обновление на платформата Red Hat OpenShift до 4.0, които ще помогнат за подготовката за прехода към новата версия.
От момента, в който представителите на току-що формираното общество Kubernetes се събраха през есента на 2014 г. в офиса на Google в Сиатъл, беше ясно, че проектът Kubernetes е предназначен да промени коренно съвременните подходи към разработката и внедряването на софтуер. В същото време публичните доставчици на облачни услуги активно инвестираха в развитието на инфраструктура и услуги, което значително улесни работата с ИТ и създаването на софтуер, правейки ги невероятно достъпни, каквито малко хора можеха да си представят в началото на днешното десетилетие.
Разбира се, анонсът на всяка нова облачна услуга е съпроводен с многобройни обсъждания на експерти в Twitter, като споровете обхващат различни теми – включително края на ерата на отворен код, упадъка на клиентската ИТ (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 и предшествениците й, както и стандартния подход за решение на подобни проблеми? Какво осигурява мащабируемостта за екипите, ангажирани с внедряване и експлоатация? Защото в тази ситуация, кластерът е на царския трон. И така,
- Нека направим така, че предназначението на кластерите да е ясно (Скъпо облако, създадох този кластер, защото мога)
- Машините и операционните системи съществуват, за да обслужват кластера (Ваше Величество)
- Управлявайте състоянието на хостовете от кластерa и минимизирайте техните изменения (drift).
- За всеки важен елемент в системата е необходима 'нянка' (механизъм), който да следи и отстранява проблемите.
- Неуспех *на всеки* аспект или елемент от системата изисква съответните механизми за възстановяване — това е обичайна част от живота.
- Цялата инфраструктура трябва да се конфигурира чрез API.
- Използвайте Kubernetes, за да стартирате Kubernetes. (Да-да, това не е печатна грешка)
- Актуализациите трябва да се инсталират лесно и безпроблемно. Ако за инсталиране на актуализация е необходимо повече от едно щракване с мишката, очевидно нещо не е наред.
- Наблюдението и отстраняването на всеки компонент не трябва да представлява затруднение, и следователно, проследяването и отчетността на цялата инфраструктура също трябва да са лесни и удобни.
Искате ли да видите възможностите на платформата в действие?
Предварителната версия на OpenShift 4 стана достъпна за разработчици. С помощта на лесен за използване инсталатор, можете да стартирате кластер на AWS над Red Hat CoreOS. За да се възползвате от предварителна версия, ви е нужна само AWS акаунт, за да предоставите инфраструктурата, и набор от акаунти за достъп до образите на предварителната версия.
- За да започнете, посетете и натиснете “Get Started”.
- Влезте в своя Red Hat акаунт (или създайте нов) и следвайте инструкциите, за да настроите своя първи кластер.
След успешна инсталация, запознайте се с нашите обучителни материали , за да получите по-подробно разбиране за системите и концепциите, които правят платформата OpenShift 4 толкова лесен и удобен инструмент за стартиране на Kubernetes.
Изпробвайте новата версия на OpenShift и споделете мнението си. Нашата цел е да направим работата с Kubernetes колкото се може по-достъпна и без усилия – бъдещето на NoOps започва още днес.
А сега внимание!
На конференцията На 20 април един от разработчиците на OpenShift, Вадим Рутковски, ще проведе майсторски клас – ще счупи десет клъстера и ще ги поправи. Конференцията е платна, но с промокод #RedHat получавате 37% отстъпка.
Майсторският клас е от 17:15 до 18:15, а щандът работи целия ден. Тениски, шапки, стикери – както обикновено!
Зала #2
«Трябва да променим цялата система: поправяме счупените k8s клъстери заедно с сертифицирани техници».
Източник: habr.com
