Image courtesy of Pixabay
This article is the second part in the series. If you haven’t read the first part and you are interested in finding out about the foundations of DevOps i.e. CALMS framework, please have a look at “DevOps and Telco Softwarisation” (link).
The continuous DevOps loop delivers value in an efficient, quick and measurable way.
As promised, we are moving ahead to understand what a “feedback loop” looks like. There are various tools and services to achieve it but the principle of “Keep It Simple” will help us to identify the best options, according to my own experiences. Let’s start with the configuration of Gitlab CI to deploy a simple web app to AWS Elastic Beanstalk.
"Elastic Beanstalk is the fastest and simplest way to deploy your application on AWS." AWS
Add Your Project on Gitlab
If the repository does not exist already, we can create a ‘New project’ and then import the existing source code. It will appear in the project list, as shown below. For our example we are going to use a simple Java web app, which builds with Gradle.
Create Access keys on AWS
Provided that we have an AWS account and, also, an environment with an ‘up and running’ application in Elastic Beanstalk (see this simple example from AWS), we are moving on to create the access keys for AWS. We are doing this because we want to use Gitlab CI and therefore we will deploy automatically. If we were doing it manually, we would have to login to AWS using a username/password combination and also a multi-factor authentication (MFA) code.
To create the access keys, we follow the steps below:
1. In the IAM Service of AWS, we click on “Add user”.
Select ‘Add user’
2. We can add the name of preference and check “Programmatic access”,
which will enable our app to access AWS through the access keys and
therefore we will not have to provide username/password.
which will enable our app to access AWS through the access keys and
therefore we will not have to provide username/password.
Programmatic access will authorize our development tools to access AWS
3. We choose the AWSElasticBeanstalkFullAccess permission to allow the user to deploy to EBS.
AWSElasticBeanstalkFullAccess will let the user to deploy to EBS
4. After reviewing the changes, the user should appear on the user list.
“gitlab” user has now been created
5. Let’s click on our newly created “gitlab” user, then select “Security
Credentials” and create the access keys. The outcome will be as follows:
Credentials” and create the access keys. The outcome will be as follows:
The summary will show us the permissions/groups/tags and credentials of our user
Well, that was the entire AWS part and we can even test our access to Elastic Beanstalk using the AWS CLI. But it makes a lot more sense to go straight to Gitlab and setup our pipeline instead!
Setup Access Keys on Gitlab
Let’s move on with the setup of the access keys on Gitlab CI by heading to the project repository, then “Settings” and “CI/CD” on the left-hand side menu. In the “Variables” section, we are adding two new variables as shown in the screenshot below. It is very important to check the option “Mask variable” in order to avoid disclosing them e.g. they may appear in the logs of the pipeline.
Setup AWS access keys into Gitlab CI variables
Creating Gitlab CI/CD script
All we have to do in this step, is creating a gitlab-ci.yaml file in the root level of the project repository. Gitlab CI will go through each command and execute them one by one.
The gitlab-ci.yaml file will need to be added into the project repository
This file is consisted of four stages:
- lint
- build
- test
- deploy
The first stage — lint is a placeholder for a linting tool. In this example, the Gitlab logs will print the message “I am linting”.
The second stage — build consists of a build task that simply runs “gradle clean build”, which will build the web application and will create a .jar file. The task exposes the artefact so it will be used by the other task — deploy.
The third stage — test will execute “gradle check” and can be also configured to run the unit tests of the application.
The last and very important stage — deploy is the reason we will be able to see any committed changes of our codebase into the web app. Below the commands are explained in detail:
pip install awscli – It installs awscli using python's pip. awscli is a command line tool to manage AWS.aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID - It configures an access key ID that will be used in communication between GitLab's docker container and AWS. The variable that starts with $ sign has already been configured in the previous section of this article. GitLab CI/CD will recognize that it is a variable and will replace it with the configured value.aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY – similarly with the above, but this time for the aws_secret_access_key.aws configure set region eu-central-1 - It switches AWS region to eu-central-1. This is a location where is our Elastic Beanstalk environment. We can modify it according to the location of the environment we are. It is an equivalent of manually changing the region when we log into AWS Console through a web browser.aws s3 cp build/libs/test-service.jar s3://elasticbeanstalk-helloapp/helloApp-$CI_PIPELINE_ID.jar – It copies the jar file from the local (GitLab CI/CD's docker container) to S3 bucket. The address of S3 bucket can be found in AWS Console in the S3 area. $CI_PIPELINE_ID is a variable that contains a unique number for a pipeline. Every time a building and deploying process starts, a new number is assigned, and it is the same for both tasks.aws elasticbeanstalk create-application-version --application-name helloApp --version-label helloApp-$CI_PIPELINE_ID --source-bundle S3Bucket=elasticbeanstalk-helloapp,S3Key=helloApp-$CI_PIPELINE_ID.jar – it creates a new application version from the jar file that was copied in the previous step.aws elasticbeanstalk update-environment --application-name helloApp --environment-name helloApp-env --version-label helloApp-$CI_PIPELINE_ID – This is the final step that makes the actual deployment. It replaces the application with the newest created version from step 6.Finally, we are going to see how the pipeline works in reality and the results of this process. In the next screenshot, we can see the automatically triggered pipeline, after committing a small change in the codebase .
Triggered CI/CD pipeline.
Web app before the deployment.
Web app after the deployment.
Thank you for making it this far! In the next blog, we will see another
example of a CI/CD pipeline. This time it will be the pipeline setup of a
big 5G Telecommunications project.
example of a CI/CD pipeline. This time it will be the pipeline setup of a
big 5G Telecommunications project.
Please let me know in the comments or email me directly, if you enjoyed reading this article and you would like me to write on any other relevant topics.
Also published at https://smosgr.medium.com/devops-and-telco-softwarisation-simple-ci-cd-example-2-e4c615c96ec5