Это первая из серии наших публикаций, посвященных улучшениям и дополнениям в грядущем обновлении платформы 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 в этом контексте?
Если постараться абстрагироваться, то для разработчиков понятия «serverless» или «NoOps» означают инструменты и сервисы, позволяющие спрятать «эксплуатационную» составляющую или минимизировать это бремя для разработчика.
Задача, как и раньше, состоит в том, чтобы ускорить итерации при разработке софта, обеспечить возможность для создания более качественных продуктов, и чтобы при этом разработчик мог не переживать о системах, на которых запускается его софт. Опытный разработчик прекрасно понимает, что если сосредоточиться на пользователях, то картина может быстро измениться, поэтому не следует вкладывать слишком много усилий в написание софта, если у вас нет абсолютной уверенности в его необходимости.
Для специалистов, занятых сопровождением и эксплуатацией, слово «NoOps» может звучать несколько пугающе. Но во время общении с инженерами по эксплуатации становится очевидно, что используемые ими паттерны и методики, направленные на обеспечение надежности безотказности (Site Reliability Engineering, SRE), во многом перекликаются с описанными выше паттернами:
Специалисты по SRE знают, что что-то может пойти не так, и им придется отслеживать и устранять проблему – поэтому они автоматизируют рутинную работу и заранее определяются с допустимыми отклонениями (error budgets), чтобы быть готовыми к расстановке приоритетов и принятию решений при возникновении проблемы.
Kubernetes в OpenShift – это платформа, призванная решить две основные задачи: вместо того, чтобы вынуждать вас разбираться с виртуальными машинами или API-интерфейсами балансировщиков нагрузки, ведется работа с абстракциями более высокого порядка – с процессами развертывания и сервисами. Вместо установки софтверных агентов можно запустить контейнеры, а вместо написания собственного стека мониторинга использовать уже доступные в платформе инструменты. Таким образом, секретный ингредиент OpenShift 4 на самом деле не представляет никакой тайны – нужно просто взять за основу принципы SRE и бессерверные концепции, и довести их до логического завершения, в помощь разработчикам и инженерам по эксплуатации:
Но в чем же заключается отличие платформы OpenShift 4 от ее предшественниц и от «стандартного» подхода к решению подобных проблем? За счет чего достигается масштабирование для команд, занимающихся внедрением и эксплуатацией? За счет того, что король в этой ситуации — кластер. Итак,
Предварительная версия OpenShift 4 стала доступна для разработчиков. С помощью простого в использовании установщика можно запустить кластер на AWS поверх Red Had CoreOS. Чтобы воспользоваться предварительной версией нужна только учетная запись AWS для предоставления инфраструктуры и набор учетных записей для доступа к образам предварительной версии.
После успешной установки, ознакомьтесь с нашими обучающими материалами OpenShift Training, чтобы получить более подробное представление о системах и концепциях, которые делают платформу OpenShift 4 столь простым и удобным инструментом для запуска Kubernetes.
А на конференции DevOpsForum 2019 один из разработчиков OpenShift, Вадим Рутковский проведет мастер-класс «Тут всю систему менять надо: чиним сломанные k8s кластеры вместе с сертифицированными слесарями» – сломает десять кластеров и покажет, как их чинить.
Вход на конференцию платный, но по промокоду #RedHat – 37% скидка.
Ждем вас 20 апреля на мастер-класс в Зале #2 в 17:15, и на нашем стенде – весь день. Полезная информация по продуктам, встречи с экспертами, футболки, шляпы, наклейки Red Hat – все как обычно! :-)
Какие инструменты вы сможете получить в свое распоряжение, чтобы создавать более качественные программные продукты, и как они позволят повысить безопасность и сделать разработку проще и надежнее?
С того самого момента как представители только еще формировавшегося сообщества 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 для предоставления инфраструктуры и набор учетных записей для доступа к образам предварительной версии.
- Чтобы начать работу, перейдите на try.openshift.com и нажмите “Get Started”.
- Войдите в свой аккаунт Red Hat (или создайте новый) и следуйте инструкциям, чтобы настроить ваш первый кластер.
После успешной установки, ознакомьтесь с нашими обучающими материалами OpenShift Training, чтобы получить более подробное представление о системах и концепциях, которые делают платформу OpenShift 4 столь простым и удобным инструментом для запуска Kubernetes.
А на конференции DevOpsForum 2019 один из разработчиков OpenShift, Вадим Рутковский проведет мастер-класс «Тут всю систему менять надо: чиним сломанные k8s кластеры вместе с сертифицированными слесарями» – сломает десять кластеров и покажет, как их чинить. Вход на конференцию платный, но по промокоду #RedHat – 37% скидка.
Ждем вас 20 апреля на мастер-класс в Зале #2 в 17:15, и на нашем стенде – весь день. Полезная информация по продуктам, встречи с экспертами, футболки, шляпы, наклейки Red Hat – все как обычно! :-)
