В этой первой части рассмотрены следующие темы:
— конфигурационный файл Ansible, Inventory-файл
— полезные команды Ansible
— теги
— переменные
— Ad-Hoc-режим
— модули
— debug в Ansible
Во второй части рассмотрены следующие темы:
— роли
— import/include
— выполнение задачи на другом сервере(delegate_to)
— однократное выполнение задачи (run_once )
— перехват и обработка ошибок(ignore_errors|any_errors_fatal)
— помещение вывода выполнения команды таска в переменную(register,failed_when)
— условия выполнения таска( when)
— Ansible Vault
Конфигурационный файл Ansible, Inventory-файл
Просмотр версии Ansible и используемого конфигурационного файла Ansible
1 |
# ansible --version |
1 2 3 |
ansible 2.7.9 config file = /etc/ansible/ansible.cfg … |
Конфигурационный файл Ansible(ansible.cfg) может располагаться в разных местах и соответственно иметь разный приоритет для Ansible
Ниже представлен список мест, откуда Ansible может читать свой конфигурационный файл в порядке наиболее приоритетного к наименее приоритетному
1. Расположение файла определено переменной окружения $ANSIBLE_CONFIG
2. Файл ansible.cfg в корне каталога с проектом(в текущей директории)
3. Файл .ansible.cfg в домашнем каталоге пользователя ~/.ansible.cfg
4. Глобальный/общий файл /etc/ansible/ansible.cfg
Полезно использовать отдельный ansible.cfg файл для проекта, помещая его в корневой каталог проекта, путем копирования из глобального файла /etc/ansible/ansible.cfg и изменяя необходимые параметры(например, расположение ролей и инвентори-файла)
Проверка используемого inventory-файла
1 |
# grep ^#inventory /etc/ansible/ansible.cfg | head -n 1 |
1 |
#inventory = /etc/ansible/hosts |
Указание Inventory файл в конфиге Ansible вместо указывания inventory-файла в командной строке
1 2 |
[defaults] inventory = /etc/ansible/hosts |
Inventory-файл можеть бать определен в следующих местах:
1. В переменной окружения $ANSIBLE_HOSTS
2. Параметром -i при запуске ansible или ansible-playbook
3. В кофигурационном файле ansible через параметр inventory
Отключение предложения по добавлению ключей SSH в файл known_hosts(проверка host fingerprint)
1 |
# nano /etc/ansible/ansible.cfg |
1 |
host_key_checking = False |
Альтернативным вариантом является установка переменной
1 |
ANSIBLE_HOST_KEY_CHECKING=False |
Добавление хоста в inventоry-файл
1 |
# cat /etc/ansible/hosts |
1 2 |
[kub] kub.mydomain.com ansible_host=174.174.174.174 ansible_user=root ansible_port=2233 ansible_ssh_private_key_file=/root/.ssh/id_rsa |
На управляемой ноде необходимо установить python, а также пакет python-apt(python интерфейс к libapt-pkg)
1 |
# apt-get update && apt-get install python python-apt |
Проверка доступности хоста по icmp-протоколу
1 |
# ansible -m ping kub |
Если нужно выполнить команду/playbook для всех серверов, тогда используем дефолтную группу all
1 |
# ansible all -m ping |
По умолчанию все сервера входят в группу all
Все сервера, которые не принадлежат какой-либо группе, по умолчанию входят в группу ungrouped
Т.е. каждый сервер, как минимум, входит в 2 группы(all + ungrouped/group_name)
Если команду необходимо выполнить локально(на самом Ansible-сервере), то в inventory-файл добавляем опцию ansible_connection со значением local для Ansible-мастера
1 |
# grep -A1 localhost /etc/ansible/hosts |
1 2 |
[localhost] 127.0.0.1 ansible_connection=local ansible_port=2233 |
1 |
# ansible localhost -m ping |
1 2 3 4 |
127.0.0.1 | SUCCESS => { "changed": false, "ping": "pong" } |
Полезные команды Ansible
Проверка синтаксиса playbook-а (опция —syntax-check)
1 |
# ansible-playbook myplaybook.yml --syntax-check |
Имитация выполнения плейбука(dry-run режим) без его фактического выполнения(опция —check).Полезно посмотреть/проверить что и на каких серверах будет изменено при выполнении этого плейбука
В этом режиме Ansible не будет вносить никаких изменений на вашем хосте, а просто сообщит, какие изменения будут сделаны, если бы плейбук был запущен без этого флага.
Важно помнить,что это может не работать должным образом, если ваших задачах используются условия.
1 |
# ansible-playbook myplaybook.yml --check |
Теги
Выполнение ТОЛЬКО задач с определенным тегом(опция —tags)
1 |
# ansible-playbook myplaybook.yml --tags "my-root-user-key" |
Предварительно необходимо установить тег на таске
1 2 3 4 5 6 7 |
- name: set authorized key for root user took from file authorized_key: user: root state: present key: "{{ lookup('file', 'files/ssh_keys/root-user.pub') }}" tags: - my-root-user-key |
Если несколько тегов необходимо установить, то используем формат
1 2 3 4 |
… tags: - my-root-user-key - my-seсond-tag-name |
Запуск плейбука с указанием нескольких(например, двух) тегов имеет вид
1 |
# ansible-playbook myplaybook.yml --tags "my-root-user-key,my-seсond-tag-name" |
Запуск плейбука без выполнения определенных тасков, отмеченных тегом
1 |
# ansible-playbook myplaybook.yml --skip-tags "my-root-user-key" |
Просмотр списка доступных в плейбуке тегов
1 |
# ansible-playbook myplaybook.yml --list-tags |
Также теги можно навешивать и на роли, таски, плейбуки
Например, для ролей
1 2 3 4 5 |
roles: - { role: webserver, port: 5000, tags: web } Или несколько тегов roles: - { role: webserver, port: 5000, tags: [ 'web', 'foo' ] } |
На плейбуки
1 2 3 4 5 6 |
--- - hosts: kub … tags: - frontend - www |
Hosts-шаблоны
Все хосты в группе app
1 |
- hosts: app |
Все хосты, за исключением хостов в группе web
1 |
- hosts: 'all:!web' |
Все хосты, которые находятся в группах lb или db
1 |
- hosts: 'lb:db' |
Выполнение плейбука на конкретном хосте(опция —limit )
1 |
# ansible-playbook myplaybook.yml --limit my-hostname |
Выполнение плейбука на нескольких хостах(опция —limit)
1 |
# ansible-playbook myplaybook.yml --limit my-hostname1: my-hostname2: my-hostname3 |
Выполнение плейбука на определенном хосте и только определенной роли/таска с указанным тегом
1 |
# ansible-playbook myplaybook.yml --limit my-hostname --tags "my-root-user-key" |
Просмотр спиcка хостов, на которых будет выполняться плейбук
1 |
# ansible-playbook myplaybook.yaml --list-hosts |
Просмотр списка всех тасков, которые будут выполнены
1 |
# ansible-playbook myplaybook.yaml --list-tasks |
Просмотра списка всех тасков, которые будут выполнены, в которых есть указанных тег
1 |
# ansible-playbook myplaybook.yaml --tags "my-root-user-key" --list-tasks |
Просмотр списка всех хостов, на которых будут выполнены таски, выполняющееся для группы kub
1 |
# ansible-playbook myplaybook.yaml --limit kub --list-hosts |
Пошаговое выполнение каждого таска в плейбуке с необходимостью подтверждения об выполнении или пропуске выполнения каждого таска
Это позволит вам выбирать, хотите ли вы выполнить задачу ( y ), пропустить ее ( n ) или ( c ) продолжить не спрашивая.
1 |
# ansible-playbook myplaybook.yaml --step |
Переменные
Inventory-переменные
Спиоск inventory-переменных для всех хостов
1 |
# ansible-inventory --list |
Или вывод в формате yaml
1 |
# ansible-inventory --list --yaml |
Список inventory-переменных для конкретного хоста(например,хоста с именем kub)
1 |
# ansible-inventory --host=kub |
1 2 3 4 5 6 7 8 |
{ "ansible_host": "174.174.174.174", "ansible_port": 2233, "ansible_ssh_private_key_file": "/root/.ssh/id_rsa", "ansible_user": "root", "message": "Hello", "owner": "myuser" } |
Часть этих переменных(ansible_host, ansible_user, ansible_port, ansible_ssh_private_key_file,owner) указана в inventory-файле для этого хоста
1 |
# grep kub /etc/ansible/hosts |
1 2 |
[kub] kub.mydomain.com ansible_host=174.174.174.174 ansible_user=root ansible_port=2233 ansible_ssh_private_key_file=/root/.ssh/id_rsa owner=myuser |
А переменная «message» указана для группы other, в которую входит группа kub, в которую входит хост kub
1 |
# cat /etc/ansible/hosts |
1 2 3 4 5 6 7 |
… [other:children] webservers kub [other:vars] message=Hello |
Построение дерева/графика inventory
1 |
# ansible-inventory --graph |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
@all: |--@localhost: | |--127.0.0.1 |--@other: | |--@kub: | | |--kub.mydomain.com | |--@webservers: | | |--ubuntu161.mydomain.com | | |--ubuntu162.mydomain.com |--@ungrouped: |--@web1: | |--ubuntu161.mydomain.com |--@web2: | |--ubuntu162.mydomain.com |
Аналогично,но с выводом переменных
1 |
# ansible-inventory --graph --vars |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
@all: |--@localhost: | |--127.0.0.1 | | |--{ansible_port = 2233} |--@other: | |--@kub: | | |--kub.mydomain.com | | | |--{ansible_host = 174.174.174.174} | | | |--{ansible_port = 2233} | | | |--{ansible_ssh_private_key_file = /root/.ssh/id_rsa} | | | |--{ansible_user = root} | | | |--{owner = myuser} | |--@webservers: | | |--ubuntu161.mydomain.com | | |--ubuntu162.mydomain.com | | |--{ansible_port = 2233} | | |--{environment = PRODUCTION} | |--{message = Hello} |--@ungrouped: |--@web1: | |--ubuntu161.mydomain.com |--@web2: | |--ubuntu162.mydomain.com |
Рекомендуется не использовать переменные в inventory-файле, а выносить в отдельный каталог с именем
group_vars – для определения групповых переменных(т.е. переменные будут доступны для всех хостов, включенных в эту группу)
Внутри каталога group_vars создаются файлы с названием группы, к хостам которой необходимо применить эту переменную
host_vars – для определения переменных для конкретного хоста
Внутри каталога host_vars создается файл с названием хоста, к которому необходимо применить переменную
Каталоги group_vars/host_vars необходимо создавать на одном уровне с inventory-файлом если предполагается использования команд типа ansible, ansible-console и т.д.
Каталоги group_vars/host_vars необходимо создавать на одном уровне с файлом плейбуком, если предполагается использования команды ansible-playbook
Если одна и та же переменная определена и для группы и для хоста, то приоритет имеет переменная, определенная для хоста.
Список переменных, отсортированный в порядке от минимального до максимального приоритета
1 2 3 4 |
• all группа (родитель всех остальных групп) • родительская группа • дочерняя группа • хост |
Например, выполним перенос переменных из файла inventory в отдельный файл в каталоге group_vars для группы webservers
Например, в inventory-файле содержится
1 2 3 |
[webservers:vars] ansible_port=2233 environment=PRODUCTION |
1 |
# mkdir /etc/ansible/group_vars |
Внутри этого каталога создадим файл с именем группы(webservers)
1 |
# nano /etc/ansible/group_vars/webservers |
1 2 3 |
--- ansible_port: 2233 environment: PRODUCTION |
Закомментируем переменные для этой группы в файле inventory
1 |
# nano /etc/ansible/hosts |
1 2 3 |
#[webservers:vars] #ansible_port=2233 #environment=PRODUCTION |
Проверяем наличие переменных у всех хостов в группе webservers
1 |
# ansible-inventory --list --yaml |
Типы переменных в Ansible:
1. Переменные определенные/заданные пользователем
2. Автоматически собранные переменные – facts ( по умолчанию в каждом плейбуке первым таском запускается сбор фактов с помощью модуля setup, который и собирает всю инфу с целевого хоста, в результате чего становятся доступным множество переменных типа ansible_ значения которых наполняется после сбора fact-ов). Если в сборе фактов не необходимости(например, не используются переменные, получаемые из фактов или просто не нужна никаая информация о хосте), то можно отключить сбор фактов. Для плейбука достаточно добавить строку gather_facts: no на том же уровне,где находится tasks
3. Локальные факты(facts.d). Пользователь может разместить файл/ы с именами *.fact на целевой машине в каталоге /etc/ansible/facts.d/ и переменные указанные в этих .fact-файлах будут доступны при обработке gathering facts, как ansible_local
4. Magic-переменные.
Имена таких переменных зарезервированы Ansible-ом. Наиболее используемые magic-переменные:
рostvars, groups, group_names, inventory_hostname
Более подробно о magic-переменных:
https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#accessing-information-about-other-hosts-with-magic-variables
Пример локальных переменных
Например, на целевом хосте размещаем файл
1 |
# cat /etc/ansible/facts.d/custom.fact |
1 2 3 4 5 6 7 8 9 |
[packages] ftp_package = vsftpd db_package = mariadb-server web_package = apache2 [services] ftp_service = vsftpd db_service = mariadb web_service = apache2 |
С управляющей ноды проверяем доступность локальных переменных
1 |
# ansible kub -m setup -a "filter=ansible_local" |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
kub.mydomain.com | SUCCESS => { "ansible_facts": { "ansible_local": { "custom": { "packages": { "db_package": "mariadb-server", "ftp_package": "vsftpd", "web_package": "apache2" }, "services": { "db_service": "mariadb", "ftp_service": "vsftpd", "web_service": "apache2" } } } }, "changed": false } |
И эти перменные доступны в templat-ах/playbook-ах
Например, значение переменной db_package доступно через
1 |
{{ ansible_local['custom']['packages']['db_package'] }} |
Переменные могут быть определены и переопределены в нескольких местах
Список мест, где могут быть определены переменные, отсортированный в порядке наиболее приоритетных
1 2 3 4 5 6 7 8 9 |
1.Переменные определенные в командной строке( с помощью опции –e/--extra-vars, например -e "key=value") 2.Переменные подключенные через include_params 3.Переменные подключенные через include_vars 4.Переменные определенные в roles/<role_name>/vars/main.yml 5.Переменные определенные в файлах в каталоге host_vars(переменные для хоста имеют больший приоритет, чем переменные для группы, в которую входит данный хост) Переменные хоста определенные в inventory-файле 6.Переменные определенные в файлах в каталоге group_vars(переменные в дочерних группах имеют приоритет над переменными в родителських группах ) Переменные группы определенные в inventory-файле 7.Переменные определенные в role defaults (defaults каталог внутри каталога с ролью) |
Полный список переменных отсортированный менее приоритетного к более приоритетному доступен по ссылке
https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#ansible-variable-precedence
В ролях переменные могут определяться как переменные по умолчанию(общие для всех) ( в файле roles//defaults/main.yml), а также более специфичные/конкретные/приоритетные в файле roles/<role_name>/vars/main.yml
Полезно разделять переменные по окружениям(dev,staging,prod)
Например, структура директорий может иметь вид
ansible/
# Групповые (общие) переменные
1 2 3 4 5 6 7 8 9 10 11 12 13 |
- group_vars/ - all/ - common - secret - dev/ - common - secret - stage/ - common - secret - prod/ - common - secret |
# Переменные отдельных хостов (частные)
1 2 3 4 5 6 7 8 9 10 |
- host_vars/ - appserv-01.example.com/ - common - secret - dbserv-01.example.com/ - common - secret - cdn-01.example.com/ - common - secret |
Общие переменные для всех групп указываются в файлах в каталоге group_vars/all
Переменные для всех хостов в группах определенных окружений соответственно в файлах group_vars/{dev,stage,prod}
Переменные для конкретных хостов указываются в файле в каталоге host_vars/{hostname}
Каждая группа и каждый хост могут иметь набор переменных в разных файлах (например common, secret).Названия файлов в директориях здесь не важны, главное чтобы имя директории совпадало с именами (группы или хоста) в соответствующем inventory. Заводить директорию для группы или единичного хоста не обязательно, можно просто создать файл и записать в нем все необходимые переменные. Однако такая структура каталогов позволяет хранить пароли в шифрованном виде (не хеши, а именно пароли), отдельно от общих переменных и в последствии использовать ansible-vault для шифрования значения переменных, содержащих sensitive-данные.
Определим переменную в плейбуке и потом выведем ее значение
1 |
# nano /etc/ansible/test-playbook.yaml |
1 2 3 4 5 6 7 8 9 |
--- - hosts: localhost vars: http_port: 8080 tasks: - name: print port number debug: msg: "Port number: {{http_port}}" |
Переменные в плейбуках могут определяться непосредственно или через подключение дополнительного файла с переменными с помощью опции vars_files
Это дополнительный файл с переменными указывается относительно пути плейбука и должен быть создан в формате YAML
1 2 3 4 5 6 7 8 9 10 11 |
- name: Test include variables hosts: kub vars: myvar1: qa vars_files: - my_vars.yml tasks: - name: Print variables debug: msg: "Our variables: {{ myvar1 }} {{ myvar2 }} {{ myvar3 }}" |
1 |
# cat my_vars.yml |
1 2 |
myvar2: dev myvar3: prod |
Определение переменных с командной строки (—extra-var/-e)
С командной строки передадим переменную MYHOSTS, которая используется в плейбуке и определяет хосты, на которых необходимо выполнить плейбук
(Более элегантный/правильный способ для изменения хостов, на которых должен выполняться playbook является указание опции -l при запуске плейбука)
1 |
# nano ansible-install-configure-apache-multi-os-loop-jinja2-role.yml |
1 2 3 4 |
--- - name: install default Apache web server and configure default page # hosts: kub hosts: "{{ MYHOSTS }}" |
Запуск плейбука выполняется с передачей переменной MYHOSTS
1 |
# ansible-playbook ansible-install-configure-apache-multi-os-loop-jinja2-role.yml --extra-var "MYHOSTS=kub" |
Проверим, что приоритет переменной, заданной с командной строки больше, чем приоритет переменной, указанной, например, в inventory-файле
Например, зададим переменную owner для хоста в inventory-файле
1 |
# grep owner /etc/ansible/hosts |
1 |
kub.mydomain.com ansible_host=174.174.174.174 ansible_user=root ansible_port=2233 ansible_ssh_private_key_file=/root/.ssh/id_rsa owner=myuser |
При выполнении плейбука с передачей уже существующей/определенной переменной(owner) с помощью —extra-var переопределим эту переменную, присвоив ей другое значение(myuser1)
1 |
# ansible-playbook ansible-install-configure-apache-multi-os-loop-jinja2-role.yml --extra-var "MYHOSTS=kub owner=myuser1" |
Переменные в Ansible доступны с помощью двойных фигурных скобок {{ variable_name }}
Если переменная используется как первый элемент значения, тогда ее обязательно необходимо обрамлять в двойные кавычки
1 2 3 4 |
tasks: - name: Сreate the user {{ user }} user: name: "{{ user }}" |
Ad-hoc-режим
Синтаксис Ad-hoc режима
1 |
# ansible <target> -m <module_name> -a <module_arguments> |
По умолчанию ansible будет подключаться к удаленным хостам по ssh под пользователем, под которым выполняется текущая команда ansible
Для подключения под отличным от текущего пользователя, необходимо использовать опцию -u
Альтернативным вариантом является указание пользователя в inventory-файле в переменной ansible_user для хоста/группы.
Также в конфигурационном файле ansible.cfg есть параметр remote_user, который можно использовать для этих целей
1 |
# grep remote_user /etc/ansible/ansible.cfg |
1 |
#remote_user = root |
В плейбуках также можно определять данную опцию remote_user, которая имеет приоритет над определенной в глобальном/общем файле конфигурации(/etc/ansible/ansible.cfg)
Для того, чтобы под текущим пользователем(например, myansibleuser) подключиться на управляемую машину для выполнения команд необходимо
1.Настроит беспарольный SSH-доступ(по приватным ключам) с Ansible управляющего хоста на управляемую ноду
1 |
# ssh-keygen -t rsa -b 4096 |
1 |
# ssh-copy-id myansibleuser@ip-of-ansible-client |
2.Предоставить пользователю myansibleuser повышать свои привилегии до root-пользователя с помощью sudo на управляемом хосте
1 |
# nano /etc/sudoers.d/myansibleuser |
1 |
myansibleuser ALL=(ALL) NOPASSWD: ALL |
3.Настроить/проверить(по умолчанию эти опции также используются) возможность повышать привилегии до root-пользователя в конфигурационном файле Ansible — ansible.cfg
1 |
# grep -A4 privilege_escalation /etc/ansible/ansible.cfg |
1 2 3 4 5 |
[privilege_escalation] #become=True #become_method=sudo #become_user=root #become_ask_pass=False |
Модули
Просмотр доступных модулей в Ansible
1 |
# ansible-doc -l |
https://docs.ansible.com/ansible/latest/modules/list_of_all_modules.html
Просмотр документации по модулю
1 |
# ansible-doc |
Просмотр примеров использования модуля(сниппетов), которые могут использоваться в плейбуках
1 |
# ansible-doc -s |
Если модуль не указывается,то используется модуль command
Например
1 |
# ansible allservers -a "/bin/echo hello" |
Аналогично команде
1 |
# ansible allservers -m command -a "/bin/echo hello" |
Модуль setup -сбор фактов
Список fact-ов(информации) собираемых ансиблом для хоста и доступних в Playbook-e или templat-е в виде соответствующих переменных
1 |
# ansible -m setup kub |
Фильтрация фактов(например, выведем только переменную ansible_distribution)
1 |
# ansible -m setup -a "filter=ansible_distribution" kub |
Модули shell и command -выполнение команды удаленном сервере
Модуль shell — запуск Shell-команды(модуль shell и в качестве аргумента передаем команду, которую нужно выполнить, запуск команды происходит в оболочке (/bin/sh) на удаленной машине )
1 |
# ansible -m shell -a "uptime" kub |
Модуль command -налогично shell, но запуск команды на удаленной машине происходит без использования оболочки, поэтому переменные окружения не будут доступны, также не будут доступны операторы типа
1 |
<,>,|,;,& |
1 |
# ansible -m command -a "uptime" kub |
Разница между shell и command хорошо видна на команде с использованием операторов, которые не поддерживает модуль command(например, оператор | )
1 |
# ansible -m shell -a "ls -al /etc/ | grep passwd" kub |
1 |
# ansible -m command -a "ls -al /etc/ | grep passwd" kub |
Модуль copy -копирование файла на удаленный сервер
Копирование файла на управляемый сервер
1 |
# echo "Ansible my test file" > my-test-ansible.txt |
1 |
# ansible -m copy -a "src=my-test-ansible.txt dest=/root/" kub |
Если не хватает прав на создание файла на управляемом хосте,то используем опцию –b (—become), которая повышает привиллегии до root-пользователя через маханизм sudo
1 |
# ansible -m copy -a "src=my-test-ansible.txt dest=/root/" kub -b |
Просмотр наличия файла на управляемой машине
1 |
# ansible -m shell -a "cat /root/my-test-ansible.txt" kub |
Модуль file -создание/удаление файла/каталога на управляемом хосте
Удаление файла на управляемом хосте
1 |
# ansible -m file -a "path=/root/my-test-ansible.txt state=absent" kub |
Модуль get_url -Закачивание файлов с HTTP,HTTPS,FTP-хостов по URL на управляемый хост
1 |
# ansible -m get_url -a "url=https://collectors.sumologic.com/rest/download/linux/64 dest=/root" kub |
1 |
# ansible -m shell -a "ls -al | grep -i sumo" kub |
Модуль apt -установка/удаление пакета в Debian/Ubuntu
Установка(если не установлен) или обновление до последней версии(если установлен) пакета stress
1 |
# ansible -m apt -a "name=stress state=latest" kub |
Либо
Установка(если не установлен) пакета stress с предварительным обновлением локального кеша пакетов
1 |
# ansible -m apt -a "name=stress state=present update_cache=yes" kub |
Удаление пакета stress
1 |
# ansible -m apt -a "name=stress state=absent" kub |
Установка Apache на Ubuntu
1 |
# ansible -m apt -a "name=apache2 state=present update_cache=yes" kub |
Модуль service — запуск/остановка/перезапуск сервиса и добавление/удаление сервиса на/из автозагрузку/и
Запуск сервиса apache2 и добавление его в автозагрузку
1 |
# ansible -m service -a "name=apache2 state=started enabled=yes" kub |
Модуль uri -проверка доступности страницы в Интернете
1 |
# ansible -m uri -a "url=https://www.google.com" kub |
по статусу кода ответа можно понять коректно ли выполнилась команда
Если нужно получить/просмотреть содержимое страницы
1 |
# ansible -m uri -a "url=https://www.google.com return_content=yes" kub |
Модуль git — получение файлов(checkout) с git-репозитария
Checkout приватного git-репозитария на целевой хост в каталог /home/calculator
SSH-ключ, с которым с целевого хоста идет аутентификация на Git-сервере, указывается в опции key_file
Если файл имеет имя id_rsa и находится внути каатлога ~/.ssh/ на целевом хосте, то этот файл будет использоваться по умолчанию и нет необходимости принудительно его указывать через опцию key_file
1 |
# ansible -m git -a "repo=git@bitbucket.org:/calculator.git dest=/home/calculator key_file=~/.ssh/id_rsa" kub |
До и после выполнения задачи считается SHA, который позволяет понять, был ли репозиторий обновлен.
Модуль debug — модуль печатает операторы во время выполнения и может быть полезен для отладки переменных или выражений без необходимости остановки выполнения плейбука
Например
1 2 3 4 5 6 7 |
- name: Say Hello to All debug: msg="Hello {{ item }}" #with_items: # before v2.5 loop: # from v2.5 - "One" - "Two" - "Three" |
Или вывести значения переменных inventory_hostname(которую мы определяем в inventory-файле) и ansible_fqdn(собранную/полученную ансиблом во время выполнения таска по умолчанию с именем gathering facts)
1 2 3 4 5 6 7 |
tasks: - name: show inventory_hostname debug: msg="inventory_hostname is {{ inventory_hostname }}" - name: show ansible_fqdn debug: msg="ansible_fqdn is {{ ansible_fqdn }}" |
Вывести значение перменной ansible_os_family
При использовании параметра var переменная указывается без каких-либо дополнительных символов/кавычек т.е. необходиом указывать непосредственно имя переменной
1 2 3 |
- name: Check and print linux version debug: var: ansible_os_family |
Модуль lineinfile — управление строками в файле
Модуль lineinfile используется для вставки/изменения/удаления текста/строк в файле
Например, вставим/добавим(параметр state) указанную строку(параметр line) в указанный файл(параметр path)
Указанная строка будет добавлена в конец указанного файла
Если файл не существует, то он будет создан(параметр create). В том числу будет создана и структуру каталогов, по пути которой находится файл(/project/devops/)
Если не указывать параметр create и файл не существует, то таск выполнится с ошибкой
Если повторно выполнить этот плейбук,т о никаких изменений сделано не будет т.к. файл уже существует и содержит желаемую строку
1 2 3 4 5 6 |
- name: add line to file lineinfile: path: /project/devops/abc.txt line: My test line state: present create: yes |
Если необходимо заменить строку, которая соответствует regexp-у на указанную строку
Например, в файле /project/devops/abc.txt(параметр path) заменить строку, которая начинается со слова «docker» (параметр regexp) строкой «hello world» (параметр line)
Важным моментом является указание параметра backrefs в значение yes(по умолчанию используется backrefs: no). Если параметр backrefs не указан или указан в no, то работает это следующим образом, если строка с указанным regexp-ом не найдена,то указанная в параметре line строка будет добавлена в конец файла. Более того, при повторном выполнении плейбука,сснова такая строка будет добавлена в конец файла т.е. по факту будет продублирована, что явно нежелательно
При указании backrefs: yes, если строка с указанным regexp-ом не найдена, то ничего не будет изменено/добавлено в файле
1 2 3 4 5 6 7 8 9 10 11 12 13 |
- name: Replace some string matching pattern/regexp lineinfile: path: /project/devops/abc.txt regexp: '^docker' line: 'hello world' state: present backrefs: yes - name: Add some string with before(insertbefore)/after(insertafter) some string lineinfile: path: /project/devops/abc.txt insertafter: '^docker' line: 'hello world' |
Для удаления строки соответствующей шаблону используется значение absent для параметра state
1 2 3 4 5 |
- name: Delete string matching pattern/regexp lineinfile: path: /project/devops/abc.txt regexp: '^docker' state: absent |
Python синтаксис регулярных выражений
https://docs.python.org/3/library/re.html
https://docs.python.org/2/library/re.html
Количество одновременно выполняемых процессов(-f)
По умолчанию используется 5 параллельных процесов для выполнения команд на разных хостах
1 |
# grep forks /etc/ansible/ansible.cfg |
1 |
#forks = 5 |
Если необходимо, чтобы команды выполнялись только на одной машине одновременно, тогда используем опцию -f
1 |
# ansible all -f 1 -a "free" |
Debug в Ansible
Уровень детализации вывода при выполнении плейбука регулируется кол-вом опций -v(verbose)
1 |
# ansible -m shell -a "systemctl status apache2" kub -v |
1 |
# ansible -m shell -a "systemctl status apache2" kub -vv |
1 |
# ansible -m shell -a "systemctl status apache2" kub –vvv |
1 |
# ansible -m shell -a "systemctl status apache2" kub -vvvv |