Registering a Docker Executor Runner and Configuring GitLab CI Pipelines

This article is part of a "GitLab CI Practice" tutorial and shows how to prepare a Docker executor runner for GitLab CI.

To register a non‑interactive Docker runner, run the following command:

gitlab-runner register \
  --non-interactive \
  --executor "docker" \
  --docker-image alpine:latest \
  --url "http://192.168.1.200:30088/" \
  --registration-token "JRzzw2j1Ji6aBjwvkxAv" \
  --description "docker-runner" \
  --tag-list "newdocker" \
  --run-untagged="true" \
  --locked="false" \
  --access-level="not_protected"

After registration, the generated configuration file looks like this:

[[runners]]
  name = "docker-runner"
  url = "http://192.168.1.200:30088/"
  token = "xuaLZD7xUVviTsyeJAWh"
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
  [runners.docker]
    pull_policy = "if-not-present"
    tls_verify = false
    image = "alpine:latest"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0

When registering a runner, you must specify a default Docker image; all jobs using this Docker executor will run inside containers based on that image unless overridden at the job level.

Example job definitions using a specific image and tags:

#image: maven:3.6.3-jdk-8

before_script:
  - ls

build:
  image: maven:3.6.3-jdk-8
  stage: build
  tags:
    - newdocker
  script:
    - ls
    - sleep 2
    - echo "mvn clean "
    - sleep 10

deploy:
  stage: deploy
  tags:
    - newdocker
  script:
    - echo "deploy"

Services allow you to run additional Docker containers alongside the main job image, such as a MySQL database, which can be accessed during the build:

services:
  - name: mysql:latest
    alias: mysql-1

You can declare deployment environments and URLs, making them visible in GitLab’s environment UI:

deploy to production:
  stage: deploy
  script: git push production HEAD:master
  environment:
    name: production
    url: https://prod.example.com

The inherit keyword controls whether global variables or default settings are inherited by jobs. You can enable or disable inheritance globally or selectively:

inherit:
  default: false
  variables: false

Or inherit specific items using a list:

inherit:
  default:
    - parameter1
    - parameter2
  variables:
    - VARIABLE1
    - VARIABLE2

To promote template reuse and reduce duplicated code, the tutorial suggests creating a Git repository (e.g., demo/demo-gitlabci-service ) that holds a template directory for pipeline templates and a jobs directory for job templates. Projects can then reference these templates in their own .gitlab-ci.yml files for customized pipelines.