Начинаем тестировать новые функции и готовиться к миграции на vRealize Automition 8. В нашей инсталляции vRA 7.x активно используются software components для настройки серверов. Поэтому основной вопрос – как настраивать сервера, если программных компонентов больше нет? vRA 8 предлагает несколько вариантов решения: cloud-init, Ansible Tower и просто Ansible (на удалённом SSH-сервере).
- Cloud-init подойдёт для небольшой “обработки напильником” сервера при первом запуске и установки дополнительного ПО, данный инструмент активно используется многими облачными провайдерами. Минусы: для сложных развёртываний кластерных приложений он не подходит и, как оказалось, пока не дружит с VMware VM customization;
- Ansible – один из самых распространённых и удобных способов управления парком серверов; имеется большое количество модулей и примеров сценариев (плейбуков) для различных систем. Ansible Tower – далеко не бесплатная система управления, но имеется и свободная реализация – Ansible AWX. Минусы: если на установку этих систем уйдёт не много времени, то про их изучение “с нуля” этого уже не скажешь;
- Ansible Open Source сочетает в себе все плюсы от использования Ansible и возможность быстрого старта, поскольку не требует много времени на настройки и изучения документации. С этим вариантом сейчас и познакомимся…
Настройка Ansible
Настройка интеграции vRA – Ansible
Блюпринт vRA
Отладка. Что происходит под капотом?
Настройка Ansible
Установка Ansible в системе (все настройки данного раздела выполняются на выделенном Linux-сервере, с которым vRA будет соединяться по SSH):
$ apt install ansible # для Ubuntu / Debian
$ yum install ansible # для RHEL / CentOS.
Рекомендация: Для интеграции vRA с Ansible создайте отдельного пользователя без прав администратора. Если в домашней директории создать файл конфигурации .ansible.cfg, то настройки будут браться именно из него.
$ useradd ansible
$ cp /etc/ansible/ansible.cfg /home/ansible/.ansible.cfg
$ cp /etc/ansible/hosts /home/ansible/hosts
$ chown -R ansible:ansible /home/ansible/
# задайте пользователю пароль или создайте пару ключей для ssh-доступа
$ passwd ansible
Настройка Ansible, как и интеграция с vRA, очень простая. Всё подробно описано в документации Configure Ansible Open Source integration in vRealize Automation Cloud Assembly.
Сделайте дополнительные настройки в файле конфигурации ~/.ansible.cfg
[defaults]
vault_password_file = ~/.creds/ansible_vault_password
...
[paramiko_connection]
record_host_keys = False
...
[ssh_connection]
#ssh_args = -C -o ControlMaster=auto -o ControlPersist=60s
ssh_args = -o UserKnownHostsFile=/dev/null
vault_password_file используется утилитой ansible-vault для хранения ключа шифрования. Если для удалённого доступа к настраиваемым серверам Вы укажите логин/пароль, то пароль будет зашифрован с использованием данного ключа. Создать этот файл можно следующими командами:
$ echo 'ksdjhfgasf32te41u2egwd32' > ~/.creds/ansible_vault_password
$ chmod 600 ~/.creds/ansible_vault_password
Настройка интеграции vRA – Ansible
Создание объекта интеграции vRA – Ansible:
- Зайдите в Infrastructure > Connections > Integrations и нажмите кнопку Add Integration;
- Выберите Ansible;
- Заполните форму: имя для нового объекта интеграции, имя хоста с настроенным ansible, путь до файла inventory (в нашем случае это ~/hosts) и параметры для соединения: имя пользователя ansible и его пароль;
- Нажмите Validate для проверки корректности введённых данных и настроек ansible на хосте;
- Нажмите Add.
Блюпринт vRA
Теперь Вы готовы развернуть первый сервер с настройкой через Ansible. Самый простой блюпринт:
formatVersion: 1
name: Ansible test blueprint
version: 1
inputs: {}
resources:
Ansible-Test:
type: Cloud.Ansible
properties:
account: Ansible-host
inventoryFile: ~/hosts
groups:
- test_echo
host: '${resource.VM.*}'
username: ansible
privateKeyFile: ~/.ssh/id_rsa
osType: linux
maxConnectionRetries: 10
playbooks:
provision:
- ~/playbooks/test/echo.yml
hostVariables: |
vmName: ${resource.VM.resourceName}
VM:
type: Cloud.Machine
properties:
image: Ubuntu_18
flavor: small
customizationSpec: tmp-linux-vra
networks:
- network: '${resource.vSphere_Network.id}'
assignment: static
vSphere_Network:
type: Cloud.vSphere.Network
properties:
networkType: existing
- account – выберите название своего объекта интеграции vRA с Ansible;
- inventoryFile – путь до файла инвентори;
- groups – название группы в файле инвентори, в которую будет прописан данный хост (если такой группы ещё нет, то она будет создана автоматически);
- host – виртуальный сервер, на котором будет выполняться плейбук ansible (при связывании элементов на схеме это значение прописывается автоматически);
- username – имя пользователя для доступа к настраиваемому серверу;
- privateKeyFile – путь до приватной части ключа ssh-соединения (если доступ по ключам ещё не настроили, то используйте доступ по паролю, укажите его в поле password);
- osType – тип настраиваемой системы;
- maxConnectionRetries – количество попыток соединения с сервером;
- playbooks.provision – плейбук для выполнения при настройке сервера (можно указать несколько, они будут выполняться последовательно);
- playbooks.de-provision – плейбуки для выполнения при выводе сервера;
- hostVariables – список переменных для передачи в Ansible.
# ~/playbooks/test/echo.yml
- name: Echo hello
hosts: all
connection: ssh
become: no
tasks:
- name: "Echo hello string"
shell: echo "{{ vmName }}" >> ~/echo.txt
Данный демо-плейбук записывает в файл ~/echo.txt имя виртуальной машины, которое передаётся в него из блюпринта в параметре hostVariables.
- hosts – список хостов для запуска плейбука или имя группы хостов. В нашем случае можно было вместо all указать группу test_echo из блюпринта, но использование группы all не приведёт к запуску на всех серверах из файла инвентори. Почему? Ответ в следующем разделе.
- become – разрешает или запрещает смену пользователя для повышения привилегий. Для выполнения этого плейбука дополнительные права не нужны. Но в большинстве случаев настройка потребует наличия прав root, для этого поменяйте значение become на yes, выдайте пользователю права администратора и разрешите повышение прав без пароля (username ALL=(ALL) NOPASSWD:ALL).
Отладка. Что происходит под капотом?
Работа vRA с Ansible отличается от обычного запуска ansible-playbook на локальном сервере.
vRA использует отдельное хранилище логов и временных файлов для каждого развертывания и каждого элемента Ansible из Вашего блюпринта. Все они находятся в ~/var/tmp/vmware/provider/user_defined_script/*. Это первое место, с которого нужно начинать поиск ошибок при выполнении плейбуков.
Для проверки значений переменных vRA посмотрите файлы в директории host_vars. Она всегда создаётся рядом с файлом инвентори, у нас это ~/host_vars. Для каждой VM создаётся отдельная поддиректория по его IP, она содержит файлы с глобальными переменными, переменными пользователя (hostVariables из vRA), а также зашифрованные пароли. Следует помнить, что если у Вас в блюпринте элемент содержит свойство count, то, передавая его свойства как значения переменных, Вы получите массивы, даже если count = 1.
Совет: Попробуйте передать в переменную в качестве значения целиком один из ресурсов, например, виртуальную машину:
vm: '${resource.VM.*}'
В переменной получите объект json и увидите все его доступные свойства: ~/host_vars/<VM IP>/vra_user_host_vars.yml
Чтобы более внимательно изучить, как происходит выполнение плейбука из vRA, добавьте к нему ещё одну задачу:
- name: "Wait 15 minutes"
shell: sleep 15m
Во время выполнения плейбука посмотрите содержимое ~/var/tmp/vmware/provider/user_defined_script/* и список процессов. Вот процессы, которые были запущены в моей системе от имени пользователя ansible:
- Выполнение начинается с запуска файла exec, он инициализирует несколько переменных и вызывает следующий процесс:
bash var/tmp/vmware/provider/user_defined_script/4c2d7946-9539-448a-89e3-a6bd2d21b100/exec
- Это основной bash-сценарий, выполняющий всю “грязную” работу: проверяет инвентори и регистрирует в нём хост, создаёт файлы с переменными, работает с зашифрованными данными… Он же делает запуск ansible-playbook:
bash var/tmp/vmware/provider/user_defined_script/4c2d7946-9539-448a-89e3-a6bd2d21b100/4c2d7946-9539-448a-89e3-a6bd2d21b100 max_connection_retries=10 ansible_inventory_path=/home/ansible/hosts use_sudo=false ansible_groups=test01 node_host=192.168.100.3 node_user=ansible node_uuid=4c2d7946-9539-448a-89e3-a6bd2d21b100 operation=create provisioning_playbook_paths=L29wdC92bXdhcmUvYW5zaWJsZS9rOHMvZWNoby55bWw= ansible_ssh_private_key_file=/home/ansible/.ssh/id_rsa
- Запуск плейбука. Параметрами заданы файл инвентори из блюпринта и конкретный хост для запуска. Именно поэтому использование группы хостов all в плейбуке не приведёт к его запуску на всех хостах из инвертори или на всех хостах в группе:
/usr/bin/python3 /usr/local/bin/ansible-playbook /home/ansible/playbooks/test/echo.yml -l 192.168.100.3 -i /home/ansible/hosts
- Далее уже работает ansible:
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o IdentityFile="/home/ansible/.ssh/id_rsa" -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User="ansible" -o ConnectTimeout=10 -tt 192.168.100.3 /bin/sh -c '/usr/bin/python3 /home/ansible/.ansible/tmp/ansible-tmp-1590723734.9405904-113746505590972/AnsiballZ_command.py && sleep 0'
В продолжение темы читайте vRA 8: Ansible + Kubernetes