Развертывание и планирование изменений с помощью Ansible OSS

Обратите внимание: меня не интересуют какие-либо корпоративные/платные (Tower) решения здесь, а только решения, доступные через предложение Ansible OSS.

Итак, мой проект Ansible настроен и отлично работает, о-о-о! Выглядит примерно так:

myansible01.example.com:/opt/ansible/
    site.yml
    fizz.yml
    buzz.yml
    group_vars/
    roles/
        common/
            tasks/
                main.yml
            handlers
                main.yml
        foos/
            tasks/
                main.yml
            handlers/
                main.yml

Есть несколько вещей, которые мне нужно выполнить, чтобы заставить это работать в производственной среде:

  • Мне нужно иметь возможность автоматизировать развертывание изменений в этом проекте
  • Мне нужно запланировать запуск плейбуков, скажем, каждые 30 секунд (чтобы все управляемые узлы всегда соответствовали требованиям)

Итак, мои опасения:

  • Как обычно развертываются изменения в действующих проектах Ansible? Скажем, проект находится по адресу myansible01.example.com:/opt/ansible (мой сервер Ansible). Достаточно ли просто удалить корень проекта Ansible (rm -rf /opt/ansible), а затем скопировать последний (содержащий изменения) проект Ansible обратно в то же место? Что произойдет, если Ansible в настоящее время запускает какие-либо воспроизведения, пока я выполняю эту команду «drop-n-swap»?
  • Похоже, что коммерческое предложение (Ansible Tower) имеет встроенную функцию планирования, но не предложение OSS. Как я могу запланировать Ansible OSS для запуска игр в определенное время? Например, я могу захотеть, чтобы определенные игры запускались каждые 30 секунд, чтобы узлы всегда соответствовали требованиям. Достаточно ли для этого cron или есть более стандартный подход?

cron ansible operation
person smeeb    schedule 22.09.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

Вы можете настроить Jenkins для запуска плейбуков по таймерам или другим событиям, таким как отправка в SCM, например git.

Обычно задание начинается с проверки тега/ветви нашей базы кода Ansible, а затем применения его ко всем указанным нами серверам, чтобы вы всегда знали, что выполняется. Если вы хотите, это может быть просто голова на мастере (в терминах git), поэтому он всегда применяет самые последние изменения. Если бы у вас также было это, чтобы подключиться к вашему репозиторию SCM, то простой толчок заставит эти изменения быть примененными ко всем вашим серверам.

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

Jenkins по умолчанию не будет запускать задание, пока выполняется одно и то же задание (или если у вас исчерпаны слоты исполнителя), поэтому вы всегда можете быть уверены, что он будет извлекать репо (включая любые изменения) только после того, как ваш запуск Ansible завершится. полный. Если у вас запущено несколько заданий, вы можете использовать блокировку, чтобы предотвратить одновременный запуск заданий (оба пытаются применить потенциально разные конфигурации к серверам), но вам не нужно беспокоиться о запуске нового задания и переносе репозитория в уже существующий. работа, поскольку Дженкинс разделяет их на отдельные рабочие области.

Мы используем Jenkins для ручного запуска Ansible в нашей среде, но у нас также есть «самовосстанавливающееся» задание Jenkins, которое просто запускает помеченную фиксацию нашей кодовой базы Ansible в нашей среде, переводя ее в идемпотентное состояние, чтобы предотвратить естественный дрейф конфигураций. Когда нам нужно сделать что-то отличное от среды или выполнить немного опережающую фиксацию нашей кодовой базы в ней, мы можем легко отключить задание самовосстановления, пока мы не будем довольны всем, а затем либо просто повторно включить задание, чтобы верните вещи или продвиньте тег, который использует Дженкинс, чтобы теперь использовать более позднюю фиксацию.

person ydaetskcoR    schedule 22.09.2015