Southbridge corporate blog
29 May 2015

Centos-admin.ru: познаем Ansible

image

Это не готовая инструкция, с большим количеством кода, а скорее описание алгоритма и результатов чего мы добились.

Итак, не так давно у нас появился новый клиент. У него было несколько нетипичных для нас требований: использовать для конфигурирования серверов 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

+9
18.3k 107
Comments 20
Top of the day