Многоступенчатое развертывание с возможностью доступа

Question

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

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

Есть два artcles:

• http://rosstuck.com/multistage-environments-with-ansible/)
• (http://toja.io/using-host-and-group-vars-files-in-ansible/)

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

Answer 1

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

Статья взята из статьи Organizing Group Vars Files in Ansible, но немного изменилась, потому что, к сожалению, название статьи не отражает ее реальной ценности, а назначение и названия игровых автоматов также запутывают. На самом деле потребовалось немало времени, чтобы понять, что это около Многоступенчатое развертывание с Ansible.

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

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

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

ansible-playbook -i staging deploy.yml 

Где deploy.yml это имя вашего сборника пьес.

анзибль-Playbook при условии, каталог в качестве описи, будет искать по умолчанию файл с именем inventory поэтому нет необходимости указывать -i production/inventory, только -i production будет работать нормально.

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

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

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

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

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

Answer 2

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

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 серверов на трех разных этапах, и это работает очень хорошо для меня. У этого есть некоторые недостатки:

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

Это, как говорится, хорошо работает для меня, поэтому, возможно, это хорошо работает и для вас.

Answer 3

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

Производство Inventory Файл:

# production inventory 
[loadbalancers] 
lb01 
lb02 
lb03 

[webservers] 
ws01 
ws02 
ws03 

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

Разработка Inventory файла:

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

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

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

в настоящее время в самой PlayBook, включают в себя следующую задачу перед загрузкой ролей:

- hosts: all 

    pre_tasks: 

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

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