How to build enterprise OS Images with Packer? Part-1
Why should you even care about Packer when everything is a container in today’s overhyped software world? I understand it may sound a bit dramatic but Not everything can be put in a container unless you are living on the edge of the world where fantasy is greeting you with open arms.
A special thanks to my ex-teammates Anton, Yevhen, and Alek. Pomeshkin.
Architecture Decisions based on
3. Tools 🧰
4. End of Life 💀
Let me try to ask a bit better questions so you can understand better what I mean by the decision mentioned above points and why they matter.
- Does your given software support static configurations?
Example: Apache Kafka requires a Unique ID per instance of Apache Kafka so we can’t use static configurations because each Apache Kafka will have the same ID and Apache Kafka may not work.
- Would you like to configure your system on the fly aka provisioning?
Example: Since Apache Kafka requires a Unique ID, we can generate this on the fly to not generate an infinite number of OS Images ranging from 1..N using Cloud-Init aka User-Data.
- Who will be your end customer of OS Images? is it a Team/Organization/Company/etc?
- What are SLAs for your end customer?
- What cloud provider would you like to use? AWS/Azure/GCP/etc.
- How many programming languages do you know and willing to learn? Bash/YAML*/HCL**/Groovy/Go/Python/etc.
- What will be your CI and CD System?
- How many security testing tools do you know? Nexpose/AWS Inspector/etc.
- What Release Mechanism / Cycle will you follow?
End of Life aka EOL Questions
- When would you like to deprecate/End the given OS Image?
- What will be your EOL contract with your customer?
* YAML can be of several syntaxes like Ansible/GitLab/etc.
** HCL can also be of several syntaxes like Packer/Terraform/etc.
In the next article, I will cover how we can translate these questions into an architecture graph and piece together the puzzle.