Это хорошая идея сделать Ansible и Rundeck работать вместе, или использовать один из них достаточно?

Недавно я смотрю на Ansible и хочу использовать его в проектах. А также еще один инструмент Rundeck можно использовать для выполнения всех видов операций. У меня нет опыта ни с одним инструментом, и это мое текущее понимание о них:

Аналогичные точки

Оба инструмента не имеют агента и используют SSH для выполнения команд на удаленных серверах.
Основная концепция Rundeck Node, то же самое, что и Ansible inventory, ключевая идея - определить/управлять/группировать целевые серверы.
Rundeck может выполнять команды ad-hoc на выбранных узлах, Ansible также может сделать это очень удобно.
Rundeck может определять рабочий процесс и выполнять выполнение на выбранных узлах, это можно сделать с помощью Ansible, написав playbook
Rundeck может быть интегрирован с инструментом CI, таким как Jenkins, чтобы выполнить работу по развертыванию, мы также можем определить задание Jenkins для запуска загрузочной книги для выполнения работы по развертыванию.

Различные точки

В Rundeck есть понятие Иов, которое Ansible не
В Rundeck есть Job Scheduler, который Ansible может достичь этого только с помощью других инструментов, таких как задачи Jenkins или Cron.
Rundeck имеет бесплатный веб-интерфейс по умолчанию бесплатно, но вам нужно заплатить за Ansible Tower

Кажется, что Ansible и Rundeck могут использоваться для работы с конфигурацией/управлением/развертыванием, возможно, по-другому. Поэтому мои вопросы:

Являются ли эти два дополнительных инструментария или они предназначены для разных целей? Если они являются дополнительными инструментами, почему Ansibl сравнивается только с такими инструментами, как Chef/Puppet/Slat, но не с Rundeck? Если они не потому, что у них так много подобных функций?
Мы уже используем Jenkins для CI, чтобы построить конвейер непрерывной доставки, какой инструмент (Ansible/Rundeck) лучше использовать для развертывания?
Если они могут использоваться вместе, какая лучшая практика?

Приветствуются любые предложения и обмен опытом.

Ответ 1

TL; DR - учитывая вашу среду Jenkins для CI/CD, я бы рекомендовал использовать только Ansible.

Вы заметили, что существует значительное пересечение между Ansible и Rundeck, поэтому лучше всего сосредоточиться на том, где каждый продукт фокусируется, его стиль и использование.

Фокус

Я считаю, что Rundeck фокусируется на том, чтобы позволить системным администраторам создавать (веб-сайт) портал самообслуживания, доступный как другим системным администраторам, так и, возможно, менее "техническим" /системным администраторам. Сайт Rundeck говорит: "Превратите свои операционные процедуры в задания самообслуживания. Безопасно дайте другим возможность контроля и видимости, в которой они нуждаются". Rundeck также чувствует, что он имеет более "централизованный" взгляд на мир: вы загружаете задания в базу данных и где они живут.

Для меня Ansible предназначен для devops, поэтому выстраиваем и автоматизируем развертывание (самостоятельно построенных) приложений таким образом, чтобы они были сильно повторяемы. Я бы сказал, что Ansible больше ориентируется на дома разработки программного обеспечения, которые строят свои собственные продукты: Ansible "playbooks" - это текстовые файлы, которые обычно хранятся в исходном контроле и обычно рядом с приложением, которое будут разворачиваться в планшетах.

Фокус создания задания

С Rundeck вы обычно создаете задания через веб-интерфейс.

С помощью Ansible вы создаете задачи /playbooks в файлах через текстовый редактор.

Операция/Задача/Стиль работы

Rundeck по умолчанию является обязательным - вы пишете сценарии, которые выполняются (через SSH).

Ansible является обязательным (т.е. выполняет команды bash), но также декларативным, поэтому в некоторых случаях, скажем, при запуске Apache вы можете использовать задачу service, чтобы убедиться, что она работает. Это ближе к другим инструментам управления конфигурацией, таким как Puppet and Chef.

Сложные задания/скрипты

Rundeck имеет возможность запускать другое задание, определяя шаг в рабочем процессе Job, но по опыту это похоже на добавленное дополнение, чем серьезная функция верхнего уровня.

Ansible предназначен для создания сложных операций; запуск/включение/etc - это функции верхнего уровня.

Как работает

Rundeck - это серверное приложение. Если вы хотите запускать задания из другого места (например, CI), вам нужно либо вызвать в cli, либо сделать вызов API.

Прямая Ansible - это командная строка.

Proviso

Из-за перекрестной и общей гибкости Rundeck и Ansible вы можете достичь всего вышеперечисленного в каждом. Вы можете добиться контроля версий своих заданий Rundeck, экспортируя их в YAML или XML и проверяя их на исходный контроль. Вы можете получить веб-интерфейс в Ansible, используя Tower. и т.д. и т.д.

Ваши вопросы:

Дополнительные инструменты?

Я мог бы представить себе магазин SaaS, используя оба: можно было бы использовать Ansible для выполнения всех действий по развертыванию, а затем использовать Rundeck для выполнения одноразовых, adhoc-заданий.

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

CI/CD-

Ansible: ваша среда больше похожа на дом программного обеспечения, где вы развертываете свое приложение. Вероятно, это должно быть повторяемо (особенно, когда вы отправляете непрерывную доставку), поэтому вам понадобятся сценарии развертывания в исходном управлении. Вы хотите простоту, а Ansible - "просто текстовые файлы". Надеюсь, вы также захотите, чтобы ваши разработчики могли работать на своих машинах (правда?), Ansible децентрализована.

Используется вместе (для CI/CD)

Вызов Rundeck от Ansible, no. Конечно, это было бы возможно, но я изо всех сил пытаюсь найти веские причины. По крайней мере, не очень специализированные специфические для конкретного приложения или рамки.

Вызвать Ansible из Rundeck, да. Я мог представить, что кто-то сначала создает некоторые повторяющиеся команды adhoc в Ansible. Тогда я мог видеть, что есть небольшой спрос на возможность вызова этого без командной строки (скажем: нетехнические пользователи). Но, опять же, это зависит от вашей среды.

Ответ 2

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

Если у вас есть бюджетные ограничения, не смотрите дальше, скалы Rundeck. Однако вы можете пропустить некоторые функции в Ansible. Также группа Google очень активна в случае поддержки.

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

Ответ 3

Моя точка - rundeck и ansible (бесплатно, без башни) выполняют разные виды работы

Несущая (без башни) - управление конфигурацией (предоставление сервера/приложения, массовые обновления конфигурации)
Rundeck - централизованный планировщик заданий с контролем доступа, уведомлением, выходом задания и т.д. (архивные старые журналы, запуск некоторых скриптов и т.д.)

Ответ 4

Стандарты сервера могут быть доступны.

Задача Adhoc/operation go rundeck.

Это то, что я сейчас использую.

Ответ 5

Если вы собираетесь использовать их как портал самообслуживания для разработчиков или команду OPS то я бы сказал, что RBAC проще и интуитивно понятнее реализовать в Башне, а не в Rundeck. Подумайте, сколько усилий и сложности требуется для установки RBAC, поскольку это может иметь решающее значение для команд, поддерживающих эти продукты.
REST API в Башне проще и проще анализировать, а не в Rundeck.
В Tower вы можете видеть отдельные события на одну задачу в книге, в то время как в Rundeck все выдается на одном консольном выходе.
Динамические запасы в Башне весьма полезны при развертывании в общественных облаках.

Ответ 6

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

Пользовательский интерфейс теперь открыт с открытым исходным кодом: AWX