2014-02-05 2 views
8

Пример сценария: файлы конфигурации для определенной службы хранятся под контролем версий в частном реестре github. Я хочу написать playbook, который извлекает один из этих файлов на удаленном узле и помещает его в нужное место.Использование Ansible для загрузки одного файла из частного github-репо на удаленный хост

Я могу назвать несколько решений этой:

  1. сделать проверку на машине, которая работает анзибль (local_action), а затем использовать модуль copy
  2. сделать проверку на удаленном узле (с git), скопируйте файлы в нужное место с помощью command: cp src dest creates=dest (возможно, сделайте это с помощью обработчика - только при изменении настроек репо).
  3. используйте модуль URL или command: wget https://raw.github.com/repo/.../file creates=file в playbook, чтобы загрузить файл, представляющий интерес. Действительно ли модуль command проверяет, отличается ли файл, который уже существует, или он просто проверяет наличие файла?
  4. использование Wget на машине, которая работает анзибль (local_action), а затем использовать модуль копирования, чтобы подтолкнуть его к удаленному узлу

Каковы преимущества/недостатки этого. Какие (если таковые имеются) из них можно считать хорошей практикой. Какое наилучшее общее решение?

+0

Решение 3: определенно просто проверьте файл. И только если add создает: параметр для команды. –

ответ

3

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

Решение №. 1:

  • Простой и надежный - будет просто работать
  • Не «загрязнять» производственные серверы, не относящимися к файлам (другие конфигурационные файлы)
  • Не загружает производственные серверы ввода/вывода GitHub (вероятно, незначительно)

Решение №. 2:

  • Простой и надежный - будет просто работать
  • Чтобы уменьшить загрязнение, мы клонировать конфигурации репо в/TMP и удалить его в конце сборника пьес

Решение нет. 3/4:

Я предполагаю, что это сработает, но немного странно иметь конфигурацию в исходном управлении, а затем не использовать функции управления источником. Преимущество этих решений заключается в том, что вы можете «выбрать вишню», какие файлы конфигурации вы хотите скачать, а не клонировать весь репозиторий. Это также уменьшает ввод-вывод против github, поскольку клонирование становится более тяжелым с течением времени.

+2

Я решил попробовать 1-е решение, и я думаю, что это именно то, что я хотел.Я думаю, что он масштабируется лучше (по крайней мере, для моего использования), поскольку вы только один раз разговариваете с github (на незаменимом сервере), а не один раз на удаленный узел на вызов задачи. – pldimitrov

+1

Что касается масштабируемости, я думаю, что это действительно зависит от вашего варианта использования. Вы предпочли бы ограничивать вызовы Github или копии файлов? С первым решением у вас есть только один вызов github, но у вас есть X-копия, по одному для каждого узла. В зависимости от вашего подключения ваша загрузочная книжка может быть немного длинной, чтобы обрабатывать многие удаленные узлы (например, копирование 50Mo на 20 хостов = 1Go данных только для вашей управляющей машины), тогда как при каждом контакте с узлом github будет использовать только 50Mo на каждом узле, и github, безусловно, масштабируется для этого ... – Pom12

Смежные вопросы