Мне любопытно, хорошая ли стратегия - предварительная сборка двоичных файлов (установка пакетов) и использование chef только для управления конфигурацией. Теоретически он должен ускорить процесс инициализации, когда нам нужны новые машины (всплеск трафика), особенно если мы используем облака, такие как AWS, где мы можем создавать собственные AMI (изображения), в то же время он может быть не гибким с точки зрения того, как другие кулинарные книги работай..
Я с нетерпением жду ваших мыслей по этому вопросу, а также лучших практик, опыта и идей!
Оба конца спектра имеют свои плюсы и минусы, как и область между ними.
A. Используйте стандартный общедоступный AMI с динамической конфигурацией системы при загрузке
(+) Не требует обучения созданию AMI.
(+) Не требует обучения управлению конюшней исторических AMI.
(+) Легко изменить и протестировать конфигурацию системы, отредактировав конфиг и запустив новый экземпляр.
(+) Простое управление в разных регионах, учетными записями с помощью общего файла (ов) конфигурации.
(+) Легко запускать варианты конфигурации, настраивая правила конфигурации запуска.
(-) Первоначальный запуск системы может быть медленным или очень медленным, в зависимости от того, сколько работы необходимо выполнить процессу настройки запуска.
(-) Требуется понимание того, как автоматизировать конфигурацию запуска, особенно при использовании с автоматическим масштабированием или спотовыми инстансами.
Б. Предварительная сборка пользовательской AMIS
(+) Первоначальный запуск выполняется быстро, так как не требуется никаких действий по настройке.
(+) Хорошо работает с автоматическим масштабированием и спотовыми инстансами.
(-) Требуется научиться эффективно создавать AMI и управлять ими.
(-) Требуется сборка нового AMI каждый раз при изменении желаемой конфигурации.
(-) Требуется сборка нового AMI при каждом выпуске исправлений безопасности ОС.
(-) Длинный цикл редактирования / сборки / тестирования при изменении конфига
(-) Требуется несколько AMI для разных регионов, разные учетные записи (если они не используются совместно), разные варианты конфигураций, разные архитектуры экземпляров.
В. Что-то среднее
Вы можете получить некоторые из преимуществ (и некоторые из недостатков) обеих стратегий, сделав что-то посередине: создайте базовый пользовательский AMI, который имеет большую часть того, что вам нужно для ваших экземпляров, затем запустите динамическую конфигурацию во время выполнения, которая обновляет и завершает настройку, применяя любые необходимые изменения.
Это ускоряет время загрузки, возможно, намного, но также дает некоторую гибкость и избавляет от необходимости часто перестраивать AMI.
Рекомендации
Начните с создания автоматических сценариев (или рецептов Chef), которые будут использовать общедоступный AMI и настраивать его для вашей желаемой системы.
Используйте автоматическую конфигурацию с общедоступными AMI (подход A выше), пока это работает для вас.
Когда и где вы сталкиваетесь с проблемами производительности при запуске, используйте автоматическую конфигурацию для создания пользовательских AMI (подход B выше). Максимально автоматизируйте этот процесс, чтобы вы могли запускать его как можно чаще.
Если у вас есть несколько вариантов системы на основе одной и той же базовой базы, создайте собственный базовый AMI и используйте подход C, описанный выше, для запуска различных вариантов системы.