Это не готовая инструкция, с большим количеством кода, а скорее описание алгоритма и результатов чего мы добились.
И так, не так давно у нас появился новый клиент. У него было несколько не типичных для нас требований: использовать для конфигурирования серверов ansible, контент сайта хранится в git, каждый сайт находится на своей виртуальной машине. Все это не сулило ничего хорошего, так как совсем не укладывалось в стандартную схему. «Клиент всегда прав!» и мы начали разрабатывать новую схему. Но обо всем по порядку.
Исходные данные: есть клиент, у которого более 30 сайтов которые надо перенести на нашу площадку. Каждый сайт должен располагаться в отдельном контейнере (мы используем OpenVZ контейнеры). Используется только один внешний IP. Для конфигурирования серверов используется ansible. Для каждого сайта есть архив с конфигурационными файлами. Контент сайта находится в git.
И мы начали творить… Что у нас получилось, можно посмотреть подкатом. Забегая в перед скажу, разворот нового сайта сводится к нескольким командам.
У нас есть несколько шаблонов для разворачивания новых контейнеров, в виде архивов. Для начала мы внесли некоторые изменения в эти шаблоны, а точнее добавили пользователя ansilble и ключи. Это позволило сразу после разворота, без дополнительных действий настраивать контейнер с помощью ansible.
В ansible у нас было создано несколько ролей, не буду описывать их все, только про самые интересные:
- create_vm
- content_update
create_vm это роль которая собственно и создает вм и и конфигурирует ее.
Чуть подробнее.
Эта роль применяется к хостовой машине на которой будет установлен контейнер. Сразу оговорюсь, везде активно используются host_vars. У хостовой машине в host_vars, есть только одна переменная vm_number. Эта переменная содержит номер последнего контейнера +1, после выполнения playbook этот номер будет увеличен на 1. Так же в playbook для это роли используются «vars_promt». Это первое, что нам показалось интересным и мало где описанный механизм. vars_promt позволяет интерактивно задавать переменные при выполнении playbook и в дальнейшем к этим переменным можно обращаться в шаблонах, заданиях и тд. Мы вынесли в эти переменные такие, уникальные данные для каждого сайта, как имя сайта, репозитарий git (где хранится контент сайта) и адрес где расположены конфигурационные файлы для сайта.
Получилось примерно так:
<spoiler title="new_vm.yml"> - name: Create new vm hosts: ds remote_user: ansible sudo: true roles: - new_vm vars_prompt: conf_url: "Введите url c архивов конфигов который приложен к заданию" area_fqdn: "Введите имя сайта" git_repo: "Введите адрес git репозитария" </spoiler> Описание самих тасков приводить не буду, так как получились достаточно длинными. Если кому-то будет интересно можем прислать.
А дальше все очень просто, ansible подключается к хосту, выкачивает архив шаблона, проверяет что вм с таким номером нет и создает вм, задает ей IP и имя, на этом все процедуры на хосте заканчиваются.
Дальше очень полезным оказался модуль ansible local_action, который позволяет выполнять действия на хосте откуда запускается playbook. Asible выкачивает файлы конфигурации для сайта (nginx, apache и т.д.), по ссылке которую мы задаем в интерактивной переменной, создает структуру каталогов в ansible, добавляет новый контейнер к ролям в ansible и раскладывает конфиги. А так же создается host_vars для нового контейнера, в которых задается имя сайта и git репозитарий, это пригодится в дальнейшем, это нам потребуется в дальнейшем. На этом создание контейнера закончено.
Как было сказано в начале, есть только один белый ip для всех сайтов. Не проблема, был создан контейнер с проксирующим nginx. Для новых контейнеров надо добавлять правила проксирования. И тут нам на помощь пришли шаблоны и все те же интерактивные переменные. Так же локально из шаблона создаётся файл конфигурации прокси для нового контейнера.
Ага, уже неплохо. Запустив playbook у нас создается контейнер со всеми настройками. Но на этом мы не останавливаемся. И добавили еще выгрузку контента из репозитария. За это как раз и отвечает роль content_update.
Вкратце о роли content_update. Ansible делает клон git репозитария и потом с помощью скрипта раскладывает контент сайта в нужные директории с нужными правами. На этом собственно подготовка контейнера почти закончена, остается запустить playbook для применения конфигурации для нового контейнера и все, контейнер можно передавать заказчику.
Автор: системный алминистратор компании Magvai69
ссылка на оригинал статьи http://habrahabr.ru/post/259107/
Добавить комментарий