Skip to main content

Cloud server with GitLab Runner

Last update:

GitLab Runner is open-source software used to automate and execute tasks (pipelines) in GitLab CI/CD. It acts as an agent that sequentially executes steps defined in pipeline tasks. It allows for automated building, testing, and deployment of applications and enables management of the entire CI/CD task execution process in GitLab.

You can create a cloud server with a pre-installed GitLab Runner application. The application runs inside a Docker container on the cloud server.

If you need to run multiple runners in one Docker container, increase the number of runners. To run multiple CI/CD tasks, enable parallel task execution.

In Russia, the server runs with a pre-configured SelectOS 1.1 64-bit operating system. In other countries — Ubuntu 22.04.

Before creating a cloud server with an application, review the software license agreements included in the image.

Minimum resource requirements

vCPU count2
RAM2 GB
Boot volume8 GB

Create a cloud server with GitLab Runner

For GitLab Runner to work in conjunction with a GitLab server from a different network, the cloud server running GitLab Runner must be accessible from the internet. To achieve this, when creating the server, you must create a private subnet and attach a public floating IP address. To configure GitLab Runner, when creating the server, you must specify user data — custom operating system configuration parameters.

  1. Optional: create a public floating IP address.

  2. Create a cloud server with GitLab Runner.

1. Optional: create a public floating IP address

Create a public floating IP address to ensure the cloud server with GitLab Runner is accessible from the internet.

Use the Create a public floating IP address section of the Public Floating IP Addresses guide.

2. Create a cloud server with GitLab Runner

  1. In the Control panel, on the top menu, click Products and select Cloud Servers.

  2. Click Create server.

  3. Fill in the blocks:

  4. Check the cloud server price.

  5. Click Create.

Name and placement

  1. Enter the server name. It will be set as the hostname in the operating system.

  2. Select a location where the server will be created. The available server configurations and resource costs depend on the location. You cannot change the location after the server is created.

Source

  1. Open the Applications tab.

  2. Select Cloud GitLab Runner.

  3. Optional: if you need a different current or archived application version, in the Version field, select the required version.

Configuration

Select a configuration from 2 vCPU, RAM starting from 2 GB and a boot disk size starting from 8 GB. For all lines, except Shared and Dedicated, two types of server configurations are available:

  • fixed configurations — ranges with different technical specifications where the resource ratio is fixed;
  • custom configurations — configurations where you can specify any resource ratio.

Configurations use different processors depending on the line and pool segment. You can customize the selected configuration. After the server is created, you will be able to change the configuration.

  1. Open the tab with the range.

  2. Click Fixed.

  3. Optional: you can adjust the configuration, if you are creating a server in a multi-AZ pool ru-6 segment or ru-3b, ru-7a, and ru-7b pool segments:

    3.1. Expand the block with the configuration settings description.

    3.2. Optional: select the processor manufacturer. Choosing the manufacturer is not available in all pools.

    3.3. Optional: if you do not want physical processor cores to be pinned to the cloud server vCPUs, clear the Dedicated cores checkbox. Learn more in the Dedicated Cores.

    3.4. Optional: if you want to disable Hyper-Threading for a server with dedicated cores, uncheck the Hyper-Threading (SMT) box.

    3.5. Optional: if you are creating a cloud server with dedicated cores and want to host a multiprocessor server on a single NUMA node, select the Mandatory placement on a single NUMA node checkbox. You can host a cloud server with 4 vCPUs or more on a single NUMA node. If the cloud server resources cannot be placed on a single node, the server will not be created. For more details, see the Placement on a single NUMA node section of the Dedicated Cores.

  4. Select a configuration.

  5. If both local and network volumes are available in the selected configuration, select the volume to be used as the boot disk:

    • local disk — check the Local SSD NVMe disk box. A server with a local disk can only be created from images and applications;
    • network volume — do not check the Local SSD NVMe disk box.

    The amount of RAM allocated to the server may be less than the amount specified in the configuration — the operating system kernel reserves a portion of RAM depending on the kernel version and distribution. You can check the allocated volume on the server using the command sudo dmesg | grep Memory.

Volumes

  1. If you did not check the Local SSD NVMe disk checkbox when setting up the configuration, the first specified network volume will be used as the server boot disk. To configure it:

    1.1. Select the type of network boot disk.

    1.2. Specify the size of the network boot disk in GB or TB. Observe the maximum size limits for network volumes.

    1.3. If you selected the Universal v2 or Fast SSD v2 disk type, specify the total number of read and write operations in IOPS. After the disk is created, you can change the number of IOPS — decrease or increase it. The number of IOPS changes is unlimited.

  2. In order to add additional network volume server :

    2.1. Click Add.

    2.2. Select the type of network volume.

    2.3. Specify the size of the network disk in GB or TB. Observe the maximum size limits for network volumes.

    2.4. If you chose the Universal v2 or SSD Fast v2 volume type, specify the total IOPS (read and write operations). After the volume is created you can change the IOPS — decrease or increase them. There is no limit to the number of IOPS changes.

    After creating the server, you will be able to attach new additional volumes.

Internet

Set up public access to the server.

The cloud server will be added to a private subnet that is connected to a cloud router with 1:1 NAT and internet access. Access to and from the internet will be performed through the cloud router. The server will be accessible from the internet via a public floating IP address.

  1. In the Connection from the internet field, select the Public floating IP address access type.

  2. Select the public floating IP address that you created in step 1.

Private network

A cloud server can be added to an existing or new private subnet.

  1. In the Subnet field, select a private subnet.

  2. Optional: in the IP address field, change the default IP address.

  3. In the Router field, select an existing router or create a new one.

    If the router is not connected to the internet, it will be automatically connected to the internet after the server is created.

Security

Select security groups to filter traffic on the server ports. Without security groups, traffic will be blocked. If the block is missing, traffic filtering (port security) is disabled in the server network. With traffic filtering disabled, all traffic will be allowed.

Access

  1. Place an SSH key for the project on the server for secure connection:

    1.1. If an SSH key for the project is not added to the cloud platform, click Add SSH key, enter the key name, paste the public key in OpenSSH format, and click Add.

    1.2. If an SSH key for the project is added to the cloud platform, in the SSH key field, select an existing key. An SSH key is only available in the pool where it is placed.

  2. Optional: in the Password for root field:

    2.1. Copy the password for the root user — the user with unrestricted privileges for all system actions.

    2.2. Save the password in a secure place and do not share it in plain text.

Additional settings

  1. Optional: if you plan to create multiple servers and want to increase infrastructure fault tolerance, add the server to a placement group:

    1.1. To create a new group, in the Placement group field, click Create.

    1.2. Select New group and enter the group name.

    1.3. Select a placement policy on different hosts:

    • preferred — soft-anti-affinity. The system will try to host the servers on different hosts. If there is no suitable host when creating the server, it will be created on the same host;
    • mandatory — anti-affinity. Servers in the group must be located on different hosts. If there is no suitable host when creating the server, the server will not be created.

    1.4. Once the group is created, in the Placement group field, select the placement group.

  2. Optional: to add additional information or filter servers in the list, add server tags. OS and configuration tags are added automatically. To add a new tag, in the Tags field, enter the tag.

  3. To add a script that will be executed using the cloud-init agent at the first operating system startup, in the Automation block in the User data field:

    • open the Text tab and paste the script as text;
    • or open the File tab and upload the file with the script.
#cloud-config

write_files:
- path: "/opt/gomplate/values/user-values.yaml"
  permissions: "0644"
  content: |
    gitlabURL: "<gitlab_server_url>"
    token: "<runner_token>"

Specify:

Increase the number of runners

  1. Connect to the cloud server.

  2. In the /opt/gomplate/templates/gitlab-runner-env.tpl file, add the URL:

    echo 'export RUNNER_GITLAB_URL_2="https://<gitlab_server_url>"' >> /opt/gomplate/templates/gitlab-runner-env.tpl

    Specify <gitlab_server_url>: the URL of the GitLab server that GitLab Runner connects to.

  3. If a second runner is being added for a different GitLab server, add the runner token to the /opt/gomplate/templates/gitlab-runner-env.tpl file:

    echo 'export RUNNER_REGISTRATION_TOKEN_2="<runner_token>"' >> /opt/gomplate/templates/gitlab-runner-env.tpl

    Specify <runner_token>: the registration token for GitLab Runner. You can obtain it following the Create a project runner with a runner authentication token instructions in the official GitLab documentation.

  4. To the /opt/gitlab-runner-pre-flight.sh script, add the registration of the new runner:

    • to the register_runner: function:

      sed -i '/register_runner () {/,/^}/ {
      /^}/ i\
      echo "Register additional runner"\
      docker run -i --rm \\\
          -v /etc/gitlab-runner:/etc/gitlab-runner \\\
          gitlab/gitlab-runner:ubuntu-v17.5.4 register \\\
          --non-interactive \\\
          --url "\${RUNNER_GITLAB_URL_2}" \\\
          --token "\${RUNNER_REGISTRATION_TOKEN_2}" \\\
          --template-config /etc/gitlab-runner/config-template.toml \\\
          --executor "docker" \\\
          \${RUNNER_ADDITIONAL_PARAMS}
      }' /opt/gitlab-runner-pre-flight.sh

    • to the register_legacy_runner: function:

      sed -i '/register_legacy_runner () {/,/^}/ {
      /^}/ i\
      echo "Register additional runner"\
      docker run -i --rm \\\
          -v /etc/gitlab-runner:/etc/gitlab-runner \\\
          gitlab/gitlab-runner:ubuntu-v17.5.4 register \\\
          --non-interactive \\\
          --url "\${RUNNER_GITLAB_URL_2}" \\\
          --registration-token "\${RUNNER_REGISTRATION_TOKEN_2}" \\\
          --template-config /etc/gitlab-runner/config-template.toml \\\
          --executor "docker" \\\
          \${RUNNER_ADDITIONAL_PARAMS}
      }' /opt/gitlab-runner-pre-flight.sh

  5. Restart the service:

    sudo systemctl restart gitlab-runner

Enable concurrent CI/CD job execution

warning

Concurrent CI/CD job execution may reduce runner performance.

  1. Connect to the cloud server.

  2. In the /etc/gitlab-runner/config.toml file, specify the number of concurrent jobs in the concurrent:

    sed -i '1 i\concurrent = 2' /etc/gitlab-runner/config.toml