Moving to an AMI deployment strategy for standing up web servers can be really awesome. From immutable artifacts that are deployed to any environment, to fewer moving parts, we can really simplify deploys.
Unfortunately, we still usually have some dynamic elements, like web server configs or environment-specific secrets. How can we supply values to those elements at runtime?
This talk will focus on how we can use a combination of Chef Infra and Habitat to solve that issue with AMI deployments.
This is a talk will have a good bit of code examples. Nothing should be very difficult to understand but I'll explain anything that could be confusing. It will lean heavily on my experience building a system like this. While the examples will use Amazon Web Services, it could very easily translate to Azure or Google Cloud.
- Introduction
- Discuss background and show why this is a problem
- Build application Amazon Machine Image (AMI)
- Very simple app just for demo purposes
- Uses Packer but that's not a focus of the talk
- Walk through cookbook
- Should be a basic cookbook that sets up a web server but needs dynamic runtime values
- Build Habitat package
- Briefly discuss what Habitat is and why to use it. This is already covered more in depth at other talks.
- Talk about the Effortless Pattern
- Show Habitat code, build package, and deploy to Habitat Builder
- Deploy AMI
- Show deploying AMI using UserData to install Habitat
- Variables stored in AWS Systems Manager
- Show how those values are pulled in and set for the Habitat service to consume
You'll get the most out of this talk if you have experience with Habitat but none is required. Here are a couple things that I'd like you to take from this:
- You can still use Chef Infra when deploying application AMIs
- The Effortless Pattern with Habitat makes it easy to run your cookbooks as an application