Gitlab CI/CD Pipeline

What is Gitlab?

Gitlab is a DevOps platform and lifecycle tool that provides Git repository management providing endless possibilities. Organizations rely on Gitlab’s source code management, CI/CD, security and many more options to deliver a software rapidly.

In this article we will explore CI/CD setup and configuration for our development pipeline. If you are new to Gitlab or CI/CD configuration, integration, and deployment. This is a basic guide and complete package for everyone.

Prerequisite

Gitlab project, environment, and credentials
Development editor e.g. VS Code or any other IDE
Docker for containerization
Node and npm for dependencies (We will use node project in this articles)

We will break this article into three steps.

Docker file and docker-compose.yml configuration
Gitlab setup and pipeline
Deployment configuration

DockerFile

Docker can build images automatically by reading the instructions from a Dockerfile. A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image.

Let’s take an example of a sample application that contains a UI and backend. We will setup a DockerFile with mono-repo architecture containing UI, backend, node and nginx images.

Through this docker file we can successfully create our desired images for our web application that we can be used for later stages. We can create image manually through docker build command or it can be done directly using docker-compose file which is shown in next step. Docker image can be created using below command

docker build -t image name .

This will create an image wrapping front-end and back-end into docker image under app folder.

Docker compose file

Compose is a tool for defining and running multi-container docker applications. With Compose, you use a YAML file to configure your application’s services.

docker-compose.yml

To wrap mono-repo into docker containers. First, we create Dockerfile that can create our images for UI & Back-end. Then we create docker-compose file which directly create and build images and up the containers for UI, Back-end & nginx.

We have three services in our docker compose file. Nginx is directly building and creating image from compose file as per our approach and we need docker file to create images for our CI/CD pipeline.

To run our application, we need to run one command only i.e. docker-compose up

As shown in below image, we have three containers up and running with docker images as well named node, nginx & our app image.

We can check containers details on which port they are running using command i.e. docker ps -a and directly access on mentioned ports which is configured in above files.

We can also check logs individually through UI as well as commands. Plugins for docker also available which are very handy to use. We can right click on any container and click logs which shows logs for specific container.

We can stop containers using docker-compose down

Step # 02

Moving container to CI/CD using Gitlab

Configuration for pipeline includes below steps:

Gitlab runner for connection
Gitlab-ci yml file to trigger pipeline
Gitlab Variables & access to container registry
SSH connection

Runner setup

Open GitLab project under Settings, you can see different options
- https://gitlab.com/project_name/app_name/-/settings/ci_cd

Through this we can setup our runner on which our pipeline jobs will be executed.

Shared Runner VS Specific Runner

Shared runners won’t access VPN and it can be dangerous to run your pipeline on shared runner due to privacy concerns as ports or other details can be accessed. While, specific runner can be setup on your own servers.

Hence, we can setup our own runner to any available server. We can run these runners on any server. In this article we will configure on Ubuntu server.

Follow this link for Ubuntu and install mentioned commands on server
https://docs.gitlab.com/runner/install/linux-manually.html

After that we can register runner using this link
https://docs.gitlab.com/runner/register/index.html#gnulinux

We also need to give permissions to runner so that it can access pipeline with sudo mode. After runner configuration. We can start/stop/restart or run runner anytime. Runner would be online all the time so that Jobs can be run automatically.

Note

Make sure shared runners should be disable so that jobs can be run on our specific runner.

After configuring runner, we need to change some configuration in runner config file. [See snapshot below]
set privileged = true

Gitlab yml file creation

Next step is to create gitlab-ci.yml file which will trigger on code push. We can run directly through Gitlab pipelines tab anytime on any branch.

.yml file includes three stages.

Stages:
- test
- build
- deploy

test — run unit test tests
build — create image and publish on Gitlab container registry
deploy — publish image and accessible through server

There are some useful features of GitLab that we can use. For instance, we can do manual trigger on any branch using Run pipeline. We can use GitLab Variables under settings CI/CD. Variables that can be accessible in pipeline script. Also, explore other features of GitLab that are mentioned in detail in another article.

Stages of pipeline script

Build — it contains docker image which firstly login to docker registry of Gitlab through access token and username, after successful login, it pulls image if no changes made, otherwise it build image using docker file and push new image to GitLab container registry. Note that it overwrites previous image with new one each time it made any changes.

After running build, go under Packages and Registries — Container registry. You can see an image here that is published.

Deploy — After successfully publish image to container registry, in deployment stage — it made connection with server and run few tasks on it mentioned below.

• remove old images and containers
• login to the registry on server through username and access token
• remove code-base if exists previously
• clone code base
• checkout specific branch
• move into that directory
• npm install
• down container if there are any up and running
• last step is to up the containers using pulled image in detached mode

We can check logs, containers details, images on deployed server as well by running same commands that mentioned in local deployment above.

After running all jobs successfully, we can able to access our application.

http://url-of-your-application:4200/ — — UI
http://url-of-your-application:4040/# — — BE
http://url-of-your-application/ — — nginx

We can also set reverse proxy configuration. Though this we can re-route app directly to app url without passing port number. This can be shown in another article.