Разработка#

General information#

Облачный PaaS-сервис управления разработкой GitLab позволяет быстро развернуть в облаке полнофункциональную DevOps-платформу для управления жизненным циклом разработки программного обеспечения (SDLC). Подготовка инфраструктуры и развёртывание платформы происходят автоматически и занимают всего несколько минут.

GitLab объединяет в себе инструменты управления репозиториями, автоматизацию CI/CD, мониторинг и средства обеспечения безопасности кода. Его использование позволяет централизовать процессы планирования, разработки и развёртывания программных продуктов и обеспечить прозрачное командное взаимодействие для разработчиков, DevOps-инженеров и системных администраторов.

В K2 Cloud поддерживается версия GitLab CE (Community Edition) с открытым исходным кодом. Данная версия обладает всеми необходимыми функциональными возможностями для поддержки DevOps, включая систему управления репозиториями, CI/CD, запросы на слияние (Merge Requests), управление задачами и пользователями. Если вам не требуются расширенные функции безопасности и управления, данный вариант будет оптимальным.

Billing#

PaaS-сервис GitLab не тарифицируется. Оплата взимается за фактически потреблённые тарифицируемые ресурсы: экземпляры, диски, Elastic IP-адреса и иные ресурсы.

Before you begin#

Мы советуем предварительно ознакомиться с рекомендациями по работе с сервисом GitLab.

Required privileges#

Для работы с сервисом GitLab пользователь должен иметь проектные привилегии PaaSFullAccess. Такие привилегии есть, например, у администраторов в группе CloudAdministrators. При необходимости вы можете создать отдельного пользователя, добавить его в проект и назначить ему политику PaaSFullAccess или включить в группу администраторов облака в этом проекте.

Проектные привилегии PaaSFullAccess предоставляют пользователю права на все действия со всеми сервисами PaaS. Если вы хотите предоставить пользователю права только на определённые действия с сервисом GitLab, то необходимо создать политику с соответствующими привилегиями и назначить её пользователю. Подробнее см. документацию на IAM, как создать политику и назначить её пользователю.

Required resources#

Для развёртывания сервиса GitLab в проекте должны иметься следующие ресурсы:

Запуск сервиса GitLab#

Для запуска сервиса в подразделе Витрина сервисов или Установленные сервисы выберите сервис GitLab на вкладке Разработка и нажмите Создать.

Important

Сервис GitLab можно запустить только в подсети, из которой есть доступ в интернет. Для настройки доступа может понадобиться присоединить к VPC интернет-шлюз и создать маршрут по умолчанию в таблице маршрутизации.

The service launch procedure comprises the following stages:

  1. Задайте параметры сети, необходимые для работы сервиса GitLab:

    Note

    Для запуска сервиса в выбранном VPC необходимо предварительно создать подсеть в предпочтительной зоне доступности.

    Note

    Опция присоединения сетевых интерфейсов может быть полезна, например, когда требуется пересоздать узел, на котором был развёрнут сервис GitLab. Если при удалении сервиса не удалять присоединённый сетевой интерфейс, то его можно использовать повторно для подключения к подсети узла, на котором будет развёрнут новый сервис. Это позволяет сохранить прежние сетевые настройки, такие как внутренний IP-адрес и группы безопасности, и не задавать их заново.

    • Конфигурацию кластера, в котором будет развёрнут сервис. Для выбора доступна только конфигурация с одним мастер-узлом (сервис без отказоустойчивости).

    • VPC, в котором будет развёрнут сервис GitLab.

    • Группы безопасности для регулирования трафика на интерфейсах экземпляра, где будет запущен сервис GitLab.

      Important

      Для корректной работы сервиса GitLab при его создании автоматически создаётся новая группа безопасности, куда добавлены следующие правила:

      • the rule to permit inbound traffic from interfaces that are in the same security group;

      • the rule to enable all outbound IPv4 traffic.

      • (при выборе внешнего балансировщика нагрузки) разрешающее входящий HTTP-трафик через порт 80.

      В случае удаления сервиса GitLab эта группа безопасности будет удалена.

    • Subnet to which an instance with the service deployed on it will be attached, or network interface by which this instance will be attached to the subnet.

    • Внешний балансировщик нагрузки.

      Note

      Если для доступа к GitLab вы планируете использовать протокол HTTPS, то необходимо выбрать эту опцию. TLS-сертификат от Let’s Encrypt будет выпущен для доменного имени балансировщика нагрузки (см. подробнее про поддержку внешнего доступа).

      В поле DNS-имя можно указать произвольное имя поддомена в сервисной зоне DNS <lb-name>-<lb-id>.lb.<region>.k2.cloud для балансировщика нагрузки. Имя должно состоять из латинских букв, цифр и дефисов.

      If the DNS name field is left blank, the name will be specified automatically.

    Click Next to proceed to the next step.

  2. В блоке Мастер-узел задайте конфигурацию экземпляра, который будет использоваться в качестве мастер-узла. Для этого выберите тип экземпляра и характеристики диска для данных: тип, размер и IOPS (если это доступно для данного типа). Системный диск будет добавлен автоматически.

    Note

    Производительность сервиса GitLab чувствительна к выбору компонентов мастер-узла. Рекомендуем использовать экземпляр с большим объёмом оперативной памяти.

    Click Next to proceed to the next step.

  3. Set the main service parameters:

    • Имя сервиса — произвольное уникальное имя для сервиса. Имя должно состоять из строчных латинских букв, цифр, символов . и -, начинаться с буквы и удовлетворять требованиям к доменным именам.

    • Пароль пользователя root для первоначального доступа к GitLab. Его можно задать вручную или сгенерировать автоматически.

      Note

      Пароль рекомендуется изменить после создания сервиса через интерфейс GitLab.

    • Опцию включения Container Registry для хранения Docker-образов приложений. При выборе опции необходимо указать тип хранилища, где будут храниться образы:

      • файловая система — образы будут храниться на диске для данных;

      • объектное хранилище — образы будут храниться в бакете объектного хранилища.

      При выборе объектного хранилища необходимо также указать:

      • пользователя с правами PaaSBackupPolicy, от имени которого выполняется запись образов в бакет (у пользователя не должно быть никаких других прав);

      • бакет, где будут храниться образы.

    • Опцию подключения логирования. Для централизованного логирования сервиса GitLab необходимо предварительно создать сервис логирования ELK. После создания сервиса PaaS установить агенты логирования можно только вручную.

      • Logging service – The selection of a logging service is only available when the Enable logging checkbox is checked.

      • Logging tags – Tags are assigned to logs when the latter are imported by the logging service. They simplify search for the required logs. Tags can only be set when the Enable logging checkbox is checked.

    • Опцию подключения мониторинга. Для централизованного мониторинга сервиса GitLab необходимо предварительно создать сервис мониторинга Prometheus.

      • Monitoring service – The selection of a monitoring service is only available when the Enable monitoring checkbox is checked.

      • Monitoring labels — Optionally, you can set monitoring labels, which the installed monitoring agents will assign to the collected metrics (for details, see Using labels). Labels can only be set when the Enable monitoring checkbox is selected.

    Click Next to proceed to the next step.

  4. Set the maintenance window (see Configuring the maintenance window). If scheduled maintenance can be performed at any time, leave the Maintenance window option set to Custom. If there are time restrictions when maintenance can be performed, select the interval that is convenient for you. To do so, specify the following parameters:

    • the Scheduled value for the Maintenance window option;

    • a day of the week for the maintenance to take place;

    • hour interval for the maintenance window.

    Чтобы задать теги для сервиса, нажмите Добавить теги.

  5. To add a tag, click Add tag and enter tag key and value.

    Note

    If no tags have been set yet, you can add the Name tag by clicking Add Name tag and specifying its value.

  6. When done, click Create to launch the service.

Important

Процесс запуска сервиса GitLab обычно занимает от 5 до 15 мин.

Modifying service node options#

Modify the instance type for the node#

You can modify the instance type for cluster nodes running the development service. You can do it only when the service is in the Ready state.

  1. Go to PaaS Running services and open the Development tab.

  2. Find the desired service in the table and click the service ID to go to its page.

  3. In the Information tab, edit the Instance type field in the configuration section of master node. To do this, click the edit icon and selecting the instance type.

  4. Click to save changes.

Modify data volume parameters#

You can only change the data volume parameters when the service is in the Ready state.

You can configure the data volume size and its performance in IOPS right from the cloud web interface.

Important

You can change IOPS only for a data volume of the type io2.

To change the volume parameters, follow these steps:

  1. Go to PaaS Running services and open the Development tab.

  2. Find the desired service in the table and click the service ID to go to its page.

  3. In the Information tab, edit the required fields (Data volume size and/or Data volume IOPS) by clicking the edit icon .

    Important

    The new data volume size must exceed the current one.

  4. Click to save changes.

Настройка сервиса GitLab#

Если вы не подключили мониторинг и/или логирование при создании сервиса GitLab, либо хотите их отключить, то это можно сделать, только когда сервис находится в состоянии Запущен.

Note

To enable monitoring and logging, first deploy Prometheus-based monitoring service and ELK-based logging service.

Кроме того, вы можете настроить параметры реестра для образов (Container Registry) и задать настройки для уведомлений по электронной почте и аутентификации с помощью OIDC и/или LDAP.

Important

If an attempt to modify some settings fails, then the service will be reset to default ones.

Чтобы настроить параметры сервиса GitLab:

  1. Перейдите в раздел PaaS Установленные сервисы и откройте вкладку Разработка.

  2. Find the desired service in the table and click the service ID to go to its page.

  3. Open the Parameters tab and click Modify.

  4. В открывшемся окне вы можете включить или настроить мониторинг, логирование, Container Registry, SMTP, OIDC и LDAP (или отключить их, если они уже включены).

    При включении Container Registry необходимо задать следующие параметры:

    • Тип хранилища — При выборе типа Файловая система образы будут храниться на диске с данными. При выборе типа Объектное хранилище образы будут храниться в бакете объектного хранилища.

      Для типа хранилища Объектное хранилище необходимо указать:

      • пользователя с правами PaaSBackupPolicy, от имени которого выполняется запись образов в бакет (у пользователя не должно быть никаких других прав);

      • бакет, где будут храниться образы.

    При включении SMTP необходимо указать:

    Настройки SMTP

    • Адрес SMTP-сервера — IP-адрес или FQDN почтового сервера. Если сервер не указан, то для отправки почты используется локальный MTA.

    • Порт SMTP-сервера — Порт, на котором работает почтовый сервер (обычно 25, 465 или 587).

    • Имя пользователя SMTP — Имя пользователя для аутентификации на почтовом сервере. Если имя не указано, аутентификация не используется.

    • Пароль SMTP — Пароль пользователя для аутентификации на почтовом сервере. Если пароль не указан, аутентификация не используется.

    • Домен SMTP — Имя почтового домена.

    • Метод аутентификации SMTP — Метод аутентификации, который поддерживает почтовый сервер. При выборе plain имя и пароль передаются в простом текстовом виде. Если аутентификация не используется, параметр передавать не нужно.

    • Использовать TLS сразу же — Должно ли при подключении к почтовому серверу сразу использоваться шифрование TLS. Если сервер слушает порт 465, то обычно требуется, чтобы при подключении клиент сразу же использовал TLS. Если сервер слушает порт 25 или 587, то обычно сначала устанавливается незашифрованное соединение, а потом осуществляется переход к шифрованию посредством механизма STARTTLS.

    • Принудительный TLS — (Только если опция Использовать TLS сразу же выключена) Шифрование при коммуникации с почтовым сервером должно поддерживаться с самого начала. Если сервер не поддерживает TLS, то соединение сразу же разрывается.

    • Включить STARTTLS автоматически — (Только если опция Использовать TLS сразу же выключена) При подключении к почтовому серверу GitLab будет пытаться установить зашифрованное соединение через механизм STARTTLS. Если сервер не поддерживает TLS, то взаимодействие продолжится без шифрования.

    • Режим проверки TLS-сертификата — При выборе peer проверяется валидность сертификата. При выборе none проверка не выполняется (например, в случае самоподписанных сертификатов).

    • Адрес отправителя — Адрес отправителя для всей исходящей почты.

    • Адрес для ответов — Адрес для ответов на электронную почту.

    При включении OIDC необходимо указать:

    Настройки OIDC

    • Название кнопки — Текст, который будет отображаться на кнопке входа в интерфейсе GitLab. Если параметр не задан, будет использоваться название по умолчанию.

    • URL OIDC-провайдера — URL-адрес OIDC-провайдера. GitLab использует этот адрес для автоматического получения конфигурации провайдера, включая адреса эндпоинтов авторизации и токенов.

    • Метод аутентификации клиента — Метод, который GitLab использует для аутентификации у провайдера OIDC. При выборе метода basic — учётные данные передаются в заголовке, при выборе query — в параметрах запроса.

    • Название поля для UID — Имя поля из ответа user_info.raw_attributes, значение которого будет использоваться в качестве уникального идентификатора пользователя (UID) в GitLab. По умолчанию используется поле sub (Subject).

    • Отправлять Scope на эндпоинт токена — Указывает, должен ли GitLab включать параметр scope в запрос к эндпоинту токенов.

    • Включить PKCE — Указывает, включать ли поддержку PKCE (Proof Key for Code Exchange). Этот механизм значительно повышает безопасность процесса авторизации, предотвращая перехват кода авторизации.

    • Идентификатор клиента — Уникальный идентификатор клиента, который был присвоен приложению GitLab при регистрации в панели управления OIDC-провайдера.

    • Секрет клиента — Секретный ключ клиента, используемый для аутентификации GitLab у провайдера OIDC.

    При включении LDAP необходимо указать:

    Настройки LDAP

    • Название кнопки Login — Текст, который будет отображаться на кнопке входа в интерфейсе GitLab.

    • Хост LDAP-сервера — IP-адрес или доменное имя LDAP-сервера.

    • Атрибут UID — Атрибут LDAP, который соответствует имени пользователя, используемому при входе в GitLab (например, sAMAccountName для Active Directory или uid для OpenLDAP).

    • База поиска — Базовый путь, с которого начинается поиск пользователей в каталоге, например: ou=people,dc=gitlab,dc=example или DC=mydomain,DC=com.

    • Метод шифрования — Используемый метод шифрования соединения с LDAP-сервером:

      • plain — незашифрованное соединение;

      • simple_tls — неявное шифрование (Implicit TLS), соединение шифруется сразу, начиная с процесса его установления.

      • start_tls — явное шифрование (Explicit TLS), сначала устанавливается незашифрованное соединение, а потом осуществляется переход к шифрованию посредством механизма STARTTLS.

    • Учётная запись для подключения — Полный путь (Distinguished Name) пользователя, от имени которого GitLab подключается к LDAP-серверу для выполнения поиска пользователей, например: CN=Gitlab,OU=Users,DC=domain,DC=com.

    • Пароль для подключения — Пароль пользователя для авторизации GitLab в службе каталогов.

    • Содержимое CA-сертификата — Содержимое файла CA-сертификата используется в случае, если выбран метод шифрования simple_tls или start_tls и включена проверка сертификатов.

    • Версия SSL — Версия SSL/TLS, которую должен использовать OpenSSL, если стандартные настройки системы не подходят.

    • Шифры SSL — Конкретные SSL-шифры, которые следует использовать при взаимодействии с LDAP-сервером (например, для отключения устаревших и небезопасных протоколов).

    • Содержимое клиентского сертификата — Содержимое клиентского сертификата необходимо предоставить, когда LDAP-сервер требует взаимной аутентификации (mTLS) и проверяет клиентский сертификат.

    • Содержимое ключа клиентского сертификата — Закрытый ключ клиентского сертификата.

    • Проверять SSL-сертификаты — Указывает, должен ли GitLab проверять валидность SSL-сертификата сервера при использовании методов шифрования simple_tls или start_tls.

    • Сервер Active Directory — Указывает, должен ли GitLab использовать специфические для Microsoft Active Directory запросы. Для всех остальных типов LDAP-серверов (например, OpenLDAP) данная опция должна быть выключена.

    • Разрешить вход по имени или email — При выборе этой опции GitLab для логина можно использовать как адрес электронной почты, так и имя пользователя (часть адреса до @).

    • Фильтр пользователей — Фильтр для ограничения списка пользователей, имеющих доступ в GitLab, в формате RFC 4515. Позволяет, например, разрешить вход только членам определенной группы: (memberOf=CN=GitLab_Users,CN=Groups,DC=example,DC=com).

    • Привести к нижнему регистру — При включённой опции GitLab автоматически переводит все имена пользователей в нижний регистр.

    • Коды ответов для повторной попытки — Список кодов ответов LDAP, при которых GitLab попытается повторно выполнить операцию, если результат или содержимое запроса оказались пустыми.

  5. To save new settings, click Modify.

Assigning tags#

Tags allow you to classify PaaS services by various attributes, such as purpose, owner, etc. Their usage simplifies the management of many similar resources.

To add, modify or delete tag for the development service:

  1. Go to PaaS Running services and open the Development tab.

  2. In the resource table, find the service for which you want to assign tags, and click on its ID to go to the service page.

  3. Open the Tags tab.

  4. To add a tag, click Add tag and specify the Key and Value fields.

    To modify a tag, edit the required fields (Value and/or Key) of the respective tag.

    To delete a tag, click the icon next to the tag you no longer need.

    Note

    If no tags have been set earlier, you can add the Name tag by clicking Add Name tag.

  5. Click Apply to save the changes.

Service start and stop#

You can stop the development service, if you don’t need it, and start it when necessary, thus saving money on computing resources, because only attached volumes. are billed when the service is stopped.

You can also restart the service in case of an error, and synchronize the service status with those of the instances where it is installed.

Stop service#

The service can be stopped when it is in the Running or Error state.

  1. Go to PaaS Running services and open the Development tab.

  2. In the resource table, find the service you want to stop and click the shutdown icon in the Actions field. Alternatively, click the service ID to go to its page and then click Stop in the Information tab.

  3. In the dialog window, confirm the action.

Restart the service#

The service can be restarted when it is in the Running or Error state.

  1. Go to PaaS Running services and open the Development tab.

  2. In the resource table, find the service you want to restart and click the restart icon in the Actions field. Alternatively, click the service ID to go to its page and then click Restart in the Information tab.

  3. In the dialog window, confirm the action.

Synchronize the service with instances#

Synchronization allows you to match the states of the service and the instances on which it is installed, when instances were manually started after the service was stopped. It can also be used to match the states if an error occurred when stopping, starting, or restarting the service and instances had to be manually stopped/started.

Attention

Synchronization is not possible if the error cannot be eliminated (the error status can be viewed, for example, using the DescribeService method).

  1. Go to PaaS Running services and open the Development tab.

  2. In the resource table, find the service you want to synchronize and click the synchronization icon in the Actions field. Alternatively, click the service ID to go to its page and then click Synchronize with confirmation in the Information tab.

  3. In the dialog window, confirm the action.

Start the service#

You can only start the service, when it is in the Stopped state.

  1. Go to PaaS Running services and open the Development tab.

  2. In the resource table, find the service you want to start and click the start icon in the Actions field. Alternatively, click the service ID to go to its page and then click Start in the Information tab.

  3. In the dialog window, confirm the action.

Configuring the maintenance window#

During scheduled maintenance, critical security patches and other important updates are installed.

Attention

During maintenance, operations with the service, including its deletion, are not available, but the service itself will continue to operate. In some cases, it may be necessary to stop and restart the cluster nodes.

Maintenance is carried out strictly during a preset time period (if a maintenance window is specified). All actions of K2 Cloud specialists during maintenance are logged.

Note

You can modify the maintenance window settings when the service is in the Running state only.

To modify the maintenance window settings:

  1. Go to PaaS Running services and open the Development tab.

  2. Find the desired service in the table and click the service ID to go to its page.

  3. In the Maintenance tab, click Set up.

  4. In the window that opens, specify the maintenance interval that is convenient for you. To do so, select the following parameters:

    • the Scheduled value for the Maintenance window option;

    • a day of the week for the maintenance to take place;

    • hour interval for the maintenance window.

    Or select the Custom value for the Maintenance window option, if maintenance can be performed at any time.

  5. Click Save to modify the maintenance window.

Удаление сервиса GitLab#

Удаление сервиса GitLab заключается в удалении созданных с ним экземпляра и дисков.

Для удаления сервиса:

  1. Go to the section PaaS Running services.

  2. Откройте вкладку Разработка и нажмите на иконку в таблице ресурсов. Либо вы можете перейти на страницу сервиса и нажать кнопку Удалить.

  3. Если вы хотите использовать в дальнейшем сетевые интерфейсы, например, чтобы пересоздать сервис с теми же сетевыми параметрами, то в открывшемся окне отключите опцию Удалить подсоединённые сетевые интерфейсы.

  4. To confirm the deletion, click Delete.