Using Gitlab CI for deployments

Hi there folks!

This time we are going to talk about something different: using Gitlab and its CI system for deployments.

Gitlab CE (community edition) is an Open Source git platform that can be used to host your git repositories on a server. It offers most of the features offered by Github, with the advantage that you can host it on your own server.

Background

In my previous organization we were using Github for hosting our git repos and using git along with git hooks for deployment on the server (tutorial). Now with a bigger team we needed a pull request and merge based approach with deployments for the same. After evaluating the options available, my thoughts are as follows:

1. Custom Hooks

These are basically git’s server side hooks and only run when someone pushes to the repo.

Pros

• Easy to setup, supported by git, and documented.

Cons

• Not executed on merges.
• Difficult to redeploy.

2. Webhooks

These allow hitting a URL for certain actions / events like push, merge, etc.

Pros

• Easy to understand.
• Triggered on both pushes and merges.

Cons

• Need to setup a custom webhook handler for it on the deployment server.
• Since Gitlab’s webhook system does not allow to store any state (like whether the deployment succeeded, or is in progress), this information needs to be stored by the webhook handler on the server (I find Github’s webhook system much better in this regard).

3. Gitlab CI

This is Gitlab’s CI (Continuous Integration) and CD (Continuous Deployment) system.

Pros

• Quite featureful and customizable.
• Runs on both pushes and merges.
• Can be used to track deployment status and redeploy if needed.

Cons

• Higher learning curve.

Gitlab CI system looks like the more appropriate choice as per the requirements. Only thing now is to set it up.

 

Setting up the Gitlab Runner

Gitlab Runner is what we will be installing on the deployment server. Installation is simple but there is a question: which executor to use? Since we are deploying on the same server as the runner (and not doing anything else that needs a clean environment), we will be choosing the shell executor.

Whenever there is a commit in the Gitlab repo, the runner gets notified, places us in a checkout of the commit, and runs through what is specified in .gitlab-ci.yml (for example I wrote a bash script to transfer the changed files using rsync to a location in the docroot of the webserver).

Edit-

Here is a sample project which can deploy to a location on push (and remove the deployment if the source branch is deleted): gitlab-ci-sample.

And that’s it! Let me know in the comments if there are any questions.

P.S.

I have not used it myself, but Auto DevOps looks cool too.

Addendum

For deploying on live I found the following link helpful: https://florianbrinkmann.com/en/3473/deployment-gitlab-ci/

---

Extras

Deployment using Gitlab Runner as normal user (non-root)

By default gitlab runner is installed and run as a service using the root user, while running jobs as a non-root user (gitlab-runner).

More info: [link]

For setups like shared hosting root access is not available. So we can do it the following way:

1. Setup gitlab runner

gitlab-runner needs to be downloaded and registered with a gitlab account/project.

After registering it can be started using the run_gitlab_runner.sh script.

It can be monitored and kept running using monit (detailed below).

2. Setup monit to monitor gitlab runner

monit is used to monitor gitlab runner and restart it in case it fails.

It can be run using the run_monit.sh script. Before running monit .monitrc file would need to be setup (template provided).

Note- Files and instructions referenced above are available at gitlab-runner-as-normal-user.

Additionally, to ensure monit itself is running and kept running even on restart, it can be added to cron:

/home/youruser/scripts/run_monit.sh >> /home/youruser/logs/cron-service.log

Have been using this setup on multiple accounts for a few weeks now, running as expected! 🙂

Advertisement