![]() Depending on your maturity level you could even remove access to the instances so that it's no longer possible to change anything on the instance once it has been deployed which, in my experience, is a major factor in operational issues. All other images are then built off the latest "Base" AMI and don't have to worry about making sure those things are installed/configured or worry about encrypting the root volume.īy baking your configuration into the AMI you are also able to move towards the immutable infrastructure model which has some major benefits in that you know that you can always throw away an instance that is having issues and very quickly replace it with a new one. ![]() I personally bake a reasonably lightweight "Base" AMI that does some basic hardening and sets up monitoring and logging that I want for all instances that are deployed and also makes sure that Packer encrypts the root volume of the AMI. I'd strongly recommend tagging your AMIs in a way that allows you to use source_ami_filter in Packer and Terraform's aws_ami data source so when you make changes to your AMIs Packer and Terraform will automatically pull those in to be built on top of or deployed at the next opportunity. Packer certainly can build on top of images and in fact requires a source_ami to be specified. In my opinion it's much better to do the configuration up front and ahead of time using Packer to bake as much as possible into the AMI and then use user data scripts/tools like Consul-Template to provide environment specific differences. If you have Terraform run a provisioner such as Chef or Ansible on every EC2 instance creation you add a chunk of time for the provisioner to run at the time you need to deploy new instances. Using Packer to create finished (or very nearly finished) images drastically shortens the time it takes to deploy new instances and also allows you to use autoscaling groups. But what I really want to know is when do you choose Packer Provisioning over Terraform Provisioning? Provisioning in Packer makes the Terraform Code much simpler and terraform applies will become faster because it's just an AMI that you fire up.įor me both of these methods have their place. Also, this will only be used in AWS so it won't use other builders necessarily. This is based on the assumption that Packer allows you to provision on top of AMIs so that AMIs can be "extended". Provisioning takes a long time because of the packages it tries to install.A change in the provisioning will probably result in instances being destroyed on apply?.I won't be able to add a different set of provisioning steps on top of the module?.If I package these resources into modules, then provisioning won't "leak out". This is what I've come up withĪs it states, I simply provision in terraform for the necessary instances. These changes are intended to be used for all internal development machinesīecause of mainly the second constraint, I was wondering where is the best place to place the provisioning.I need to provision on top of a specific AMI, which adds enterprisey stuff such as LDAP/AD access and so on.There are a couple of (enterprise/corporate) constraints that exist: I am sitting with a situation where I need to provision EC2 instances with some packages on startup.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |