{"id":3503,"date":"2018-03-30T23:12:28","date_gmt":"2018-03-30T21:12:28","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=3503"},"modified":"2023-06-09T14:22:37","modified_gmt":"2023-06-09T12:22:37","slug":"ci-cd-with-gitlab-ci-for-a-web-application-part-2","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2018\/03\/30\/ci-cd-with-gitlab-ci-for-a-web-application-part-2\/","title":{"rendered":"CI\/CD with GitLab CI for a web application – Part 2"},"content":{"rendered":"

GitLab<\/h1>\n

Our first approach was to use the existing GitLab instance of HdM for our project. For them, a shared runner was already defined on which we could run our jobs, so we were able to focus on the CI process itself. This plan worked out at first. We simply defined build and test jobs, which passed without any problems. But when we tried to deploy to our staging server we were a bit confused, because no matter what we tried, the SSH connection to the server could not be established. Even after several reconfigurations of the keys and rewriting of the job we did not succeed, which was surprising, because we could connect to the server from our PC via SSH without problems. Finally, we found out that the HdM firewall blocked our SSH connection to the outside. Since the “HdM-GitLab solution” seemed to be a dead end, we decided to set up our own GitLab instance to be independent of external configurations.
\n<\/p>\n

Setting up your own GitLab instance<\/b><\/h2>\n

It is recommended to have at least 4GB of RAM available on the machine on which you want to host GitLab (more on that later). We decided to host it on a t2.medium instance on Amazon Web Services (running Ubuntu). It provides the necessary specifications without completely emptying one’s wallet. In the process of launching a new instance, you can choose an appropriate AMI of GitLab. This will basically relieve you of any further installation duties. Under the tag Community AMIs you will find different versions of the Enterprise or Community Edition. We went for the newest version of the Community Edition. It is essential to specify open ports for SSH (22) and HTTP (80). Therefore you need to configure a security group in your AWS interface. Under “Security Groups” you can edit existing groups or add new ones. After making sure the appropriate ports are opened for inbound traffic, you need to assign the security group to the EC2 instance.<\/p>\n

After everything is set up you can access your GitLab instance via your preferred browser.<\/p>\n

Setting up a GitLab Runner<\/b><\/h2>\n

Before we are able to use the Runner, which uses the Docker executor, we first need to install docker on our server. SSH into your AWS server and execute the following commands to install docker (updating the apt package index and then install docker-ce<\/em>).<\/p>\n

Now that we have got Docker installed, we can get to installing and configuring the runner. First we need to add GitLab’s official repository and then install gitlab-runner<\/em>.<\/p>\n

Now we can use the CLI to register a new runner, on which the jobs of our CI pipeline are executed. Just execute sudo gitlab-runner register <\/em>and answer the questions of the the command dialog. When asked for the coordinator URL, simply put in the URL of your GitLab instance. You will find the token for registering the runner under Runner settings inside the CI\/CD settings. There is no need to add any tags or set up the runner as unlocked. But all if this can also be changed later in the GitLab UI. As executor choose docker and as default image choose node. The default image will be used, if there is none defined in the .gitlab-ci.yml<\/em> file (which we will do anyway).<\/p>\n

Defintion of the pipeline<\/b><\/h2>\n

The essential file to specify the continuous integration pipeline is the .gitlab-ci.yml<\/em> file, which needs to be put inside the root folder of the project. The file serves as the definition of the stages and jobs of the pipeline.<\/p>\n

First of all we need to define the Docker image, which is used to run the jobs. In our case we want to use the Node.js image, therefore we simply add image: node<\/em> to the yaml file. The CI executor will pull images from the the Docker Hub, so any of the pre-built images can be used here. The described code would use the latest node image, but you may also specify a different version by for example adding image: node:8:10:0 <\/em>instead.<\/p>\n

You can also define services (for example databases), which should be used, in the same manner. Any image available on the Docker Hub is possible. Since we use MongoDB as a database, we add the following to the file.<\/p>\n

services:\n   - mongo<\/pre>\n
Our pipeline consists of 4 stages, which are defined as follows:<\/p>\n