[Yandex Cloud documentation](../../index.md) > [Yandex Managed Service for GitLab](../index.md) > Concepts > Resource relationships

# Resource relationships in Managed Service for GitLab

[GitLab](https://about.gitlab.com/) is an open-source web-based DevOps lifecycle tool. It is a code repository management system for [Git](https://git-scm.com/) with error tracking, [CI/CD](https://en.wikipedia.org/wiki/CI/CD) pipeline, dedicated Wiki, and other features.

Managed Service for GitLab helps configure application deployment on [VMs](../../compute/concepts/vm.md) in [Yandex Compute Cloud](../../compute/index.md) and supports integration with [Yandex Container Registry](../../container-registry/index.md) and [Yandex Managed Service for Kubernetes](../../managed-kubernetes/index.md).

How Managed Service for GitLab works:

![image](../../_assets/managed-gitlab/gitlab_schema_en.svg)

## GitLab instance {#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](https://console.yandex.cloud), [CLI](../cli-ref/index.md), and [API](../api-ref/authentication.md).

## Instance configuration {#config}

When creating an instance, you specify:
* Instance type: [Number of vCPUs and RAM amount](../../compute/concepts/vm-platforms.md). 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](../operations/instance/instance-update.md) to a higher performing one.
* [Subnet](../../vpc/concepts/network.md#subnet).

  {% note warning %}
  
  Currently, Yandex Cloud technical restrictions do not allow selecting a subnet with the `192.168.0.0/24` address range.
  
  {% endnote %}

* Disk size. After you create an instance, [you can increase](../operations/instance/instance-update.md) its disk size.
* Name in the `.gitlab.yandexcloud.net` domain: Your GitLab instance's internet address.
* Administrator information:
  * Email.
  * Login.

{% note info %}

When you create an instance in Managed Service for GitLab, the system automatically generates an SSL certificate. Using HTTPS requires no advanced setup.

{% endnote %}

## GitLab Runner {#runners}

[GitLab Runner](https://docs.gitlab.com/runner/) is an open-source application that runs GitLab [CI/CD](https://en.wikipedia.org/wiki/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](../../managed-kubernetes/concepts/index.md#kubernetes-cluster) and on [Compute Cloud VMs](../../compute/concepts/vm.md).

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

* [Install GitLab Runner in a Managed Service for Kubernetes cluster](../../managed-kubernetes/operations/applications/gitlab-runner.md).
* Create a Compute Cloud VM and [install GitLab Runner on it manually](../tutorials/install-gitlab-runner.md#install).
* [Create a runner managed by Yandex Cloud](#managed-runners).

### Managed runners {#managed-runners}

{% note info %}

The feature of creating and managing runners using the management console is at the [Preview](../../overview/concepts/launch-stages.md) stage. To request access, contact [support](https://center.yandex.cloud/support) or your account manager.

{% endnote %}

In Managed Service for GitLab, you can create a managed runner that automatically deploys a specified number of Compute Cloud [VMs](../../compute/concepts/vm.md) with installed GitLab workers. The managed runner also scales out the worker VMs to accommodate the load.

{% note warning %}

There is a fee for using VM instances (workers) (see [Compute Cloud pricing](../../compute/pricing.md)).

{% endnote %}

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](../../compute/concepts/disk.md#disks-types).
  * [Service account](../../iam/concepts/users/service-accounts.md).

    {% note info %}
    
    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](../../iam/operations/sa/assign-role-for-sa.md) your service account a role for the resource you want to manage.
    
    {% endnote %}

  * [Security group](../../vpc/concepts/security-groups.md).

For more on managed runners, see these pages:
* [Working with a managed runner](../operations/runner.md)
* [Deploying GitLab Runner on a Yandex Compute Cloud virtual machine](../tutorials/install-gitlab-runner.md)

### Networking between GitLab and managed runners {#networking-gl-mr}

The subnet of the instance the managed runner is connected to must have internet access via a [NAT gateway](../../vpc/concepts/gateways.md) or [NAT instance](../../vpc/tutorials/nat-instance/index.md).

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

![image](../../_assets/managed-gitlab/networking.svg)

#### Rules for incoming traffic {#ingress-rules-runner}

#|
|| **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 traffic {#egress-rules-runner}

#|
|| **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 Pages {#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](https://docs.gitlab.com/user/project/pages/).

{% note info %}

This feature is in the [Preview](../../overview/concepts/launch-stages.md) stage. To get access, contact [tech support](https://center.yandex.cloud/support) or your account manager.

{% endnote %}

## Use cases {#examples}

* [Secure storage of GitLab CI passwords as Yandex Lockbox secrets](../tutorials/gitlab-lockbox-integration.md)
* [Building a CI/CD pipeline with serverless products](../tutorials/ci-cd-serverless.md)
* [Deploying GitLab Runner on a Yandex Compute Cloud virtual machine](../tutorials/install-gitlab-runner.md)
* [Continuous deployment of containerized Managed Service for Kubernetes applications](../tutorials/gitlab-containers.md)