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 CI to deploy a simple web app to . Gitlab 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 , which builds with . a simple Java web app 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 ( ), 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 . 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. see this simple example from AWS deploy automatically To create the access keys, we follow the steps below: In the IAM Service of AWS, we click on “Add user”. 1. Select ‘Add user’ 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. 2. Programmatic access will authorize our development tools to access AWS We choose the permission to allow the user to deploy to EBS. 3. AWSElasticBeanstalkFullAccess AWSElasticBeanstalkFullAccess will let the user to deploy to EBS After reviewing the changes, the user should appear on the user list. 4. “gitlab” user has now been created Let’s click on our newly created “gitlab” user, then select “Security Credentials” and create the access keys. The outcome will be as follows: 5. 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 . But it makes a lot more sense to go straight to Gitlab and setup our pipeline instead! AWS CLI 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 “ ” and “ ” on the left-hand side menu. In the “ ” section, we are adding two new variables as shown in the screenshot below. It is very important to check the option “ ” in order to avoid disclosing them e.g. they may appear in the logs of the pipeline. Settings CI/CD Variables Mask variable Setup AWS access keys into Gitlab CI variables Creating Gitlab CI/CD script All we have to do in this step, is creating a file in the root level of the project repository. Gitlab CI will go through each command and execute them one by one. gitlab-ci.yaml 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 — is a placeholder for a linting tool. In this example, the Gitlab logs will print the message “I am linting”. lint The second stage — 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. build The third stage — will execute “gradle check” and can be also configured to run the unit tests of the application. test The last and very important stage — 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: deploy 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 communication between GitLab in '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 the above, but time the aws_secret_access_key. with this for aws configure set region eu-central - It switches AWS region to eu-central This is a location where is our Elastic Beanstalk environment. We can modify it according to the location the environment we are. It is an equivalent manually changing the region when we log into AWS Console through a web browser. -1 -1. of of 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 application version the jar file that was copied the previous step. new from in 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 the newest created version step with from 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. 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
