2

How are people who are using immutable infrastructure handling configuration changes between their different environments? I can't workout a nice way to create one AMI per role and use it in all environments.

What I mean is how do I build a single ami that I can deploy to development, staging and production, but that points to the correct ELB, etc. for that environment. At the minute the only options I can think of are:

  • Build an AMI per environment per role (production web server, prod. app server, staging web server, ...). This seems to defeat the purpose of II in having the same image pushed to all environments.
  • Build an almost complete AMI and do the final configuration after launching it but before adding it to the ELB. This seems to be close but I feel like there is something missing.

Is there anyway for me to pass a set of parameters to an AMI when it's being created or something else? How are others using immutable infrastructure?

Thanks.

Bill
  • 23
  • 3
  • 1
    Look at user-data http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html and cloud-init https://cloudinit.readthedocs.org/en/latest/ – dmourati May 17 '15 at 18:37

1 Answers1

1

At Boxfuse we live and breathe immutable infrastructure. We recommend a combination the following two approaches:

  1. Bake as much configuration as possible for all environments directly in the AMI (and auto-select the correct set at runtime)
  2. Pass in the remaining settings as an instance user data shell script (cloud-init) that exports environment environments with the values you need for that machine/environment
Axel Fontaine
  • 202
  • 2
  • 10