DevOps and Telco Softwarisation — a simple CI/CD example (2)

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 in “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 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”.

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.

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 Gi­­tlab 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 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.

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 commiting a small change in the codebase .

Image for post
Image for post
Web app before the deployment
Image for post
Image for post
Web app after the deployment

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 specialising 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 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.

DevOps/Software Engineer| Consulting | Mentoring | smos.gr

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store