Разработка#

Общая информация#

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

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

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

Тарификация#

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

Перед началом работы#

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

Необходимые привилегии#

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

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

Необходимые ресурсы#

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

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

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

Важно

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

Процедура запуска сервиса состоит из следующих основных этапов:

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

    Примечание

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

    Примечание

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

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

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

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

      Важно

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

      • разрешающее входящий трафик от интерфейсов, находящихся в этой же группе безопасности;

      • разрешающее весь исходящий IPv4-трафик.

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

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

    • Подсеть, к которой будет подключён экземпляр с развёрнутым на нём сервисом, либо сетевой интерфейс, через который экземпляр будет подсоединяться к подсети.

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

      Примечание

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

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

      Если поле DNS-имя оставить пустым, то имя будет задано автоматически.

    Нажмите Далее для перехода на следующий шаг.

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

    Примечание

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

    Нажмите Далее для перехода на следующий шаг.

  3. Задайте основные параметры сервиса:

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

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

      Примечание

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

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

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

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

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

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

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

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

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

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

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

      • Сервис мониторинга — Выбор сервиса мониторинга доступен только при выборе опции Подключить мониторинг.

      • Метки для мониторинга — Опционально можно задать метки, которые установленные агенты мониторинга будут присваивать собираемым метрикам (см. подробнее о метках). Метки можно задать только при выборе опции Подключить мониторинг.

    Нажмите Далее для перехода на следующий шаг.

  4. Задайте окно обслуживания (см. Настройка окна обслуживания). Если плановое техническое обслуживание может проводиться в любое время, оставьте значение Произвольное для опции Окно обслуживания без изменения. Если есть ограничения по времени, когда может проводиться техническое обслуживание, выберите удобный вам интервал. Для этого укажите следующие параметры:

    • значение По расписанию для опции Окно обслуживания;

    • день недели, когда должно проводиться обслуживание;

    • часовой интервал для окна обслуживания.

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

  5. Чтобы добавить тег, нажмите Добавить тег и задайте ключ и значение тега.

    Примечание

    Если ни один тег ещё не был задан, то вы можете добавить тег Name, нажав Добавить тег Name и задав его значение.

  6. После завершения настройки нажмите Создать для запуска сервиса.

Важно

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

Изменение параметров узлов сервиса#

Изменить тип экземпляра у узла#

Вы можете изменить тип экземпляра у узлов кластера, на которых развёрнут сервис разработки. Изменение возможно, только когда сервис находится в состоянии Готов.

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

  2. Найдите нужный сервис в таблице и нажмите на идентификатор сервиса для перехода на его страницу.

  3. На вкладке Информация отредактируйте поле Тип экземпляра в конфигурации мастер-узла. Для этого нажмите на иконку редактирования и выберите тип экземпляра в селекторе.

  4. Сохраните изменения, нажав .

Изменить параметры диска для данных#

Изменение параметров диска для данных возможно, когда сервис находится в состоянии Готов.

Вы можете настроить размер диска для данных и его производительность в IOPS непосредственно из веб-интерфейса облака.

Важно

Изменить IOPS диска для данных можно только для типа диска io2.

Чтобы изменить параметры диска, выполните следующие действия:

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

  2. Найдите нужный сервис в таблице и нажмите на идентификатор сервиса для перехода на его страницу.

  3. На вкладке Информация отредактируйте требуемые поля (Размер диска для данных и/или IOPS диска для данных), нажав на иконку редактирования .

    Важно

    Новый размер диска должен превышать текущий.

  4. Сохраните изменения, нажав .

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

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

Примечание

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

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

Важно

Если какие-либо настройки не удастся изменить, то сервис будет возвращён к исходным.

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

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

  2. Найдите в таблице сервисов нужный и нажмите на идентификатор сервиса для перехода на его страницу.

  3. Откройте вкладку Параметры и нажмите Изменить.

  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. Для сохранения новых параметров нажмите Изменить.

Назначение тегов#

Теги позволяют классифицировать сервисы PaaS по различным признакам, например, назначению, владельцу и т.п. Их использование упрощает управление множеством однотипных ресурсов.

Чтобы добавить, изменить или удалить теги для сервиса разработки:

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

  2. В таблице ресурсов найдите сервис, которому надо назначить теги, и нажмите на его идентификатор для перехода на страницу сервиса.

  3. Откройте вкладку Теги.

  4. Для добавления тега нажмите Добавить тег и задайте поля Ключ и Значение.

    Для изменения тега отредактируйте требуемые поля (Значение и/или Ключ) у изменяемого тега.

    Для удаления тега нажмите на иконку рядом с ненужным тегом.

    Примечание

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

  5. Нажмите Применить для сохранения изменений.

Остановка и запуск сервиса#

Сервис разработки можно остановить, если в нём нет необходимости, и запустить, когда потребуется. Это позволяет экономить на оплате вычислительных ресурсов, так как при остановке сервиса тарифицируются только подключённые диски.

Вы также можете перезапустить сервис, если возникла ошибка, и синхронизировать статусы сервиса и экземпляров, на которых он установлен.

Выключить сервис#

Сервис можно остановить, когда он находится в состоянии Запущен или Ошибка.

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

  2. В таблице ресурсов найдите сервис, который необходимо остановить, и нажмите на иконку выключения в поле Действия. Либо нажмите на идентификатор сервиса для перехода на его страницу и на вкладке Информация нажмите Выключить.

  3. Подтвердите действие в открывшемся окне.

Перезапустить сервис#

Сервис можно перезапустить, когда он находится в состоянии Запущен или Ошибка.

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

  2. В таблице ресурсов найдите сервис, который необходимо перезапустить, и нажмите на иконку перезапуска в поле Действия. Либо нажмите на идентификатор сервиса для перехода на его страницу и на вкладке Информация нажмите Перезапустить.

  3. Подтвердите действие в открывшемся окне.

Синхронизировать сервис с экземплярами#

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

Внимание

Синхронизация невозможна, если ошибка не устранима (статус ошибки можно посмотреть, например, с помощью метода DescribeService).

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

  2. В таблице ресурсов найдите сервис, который необходимо синхронизировать, и нажмите на иконку синхронизации в поле Действия. Либо нажмите на идентификатор сервиса для перехода на его страницу и на вкладке Информация нажмите Синхронизировать с подтверждением.

  3. Подтвердите действие в открывшемся окне.

Включить сервис#

Сервис можно запустить, только когда он находится в состоянии Выключен.

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

  2. В таблице ресурсов найдите сервис, который необходимо запустить, и нажмите на иконку включения в поле Действия. Либо нажмите на идентификатор сервиса для перехода на его страницу и на вкладке Информация нажмите Включить.

  3. Подтвердите действие в открывшемся окне.

Настройка окна обслуживания#

Во время планового технического обслуживания выполняется установка критических исправлений безопасности и других важных обновлений.

Внимание

Во время обслуживания операции с сервисом, в том числе его удаление, невозможны, однако сам сервис продолжит работать. В некоторых случаях может потребоваться остановка и перезагрузка узлов кластера.

Обслуживание проводится строго в предопределённый интервал времени (если задано окно обслуживания). Все действия специалистов К2 Облака при проведении обслуживания протоколируются.

Примечание

Изменить настройки окна обслуживания можно, только когда сервис находится в состоянии Запущен.

Чтобы изменить настройки окна обслуживания:

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

  2. Найдите в таблице сервисов нужный и нажмите на идентификатор сервиса для перехода на его страницу.

  3. На вкладке Обслуживание нажмите Настроить.

  4. В открывшемся окне укажите удобный вам интервал, когда может проводиться техническое обслуживание. Для этого выберите следующие параметры:

    • значение По расписанию для опции Окно обслуживания;

    • день недели, когда должно выполняться обслуживание;

    • часовой интервал для окна обслуживания.

    Либо выберите значение Произвольное для опции Окно обслуживания, если обслуживание может проводиться в любое время.

  5. Нажмите Сохранить для изменения окна обслуживания.

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

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

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

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

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

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

  4. Для подтверждения удаления нажмите Удалить.