InfoGrab DocsInfoGrab Docs

Service Desk 구성

요약

기본적으로 Service Desk는 새 프로젝트에서 활성화되어 있습니다. 프로젝트에서 Service Desk를 활성화하려면: 이 프로젝트에 대해 Service Desk가 활성화되었습니다. 이 용어집은 Service Desk와 관련된 용어의 정의를 제공합니다.

기본적으로 Service Desk는 새 프로젝트에서 활성화되어 있습니다. 활성화되지 않은 경우, 프로젝트 설정에서 활성화할 수 있습니다.

전제 조건:

  • 프로젝트에 대해 Maintainer 또는 Owner 역할이 있어야 합니다.
  • GitLab Self-Managed의 경우, GitLab 인스턴스에 대해 수신 이메일을 설정해야 합니다. 이메일 서브 어드레싱을 사용하는 것이 좋지만 catch-all 사서함도 사용할 수 있습니다. 이를 위해 관리자 액세스가 필요합니다.
  • 프로젝트에 대해 이슈 트래커를 활성화해야 합니다.

프로젝트에서 Service Desk를 활성화하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. Service Desk 활성화 토글을 켜세요.
  5. 선택 사항. 필드를 완성하세요.
    • Service Desk 별칭 이메일에 접미사를 추가하세요.
    • 모든 Service Desk 이슈에 추가할 템플릿 목록이 비어 있으면 저장소에 설명 템플릿을 생성하세요.
  6. 변경 사항 저장을 선택하세요.

이 프로젝트에 대해 Service Desk가 활성화되었습니다. Service Desk에 사용할 이메일 주소 아래에 있는 주소로 이메일을 보내면 GitLab이 이메일 내용으로 기밀 티켓을 생성합니다.

Service Desk 용어집#

이 용어집은 Service Desk와 관련된 용어의 정의를 제공합니다.

용어 정의
외부 참여자 GitLab 계정이 없는 사용자로, 이메일을 통해서만 이슈 또는 Service Desk 티켓과 상호작용할 수 있습니다.
요청자 Service Desk 티켓을 생성했거나 /convert_to_ticket 빠른 작업을 사용하여 요청자로 추가된 외부 참여자입니다.

프로젝트 보안 개선#

Service Desk 프로젝트의 보안을 개선하려면 다음을 수행하세요:

  • 나중에 변경할 수 있도록 이메일 시스템의 별칭 뒤에 Service Desk 이메일 주소를 배치하세요.
  • GitLab 인스턴스에서 Akismet을 활성화하여 이 서비스에 스팸 검사를 추가하세요. 차단되지 않은 이메일 스팸은 많은 스팸 이슈가 생성될 수 있습니다.

외부 참여자에게 전송되는 이메일 커스터마이즈#

히스토리
  • GitLab 15.9에서 UNSUBSCRIBE_URL, SYSTEM_HEADER, SYSTEM_FOOTER, ADDITIONAL_TEXT 플레이스홀더가 도입됨.
  • GitLab 16.0에서 %{ISSUE_DESCRIPTION}도입됨.
  • GitLab 16.1에서 %{ISSUE_URL}도입됨.

다음의 경우 외부 참여자에게 이메일이 전송됩니다:

  • 요청자가 Service Desk에 이메일을 보내 새 티켓을 제출할 때.
  • 외부 참여자가 Service Desk 티켓에 추가될 때.
  • Service Desk 티켓에 새 공개 댓글이 추가될 때.
    • 댓글 편집은 새 이메일 전송을 트리거하지 않습니다.

Service Desk 이메일 템플릿으로 이러한 이메일 메시지의 본문을 커스터마이즈할 수 있습니다. 템플릿에는 GitLab Flavored Markdown일부 HTML 태그를 포함할 수 있습니다. 예를 들어, 조직의 브랜드 가이드라인에 따라 머리글과 바닥글을 포함하도록 이메일 형식을 지정할 수 있습니다. 또한 다음 플레이스홀더를 포함하여 Service Desk 티켓 또는 GitLab 인스턴스에 특정한 동적 콘텐츠를 표시할 수 있습니다.

플레이스홀더 thank_you.mdnew_participant new_note.md 설명
%{ISSUE_ID} 티켓 IID.
%{ISSUE_PATH} 티켓 IID가 추가된 프로젝트 경로.
%{ISSUE_URL} 티켓의 URL. 외부 참여자는 프로젝트가 공개이고 티켓이 기밀이 아닌 경우에만 티켓을 볼 수 있습니다 (Service Desk 티켓은 기본적으로 기밀입니다).
%{ISSUE_DESCRIPTION} 티켓 설명. 사용자가 설명을 편집한 경우, 외부 참여자에게 전달하려는 의도가 아닌 민감한 정보가 포함될 수 있습니다. 이 플레이스홀더는 주의해서 사용하고, 이상적으로는 티켓 설명을 절대 수정하지 않거나 팀이 템플릿 디자인을 알고 있는 경우에만 사용하세요.
%{UNSUBSCRIBE_URL} 구독 취소 URL. 외부 참여자로서 알림 이메일 구독 취소 방법과 GitLab의 알림 이메일에서 구독 취소 헤더 사용 방법을 알아보세요.
%{NOTE_TEXT} 사용자가 티켓에 추가한 새 댓글. 외부 참여자가 Service Desk 티켓의 업데이트를 볼 수 있도록 new_note.md에 이 플레이스홀더를 포함시키세요.

감사 이메일#

요청자가 Service Desk를 통해 이슈를 제출하면 GitLab이 감사 이메일을 전송합니다. 추가 구성 없이 GitLab은 기본 감사 이메일을 전송합니다.

사용자 정의 감사 이메일 템플릿을 생성하려면:

  1. 저장소의 .gitlab/service_desk_templates/ 디렉터리에 thank_you.md라는 파일을 생성하세요.
  2. Service Desk 요청자에 대한 답변을 커스터마이즈하기 위한 텍스트, GitLab Flavored Markdown, 일부 선택된 HTML 태그, 플레이스홀더로 Markdown 파일을 채우세요.

새 참여자 이메일#

히스토리
  • GitLab 17.0에서 new_participant 이메일이 도입됨.

외부 참여자가 티켓에 추가되면 GitLab이 새 참여자 이메일을 보내 대화에 참여했음을 알려줍니다. 추가 구성 없이 GitLab은 기본 새 참여자 이메일을 전송합니다.

사용자 정의 새 참여자 이메일 템플릿을 생성하려면:

  1. 저장소의 .gitlab/service_desk_templates/ 디렉터리에 new_participant.md라는 파일을 생성하세요.
  2. Service Desk 요청자에 대한 답변을 커스터마이즈하기 위한 텍스트, GitLab Flavored Markdown, 일부 선택된 HTML 태그, 플레이스홀더로 Markdown 파일을 채우세요.

새 노트 이메일#

Service Desk 티켓에 새 공개 댓글이 있으면 GitLab이 새 노트 이메일을 전송합니다. 추가 구성 없이 GitLab은 댓글의 내용을 전송합니다.

이메일을 브랜드에 맞게 유지하려면 사용자 정의 새 노트 이메일 템플릿을 생성할 수 있습니다:

  1. 저장소의 .gitlab/service_desk_templates/ 디렉터리에 new_note.md라는 파일을 생성하세요.
  2. 새 노트 이메일을 커스터마이즈하기 위한 텍스트, GitLab Flavored Markdown, 일부 선택된 HTML 태그, 플레이스홀더로 Markdown 파일을 채우세요. 이메일 수신자가 댓글 내용을 읽을 수 있도록 템플릿에 %{NOTE_TEXT}를 반드시 포함하세요.

인스턴스 전체 이메일 머리글, 바닥글, 추가 텍스트#

히스토리

인스턴스 관리자는 GitLab 인스턴스에 머리글, 바닥글 또는 추가 텍스트를 추가하여 GitLab에서 전송된 모든 이메일에 적용할 수 있습니다. 사용자 정의 thank_you.md, new_participant.md 또는 new_note.md를 사용하는 경우 이 내용을 포함하려면 템플릿에 %{SYSTEM_HEADER}, %{SYSTEM_FOOTER}, 또는 %{ADDITIONAL_TEXT}를 추가하세요.

자세한 내용은 시스템 머리글 및 바닥글 메시지사용자 정의 추가 텍스트를 참조하세요.

Service Desk 티켓에 사용자 정의 템플릿 사용#

프로젝트당 하나의 설명 템플릿을 선택하여 모든 새 Service Desk 티켓 설명에 추가할 수 있습니다.

다양한 수준에서 설명 템플릿을 설정할 수 있습니다:

템플릿은 상속됩니다. 예를 들어, 프로젝트에서 인스턴스 또는 프로젝트의 상위 그룹에 설정된 템플릿에도 액세스할 수 있습니다.

전제 조건:

Service Desk에서 사용자 정의 설명 템플릿을 사용하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. 모든 Service Desk 이슈에 추가할 템플릿 드롭다운 목록에서 템플릿을 검색하거나 선택하세요.

Support Bot 사용자#

Service Desk는 내부적으로 특별한 Support Bot 사용자가 티켓을 생성하여 작동합니다. 이 사용자는 청구 가능한 사용자가 아니므로 라이선스 제한 수에 포함되지 않습니다.

GitLab 16.0 이하에서 Service Desk 이메일로 생성된 댓글은 GitLab Support Bot을 작성자로 표시합니다. GitLab 16.1 이상에서는 이러한 댓글에 이메일을 보낸 사용자의 이메일이 표시됩니다. 이 기능은 GitLab 16.1 이상에서 작성된 댓글에만 적용됩니다.

Support Bot의 표시 이름 변경#

Support Bot 사용자의 표시 이름을 변경할 수 있습니다. Service Desk 티켓에서 전송된 이메일의 From 헤더에 이 이름이 표시됩니다. 기본 표시 이름은 GitLab Support Bot입니다.

사용자 정의 이메일 표시 이름을 편집하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. 이메일 표시 이름 아래에 새 이름을 입력하세요.
  5. 변경 사항 저장을 선택하세요.

기본 티켓 가시성#

히스토리

새 티켓은 기본적으로 기밀이므로 Planner, Reporter, Developer, Maintainer, 또는 Owner 역할을 가진 프로젝트 멤버만 볼 수 있습니다.

비공개 및 내부 프로젝트에서 새 티켓이 기본적으로 기밀이 아니도록 GitLab을 구성할 수 있으며, 모든 프로젝트 멤버가 볼 수 있습니다.

공개 프로젝트에서는 새 티켓이 항상 기본적으로 기밀이기 때문에 이 설정을 사용할 수 없습니다.

전제 조건:

  • 프로젝트에 대해 Maintainer 또는 Owner 역할이 있어야 합니다.

이 설정을 비활성화하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. 새 티켓은 기본적으로 기밀 체크박스를 해제하세요.
  5. 변경 사항 저장을 선택하세요.

외부 참여자가 댓글을 달면 티켓 재개#

히스토리

외부 참여자가 이메일로 티켓에 새 댓글을 달면 닫힌 티켓을 다시 열도록 GitLab을 구성할 수 있습니다. 이는 또한 티켓의 담당자를 언급하는 내부 댓글을 추가하고 그들을 위해 할 일 항목을 생성합니다.

이 설정을 활성화하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. 외부 참여자의 새 노트에 이슈 재개 체크박스를 선택하세요.
  5. 변경 사항 저장을 선택하세요.

사용자 정의 이메일 주소#

히스토리

지원 커뮤니케이션의 발신자로 표시할 사용자 정의 이메일 주소를 구성하세요. 지원 요청자가 인식하는 도메인으로 브랜드 아이덴티티를 유지하고 신뢰를 심어주세요.

이 기능은 베타 상태입니다. 베타 기능은 프로덕션에 준비되지 않았지만, 릴리스 전에 대폭 변경될 가능성이 낮습니다. 사용자들이 베타 기능을 사용해보고 피드백 이슈에 피드백을 제공하는 것을 권장합니다.

전제 조건#

프로젝트당 하나의 사용자 정의 이메일 주소를 Service Desk에 사용할 수 있으며 인스턴스 전체에서 고유해야 합니다.

사용하려는 사용자 정의 이메일 주소는 다음 요구 사항을 모두 충족해야 합니다:

  • 이메일 전달을 설정할 수 있어야 합니다.

  • 전달된 이메일이 원래 From 헤더를 유지해야 합니다.

  • 서비스 제공자가 서브 어드레싱을 지원해야 합니다. 이메일 주소는 로컬 파트(@ 이전 모든 것)와 도메인 파트로 구성됩니다.

    이메일 서브 어드레싱을 사용하면 로컬 파트에 + 기호와 임의의 텍스트를 추가하여 이메일 주소의 고유한 변형을 생성할 수 있습니다. support@example.com 이메일 주소에서 support+1@example.com으로 이메일을 보내 서브 어드레싱이 지원되는지 확인하세요. 이 이메일은 사서함에 나타나야 합니다.

  • SMTP 자격증명이 있어야 합니다 (이상적으로 앱 비밀번호를 사용하세요). 사용자 이름과 비밀번호는 256비트 키를 사용하는 AES(Advanced Encryption Standard)를 사용하여 데이터베이스에 저장됩니다.

  • SMTP 호스트는 GitLab 인스턴스 네트워크(GitLab Self-Managed의 경우) 또는 공공 인터넷(GitLab.com의 경우)에서 확인 가능해야 합니다.

  • 프로젝트에 대해 Maintainer 또는 Owner 역할이 있어야 합니다.

  • 프로젝트에 대해 Service Desk가 구성되어 있어야 합니다.

사용자 정의 이메일 주소 구성#

자신의 이메일 주소를 사용하여 Service Desk 이메일을 보내려면 사용자 정의 이메일 주소를 구성하고 확인하세요.

Note

이메일 전달을 설정할 때 사용자 정의 이메일 양식의 이메일을 전달할 Service Desk 이메일 주소 필드에 있는 주소(incoming+... 주소)를 사용하세요. Service Desk 설정 페이지 상단의 별칭 주소(contact-project+...)로는 전달하지 마세요. 별칭 주소로 전달하면 잘못된 전달 대상 확인 실패가 발생합니다.

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치고 사용자 정의 이메일 주소 구성 섹션을 찾으세요.
  4. 이 프로젝트의 표시된 Service Desk 주소를 확인하고, 이메일 제공자(예: Gmail)에서 사용자 정의 이메일 주소에서 Service Desk 주소로 이메일 전달을 설정하세요.
  5. GitLab으로 돌아와서 필드를 완성하세요.
  6. 저장 및 연결 테스트를 선택하세요.

구성이 저장되고 사용자 정의 이메일 주소 확인이 트리거됩니다.

확인#

  1. 구성을 완료한 후, 모든 프로젝트 소유자와 사용자 정의 이메일 구성을 저장한 관리자가 알림 이메일을 받습니다.
  2. 제공된 SMTP 자격증명을 사용하여 사용자 정의 이메일 주소(서브 어드레싱 파트 포함)로 확인 이메일이 전송됩니다. 이메일에는 확인 토큰이 포함되어 있습니다. 이메일 전달이 올바르게 설정되고 모든 전제 조건이 충족되면 이메일이 Service Desk 주소로 전달되고 GitLab이 이를 수신합니다. GitLab은 다음 조건을 확인합니다:
    1. GitLab이 SMTP 자격증명을 사용하여 이메일을 보낼 수 있는지.
    2. 서브 어드레싱이 지원되는지(+verify 서브 어드레싱 파트 사용).
    3. 전달 후 From 헤더가 유지되는지.
    4. 확인 토큰이 올바른지.
    5. 이메일이 30분 이내에 수신되는지.

일반적으로 이 과정은 몇 분밖에 걸리지 않습니다.

언제든지 또는 실패한 경우 확인을 취소하려면 사용자 정의 이메일 재설정을 선택하세요. 설정 페이지가 업데이트되어 현재 확인 상태를 반영합니다. SMTP 자격증명이 삭제되고 구성을 다시 시작할 수 있습니다.

실패 및 성공 시 모든 프로젝트 소유자와 확인 프로세스를 트리거한 사용자가 확인 결과가 포함된 알림 이메일을 받습니다. 확인에 실패하면 이메일에 실패 이유에 대한 세부 정보도 포함됩니다.

확인이 성공하면 사용자 정의 이메일 주소를 사용할 준비가 된 것입니다. 이제 사용자 정의 이메일 주소를 사용하여 Service Desk 이메일을 보내는 것을 활성화할 수 있습니다.

구성 문제 해결#

사용자 정의 이메일을 구성할 때 다음 문제가 발생할 수 있습니다.

유효하지 않은 자격증명#

다음과 같은 오류가 발생할 수 있습니다:

The given credentials (username and password) were rejected by the SMTP server,
or you need to explicitly set an authentication method.

이 문제는 SMTP 서버가 인증 자격증명을 거부할 때 발생합니다.

이 문제를 해결하려면:

  1. 사용자 이름과 비밀번호가 올바른지 확인하세요.

  2. GitLab이 지원되는 인증 방법을 자동으로 선택할 수 없는 경우 다음 중 하나를 수행하세요:

    • 사용 가능한 인증 방법 테스트: Plain, Login, CRAM-MD5.

    • GitLab 서버에서 이 명령어를 실행하여 SMTP 서버가 지원하는 인증 방법을 확인하세요:

           swaks --to user@example.com \
                 --from support@example.com \
                 --auth-user support@example.com \
                 --server smtp@example.com:587 \
                 -tls-optional \
                 --auth-password your-app-password
      

      출력에서 250-AUTH로 시작하는 줄을 찾은 다음 사용자 정의 이메일 설정 양식에서 지원되는 인증 방법 중 하나를 선택하세요.

  3. Microsoft 365를 사용 중이고 오류가 지속되면 조건부 액세스를 비활성화하고 이전 단계를 반복하세요.

잘못된 전달 대상#

잘못된 전달 대상이 사용되었다는 오류가 발생할 수 있습니다.

이는 확인 이메일이 사용자 정의 이메일 구성 양식에 표시된 프로젝트별 Service Desk 주소가 아닌 다른 이메일 주소로 전달되었을 때 발생합니다.

incoming_email에서 생성된 Service Desk 주소를 사용해야 합니다. service_desk_email에서 생성된 추가 Service Desk 별칭 주소로 전달하는 것은 모든 이메일 답장 기능을 지원하지 않기 때문에 지원되지 않습니다.

이 문제를 해결하려면:

  1. 이메일을 전달할 올바른 이메일 주소를 찾으세요:
    • 모든 프로젝트 소유자와 확인 프로세스를 트리거한 사용자가 받는 확인 결과 이메일에서 주소를 확인하세요.
    • 사용자 정의 이메일 설정 양식의 이메일을 전달할 Service Desk 이메일 주소 입력란에서 주소를 복사하세요.
  2. 사용자 정의 이메일 주소로 전송된 모든 이메일을 올바른 대상 이메일 주소로 전달하세요.

사용자 정의 이메일 주소 활성화 또는 비활성화#

사용자 정의 이메일 주소가 확인되면 관리자는 사용자 정의 이메일 주소를 사용하여 Service Desk 이메일을 보내는 것을 활성화하거나 비활성화할 수 있습니다.

사용자 정의 이메일 주소를 활성화하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. 사용자 정의 이메일 활성화 토글을 켜세요. 외부 참여자에 대한 Service Desk 이메일이 SMTP 자격증명을 사용하여 전송됩니다.

사용자 정의 이메일 주소를 비활성화하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.

  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.

  3. Service Desk를 펼치세요.

  4. 사용자 정의 이메일 활성화 토글을 끄세요. 이메일 전달을 설정했으므로 사용자 정의 이메일 주소로 전송된 이메일은 계속 처리되어 프로젝트의 Service Desk 티켓으로 나타납니다.

    외부 참여자에 대한 Service Desk 이메일은 이제 GitLab 인스턴스의 기본 발신 이메일 구성을 사용하여 전송됩니다.

사용자 정의 이메일 구성 변경 또는 제거#

사용자 정의 이메일 구성을 변경하려면 재설정하여 제거한 다음 사용자 정의 이메일을 다시 구성해야 합니다.

프로세스의 어느 단계에서도 구성을 재설정하려면 사용자 정의 이메일 재설정을 선택하세요. 그러면 자격증명이 데이터베이스에서 제거됩니다.

사용자 정의 이메일 답장 주소#

외부 참여자는 Service Desk 티켓에 이메일로 답장할 수 있습니다. GitLab은 티켓에 해당하는 32자 답장 키가 있는 이메일 답장 주소를 사용합니다. 사용자 정의 이메일이 구성되면 GitLab은 해당 이메일에서 답장 주소를 생성합니다.

자체 도메인으로 Google Workspace 사용#

자체 도메인을 가진 Google Workspace를 사용할 때 Service Desk의 사용자 정의 이메일 주소를 설정하세요.

전제 조건:

  • Google Workspace 계정이 이미 있어야 합니다.
  • 테넌트에 대해 새 계정을 생성할 수 있어야 합니다.

Google Workspace로 사용자 정의 Service Desk 이메일 주소를 구성하려면:

  1. Google Workspace 계정 구성.
  2. Google Workspace에서 이메일 전달 구성.
  3. Google Workspace 계정을 사용하여 사용자 정의 이메일 주소 구성.

Google Workspace 계정 구성#

먼저 Google Workspace 계정을 생성하고 구성해야 합니다.

Google Workspace에서:

  1. 사용하려는 사용자 정의 이메일 주소(예: support@example.com)에 대한 새 계정을 생성하세요.
  2. 해당 계정에 로그인하고 2단계 인증을 활성화하세요.
  3. SMTP 비밀번호로 사용할 수 있는 앱 비밀번호를 생성하세요. 안전한 장소에 저장하고 문자 사이의 공백을 제거하세요.

다음으로 Google Workspace에서 이메일 전달을 구성해야 합니다.

Google Workspace에서 이메일 전달 구성#

다음 단계는 GitLab과 Google Workspace 간의 이동이 필요합니다.

GitLab에서:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. 이메일을 전달할 Service Desk 이메일 주소 아래의 이메일 주소를 확인하세요.

Google Workspace에서:

  1. 사용자 정의 이메일 계정에 로그인하고 전달 및 POP/IMAP 설정 페이지를 여세요.
  2. 전달 주소 추가를 선택하세요.
  3. 사용자 정의 이메일 양식의 Service Desk 주소를 입력하세요.
  4. 다음을 선택하세요.
  5. 입력을 확인하고 계속을 선택하세요. Google이 Service Desk 주소로 이메일을 보내고 확인 코드를 요구합니다.

GitLab에서:

  1. 프로젝트의 이슈로 이동하고 Google의 확인 이메일로 새 이슈가 생성될 때까지 기다리세요.
  2. 이슈를 열고 확인 코드를 확인하세요.
  3. (선택 사항) 이슈를 삭제하세요.

Google Workspace에서:

  1. 확인 코드를 입력하고 확인을 선택하세요.
  2. 수신 메일의 사본을 다음으로 전달을 선택하고 드롭다운 목록에서 Service Desk 주소가 선택되어 있는지 확인하세요.
  3. 페이지 하단에서 변경 사항 저장을 선택하세요.

다음으로 Service Desk와 함께 사용하기 위해 Google Workspace 계정을 사용하여 사용자 정의 이메일 주소를 구성하세요.

Google Workspace 계정을 사용하여 사용자 정의 이메일 주소 구성#

GitLab에서:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치고 사용자 정의 이메일 설정을 찾으세요.
  4. 필드를 완성하세요:
    • 사용자 정의 이메일 주소: 사용자 정의 이메일 주소.
    • SMTP 호스트: smtp.gmail.com.
    • SMTP 포트: 587.
    • SMTP 사용자 이름: 사용자 정의 이메일 주소로 미리 채워짐.
    • SMTP 비밀번호: 사용자 정의 이메일 계정을 위해 이전에 생성한 앱 비밀번호.
    • SMTP 인증 방법: GitLab이 서버 지원 방법을 선택하도록 허용 (권장)
  5. 저장 및 연결 테스트를 선택하세요.
  6. 확인 프로세스사용자 정의 이메일 주소를 활성화할 수 있어야 합니다.

자체 도메인으로 Microsoft 365 (Exchange online) 사용#

히스토리

자체 도메인을 가진 Microsoft 365 (Exchange)를 사용할 때 Service Desk의 사용자 정의 이메일 주소를 설정하세요.

전제 조건:

  • Microsoft 365 계정이 이미 있어야 합니다.
  • 테넌트에 대해 새 계정을 생성할 수 있어야 합니다.

Microsoft 365로 사용자 정의 Service Desk 이메일 주소를 구성하려면:

  1. Microsoft 365 계정 구성.
  2. Microsoft 365에서 이메일 전달 구성.
  3. Microsoft 365 계정을 사용하여 사용자 정의 이메일 주소 구성.

Microsoft 365 계정 구성#

먼저 Microsoft 365 계정을 생성하고 구성해야 합니다. 이 가이드에서는 사용자 정의 이메일 사서함에 라이선스가 있는 사용자를 사용하세요. 다른 구성 옵션도 실험해 볼 수 있습니다.

Microsoft 365 관리 센터에서:

  1. 사용하려는 사용자 정의 이메일 주소(예: support@example.com)에 대한 새 계정을 생성하세요.
    1. 사용자 섹션을 펼치고 메뉴에서 활성 사용자를 선택하세요.
    2. 사용자 추가를 선택하고 화면의 지시를 따르세요.
  2. Microsoft Entra(이전 Active Directory)에서 계정에 대해 2단계 인증을 활성화하세요.
  3. 사용자가 앱 비밀번호를 생성하도록 허용.
  4. 계정에 대해 인증된 SMTP를 활성화하세요.
    1. 목록에서 계정을 선택하세요.
    2. 서랍에서 메일을 선택하세요.
    3. 이메일 앱 아래에서 이메일 앱 관리를 선택하세요.
    4. 인증된 SMTP를 체크하고 변경 사항 저장을 선택하세요.
  5. 전체 Exchange online 구성에 따라 다음을 구성해야 할 수도 있습니다:
    1. Azure Cloud Shell을 사용하여 SMTP 클라이언트 인증을 허용하세요:

      Set-TransportConfig -SmtpClientAuthenticationDisabled $false
      
    2. Azure Cloud Shell을 사용하여 SMTP AUTH를 사용하는 레거시 TLS 클라이언트를 허용하세요:

      Set-TransportConfig -AllowLegacyTLSClients $true
      
    3. 외부 수신자에게 전달하려면 외부 이메일 전달을 활성화하는 방법에 대한 이 가이드를 참조하세요. 또한 필요한 사용자만 외부 수신자에게 전달할 수 있도록 아웃바운드 스팸 방지 정책을 생성하는 것이 좋습니다.

  6. 해당 계정에 로그인하고 2단계 인증을 활성화하세요.
    1. 오른쪽 상단 모서리의 메뉴에서 계정 보기를 선택하고 보안 정보로 이동하세요.
    2. 로그인 방법 추가를 선택하고 적합한 방법(인증 앱, 전화 또는 이메일)을 선택하세요.
    3. 화면의 지시를 따르세요.
  7. 보안 정보 페이지에서 SMTP 비밀번호로 사용할 앱 비밀번호를 생성하세요.
    1. 로그인 방법 추가를 선택하고 드롭다운 목록에서 앱 비밀번호를 선택하세요.

    2. 앱 비밀번호에 GitLab SD와 같은 설명적인 이름을 설정하세요.

    3. 다음을 선택하세요.

    4. 표시된 비밀번호를 복사하여 안전한 장소에 저장하세요.

    5. 선택 사항. swaks 명령줄 도구를 사용하여 SMTP를 통해 이메일을 보낼 수 있는지 확인하세요.

    6. 자격증명과 함께 다음 명령어를 실행하고 앱 비밀번호를 auth-password로 사용하세요:

      swaks --to your-email@example.com \
            --from custom-email@example.com \
            --auth-user custom-email@example.com \
            --server smtp.office365.com:587 \
            -tls-optional \
            --auth-password <your_app_password>
      

다음으로 Microsoft 365에서 이메일 전달을 구성해야 합니다.

Microsoft 365에서 이메일 전달 구성#

다음 단계는 GitLab과 Microsoft 365 관리 센터 간의 이동이 필요합니다.

GitLab에서:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.

  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.

  3. Service Desk를 펼치세요.

  4. 서브 어드레스 파트 없이 이메일을 전달할 Service Desk 이메일 주소 아래의 이메일 주소를 확인하세요.

    수신자 주소에 서브 주소(예: GitLab에서 생성한 답장 주소)가 포함되고 전달 이메일 주소에 서브 주소(이메일을 전달할 Service Desk 이메일 주소)가 포함되면 이메일이 전달되지 않습니다.

    예를 들어, incoming+group-project-12346426-issue-@incoming.gitlab.comincoming@incoming.gitlab.com이 됩니다. Exchange online이 전달 후 To 헤더에 사용자 정의 이메일 주소를 유지하고 GitLab이 사용자 정의 이메일 주소를 기반으로 올바른 프로젝트를 지정할 수 있으므로 괜찮습니다.

Microsoft 365 관리 센터에서:

  1. 사용자 섹션을 펼치고 메뉴에서 활성 사용자를 선택하세요.
  2. 목록에서 사용자 정의 이메일에 사용할 계정을 선택하세요.
  3. 서랍에서 메일을 선택하세요.
  4. 이메일 전달 아래에서 이메일 전달 관리를 선택하세요.
  5. 이 사서함으로 전송된 모든 이메일 전달을 체크하세요.
  6. 서브 주소 파트 없이 전달 이메일 주소에 사용자 정의 이메일 양식의 Service Desk 주소를 입력하세요.
  7. 변경 사항 저장을 선택하세요.

다음으로 Service Desk와 함께 사용하기 위해 Microsoft 365 계정을 사용하여 사용자 정의 이메일 주소를 구성하세요.

Microsoft 365 계정을 사용하여 사용자 정의 이메일 주소 구성#

GitLab에서:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치고 사용자 정의 이메일 설정을 찾으세요.
  4. 필드를 완성하세요:
    • 사용자 정의 이메일 주소: 사용자 정의 이메일 주소.
    • SMTP 호스트: smtp.office365.com.
    • SMTP 포트: 587.
    • SMTP 사용자 이름: 사용자 정의 이메일 주소로 미리 채워짐.
    • SMTP 비밀번호: 사용자 정의 이메일 계정을 위해 이전에 생성한 앱 비밀번호.
    • SMTP 인증 방법: Login
  5. 저장 및 연결 테스트를 선택하세요.
  6. 확인 프로세스사용자 정의 이메일 주소를 활성화할 수 있어야 합니다.

알려진 문제#

  • 일부 서비스 제공자는 더 이상 SMTP 연결을 허용하지 않습니다. 종종 사용자별로 활성화하고 앱 비밀번호를 생성할 수 있습니다.

추가 Service Desk 별칭 이메일 사용#

인스턴스에 대한 Service Desk의 추가 별칭 이메일 주소를 사용할 수 있습니다.

이를 위해 인스턴스 구성에서 service_desk_email을 구성해야 합니다. 또한 서브 어드레싱 파트의 기본 -issue- 부분을 대체하는 사용자 정의 접미사를 구성할 수 있습니다.

Service Desk 별칭 이메일 구성#

Note

GitLab.com에서는 contact-project+%{key}@incoming.gitlab.com을 이메일 주소로 사용하는 사용자 정의 사서함이 이미 구성되어 있습니다. 프로젝트 설정에서 사용자 정의 접미사를 여전히 구성할 수 있습니다.

Service Desk는 기본적으로 수신 이메일 구성을 사용합니다. 그러나 Service Desk에 별도의 이메일 주소를 갖기 위해 프로젝트 설정에서 사용자 정의 접미사와 함께 service_desk_email을 구성하세요.

전제 조건:

  • address에는 이슈가 생성될 프로젝트를 식별하는 데 사용되는 주소의 user 부분(@ 이전), 즉 +%{key} 플레이스홀더를 포함해야 합니다.
  • service_desk_emailincoming_email 구성은 Service Desk 이메일이 올바르게 처리되도록 항상 별도의 사서함을 사용해야 합니다.

IMAP으로 Service Desk의 사용자 정의 사서함을 구성하려면 구성 파일에 다음 스니펫을 전체적으로 추가하세요:

Note

GitLab 15.3 이상에서 Service Desk는 Sidekiq 작업을 큐에 넣는 대신 기본적으로 webhook(내부 API 호출)을 사용합니다. GitLab 15.3을 실행하는 Linux 패키지 설치에서 webhook을 사용하려면 시크릿 파일을 생성해야 합니다. GitLab 15.4에서 Linux 패키지 설치를 재구성하면 이 시크릿 파일이 자동으로 생성되므로 시크릿 파일 구성 설정이 필요하지 않습니다.

gitlab_rails['service_desk_email_enabled'] = true
gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@gmail.com"
gitlab_rails['service_desk_email_email'] = "project_contact@gmail.com"
gitlab_rails['service_desk_email_password'] = "[REDACTED]"
gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
gitlab_rails['service_desk_email_idle_timeout'] = 60
gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
gitlab_rails['service_desk_email_host'] = "imap.gmail.com"
gitlab_rails['service_desk_email_port'] = 993
gitlab_rails['service_desk_email_ssl'] = true
gitlab_rails['service_desk_email_start_tls'] = false
service_desk_email:
  enabled: true
  address: "project_contact+%{key}@example.com"
  user: "project_contact@example.com"
  password: "[REDACTED]"
  host: "imap.gmail.com"
  delivery_method: webhook
  secret_file: .gitlab-mailroom-secret
  port: 993
  ssl: true
  start_tls: false
  log_path: "log/mailroom.log"
  mailbox: "inbox"
  idle_timeout: 60
  expunge_deleted: true

구성 옵션은 수신 이메일 구성과 동일합니다.

암호화된 자격증명 사용#

히스토리

구성 파일에 일반 텍스트로 Service Desk 이메일 자격증명을 저장하는 대신 선택적으로 수신 이메일 자격증명에 암호화된 파일을 사용할 수 있습니다.

전제 조건:

  • 암호화된 자격증명을 사용하려면 먼저 암호화된 구성을 활성화해야 합니다.

암호화된 파일에 지원되는 구성 항목은 다음과 같습니다:

  • user
  • password
  1. /etc/gitlab/gitlab.rb의 Service Desk 구성이 처음에 다음과 같이 보였다면:

    gitlab_rails['service_desk_email_email'] = "service-desk-email@mail.example.com"
    gitlab_rails['service_desk_email_password'] = "examplepassword"
    
  2. 암호화된 시크릿을 편집하세요:

    sudo gitlab-rake gitlab:service_desk_email:secret:edit EDITOR=vim
    
  3. Service Desk 이메일 시크릿의 암호화되지 않은 내용을 입력하세요:

    user: 'service-desk-email@mail.example.com'
    password: 'examplepassword'
    
  4. /etc/gitlab/gitlab.rb를 편집하고 emailpassword에 대한 service_desk 설정을 제거하세요.

  5. 파일을 저장하고 GitLab을 재구성하세요:

    sudo gitlab-ctl reconfigure
    

Kubernetes 시크릿을 사용하여 Service Desk 이메일 비밀번호를 저장하세요. 자세한 내용은 Helm IMAP 시크릿을 참조하세요.

  1. docker-compose.yml의 Service Desk 구성이 처음에 다음과 같이 보였다면:

    version: "3.6"
    services:
      gitlab:
        image: 'gitlab/gitlab-ee:latest'
        restart: always
        hostname: 'gitlab.example.com'
        environment:
          GITLAB_OMNIBUS_CONFIG: |
            gitlab_rails['service_desk_email_email'] = "service-desk-email@mail.example.com"
            gitlab_rails['service_desk_email_password'] = "examplepassword"
    
  2. 컨테이너 내부에서 암호화된 시크릿을 편집하세요:

    sudo docker exec -t <container_name> bash
    gitlab-rake gitlab:service_desk_email:secret:edit EDITOR=editor
    
  3. Service Desk 시크릿의 암호화되지 않은 내용을 입력하세요:

    user: 'service-desk-email@mail.example.com'
    password: 'examplepassword'
    
  4. docker-compose.yml을 편집하고 emailpassword에 대한 service_desk 설정을 제거하세요.

  5. 파일을 저장하고 GitLab을 재시작하세요:

    docker compose up -d
    
  1. /home/git/gitlab/config/gitlab.yml의 Service Desk 구성이 처음에 다음과 같이 보였다면:

    production:
      service_desk_email:
        user: 'service-desk-email@mail.example.com'
        password: 'examplepassword'
    
  2. 암호화된 시크릿을 편집하세요:

    bundle exec rake gitlab:service_desk_email:secret:edit EDITOR=vim RAILS_ENVIRONMENT=production
    
  3. Service Desk 시크릿의 암호화되지 않은 내용을 입력하세요:

    user: 'service-desk-email@mail.example.com'
    password: 'examplepassword'
    
  4. /home/git/gitlab/config/gitlab.yml을 편집하고 userpassword에 대한 service_desk_email: 설정을 제거하세요.

  5. 파일을 저장하고 GitLab과 Mailroom을 재시작하세요.

    # systemd를 실행하는 시스템의 경우
    sudo systemctl restart gitlab.target
    
    # SysV init을 실행하는 시스템의 경우
    sudo service gitlab restart
    

Microsoft Graph#

히스토리
  • GitLab 15.11에서 소스 컴파일 설치에 대해 도입됨.

service_desk_email은 IMAP 대신 Microsoft Graph API를 사용하여 Microsoft Exchange Online 사서함을 읽도록 구성할 수 있습니다. 수신 이메일과 동일한 방식으로 Microsoft Graph의 OAuth 2.0 애플리케이션을 설정하세요.

  1. /etc/gitlab/gitlab.rb를 편집하고 원하는 값을 대체하여 다음 줄을 추가하세요:
gitlab_rails['service_desk_email_enabled'] = true
gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.onmicrosoft.com"
gitlab_rails['service_desk_email_email'] = "project_contact@example.onmicrosoft.com"
gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
gitlab_rails['service_desk_email_inbox_method'] = 'microsoft_graph'
gitlab_rails['service_desk_email_inbox_options'] = {
  'tenant_id': '',
  'client_id': '',
  'client_secret': '',
  'poll_interval': 60  # 선택 사항
}

미국 정부 Microsoft Cloud 또는 기타 Azure 배포의 경우 azure_ad_endpointgraph_endpoint 설정을 구성하세요:

gitlab_rails['service_desk_email_inbox_options'] = {
  'azure_ad_endpoint': 'https://login.microsoftonline.us',
  'graph_endpoint': 'https://graph.microsoft.us',
  'tenant_id': '',
  'client_id': '',
  'client_secret': '',
  'poll_interval': 60  # 선택 사항
}
  1. OAuth 2.0 애플리케이션 클라이언트 시크릿을 포함하는 Kubernetes 시크릿을 생성하세요:

    kubectl create secret generic service-desk-email-client-secret --from-literal=secret=
    
  2. GitLab Service Desk 이메일 인증 토큰을 위한 Kubernetes 시크릿을 생성하세요. <name>은 GitLab 설치의 Helm 릴리스 이름으로 바꾸세요:

    kubectl create secret generic <name>-service-desk-email-auth-token --from-literal=authToken=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64)
    
  3. Helm 값을 내보내세요:

    helm get values gitlab > gitlab_values.yaml
    
  4. gitlab_values.yaml을 편집하세요:

    global:
      appConfig:
      serviceDeskEmail:
        enabled: true
        address: "project_contact+%{key}@example.onmicrosoft.com"
        user: "project_contact@example.onmicrosoft.com"
        mailbox: inbox
        inboxMethod: microsoft_graph
        azureAdEndpoint: https://login.microsoftonline.com
        graphEndpoint: https://graph.microsoft.com
        tenantId: "YOUR-TENANT-ID"
        clientId: "YOUR-CLIENT-ID"
        clientSecret:
          secret: service-desk-email-client-secret
          key: secret
        deliveryMethod: webhook
        authToken:
          secret: <name>-service-desk-email-auth-token
          key: authToken
    

    미국 정부 Microsoft Cloud 또는 기타 Azure 배포의 경우 azureAdEndpointgraphEndpoint 설정을 구성하세요. 이 필드들은 대소문자를 구분합니다:

    global:
      appConfig:
      serviceDeskEmail:
        [..]
        azureAdEndpoint: https://login.microsoftonline.us
        graphEndpoint: https://graph.microsoft.us
        [..]
    
  5. 파일을 저장하고 새 값을 적용하세요:

    helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
    
  1. docker-compose.yml을 편집하세요:

    version: "3.6"
    services:
      gitlab:
        environment:
          GITLAB_OMNIBUS_CONFIG: |
            gitlab_rails['service_desk_email_enabled'] = true
            gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.onmicrosoft.com"
            gitlab_rails['service_desk_email_email'] = "project_contact@example.onmicrosoft.com"
            gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
            gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
            gitlab_rails['service_desk_email_inbox_method'] = 'microsoft_graph'
            gitlab_rails['service_desk_email_inbox_options'] = {
              'tenant_id': '',
              'client_id': '',
              'client_secret': '',
              'poll_interval': 60  # 선택 사항
            }
    
  2. 파일을 저장하고 GitLab을 재시작하세요:

    docker compose up -d
    

미국 정부 Microsoft Cloud 또는 기타 Azure 배포의 경우 azure_ad_endpointgraph_endpoint 설정을 구성하세요:

  1. docker-compose.yml을 편집하세요:

    version: "3.6"
    services:
      gitlab:
        environment:
          GITLAB_OMNIBUS_CONFIG: |
            gitlab_rails['service_desk_email_enabled'] = true
            gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.onmicrosoft.com"
            gitlab_rails['service_desk_email_email'] = "project_contact@example.onmicrosoft.com"
            gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
            gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
            gitlab_rails['service_desk_email_inbox_method'] = 'microsoft_graph'
            gitlab_rails['service_desk_email_inbox_options'] = {
              'azure_ad_endpoint': 'https://login.microsoftonline.us',
              'graph_endpoint': 'https://graph.microsoft.us',
              'tenant_id': '',
              'client_id': '',
              'client_secret': '',
              'poll_interval': 60  # 선택 사항
            }
    
  2. 파일을 저장하고 GitLab을 재시작하세요:

    docker compose up -d
    
  1. /home/git/gitlab/config/gitlab.yml을 편집하세요:

      service_desk_email:
        enabled: true
        address: "project_contact+%{key}@example.onmicrosoft.com"
        user: "project_contact@example.onmicrosoft.com"
        mailbox: "inbox"
        delivery_method: webhook
        log_path: "log/mailroom.log"
        secret_file: .gitlab-mailroom-secret
        inbox_method: "microsoft_graph"
        inbox_options:
          tenant_id: ""
          client_id: ""
          client_secret: ""
          poll_interval: 60  # 선택 사항
    

미국 정부 Microsoft Cloud 또는 기타 Azure 배포의 경우 azure_ad_endpointgraph_endpoint 설정을 구성하세요:

  service_desk_email:
    enabled: true
    address: "project_contact+%{key}@example.onmicrosoft.com"
    user: "project_contact@example.onmicrosoft.com"
    mailbox: "inbox"
    delivery_method: webhook
    log_path: "log/mailroom.log"
    secret_file: .gitlab-mailroom-secret
    inbox_method: "microsoft_graph"
    inbox_options:
      azure_ad_endpoint: "https://login.microsoftonline.us"
      graph_endpoint: "https://graph.microsoft.us"
      tenant_id: ""
      client_id: ""
      client_secret: ""
      poll_interval: 60  # 선택 사항

Service Desk 별칭 이메일의 접미사 구성#

프로젝트의 Service Desk 설정에서 사용자 정의 접미사를 설정할 수 있습니다.

접미사는 소문자(a-z), 숫자(0-9), 밑줄(_)만 포함할 수 있습니다.

구성되면 사용자 정의 접미사는 service_desk_email_address 설정과 <project_full_path>-<custom_suffix> 형식의 키로 구성된 새 Service Desk 이메일 주소를 생성합니다.

전제 조건:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. 이메일 주소 접미사 아래에 사용할 접미사를 입력하세요.
  5. 변경 사항 저장을 선택하세요.

예를 들어, mygroup/myproject 프로젝트 Service Desk 설정에 다음이 구성되었다고 가정하세요:

  • 이메일 주소 접미사가 support로 설정됨.
  • Service Desk 이메일 주소가 contact+%{key}@example.com으로 구성됨.

이 프로젝트의 Service Desk 이메일 주소는 contact+mygroup-myproject-support@example.com입니다. 수신 이메일 주소는 여전히 작동합니다.

사용자 정의 접미사를 구성하지 않으면 기본 프로젝트 식별이 프로젝트를 식별하는 데 사용됩니다.

다중 노드 환경에서 이메일 수신 구성#

다중 노드 환경은 확장성, 내결함성 및 성능을 위해 여러 서버에서 GitLab을 실행하는 설정입니다.

GitLab은 incoming_emailservice_desk_email 사서함에서 새로운 읽지 않은 이메일을 수신하기 위해 mail_room이라는 별도의 프로세스를 사용합니다.

Helm 차트 (Kubernetes)#

GitLab Helm 차트는 여러 서브차트로 구성되어 있으며, 그 중 하나가 Mailroom 서브차트입니다. incoming_email에 대한 공통 설정service_desk_email에 대한 공통 설정을 구성하세요.

Linux 패키지 (Omnibus)#

다중 노드 Linux 패키지 설치 환경에서는 하나의 노드에서만 mail_room을 실행하세요. 단일 rails 노드(예: application_role)나 완전히 별도로 실행하세요.

모든 노드 설정#

  1. 모든 노드에서 incoming_emailservice_desk_email에 대한 기본 구성을 추가하여 웹 UI 및 생성된 이메일에서 이메일 주소를 렌더링하세요.

    /etc/gitlab/gitlab.rb에서 incoming_email 또는 service_desk_email 섹션을 찾으세요:

   gitlab_rails['incoming_email_enabled'] = true
   gitlab_rails['incoming_email_address'] = "incoming+%{key}@example.com"
   gitlab_rails['service_desk_email_enabled'] = true
   gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.com"
  1. GitLab은 mail_room에서 GitLab 애플리케이션으로 이메일을 전송하는 두 가지 방법을 제공합니다. 각 이메일 설정에 대해 delivery_method를 개별적으로 구성할 수 있습니다:
    1. 권장: webhook(GitLab 15.3 이상의 기본값)은 이메일 페이로드를 GitLab 애플리케이션으로 API POST 요청으로 전송합니다. 인증에 공유 토큰을 사용합니다. 이 방법을 선택하면 mail_room 프로세스가 API 엔드포인트에 액세스할 수 있는지 확인하고 모든 애플리케이션 노드에 공유 토큰을 배포하세요.

      gitlab_rails['incoming_email_delivery_method'] = "webhook"

      # mail_room이 연결할 수 있는 URL. 내부 URL 또는 IP도 사용할 수 있지만
      # mail_room이 해당 주소로 GitLab API에 액세스할 수 있는지 확인하세요.
      # "/"로 끝내지 마세요.
      gitlab_rails['incoming_email_gitlab_url'] = "https://gitlab.example.com"

      # 무작위 토큰을 포함해야 하는 공유 시크릿 파일. 모든 노드에서 동일한지 확인하세요.
      gitlab_rails['incoming_email_secret_file'] = ".gitlab_mailroom_secret"
      ```

</div>

<div class="tab-panel" data-tab-index="1">

```ruby
      gitlab_rails['service_desk_email_delivery_method'] = "webhook"

      # mail_room이 연결할 수 있는 URL. 내부 URL 또는 IP도 사용할 수 있지만
      # mail_room이 해당 주소로 GitLab API에 액세스할 수 있는지 확인하세요.
      # "/"로 끝내지 마세요.

      gitlab_rails['service_desk_email_gitlab_url'] = "https://gitlab.example.com"

      # 무작위 토큰을 포함해야 하는 공유 시크릿 파일. 모든 노드에서 동일한지 확인하세요.
      gitlab_rails['service_desk_email_secret_file'] = ".gitlab_mailroom_secret"
      ```

</div>

</div>

   1. `webhook` 설정에 문제가 있으면 `sidekiq`를 사용하여 Redis를 통해 GitLab Sidekiq에 직접 이메일 페이로드를 전달하세요.

      <div class="tabs-container" data-tabs><div class="tabs-nav"><button class="tab-button active" data-tab-index="0">`incoming_email`</button><button class="tab-button" data-tab-index="1">`service_desk_email`</button></div><div class="tab-panel active" data-tab-index="0">

```ruby
      # Redis 구성을 사용하여 직접 Sidekiq 작업을 추가합니다
      gitlab_rails['incoming_email_delivery_method'] = "sidekiq"
      ```

</div>

<div class="tab-panel" data-tab-index="1">

```ruby
      # Redis 구성을 사용하여 직접 Sidekiq 작업을 추가합니다
      gitlab_rails['service_desk_email_delivery_method'] = "sidekiq"
      ```

</div>

</div>

1. 이메일 수신을 실행하지 않아야 하는 모든 노드에서 `mail_room`을 비활성화하세요. 예를 들어 `/etc/gitlab/gitlab.rb`에서:

   ```ruby
   mailroom['enable'] = false
  1. 변경 사항을 적용하기 위해 GitLab을 재구성하세요.

단일 이메일 수신 노드 설정#

모든 노드를 설정하고 mail_room 프로세스를 비활성화한 후, 단일 노드에서 mail_room을 활성화하세요. 이 노드는 정기적으로 incoming_emailservice_desk_email의 사서함을 폴링하고 새 읽지 않은 이메일을 GitLab으로 이동합니다.

  1. 이메일 수신도 처리할 기존 노드를 선택하세요.

  2. incoming_emailservice_desk_email에 대한 전체 구성 및 자격증명을 추가하세요.

  3. 이 노드에서 mail_room을 활성화하세요. 예를 들어 /etc/gitlab/gitlab.rb에서:

    mailroom['enable'] = true
    
  4. 변경 사항을 적용하기 위해 이 노드에서 GitLab을 재구성하세요.

여러 프로젝트에 대해 Service Desk 끄기#

네임스페이스의 여러 프로젝트에서 Service Desk를 끄려면 API를 사용하거나, GitLab Self-Managed에서는 Rails 콘솔을 사용하세요.

그룹 또는 네임스페이스의 프로젝트에 대해 Service Desk를 끄면 다음이 적용됩니다:

Warning

데이터를 변경하는 명령어는 올바르게 실행되지 않거나 적절한 조건에서 실행되지 않으면 손상을 일으킬 수 있습니다. 항상 테스트 환경에서 먼저 명령어를 실행하고 복원할 수 있는 백업 인스턴스를 준비하세요.

네임스페이스의 모든 프로젝트에 대해 Service Desk를 끄려면 다음 명령어를 실행하세요. my-namespace를 그룹 또는 개인 네임스페이스의 전체 경로로 바꿉니다.

namespace = Namespace.find_by_full_path!('my-namespace')
scope = namespace.is_a?(Group) ? namespace.all_projects : namespace.projects

scope.where(service_desk_enabled: true).each_batch(of: 100) do |batch|
  batch.update_all(service_desk_enabled: false)
end

일부 프로젝트에서 Service Desk를 활성 상태로 유지하려면 해당 프로젝트 ID를 제외합니다:

keep_ids = [42, 1337]
namespace = Namespace.find_by_full_path!('my-namespace')
scope = namespace.is_a?(Group) ? namespace.all_projects : namespace.projects

scope.where(service_desk_enabled: true).where.not(id: keep_ids).each_batch(of: 100) do |batch|
  batch.update_all(service_desk_enabled: false)
end

Service Desk 구성

GitLab v19.2
Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed
원문 보기
요약

기본적으로 Service Desk는 새 프로젝트에서 활성화되어 있습니다. 프로젝트에서 Service Desk를 활성화하려면: 이 프로젝트에 대해 Service Desk가 활성화되었습니다. 이 용어집은 Service Desk와 관련된 용어의 정의를 제공합니다.

기본적으로 Service Desk는 새 프로젝트에서 활성화되어 있습니다. 활성화되지 않은 경우, 프로젝트 설정에서 활성화할 수 있습니다.

전제 조건:

  • 프로젝트에 대해 Maintainer 또는 Owner 역할이 있어야 합니다.
  • GitLab Self-Managed의 경우, GitLab 인스턴스에 대해 수신 이메일을 설정해야 합니다. 이메일 서브 어드레싱을 사용하는 것이 좋지만 catch-all 사서함도 사용할 수 있습니다. 이를 위해 관리자 액세스가 필요합니다.
  • 프로젝트에 대해 이슈 트래커를 활성화해야 합니다.

프로젝트에서 Service Desk를 활성화하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. Service Desk 활성화 토글을 켜세요.
  5. 선택 사항. 필드를 완성하세요.
    • Service Desk 별칭 이메일에 접미사를 추가하세요.
    • 모든 Service Desk 이슈에 추가할 템플릿 목록이 비어 있으면 저장소에 설명 템플릿을 생성하세요.
  6. 변경 사항 저장을 선택하세요.

이 프로젝트에 대해 Service Desk가 활성화되었습니다. Service Desk에 사용할 이메일 주소 아래에 있는 주소로 이메일을 보내면 GitLab이 이메일 내용으로 기밀 티켓을 생성합니다.

Service Desk 용어집#

이 용어집은 Service Desk와 관련된 용어의 정의를 제공합니다.

용어 정의
외부 참여자 GitLab 계정이 없는 사용자로, 이메일을 통해서만 이슈 또는 Service Desk 티켓과 상호작용할 수 있습니다.
요청자 Service Desk 티켓을 생성했거나 /convert_to_ticket 빠른 작업을 사용하여 요청자로 추가된 외부 참여자입니다.

프로젝트 보안 개선#

Service Desk 프로젝트의 보안을 개선하려면 다음을 수행하세요:

  • 나중에 변경할 수 있도록 이메일 시스템의 별칭 뒤에 Service Desk 이메일 주소를 배치하세요.
  • GitLab 인스턴스에서 Akismet을 활성화하여 이 서비스에 스팸 검사를 추가하세요. 차단되지 않은 이메일 스팸은 많은 스팸 이슈가 생성될 수 있습니다.

외부 참여자에게 전송되는 이메일 커스터마이즈#

히스토리
  • GitLab 15.9에서 UNSUBSCRIBE_URL, SYSTEM_HEADER, SYSTEM_FOOTER, ADDITIONAL_TEXT 플레이스홀더가 도입됨.
  • GitLab 16.0에서 %{ISSUE_DESCRIPTION}도입됨.
  • GitLab 16.1에서 %{ISSUE_URL}도입됨.

다음의 경우 외부 참여자에게 이메일이 전송됩니다:

  • 요청자가 Service Desk에 이메일을 보내 새 티켓을 제출할 때.
  • 외부 참여자가 Service Desk 티켓에 추가될 때.
  • Service Desk 티켓에 새 공개 댓글이 추가될 때.
    • 댓글 편집은 새 이메일 전송을 트리거하지 않습니다.

Service Desk 이메일 템플릿으로 이러한 이메일 메시지의 본문을 커스터마이즈할 수 있습니다. 템플릿에는 GitLab Flavored Markdown일부 HTML 태그를 포함할 수 있습니다. 예를 들어, 조직의 브랜드 가이드라인에 따라 머리글과 바닥글을 포함하도록 이메일 형식을 지정할 수 있습니다. 또한 다음 플레이스홀더를 포함하여 Service Desk 티켓 또는 GitLab 인스턴스에 특정한 동적 콘텐츠를 표시할 수 있습니다.

플레이스홀더 thank_you.mdnew_participant new_note.md 설명
%{ISSUE_ID} 티켓 IID.
%{ISSUE_PATH} 티켓 IID가 추가된 프로젝트 경로.
%{ISSUE_URL} 티켓의 URL. 외부 참여자는 프로젝트가 공개이고 티켓이 기밀이 아닌 경우에만 티켓을 볼 수 있습니다 (Service Desk 티켓은 기본적으로 기밀입니다).
%{ISSUE_DESCRIPTION} 티켓 설명. 사용자가 설명을 편집한 경우, 외부 참여자에게 전달하려는 의도가 아닌 민감한 정보가 포함될 수 있습니다. 이 플레이스홀더는 주의해서 사용하고, 이상적으로는 티켓 설명을 절대 수정하지 않거나 팀이 템플릿 디자인을 알고 있는 경우에만 사용하세요.
%{UNSUBSCRIBE_URL} 구독 취소 URL. 외부 참여자로서 알림 이메일 구독 취소 방법과 GitLab의 알림 이메일에서 구독 취소 헤더 사용 방법을 알아보세요.
%{NOTE_TEXT} 사용자가 티켓에 추가한 새 댓글. 외부 참여자가 Service Desk 티켓의 업데이트를 볼 수 있도록 new_note.md에 이 플레이스홀더를 포함시키세요.

감사 이메일#

요청자가 Service Desk를 통해 이슈를 제출하면 GitLab이 감사 이메일을 전송합니다. 추가 구성 없이 GitLab은 기본 감사 이메일을 전송합니다.

사용자 정의 감사 이메일 템플릿을 생성하려면:

  1. 저장소의 .gitlab/service_desk_templates/ 디렉터리에 thank_you.md라는 파일을 생성하세요.
  2. Service Desk 요청자에 대한 답변을 커스터마이즈하기 위한 텍스트, GitLab Flavored Markdown, 일부 선택된 HTML 태그, 플레이스홀더로 Markdown 파일을 채우세요.

새 참여자 이메일#

히스토리
  • GitLab 17.0에서 new_participant 이메일이 도입됨.

외부 참여자가 티켓에 추가되면 GitLab이 새 참여자 이메일을 보내 대화에 참여했음을 알려줍니다. 추가 구성 없이 GitLab은 기본 새 참여자 이메일을 전송합니다.

사용자 정의 새 참여자 이메일 템플릿을 생성하려면:

  1. 저장소의 .gitlab/service_desk_templates/ 디렉터리에 new_participant.md라는 파일을 생성하세요.
  2. Service Desk 요청자에 대한 답변을 커스터마이즈하기 위한 텍스트, GitLab Flavored Markdown, 일부 선택된 HTML 태그, 플레이스홀더로 Markdown 파일을 채우세요.

새 노트 이메일#

Service Desk 티켓에 새 공개 댓글이 있으면 GitLab이 새 노트 이메일을 전송합니다. 추가 구성 없이 GitLab은 댓글의 내용을 전송합니다.

이메일을 브랜드에 맞게 유지하려면 사용자 정의 새 노트 이메일 템플릿을 생성할 수 있습니다:

  1. 저장소의 .gitlab/service_desk_templates/ 디렉터리에 new_note.md라는 파일을 생성하세요.
  2. 새 노트 이메일을 커스터마이즈하기 위한 텍스트, GitLab Flavored Markdown, 일부 선택된 HTML 태그, 플레이스홀더로 Markdown 파일을 채우세요. 이메일 수신자가 댓글 내용을 읽을 수 있도록 템플릿에 %{NOTE_TEXT}를 반드시 포함하세요.

인스턴스 전체 이메일 머리글, 바닥글, 추가 텍스트#

히스토리

인스턴스 관리자는 GitLab 인스턴스에 머리글, 바닥글 또는 추가 텍스트를 추가하여 GitLab에서 전송된 모든 이메일에 적용할 수 있습니다. 사용자 정의 thank_you.md, new_participant.md 또는 new_note.md를 사용하는 경우 이 내용을 포함하려면 템플릿에 %{SYSTEM_HEADER}, %{SYSTEM_FOOTER}, 또는 %{ADDITIONAL_TEXT}를 추가하세요.

자세한 내용은 시스템 머리글 및 바닥글 메시지사용자 정의 추가 텍스트를 참조하세요.

Service Desk 티켓에 사용자 정의 템플릿 사용#

프로젝트당 하나의 설명 템플릿을 선택하여 모든 새 Service Desk 티켓 설명에 추가할 수 있습니다.

다양한 수준에서 설명 템플릿을 설정할 수 있습니다:

템플릿은 상속됩니다. 예를 들어, 프로젝트에서 인스턴스 또는 프로젝트의 상위 그룹에 설정된 템플릿에도 액세스할 수 있습니다.

전제 조건:

Service Desk에서 사용자 정의 설명 템플릿을 사용하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. 모든 Service Desk 이슈에 추가할 템플릿 드롭다운 목록에서 템플릿을 검색하거나 선택하세요.

Support Bot 사용자#

Service Desk는 내부적으로 특별한 Support Bot 사용자가 티켓을 생성하여 작동합니다. 이 사용자는 청구 가능한 사용자가 아니므로 라이선스 제한 수에 포함되지 않습니다.

GitLab 16.0 이하에서 Service Desk 이메일로 생성된 댓글은 GitLab Support Bot을 작성자로 표시합니다. GitLab 16.1 이상에서는 이러한 댓글에 이메일을 보낸 사용자의 이메일이 표시됩니다. 이 기능은 GitLab 16.1 이상에서 작성된 댓글에만 적용됩니다.

Support Bot의 표시 이름 변경#

Support Bot 사용자의 표시 이름을 변경할 수 있습니다. Service Desk 티켓에서 전송된 이메일의 From 헤더에 이 이름이 표시됩니다. 기본 표시 이름은 GitLab Support Bot입니다.

사용자 정의 이메일 표시 이름을 편집하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. 이메일 표시 이름 아래에 새 이름을 입력하세요.
  5. 변경 사항 저장을 선택하세요.

기본 티켓 가시성#

히스토리

새 티켓은 기본적으로 기밀이므로 Planner, Reporter, Developer, Maintainer, 또는 Owner 역할을 가진 프로젝트 멤버만 볼 수 있습니다.

비공개 및 내부 프로젝트에서 새 티켓이 기본적으로 기밀이 아니도록 GitLab을 구성할 수 있으며, 모든 프로젝트 멤버가 볼 수 있습니다.

공개 프로젝트에서는 새 티켓이 항상 기본적으로 기밀이기 때문에 이 설정을 사용할 수 없습니다.

전제 조건:

  • 프로젝트에 대해 Maintainer 또는 Owner 역할이 있어야 합니다.

이 설정을 비활성화하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. 새 티켓은 기본적으로 기밀 체크박스를 해제하세요.
  5. 변경 사항 저장을 선택하세요.

외부 참여자가 댓글을 달면 티켓 재개#

히스토리

외부 참여자가 이메일로 티켓에 새 댓글을 달면 닫힌 티켓을 다시 열도록 GitLab을 구성할 수 있습니다. 이는 또한 티켓의 담당자를 언급하는 내부 댓글을 추가하고 그들을 위해 할 일 항목을 생성합니다.

이 설정을 활성화하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. 외부 참여자의 새 노트에 이슈 재개 체크박스를 선택하세요.
  5. 변경 사항 저장을 선택하세요.

사용자 정의 이메일 주소#

히스토리

지원 커뮤니케이션의 발신자로 표시할 사용자 정의 이메일 주소를 구성하세요. 지원 요청자가 인식하는 도메인으로 브랜드 아이덴티티를 유지하고 신뢰를 심어주세요.

이 기능은 베타 상태입니다. 베타 기능은 프로덕션에 준비되지 않았지만, 릴리스 전에 대폭 변경될 가능성이 낮습니다. 사용자들이 베타 기능을 사용해보고 피드백 이슈에 피드백을 제공하는 것을 권장합니다.

전제 조건#

프로젝트당 하나의 사용자 정의 이메일 주소를 Service Desk에 사용할 수 있으며 인스턴스 전체에서 고유해야 합니다.

사용하려는 사용자 정의 이메일 주소는 다음 요구 사항을 모두 충족해야 합니다:

  • 이메일 전달을 설정할 수 있어야 합니다.

  • 전달된 이메일이 원래 From 헤더를 유지해야 합니다.

  • 서비스 제공자가 서브 어드레싱을 지원해야 합니다. 이메일 주소는 로컬 파트(@ 이전 모든 것)와 도메인 파트로 구성됩니다.

    이메일 서브 어드레싱을 사용하면 로컬 파트에 + 기호와 임의의 텍스트를 추가하여 이메일 주소의 고유한 변형을 생성할 수 있습니다. support@example.com 이메일 주소에서 support+1@example.com으로 이메일을 보내 서브 어드레싱이 지원되는지 확인하세요. 이 이메일은 사서함에 나타나야 합니다.

  • SMTP 자격증명이 있어야 합니다 (이상적으로 앱 비밀번호를 사용하세요). 사용자 이름과 비밀번호는 256비트 키를 사용하는 AES(Advanced Encryption Standard)를 사용하여 데이터베이스에 저장됩니다.

  • SMTP 호스트는 GitLab 인스턴스 네트워크(GitLab Self-Managed의 경우) 또는 공공 인터넷(GitLab.com의 경우)에서 확인 가능해야 합니다.

  • 프로젝트에 대해 Maintainer 또는 Owner 역할이 있어야 합니다.

  • 프로젝트에 대해 Service Desk가 구성되어 있어야 합니다.

사용자 정의 이메일 주소 구성#

자신의 이메일 주소를 사용하여 Service Desk 이메일을 보내려면 사용자 정의 이메일 주소를 구성하고 확인하세요.

Note

이메일 전달을 설정할 때 사용자 정의 이메일 양식의 이메일을 전달할 Service Desk 이메일 주소 필드에 있는 주소(incoming+... 주소)를 사용하세요. Service Desk 설정 페이지 상단의 별칭 주소(contact-project+...)로는 전달하지 마세요. 별칭 주소로 전달하면 잘못된 전달 대상 확인 실패가 발생합니다.

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치고 사용자 정의 이메일 주소 구성 섹션을 찾으세요.
  4. 이 프로젝트의 표시된 Service Desk 주소를 확인하고, 이메일 제공자(예: Gmail)에서 사용자 정의 이메일 주소에서 Service Desk 주소로 이메일 전달을 설정하세요.
  5. GitLab으로 돌아와서 필드를 완성하세요.
  6. 저장 및 연결 테스트를 선택하세요.

구성이 저장되고 사용자 정의 이메일 주소 확인이 트리거됩니다.

확인#

  1. 구성을 완료한 후, 모든 프로젝트 소유자와 사용자 정의 이메일 구성을 저장한 관리자가 알림 이메일을 받습니다.
  2. 제공된 SMTP 자격증명을 사용하여 사용자 정의 이메일 주소(서브 어드레싱 파트 포함)로 확인 이메일이 전송됩니다. 이메일에는 확인 토큰이 포함되어 있습니다. 이메일 전달이 올바르게 설정되고 모든 전제 조건이 충족되면 이메일이 Service Desk 주소로 전달되고 GitLab이 이를 수신합니다. GitLab은 다음 조건을 확인합니다:
    1. GitLab이 SMTP 자격증명을 사용하여 이메일을 보낼 수 있는지.
    2. 서브 어드레싱이 지원되는지(+verify 서브 어드레싱 파트 사용).
    3. 전달 후 From 헤더가 유지되는지.
    4. 확인 토큰이 올바른지.
    5. 이메일이 30분 이내에 수신되는지.

일반적으로 이 과정은 몇 분밖에 걸리지 않습니다.

언제든지 또는 실패한 경우 확인을 취소하려면 사용자 정의 이메일 재설정을 선택하세요. 설정 페이지가 업데이트되어 현재 확인 상태를 반영합니다. SMTP 자격증명이 삭제되고 구성을 다시 시작할 수 있습니다.

실패 및 성공 시 모든 프로젝트 소유자와 확인 프로세스를 트리거한 사용자가 확인 결과가 포함된 알림 이메일을 받습니다. 확인에 실패하면 이메일에 실패 이유에 대한 세부 정보도 포함됩니다.

확인이 성공하면 사용자 정의 이메일 주소를 사용할 준비가 된 것입니다. 이제 사용자 정의 이메일 주소를 사용하여 Service Desk 이메일을 보내는 것을 활성화할 수 있습니다.

구성 문제 해결#

사용자 정의 이메일을 구성할 때 다음 문제가 발생할 수 있습니다.

유효하지 않은 자격증명#

다음과 같은 오류가 발생할 수 있습니다:

The given credentials (username and password) were rejected by the SMTP server,
or you need to explicitly set an authentication method.

이 문제는 SMTP 서버가 인증 자격증명을 거부할 때 발생합니다.

이 문제를 해결하려면:

  1. 사용자 이름과 비밀번호가 올바른지 확인하세요.

  2. GitLab이 지원되는 인증 방법을 자동으로 선택할 수 없는 경우 다음 중 하나를 수행하세요:

    • 사용 가능한 인증 방법 테스트: Plain, Login, CRAM-MD5.

    • GitLab 서버에서 이 명령어를 실행하여 SMTP 서버가 지원하는 인증 방법을 확인하세요:

           swaks --to user@example.com \
                 --from support@example.com \
                 --auth-user support@example.com \
                 --server smtp@example.com:587 \
                 -tls-optional \
                 --auth-password your-app-password
      

      출력에서 250-AUTH로 시작하는 줄을 찾은 다음 사용자 정의 이메일 설정 양식에서 지원되는 인증 방법 중 하나를 선택하세요.

  3. Microsoft 365를 사용 중이고 오류가 지속되면 조건부 액세스를 비활성화하고 이전 단계를 반복하세요.

잘못된 전달 대상#

잘못된 전달 대상이 사용되었다는 오류가 발생할 수 있습니다.

이는 확인 이메일이 사용자 정의 이메일 구성 양식에 표시된 프로젝트별 Service Desk 주소가 아닌 다른 이메일 주소로 전달되었을 때 발생합니다.

incoming_email에서 생성된 Service Desk 주소를 사용해야 합니다. service_desk_email에서 생성된 추가 Service Desk 별칭 주소로 전달하는 것은 모든 이메일 답장 기능을 지원하지 않기 때문에 지원되지 않습니다.

이 문제를 해결하려면:

  1. 이메일을 전달할 올바른 이메일 주소를 찾으세요:
    • 모든 프로젝트 소유자와 확인 프로세스를 트리거한 사용자가 받는 확인 결과 이메일에서 주소를 확인하세요.
    • 사용자 정의 이메일 설정 양식의 이메일을 전달할 Service Desk 이메일 주소 입력란에서 주소를 복사하세요.
  2. 사용자 정의 이메일 주소로 전송된 모든 이메일을 올바른 대상 이메일 주소로 전달하세요.

사용자 정의 이메일 주소 활성화 또는 비활성화#

사용자 정의 이메일 주소가 확인되면 관리자는 사용자 정의 이메일 주소를 사용하여 Service Desk 이메일을 보내는 것을 활성화하거나 비활성화할 수 있습니다.

사용자 정의 이메일 주소를 활성화하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. 사용자 정의 이메일 활성화 토글을 켜세요. 외부 참여자에 대한 Service Desk 이메일이 SMTP 자격증명을 사용하여 전송됩니다.

사용자 정의 이메일 주소를 비활성화하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.

  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.

  3. Service Desk를 펼치세요.

  4. 사용자 정의 이메일 활성화 토글을 끄세요. 이메일 전달을 설정했으므로 사용자 정의 이메일 주소로 전송된 이메일은 계속 처리되어 프로젝트의 Service Desk 티켓으로 나타납니다.

    외부 참여자에 대한 Service Desk 이메일은 이제 GitLab 인스턴스의 기본 발신 이메일 구성을 사용하여 전송됩니다.

사용자 정의 이메일 구성 변경 또는 제거#

사용자 정의 이메일 구성을 변경하려면 재설정하여 제거한 다음 사용자 정의 이메일을 다시 구성해야 합니다.

프로세스의 어느 단계에서도 구성을 재설정하려면 사용자 정의 이메일 재설정을 선택하세요. 그러면 자격증명이 데이터베이스에서 제거됩니다.

사용자 정의 이메일 답장 주소#

외부 참여자는 Service Desk 티켓에 이메일로 답장할 수 있습니다. GitLab은 티켓에 해당하는 32자 답장 키가 있는 이메일 답장 주소를 사용합니다. 사용자 정의 이메일이 구성되면 GitLab은 해당 이메일에서 답장 주소를 생성합니다.

자체 도메인으로 Google Workspace 사용#

자체 도메인을 가진 Google Workspace를 사용할 때 Service Desk의 사용자 정의 이메일 주소를 설정하세요.

전제 조건:

  • Google Workspace 계정이 이미 있어야 합니다.
  • 테넌트에 대해 새 계정을 생성할 수 있어야 합니다.

Google Workspace로 사용자 정의 Service Desk 이메일 주소를 구성하려면:

  1. Google Workspace 계정 구성.
  2. Google Workspace에서 이메일 전달 구성.
  3. Google Workspace 계정을 사용하여 사용자 정의 이메일 주소 구성.

Google Workspace 계정 구성#

먼저 Google Workspace 계정을 생성하고 구성해야 합니다.

Google Workspace에서:

  1. 사용하려는 사용자 정의 이메일 주소(예: support@example.com)에 대한 새 계정을 생성하세요.
  2. 해당 계정에 로그인하고 2단계 인증을 활성화하세요.
  3. SMTP 비밀번호로 사용할 수 있는 앱 비밀번호를 생성하세요. 안전한 장소에 저장하고 문자 사이의 공백을 제거하세요.

다음으로 Google Workspace에서 이메일 전달을 구성해야 합니다.

Google Workspace에서 이메일 전달 구성#

다음 단계는 GitLab과 Google Workspace 간의 이동이 필요합니다.

GitLab에서:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. 이메일을 전달할 Service Desk 이메일 주소 아래의 이메일 주소를 확인하세요.

Google Workspace에서:

  1. 사용자 정의 이메일 계정에 로그인하고 전달 및 POP/IMAP 설정 페이지를 여세요.
  2. 전달 주소 추가를 선택하세요.
  3. 사용자 정의 이메일 양식의 Service Desk 주소를 입력하세요.
  4. 다음을 선택하세요.
  5. 입력을 확인하고 계속을 선택하세요. Google이 Service Desk 주소로 이메일을 보내고 확인 코드를 요구합니다.

GitLab에서:

  1. 프로젝트의 이슈로 이동하고 Google의 확인 이메일로 새 이슈가 생성될 때까지 기다리세요.
  2. 이슈를 열고 확인 코드를 확인하세요.
  3. (선택 사항) 이슈를 삭제하세요.

Google Workspace에서:

  1. 확인 코드를 입력하고 확인을 선택하세요.
  2. 수신 메일의 사본을 다음으로 전달을 선택하고 드롭다운 목록에서 Service Desk 주소가 선택되어 있는지 확인하세요.
  3. 페이지 하단에서 변경 사항 저장을 선택하세요.

다음으로 Service Desk와 함께 사용하기 위해 Google Workspace 계정을 사용하여 사용자 정의 이메일 주소를 구성하세요.

Google Workspace 계정을 사용하여 사용자 정의 이메일 주소 구성#

GitLab에서:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치고 사용자 정의 이메일 설정을 찾으세요.
  4. 필드를 완성하세요:
    • 사용자 정의 이메일 주소: 사용자 정의 이메일 주소.
    • SMTP 호스트: smtp.gmail.com.
    • SMTP 포트: 587.
    • SMTP 사용자 이름: 사용자 정의 이메일 주소로 미리 채워짐.
    • SMTP 비밀번호: 사용자 정의 이메일 계정을 위해 이전에 생성한 앱 비밀번호.
    • SMTP 인증 방법: GitLab이 서버 지원 방법을 선택하도록 허용 (권장)
  5. 저장 및 연결 테스트를 선택하세요.
  6. 확인 프로세스사용자 정의 이메일 주소를 활성화할 수 있어야 합니다.

자체 도메인으로 Microsoft 365 (Exchange online) 사용#

히스토리

자체 도메인을 가진 Microsoft 365 (Exchange)를 사용할 때 Service Desk의 사용자 정의 이메일 주소를 설정하세요.

전제 조건:

  • Microsoft 365 계정이 이미 있어야 합니다.
  • 테넌트에 대해 새 계정을 생성할 수 있어야 합니다.

Microsoft 365로 사용자 정의 Service Desk 이메일 주소를 구성하려면:

  1. Microsoft 365 계정 구성.
  2. Microsoft 365에서 이메일 전달 구성.
  3. Microsoft 365 계정을 사용하여 사용자 정의 이메일 주소 구성.

Microsoft 365 계정 구성#

먼저 Microsoft 365 계정을 생성하고 구성해야 합니다. 이 가이드에서는 사용자 정의 이메일 사서함에 라이선스가 있는 사용자를 사용하세요. 다른 구성 옵션도 실험해 볼 수 있습니다.

Microsoft 365 관리 센터에서:

  1. 사용하려는 사용자 정의 이메일 주소(예: support@example.com)에 대한 새 계정을 생성하세요.
    1. 사용자 섹션을 펼치고 메뉴에서 활성 사용자를 선택하세요.
    2. 사용자 추가를 선택하고 화면의 지시를 따르세요.
  2. Microsoft Entra(이전 Active Directory)에서 계정에 대해 2단계 인증을 활성화하세요.
  3. 사용자가 앱 비밀번호를 생성하도록 허용.
  4. 계정에 대해 인증된 SMTP를 활성화하세요.
    1. 목록에서 계정을 선택하세요.
    2. 서랍에서 메일을 선택하세요.
    3. 이메일 앱 아래에서 이메일 앱 관리를 선택하세요.
    4. 인증된 SMTP를 체크하고 변경 사항 저장을 선택하세요.
  5. 전체 Exchange online 구성에 따라 다음을 구성해야 할 수도 있습니다:
    1. Azure Cloud Shell을 사용하여 SMTP 클라이언트 인증을 허용하세요:

      Set-TransportConfig -SmtpClientAuthenticationDisabled $false
      
    2. Azure Cloud Shell을 사용하여 SMTP AUTH를 사용하는 레거시 TLS 클라이언트를 허용하세요:

      Set-TransportConfig -AllowLegacyTLSClients $true
      
    3. 외부 수신자에게 전달하려면 외부 이메일 전달을 활성화하는 방법에 대한 이 가이드를 참조하세요. 또한 필요한 사용자만 외부 수신자에게 전달할 수 있도록 아웃바운드 스팸 방지 정책을 생성하는 것이 좋습니다.

  6. 해당 계정에 로그인하고 2단계 인증을 활성화하세요.
    1. 오른쪽 상단 모서리의 메뉴에서 계정 보기를 선택하고 보안 정보로 이동하세요.
    2. 로그인 방법 추가를 선택하고 적합한 방법(인증 앱, 전화 또는 이메일)을 선택하세요.
    3. 화면의 지시를 따르세요.
  7. 보안 정보 페이지에서 SMTP 비밀번호로 사용할 앱 비밀번호를 생성하세요.
    1. 로그인 방법 추가를 선택하고 드롭다운 목록에서 앱 비밀번호를 선택하세요.

    2. 앱 비밀번호에 GitLab SD와 같은 설명적인 이름을 설정하세요.

    3. 다음을 선택하세요.

    4. 표시된 비밀번호를 복사하여 안전한 장소에 저장하세요.

    5. 선택 사항. swaks 명령줄 도구를 사용하여 SMTP를 통해 이메일을 보낼 수 있는지 확인하세요.

    6. 자격증명과 함께 다음 명령어를 실행하고 앱 비밀번호를 auth-password로 사용하세요:

      swaks --to your-email@example.com \
            --from custom-email@example.com \
            --auth-user custom-email@example.com \
            --server smtp.office365.com:587 \
            -tls-optional \
            --auth-password <your_app_password>
      

다음으로 Microsoft 365에서 이메일 전달을 구성해야 합니다.

Microsoft 365에서 이메일 전달 구성#

다음 단계는 GitLab과 Microsoft 365 관리 센터 간의 이동이 필요합니다.

GitLab에서:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.

  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.

  3. Service Desk를 펼치세요.

  4. 서브 어드레스 파트 없이 이메일을 전달할 Service Desk 이메일 주소 아래의 이메일 주소를 확인하세요.

    수신자 주소에 서브 주소(예: GitLab에서 생성한 답장 주소)가 포함되고 전달 이메일 주소에 서브 주소(이메일을 전달할 Service Desk 이메일 주소)가 포함되면 이메일이 전달되지 않습니다.

    예를 들어, incoming+group-project-12346426-issue-@incoming.gitlab.comincoming@incoming.gitlab.com이 됩니다. Exchange online이 전달 후 To 헤더에 사용자 정의 이메일 주소를 유지하고 GitLab이 사용자 정의 이메일 주소를 기반으로 올바른 프로젝트를 지정할 수 있으므로 괜찮습니다.

Microsoft 365 관리 센터에서:

  1. 사용자 섹션을 펼치고 메뉴에서 활성 사용자를 선택하세요.
  2. 목록에서 사용자 정의 이메일에 사용할 계정을 선택하세요.
  3. 서랍에서 메일을 선택하세요.
  4. 이메일 전달 아래에서 이메일 전달 관리를 선택하세요.
  5. 이 사서함으로 전송된 모든 이메일 전달을 체크하세요.
  6. 서브 주소 파트 없이 전달 이메일 주소에 사용자 정의 이메일 양식의 Service Desk 주소를 입력하세요.
  7. 변경 사항 저장을 선택하세요.

다음으로 Service Desk와 함께 사용하기 위해 Microsoft 365 계정을 사용하여 사용자 정의 이메일 주소를 구성하세요.

Microsoft 365 계정을 사용하여 사용자 정의 이메일 주소 구성#

GitLab에서:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치고 사용자 정의 이메일 설정을 찾으세요.
  4. 필드를 완성하세요:
    • 사용자 정의 이메일 주소: 사용자 정의 이메일 주소.
    • SMTP 호스트: smtp.office365.com.
    • SMTP 포트: 587.
    • SMTP 사용자 이름: 사용자 정의 이메일 주소로 미리 채워짐.
    • SMTP 비밀번호: 사용자 정의 이메일 계정을 위해 이전에 생성한 앱 비밀번호.
    • SMTP 인증 방법: Login
  5. 저장 및 연결 테스트를 선택하세요.
  6. 확인 프로세스사용자 정의 이메일 주소를 활성화할 수 있어야 합니다.

알려진 문제#

  • 일부 서비스 제공자는 더 이상 SMTP 연결을 허용하지 않습니다. 종종 사용자별로 활성화하고 앱 비밀번호를 생성할 수 있습니다.

추가 Service Desk 별칭 이메일 사용#

인스턴스에 대한 Service Desk의 추가 별칭 이메일 주소를 사용할 수 있습니다.

이를 위해 인스턴스 구성에서 service_desk_email을 구성해야 합니다. 또한 서브 어드레싱 파트의 기본 -issue- 부분을 대체하는 사용자 정의 접미사를 구성할 수 있습니다.

Service Desk 별칭 이메일 구성#

Note

GitLab.com에서는 contact-project+%{key}@incoming.gitlab.com을 이메일 주소로 사용하는 사용자 정의 사서함이 이미 구성되어 있습니다. 프로젝트 설정에서 사용자 정의 접미사를 여전히 구성할 수 있습니다.

Service Desk는 기본적으로 수신 이메일 구성을 사용합니다. 그러나 Service Desk에 별도의 이메일 주소를 갖기 위해 프로젝트 설정에서 사용자 정의 접미사와 함께 service_desk_email을 구성하세요.

전제 조건:

  • address에는 이슈가 생성될 프로젝트를 식별하는 데 사용되는 주소의 user 부분(@ 이전), 즉 +%{key} 플레이스홀더를 포함해야 합니다.
  • service_desk_emailincoming_email 구성은 Service Desk 이메일이 올바르게 처리되도록 항상 별도의 사서함을 사용해야 합니다.

IMAP으로 Service Desk의 사용자 정의 사서함을 구성하려면 구성 파일에 다음 스니펫을 전체적으로 추가하세요:

Note

GitLab 15.3 이상에서 Service Desk는 Sidekiq 작업을 큐에 넣는 대신 기본적으로 webhook(내부 API 호출)을 사용합니다. GitLab 15.3을 실행하는 Linux 패키지 설치에서 webhook을 사용하려면 시크릿 파일을 생성해야 합니다. GitLab 15.4에서 Linux 패키지 설치를 재구성하면 이 시크릿 파일이 자동으로 생성되므로 시크릿 파일 구성 설정이 필요하지 않습니다.

gitlab_rails['service_desk_email_enabled'] = true
gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@gmail.com"
gitlab_rails['service_desk_email_email'] = "project_contact@gmail.com"
gitlab_rails['service_desk_email_password'] = "[REDACTED]"
gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
gitlab_rails['service_desk_email_idle_timeout'] = 60
gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
gitlab_rails['service_desk_email_host'] = "imap.gmail.com"
gitlab_rails['service_desk_email_port'] = 993
gitlab_rails['service_desk_email_ssl'] = true
gitlab_rails['service_desk_email_start_tls'] = false
service_desk_email:
  enabled: true
  address: "project_contact+%{key}@example.com"
  user: "project_contact@example.com"
  password: "[REDACTED]"
  host: "imap.gmail.com"
  delivery_method: webhook
  secret_file: .gitlab-mailroom-secret
  port: 993
  ssl: true
  start_tls: false
  log_path: "log/mailroom.log"
  mailbox: "inbox"
  idle_timeout: 60
  expunge_deleted: true

구성 옵션은 수신 이메일 구성과 동일합니다.

암호화된 자격증명 사용#

히스토리

구성 파일에 일반 텍스트로 Service Desk 이메일 자격증명을 저장하는 대신 선택적으로 수신 이메일 자격증명에 암호화된 파일을 사용할 수 있습니다.

전제 조건:

  • 암호화된 자격증명을 사용하려면 먼저 암호화된 구성을 활성화해야 합니다.

암호화된 파일에 지원되는 구성 항목은 다음과 같습니다:

  • user
  • password
  1. /etc/gitlab/gitlab.rb의 Service Desk 구성이 처음에 다음과 같이 보였다면:

    gitlab_rails['service_desk_email_email'] = "service-desk-email@mail.example.com"
    gitlab_rails['service_desk_email_password'] = "examplepassword"
    
  2. 암호화된 시크릿을 편집하세요:

    sudo gitlab-rake gitlab:service_desk_email:secret:edit EDITOR=vim
    
  3. Service Desk 이메일 시크릿의 암호화되지 않은 내용을 입력하세요:

    user: 'service-desk-email@mail.example.com'
    password: 'examplepassword'
    
  4. /etc/gitlab/gitlab.rb를 편집하고 emailpassword에 대한 service_desk 설정을 제거하세요.

  5. 파일을 저장하고 GitLab을 재구성하세요:

    sudo gitlab-ctl reconfigure
    

Kubernetes 시크릿을 사용하여 Service Desk 이메일 비밀번호를 저장하세요. 자세한 내용은 Helm IMAP 시크릿을 참조하세요.

  1. docker-compose.yml의 Service Desk 구성이 처음에 다음과 같이 보였다면:

    version: "3.6"
    services:
      gitlab:
        image: 'gitlab/gitlab-ee:latest'
        restart: always
        hostname: 'gitlab.example.com'
        environment:
          GITLAB_OMNIBUS_CONFIG: |
            gitlab_rails['service_desk_email_email'] = "service-desk-email@mail.example.com"
            gitlab_rails['service_desk_email_password'] = "examplepassword"
    
  2. 컨테이너 내부에서 암호화된 시크릿을 편집하세요:

    sudo docker exec -t <container_name> bash
    gitlab-rake gitlab:service_desk_email:secret:edit EDITOR=editor
    
  3. Service Desk 시크릿의 암호화되지 않은 내용을 입력하세요:

    user: 'service-desk-email@mail.example.com'
    password: 'examplepassword'
    
  4. docker-compose.yml을 편집하고 emailpassword에 대한 service_desk 설정을 제거하세요.

  5. 파일을 저장하고 GitLab을 재시작하세요:

    docker compose up -d
    
  1. /home/git/gitlab/config/gitlab.yml의 Service Desk 구성이 처음에 다음과 같이 보였다면:

    production:
      service_desk_email:
        user: 'service-desk-email@mail.example.com'
        password: 'examplepassword'
    
  2. 암호화된 시크릿을 편집하세요:

    bundle exec rake gitlab:service_desk_email:secret:edit EDITOR=vim RAILS_ENVIRONMENT=production
    
  3. Service Desk 시크릿의 암호화되지 않은 내용을 입력하세요:

    user: 'service-desk-email@mail.example.com'
    password: 'examplepassword'
    
  4. /home/git/gitlab/config/gitlab.yml을 편집하고 userpassword에 대한 service_desk_email: 설정을 제거하세요.

  5. 파일을 저장하고 GitLab과 Mailroom을 재시작하세요.

    # systemd를 실행하는 시스템의 경우
    sudo systemctl restart gitlab.target
    
    # SysV init을 실행하는 시스템의 경우
    sudo service gitlab restart
    

Microsoft Graph#

히스토리
  • GitLab 15.11에서 소스 컴파일 설치에 대해 도입됨.

service_desk_email은 IMAP 대신 Microsoft Graph API를 사용하여 Microsoft Exchange Online 사서함을 읽도록 구성할 수 있습니다. 수신 이메일과 동일한 방식으로 Microsoft Graph의 OAuth 2.0 애플리케이션을 설정하세요.

  1. /etc/gitlab/gitlab.rb를 편집하고 원하는 값을 대체하여 다음 줄을 추가하세요:
gitlab_rails['service_desk_email_enabled'] = true
gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.onmicrosoft.com"
gitlab_rails['service_desk_email_email'] = "project_contact@example.onmicrosoft.com"
gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
gitlab_rails['service_desk_email_inbox_method'] = 'microsoft_graph'
gitlab_rails['service_desk_email_inbox_options'] = {
  'tenant_id': '',
  'client_id': '',
  'client_secret': '',
  'poll_interval': 60  # 선택 사항
}

미국 정부 Microsoft Cloud 또는 기타 Azure 배포의 경우 azure_ad_endpointgraph_endpoint 설정을 구성하세요:

gitlab_rails['service_desk_email_inbox_options'] = {
  'azure_ad_endpoint': 'https://login.microsoftonline.us',
  'graph_endpoint': 'https://graph.microsoft.us',
  'tenant_id': '',
  'client_id': '',
  'client_secret': '',
  'poll_interval': 60  # 선택 사항
}
  1. OAuth 2.0 애플리케이션 클라이언트 시크릿을 포함하는 Kubernetes 시크릿을 생성하세요:

    kubectl create secret generic service-desk-email-client-secret --from-literal=secret=
    
  2. GitLab Service Desk 이메일 인증 토큰을 위한 Kubernetes 시크릿을 생성하세요. <name>은 GitLab 설치의 Helm 릴리스 이름으로 바꾸세요:

    kubectl create secret generic <name>-service-desk-email-auth-token --from-literal=authToken=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64)
    
  3. Helm 값을 내보내세요:

    helm get values gitlab > gitlab_values.yaml
    
  4. gitlab_values.yaml을 편집하세요:

    global:
      appConfig:
      serviceDeskEmail:
        enabled: true
        address: "project_contact+%{key}@example.onmicrosoft.com"
        user: "project_contact@example.onmicrosoft.com"
        mailbox: inbox
        inboxMethod: microsoft_graph
        azureAdEndpoint: https://login.microsoftonline.com
        graphEndpoint: https://graph.microsoft.com
        tenantId: "YOUR-TENANT-ID"
        clientId: "YOUR-CLIENT-ID"
        clientSecret:
          secret: service-desk-email-client-secret
          key: secret
        deliveryMethod: webhook
        authToken:
          secret: <name>-service-desk-email-auth-token
          key: authToken
    

    미국 정부 Microsoft Cloud 또는 기타 Azure 배포의 경우 azureAdEndpointgraphEndpoint 설정을 구성하세요. 이 필드들은 대소문자를 구분합니다:

    global:
      appConfig:
      serviceDeskEmail:
        [..]
        azureAdEndpoint: https://login.microsoftonline.us
        graphEndpoint: https://graph.microsoft.us
        [..]
    
  5. 파일을 저장하고 새 값을 적용하세요:

    helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
    
  1. docker-compose.yml을 편집하세요:

    version: "3.6"
    services:
      gitlab:
        environment:
          GITLAB_OMNIBUS_CONFIG: |
            gitlab_rails['service_desk_email_enabled'] = true
            gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.onmicrosoft.com"
            gitlab_rails['service_desk_email_email'] = "project_contact@example.onmicrosoft.com"
            gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
            gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
            gitlab_rails['service_desk_email_inbox_method'] = 'microsoft_graph'
            gitlab_rails['service_desk_email_inbox_options'] = {
              'tenant_id': '',
              'client_id': '',
              'client_secret': '',
              'poll_interval': 60  # 선택 사항
            }
    
  2. 파일을 저장하고 GitLab을 재시작하세요:

    docker compose up -d
    

미국 정부 Microsoft Cloud 또는 기타 Azure 배포의 경우 azure_ad_endpointgraph_endpoint 설정을 구성하세요:

  1. docker-compose.yml을 편집하세요:

    version: "3.6"
    services:
      gitlab:
        environment:
          GITLAB_OMNIBUS_CONFIG: |
            gitlab_rails['service_desk_email_enabled'] = true
            gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.onmicrosoft.com"
            gitlab_rails['service_desk_email_email'] = "project_contact@example.onmicrosoft.com"
            gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
            gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
            gitlab_rails['service_desk_email_inbox_method'] = 'microsoft_graph'
            gitlab_rails['service_desk_email_inbox_options'] = {
              'azure_ad_endpoint': 'https://login.microsoftonline.us',
              'graph_endpoint': 'https://graph.microsoft.us',
              'tenant_id': '',
              'client_id': '',
              'client_secret': '',
              'poll_interval': 60  # 선택 사항
            }
    
  2. 파일을 저장하고 GitLab을 재시작하세요:

    docker compose up -d
    
  1. /home/git/gitlab/config/gitlab.yml을 편집하세요:

      service_desk_email:
        enabled: true
        address: "project_contact+%{key}@example.onmicrosoft.com"
        user: "project_contact@example.onmicrosoft.com"
        mailbox: "inbox"
        delivery_method: webhook
        log_path: "log/mailroom.log"
        secret_file: .gitlab-mailroom-secret
        inbox_method: "microsoft_graph"
        inbox_options:
          tenant_id: ""
          client_id: ""
          client_secret: ""
          poll_interval: 60  # 선택 사항
    

미국 정부 Microsoft Cloud 또는 기타 Azure 배포의 경우 azure_ad_endpointgraph_endpoint 설정을 구성하세요:

  service_desk_email:
    enabled: true
    address: "project_contact+%{key}@example.onmicrosoft.com"
    user: "project_contact@example.onmicrosoft.com"
    mailbox: "inbox"
    delivery_method: webhook
    log_path: "log/mailroom.log"
    secret_file: .gitlab-mailroom-secret
    inbox_method: "microsoft_graph"
    inbox_options:
      azure_ad_endpoint: "https://login.microsoftonline.us"
      graph_endpoint: "https://graph.microsoft.us"
      tenant_id: ""
      client_id: ""
      client_secret: ""
      poll_interval: 60  # 선택 사항

Service Desk 별칭 이메일의 접미사 구성#

프로젝트의 Service Desk 설정에서 사용자 정의 접미사를 설정할 수 있습니다.

접미사는 소문자(a-z), 숫자(0-9), 밑줄(_)만 포함할 수 있습니다.

구성되면 사용자 정의 접미사는 service_desk_email_address 설정과 <project_full_path>-<custom_suffix> 형식의 키로 구성된 새 Service Desk 이메일 주소를 생성합니다.

전제 조건:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.
  2. 왼쪽 사이드바에서 설정 > 일반을 선택하세요.
  3. Service Desk를 펼치세요.
  4. 이메일 주소 접미사 아래에 사용할 접미사를 입력하세요.
  5. 변경 사항 저장을 선택하세요.

예를 들어, mygroup/myproject 프로젝트 Service Desk 설정에 다음이 구성되었다고 가정하세요:

  • 이메일 주소 접미사가 support로 설정됨.
  • Service Desk 이메일 주소가 contact+%{key}@example.com으로 구성됨.

이 프로젝트의 Service Desk 이메일 주소는 contact+mygroup-myproject-support@example.com입니다. 수신 이메일 주소는 여전히 작동합니다.

사용자 정의 접미사를 구성하지 않으면 기본 프로젝트 식별이 프로젝트를 식별하는 데 사용됩니다.

다중 노드 환경에서 이메일 수신 구성#

다중 노드 환경은 확장성, 내결함성 및 성능을 위해 여러 서버에서 GitLab을 실행하는 설정입니다.

GitLab은 incoming_emailservice_desk_email 사서함에서 새로운 읽지 않은 이메일을 수신하기 위해 mail_room이라는 별도의 프로세스를 사용합니다.

Helm 차트 (Kubernetes)#

GitLab Helm 차트는 여러 서브차트로 구성되어 있으며, 그 중 하나가 Mailroom 서브차트입니다. incoming_email에 대한 공통 설정service_desk_email에 대한 공통 설정을 구성하세요.

Linux 패키지 (Omnibus)#

다중 노드 Linux 패키지 설치 환경에서는 하나의 노드에서만 mail_room을 실행하세요. 단일 rails 노드(예: application_role)나 완전히 별도로 실행하세요.

모든 노드 설정#

  1. 모든 노드에서 incoming_emailservice_desk_email에 대한 기본 구성을 추가하여 웹 UI 및 생성된 이메일에서 이메일 주소를 렌더링하세요.

    /etc/gitlab/gitlab.rb에서 incoming_email 또는 service_desk_email 섹션을 찾으세요:

   gitlab_rails['incoming_email_enabled'] = true
   gitlab_rails['incoming_email_address'] = "incoming+%{key}@example.com"
   gitlab_rails['service_desk_email_enabled'] = true
   gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.com"
  1. GitLab은 mail_room에서 GitLab 애플리케이션으로 이메일을 전송하는 두 가지 방법을 제공합니다. 각 이메일 설정에 대해 delivery_method를 개별적으로 구성할 수 있습니다:
    1. 권장: webhook(GitLab 15.3 이상의 기본값)은 이메일 페이로드를 GitLab 애플리케이션으로 API POST 요청으로 전송합니다. 인증에 공유 토큰을 사용합니다. 이 방법을 선택하면 mail_room 프로세스가 API 엔드포인트에 액세스할 수 있는지 확인하고 모든 애플리케이션 노드에 공유 토큰을 배포하세요.

      gitlab_rails['incoming_email_delivery_method'] = "webhook"

      # mail_room이 연결할 수 있는 URL. 내부 URL 또는 IP도 사용할 수 있지만
      # mail_room이 해당 주소로 GitLab API에 액세스할 수 있는지 확인하세요.
      # "/"로 끝내지 마세요.
      gitlab_rails['incoming_email_gitlab_url'] = "https://gitlab.example.com"

      # 무작위 토큰을 포함해야 하는 공유 시크릿 파일. 모든 노드에서 동일한지 확인하세요.
      gitlab_rails['incoming_email_secret_file'] = ".gitlab_mailroom_secret"
      ```

</div>

<div class="tab-panel" data-tab-index="1">

```ruby
      gitlab_rails['service_desk_email_delivery_method'] = "webhook"

      # mail_room이 연결할 수 있는 URL. 내부 URL 또는 IP도 사용할 수 있지만
      # mail_room이 해당 주소로 GitLab API에 액세스할 수 있는지 확인하세요.
      # "/"로 끝내지 마세요.

      gitlab_rails['service_desk_email_gitlab_url'] = "https://gitlab.example.com"

      # 무작위 토큰을 포함해야 하는 공유 시크릿 파일. 모든 노드에서 동일한지 확인하세요.
      gitlab_rails['service_desk_email_secret_file'] = ".gitlab_mailroom_secret"
      ```

</div>

</div>

   1. `webhook` 설정에 문제가 있으면 `sidekiq`를 사용하여 Redis를 통해 GitLab Sidekiq에 직접 이메일 페이로드를 전달하세요.

      <div class="tabs-container" data-tabs><div class="tabs-nav"><button class="tab-button active" data-tab-index="0">`incoming_email`</button><button class="tab-button" data-tab-index="1">`service_desk_email`</button></div><div class="tab-panel active" data-tab-index="0">

```ruby
      # Redis 구성을 사용하여 직접 Sidekiq 작업을 추가합니다
      gitlab_rails['incoming_email_delivery_method'] = "sidekiq"
      ```

</div>

<div class="tab-panel" data-tab-index="1">

```ruby
      # Redis 구성을 사용하여 직접 Sidekiq 작업을 추가합니다
      gitlab_rails['service_desk_email_delivery_method'] = "sidekiq"
      ```

</div>

</div>

1. 이메일 수신을 실행하지 않아야 하는 모든 노드에서 `mail_room`을 비활성화하세요. 예를 들어 `/etc/gitlab/gitlab.rb`에서:

   ```ruby
   mailroom['enable'] = false
  1. 변경 사항을 적용하기 위해 GitLab을 재구성하세요.

단일 이메일 수신 노드 설정#

모든 노드를 설정하고 mail_room 프로세스를 비활성화한 후, 단일 노드에서 mail_room을 활성화하세요. 이 노드는 정기적으로 incoming_emailservice_desk_email의 사서함을 폴링하고 새 읽지 않은 이메일을 GitLab으로 이동합니다.

  1. 이메일 수신도 처리할 기존 노드를 선택하세요.

  2. incoming_emailservice_desk_email에 대한 전체 구성 및 자격증명을 추가하세요.

  3. 이 노드에서 mail_room을 활성화하세요. 예를 들어 /etc/gitlab/gitlab.rb에서:

    mailroom['enable'] = true
    
  4. 변경 사항을 적용하기 위해 이 노드에서 GitLab을 재구성하세요.

여러 프로젝트에 대해 Service Desk 끄기#

네임스페이스의 여러 프로젝트에서 Service Desk를 끄려면 API를 사용하거나, GitLab Self-Managed에서는 Rails 콘솔을 사용하세요.

그룹 또는 네임스페이스의 프로젝트에 대해 Service Desk를 끄면 다음이 적용됩니다:

Warning

데이터를 변경하는 명령어는 올바르게 실행되지 않거나 적절한 조건에서 실행되지 않으면 손상을 일으킬 수 있습니다. 항상 테스트 환경에서 먼저 명령어를 실행하고 복원할 수 있는 백업 인스턴스를 준비하세요.

네임스페이스의 모든 프로젝트에 대해 Service Desk를 끄려면 다음 명령어를 실행하세요. my-namespace를 그룹 또는 개인 네임스페이스의 전체 경로로 바꿉니다.

namespace = Namespace.find_by_full_path!('my-namespace')
scope = namespace.is_a?(Group) ? namespace.all_projects : namespace.projects

scope.where(service_desk_enabled: true).each_batch(of: 100) do |batch|
  batch.update_all(service_desk_enabled: false)
end

일부 프로젝트에서 Service Desk를 활성 상태로 유지하려면 해당 프로젝트 ID를 제외합니다:

keep_ids = [42, 1337]
namespace = Namespace.find_by_full_path!('my-namespace')
scope = namespace.is_a?(Group) ? namespace.all_projects : namespace.projects

scope.where(service_desk_enabled: true).where.not(id: keep_ids).each_batch(of: 100) do |batch|
  batch.update_all(service_desk_enabled: false)
end