Cloud Assembly поддерживает интеграцию с Puppet Enterprise, Ansible Open Source и Ansible Tower, позволяя управлять конфигурациями развертываний и дрейфом конфигураций.

Интеграция Puppet

Для интеграции управления конфигурацией на основе Puppet необходимо установить допустимый экземпляр Puppet Enterprise в общедоступном или частном облаке с рабочей нагрузкой vSphere. Между этой внешней системой и экземпляром Cloud Assembly необходимо установить соединение. После этого можно предоставить Cloud Assemblyдоступ к управлению конфигурацией Puppet путем его добавления в соответствующие схемы элементов.

Поставщик Puppet для службы схем элементов Cloud Assembly устанавливает, настраивает и запускает агент Puppet на развернутом вычислительном ресурсе. Поставщик Puppet поддерживает подключения по протоколу SSH и WinRM со следующими предварительными условиями.

  • Подключения по SSH:
    • В качестве пользователя должен быть указан либо привилегированный пользователь, либо пользователь с разрешениями sudo для выполнения команд в режиме NOPASSWD.
    • Деактивируйте requiretty для заданного пользователя.
    • В вычислительном ресурсе развертывания должна быть доступна служба cURL.
  • Подключения по WinRM:
    • в вычислительном ресурсе развертывания должен быть доступен инструмент PowerShell 2.0.
    • Настройте шаблон Windows, как описано в документации по vRealize Orchestrator.

Администратор DevOps отвечает за управление подключениями к Puppet Master и применение ролей Puppet или правил настройки к определенным развертываниям. После развертывания виртуальные машины, в которых настроена поддержка управления конфигурацией, регистрируются с помощью назначенного сервера Puppet Master.

При развертывании виртуальных машин пользователи могут добавлять или удалять Puppet Master как внешнюю систему или обновлять проекты, назначенные серверу Puppet Master. Наконец, соответствующие пользователи могут отменять регистрацию развернутых виртуальных машин в Puppet Master после вывода их из эксплуатации.

Интеграция Ansible Open Source

При настройке интеграции Ansible установите Ansible Open Source в соответствии с инструкциями по установке Ansible. Дополнительные сведения об установке см. в документации по Ansible.

Ansible по умолчанию включает функцию проверки ключа узла. Если узел установлен повторно с другим ключом в файле known_hosts, появится сообщение об ошибке. Если узел не указан в файле known_hosts, необходимо ввести ключ при запуске. Для деактивации проверки ключа узла используйте следующий параметр в файле /etc/ansible/ansible.cfg или ~/.ansible.cfg: 
[defaults]
host_key_checking = False
localhost_warning = False
 
[paramiko_connection]
record_host_keys = False
 
[ssh_connection]
#ssh_args = -C -o ControlMaster=auto -o ControlPersist=60s
ssh_args = -o UserKnownHostsFile=/dev/null

Для предотвращения ошибок при проверке ключей узла задайте для параметров host_key_checking и record_host_keys значение False, а также добавьте дополнительный параметр UserKnownHostsFile=/dev/null, заданный в ssh_args. Кроме того, если изначально иерархия пуста, Ansible выведет предупреждение, что список узлов пуст. Это приведет к сбою проверки синтаксиса сценария.

Хранилище Ansible Vault позволяет хранить конфиденциальные данные, например пароли или ключи, в зашифрованных файлах, а не в виде обычных текстовых файлов. Хранилище шифруется с помощью пароля. В системе Cloud Assembly Ansible использует хранилище для шифрования таких данных, как пароли SSH для компьютеров узлов. Предполагается, что задан путь к паролю хранилища.

Файл ansible.cfg можно изменить, указав расположение файла с паролем в следующем формате. 

vault_password_file = /path to/file.txt

Кроме того, можно задать переменную среды ANSIBLE_VAULT_PASSWORD_FILE, чтобы Ansible автоматически выполняла поиск пароля. Например, ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass.txt.

Cloud Assembly управляет файлом иерархии Ansible, поэтому необходимо убедиться, что пользователь Cloud Assembly имеет доступ rwx к файлу иерархии. 

cat ~/var/tmp/vmware/provider/user_defined_script/$(ls -t ~/var/tmp/vmware/provider/user_defined_script/ | head -1)/log.txt
Если необходимо использовать пользователя, не являющегося привилегированным (root), с интеграцией Cloud Assembly с открытым исходным кодом, то пользователям потребуется набор разрешений для запуска команд, используемых поставщиком Cloud Assembly с открытым исходным кодом. В файле sudoers пользователя должны быть настроены следующие команды. 
Defaults:myuser !requiretty
Если пользователь не является членом группы администраторов, для которой приложение askpass не указано, настройте следующую команду в файле sudoers пользователя. 
myuser ALL=(ALL) NOPASSWD: ALL

Если при настройке интеграции Ansible возникают ошибки или иные проблемы, используйте файл log.txt в 'cat~/var/tmp/vmware/provider/user_defined_script/$(ls -t ~/var/tmp/vmware/provider/user_defined_script/ | head -1)/' на управляющем компьютере Ansible.

Интеграция Ansible Tower

Поддерживаемые типы операционных систем
  • Red Hat Enterprise Linux 8.0 или более поздней версии, 64-разрядная (x86), поддерживает только Ansible Tower 3.5 или более поздней версии.
  • Red Hat Enterprise Linux 7.4 или более поздней версии, 64-разрядная (x86).
  • CentOS 7.4 или более поздней версии, 64-разрядная (x86).

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

[root@cava-env8-dev-001359 ansible-tower-setup-bundle-3.5.2-1.el8]# pwd
 
/root/ansible-tower-install/ansible-tower-setup-bundle-3.5.2-1.el8
 
[root@cava-env8-dev-001359 ansible-tower-setup-bundle-3.5.2-1.el8]# cat inventory
 
[tower]
 
localhost ansible_connection=local
 
 
 
 
[database]
 
 
 
 
[all:vars]
 
admin_password='VMware1!'
 
 
 
 
pg_host=''
 
pg_port=''
 
 
 
 
pg_database='awx'
 
pg_username='awx'
 
pg_password='VMware1!'
 
 
 
 
rabbitmq_port=5672
 
rabbitmq_vhost=tower
 
rabbitmq_username=tower
 
rabbitmq_password='VMware1!'
 
rabbitmq_cookie=cookiemonster
 
 
 
 
# Needs to be true for fqdns and ip addresses
 
rabbitmq_use_long_name=false
 
 
 
 
# Isolated Tower nodes automatically generate an RSA key for authentication;
 
# To deactivate this behavior, set this value to false
 
# isolated_key_generation=true