Настройка GitLab Service Desk: пошаговое руководство
Всем привет! С вами @netandreus, и сегодня мы рассмотрим настройку GitLab Service Desk. Это мощный инструмент для автоматизации обработки обращений пользователей через электронную почту. Ниже рассмотрим процесс настройки системы для группы компаний, где каждая компания получает собственный репозиторий и адрес для технической поддержки.
Архитектура решения
Концепция
Система построена на принципе автоматического создания тикетов (issues) в GitLab на основе входящих писем от пользователей. Для группы компаний “company_group” каждая отдельная компания “company” получает:
– Собственный репозиторий
– Уникальный адрес для helpdesk:
helpdesk_company@company_group.idПочтовые ящики
Для корректной работы системы требуется три почтовых ящика:
1. Основной ящик (
helpdesk@company_group.id) — для обработки входящих писем2. Ящик ответов (
replies@company_group.id) — для обработки ответов пользователей3. Проектный ящик (
helpdesk_company@company_group.id) — для конкретного проекта в качестве “Custom email address”Важно: Если не указать проектный ящик в поле Custom email, пользователи не будут получать подтверждения о получении их обращений.
Пошаговая настройка
Шаг 1: Создание почтовых ящиков
Создайте три почтовых ящика на базе Zoho Mail:
– incoming_email_address — для входящих писем
– service_desk_email_address — для служебной переписки
– custom_email_address — для проектных обращений
Шаг 2: Конфигурация GitLab
Отредактируйте файл /etc/gitlab/gitlab.rb:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
# Настройки входящей почты gitlab_rails['incoming_email_enabled'] = true gitlab_rails['incoming_email_address'] = "replies+%{key}@company_group.id" gitlab_rails['incoming_email_email'] = "replies@company_group.id" gitlab_rails['incoming_email_password'] = "xxxxxxxxx" gitlab_rails['incoming_email_host'] = "imappro.zoho.com" gitlab_rails['incoming_email_port'] = 993 gitlab_rails['incoming_email_ssl'] = true gitlab_rails['incoming_email_start_tls'] = false gitlab_rails['incoming_email_user'] = "replies@company_group.id" gitlab_rails['incoming_email_mailbox'] = "inbox" gitlab_rails['incoming_email_delete_after_delivery'] = true gitlab_rails['incoming_email_expunge_deleted'] = true # Настройки Service Desk gitlab_rails['service_desk_email_enabled'] = true gitlab_rails['service_desk_email_address'] = "helpdesk+%{key}@company_group.id" gitlab_rails['service_desk_email_email'] = "helpdesk@company_group.id" gitlab_rails['service_desk_email_password'] = "xxxxxx" gitlab_rails['service_desk_email_host'] = "imappro.zoho.com" gitlab_rails['service_desk_email_port'] = 993 gitlab_rails['service_desk_email_ssl'] = true gitlab_rails['service_desk_email_start_tls'] = false gitlab_rails['service_desk_email_user'] = "helpdesk@company_group.id" gitlab_rails['service_desk_email_mailbox'] = "inbox" gitlab_rails['service_desk_email_delete_after_delivery'] = true gitlab_rails['service_desk_email_expunge_deleted'] = true |
Критически важно: Установите параметры
incoming_email_delete_after_delivery и incoming_email_expunge_deleted в значение true. Без этого будет происходить бесконечный цикл создания issues, так как GitLab не будет удалять обработанные письма.Шаг 3: Применение конфигурации
Перезапустите GitLab с новыми настройками:
|
1 |
sudo gitlab-ctl reconfigure |
Шаг 4: Проверка работоспособности
Убедитесь, что почтовая система работает корректно:
|
1 |
sudo gitlab-rake gitlab:incoming_email:check |
Пример успешного вывода:
|
1 2 3 4 5 6 7 8 |
Checking Incoming Email ... Incoming Email: ... Checking Reply by email ... IMAP server credentials are correct? ... Checking helpdesk@company_group.id yes Mailroom enabled? ... skipped MailRoom running? ... skipped Checking Reply by email ... Finished Checking Incoming Email ... Finished |
Шаг 5: Настройка переадресации
На почтовом ящике
custom_email_address (helpdesk_company@company_group.id) в веб-интерфейсе Zoho создайте фильтр для безусловной переадресации всех писем на incoming_email_address с ключом конкретного проекта, например “replies+company-helpdesk-5-issue-@company_group.id”.Адрес проекта можно найти в разделе:
Project → Settings → General → Service Desk → Email address to use for Service Desk
Если в конфиге указан только incoming_email_address, то он будет в поле “Email address to use for Service Desk”. Используете его для переадресации. Если же у вас в конфиге указаны оба адреса: и incoming_email_address и service_desk_email_address, то под основным полем будет подпись “Emails sent to replies+%{key}@company_group.id”, тогда берете его для вставки в переадресацию.
Шаг 6: Активация кастомного email-адреса
После создания и валидации переадресации активируйте “Configure a custom email address” и заполните данные проектного ящика:
|
1 2 3 4 5 |
Custom email address: helpdesk_company@company_group.id SMTP Host: smtppro.zoho.com SMTP Port: 587 SMTP username: helpdesk_company@company_group.id SMTP password (application password): xxxxxx |
Принцип работы верификации
1. GitLab отправляет письмо с кодом подтверждения на
custom_email_address2. Срабатывает Zoho filter (forwarder) на почту проекта
3. GitLab получает письмо, проверяет код и верифицирует почтовый ящик
Разделение почтовых ящиков: техническое обоснование
Почему нужны разные ящики
Функции
incoming_email_address и service_desk_email_address обрабатываются разными пайплайнами и воркерами. Использование одного почтового ящика для обеих функций приводит к:– Двойному захвату сообщений
– Неправильной маршрутизации
– Дублированию issues
Внутренняя архитектура
GitLab использует два независимых потока обработки:
1. Service Desk — создание новых внешних тикетов по email
2. Incoming Email — обработка ответов по email и создание issues от пользователей
Технические детали
– MailRoom запускает отдельный поток для каждого настроенного почтового ящика
– Каждый поллер опрашивает свой inbox с заданным интервалом
– При совмещении функций в один inbox происходит повторная обработка писем
– Дублирование происходит примерно каждые 10 минут
Рекомендации по настройке
– Оставьте
service_desk_email_* настроенным на ящик вида helpdesk@...– Настройте
incoming_email_* на другой ящик, например replies@...– Не создавайте алиасы на один и тот же inbox
– Избегайте смешивания функций
Такое разделение исключает двойной захват писем, обеспечивает корректную маршрутизацию и устраняет повторяющиеся проблемы.
Заключение
Правильная настройка GitLab Service Desk требует понимания архитектуры системы и соблюдения принципа разделения почтовых ящиков. Следование описанным шагам обеспечит стабильную работу системы автоматизации обработки обращений пользователей.