Pull to refresh

Запускаем приложение в Openshift и сравниваем существующий инструментарий

IT InfrastructureDevOpsKubernetesOpenshift

This is fine


Я хочу рассказать история, как запускали приложение в Openshift. Так же по ходу пьесы рассмотрим утилиты для управления приложением внутри Openshift. Это расшифровка выступления на kubernetes SPB meetup #3..


Цель


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


Для начала надо поговорить про наше приложение. Проект с богатой историей. Используется в больших организациях и вероятно каждый из вас косвенно пересекался. Приложение поддерживает множество баз данных, интеграций итд итп.


Пререквизиты


Deploy


Приложение должно работать в совершенно разных окружениях. Как результат наша документация по установке, весьма, обширная. Но если посмотреть свысока, то ничего сложного:


  • Применить схему БД.
  • Настроить сервер приложений.
  • Установить лицензию.
  • Настроить приложение и интеграции с внешними системами.

Deploy


Но мир жесток, у нас был ряд ограничений:


  • Приложение можно собирать только на специально Jenkins, который занимается подписанием. И только там.
  • Нет доступа из клиентского Openshift в окружение для разработки.
  • По ряду идеологических причин Не было возможности переиспользовать существующие Docker образы для разработки.
  • У нас есть ansible playbooks для установки и настройки приложения на серверах.

Ansible-container demo


Ansible-container


Ansible container это открытое программное обеспечение, которое преследует цель автоматизации сборки контейнеров, деплоя и управления процессом. Как можно догадаться из названия. для сборки контейнеров используется Ansible. У нас уже были написано Ansible роли для инсталляции и развертывания приложения поверх серверов, так что мы решили не изобретать велосипед и переиспользовать их. Не то что бы это идеальный инструмент, но быстрое переиспользование существующих ролей оказалось решающим фактором для демо.


По большому счету, что бы сделать сделать демо мы взяли существующие роли, настраивающие всё и вся, и сделали "монолитный контейнер". Что собрать контейнер не было особых проблем, т.к. у Openshift есть замечательные рекомендации, но отдельно отмечу:


  • Роли было необходимо было доработать, т.к. мы используем systemd.
  • По умолчанию, в целях безопасности в openshift запрещено использовать некоторые syscall. Как следствие будут нюансы с chroot, sudo. Привет CVE-2019-5736.
  • Аналогично из соображений безопасности контейнер запускается из под пользователя со случайным ID, это так же настраиваемое поведение.

Основная идея в этом пункте, что мы сделали демо ооочень быстро.


Multiple containers demo


Multiple containers


Демо контейнер выполнил свою роль и мы распилили его на отдельные составляющие:


  1. Наше приложение.
  2. База данных.
  3. Внешние сервисы итд...

Multiple containers


Первое с чем столкнулись, как инициализировать базу данных? Понятно что используем миграции, но когда и как их применять? Тут стоит дать ссылку на замечательную статью описывающие устройство POD: PODs life. По большому счету есть несколько подходом:


  • Использовать init-container
  • Использовать системы оркестрации, которые определят порядок развертывания сервисов и накатят миграции когда надо.

Мы решили пойти по пути Init-container. Т.е. в POD нашего приложение, до старта нашего приложения, стартует контейнер, который катит миграции. Но как сконфигурировать само приложение и внешние интеграции?


Initialize the application


Multiple containers


Как я уже упоминал, наше приложение может и должно работать совершенно в разных окружениях, с разными БД и интеграциями. Опять же вопрос, как это все настраивать?


  • Использовать системы оркестрации, которые определят порядок развертывания сервисов и применять конфигурацию после старта приложения.
  • Передавать через переменные окружения контейнеру как настроиться.
  • Использовать start hook.
  • Сделать отдельный контейнер, который содержит конфигурацию и применит ее к приложению. Грубо аналог миграция для БД.

Мы выбрали последний подход, т.к. он позволяет делать конфигурацию воспроизводимой и самодостаточной. Только зачем-то изначально сделали этот контейнер в отдельном replication controller с фактором 1.


Multiple containers


Ок, почитаем документацию снова.


A pod (as in a pod of whales or pea pod) is a group of one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers.

POD это группа контейнеров. В итоге наш под состоял из 3 контейнеров


  1. Init container для инициализации a PostgreSQL.
  2. Контейнер с приложение.
  3. Контейнер с конфигурацией приложения.

Инструментарий


У нас получилась схема как выглядит приложение развернутое. Теперь настало время обсудить инструментарий в природе существует много уже готового, я рассмотрю некоторые из списка ниже и сделаю субъективные выводы.



Openshift templates


Openshift templates


Openshift templates


Плюсы:


  • Нативно и у них отличная документация.

Минусы:


  • Еще один шаблонизатор.
  • Длинные и ужасные YAML файлы.
  • Если у вас есть зависимости между сервисами и их очередностью старта, то будет сложно.

Scripts and template


Custom scripts


Плюсы:


  • Можете использовать отличные инструменты и всю мощь ООП.

Минусы:


  • Костыли, которые поддерживать. И не только вам.

Terraform k8s provider


Terraform k8s provider


Terraform k8s provider


Плюсы:


  • Вы не беспокоитесь об очередности создания элементов инфраструктуры.
  • Можно переиспользовать код инфраструктуры как модули.
  • Можно добавить логику инициализации приложения.

Минусы:


  • Нет поддержки Openshift, только k8s.
  • Иногда устаревшая дока и модули.
  • Еще одна тула в вашей команде.

Ansible-container


Ansible-container


Ansible-container


Плюсы:


  • Make CM, no bash
  • Можно переиспользовать код в виде ролей.
  • В нашем случае один инструмент для всего.

Минусы:


  • Огромные образы, т.к. идут одним слоем.
  • Выглядит покинутым и не поддерживаемым. Был заменен Ansible bender.

Ansible k8s module


Ansible k8s module


Ansible + k8s module


Плюсы:


  • Один плэйбук для описания все инфраструктуры проекта внутри Openshift.
  • Переиспользование кода в виде ролей.
  • Можно добавить логику инициализации приложения.

Минусы:


  • Нет поддержки прокси.
  • Вы заботитесь об удаление. Если объект больше не нужен надо описать его удаление.
  • Вы сами описываете очередность создания элементов инфраструктуры.

Ansible Playbook Bundle


Ansible Playbook Bundle


Утилита Ansible Playbook Bundle (APB) предлагает подход: а давайте запакуем ansible роли для развертывания приложения внутри k8s/openshift в контейнер и будем запускать внутри k8s/openshift.


Плюсы:


  • Всё свое ношу с собой.
  • Тестируемо и воспроизводимо.
  • Интеграция с Service catalogue(дружелюбный веб интерфейс для запуска приложений).

Минусы:


  • Вам нужны привилегии уровня администратора.
  • Документация иногда оставляет желать лучшего.

Result


Result


Не хочется быть последний инстанцией, но поделюсь своими умозаключениями:



P.S.


Only registered users can participate in poll. Log in, please.
Что вы используете?
47.83% Openshift templates 11
26.09% bash/python/ruby + yml templates 6
0% Terraform k8s provider 0
0% Ansible-container 0
4.35% Ansible Playbook Bundle 1
21.74% helm 5
8.7% Ansible + k8s module 2
23 users voted. 15 users abstained.
Tags:devopsopenshiftansibleansible-containerterraformansible playbook bundlekubernetes
Hubs: IT Infrastructure DevOps Kubernetes Openshift
Total votes 9: ↑9 and ↓0 +9
Views6.9K

Comments 23

Only those users with full accounts are able to leave comments. Log in, please.

Popular right now

DevOps инженер
from 180,000 ₽DialogМоскваRemote job
DevOps Engineer
from 250,000 to 300,000 ₽ZAVOD GamesМосква
DevOps инженер
from 150,000 to 300,000 ₽Sportmaster LabМоскваRemote job
Middle-Senior DevOps Engineer
from 140,000 to 300,000 ₽SolvevaСанкт-ПетербургRemote job
DevOps-инженер
from 200,000 ₽UnitpayМоскваRemote job