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.

UPDATE YAML FILE

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. (deployment-script-dev.sh, deployment-script-stage.sh)

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.

SETUP INBOUND RULES OF AWS EC2 FROM SHARED GitLab RUNNER

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 GitLab.com 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 

THANK YOU
Find Us @
Facebook
Telegram
Twitter
LinkedIn