Ansible позволяет структурировать переменные и задачи инвентаризации разными способами. Сформулируйте собственное мнение о том, куда логично поместить вещи, основываясь на ожиданиях различных плагинов Ansible.
Лаборатория находится в защищенной сети VLAN, что означает, что для запуска сценариев из
удаленно мне нужно подключиться к машине с их IP, а не с
свое полное доменное имя и предоставить учетные данные.
ЛОЖЬ. DNS возможен для каждой среды. Возможно делегировать зону hiddai.lab.example.net
на DNS-сервер тестовой лаборатории, и узлы используют полные доменные имена в этой зоне.
Тем не менее, ansible_host
переменная может быть предоставлена для переопределения имен хостов или IP-адресов для использования подключаемыми модулями.
Не используйте IP-адреса, выделенные для других пользователей. 1.1.1.1 не ваш, это DNS Cloudflare. Используйте либо свои реальные IP-адреса, либо тестовые сети документации, такие как 192.0.2.0/24 198.51.100.0/24 203.0.113.0/24.
Кроме того, мне нужно решить, будет ли мой продукт установлен безопасным или
не в моей лаборатории (какой протокол - HTTPS или HTTP?)
Всегда безопасно, поэтому HTTPS. Лабораторные настройки могут быть более расслабленными для PKI, личных простых ЦС, самоподписанных сертификатов.
Кроме списка хостов и IP-адресов в инвентаре ansible yaml
файл, ожидается ли добавление переменных или ключей, таких как:
«учетные данные», «протокол», «файлы», «машинный тип» и т. д.
Нет, отдельный список хостов от данных конфигурации приложения на уровне ролей. Это позволяет проводить несколько инвентаризаций. Минимальное дублирование данных между несколькими лабораториями, промежуточными и производственными запасами.
Ограничьте инвентаризацию тем, что необходимо для подключения к хосту: имя хоста, пользователь, возможно, учетные данные, подключаемый модуль. Поместите информацию о приложении в другое место, например group_vars.
кредит:
пользователь: а
проход: 1
Говоря об учетных данных, я считаю пароль из одного символа недопустимо коротким. Даже не имейте это как поддельный пример. В идеале замените аутентификацию по паролю чем-то лучшим, например, аутентификацией на основе ключа или сертификата. Или, по крайней мере, длинные пароли, состоящие из слов, например к несчастью-притворство-занимают-квартиру
.
Ваши пути к файлам кажутся Windows. Читать Документация Ansible по winrm и рассмотрим ваши варианты авторизации.
Хранение кредитов в инвентаре означает, что любой, у кого есть файл инвентаря, может выполнять команды. Защитите файл надлежащим образом. Рассмотрите возможность хранения учетных данных в отдельных файлах ключей или в какой-либо секретной системе, к которой вы можете получить доступ с помощью поиска Ansible.
Ваш файл vars - это YAML, но не в структуре Статический плагин инвентаризации YAML от Ansible надеется. Возможно, что-то вроде этого инвентарь/lab.yml
Я изменил некоторые значения на фактические примеры в соответствии с RFC в Интернете.
---
все:
дети:
окна:
# Группа, содержащая только хосты Windows, позволяет
# Переменные аутентификации и подключения для Windows
вары:
ansible_user: а
ansible_password: неудачно-притворно-занято-четвертованное
ansible_connection: winrm
ansible_winrm_transport: credssp
дети:
дБ:
# Полное доменное имя как inventory_hostname должно разрешаться, если в DNS
# Ansible выделяет для вас верхнюю метку как специальную var inventory_hostname_short
хосты:
центр-db.hiddai.lab.example.net:
# ansible_host переопределяет, к чему подключаться
# Например, когда нет DNS
доступный_хост: 203.0.113.23
дети:
очередь:
хосты:
центр-очередь.hiddai.lab.example.net:
доступный_хост: 203.0.113.83
дети:
приложение:
хосты:
центр-приложение.hiddai.lab.example.net:
доступный_хост: 203.0.113.62
дети:
клиент:
хосты:
клиент-приложение.hiddai.lab.example.net:
доступный_хост: 203.0.113.28
дб: центр-дб
Мне неясно, что такое «центр» в этом примере, программный продукт, имя развертывания, имя клиента? Поскольку инвентарь Ansible на самом деле плоский внутри, я свернул его. Добавьте его обратно как переменную или группу, если хотите.
Что касается данных конфигурации приложения для конкретного хоста, рассмотрите group_vars. Они могут быть связаны с вашим файлом инвентаризации, с именем файла, совпадающим с именем группы.
инвентарь/group_vars/windows.yml
---
base_dir: 'C:\папка\'
общие_файлы:
- Сервер.msi
инвентарь/group_vars/app.yml
---
файлы_дополнительно:
- файлы
- Центр-Клиент.msi
инвентарь/group_vars/client.yml
---
файлы_дополнительно:
- Клиент-Клиент.msi
Примечание. Я придумал пару переменных для файлов. Поскольку они имеют разные имена, вы можете позже объединить их в один список, поэтому {{ файлы_общие + файлы_дополнительные}}
В идеале написать и использовать роли Ansible, у которых есть свои переменные и задачи. Рассмотрите значения ролей по умолчанию, подходящие для большинства случаев использования. Например, задача win_package установить эти msi-пакеты и по умолчанию загрузить их с https-сервера. Но сделайте исходный файл пакета переменной, чтобы его можно было переопределить.
И пьесы — это то, что сопоставляет эти шаблоны хозяина с ролями. Я не уверен, как назвать ваше приложение, учитывая только общие имена, поэтому я поставил перед ролями префикс «вещь». play.yml:
---
хосты: БД
роли:
- вещь БД
хосты: очередь
роли:
- очередь вещей
хосты: приложение
роли:
- вещь приложение
хосты: клиент
роли:
- вещьклиент
Запустите такой плейбук с ansible-playbook play.yml -i inventory/lab.yml
Не включено: роли. Я не знаю, чего вы хотите достичь, и этот ответ становится немного длинным.