How to build enterprise OS Images with Packer? Part-2

How to build enterprise OS Images with Packer? Part-1

Let me explain, how images will be built with previously mentioned requirements and also consider scalability, Isolation and better debugging.

Made with Lucid Chart

Meanings of above shown colourful boxes

1. Vendor OS Image is any OS Image that the original vendor provides like we download ISO from Ubuntu or aws-images aka vanilla.
2. Global OS Image (Optional) is an image which would include company security standards like CIS/PCI-DSS/etc. and serve as a base image for the whole company.
3. Org./Product Image (Optional) is an image which takes Global OS Image and adds Product/Org. required changes. Example — Using Python 3.10 Runtime.
4. Service OS Image (Optional) is an image which takes either Global OS Image or Product Image and adds service-related changes. Example — Using Python urllib3 instead of urllib.

Even though all the layers are mentioned as optional but they are not when we consider the full picture because each image layer fulfil a couple of requirements.

Now, Let’s Take another look at the above-mentioned boxes but in a stack diagram mentioned just below.

Made with Lucid Chart

With Stack Diagram, we understand better that we need all Image changes to ensure our Image is Secure, Meets Requirements, and is Configurable.

Our ideal image should include base OS, Application Dependencies, and Application binaries/configurations, and also meets security standards.

The process mentioned above is very similar to another approach (maybe) borrowed from the Docker Image building process.

We achieve the following goals
1. Global Security Standards
2. Flexibility
3. Resuablilty of Code and Images
4. Ease of issue debugging
5. many more!

Let’s take a quick look at a sample CI/CD Flow.

Made with Lucid Chart

Few Notes*
1. CI and CD are loosely coupled via git repository tags.
2. CI only emits tags and no other artifacts.
3. Assuming CI system via GitHub Actions.
4. Assuming CD system via Jenkins Pipelines.
5. Github.com can be used as Git Repository.

The actor can be following
1. DevOps
2. SRE
3. Platform Engineers

The Shared Packer Code repository will be our primary location to version control Packer / HCL codebase.
The following tree structure can be used

$ tree shared-packer-code/
shared-packer-code/
├── .github
│   └── workflows
├── bin
├── src
│   └── example
│       ├── aws
│       │   ├── linux
│       │   └── windows
│       ├── azure
│       │   ├── linux
│       │   └── windows
│       └── gcp
│           ├── linux
│           └── windows
└── tests
........

The other shared code repositories will be following

1. Ansible Roles.
2. Helper Scripts for CI/CD.
3. IaC aka Infrastructure as Code repositories.

To make sure, I don’t overcomplicate this article. I will deep dive into CI/CD workflow in the following article of this series.