🥇Современная платформа для разработки и развертывания программного обеспечения

Это первая публикация в серии материалов, посвященных изменениям, улучшениям и дополнениям в грядущем обновлении платформы 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 для предоставления инфраструктуры и набор учетных записей для доступа к образам предварительной версии.

Чтобы начать работу, перейдите на try.openshift.com и нажмите “Get Started”.
Войдите в свой аккаунт Red Hat (или создайте новый) и следуйте инструкциям, чтобы настроить ваш первый кластер.

После успешной установки, ознакомьтесь с нашими обучающими материалами OpenShift Training, чтобы получить более подробное представление о системах и концепциях, которые делают платформу OpenShift 4 столь простым и удобным инструментом для запуска Kubernetes.

Попробуйте новый релиз OpenShift и поделитесь своим мнением. Мы стремимся сделать работу с Kumbernetes максимально доступной и не требующей усилий – будущее NoOps начинается уже сегодня.

А теперь внимание!
На конференции DevOpsForum 2019 20 апреля один из разработчиков OpenShift, Вадим Рутковский проведет мастер класс — сломает десять кластеров и заставит чинить. Конфа платная, но по промокоду #RedHat скидка 37%

Мастер класс в 17:15 — 18:15, а стенд работает весь день. Футболки, шляпы, наклейки — как обычно!

Зал #2
«Тут всю систему менять надо: чиним сломанные k8s кластеры вместе с сертифицированными слесарями».

Источник: habr.com