Многоступенчатое развертывание с ansible

Какой подход вы бы посоветовали организовать многоступенчатое развертывание с ansible, если у вас есть разные переменные для этапов?

Основная идея заключается в определении групповых переменных для разных этапов.

Есть два искусства:

Я хотел бы получить больше примеров об организации playbooks, переменных, хостов и понять преимущества и недостатки вашего подхода.

Источник

3 ответа

Решение

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

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

Ваш макет каталогов должен быть таким:

production/
├── group_vars
│   └── server.yml
└── inventory
staging/
├── group_vars
│   └── server.yml
└── inventory
deploy.yml

И использование чрезвычайно просто:

ansible-playbook -i staging deploy.yml

куда deploy.yml это название вашей пьесы.

Ansible-playbook, если указана директория в качестве инвентаря, по умолчанию будет искать файл с именем inventory так что не нужно указывать -i production/inventory, только -i production будет работать просто отлично.

И преимущества:

  • Вы не должны содержать некоторые ненужные группы, такие как [production:children]

  • Вам не нужно смешивать группы и файлы вроде group_vars/production.yml

  • Все vars и hosts находятся в отдельных каталогах, поэтому их легко отличать, а история изменений понятна. Вы можете даже разделить его на отдельные репозитории, если хотите

Вы также можете хранить секреты для производства в хранилище, используя ansible-vault другими словами, храните все ваши жизненно важные переменные в зашифрованном виде

Источник

В случае сложных структур инвентаризации, когда ведение групп групп не является лучшим вариантом ( http://docs.ansible.com/ansible/intro_inventory.html), следующий прием может использоваться:

Файл инвентаризации продукции:

# production inventory 
[loadbalancers]
lb01
lb02
lb03

[webservers]
ws01
ws02
ws03

[all:vars]
inventory_vars=prod.config.yml

Файл инвентаризации разработки:

# development inventory 
[loadbalancers]
test-lb01
test-lb02
test-lb03

[webservers]
test-ws01
test-ws02
test-ws03

[all:vars]
inventory_vars=development.config.yml

Теперь в самой книге включите следующую задачу перед загрузкой ролей:

- hosts: all

  pre_tasks:

    - name: Load inventory specific variables
      include_vars: "{{ inventory_vars }}"

Чтобы предотвратить случайное выполнение playbook на производственной среде, prod.config.yml может быть зашифрован с ansible-vault

Источник

В настоящее время я использую следующую структуру:

hosts/development
hosts/production
hosts/group_vars/development/service1.yml
hosts/group_vars/development/service2.yml
hosts/group_vars/production/service1.yml
hosts/group_vars/production/service2.yml
hosts/group_vars/production/service3.yml
hosts/host_vars/dev1.yml
hosts/host_vars/prod1/something.yml
hosts/host_vars/prod1/something_else.yml

Запасы могут выглядеть так:

# hosts/development

dev1 ansible_ssh_host=dev1.example.com
dev2 ansible_ssh_host=dev2.example.com

[development]
dev1
dev2

[service1]
dev1

[service2]
dev2

[service3]
dev1
dev2

И для производства:

# hosts/production

prod1 ansible_ssh_host=prod1.example.com
prod2 ansible_ssh_host=prod2.example.com

[production]
prod1
prod2

[service1]
prod1

[service2]
prod2

[service3]
prod1
prod2

Это учитывает некоторые хорошие комбинации. Используя ansible -i hosts Я могу настроить таргетинг на всех известных хостов. Я использую это, например, чтобы добавить все серверы из инвентаря в файл конфигурации мониторинга.

Используя ansible -i hosts/development Я могу ограничить команду серверами разработки (или производства). Я делаю это, когда хочу протестировать новую конфигурацию в системе разработки, прежде чем применить ее к производству.

В настоящее время я использую эту структуру для примерно 25 серверов на 3 разных этапах, и она довольно хорошо работает для меня. Однако у него есть некоторые недостатки:

  • Хотя в моем случае преимущества перевешивают эти недостатки. Мой самый большой страх - это случайное нацеливание на все запасы в каталоге хостов, забыв ограничиться одним из этапов. Этого было бы легче избежать, если бы кадастры были совершенно раздельными.
  • Кроме того, мне не нравится снова перечислять все серверы в инвентаре в development или же production группы, потому что это избыточно и легко забыть.
  • Я полагаю, что если ваша система будет расти, это может немного сбить с толку, чтобы понять, откуда и в каком порядке загружаются переменные.

Тем не менее, это работает довольно хорошо для меня, так что, возможно, это работает хорошо и для вас.

Источник
Другие вопросы по тегам