Что такое Deis?

What is Deis?

Deis is an open source PaaS that makes it easy to deploy and manage applications on your own servers. Deis builds upon Docker and CoreOS to provide a lightweight PaaS with a Heroku-inspired workflow (источник: Deis - overview).

Давайте посмотрим, что же такое PaaS:

Platform as a service (Deis) is a category of cloud computing services that provides a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app (источник: Wikipedia).

Другими словами, PaaS может брать на себя функции deploy'a приложений, запуск его дополнительных экземпляров. Предоставляет инструменты для конфигурации, централизованного сбора логов и метрик.

Наше знакомство с Deis

Для проекта с микросервисной архитектурой, нам был необходим простой инструмент deploy'a и масштабирования, и мы использовали Deis . Из коробки он поддерживает автоматическое развёртывание кластера на ряде hosting'ов, таких как Amazon, Digital Ocean, etc. Мы использовали AWS и минимальную конфигурацию из трёх серверов (нод). Создание кластера занимает порядка часа, но подготовка и изучение документации отняло куда больше времени.

Так как Deis использует docker для запуска, изоляции и виртуализации приложений, мы могли очень просто подготовить deploy для разных стеков - достаточно было подобрать соответствующий docker-образ для статики (frontend для single page application), Ruby, Ruby on Rails и для Node.js.

Deploy приложения делался обновлением (push-ем) особого git-репозитория кластера. Каждое обновление приложения или конфигурации означает создание новой версии (release) в терминале Deis. Release'ы автоматически хранятся и мы не раз откатывали приложения на предыдущую версию. Это делается всего одной консольной командой.

С Deis действительно очень просто проводить deploy, конфигурацию и масштабировать приложение. Мы долгое время использовали Chef для deploy'a наших приложений, но разворачивание приложения в контейнере сильно облегчает работу. Приложение, конечно, должно соответствовать 12-factor app принципам, которые так пропагандирует Heroku, но это вряд ли можно назвать сложным.

Нам было интересно настроить Continuous delivery самым простым способом с помощью TravisCI. У нас достаточно легко получилось настроить deploy на staging-кластер при каждом обновлении git-репозитория (master-ветки в нашем случае). То есть, после каждого принятого pull-request'а в master мы сразу получали обновлённое приложение на staging-кластере.

Likes

Deis действительно упрощает администрирование серверов и deploy приложений.

Можно удобно и быстро развернуть кластер на AWS. Для разработки кластер можно развернуть даже на локальной машине используя Vargant.

Простое масштабирование в Deis действительно есть - мы легко можем управлять количеством запущенных экземпляров приложения и относительно просто увеличивать количество узлов в кластере.

У Deis хорошая документация. В ней детально описаны настройка и конфигурация кластера, и что показательно - инструкции для устранения возможных проблем.

Deis достаточно активно развивается, регулярно выходят обновления и новые версии (releases). Проект спонсируется Engine Yard, а это сулит ему годы жизни, развития и процветания.

Dislikes

Мы столкнулись с нестабильностью staging-кластера. Регулярно отказывали служебные компоненты платформы, такие как система deploy'a, система логирования и штатные инструменты управления.

Технические детали:
Обычно это было симптомами нехватки свободного места на жестких дисках. Как оказалось - распределённая файловая система, которая должна равномерно заполнять узлы кластера, может успешно забить до отказа один узел, и штатные механизмы контроля Deis это не замечают. В результате отсутствия свободного места на любом из узлов весь кластер становится неуправляемым. Мы не использовали кластер как файловое хранилище, т.е. свободное место на дисках заполнялось служебными данными Deis'a.

Мы пытались бороться с этим разными способами. Один из них - перенос хранилища образов релизов (registry) из кластера на внешний хостинг - Amazon S3. Это помогло существенно увеличить живучесть кластера, но через какое-то время мы снова столкнулись с нехваткой свободного места на диске одной из нод, на которой расположена служба сборок релизов (builder). На этот раз оказалось, что место занимается ненужными образами docker-а, а штатный механизм их удаления не срабатывал. Мы пока не понимаем, что занимает ~90% на HDD в папке докера и в чём причина роста этой папки.

При решении проблем, чтобы разобраться с тем, куда смотреть и на что пенять, пришлось лезть под капот Deis'а (внутри мы обнаружили fleet, etcd, ceph, journal, system...), что потребовало полного погружения и DevOps навыков. Сам Deis написан на смеси Python/Bash/Go, поэтому разбираться с ними было не всегда просто. Когда ничего не получалось исправить, мы просто создавали кластер заново.

Пока не реализованы некоторые важные возможности. Кое-что запланировано на следующий мажорный релиз (v2). Например, сейчас нельзя запустить интерактивную консольную команду на выбранном Docker-контейнере. Неинтерактивные команды поддерживаются, но если надо запустить, скажем, shell/repl, приходится делать много лишнего.

Выводы

Это работает, уже сейчас можно поиграться. Для staging-окружения вполне подходит. Но для production? Вряд ли у кого бы то ни было найдётся столько времени и желания, чтобы бороться с платформой вместо того, чтобы просто использовать её.

Связаться