Lev Goncharov
DevOps Engineer
Запускаем приложение в Openshift и сравниваем существующий инструментарий
Это расшифровка выступления на kubernetes SPB meetup #3 (RU) 2019-02-25 и ITGM #14 (ENG) 2019-03-23.
- Video from k8spb meetup at dell emc 2019-02-25
- k8spb slides
- ITGM slides
- English version
- Russian version
Предыстория
Я хочу рассказать история, как запускали приложение в Openshift. Так же по ходу пьесы рассмотрим утилиты для управления приложением внутри Openshift.
Цель
Обычно клиенты разворачивают на отдельных серверах, но тут пришла задача, прощупать возможность запуска в openshift и пособирать граблей.
Для начала надо поговорить про наше приложение. Проект с богатой историей. Используется в больших организациях и вероятно каждый из вас косвенно пересекался. Приложение поддерживает множество баз данных, интеграций итд итп.
Пререквизиты
Приложение должно работать в совершенно разных окружениях. Как результат наша документация по установке, весьма, обширная. Но если посмотреть свысока, то ничего сложного:
- Применить схему БД.
- Настроить сервер приложений.
- Установить лицензию.
- Настроить приложение и интеграции с внешними системами.
Но мир жесток, у нас был ряд ограничений:
- Приложение можно собирать только на специально Jenkins, который занимается подписанием. И только там.
- Нет доступа из клиентского Openshift в окружение для разработки.
- По ряду идеологических причин Не было возможности переиспользовать существующие Docker образы для разработки.
- У нас есть ansible playbooks для установки и настройки приложения на серверах.
Ansible-container demo
Ansible container это открытое программное обеспечение, которое преследует цель автоматизации сборки контейнеров, деплоя и управления процессом. Как можно догадаться из названия. для сборки контейнеров используется Ansible. У нас уже были написано Ansible роли для инсталляции и развертывания приложения поверх серверов, так что мы решили не изобретать велосипед и переиспользовать их. Не то что бы это идеальный инструмент, но быстрое переиспользование существующих ролей оказалось решающим фактором для демо.
По большому счету, что бы сделать сделать демо мы взяли существующие роли, настраивающие всё и вся, и сделали “монолитный контейнер”. Что собрать контейнер не было особых проблем, т.к. у Openshift есть замечательные рекомендации, но отдельно отмечу:
- Роли было необходимо было доработать, т.к. мы используем systemd.
- По умолчанию, в целях безопасности в openshift запрещено использовать некоторые syscall. Как следствие будут нюансы с chroot, sudo. Привет CVE-2019-5736.
- Аналогично из соображений безопасности контейнер запускается из под пользователя со случайным ID, это так же настраиваемое поведение.
Основная идея в этом пункте, что мы сделали демо ооочень быстро.
Multiple containers demo
Демо контейнер выполнил свою роль и мы распилили его на отдельные составляющие:
- Наше приложение.
- База данных.
- Внешние сервисы итд…
Первое с чем столкнулись, как инициализировать базу данных? Понятно что используем миграции, но когда и как их применять? Тут стоит дать ссылку на замечательную статью описывающие устройство POD: PODs life. По большому счету есть несколько подходом:
- Использовать init-container
- Использовать системы оркестрации, которые определят порядок развертывания сервисов и накатят миграции когда надо.
Мы решили пойти по пути Init-container. Т.е. в POD нашего приложение, до старта нашего приложения, стартует контейнер, который катит миграции. Но как сконфигурировать само приложение и внешние интеграции?
Initialize the application
Как я уже упоминал, наше приложение может и должно работать совершенно в разных окружениях, с разными БД и интеграциями. Опять же вопрос, как это все настраивать?
- Использовать системы оркестрации, которые определят порядок развертывания сервисов и применять конфигурацию после старта приложения.
- Передавать через переменные окружения контейнеру как настроиться.
- Использовать start hook.
- Сделать отдельный контейнер, который содержит конфигурацию и применит ее к приложению. Грубо аналог миграция для БД.
Мы выбрали последний подход, т.к. он позволяет делать конфигурацию воспроизводимой и самодостаточной. Только зачем-то изначально сделали этот контейнер в отдельном replication controller с фактором 1.
Ок, почитаем документацию снова.
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 контейнеров
- Init container для инициализации a PostgreSQL.
- Контейнер с приложение.
- Контейнер с конфигурацией приложения.
Инструментарий
У нас получилась схема как выглядит приложение развернутое. Теперь настало время обсудить инструментарий в природе существует много уже готового, я рассмотрю некоторые из списка ниже и сделаю субъективные выводы.
- Openshift templates
- bash/python/ruby + yml templates
- Terraform k8s provider
- Ansible-container
- Ansible + k8s module
- Ansible Playbook Bundle
- Ansible bender
- operator
- source2image
- kustomize
- helm
- Automation broker
Openshift templates
Плюсы:
- Нативно и у них отличная документация.
Минусы:
- Еще один шаблонизатор.
- Длинные и ужасные YAML файлы.
- Если у вас есть зависимости между сервисами и их очередностью старта, то будет сложно.
Scripts and template
Плюсы:
- Можете использовать отличные инструменты и всю мощь ООП.
Минусы:
- Костыли, которые поддерживать. И не только вам.
Terraform k8s provider
Плюсы:
- Вы не беспокоитесь об очередности создания элементов инфраструктуры.
- Можно переиспользовать код инфраструктуры как модули.
- Можно добавить логику инициализации приложения.
Минусы:
- Нет поддержки Openshift, только k8s.
- Иногда устаревшая дока и модули.
- Еще одна тула в вашей команде.
Ansible-container
Плюсы:
- Make CM, no bash
- Можно переиспользовать код в виде ролей.
- В нашем случае один инструмент для всего.
Минусы:
- Огромные образы, т.к. идут одним слоем.
- Выглядит покинутым и не поддерживаемым. Был заменен Ansible bender.
Ansible k8s module
Плюсы:
- Один плэйбук для описания все инфраструктуры проекта внутри Openshift.
- Переиспользование кода в виде ролей.
- Можно добавить логику инициализации приложения.
Минусы:
- Нет поддержки прокси.
- Вы заботитесь об удаление. Если объект больше не нужен надо описать его удаление.
- Вы сами описываете очередность создания элементов инфраструктуры.
Ansible Playbook Bundle
Утилита Ansible Playbook Bundle (APB) предлагает подход: а давайте запакуем ansible роли для развертывания приложения внутри k8s/openshift в контейнер и будем запускать внутри k8s/openshift.
Плюсы:
- Всё свое ношу с собой.
- Тестируемо и воспроизводимо.
- Интеграция с Service catalogue(дружелюбный веб интерфейс для запуска приложений).
Минусы:
- Вам нужны привилегии уровня администратора.
- Документация иногда оставляет желать лучшего.
Выводы
Не хочется быть последний инстанцией, но поделюсь своими умозаключениями:
- Если не планируете предоставлять приложение как сервис то Ansible k8s module ваш выбор.
- Но если оно вам надо, то надо копать про automation broker и Ansible Playbook Bundle.