8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23ai | Misc | PL/SQL | SQL | RAC | WebLogic | Linux
Home » Articles » Linux » Here
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
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...