Домой Администрирование Управление серверами – Ansible (часть 3)

Управление серверами – Ansible (часть 3)

В в прошлых статьях были описаны обшие концепции и управляющие конструкции. 

Так как часто на серверах есть потребность не в простом копировании файлов, как они есть, а необходимость создать файл под конкретный сервер. Для этого и служат шаблоны.

Шаблоны

Шаблон это файл формата Jinja Template, которые обычно имеют разрешение j2. Детальная информация о шаблонах доступна в документации. Для работы шаблонов используется модуль template. Пример задачи с модулем шаблон:

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

При этом шаблон будет иметь следующий вид:

Важно отметить, что это файл любого формата, как то конфигурационный страница html в оторой вставляются управляющие конструкции jinja, которые при формирования файла заменяются на значения взятые из ansible. 

При работе с переменными есть несколько особенностей. Например возможно задать значение по умолчанию для переменной, если она не будет определена.

Если перменная some_variable не определена, то будет взято значение 5.

Если необходимо, что бы значение по умолчанию задавалось даже в том случае если переменная вычисляется как пустая строка или false, то в этом случае к default добавляется второй параметр true. 

При обработке шаблона необходимо определение всех переменных или задание им значений по умолчанию, если это не так, то будет ошибка. Однако ситуация может потребовать что бы переменная была не обязательной, тогда применяется default(omit).

Есть разные другие фильтры и преобразователи как то to_json, to_yaml, to_nice_json, to_nice_yaml, zip, zip_longest

Вот пример из документации:

Кроме того весьма интересные примеры извлечения значений из JSON данных:

Другой вариант применения является посроение другого запроса:

Есть еще интересная функция urlsplit, которая разделяет url на части, при этом можно получить как комплексный объект в котором есть все части, так и можно получить конкретную часть:

Так же есть способы работать с регулярными выражениями:

Если регулярное выражение ничего не находит, то возвращается пустая строка. Не менее важно наличие еще и функции замены regex_replace, regex_findall. 

Есть еще функции связанные с получением частей пути, как то имя файла, каталога или диск. Это функции dirname, win_dirname, basename, win_basename, win_splitdrive.

Есть фильтры по работе со строками join, split, b64encode, b64decode, quote – соотвественно соединение значений, разбиение строки преобразование в base64 и обратно, а также экранирование.

Роли

Есть еще одна технология ролей (смотри документацию), которая позволяет создавать переносисые шалоны для повтороного использования, вместе с файламт которые необходимы.

В каталоге /etc/ansible создаем каталог roles. Потом в этом каталоге вызваем команду ansible-galaxy init <имя роли>. В результате создатся структура каталогов внутри каталога с именем роли. Структура показана на картинке ниже:

Структура роли

Сами создаваемые файлы пустые. Их стурктура имеет следующие значение:

  • tasks/main.yml – основной список задач которые выполняются в роли.

  • handlers/main.yml – обработчики, которые используются внутри или снаружи роли.

  • library/my_module.py – модули, которые используются в данной роли (см. Embedding modules and plugins in roles для более полной инфорации).

  • defaults/main.yml – переменные по умолчанию для роли (см Using Variables для большей информации). Эти переенные имеют наиболее низкий приоритет чем любые другие переменные и могут быть легко переопределены другими переменными даже темы, что заданы в файле инвентаризации.

  • vars/main.yml – другие переменные для роли (см Using Variables).

  • files/main.yml – файлы которые роль устанавливает.

  • templates/main.yml – шаблоны которые роль устанавливает.

  • meta/main.yml – metadata для роли влючая зависимости.

Таким образом, мы получим разделение плейбука на части, которые будут отнесены в специальные файлы. Возмем плейбук из прошлой части, установка веб сервера. И разнесем его по файлам в соотвествии с назначением. 

Так например переменная dst_path будет вынесена в файл vars/main.yml. (при этом путь к файлам для копирования уже не применяется, так как для файлов отведен специальный каталог files/). Тоже касается и шаблонов для них тоже есть спец каталог – templates/. А обработчики перенесутся в handlers/main.yml. В тоже время все задачи переедут tasks/main.yml.

Таким образом мы получаем файл vars/main.yml будет иметь вид:

Таким образом мы получаем файл handlers/main.yml будет иметь вид:

—
– name: Restart Apache RedHat
    service: name=httpd state=restarted
    when: ansible_os_family == “RedHat”
 
  – name: Restart Apache Debian
    service: name=apache2 state=restarted
    when: ansible_os_family == “Debian”

Таким образом мы получаем файл tasks/main.yml будет иметь вид:

—
  – name: Show linux version
    debug: var=ansible_os_family
 
  – block: # Block for Debian
      – name: HTTP service install (Debian)
        apt: name=apache2 state=latest
 
      – name: Start service and enable on boot (Debian)
        service: name=apache2 state=started enabled=yes
     when: ansible_os_family == “Debian”
 
  – block: # Block for RedHat
      – name: HTTP service install (RedHat)
        yum: name=httpd state=latest
 
      – name: Start service and enable on boot (RedHat)
        service: name=httpd state=started enabled=yes
     when: ansible_os_family == “RedHat”
 
  –  name: Generate config
     template: src=index.j2 dest= {{ dest_path }}
 
  – name: Copy Page on servers
    copy: src={{ item }} dest={{ dst_path }} mode=0555
    loop:
      – file1
      – file2

Получим такус

Что стоит отметить, остуствие путей к файлам, в шаблонах и при копировании, ansible сам знает где брать файлы (они ищутся в соотвествующих каталогах). Происходит такое преобразование:

Для того, что бы использовать роль, нужно указать ее в каком то плейбук:

При этом можно назначить множество ролей. Кроме того, роль можно добавить по условию, как вторая роль в примере.

Информация про роли ищется в каталоге roles, который расположен рядом с файлом плейбук, в пути указанном в файле конфигурации ansible, переменная roles_path, которая имеет значение по умолчанию “~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles”, а также рядом с самим файлом плейбук.

Внешние переменные

Плейбук в примере выше всегда выполняется на всех сервера, и что бы сменить сервера для выполнения, придется изменить файл, сохранить его и снова выполнить. Что не удобно, но такое поведение можно изменить, для этого вместа значения all можно использовать переменную:

ansible-playbook playbook.yml –extra-var “MYSERVERS=all”

Или другой вариант:

ansible-playbook playbook.yml -e “MYSERVERS=all owner=denis”

ВАЖНО: переменные extra-var имеют наивысший приоритет и перезаписывают любые значения, не важно где они были определены.

Include и Import

Посмтрим следующий плейбук:

 

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

Например вынесем в отдельный файл create_directory.yml следующего содержимого:

А содержимое создания файлов в другой файл create_file.yml такого содержимого:

Тогда главный файл будет иметь следующее содержимое:

Основное отличие import от include, в том, что import обрабатывается при парсинге и замещается импортированным содержимым, причем в нем сразу замещаются переменные их значениями. А include вставляется только в момеент выполнения таска и тогда переменные получат значения на момент выполнения (а не описания, как с import). Атрибут name можно не использовать. Можно также передавать переменные:

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

Обсуждение закрыто.