CICD Auto Deployment Using Gitlab Runner - Deploy to Multiple Private Subnets EC2 Environment

1 year ago SETHA THAY 1596
CICD Auto Deployment Using Gitlab Runner - Deploy to Multiple Private Subnets EC2 Environment

In our previous blog post, CICD Auto Deploy Your Project Using Gitlab Runner, we show you how to use Gilab Runner to execute the jobs prepared by GitLab Pipeline to gain deployment time to the production server. By this means, we create only one pipeline linked with the git branch prod for getting the CD technique done.

We have another scenario: we want to use this CD technique in the development and user acceptance test (UAT) private subnet EC2 environment to release recently pushed code to the remote git branch master and stage. We still use the same guideline steps in this article, CICD Auto Deploy Your Project Using Gitlab Runner, but there are some modifications and additional instructions to fulfill the goal.


In order to support continuous deployment from two different git branches, we need to change the YAML file shown as below (Our test case branch master and stage)


From the above YAML file, we can describe as below

  • There are two defined stages
    • deploy_dev is used to define the job running in the development environment (master branch)
    • deploy_stage is used to define the job running in the user acceptance test (UAT) environment (stage branch)
  • Key (environment) uses to specify the environment in that jobs will be executed
  • Key (only) uses to tell the jobs which git branch to deploy the source code
  • You have to prepare two separate bash files for deployment to the development and UAT environment. (,

The deployment script is prepared the same as the previous article. Using private key stored in GitLab variable to SSH to server and finally pull the latest updated source code. However, in this scenario, the server (AWS EC2) is in private subnets that cannot access from outside and access limitation is controlled by in-bound rules of the AWS EC2 Security Group.


As you might know that the job is run by GitLab Runner (Can be Local / Online Cloud). If you are using GitLab online there is a high possibility that you might use the shared GitLab runner provided by GitLab itself. Therefore, we have to find a way to allow connection from AWS EC2 to Shared GitLab Runner, specifically IP Address to apply in the inbound rule of EC2. Based on the documentation provided by GitLab HERE mentioned that "For outgoing connections from CI/CD runners, we are not providing static IP addresses. All shared runners are deployed into the Google Cloud Platform (GCP) in us-east1. Any IP-based firewall can be configured by looking up IP address ranges or CIDR blocks for GCP."

According to the above statement, we can get IP address ranges or CIDR blocks for GCP of the region us-east1 using this link. For adding IP addresses of GCP we will not individually add to the inbound rules one by one, we will use "Managed prefix lists" as shown below


Then, you can attach the newly created managed prefix lists to inbound rules to allow SSH from the shared GitLab runner to AWS EC2 as shown below


As a result, while deploying your application using bash script you can easily SSH from Shared GitLab Runner to AWS Private Subnet EC2.

We hope this technique will help you in some ways with your project deployment. It is a small tip but it will save you a lot of time yes

Find Us @

About author

Author Profile


Software Engineer & Project Manager. I am willing to share IT knowledge, technical experiences and investment to financial freedom. Feel free to ask and contact me.

Scroll to Top