DevOps and Telco Softwarisation — a simple CI/CD example (2)
This article is the second part of 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”.
In this series of articles, we will explore the convergence happening between the IT and Telecom industries, which is referred to as “Telco Softwarisation”. Nowadays numerous companies are shipping software in minutes following a DevOps concept, called Continuous Integration and Continuous Delivery (CI/CD). It uses automation for building, testing and delivering software components to development and production environments with swiftness, safety and reliability, validating in a continuous way the value streams of an organization. A list of common tools and use cases will be discussed along the way of these articles.
As promised, we are moving ahead to understand how 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.
“It 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 log in 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:
- In the IAM Service of AWS, we click on “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 a username/password.
3. We choose the AWSElasticBeanstalkFullAccess permission to allow the user to deploy to EBS.
4. After reviewing the changes, the user should appear on the user list.
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:
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.
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.
This file consists 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.
1. pip install awscli – It installs awscli using python's pip. awscli is a command line tool to manage AWS.2. 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.3. aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY – similarly with the above, but this time for the aws_secret_access_key.4. 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.5. 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.6. 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.7. 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.
The web app BEFORE the deployment.
.
.
.
.
.
.
The 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.
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, please don’t forget to clap. It means a lot to me :)
I’m a Senior Consultant at Net Reply in the Future Networks team. Our team consists of consultants, software developers, technology enthusiasts specializing in Telecommunications and technological concepts such as Software Defined Networks (SDN) and Network Function Virtualisation (NFV). Our mission is to build the Next Generation Networks leveraging the art of software and the latest technological trends. If you would like more information on these, please contact me on s.moschos@reply.com. Alternatively, you can learn more about us on LinkedIn and Twitter.
👋 Join FAUN today and receive similar stories each week in your inbox! ️ Get your weekly dose of the must-read tech stories, news, and tutorials.
Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬
