Раз-два и в Docker, или чем хорош Red Hat OpenShift

Все постоянно меняется. Особенно когда дело касается IT. Бывает, меняется эволюционно, бывает, революционно. Иногда топ-менеджмент проникается умными словами типа «эджайл», «бигдата», «блокчейн» и пытается реализовать их (как может). А иногда изменения начинаются снизу, например, с автоматизации и перехода на частые релизы. Этот сценарий уже поинтересней. В этом посте мы разберем, как он реализуется с Red Hat OpenShift по принципам DevOps и CI/CD, с помощью контейнеризации через Docker и управления через Kubernetes . Надеемся, наш опыт будет полезен.

Приведем забавную аналогию. Предположим, у вас родился ребенок. Версия 0. Он обладает базовыми функциями человека — спит, ест, оснащен необходимыми интерфейсами. Правда, пока еще не умеет ими пользоваться.
В классической разработке он останется в этом состоянии до следующего большого релиза 1.0, который состоится, например, года через два. В «1.0» ребенок сможет нас узнавать, сидеть, вставать, издавать какие-то звуки и общаться. Подготовится и техподдержка — родители, бабушки и дедушки — потому что старые приемы перестают работать и надо быстро адаптироваться к «обновленному» ребенку.
Затем начинается подготовка к релизу 2.0, в котором чадо начнет бегать, говорить, конфликтовать на площадках и вообще вести себя очень активно. Техподдержка примет успокоительное и подстроится под новые условия, чтобы быть в строю. Ну и так далее.
Но существуют и другие подходы к разработке, к примеру, дополняющие друг друга DevOps (разработка и операционная деятельность) и CI/CD (непрерывная доставка и интеграция). Суть обоих сводится к появлению частых программных сборок и высокому релизному темпу. В примере с ребенком это означает постоянное развитие (ежемесячное, еженедельное или даже ежедневное). Ребенок будет учиться постепенно, наращивая от релиза к релизу нейронные связи. Он будет делать правильные вещи, неправильные (и тут его легко направить, пояснив, что именно не так). Техподдержка будет догонять релизы, обучаясь вместе и параллельно с продуктом.
Про DevOps и CI/CD написано очень много (особенно на Хабре), поэтому мы не будем сейчас углубляться в методологию. Важно, что эта методология позволяет:
  • не грузить техподдержку (родителей, бабушек и дедушек) одним «большим» взрывом изменений;
  • постепенно наращивать нейронные связи «растущего организма»;
  • вводить быструю интеграцию внутренних минипроцессов друг с другом;
  • без лишних усилий адаптировать «ребенка» к новой среде — выводя его на новый рынок;
  • быстро реагировать на происходящее, оперативно исправлять ошибки, не дожидаясь очередной большой даты;
  • радоваться тому, что вложенные усилия с лихвой оправдывают себя и дают долгожданные плоды.
Чем ускоряться
Представьте, что у вас 20 региональных филиалов. В случае наличия нескольких релизных продуктов и постоянного обновления (те самые десятки минипроцессов, несущие вас в светлое будущее), вы парализуете IT-службу необходимостью постоянной ручной установки и ручным же мониторингом развертывания.
Тут на помощь приходит Docker, который позволяет делать это удобно и быстро.
Docker — открытая программная платформа, обеспечивающая автоматизацию развёртывания и управления приложениями в средах с поддержкой контейнеризации. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре.
В этом случае на помощь приходят шаблоны. Долгое время (до известной книжки Александреску) шаблоны использовались в основном утилитарно. Но пришёл 2001 год и стало понятно, что в спецификации C++, сугубо императивного языка, присутствует тьюринг-полный декларативный язык, имеющий много атрибутов функционального. И понеслась...
Docker предоставляет возможность отделить приложение от инфраструктуры и обращаться с инфраструктурой как с управляемым приложением. Docker помогает быстрее разрабатывать код, быстрее его тестировать, быстрее выкладывать приложения и быстрее возвращаться к чтению Хабра.
Поскольку речь идет о нескольких параллельных релизных ветках, разворачиваемых одновременно в разных филиалах, понадобится инструмент для удобного управления контейнерами. И такой инструмент есть, он называется Kubernetes, и, также как Docker, он является проектом с открытым исходным кодом.
Kubernetes помогает управлять и запускать контейнеры на большом количестве хостов. Кроме того, он обеспечивает совместное размещение и репликацию большого количества контейнеров. Позволим себе процитировать часть подробного хабратопика о Kubernetes, приведенного по ссылке выше:
Проект преследует две цели. Если вы пользуетесь контейнерами Docker, возникает следующий вопрос о том, как масштабировать и запускать контейнеры сразу на большом количестве хостов, а также как выполнять их балансировку. В проекте предлагается высокоуровневый API, который определяет логическое группирование контейнеров, позволяет определять пулы контейнеров, балансировать нагрузку, а также задавать их размещение.
А теперь сделаем еще один логический шаг в сторону удобства и получим Red Hat OpenShift Container Platform — платформу для разработки, развертывания и эксплуатации классических и контейнерных приложений в физических, виртуальных и общедоступных облачных средах. Причем это будет платформа, где максимально упрощены рутинные задачи по сопровождению.
Давайте рассмотрим ее более внимательно. Red Hat OpenShift Container Platform представляет собой платформу для самостоятельной подготовки, сборки и развертывания приложений и их компонентов. Средства автоматизации вроде сборки исходного кода на основе S2I-образов (от source-to-image) упрощают сборку контейнеров Docker на основе кода, извлеченного из системы контроля версий. Объединение с инструментами CI/CD превращает Red Hat OpenShift Container Platform в оптимальное решение для любого бизнеса.
Посмотрим на примерах конкретных кейсов, как это реализовано в жизни:
Один из партнеров Red Hat создает программное обеспечение на аутсорсе для ряда крупных и средних компаний. Работа с ПО ведется как на локальных устройствах, так и в публичных или частных облаках. Из интересного: никогда неизвестно заранее, захочет ли клиент со временем мигрировать в облако или наоборот, вернуться обратно в локал, что накладывает весомый отпечаток на стек используемых технологий. Получается, что в идеале разработка должна вестись в среде, которая позволит безболезненно мигрировать между любыми средами.
На основе платформы Red Hat OpenShift было создано корпоративное решение класса PaaS (платформа как услуга). Это позволило собственным разработчикам быстро создавать и запускать мигрируемые, масштабируемые и готовые к использованию в корпоративных средах приложения для клиентов.
Решение, которое разработала компания, позволило получить ряд важнейших преимуществ перед конкурентами:
  • сократились сроки ввода новых продуктов в продакшн;
  • заметно сократились затраты на разработку и тестирование. Появилась возможность управлять изменениями в режиме, что называется, реального времени;
  • появился контроль работы приложений на уровне кода, благодаря чему служба ИБ теперь может осуществлять анализ и контроль рисков;
  • у пользователей появилась возможность быстро влиять на функциональность и получать максимально гибкие и настроенные под их задачи продукты.
Как говорит сам заказчик: «Теперь мы можем ставить любые эксперименты, на которые у нас раньше просто не было ресурсов. А если что-то не работает — мы движемся дальше без особых потерь».
Выше описана модель OpenShift Container Platform, которая работает на локальном оборудовании заказчика или в сети у сертифицированного облачного провайдера. Помимо такого варианта, доступен сервис OpenShift Online, предлагающий решение в общедоступной облачной службе (к примеру AWS) на основе того же Docker и Kubernetes. Наличие данной службы позволяет сделать 10 вещей:
01) вести разработку сразу на кластере, задействуя его мощности;
10) оптимально регулировать нагрузку на оборудование, подключая/отключая вычислительные мощности в зависимости от текущей нагрузки.
Здесь инженеры обещали шутку про троичную систему, но она будет в следующем релизе.
Если судить по описанному выше примеру, может показаться, что инструмент Red Hat OpenShift нужен и доступен только крупным компаниям. Но это не так. К примеру, у Red Hat существует программа Red Hat OpenShift Startup. Благодаря ей, команды, только начинающие свой бизнес, могут подать заявку и получить 750 долларов в виде кредитов на 6 месяцев для использования платформы Red Hat OpenShift. Этого вполне достаточно, чтобы материализовать свою идею. И именно по такой схеме работали герои следующей истории.
Стартап в области финансовых технологий предложил услуги роботизированного консультанта, автоматически подбирающего стратегии для профессиональных и частных инвесторов. В компании меньше 10 сотрудников (на этот раз число в десятеричной системе), причем никто из них не являлся IT-специалистом в классическом понимании этого слова. Однако, это не помешало им выйти на рынок и почти сразу же получить прибыль.
Как говорят сами разработчики: «Мы — крохотная компания без внешних источников финансирования, поэтому нам было важно сразу, быстро и эффективно начать реализовывать наши идеи. В чем мы действительно хороши, так это в алгоритмах и бизнес-логике. Мы не хотели управлять центром обработки данных, планировать обновления, устанавливать системы управления БД и вот это все. Нам просто надо было работать.»
В результате бизнес-логика и инструменты были написаны на Python и Django. Тестовая среда работает на собственных компьютерах, а рабочая версия — в облаке OpenShift.
Опыт финансового стартапа подтверждает теорию: «Благодаря тому, что тестовая и рабочая среды запущены параллельно, мы можем перенести мелкие изменения в рабочую версию всего за 15 секунд. Ну а более масштабные — внедрить вначале в тестовую среду и понаблюдать за их работой. Учитывая наличия у OpenShift возможности управления версиями, нам легко вести разработку в этих двух ветках. Также стоит отметить, что наличие двух копий данных и кода позволяет сервису быстро восстанавливать работоспособность в случае серьезной аварии».
В примерах выше мы постоянно говорили о работе в разнородных средах. Давайте добавим сюда условие нестабильной работы инфраструктуры и получим третью историю Red Hat.
Еще одна компания — разработчик сервисов для туристической отрасли. В его состав входит более 12 тысяч инфраструктурных устройств, а центр обработки данных справляется с 30 тысячами операций пользователей в секунду.
Туристический бизнес традиционно подвержен форс-мажорам. Поэтому заказчиков партнера интересовали отказоустойчивые приложения, работающие как в локальной среде, так и распределенные между ЦОДами, включая публичные, частные или гибридные облака. Плюс, помимо снижения рисков, клиенты были заинтересованы в повышении скорости работы.
Для перехода на Red Hat OpenShift Container Platform партнер сформировал 6 гибких групп разработчиков, работающих над созданием частной облачной платформы приложений. В результате повысилась общая производительность системы, уменьшились задержки, появилась адаптивность к пиковым нагрузкам. И самое важное, благодаря гибридному размещению, в случае системного или серверного сбоя приложения оперативно разворачиваются в другой части сети.
Резюме
Слоганами о цифровой трансформации IT-директоров пугают. И это сродни тем страхам, которые часто испытывают родители. А всего-то и надо — и в том, и в другом случае, — оставаться адекватными уровню развития технологий (и «технологий») и уметь их использовать. В деле развития IT-инфраструктуры — активнее разрабатывать и внедрять корпоративные приложения, используя мировой опыт — к числу которых относится и платформа Red Hat OpenShift.
Сегодня в списке заказчиков Red Hat — и Amazon, и Marriott, и Dream Works, компании из самых разных областей деятельности и с очень разными задачами. Их выбор объясняется тем, что OpenShift позволяет собрать воедино множество разрозненных процессов внутри компании и вести разработку в соответствии с принципами DevOps и CI/CD. Забыть о революционных подвигах и развивать IT-инфраструктуру эволюционным, а значит, более естественным путем. Сродни развитию живого организма — растущему ежеминутно.
С 2012 года официальным представителем Red Hat в России выступает Axoft. Все это время компания помогала своим партнерам и заказчикам Red Hat находить оптимальные пути цифровизации бизнеса: разрабатывать приложения, внедрять новые разработки. Общее число превысило тысячу и не ограничивается перечисленными выше кейсами. На сайте Axoft можно найти описания этих решений, а также запись недавнего вебинара, в котором рассказывается про OpenShift более подробно. Не стесняйтесь обращаться за консультацией к экспертам Axoft, как в части подбора решений, так и по вопросам технической реализации проектов — www.redhat.axoft.ru.

Комментарии 5

    +15

    От статьи создаётся ощущение, что встретился с sales менеджером и его очередной серебряной пулей. Много эпитетов, утрирований и минимум технических деталей

      +2

      Я сначала познакомился с Kubernetes, а уже потом с OpenShift и у меня только отрицательные впечателния от последнего:


      • Введены свои сущности DeploymentConfig, Route, ImageStream и Релизы
      • Провоцирует на конфигурирование в ручную (oc new-app или oc scale), а не согласно концепции Infrastructure as code (пачкой yaml)
      • Поведение иногда не интуитивное, при ошибке во время деплоя, релиз не откатился, при удалении сломанных ReplicationController-ов автоматом откатилось
      • Надо указывать порты в DeploymentConfig вроде чтоб можно было route пробросить, просто указать порт в Service оказалось не достаточно
      • Встроенный стек логгирования основан на Elastic/Kibana/Fluentd, очень медленно отвечает. У Fluentd очень сложный конфиг, видимо на все случаи жизни.

      UI кончено хорош.

        0
        ничего хорошего в UI, роут нельзя с кнопки создать, надо yaml загружать
        0
        Добавлю минусов:
        1. Нет возможности поставить чистый K8s без Ansible, Jenkins и прочего.
        2. Сама по себе странная идея, что в production будем разворачиваться из исходников.
        3. Довольно низкокачественный Ansible Playbook: если что-то пошло не так, то не исправляется (да и удаление не всегда отрабатывает). Чаще нужно переставлять операционную систему.
        4. Встроенный стек мониторинга — спорный вопрос. Мы еще деплоимся в публичные облака через managed K8s и там такого блока нет. Соответственно, в облаке и OpenShift ставим свой стек. В OpenShift получается 2 установки похожих сервисов — неоптимально.
          0
          Присоединюсь к предыдущим ораторам — моё впечатление от соприкосновения с OpenShift тоже довольно тягостное. Основные детали уже описали до меня.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.