Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
  • Groups
    • Research Collaboration and Enablement
    • DesignStart
    • Education Hub
    • Innovation
    • Open Source Software and Platforms
  • Forums
    • AI and ML forum
    • Architectures and Processors forum
    • Arm Development Platforms forum
    • Arm Development Studio forum
    • Arm Virtual Hardware forum
    • Automotive forum
    • Compilers and Libraries forum
    • Graphics, Gaming, and VR forum
    • High Performance Computing (HPC) forum
    • Infrastructure Solutions forum
    • Internet of Things (IoT) forum
    • Keil forum
    • Morello Forum
    • Operating Systems forum
    • SoC Design and Simulation forum
    • 中文社区论区
  • Blogs
    • AI and ML blog
    • Announcements
    • Architectures and Processors blog
    • Automotive blog
    • Graphics, Gaming, and VR blog
    • High Performance Computing (HPC) blog
    • Infrastructure Solutions blog
    • Innovation blog
    • Internet of Things (IoT) blog
    • Operating Systems blog
    • Research Articles
    • SoC Design and Simulation blog
    • Smart Homes
    • Tools, Software and IDEs blog
    • Works on Arm blog
    • 中文社区博客
  • Support
    • Arm Support Services
    • Documentation
    • Downloads
    • Training
    • Arm Approved program
    • Arm Design Reviews
  • Community Help
  • More
  • Cancel
Arm Community blogs
Arm Community blogs
Infrastructure Solutions blog Cloud Native Application Deployment on AWS Graviton2
  • Blogs
  • Mentions
  • Sub-Groups
  • Tags
  • Jump...
  • Cancel
More blogs in Arm Community blogs
  • AI and ML blog

  • Announcements

  • Architectures and Processors blog

  • Automotive blog

  • Embedded blog

  • Graphics, Gaming, and VR blog

  • High Performance Computing (HPC) blog

  • Infrastructure Solutions blog

  • Internet of Things (IoT) blog

  • Operating Systems blog

  • SoC Design and Simulation blog

  • Tools, Software and IDEs blog

Tags
  • aws
  • Graviton2
  • infrastructure
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

Cloud Native Application Deployment on AWS Graviton2

Pranay Bakre
Pranay Bakre
September 30, 2020
5 minute read time.

Developers can now develop their containerized applications on AWS Graviton2 based EC2 instances using Amazon Elastic Kubernetes Service (EKS) and GitLab as their Continuous Integration (CI), Continuous Delivery (CD) natively on Arm architecture. Gitlab is a web-based DevOps platform that provides a git-based repository. A major feature of Gitlab is its CI/CD capability. Gitlab supports self-hosted runners deployed on Amazon M6g instances. These instances deliver 20% better price over comparable current generation x86-based instances and better performance for wide range of workloads.

Use case: Build and Deploy a MediaWiki application with Arm based Gitlab runners and EKS cluster.

  Figure 1 Architecture - EKS cluster and Gitlab runners on Arm-based instances

In this architecture, we deployed an EKS cluster on M6g instances, spread across two (2) availability zones for redundancy. We also configured an Application Load Balancer (ALB) for accessing the application. The source code of the application is hosted in a Gitlab repository. When we commit the source code of MediaWiki application into the Gitlab repository, a pipeline is triggered with the following stages: build, push, and deploy: 

  • In the build stage, the MediaWiki application containers are built with Gitlab runner deployed on a M6g instance.
  • In the push stage, the container images are pushed to Amazon Elastic Container Registry (ECR). ECR is a fully managed docker container registry by AWS that offers native and seamless integration with EKS.
  • In the deploy stage of the pipeline, the application images are pulled from the registry and deployed on our EKS cluster. Once the deployment is complete, the application is accessed via the ALB URL.

For this use case, we have used the source code and related config files hosted on the official MediaWiki docker hub repo.

The following video captures the application deployment workflow.

 

Configuration Details

Let us look at the following steps to configure this use case.

Here are the pre-requisites for building the use case:

  • Amazon Linux2 (arm64) deployed on each EC2 instance (or any other Linux distribution supported on Arm)
  • awscli installed on the client machine
  • kubectl utility to access the kubernetes cluster nodes
  • eksctl utility to provision the EKS cluster

EKS configuration:

Use the following source code to create a yaml file to provision our EKS cluster.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: arm-isv-demo
  region: us-east-1


Run the eksctl command to create the cluster using the YAML manifest file.


eksctl create cluster <YAML manifest file>

This starts the cluster creation process. We should be able to see the following output.

Figure 2 eksctl command output.

We can track the progress with the Cloud Formation service. In the AWS management console, navigate to the Cloud Formation dashboard, select the stack being created and switch to the events tab. Here we can observe the events related to the creation of our EKS cluster.

Figure 3 CloudFormation output for cluster creation

After the cluster is created, we should be able to see the cluster being created in the Elastic Kubernetes Service (EKS) Dashboard in Active status. 

Now, let us navigate to EKS Dashboard and select the cluster. Navigate to the Compute tab and click Add Node Group. Additionally, set the Name of a Node Group and the IAM role for worker nodes in the group.
Note: The IAM role should have the attached policies, depending on your needs and workflow. In this case, we are using the following AWS-managed policies.

Figure 4 IAM roles and policies

On the Compute and Scaling page please select Amazon Linux 2 (arm64) as your AMI type. Select the instance type of your choice and set the disk size for your worker nodes. We can also set the scaling configuration with Minimum, Maximum and Desired number of worker nodes in our Node Group. 

Figure 5 Node group Auto-scaling configuration

On the Networking page, please select the subnets where our worker nodes need to be placed. There will be four (4) subnets created by default for the EKS cluster. Also, select the security groups for the cluster. We are using ControlPlane and Cluster Nodes (security groups tags created by default with the EKS cluster). Please review all your data on the review page and create the Node Group. You should be able to see the new Node Group under your cluster in few minutes. Please wait for the status to become Active.

Figure 6 Node group details

Alternatively, we can also use the following command to check the status of the worker node in our EKS cluster.
kubectl get nodes

This shows the worker nodes and their running status.

Gitlab configuration:

In this section, we deploy an m6g.large EC2 instance in AWS and configure the Gitlab-runner for our project repository.

Log in to the EC2 instance and install gitlab-runner using the following command.

sudo yum install gitlab-runner

Instantiate gitlab-runner registration using the following command.

gitlab-runner register

Enter the following parameters:
- Name of Node
- Gitlab url
- Token from Gitlab
- Executor

Copy the registration token from Gitlab (CI/CD section of our project) and register the runner. After successful registration, we should see the runner associated with our project repository.

Here is our project repository in Gitlab:

Figure 7 Gitlab project repository

 All the source code and configuration files mentioned in this blog are hosted here. 

CI/CD workflow:

In this section, we cover the application deployment workflow. Starting from updating the code in the Gitlab repository to application deployment on EKS cluster.

Let us look at the current version of MediaWiki application pods running in our EKS cluster:

Figure 8 Applications pods running on EKS cluster

Now, we are going to make a simple change in the application’s source code. For instance, here we are changing the default logo to a new logo ‘Arm_logo’. In the Gitlab project repository, update the Dockerfile and LocalSettings.php files as shown in the following screenshot.

 

  

 

 Now, let us commit both of these files in Gitlab. Once the commit is done, a pipeline gets triggered:

 

  

Once the pipeline gets successfully completed, copy the ALB URL in the AWS console to access the new version of the application in the browser:

Conclusion:

As shown previously, developers can build their containerized application using AWS EKS with Gitlab CI/CD and leverage the cost and performance benefits of the AWS Graviton2 processors.

To learn more on running Gitlab on Arm architecture, please visit these sessions at Arm DevSummit or reach us here with questions or comments.

Anonymous
Infrastructure Solutions blog
  • Arm Neoverse V1 – Top-down Methodology for Performance Analysis & Telemetry Specification

    Jumana Mundichipparakkal
    Jumana Mundichipparakkal
    In this blog we introduce the Arm Neoverse V1 Performance Analysis Methodology whitepaper. This whitepaper is intended to help you optimize application code written for Neoverse V1-based production systems…
    • February 6, 2023
  • Improve Apache httpd performance up to 40% by deploying on Alibaba Cloud Yitian 710 instances

    Martin Ma
    Martin Ma
    In this blog, we look at the advantages of using Alibaba Yitian 710 CPU Arm-based instances for Apache httpd compared to x86-based instances.
    • January 5, 2023
  • Deep learning inference performance on the Yitian 710

    Honglin Zhu
    Honglin Zhu
    In this blog post, we focus on Alibaba Elastic Cloud Service (ECS) powered by Yitian 710 to test and compare the performance of deep learning inference.
    • December 19, 2022