8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23c | Misc | PL/SQL | SQL | RAC | WebLogic | Linux

Install and Configure a Gitlab Runner on Oracle Linux

This article describes how to install and configure a GitLab runner on Oracle Linux for use with CI/CD automation pipelines.

Assumptions
Install the Runner
Register the Runner
Use the Runner
What Next

Assumptions

This article assumes the following.

You are using Oracle Linux, RHEL or CentOS.
The installation and configuration actions are performed as the "root" user. If you are using an administrator user with SUDO privileges, simply add sudo to the front of each command.
You have GitLab repository, and want commits to that repository to trigger an action.
We are using a VM called OBVM1.
You will sometimes hear the term "build agent", which is the server with the GitLab runner on it. This could be a separate server that performs the actions to complete your deployment to a separate server, or the runner could run on the actual server that runs the code, such as an application server.

Install the Runner

There are multiple ways to install the GitLab runner software, but the one with the least maintenance is to use the GitLab runner repository. The following actions are performed as the "root" user.

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
yum install -y gitlab-runner

Updates will be picked up in the normal way.

# Just this package.
yum update -y gitlab-runner

# All packages, including this.
yum update -y

Register the Runner

Get the information needed to register the runner.

Log into https://gitlab.com/ and go to the repository.
Navigate to "Settings > CI/CD".
Click the "Expand" button next to the "Runners" section.
Scroll down the page and check the "Set up a specific Runner manually" section. It provides the following information.
- URL: https://gitlab.com/
- Registration Token: {YourToken}
Make a note of these values. You'll need them later.

Register the runner. The URL and token are those displayed above. The description is just text. I've given it the machine name.

gitlab-runner register -n \
  --url https://gitlab.com/ \
  --registration-token {YourToken} \
  --executor shell \
  --description "obvm1"

Check the runner is active.

service gitlab-runner status

Use the Runner

An explanation of how to use the running is beyond the scope of this post, but here is a simple example to test the runner is working as expected.

To use the runner you need a file called ".gitlab-ci.yml" in the root directory of your GitLab repository. This file can contain multiple stages associated with build, test and deploy operations. Here's a simple example with a single deploy stage, that echos some text to a file on the server. Remember to adjust the environment name and IP address as required. Notice this is "only" triggered by a commit on the "master" branch.

stages:
  - deploy

deploy_to_obvm1: 
  stage: deploy
  script:
  - echo "Deploy to OBVM1" >> "/tmp/deploy.txt"
  environment:
    name: obvm1
    url: 123.123.123.123
  only:
  - master

Make sure you commit and push the new file to the GitLab repository. Then do the following.

Log into https://gitlab.com/ and go to the repository.
Navigate to the "CI/CD > Pipelines" page.
On first commit of the file there will be a test of the pipeline. This is sometimes a little slow.
Wait until the test completes. If it fails, look at the errors and fix them. If it's fine, continue.
Click the "Run Pipeline" button, and again on the subsequent screen.

If everything has worked, you should have a new file on the server.

[root@obvm1 tmp]# cd /tmp
[root@obvm1 tmp]# cat ./deploy.txt
Deploy to OBVM1
[root@obvm1 tmp]#

Navigate to the "CI/CD > Jobs" page. You will see a list of previous jobs and their statuses.

The actions associated with the pipeline will now take place on every commit to the repository on the master branch.

What Next

What you do next depends on your requirements. Things to consider include the following.

Decide what your runner should do on a commit, and script accordingly.
Make sure the "gitlab-runner" OS user has the correct privileges to perform the actions, or sudo to perform them. This may include doing tests, builds and deploys to other servers.
You may prefer to have multiple deploy stages to deploy to all servers separately.
You may need multiple deploy stages associated with different branches if you are using something like GitFlow to handler you progression through "Dev > Test > UAT > Prod" etc.
The CI/CD pipeline can easily work with Docker, allowing a build agent to fire up a whole environment to perform testing, before a deploy process.

For more information see:

Hope this helps. Regards Tim...

Back to the Top.