{{announcement.body}}
{{announcement.title}}

Using EC2 Image Builder

DZone 's Guide to

Using EC2 Image Builder

Integrate EC2 Image Builder with other automation tools provided by Amazon to create longer pipelines—and efficient CI/CD cycles—without going to extra trouble.

· Cloud Zone ·
Free Resource

Modern CI/CD cycles force cloud infrastructure to be as agile as other components of the development and deployment process. After integrating security into the CI/CD cycle and adopting Infrastructure as Code, automation becomes the next thing to leverage.

Automation in cloud infrastructure, however, can be limited in its application. With image management, for instance, automation can only be done through scripts designed to create snapshots and maintain images.

EC2 Image Builder is Amazon’s answer to the growing demand for agile cloud infrastructure. As the name suggests, it is a fully managed and automated AWS service for the creation, management, and deployment of customized Images.

Image Creation, Simplified

EC2 Image Builder works not only with Amazon EC2 but also with on-premise infrastructure connected through AWS Outposts. Creating EC2 images that are ready to deploy becomes a simple process because it can now be done through a graphical user interface.

The real benefit of using EC2 Image Builder, however, can be felt when you start managing hundreds of images. That’s when keeping images up-to-date and maintaining your repository of images become complicated when done manually.

Keeping server images up-to-date can be time-consuming, resource-intensive, and error-prone. Currently, customers either manually update and snapshot VMs or have teams that build automation scripts to maintain images.

With EC2, images are automatically kept up-to-date and whenever there is a pending update (e.g., source AMI updates, security updates, updates to compliance, new tests, etc.), triggers get generated. Based on those triggers, new images are configured. 

The latest images can also be tested with the Image Builder to validate our applications on the updated builds. We can also subscribe to notifications via SNS queues for pending updates to images built with the Image Builder. We can use these notifications as triggers to build new images. 

EC2 Image Builder eliminates manual steps completely. The automation pipeline is also not needed—you don’t have to develop custom scripts for your CI/CD cycles or applications. Since the lack of proprietary scripts also means no code maintenance, image management and maintenance become incredibly efficient.

Integrated Security

Another big advantage of using EC2 Image Builder is the way it simplifies securing your VMs. You can, for instance, configure images to include only the essential components. Image Builder can recommend components that can be removed safely.

Security policies get implemented automatically during the image creation process. Known vulnerabilities are closed following Amazon’s information security best practices. Similar to image creation, Image Builder automates patch deployments and the implementation of custom security policies, allowing server administrators to focus more on aspects such as compliance and rapid delivery.

It is also worth noting that EC2 Image Builder supports a wide range of image formats. Naturally, it supports VM Import/Export natively, so you can easily create images for Amazon EC2 f. Support for Open Virtualization Format, VMware vSphere, and Microsoft Hyper-V are also available.

Another security feature that brings value to this tool is validation. There is a build-in image validation function, and it is highly tunable. Aside from following security standards defined by Amazon, you can also run validation tests for functionality and compatibility based on your own parameters. Automated validation allows for quality checks of images being deployed to a production environment.

Understanding The Core EC2 Image Builder Components

EC2 Image Builder is designed to be simple for most users, but that doesn’t mean it cannot be used to manage complex environments. With a source image prepared, there are several things you can do with your EC2 images.

First, you can customize the software installed in the image, which means images can have specific build environments depending on their intended purpose. A development image, for example, can have extra tools for debugging and testing.

You can also secure the images you build differently. Security patches can be applied across all images, but security policies, ports configuration, and firewalls can be defined differently. Even better, maintaining these different configurations is fully automated.

Tests, as mentioned before, will validate the images. You can test if certain patches are applied or if the security policy hampers your microservices before allowing images to be deployed; yes, Image Builder can automate flagging images too.

Everything is stored as an Amazon Machine Image (AMI) that can be deployed as EC2 instances right away. Additional components include Amazon EBS volume, IAM-related configurations, and security policies, and a unique AMI signature.

A Breakdown Of Core EC2 Image Builder Components

EC2 image builder includes the following:

  • Image Pipeline: This defines the process for customizing the images. It consists of the image recipe, build components, infrastructure configuration, distribution, and test settings.
  • Image Recipe: We can add components and tests in the recipe which specifies the activities needed to make changes to the source image. A recipe cannot be modified once it is created but we can reuse it for duplicate builds. We can also use image recipes with our version control software to maintain shareable versioned image recipes and implement a CI/CD pipeline for repeatable automation.
  • Source Image: The source image is the OS image that can be either an existing AMI or an Amazon EBS snapshot.
  • Build Components: Components are consumed by an image recipe. We can add packages for installation, security hardening steps, and tests here. The selected OS and components make up an image recipe. Components are installed in the order in which they are specified and cannot be reordered after selection.
  • Tests: Tests are the orchestration documents that run on software packages. The tests validate the images before using them in production with AWS provided or custom tests. We can also create custom tests using a script. 
  • Document:  It is a declarative text document written in YAML format which is used for executing the build, validation, and test of an AMI on an instance. The document is input to a configuration management application, which runs locally on an Amazon EC2 instance to execute the document steps.

Benefits Of EC2 Image Builder

The advantages of using the AWS service include:

  • Improved IT productivity
  • Simple to secure
  • Simple image management for both AWS and on-premises
  • Built-in validation support
  • Centralized policy enforcement

Image Builder is present in all AWS regions at no cost, other than the cost of the underlying AWS resources used to create, store, and share the images. We can also share these generated images to different regions, different AWS accounts, and also to on-premises machines.

Adding A Pipeline

Interestingly, the EC2 Image Builder service even lets you turn the process of creating and maintaining EC2 images into a highly efficient workflow. When creating a new image, you immediately have access to build components provided by Amazon, which means Python 3 or PowerShell Core are immediately available.

As mentioned, creating tests is just as comprehensive a process. EC2 Image Builder lets you schedule tasks—including tests—using standard CRON expression. Make sure you configure the infrastructure settings to define EC2 instance type and details such as VPC.

When we use the AWS console to leverage the EC2 Image Builder, we go through the following steps:

  • Login to the EC2 image builder console and choose to "create image pipeline."
  • We need to select the Linux or Windows in the image operating system and then we can go with either managed AMI or custom AMI by browsing the images.
  • When we browse the images we can see the images as below, here we can select the required image.
  • If we always want the latest version to be built, then tick the checkbox.
  • In the build component section, we can select the components we require. They can either be an AWS provided one or a custom one. If we want to use a custom component, we can create one by selecting the ‘Create build component’ option or we can choose from existing components under the ‘Browse build components’ option.
  • We can select multiple build components as shown here.
  • In order to validate our image before using it in production, we can run a test on it—either a custom test or an AWS provided test. It is possible to add multiple tests.
  • If we want a custom test or custom components to be performed, we need to write a document that consists of a YAML script by selecting the ‘Create test’ or we can choose from the ‘Browse tests’ option to use a test example.
  • Name the pipeline and give some description(optional) in the "Configure pipeline" screen. An IAM role must be provided which has an EC2 instance profile and AWS SSM managed instance core permissions to perform necessary tests.
  • We can run the pipeline manually or we can schedule it by using a maintenance window or by writing a CRON expression. Even if we schedule the build, we can overwrite the schedule and run the build whenever we want.
  • The EC2 instance type must be selected here. We can choose the SNS topic if we have one or can create it—this infrastructure setting is optional though. 
  • As this pipeline launches an instance in the backend to run the tests in order to provide the image, we can select the VPC, subnet ID, and security groups where the instance can be launched. We can also specify the keypair, instance settings, and location in which to save our logs.
  • If we have a license we can associate it with our AMI or we can leave this as it is (also optional). Name the AMI in the output AMI and add tags here too.
  • Next, we need to select the regions here in order to distribute the image. If we set the launch permission as private, the image is only shared to a configured account (but the account number must be added) or region which we specify, but if it is public it can be accessed by everyone.
  • Review and create the pipeline. You’ll then see the below status as ‘Enabled’ which means the image pipeline is created successfully. We can run the pipeline by selecting the ‘Run pipeline’ option.
  • If we go to our image pipeline screen, it shows the status of our build as ‘Building, in the output image.
  • When we run the pipeline, it shows the steps executed as per the image below in ‘Automation’ in the AWS Systems Manager console. We can also send logs to our S3 bucket from here so, it is very easy to troubleshoot any issues. 
  • If the build is successful, we can see the status as ‘available’ and if it is failed it displays the reason for the failure to allow you to resolve and try again. 
  • The image generated after completion of this build is displayed in the images in EC2 image builder dashboard.

And there we have it, a successfully implemented pipeline from start to finish and completed image build. When used properly, the EC2 Image Builder simplifies image management and maintenance completely. 

The fact that you can integrate EC2 Image Builder with other automation tools also provided by Amazon means you can create longer pipelines—and efficient CI/CD cycles—without going to extra trouble.

Topics:
agile adoption, aws, aws architect, cicd, cicd pipeline, cloud infrastructure, ec2, ec2 image, image building

Published at DZone with permission of kavya sri . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}