Что в конечном итоге приводит к значительному снижению затрат на протяжении всего жизненного цикла серверного приложения.
Хотя большинство преимуществ Docker верны, те, кто действительно использует контейнеры, могут быть немного разочарованы.
А поскольку Docker — не панацея, а всего лишь включен в список «лекарств» от рецепта автоматического развертывания, разработчикам приходится осваивать дополнительные технологии, писать дополнительный код и т. д. Свой рецепт автоматизации настройки и развертывания контейнеров на различных инфраструктурах мы разрабатывали последние несколько месяцев параллельно с коммерческими проектами.
И полученный результат практически полностью удовлетворил наши текущие потребности в авторазвертывании.
Выбор инструмента
Когда впервые возникает необходимость автоматического развертывания Docker-приложений, первое, что подсказывает опыт (или поисковая система), — попытаться адаптировать его под эту задачу.
Докер Составление .
Изначально Docker Compose задумывался как инструмент для быстрого запуска контейнеров в тестовой инфраструктуре.
в бою .
Еще один вариант, который мы сочли подходящим инструментом, — это Анзибль , включающий в себя модули для работы с контейнеры И изображений Докер.
Но ни то, ни другое решение нас как разработчиков не устроило.
И основная причина этого кроется в способе описания конфигураций — с помощью YAML-файлов.
Чтобы понять эту причину, я задам простой вопрос: кто-нибудь из вас умеет программировать на YAML? Я удивлюсь, если кто-нибудь ответит утвердительно.
Отсюда главный недостаток всех инструментов, использующих для настройки всевозможные варианты разметки (от INI/XML/JSON/YAML до более экзотических, вроде ХКЛ ) — невозможность расширения логики стандартными методами.
Из недостатков также можно отметить отсутствие автозаполнения и возможности чтения исходного кода используемой функции, отсутствие подсказок о типе и количестве аргументов и прочие радости использования IDE. Далее мы посмотрели в сторону Ткань И Капистрано .
Для настройки они используют обычный язык программирования (Python и Ruby соответственно), то есть позволяют писать собственную логику внутри файлов конфигурации с возможностью использования внешних модулей, чего мы, собственно, и хотели.
Мы долго не выбирали между Fabric и Capistrano и почти сразу остановились на первом.
Наш выбор, в первую очередь, определялся наличием экспертизы Python и практически полным ее отсутствием в Ruby. К тому же, это было довольно сложно Структура проекта Капистрано .
В общем выбор пал на Fabric. Благодаря своей простоте, удобству, компактности и модульности он прижился в каждом нашем проекте, позволяя хранить само приложение и логику его развертывания в одном репозитории.
Наш первый опыт написания конфига для автоматического развертывания с помощью Fabric позволил выполнить базовые действия по обновлению приложения на продакшн и тестовой инфраструктуре и позволил сэкономить значительное количество времени разработчиков (отдельного релиз-менеджера у нас нет).
Но в то же время файл настроек оказался достаточно громоздким и его сложно перенести в другие проекты.
Мы подумали, как проще и быстрее решить проблему адаптации конфигов под другой проект. В идеале я хотел получить универсальный и компактный шаблон конфигурации развертывания для стандартного набора существующих инфраструктур (тестовая, Staging, Production).
Например, теперь наши конфиги авторазвертывания выглядят примерно так: fabfile.py
Available commands:
PRODUCTION
STAGING
nginx deploy[:force=no,tag=None,migrate=yes,backup=yes] - backup -> pull -> migrate -> update
nginx.deploy deploy[:force=no,tag=None,migrate=yes,backup=yes] - backup -> pull -> migrate -> update
nginx.pull pull[:tag=None] - pull Docker image from registry
nginx.revert revert - revert Docker container to previous version
nginx.rollback rollback[:migrate_back=yes] - migrate_back -> revert
nginx.update update[:force=no,tag=None] - recreate Docker container
Приведенный пример кода содержит описание нескольких стандартных действий по управлению контейнером, в котором запускается всем известный веб-сервер.
Вот что мы увидим, если попросим Fabric перечислить команды из каталога с этим файлом: потрясающе --список
Available commands:
PRODUCTION
STAGING
nginx deploy[:force=no,tag=None,migrate=yes,backup=yes] - prepare -> push -> backup -> pull -> migrate -> update
nginx.deploy deploy[:force=no,tag=None,migrate=yes,backup=yes] - prepare -> push -> backup -> pull -> migrate -> update
nginx.prepare prepare[:tag=None] - prepare Docker image
nginx.pull pull[:tag=None] - pull Docker image from registry
nginx.push push[:tag=None] - push Docker image to registry
nginx.revert revert - revert Docker container to previous version
nginx.rollback rollback[:migrate_back=yes] - migrate_back -> revert
nginx.update update[:force=no,tag=None] - recreate Docker container
Здесь стоит немного пояснить, что помимо стандартных задач Deploy, Pull, Update и т.д. в списке присутствуют еще задачи PRODUCTION и STAGING, которые при запуске не выполняют никаких действий, а подготавливают среду для работы с выбранными.
инфраструктура.
Без них большинство других задач невозможно выполнить.
Это «стандартное» решение проблемы, связанной с тем, что Fabric не поддерживает явный выбор инфраструктуры для работы.
Поэтому, чтобы запустить процесс развертывания/обновления контейнера с Nginx, например на STAGING, вам необходимо выполнить следующую команду: from fabric import colors, api as fab
from fabricio import tasks, docker
##############################################################################
# infrastructures
##############################################################################
@tasks.infrastructure
def STAGING():
fab.env.update(
roledefs={
'nginx': ['[email protected]'],
},
)
@tasks.infrastructure(color=colors.red)
def PRODUCTION():
fab.env.update(
roledefs={
'nginx': ['[email protected]'],
},
)
##############################################################################
# containers
##############################################################################
class NginxContainer(docker.Container):
image = docker.Image('nginx')
ports = '80:80'
##############################################################################
# tasks
##############################################################################
nginx = tasks.DockerTasks(
container=NginxContainer('nginx'),
roles=['nginx'],
)
Как не трудно было догадаться, за этими строками скрыта почти вся «магия»: fab STAGING nginx
Чао, Фабрисио!
В общем, позвольте представить Фабрисио — модуль, расширяющий стандартные возможности Fabric за счет добавления функционала для работы с Docker-контейнерами.Разработка Fabricio позволила нам перестать думать о сложности реализации автоматического развертывания и полностью сосредоточиться на решении наших бизнес-задач.
Очень часто мы сталкиваемся с ситуацией, когда боевая инфраструктура заказчика имеет ограничения на доступ в Интернет. В данном случае решаем задачу развертывания с помощью частного Docker Registry, работающего в локальной сети администратора (или просто на его рабочем компьютере).
Для этого в примере выше нужно просто изменить тип задачи — DockerTasks на PullDockerTasks .
Список доступных команд в этом случае будет выглядеть так: потрясающе --список nginx = tasks.DockerTasks(
container=NginxContainer('nginx'),
roles=['nginx'],
)
Новые команды подготовить и нажать подготовить, загрузить образ из основного реестра и загрузить его в локальный, откуда туннель изображение поступает в боевую инфраструктуру (команда вытягивания).
Вы можете запустить частный реестр локально, запустив в терминале следующую строку кода: docker run --name registry --publish 5000:5000 --detach --restart always registry:2
Пример со сборкой образа отличается от первых двух аналогично только типом задач — в данном случае это СборкаDockerTasks .
Список команд для задач сборки такой же, как и в предыдущем примере, за исключением того, что команда подготовки вместо загрузки образа из основного реестра собирает его из локальных источников.
Чтобы использовать PullDockerTasks и BuildDockerTasks, на компьютере администратора должен быть установлен клиент Docker. С анонсом публичных бета-версий Docker для платформ MacOS и Windows это уже не такая головная боль для пользователей.
Fabricio — проект с полностью открытым исходным кодом, любой улучшения приветствуются.
При этом мы сами активно продолжаем дополнять его новыми возможностями, исправлять ошибки и устранять неточности, постоянно совершенствуя нужный нам инструмент. На данный момент основными особенностями Fabricio являются:
- создание образов Docker
- запуск контейнеров из образов с произвольными тегами
- совместимость с режимом параллельного выполнения задач на разных хостах
- возможность отката к предыдущему состоянию (откат)
- работа с публичными и частными реестрами Docker
- группировка типовых задач в отдельные классы
- автоматическое применение и откат миграции приложений Django
pip install --upgrade fabricio
В настоящее время поддержка ограничена Python 2.5–2.7. Это ограничение является прямым следствием поддержки соответствующих версий модулем Fabric. Мы надеемся, что в ближайшем будущем Fabric сможет работать на Python 3. Хотя особой необходимости в этом нет — в большинстве дистрибутивов Linux, а также MacOS версия 2 является версией Python по умолчанию.
Буду рад ответить на любые вопросы в комментариях, а также выслушать конструктивную критику.
Теги: #python #docker #DevOps #deploy #redmadrobot #fabric
-
6 Типичных Сюжетов Мировой Литературы
19 Oct, 24 -
Cisco Ucs Глазами Облачного Провайдера
19 Oct, 24
