Join us

Automated 5G Infrastructure deployment — the practical part


This talk was delivered during the internal Reply conference, Xchange 2021. In this article, we are going to start with some theoretical concepts and then we will explain in a more practical way by showing the results of our demo during the conference.

In the previous article (1/2), we have discussed the theory of DevOps and Infrastructure as Code. It’s now time to dig into the practical concepts of these topics and see the results of actual results from a CICD pipeline that runs Terraform and deploys the infrastructure for a Kubernetes cluster that can host a 5G networking solution (2/2).

The entire talk can be watched on the platform of the Xchange conference. It’s available for all Replyers and Reply’s customers.

First, in this practical article, we wanted to share the code used for the different Terraform demos. The <> files of each demo are shown also in the screenshots below.

Of course, we can do all these manually by typing a couple of commands on our local machine (assuming AWS credentials are set up). The commands we need to do this locally are:

  • terraform init — initialises the terraform providers used in the TF code.
  • terraform validate (optional) — validates the structure of Terraform codebase.
  • terraform plan — as the name suggests it will plan what type of infrastructure services will be deployed without doing so. Thus, it gives a good idea of what we will have when typing the following command.
  • terraform apply — this is the final step where the message of deploying the infrastructure will be “transmitted” to AWS. Remember Terraform is declarative code, which means whatever is listed will be deployed on AWS. Normally, we will be asked “if we are sure” about applying this code. If we cannot be asked then the flag “-auto-approve” will be required.
  • terraform destroy — finally, the infrastructure is not needed anymore we can destroy it. Similarly, with the previous command, we can use “-auto-approve”.

Terraform Automation

Automation couldn’t be missing from one of our articles since we have talked about DevOps, CI/CD and other automation concepts recently in previous blogs. Below we can see how a Gitlab CI (CI/CD) pipeline looks like in the context of provisioning the infrastructure. The three steps are responsible for automatically building (init & validate), deploy and, when needed, destroy the infrastructure.

As with any code the tools we need to trigger automatically this pipeline is our IDE (we used IntelliJ), git and the setup on Gitlab CI (gitlab-ci.yml is attached below). Once we make a change and push the code to our repository the pipeline will be triggered and the steps will be executed.

  name: rockcontent/terraform-awscli-kubectl-kops:0.14.3-1.17.3-1.17.1
    - '/usr/bin/env'
    - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'

  - build
  - deploy
  - destroy

    - rm -rf .terraform
    - terraform --version
    - cd infrastructure/02-AWS-EC2-Provision-Auto
    - cd infrastructure/03-EKS-Cluster-Deployment-Auto
    - terraform init
    - terraform destroy --auto-approve

  stage: build
    - terraform validate
    - terraform plan

  stage: deploy
  allow_failure: true
    - aws --version
    - terraform apply --auto-approve=true

  stage: destroy
    - terraform destroy --auto-approve
  when: manual

Finally, following the successful execution of the pipeline i.e. green pipeline, we will be able to browse to our AWS account in the EC2 section and see what instances have been initiated. Below we can see the t2.small EC2 instances created as part of the Elastic Kubernetes Service (EKS) when executing the TF files within the directory of “03-EKS-Cluster-Deployment-Auto”. Also a t2.micro server is created by the TF code in the directory of “02-AWS-EC2-Provision-Auto”.

Thank you!

Before you go away, we would like to thank you for reaching this point. I really hope we have managed to transfer some knowledge to you. This article has delved into the practical concepts of DevOps and Infrastructure as Code (IaC). Our the previous article provides a theoretical explanation to these. If you would like to explore more of these services and concepts, at Reply we are offering the opportunity to discuss these topics and adjust them to your services and needs. Feel free to browse at Reply Online Services (ROSe) — and book an appointment with us.

Find us at

Net Reply UK consists of software developers, technology enthusiasts specialising in Telecommunications and technological concepts such as Software Defined Networks (SDN), Network Function Virtualisation (NFV), DevOps. 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, feel free to reach out on LinkedIn (stelios-moschos) LinkedIn (thayná-dorneles). Alternatively, you can learn more about us on LinkedIn (Net UK) and Twitter (Net UK)

Only registered users can post comments. Please, login or signup.

Start blogging about your favorite technologies, reach more readers and earn rewards!

Join other developers and claim your FAUN account now!


Stelios Moschos

Software/DevOps engineer | Consulting @ | Blogging @
User Popularity



Total Hits