Ролевая модель в GitLab¶
GitLab в составе KeyStack выполняет функции LCM (Lifecycle Management) — хранения кода автоматизации и управления процессами развёртывания, обновления и эксплуатации регионов. Ролевая модель обеспечивает контролируемый доступ к изменению критической инфраструктуры.
Политика безопасности¶
При включении ролевой модели автоматически активируется строгая политика безопасности: учётная запись root блокируется для предотвращения неконтролируемых изменений, создаётся технический пользователь ks-admin для выполнения автоматизированных операций. Пароль и персональный токен доступа (PAT) для ks-admin сохраняются в Vault по пути secret_v2 / deployments/ <LCM FQDN> / secrets / accounts — это обеспечивает централизованное управление техническими учётными записями.
Прямые коммиты в ветку master запрещены для исключения неконтролируемых изменений критической инфраструктуры. Все изменения выполняются через процедуру Merge Request с требованием одобрения двух участников группы KS-Admin и перезапуска пайплайна.
Аутентификация¶
Форма входа в GitLab по адресу https://ks-lcm.cloud.itkey.com/users/sign_in содержит две вкладки: LDAP для корпоративных учётных записей и Standard для локальных пользователей. Использование вкладки LDAP обеспечивает автоматическое получение ролей на основе членства в группах LDAP.
Форма входа в GitLab с вкладками LDAP и Standard¶
Работа с Merge Request¶
Страница Merge requests предоставляет интерфейс управления изменениями кода. Выпадающий список Select project to create merge request содержит репозитории проекта: project_k / services / upgrade, project_k / deployments / <имя региона>, project_k / services / support-bundle, project_k / services / backup и другие компоненты автоматизации.
Страница Merge requests с выбором репозитория проекта¶
Каждый MR проходит процедуру двойной проверки: код-ревью от двух администраторов исключает человеческие ошибки, а автоматическая валидация через пайплайн проверяет синтаксис и совместимость изменений. Это двухуровневая защита от ошибок в критической инфраструктуре.
Настройка правил Merge Request¶
Для обеспечения качества кода и предотвращения ошибок в критической инфраструктуре автоматически настроены правила слияния.
При необходимости настройки она выполняется от имени главного администратора GitLab, который генерируется в HashiCorp Vault. Не используйте для этих настроек учётные записи администраторов из LDAP — они не имеют необходимых прав для изменения настроек проектов GitLab.
Для того чтобы настроить правила слияния для репозитория, выполните следующие действия:
Перейдите в нужный репозиторий или создайте форк существующего репозитория.
Откройте раздел .
В разделе Merge checks установите следующие параметры:
Pipelines must succeed — запрос на слияние можно объединить только если последний пайплайн успешно завершён или всё ещё выполняется. При включении опции Skipped pipelines are considered successful пропущенные пайплайны также считаются успешными.
All threads must be resolved — все обсуждения в запросе на слияние должны быть разрешены перед объединением.
Настройки проверок слияния в GitLab¶
Эти настройки обеспечивают двухуровневую защиту от ошибок: автоматическая валидация через пайплайн проверяет синтаксис и совместимость изменений, а требование разрешения всех обсуждений гарантирует, что все замечания учтены.
Процесс создания и утверждения Merge Request¶
При внесении изменений в репозиторий следует придерживаться следующего процесса:
Создайте новую ветку для ваших изменений.
Внесите необходимые изменения в код. Подробнее в разделе Редактор кода.
Создайте Merge Request для слияния изменений в основную ветку.
Получите одобрение от двух пользователей с правами администратора.
Дождитесь успешного прохождения пайплайна автоматической проверки.
Сделайте Merge для слияния изменений в основную ветку.
Примечание
Один из одобряющих может быть инициатором запроса, но для слияния всегда требуется минимум два одобрения от администраторов. Это исключает возможность самостоятельного слияния (self-merge) и обеспечивает процедуру двойной проверки.
Настройка шаблонов сообщений¶
В разделе Merge suggestions можно настроить шаблон сообщения, который будет использоваться при применении предложений слияния. Доступные переменные для шаблона:
%{suggestions_count}— количество предложений.%{files_count}— количество файлов.%{co_authored_by}— информация о соавторах.
В разделе Merge commit message template настраивается шаблон сообщения для коммита слияния. Доступные переменные:
%{source_branch}— исходная ветка.%{target_branch}— целевая ветка.%{title}— заголовок запроса на слияние.%{issues}— связанные задачи.%{reference}— ссылка на запрос слияния.
Раздел Squash commit message template позволяет настроить шаблон для объединённых коммитов при использовании функции squash.
Редактор пайплайнов¶
Pipeline editor предоставляет инструменты создания и отладки процессов автоматизации. Интерфейс содержит четыре вкладки: Edit для редактирования кода, Visualize для отображения структуры процесса, Validate для проверки синтаксиса, Full configuration для просмотра итоговой конфигурации.
Индикатор «Pipeline syntax is correct» сигнализирует о корректности синтаксиса YAML-конфигурации пайплайна.
Pipeline editor с проверкой синтаксиса и вкладками управления¶
Редактор кода¶
Для того чтобы внести изменения в рамках одного файла, выполните следующие действия:
Войдите в GitLab и перейдите в нужный вам репозиторий, например, в репозиторий региона project_k / deployments / <имя региона>.
Выберите файл для редактирования, например
globals.d/REGION.yml.Нажмите .
Изменение одного файла¶
В открывшемся окне измените или добавьте строки.
Нажмите Commit changes.
В открывшемся окне заполните поле Commit message и нажмите Commit changes.
Отправка изменения одного файла¶
GitLab Web IDE¶
GitLab Web IDE — это встроенная в интерфейс GitLab среда разработки, которая позволяет просматривать, редактировать и создавать файлы напрямую из браузера, без необходимости клонировать репозиторий на локальную машину и использовать локальные редакторы кода.
Для того чтобы внести изменения в файл в репозитории с помощью Web IDE, выполните следующие действия:
Войдите в GitLab и перейдите в нужный вам репозиторий, например, в репозиторий региона project_k / deployments / <имя региона>.
Выберите файл для редактирования, например
globals.d/REGION.yml.Нажмите .
Open in Web IDE¶
В открывшемся окне измените или добавьте строки.
Перейдите во вкладку слева Source control и заполните поле Commit message.
Нажмите Commit and push to master.
Редактирование файла с помощью Web IDE¶
Подтвердите изменения в открывшемся окне.
Разграничение функций по ролям¶
Admin обладает правами создания, изменения и удаления пайплайнов, управления процессами.
Security_auditor и reader ограничены просмотром кода, конфигураций и журналов выполнения.