In the middle ages, Byzantine emperors and European monarchs issued decrees with a golden seal that was a testament to the origin of the decree. Fast forward to today and we can see how the idea of a golden seal — or golden copy– is used in technology to express that something is the official or master version. Taking the idea of a golden copy one step further, today we will discuss the concept of the golden Amazon Machine Image (AMI), its role in supporting a successful DevOps model, and how it can generate greater agility and stability.
AMI and Golden AMI
For those of you new to the concept, an AMI is what gives you the information required to launch an instance, or virtual server, in the cloud. When you launch an instance, you specify an AMI. From that AMI you can launch as many instances as you want. AMIs are comprised of templates for the root volume for the instance, launch permissions, (e.g. which AWS accounts can use the AMI to launch instances) and a block device mapping that specifies the volumes to attach to the instance when it’s launched.
A golden AMI is a base AMI approved by the IT Operations team. The golden AMI is a template EC2 machine image that contains a preconfigured (ideally hardened) OS and a well-defined stack of server software fully configured to run your application. A golden AMI may also be referred to as a master AMI or base AMI. A collection of golden AMIs may be referred to as a golden image library.
Golden AMIs are beneficial to organizations as once the ideal template is set-up, administrators need only replicate it, thus saving time, eliminating potential errors from creating new AMIs from scratch, and ensuring environmental consistency. (Which in turn reduces risk and increases repair rates when an issue does occur.)
DevOps and Golden AMIs
At Flux7, our DevOps team has created a patent-pending Enterprise DevOps Framework (EDF) in which the traditional IT operations team is converted into a concept that we call the landing zone. The landing zone is where services deploy and as a result is focused on catching service agnostic components as they are delivered via pipelines. (Pipelines are processes designed specifically to automate the delivery of services into the landing zone.) In the EDF, the concept of a service-agnostic landing zone is very critical as is the idea of service teams owning more of their dependencies.
Within the EDF, automation is important as it increases agility, removes the potential for human error and also grows consistency across both process and output. With a golden AMI library, DevOps teams are able to use automation to replicate best practice instances, speeding the flow of services through the pipeline. Using golden AMIs to create new EC2 instances within your AWS environment brings major benefits, such as fast and stable applications. Moreover, as these AMIs all have the same base security agents installed with similar OS system settings, hardening, and more, golden AMIs give security and operations an opportunity to bake the agents that collect data for them in every image. For example, several of our customers use an SIEM solution and others use vulnerability detection software like AWS Inspector. Both can be baked into the golden AMI, helping ensure security standards are consistently met. For all these reasons, we actively use (and recommend you do, too) golden AMIs in our customer accounts.
Case in Point
For example, we worked with a large energy company on a project where we developed a Jenkins pipeline for image delivery. The primary thrust behind the application image pipeline was to enable developers to push their code to GitLab, and from here Jenkins would read the jenkinsfile, execute the necessary steps and create images. We automated the process with HashiCorp Packer which built, ran and registered the appropriate images as AWS AMIs.
We helped a broadband company migrate to AWS, building the framework for them and migrating initial applications, teaching them how to migrate subsequent applications. As a core part of the framework, we built the landing zone for this firm. A part of its landing zone were the golden AMIs and standard Ansible playbooks applied on top of them. The golden AMI included the logging and monitoring agents, security agent, vulnerability scanner, and CIS hardening practices. We automated the golden AMI creation using Packer and Ansible.
On top of the golden AMI, we used a set of Ansible playbooks to provision the AWS ECS agent, Docker engine, Logstash agent, and AWS SSM agent. This provided the final application AMI that could be used to run any Amazon ECS cluster. Last, we were able to verify using AMI ID and AWS Config Rules that the instances were launched by the golden AMI. This led to a solution where Development teams could spin up ECS clusters in a self-service manner, while the Ops team and InfoSec teams were confident that the clusters being built on-demand were compliant with corporate security policy. Thus, Golden AMIs played a key role in enabling a DevOpsSec strategy.
Best practices codified as golden AMIs enable you to build stable applications as it embeds the necessary elements to launch secure instances. Moreover, golden AMIs allow you to speed deployment, especially when coupled with automation like Packer which allows you to automate the launching of instances. And, automation further grows security as it eliminates human error that can occur in manual processes. For further reading on how DevOps automation can grow your stability and agility:
The Flux7 Enterprise DevOps Framework, a model for marrying DevOps process improvement with digital transformation.
Seven Steps to Successful and Sustainable DevOps Transformation
What is DevOps? And how do Code, Config, CI/CD & Containers Relate
DevOps Case Studies
Post Date: 12/21/2017