Build SAP Golden AMIs with EC2 Image Builder and Ansible

Introduction

Over the last few years, we’ve been sharing with you how to optimize the operations of your SAP workloads on AWS, using automation, through a series of blog posts. This includes using Terraform to provision AWS infrastructure for SAP, automating the installation and configuration of your SAP applications, and proving the resiliency of your environment through chaos engineering for SAP HANA. But we were still missing something critical, how to build the golden Amazon Machine Image (AMI) that you use as part of deploying this AWS infrastructure for SAP. So, in this blog post we’ll share how to build a reusable Amazon Machine Image (AMI) to deploy your Amazon Elastic Compute Cloud (EC2) instances, as part of your SAP installation, and provide some sample code for you to get started.

This approach uses EC2 Image Builder to bake (follow a series of procedures) a brand new AMI ready to receive an SAP installation. The code presented in this blog post supports both Oracle Enterprise Linux (OEL) and RedHat Enterprise Linux (RHEL) subscriptions from AWS Marketplace. The benefits of using this solution are:

1. Automated and repeatable process for creating SAP AMIs.
2. Simplify staying up to date with updates and security patches.
3. Enables an immutable infrastructure approach, which can improve the security, resiliency and consistency of your deployment.

To help you get started, we’ve shared sample code to automate this process to a GitHub repository for this automation.

The solution

This Terraform + Ansible code helps you to create the Golden AMIs for using with your SAP projects. This project creates two Golden AMIs: Red Hat Enterprise Linux (RHEL) and Oracle Enterprise Linux (OEL).

What is configured on the golden AMI

1. Install several packages using YUM: code
2. Install AWS CLI: code
3. Install AWS SAP Data Provider: code
4. Install EFS Utils: code
5. Disable Firewall: code
6. Set Clock Source: code
7. Set Timezone: code
8. Set UUIDD: code
9. Disable core dump, KSM, and SELINUX, enable TSX, Configure user limits for SAP, set general limits, set SAP conf and for tmp files, set tuned: code and code

All these configuration steps are listed as pre requisites in SAP on AWS Technical Documentation for SAP HANA, AWS Data Provider, SAP notes listed as RHEL requirements for SAP HANA on AWS, and some requirements for SAP NetWeaver as well. It is important to note that actions mentioned on the links that have to happen once the real SAP instance is up, such as setting the hostname, mount EBS and EFS volumes, etc, are not covered in this automation.

How to customize your instance configuration using the provided Ansible code

1. Make a copy/fork of this repository into your own one
2. Make the required changes in the folder “ansible”
3. Push your code to your own repository
4. Take a look at the file terraform/modules/ec2-image-builder/files/call_ansible_from_git.yaml
   On line 24 you’ll see it cloning this original repo from main branch. Update it to clone your own repository. Your new command will look close to this one:

   git clone https://USER:PASSWORD@github.com/my-org/my-repo.git

   Remember to update this command using your own GitHub credentials, and use SSH keys instead of passwords whenever possible.

5. Run the Terraform solution (jump to step 3 below)
   If this is not the first time you are running this Terraform, add a new entry on the dev.tfvars file under “versions” variable. This way you will create a new build and not discard the previous AMI(s) created

Running the solution

1. Manual tasks for creating the base AMI for RHEL/OEL/etc:

1.1 Subscribe to the RHEL AMI:

1.1.1 Open “AWS Marketplace Solutions” on your AWS console.

1.1.2 Navigate to “Discover Products” and search for “RHEL SAP”

1.1.3 Subscribe to the image named “Red Hat Enterprise Linux for SAP with HA and Update Services 8.2″Important: while this this automation code was tested with RHEL 8.2, newer versions should work as well. Keep in mind to spare some time to get it properly tested for your use case.

1.2       Launch an instance using your just subscribed image:

1.2.1      Make sure you’re logged in to the region where you want to have your AMIs built into.
1.2.2      Go to AWS Marketplace again and then “Manage subscriptions” on the left menu
1.2.3      Select the RHEL image you just subscribed (the date might vary from the one shown in the screenshot below).
1.2.4      Select “continue to launch through EC2”

1.2.5      The parameters you have to fill in are (all the rest you can leave as default):

Field	Suggested value	Comment
Name	rhel-base
Key pair name	any	Select one keypair you have access to (or create a new key pair and save it somewhere safe), which is necessary to SSH into the instance.
Allow SSH traffic from	My IP	Under network settings, select to create a new security group and allow SSH (port 22) via your IP only
IAM instance profile	ssm-role	Under “Advanced details”, click “Create new IAM profile” and follow the steps: 1. Click “Create Role”. 2. Select “AWS Service”. 3. Scroll down and select “EC2 Role for AWS Systems Manager”. 4. Select next. 5. Select next. 6. Add “ssm-role” on the role name. 7. Select “Create role”. Go back to the previous tab, hit refresh on the IAM instance profile and select your newly created “ssm-role”.
User data	Code on the right	Paste the code below on the user data field to install the SSM Agent automatically for you. #!/bin/bash cd /tmp sudo dnf install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm sudo systemctl enable amazon-ssm-agent sudo systemctl start amazon-ssm-agent

1.2.6      Click “Launch instance”
1.2.7      Make sure the step 1.2.6 is complete by going back into the EC2 console, select your instance, and click Connect. If the tab “Session Manager” doesn’t have any error and allows you to click “Connect”, leading to a new tab with an SSH session into your instance, it means the SSM agent is correctly installed and you are ready for the automated steps.

IMPORTANT! Make sure to check your SSM installation using step 1.2.7. If the SSM Agent installation is not correctly done, the automated steps with EC2 Image Builder will not work!

1.3 Create your BASE AMI for EC2 Image Builder to use:
1.3.1 Now back on the EC2 console, select your instance, click “Actions”, then “Image and templates”, then “Create image”.
1.3.2 Give it the name “rhel-base” and click “Create image”.
1.3.3 Go to “AMIs” on the menu on the left, find your new AMI and wait for it to be on Status “Available”.
1.3.4 Copy the AMI ID and save it somewhere safe
1.4 Clean up the resources:
1.4.1 Delete the rhel-base instance used for capturing the AMI
1.4.2 Delete the security group created for SSHing into the instance (named launch-wizard-X)

2        Manual tasks for creating the base AMI for OEL (Oracle Enterprise Linux)

2.1       Find your base AMI ID in this blog post from Oracle: https://forums.oracle.com/ords/apexds/post/launch-an-oracle-linux-instance-in-aws-9462
2.2       Once you find your AMI, on the list click “Launch instance from AMI”
Important: this automation is fully tested to work with OEL 8.8, though newer versions are similar and possibly will work out of the box as well.

2.3 Use the same instructions on step 1.2.4 above up until the end
2.4 After you are done creating your new AMI with the SSM Agent installed in it, for creating the new Parameter in Parameter Store (step 1.4.6 above), use the name /dev/ec2/amis/oel/base

Important! Many SAP on AWS customers use SUSE or other operating systems for their SAP landscapes. While EC2 Image Builder code remains basically the same, you can extend this solution to support SUSE installation by:

• Updating the Ansible code to prepare a SUSE OS for an SAP application
• Running the step 1 listed above for your SUSE installation
• Updating Terraform to generate a new AMI based off your SUSE base AMI
• Validating the generated AMI

3        Running the automation to create the golden AMIs

3.1       Create an S3 bucket to save your Terraform states and save its name. See how to create the bucket in this guide.
3.2       Update the file run_terraform_init.sh in this repo changing the value for the variable “BUCKET_NAME” with your new bucket.
3.3       Update the files run_terraform_init.sh and dev.tfvars with the region you want to use for this deployment.
3.4       IMPORTANT: for productive environments, the run_terraform_init.sh should be updated to include a Dynamo DB table too. This prevents errors in the Terraform State file caused by multiple people trying to update it at the same time. More details here.

3.5 In a console, cd into the terraform folder and run ./run_terraform_init.sh

terraform git:(main) ./run_terraform_init.sh

Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.
Initializing modules...
- ec2_image_builder in modules/ec2-image-builder
- ec2_image_builder.parameters in modules/ssm_parameters
- s3_bucket_ec2_image_builder in modules/s3
- sap_iam_roles in modules/iam

Initializing provider plugins...
- Reusing previous version of hashicorp/random from the dependency lock file
- Reusing previous version of hashicorp/aws from the dependency lock file
- Installing hashicorp/random v3.6.0...
- Installed hashicorp/random v3.6.0 (signed by HashiCorp)
- Installing hashicorp/aws v5.34.0...
- Installed hashicorp/aws v5.34.0 (signed by HashiCorp)

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

3.6 Rename the file dev.tfvars.template into dev.tfvars and replace the following values:

3.7 You can run both of them at the same time but also run OEL OR RHEL by commenting out the respective section in the tfvars file.
3.8 Run ./run_terraform_plan.sh and check the resources you are about to create
3.9 Run ./run_terraform_apply.sh
3.10 Results:
3.10.1 Once Terraform is done, your Golden AMI IDs will be available at EC2 > AMIs with a name prefixed with “Golden-AMI”.

3.10.2 Also, you can find them on the SSM Parameter Store under the names /dev/amis/golden/oel/sap-and-oracle and /dev/amis/golden/rhel/sap

4 Troubleshooting the image creation

For troubleshooting the image creation you have two alternatives:
4.1 Diving straight into the logs of each step. For this, go to CloudWatch > Log Groups, and look for “/aws/imagebuilder/dev-OEL-AMI-recipe” or “/aws/imagebuilder/dev-RHEL-AMI-recipe”. These log groups will contain all the steps taken for the installations for each of the version you launch.

4.2 To have an overview of all the steps applied during the creation, search for “EC2 Image Builder”, then go to “Images” on the left menu. Select the image you want to check, and on this page you’ll have the following resources:

4.2.1 Output resources – if your run finished and was successful, there will be the AMI generated for your build.

4.2.2 Infrastructure configuration – will show the infrastructure (EC2 instance) used for the build.

4.2.3 Distribution settings – shows to which accounts and regions the AMI is shared after the build finishes.

4.2.4 Workflow – get the detailed logs for all the 7 steps that EC2 Image Builder runs during the build.

Next steps

The code provided in this blog post helped you to create the AMIs in one account and one region. You can now extend the solution and update the Terraform code (file terraform/modules/ec2-image-builder/distribution_config.tf) to automatically share your AMIs to different regions and accounts. Make sure to apply the few pre requisites to your target accounts/regions before changing your distribution configuration. EC2 Image Builder is a free service to use, but the underlying infrastructure it uses, such as EC2 Instances and S3 storage are not. Check more details about the EC2 Image Builder pricing here.

Now go ahead, download the code in your local machine and start creating your AMIs using an standardized process! You can also customize the code to meet your needs, like adding a new OS support on Ansible (such as those who want to use SUSE Linux Enterprise Server), and also to customize your packages or install any agents required by your company policy.

If you are looking for expert guidance and project support as you move your SAP systems to a DevOps model, the AWS Professional Services Global SAP Specialty Practice can help. Increasingly, SAP on AWS customers—including Companies House Services and Phillips 66—are investing in engagements with our team to accelerate their SAP transformation. If you would like to learn more about how the AWS Professional Services team can help, you can contact them using this form.