Skip to content

Latest commit

 

History

History
executable file
·
80 lines (64 loc) · 3.9 KB

use-own-runner.md

File metadata and controls

executable file
·
80 lines (64 loc) · 3.9 KB

Use own runner

While using GitLab CI/CD functionality share runners are active by default. Shared runners does a great job except it comes to "more advanced" and powerful usage (disadvantages). GitLab has you covered! We do not know another CI/CD system giving the ability to run jobs so easily on your own server.

{% hint style="info" %} Below is an example of how you can create exactly one own Gitlab CI runner for your repository, running Docker as an executor. The following steps may differ for more complex or scalable scenarios. For more advanced usage refer to the official Runner documentation. {% endhint %}

Setup an own runner

  1. If you do not have yet your own server navigate to Scaleway and order one (the cheapest Linux server should be enough)
  2. SSH into your server (Scaleway explains while ordering how that works)
  3. Install docker and docker-compose on that server (see this for reference)
  4. Install gitlab-runner (see documentation)
  5. Register GitLab runner with Docker Executor onto your GitLab project or Group (see documentation)
  6. Open the configuration fileand modify as follow (see below example to know the exact position)
    • Add concurrent = 4 so jobs inside stages run parallel
    • Add "/var/run/docker.sock:/var/run/docker.sock" in volumes so jobs can access docker daemon to run containers in containers
  7. Restart Runner gitlab-runner restart

Configure your GitLab project

  1. Disable shared runners in GitLab > Project > CI/CD > Runners and enable the registered one
  2. Add variable $DOCKER_DAEMON_ALLOW_UP with value 1 in GitLab > Project > CI/CD > Variables
  3. Enable Review applications

{% hint style="info" %} Note #1: You can use one registered gitlab-runner (executor) for multiple projects. Note #2: If your server runs out of disk you need to configure a cleanup, read more here. {% endhint %}

Use cache

By default, the gitlab-runner cache does not work as expected. You need to configure an own S3-compatible cache. Here, minio comes to the game.

  1. Follow the complete introduction here
  2. Open the gitlab-runner configuration file and modify as follow (see below example to know the exact position)
    • Copy the complete [runners.cache] section into your configuration
    • Adjust the values XXX to yours
    • Make sure Insecure is false because you do not have setup HTTPS with minio
  3. Restart Runner gitlab-runner restart

Read more about it here.

Example configuration

A complete gitlab-runner with one executor configured can look like this:

concurrent = 4
check_interval = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "XXX"
  url = "https://gitlab.com"
  token = "XXX"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "alpine:latest"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
    shm_size = 0
  [runners.cache]
    Type = "s3"
    Path = "XXX"
    Shared = false
    [runners.cache.s3]
      ServerAddress = "XXX"
      AccessKey = "XXX"
      SecretKey = "XXX"
      BucketName = "runner"
      Insecure = true