Расширенная настройка GitLab

Расширенная настройка GitLab 01Расширенная настройка GitLab подразумевает конфигурирование множества дополнительных компонентов, среди которых я планирую рассмотреть настройку почтовых уведомлений, интеграцию с LDAP, а также настройку Rack attack.


Если вам интересна тематика Debian и связанных с ним приложений, рекомендую обратиться к тегу Debian на моем блоге.


Расширенная настройка GitLab

Ранее я рассматривал установку GitLab с нуля (см. Установка GitLab), теперь же я планирую пролить свет на некоторые дополнительные настройки, о чем ниже.

Настройка почтовых уведомлений

Настройка рассылок по электронной почте крайне желательна, ведь иначе пользователи не смогут получать даже письма для восстановления/сброса пароля.

По умолчанию GitLab использует Postfix в качестве MTA и лично меня это полностью устраивает. Тем не менее, при стандартной установке GitLab 1 из репозиториев Postfix у меня нормально не поставился и выкидывал кучу ошибок при попытке что-либо настроить. В таких ситуациях лучшим вариантом будет переконфигурировать пакет:

В процессе работы команды вам будут заданы множество вопросов о конфигурации MTA. На все можете отвечать утвердительно, ответа при этом не меняя (итоговая конфигурация все равно будет задана вручную).

После завершения операции мой конфиг выглядел следующим образом (не рекомендую его слепо копировать, в зависимости от версий Postfix и окружения ваши настройки могут сильно отличаться):

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

Примечание: для углубленного изучения настройки Postfix читайте официальную документацию. В данном примере вас должна интересовать настройка Postfix как null-клиента 2. Также вы можете воспользоваться моими статьями, которые доступны по тегу Unix Mail.

С базовой настройкой почты разобрались.

Расширенная настройка почты

Этот вариант настройки интеграции с почтовыми сервисами я рассматривать не планирую, но и не оставить на него ссылку я не могу 3.

Интеграция с LDAP

В GitLab доступна интеграция 4 с LDAP. Имея инфраструктуру Active Directory, вполне логично воспользоваться данным функционалом.

Открываем конфиг:

Вставляем кусок кода:

Сохраняем изменения и выходим.

Примечание: будьте внимательны, конфиг чувствителен к пробелам и знакам табуляции, которых там быть вообще не должно, иначе при компиляции будете стабильно получать ошибки. Дойти до этого мне помогли отдельные ресурсы 5 6.

Небольшие пояснения по некоторым параметрам секции:

  • host: — адрес хоста, то есть контроллера домена. Можно ввести только один адрес, отказоустойчивая конфигурация доступна в платных версиях GitLab;
  • port: — стандартный порт LDAP;
  • uid: — идентификатор пользователя, по умолчанию sAMAccountName. Это говорит о том, что пользователям нужно будет вводить свой логин AD без конструкций domain\ или @domain.tld. Если вам нужна аутентификация с учетками вида user@domain.tld, то используйте атрибут userPrincipalName;
  • bind_dn: — учетная запись, через которую GitLab будет получать данные из AD. Наделять эту учетку лишними правами не нужно;
  • password: — пароль от учетки, все просто;
  • base: — контейнер для поиска учетных записей. Задайте его в явном виде, если хотите ограничить круг поиска, например определив путь до контейнера с учетными записями отдела разработки ПО. Обратите внимание, что AD чувствителен к регистру букв, путь должен быть в точности как в свойствах контейнера в атрибуте msDS-parentdistname.

Про остальные параметры вы сможете прочитать из официальной документации 7 8, в том числе и других редакций GitLab.

Пересобираем GitLab:

Если все пройдет успешно, в конце получите сообщение:

При вводе неправильных данных будете получать ошибки на подобии этой:

Расширенная настройка GitLab 02

Остается проверить 9 работает ли интеграция:

В идеале вы должны увидеть перечисление всех учетных записей в указанном контейнере AD и в конце:

Если видите что-то другое, разбирайтесь с конфигом.

Rack attack

Этот механизм 10 представляет из себя своеобразную защиту от DDOS-атак (от «надоедливых» клиентов, как это написано в руководстве). Скорее всего большинство админов и не собираются выставлять GitLab наружу, оставив ему судьбу исключительно внутреннего ресурса. Тем не менее, как минимум нужно указать надежные сети, клиентам из которых разрешено мучать GitLab сколько вздумается.

Для этого открываем конфиг:

Редактируем секцию:

Жирным шрифтом выделена подсеть с результирующей маской, добавленная вручную.

Не забываем пересобрать:

На этом настройка завершена.

comments powered by HyperComments