Ansible: как обрабатывать серверы на одном хосте?

Question

Я пытался в течение нескольких дней настраивать Ansible, чтобы использовать его для загрузки среды dev для моего проекта и, во-вторых, развертывания для бета-версий и живых серверов. Проект не такой большой, но кажется, что Ansible недостаточно гибкий, когда речь идет о небольших проектах.

Инвентарь

[development] 
web_server ansible_connection=docker 
db_server ansible_connection=docker 

[production] 
web_server ansible_host=10.10.10.10 ansible_user=tom ansible_connection=ssh 
db_server ansible_host=10.10.10.10 ansible_user=tom ansible_connection=ssh 

Я хочу, чтобы держать web_server и db_server псевдонимов нетронутыми, так что я могу переключаться между разработкой и производством в моем сценарии без шума. Основная проблема заключается в том, что я не могу понять, как создать playbook, который будет хорошо работать с вышеуказанной настройкой.

Это решение не работает, так как оно выполняет все задачи дважды!

--- 
- hosts: staging 
    tasks: 
    - name: Setup web server 
     command: uptime 
     delegate_to: web_server 
    - name: Setup db server 
     command: ls 
     delegate_to: db_server 

Это решение решает вышеуказанную проблему, но она выводит неправильный псевдоним (web_server даже при выполнении задачи дб)!

--- 
- hosts: staging 
    run_once: true 
    tasks: 
    - name: Setup web servers 
     command: uptime 
     delegate_to: web_server 
    - name: Setup db servers 
     command: ls 
     delegate_to: db_server 

Это решение было бы правдоподобно, но анзибль не поддерживает доступ к отдельному узлу из группы:

--- 
- hosts: staging:web_server 
    tasks: 
    - name: Deploy to web server 
     command: uptime 

--- 
- hosts: staging:db_server 
    tasks: 
    - name: Deploy to db server 
     command: ls 

Есть ли способ добиться того, чего я хочу? Безразличный чувствует себя довольно ограничительным, пока этот момент не станет обломком после всей похвалы, которую я слышал об этом.

-------------------------- Редактировать после предложения удондана ---------------- ------

Я попробовал предложение удондана, и оно, похоже, сработало. Однако, когда я добавляю новую группу в инвентарь, она ломается.

[development] 
web_server ansible_connection=docker 
db_server ansible_connection=docker 

[staging] 
web_server ansible_host=20.20.20.20 ansible_user=tom ansible_connection=ssh 
db_server ansible_host=20.20.20.20 ansible_user=tom ansible_connection=ssh 

[production] 
web_server ansible_host=10.10.10.10 ansible_user=tom ansible_connection=ssh 
db_server ansible_host=10.10.10.10 ansible_user=tom ansible_connection=ssh 

В этом случае IP-сервер промежуточного (20.20.20.20) будет использоваться при запуске производства пьес.

Answer 1

Это решение не работает, так как оно выполняет все задачи дважды!

Предполагая, что hosts: staging является то, что вы определили в development это ожидаемое поведение. Вы определили группу хостов и выполнили задачи или роли против этой группы, все хосты этой группы будут обработаны. Делегируя задачу на другой хост, вы только заставляете задачу выполнять в другом месте, но задача все еще выполняется для каждого хоста группы.

Я думаю, что вы хотите это:

--- 

- hosts: web_server 
    tasks: 
    - name: Setup web server 
     command: uptime 

- hosts: db_server 
    tasks: 
    - name: Setup db server 
     command: ls 

---

Update после ответа:

Проблема заключается в использовании тех же имен хостов для всех сред и попытаться передать их в разные разъемы. Что бы ни случилось, это так:

Он читает ваш инвентарь сверху донизу, находит группы и обрабатывает группы в алфавитном порядке.(разработка, производство, постановка). Он находит хост web_server в группе development, поэтому он создает эту группу, добавляет этот хост и устанавливает для этого хоста var ansible_connection. Он переходит к группе production, снова находит хост web_server, поэтому он добавляет его в группу production и устанавливает vars ansible_host, ansible_user и ansible_connection. Но это не относится к этой группе. Он задан для имени хоста web_server, переопределяя предыдущее значение ansible_connection. Ansible продолжает группу staging и снова переопределяет все настройки. Хост web_server принадлежит ко всем 3 группам, и его вары объединены, даже если вы нацелились только на одну группу, например. ansible-playbook ... --limit=development. Предел ограничивает воспроизведение только совпадающими хостами, но хост по-прежнему принадлежит ко всем группам и имеет все (объединенные) вары, которые были определены.

Настоятельно рекомендуется и передовая практика иметь файл инвентаря для каждой среды. Не специально для проблемы, с которой вы сталкиваетесь, а просто для добавления еще одного уровня безопасности, чтобы случайно не сделать что-либо для ваших производственных хостов, когда вы действительно хотите настроить таргетинг на стойки. Но это также решит вашу проблему. Таким образом, вместо того, чтобы один файл инвентаризации, как вы бы:

inventory/development:

[development] 
web_server 
db_server 

[development:vars] 
ansible_connection=docker 

inventory/staging:

[staging] 
web_server 
db_server 

[staging:vars] 
ansible_host=20.20.20.20 
ansible_user=tom 
ansible_connection=ssh 

inventory/production:

[production] 
web_server 
db_server 

[production:vars] 
ansible_host=10.10.10.10 
ansible_user=tom 
ansible_connection=ssh 

Тогда вы назвали бы анзибль с соответствующий файл инвентаризации:

ansible-playbook -i inventory/staging ... playbook.yml 

Если вы как-то не можете этого сделать и вам нужен один файл инвентаря, вам нужно убедиться, что имена узлов уникальны, поэтому детали подключения не переопределены.