Когда проводить подготовку в Packer vs Terraform?
Я сижу в ситуации, когда мне нужно подготовить экземпляры EC2 с некоторыми пакетами при запуске. Существует несколько ограничений (корпоративных / корпоративных):
- Мне нужно настроить поверх определенного AMI, который добавляет корпоративные вещи, такие как доступ к LDAP / AD и т. д.
- Эти изменения предназначены для использования на всех машинах для внутренней разработки.
В основном из-за второго ограничения мне было интересно, где лучше всего разместить подготовку. Это то, что я придумал
Положение в Terraform
Как говорится, я просто готовлю в терраформе необходимые экземпляры. Если я упакую эти ресурсы в модули, то подготовка не «просочится». Недостатки
- Я не смогу добавить другой набор шагов подготовки поверх модуля?
- Изменение в настройке, вероятно, приведет к уничтожению экземпляров при применении?
- Подготовка занимает много времени из-за пакетов, которые он пытается установить.
Подготовка в Packer
Это основано на предположение, который Packer позволяет вам предоставлять поверх AMI, так что AMI могут быть «расширены». Кроме того, это будет использоваться только в AWS, поэтому не обязательно использовать другие компоновщики. Подготовка в Packer значительно упрощает код Terraform, а применение terraform становится быстрее, потому что вы запускаете просто AMI.
Для меня оба этих метода имеют свое место. Но что я действительно хочу знать, так это когда вы выбираете Packer Provisioning вместо Terraform Provisioning?
Ответы 2
Использование Packer для создания готовых (или почти готовых) образов значительно сокращает время, необходимое для развертывания новых экземпляров, а также позволяет использовать группы автомасштабирования.
Если у вас есть Terraform, запускающий средство обеспечения, такое как Chef или Ansible, при каждом создании экземпляра EC2, вы добавляете отрезок времени для запуска средства обеспечения в то время, когда вам нужно развернуть новые экземпляры. На мой взгляд, гораздо лучше выполнить настройку заранее и заблаговременно, используя Packer, чтобы как можно больше встроить в AMI, а затем использовать сценарии / инструменты пользовательских данных, такие как Консул-Шаблон, для определения различий, специфичных для среды.
Packer, безусловно, может строить поверх изображений и фактически требует указания source_ami. Я настоятельно рекомендую пометить ваши AMI таким образом, чтобы вы могли использовать source_ami_filter в Packer и Источник данных aws_ami Terraform, чтобы, когда вы вносите изменения в свои AMI, Packer и Terraform автоматически подтягивают их для создания поверх или развертывания при следующей возможности. .
Я лично создаю достаточно легкий «базовый» AMI, который выполняет базовое усиление и настраивает мониторинг и ведение журнала, которые мне нужны для всех развернутых экземпляров, а также гарантирует, что Packer зашифровывает корневой том AMI. Все остальные образы затем создаются на основе последнего «Базового» AMI, и вам не нужно беспокоиться об установке / настройке этих вещей или о шифровании корневого тома.
Запекая свою конфигурацию в AMI, вы также можете перейти к модели неизменяемой инфраструктуры, которая имеет некоторые важные преимущества, поскольку вы знаете, что вы всегда можете выбросить экземпляр, у которого есть проблемы, и очень быстро заменить его новым. В зависимости от вашего уровня зрелости вы можете даже удалить доступ к экземплярам, чтобы больше не было возможности изменить что-либо в экземпляре после его развертывания, что, по моему опыту, является основным фактором операционных проблем.
Очень редко вы можете столкнуться с чем-то, что очень затрудняет запекание AMI, и в этих случаях вы можете запустить свои сценарии подготовки в средстве подготовки Terraform, когда он создается. Иногда проще перенести существующий процесс на использование провайдеров с Terraform, чем запекать AMI, но я бы настаивал на переносе этого в Packer, где это возможно.
Я столкнулся с такой же ситуацией. В соответствии с моим пониманием
- Если вы очень часто вызываете свои инстансы EC2, скажите 2–3 раза день, затем перейдите к созданию настраиваемого AMI с упаковщиком, а затем вызовите ami через терраформ.
- Если ваш базовый образ (AMI, созданный упаковщиком) часто меняется в зависимости от в соответствии с вашими требованиями, тогда его хорошо использовать упаковщик. Но для меня запуск сценариев упаковщика занимает очень много времени.
- То же самое можно сделать и с упаковщиком. Вы можете написать свой требования в скрипте и назовите его терраформом. Имея все включение в скрипт терраформирования уменьшит некоторое время
Наконец, ваше решение и частота появления инстансов EC2.