Противоракетная оболочка против марионеток против шеф-повара

У меня есть следующая настройка:

  • Много разных проектов, которые являются отдельными репозиториями git, но все они имеют в основном ту же конфигурацию сервера
  • Каждый проект, в свою очередь, зависит от многих других проектов, и мы используем менеджер зависимостей композитора, чтобы собрать их (язык PHP здесь).

Я хочу использовать Vagrant и включать в репозиторий файл Vagrant, поэтому мои члены команды могут клонировать репозиторий, запускать vagrant up и быть готовым к работе.

Теперь мой вопрос направлен на обеспечение. Мне нужно установить несколько инструментов и пакетов, таких как apache, git, mysql и несколько php-пакетов, а затем загрузить некоторые файлы (например, недавний db dump dump), установить все в /var/www и запустить команду установки компоновщика.

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

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

Почему мне кажется, что плохой подход пойти с марионеткой/шеф-поваром:

Я понимаю, что мне придется использовать несколько разных рецептов и почти всегда будут использовать одни и те же рецепты для моих разных репозиториев, поэтому мне пришлось бы включить их во все репозитории. Подумайте о том, чтобы иметь 20 репозиториев и нуждающихся в 10 рецептах, это означает, что мне нужно будет добавить 200 рецептов в виде git -подмодуля или одинакового (также каждый член команды должен клонировать репозиторий, затем клонировать 10 репозиториев рецептов и только затем запускать бродячие вверх для каждого проекта). Напротив, мне просто нужно иметь небольшое репо с моей оболочкой script и клонировать его 20 раз.

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

Ответы

Ответ 1

В следующей статье рассматривается еще один инструмент CM (ansible), но я думаю, что автор делает отличную работу по разъяснению преимуществ перехода от сценариев оболочки.

http://devopsu.com/blog/ansible-vs-shell-scripts/

quote 1:

То, что действительно удивило меня, было ответом от некоторых из этих более известных разработчиков. Они в основном сказали: "Это действительно здорово, но я, вероятно, не буду читать его, так как рабочий процесс manual-install/shell- script сейчас прекрасен".

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

quote 2:

Для них использование инструмента СМ означало недели усилий, усложняя сложные концепции, борясь со сложным процессом установки и поддерживая эту сложную систему с течением времени. Они были в курсе преимуществ, но затраты на использование инструмента СМ просто казались слишком высокими, чтобы приложить усилия.

Преимущества по сценариям оболочки суммируются в конце, и я думаю, что они применимы ко всем инструментам CM, кукольным, шеф-поварам, соли, незаменимым...

  • Какой метод, скорее всего, попадет в исходный контроль?
  • Какой метод можно запускать несколько раз безопасно с уверенностью?
  • Какой метод можно легко запускать на нескольких серверах?
  • Какой метод на самом деле проверяет (проверяет) ваш сервер на правильность?
  • Какой метод может легко ориентироваться на определенные серверы (web, db и т.д.)?
  • Какой способ поддерживает легкую настройку ваших конфигурационных файлов?
  • Какой метод будет расти, чтобы легко поддерживать весь ваш стек?

Надеюсь, что это поможет.

Ответ 2

Обновлено 2016

Для тех, кто нашел это через Google, кажется, что группа разработчиков движется в сторону Ansible для простоты. Из сообщения:

"Ansible - это инструмент развертывания для людей, которым не нравятся инструменты развертывания. Он близок к сценариям, не загрязняет ваши серверы агентами или централизованными серверами и просто имеет смысл".

Недавно мы реализовали его в нашей микросервисной архитектуре, и это было потрясающе.

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

Кукольный/повар всегда имеет место в моем сердце/стек, но Ansible просто легче.