Introduction
I’ve been a fan of immutable infrastructure ever since I used tools like Terraform and Packer. I wouldn’t say I understood the pros of it right away, but with time spent managing deployment of services in high traffic environments, one sort of understands the importance of being able to have an infrastructure which is scalable, predictable and can be recovered automatically. Who better to explain what immutable infrastructure is than Armon Dadgar himself?
Image layering
If you go through Section 2.3 of the book container best practices, they have a good section on various types of images. This brought back few of the steps I used to use previously on maintaining and building container images.
Poor quick drawing credits: sketchpad.io
Base Layer
This base layer contains the operating system, core system tools, (eg: such as vim, bash, software-properties-common, curl, vim etc) and tools necessary to install packages and make updates to the image over time. The best example of such base layers are the alpine images.
Dependency layer
Dependency image layers are where you would install the platform related dependencies (eg: such as Java runtime, mysql, Go, Erlang etc)
Application layer
Application layer is where the dependencies specific to the container would go (eg: Database configurations, Go application code etc)
One can add the application specific endpoints here or add something like dumb-init.
What this helps us do is to reuse the layers at one specific stage and to use it for multiple purposes. Images being layered in this fashion will help break down large sized images into smaller images with well defined layers. It will help in faster builds, maintenance and also for reusing them as components.
References
Please follow TechLog for more.
Top comments (0)