Resource relationships in Managed Service for GitLab

GitLab is an open-source web-based DevOps lifecycle tool. It is a code repository management system for Git with error tracking, CI/CD pipeline, dedicated Wiki, and other features.

Managed Service for GitLab helps configure application deployment on VMs in Yandex Compute Cloud and supports integration with Yandex Container Registry and Yandex Managed Service for Kubernetes.

How Managed Service for GitLab works:

GitLab instanceGitLab instance

A GitLab instance is the main entity in Managed Service for GitLab. It is a VM deployed in Yandex Cloud. Managed Service for GitLab takes care of its routine maintenance, such as ensuring storage fault tolerance, applying security patches, automatically upgrading the GitLab version, and more.

Users can mange instances from the Yandex Cloud management console, CLI, and API.

Instance configurationInstance configuration

When creating an instance, you specify:

• Instance type: Number of vCPUs and RAM amount. Below are available instance types:

  Type	Computing resources
  s2.micro	2 vCPUs, 8 GB RAM
  s2.small	4 vCPUs, 16 GB RAM
  s2.medium	8 vCPUs, 32 GB RAM
  s2.large	16 vCPUs, 64 GB RAM

  After you create an instance, you can upgrade its type to a higher performing one.

• Subnet.

  Warning

  Currently, Yandex Cloud technical restrictions do not allow selecting a subnet with the 192.168.0.0/24 address range.

• Disk size. After you create an instance, you can increase its disk size.

• Name in the .gitlab.yandexcloud.net domain: Your GitLab instance's internet address.

• Administrator information:

  • Email.
  • Login.

GitLab RunnerGitLab Runner

GitLab Runner is an open-source application that runs GitLab CI/CD pipeline jobs based on instructions from a special file named .gitlab-ci.yml. It helps run automated builds in Managed Service for Kubernetes clusters and on Compute Cloud VMs.

You can get started with GitLab Runner in the following ways:

• Install GitLab Runner in a Managed Service for Kubernetes cluster.
• Create a Compute Cloud VM and install GitLab Runner on it manually.
• Create a runner managed by Yandex Cloud.

Managed runnersManaged runners

In Managed Service for GitLab, you can create a managed runner that automatically deploys a specified number of Compute Cloud VMs with installed GitLab workers. The managed runner also scales out the worker VMs to accommodate the load.

You can specify the following managed runner settings:

• Scaling settings:

  • Minimum workers: Number of workers that are always running and ready to execute jobs. Default value: 1; minimum: 0; maximum: 10.
  • Maximum workers: Maximum number of workers that can be created to execute jobs. Default value: 3; minimum: 1; maximum: 30. The maximum number of workers cannot be less than the minimum number.
  • Maximum worker downtime, in minutes: Maximum idle time after which the additionally created worker will be deleted. Default value: 10; minimum: 0.
  • Maximum number of jobs per worker: Maximum number of jobs after which the worker will be deleted. Default value: 100; minimum: 0.
  • Number of parallel tasks per worker: Number of parallel jobs per worker. Default value: 1; minimum: 0.

• Worker VM settings:

  • Worker computing resource configuration:

    • 2 vCPUs, 4 GB RAM
    • 2 vCPUs, 8 GB RAM
    • 4 vCPUs, 16 GB RAM
    • 8 vCPUs, 64 GB RAM
    • 16 vCPUs, 128 GB RAM

  • Disk type (HDD or SSD) and size. For more information, see Disk types.

  • Service account.

    Note

    This service account will be associated with the worker VM. The worker can use the account to authenticate in the Yandex Cloud API and access cloud resources.

    Assign your service account a role for the resource you want to manage.

  • Security group.

For more on managed runners, see these pages:

• Working with a managed runner
• Deploying GitLab Runner on a Yandex Compute Cloud virtual machine

Networking between GitLab and managed runnersNetworking between GitLab and managed runners

The subnet of the instance the managed runner is connected to must have internet access via a NAT gateway or NAT instance.

To set up networking between GitLab and managed runners, you need to configure required, recommended, and optional security group settings.

Rules for incoming trafficRules for incoming traffic

Rule purpose	Rule settings
To manage the runner from the GitLab instance over SSH. This is a required rule.	Port range: 22. Protocol: TCP. Source: CIDR. CIDR blocks: CIDRs of all subnets where runners may run. Instead of a CIDR, you can specify a security group created for runners.

Rules for outgoing trafficRules for outgoing traffic

Rule purpose	Rule settings
To access the GitLab instance's public address over HTTPS, e.g., for cloning repositories or downloading artifacts. This is a required rule.	Port range: 443. Protocol: TCP. Source: CIDR. CIDR blocks: public GitLab address.
To access the artifact registry, e.g., Cloud Registry or dockerhub.io. This is a recommended rule.	Port range: 443, 5000, or other. Protocol: TCP. Source: CIDR. CIDR blocks: CIDRs of the registries to which access is granted. To allow traffic to any IP addresses, specify 0.0.0.0/0.
To access object storages, e.g., LFS or Container Registry. This is a recommended rule.	Port range: 443. Protocol: TCP. Source: CIDR. CIDR blocks: CIDRs of the object storages to which access is granted. To allow traffic to any IP addresses, specify 0.0.0.0/0.
To access external resources. This is an optional rule.	Port range: 443, 80, or other. Protocol: TCP. Source: CIDR. CIDR blocks: CIDRs of external resources. If the list of resources is not defined, you can allow outgoing traffic to any addresses (the 0.0.0.0/0 CIDR) on all ports. In this case, you can skip configuring the recommended rules and access from a managed runner to the GitLab instance's public address.

GitLab PagesGitLab Pages

GitLab Pages is a tool for publishing static websites composed of files residing in a GitLab repository. Websites are deployed via GitLab CI/CD jobs. GitLab Pages works with static website generators and standard HTML, CSS, and JavaScript files.

GitLab Pages enables you to use your own domains and SSL/TLS certificates and to configure access to websites.

For more information, see this GitLab article.

Use casesUse cases

• Secure storage of GitLab CI passwords as Yandex Lockbox secrets
• Building a CI/CD pipeline with serverless products
• Deploying GitLab Runner on a Yandex Compute Cloud virtual machine
• Continuous deployment of containerized Managed Service for Kubernetes applications