Как стать автором
Обновить
56.38
Рейтинг
Red Hat
Программные решения с открытым исходным кодом

OpenShift 4.0 – готовимся к гиперскачку

Red HatOpen sourceВиртуализацияDevOpsKubernetes
Это первая из серии наших публикаций, посвященных улучшениям и дополнениям в грядущем обновлении платформы Red Hat OpenShift до версии 4.0, которая поможет вам подготовиться к переходу на новую версию.



Какие инструменты вы сможете получить в свое распоряжение, чтобы создавать более качественные программные продукты, и как они позволят повысить безопасность и сделать разработку проще и надежнее?

С того самого момента как представители только еще формировавшегося сообщества Kubernetes впервые собрались осенью 2014 года в офисе Google в Сиэтле, уже можно было сказать, что проекту Kubernetes суждено в корне изменить современные подходы к разработке и внедрению программного обеспечения. В то же время публичные поставщики облачных услуг продолжали активно инвестировать в развитие инфраструктуры и сервисов, что значительно облегчило и упростило работу с ИТ и создание софта, и сделало их невероятно доступными, что мало кто мог представить себе еще в начале десятилетия.

Разумеется, анонс каждого нового облачного сервиса сопровождался многочисленными обсуждениями экспертов в Твиттере, причем споры велись на самые разные темы – в том числе о конце эпохи открытых исходных кодов, о закате ИТ на стороне клиентов (on-premises IT), о неизбежности новой софтовой монополии в облаке, и о том, как новая парадигма X придет на смену всем остальным парадигмам.

Однако, реальность такова, что ничто никуда не пропадает, и сегодня можно наблюдать экспоненциальный рост конечных продуктов и способов их разработки, что связано с постоянным появлением нового программного обеспечения в нашей жизни. И несмотря на то, что все вокруг будет меняться, в то же время по своей сути все будет оставаться неизменным. Разработчики софта будут по-прежнему писать код с ошибками, инженеры-эксплуатационники и специалисты по надежности будут по-прежнему ходить с пейджерами и получать автоматические оповещения в Slack, менеджеры будут все так же оперировать понятиями OpEx и CapEx, и всякий раз при возникновении сбоя старший разработчик будет грустно вздыхать со словами: «Я же говорил»…

С увеличением сложности проектов появляются и новые риски, и сегодня жизни людей настолько зависят от программного обеспечения, что разработчики просто обязаны стараться делать свою работу лучше.

Kubernetes является одним из таких инструментов. Ведется работа над тем, чтобы в рамках Red Hat 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 для предоставления инфраструктуры и набор учетных записей для доступа к образам предварительной версии.

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

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

А на конференции DevOpsForum 2019 один из разработчиков OpenShift, Вадим Рутковский проведет мастер-класс «Тут всю систему менять надо: чиним сломанные k8s кластеры вместе с сертифицированными слесарями» – сломает десять кластеров и покажет, как их чинить.

Вход на конференцию платный, но по промокоду #RedHat – 37% скидка.

Ждем вас 20 апреля на мастер-класс в Зале #2 в 17:15, и на нашем стенде – весь день. Полезная информация по продуктам, встречи с экспертами, футболки, шляпы, наклейки Red Hat – все как обычно! :-)
Теги:Red Hatopen sourcelinuxdevops
Хабы: Red Hat Open source Виртуализация DevOps Kubernetes
Всего голосов 3: ↑2 и ↓1 +1
Просмотры3.6K

Похожие публикации

Лучшие публикации за сутки

Информация

Дата основания
Местоположение
США
Сайт
www.redhat.com
Численность
5 001–10 000 человек
Дата регистрации

Блог на Хабре