26. 알림¶

26.1. 알림 계층 구조¶

특정 수준에 할당된 알림 템플릿은 다음과 같이 상위 오브젝트에 정의된 템플릿을 상속합니다.

• 작업 템플릿은 작업 템플릿에 정의된 알림 템플릿을 사용하고, 작업 템플릿에서 사용하는 프로젝트 및 해당 템플릿이 속한 조직에서 (프로젝트를 통해) 알림 템플릿을 상속합니다.

• 프로젝트 업데이트에서는 프로젝트에 정의된 알림 템플릿을 사용하고, 연결된 조직에서 알림 템플릿을 상속합니다.

• 인벤토리 업데이트에서는 인벤토리가 속한 조직에 정의된 알림 템플릿을 사용합니다.

• 임시 명령에서는 인벤토리가 연결된 조직에 정의된 알림 템플릿을 사용합니다.

26.2. 워크플로우¶

작업이 성공 또는 실패하면 오류 또는 성공 처리기에서 위에 정의된 절차를 통해 관련 알림 템플릿 목록을 가져옵니다. 그런 다음 각각 작업에 대한 관련 세부 정보가 포함된 알림 오브젝트를 생성하여 대상(이메일 주소, Slack 채널, SMS 번호 등)으로 보냅니다. 이러한 알림 오브젝트는 작업 유형(작업, 인벤토리 업데이트, 프로젝트 업데이트)에서 관련 리소스로 사용할 수 있으며 ``/api/v2/notifications``에서도 사용할 수 있습니다. 관련 리소스를 검사하여 알림 템플릿에서 보낸 알림을 확인할 수도 있습니다.

알림이 실패하면 연결된 작업에 영향을 미치지 않거나 실패합니다. 알림 상태는 세부 정보 끝점(/api/v2/notifications/<n>)에서 확인할 수 있습니다.

26.3. 알림 템플릿 생성¶

알림 템플릿을 생성하려면 다음을 수행합니다.

1. 왼쪽 탐색 모음에서 **알림**을 클릭합니다.

2. 추가 버튼을 클릭합니다.

3. 해당 필드에 알림 이름과 설명을 입력하고 알림이 속하는 조직(필수)을 지정합니다.

4. 유형 드롭다운 메뉴에서 알림 유형을 선택합니다. 자세한 내용은 다음 섹션을 참조하십시오.

5. 필요한 모든 정보가 완료되면 **저장**을 클릭하여 알림을 추가합니다.

26.4. 알림 유형¶

|at|에서 지원되는 알림 유형은 다음과 같습니다.

이들 각각에는 고유한 구성과 동작 의미 체계가 있으며, 테스트하는 데 서로 다른 접근 방식이 필요할 수 있습니다. 또한 각 유형의 알림을 특정 세부 정보 또는 알림을 트리거하는 일련의 기준으로 사용자 지정할 수 있습니다. 사용자 정의 알림을 구성하는 방법에 대한 자세한 내용은 :ref:`ug_custom_notifications`을 참조하십시오. 다음 섹션에서는 각 알림 유형에 대해 가능한 한 자세히 설명합니다.

26.4.1. 이메일¶

이메일 알림 유형은 다양한 SMTP 서버를 지원하며 TLS/SSL 연결을 지원합니다.

이메일 알림을 설정하려면 다음 세부 정보를 제공해야 합니다.

• 호스트

• 수신자 목록

• 보낸 사람 이메일

• 포트

• 시간 초과(초): |at|에서 포기하기 전에 이메일 서버에 연결을 시도할 수 있는 시간으로, 최대 120초까지 지정할 수 있습니다.

26.4.2. Grafana¶

Grafana는 매우 간단한 통합입니다. 먼저 `Grafana system`_에 API 키를 생성합니다. 이는 |at|에 제공된 토큰입니다.

Grafana 알림을 설정하려면 다음 세부 정보를 제공해야 합니다.

• Grafana URL: Grafana API 서비스의 URL, 일반적으로 ``http://yourcompany.grafana.com``입니다.

• Grafana API 키: 사용자가 Grafana 시스템에서 먼저 API 키를 생성해야 합니다. 이는 |at|에 제공된 토큰입니다.

참고할 다른 옵션은 다음과 같습니다.

• 대시보드 ID: Grafana 계정의 API 키를 생성한 경우 고유 ID를 사용하여 대시보드를 설정할 수 있습니다.

• 패널 ID: Grafana 인터페이스에 패널과 그래프를 추가한 경우 여기에서 ID를 지정할 수 있습니다.

• 주석 태그: 구성 중인 알림의 이벤트 유형을 식별하는 데 도움이 되는 키워드를 입력합니다.

• SSL 확인 비활성화: SSL 확인은 기본적으로 켜져 있지만 대상 인증서의 진위 확인 기능을 끄도록 선택할 수 있습니다. 내부 또는 개인 CA를 사용하는 환경에서는 확인을 비활성화도록 이 옵션을 선택해야 합니다.

26.4.3. IRC¶

IRC 알림은 채널 또는 개별 사용자를 연결하고 이들에게 메시지를 전달한 다음 연결을 끊는 IRC 봇의 형태를 취합니다. 알림 봇은 SSL 인증도 지원합니다. 봇은 현재 닉네임 식별 기능을 지원하지 않습니다. 채널 또는 사용자가 존재하지 않거나 온라인에 없는 경우에도 알림은 실패하지 않습니다. 연결을 위한 실패 시나리오가 특별히 예약되어 있습니다.

연결 정보는 간단합니다.

• IRC 서버 암호(선택 사항): IRC 서버에 연결하려면 암호가 필요할 수 있습니다. 서버에 필요하지 않는 경우 공백으로 둡니다.

• IRC 서버 포트: IRC 서버 포트입니다.

• IRC 서버 주소: IRC 서버의 호스트 이름 또는 주소입니다.

• IRC 닉네임: 서버에 연결된 봇의 닉네임입니다.

• 대상 채널 또는 사용자: 알림을 보낼 사용자 및/또는 채널 목록입니다.

• SSL 연결(선택 사항): 연결할 때 봇에서 SSL을 사용해야 합니다.

26.4.4. 가장 중요¶

Mattermost 알림 유형은 Mattermost의 메시징 및 협업 작업 공간에 간단한 인터페이스를 제공합니다. 지정할 수 있는 매개변수는 다음과 같습니다.

• 대상 URL(필수): 게시할 대상의 전체 URL입니다.

• 사용자 이름

• 채널

• 아이콘 URL: 이 알림에 표시할 아이콘을 지정합니다.

• SSL 확인 비활성화: 대상 인증서의 진위 확인 기능을 끕니다. 내부 또는 개인 CA를 사용하는 환경에서는 확인을 비활성화도록 이 옵션을 선택해야 합니다.

26.4.5. PagerDuty¶

PagerDuty는 매우 간단한 통합입니다. 먼저 `PagerDuty system`_에서 API 키(|at|에 제공되는 토큰)를 생성한 다음 |at|에도 제공될 《통합 키》를 제공하는 《서비스》를 생성합니다. 기타 필수 옵션은 다음과 같습니다.

• API 토큰: 사용자가 PagerDuty 시스템에서 먼저 API 키를 생성해야 합니다. 이는 |at|에 제공된 토큰입니다.

• PagerDuty 하위 도메인: PagerDuty 계정에 등록하면 통신에 사용할 고유한 하위 도메인이 제공됩니다. 예를 들어, 《testuser》로 등록한 경우 웹 대시보드는 ``testuser.pagerduty.com``에 있으며 하위 도메인으로 API ``testuser``가 제공됩니다(전체 도메인 아님).

• API 서비스/통합 키

• 클라이언트 ID: API 키/서비스를 사용 중인 서비스를 확인할 수 있도록 PagerDuty 서비스에 경고 내용과 함께 전송됩니다. 여러 통합에서 동일한 API 키 및 서비스를 사용하는 경우 유용합니다.

26.4.6. Rocket.Chat¶

Rocket.Chat 알림 유형은 Ramet.Chat의 협업 및 통신 플랫폼에 대한 인터페이스를 제공합니다. 지정할 수 있는 매개변수는 다음과 같습니다.

• 대상 URL(필수): 게시할 대상의 전체 URL입니다.

• 사용자 이름

• 아이콘 URL: 이 알림에 표시할 아이콘을 지정합니다.

• SSL 확인 비활성화: 대상 인증서의 진위 확인 기능을 끕니다. 내부 또는 개인 CA를 사용하는 환경에서는 확인을 비활성화도록 이 옵션을 선택해야 합니다.

26.4.7. Slack¶

Slack, 협업 팀 통신, 메시징 툴은 매우 쉽게 구성할 수 있습니다.

Slack 알림을 설정하려면 다음을 제공해야 합니다.

• Slack 앱(생성 방법에 대한 정보는 Slack 문서의 Basic App Setup 페이지 참조)

• 토큰(Token Types 문서 페이지에서 Enabling Interactions with Bots <https://api.slack.com/bot-users> 및 봇 토큰에 대한 특정 세부 정보 참조)

봇/앱을 설정한 후에는 《내 앱》으로 이동하여 새로 생성된 앱을 클릭하고 들어오는 Webhook, 봇, 권한을 구성할 수 있는 **기능 추가**로 이동해야 합니다. 그리고 **작업 공간에 앱을 설치**합니다.

또한 Slack에서 해당 채널에 가입하려면 알림 봇을 초대해야 합니다. 개인 메시지는 지원되지 않습니다.

26.4.8. Twilio¶

Twilio 서비스는 음성 및 SMS 자동화 서비스입니다. 로그인하면 메시지를 전송할 전화번호를 생성해야 합니다. 그러면 프로그램 가능한 SMS에 《메시징 서비스》를 정의하고 이전에 생성한 번호와 연결할 수 있습니다.

이 번호를 사용하여 임의의 번호로 전송하려면 먼저 이 번호 또는 몇 가지 기타 정보를 확인해야 할 수 있습니다. 메시징 서비스에는 상태 콜백 URL이 필요하지 않으며 인바운드 메시지를 처리하는 기능도 필요하지 않습니다.

개별 (또는 하위) 계정 설정에 API 인증 정보가 있습니다. Twilio는 두 가지 인증 정보를 사용하여 API 요청을 보내는 계정을 확인합니다. 즉, 사용자 이름 역할을 하는 ‘계정 SID’와 암호 역할을 하는 ‘인증 토큰’입니다.

Twilio를 설정하려면 다음 세부 정보를 제공합니다.

• 계정 토큰

• 원본 전화번호(위 메시징 서비스와 연결된 번호이며 《+15556667777》 형식으로 제공되어야 함)

• 대상 SMS 번호(SMS를 수신할 번호 목록이며 10자리 전화번호여야 함)

• 계정 SID

26.4.9. Webhook¶

Webhook 알림 유형은 사전 정의된 웹 서비스에 POST를 보내는 간단한 인터페이스를 제공합니다. |at|는 json 형식의 모든 관련 세부 정보가 포함된 데이터 페이로드와 함께 애플리케이션/json 콘텐츠 유형을 사용하여 이 주소에 POST합니다. 일부 웹 서비스 API에서는 HTTP 요청이 특정 필드가 포함된 특정 형식이어야 합니다. 다음과 같은 방법으로 Webhook 알림을 추가로 구성할 수 있습니다.

• HTTP 메서드 구성(POST 또는 PUT 사용)

• 발신 요청 본문

• 인증 구성(기본 인증 사용)

Webhook 구성에 사용되는 매개변수는 다음과 같습니다.

• 사용자 이름

• 기본 인증 암호

• 대상 URL(필수): Webhook 알림이 PUT 또는 POST될 전체 URL입니다.

• SSL 확인 비활성화: SSL 확인은 기본적으로 켜져 있지만 대상 인증서의 진위 확인 기능을 끄도록 선택할 수 있습니다. 내부 또는 개인 CA를 사용하는 환경에서는 확인을 비활성화도록 이 옵션을 선택해야 합니다.

• HTTP 헤더(필수): 키와 값이 문자열인 JSON 형식의 헤더입니다. 예를 들면 ``{《Authentication》: 《988881adc9fc3655077dc2d4d757d480b5ea0e11》, 《MessageType》: 《Test》}``입니다.

• HTTP 메서드(필수). Webhook의 메서드를 선택합니다.

  • POST: 새 리소스를 생성합니다. 또한 다른 카테고리에 맞지 않는 작업에 대해 다양한 역할을 합니다. Webhook 서비스에 PUT이 필요하지 않은 경우 POST를 수행해야 할 수 있습니다.

  • PUT: 특정 리소스(ID별) 또는 리소스 컬렉션을 업데이트합니다. 리소스 ID를 미리 알고 있는 경우 PUT을 사용하여 특정 리소스를 생성할 수도 있습니다.

26.4.9.1. Webhook 페이로드¶

|At|는 기본적으로 Webhook 끝점에서 다음 데이터를 보냅니다.

job id
name
url
created_by
started
finished
status
traceback
inventory
project
playbook
credential
limit
extra_vars
hosts
http method

다음은 Webhook 메시지를 통해 |at|에서 반환하는 started 알림의 예입니다.

{"id": 38, "name": "Demo Job Template", "url": "https://host/#/jobs/playbook/38", "created_by": "bianca", "started":
"2020-07-28T19:57:07.888193+00:00", "finished": null, "status": "running", "traceback": "", "inventory": "Demo Inventory",
"project": "Demo Project", "playbook": "hello_world.yml", "credential": "Demo Credential", "limit": "", "extra_vars": "{}",
"hosts": {}}POST / HTTP/1.1

|At|는 기본적으로 success/fail 상태에 대해 Webhook 끝점에서 다음 데이터를 반환합니다.

job id
name
url
created_by
started
finished
status
traceback
inventory
project
playbook
credential
limit
extra_vars
hosts

다음은 Webhook 메시지를 통해 |at|에서 반환하는 success/fail 알림의 예입니다.

{"id": 46, "name": "AWX-Collection-tests-awx_job_wait-long_running-XVFBGRSAvUUIrYKn", "url": "https://host/#/jobs/playbook/46",
"created_by": "bianca", "started": "2020-07-28T20:43:36.966686+00:00", "finished": "2020-07-28T20:43:44.936072+00:00", "status": "failed",
"traceback": "", "inventory": "Demo Inventory", "project": "AWX-Collection-tests-awx_job_wait-long_running-JJSlglnwtsRJyQmw", "playbook":
"fail.yml", "credential": null, "limit": "", "extra_vars": "{\"sleep_interval\": 300}", "hosts": {"localhost": {"failed": true, "changed": 0,
"dark": 0, "failures": 1, "ok": 1, "processed": 1, "skipped": 0, "rescued": 0, "ignored": 0}}}

26.5. 사용자 정의 알림 생성¶

토글 버튼을 사용하여 알림 양식 하단의 메시지 사용자 정의 부분을 활성화하면 각 :ref:`ug_notifications_types`의 :ref:`customize the text content <ir_notifications_reference>`를 수행할 수 있습니다.

다양한 작업 이벤트에 대해 사용자 정의 메시지를 제공할 수 있습니다.

• 시작

• 성공

• 오류

• 워크플로우 승인됨

• 워크플로우 거부됨

• 워크플로우 실행 중

• 워크플로우 시간 초과

메시지 양식은 구성 중인 알림 유형에 따라 다릅니다. 예를 들어, 이메일 및 PagerDuty 알림에 대한 메시지에는 제목과 본문이 있는 일반적인 이메일 양식으로 표시됩니다. 이 경우 |at|에 해당 필드가 메시지 및 **메시지 본문**으로 표시됩니다. 기타 알림 유형에는 각 이벤트 유형에 대한 **메시지**만 있으면 됩니다.

메시지 필드는 id 또는 ``name``과 같은 특성과 함께 최상위 변수 ``job``이 포함된 템플릿으로 미리 채워집니다. 템플릿은 중괄호로 묶여 있으며 미리 채워진 메시지 필드에 표시된 것처럼 |at|에서 제공하는 고정 필드 세트에서 가져올 수 있습니다.

미리 채워진 이 필드에서는 이벤트 알림을 받는 수신자에게 일반적으로 표시되는 메시지를 제안합니다. 그러나 필요에 따라 작업에 대한 고유한 특성을 추가하여 다른 기준으로 이러한 메시지를 사용자 정의할 수 있습니다. 사용자 정의 알림 메시지는 Ansible 플레이북에서 사용하는 것과 동일한 템플릿 작성 엔진인 Jinja를 사용하여 렌더링됩니다.

메시지 및 메시지 본문에는 다음과 같이 다양한 유형의 콘텐츠가 있습니다.

• 메시지는 항상 문자열입니다(단일 행 사용, 새 줄은 허용되지 않음)

• 메시지 본문은 사전 또는 텍스트 블록입니다.

  • Webhooks 및 *PagerDuty*의 메시지 본문에서는 사전 정의를 사용합니다. 이들에 대한 기본 메시지 본문은 ``{{ job_metadata }}``이며 그대로 유지하거나 고유한 사전을 제공할 수 있습니다.

  • 이메일의 메시지 본문에는 텍스트 블록이나 여러 행의 문자열이 사용됩니다. 기본 메시지 본문은 다음과 같습니다.

  {{ job_friendly_name }} #{{ job.id }} had status {{ job.status }}, view details at {{ url }} {{ job_metadata }}
  

  이 텍스트는 조정할 수 있습니다(``{{ job_metadata }}``를 그대로 두거나 ``{{ job_metadata }}``를 모두 삭제). 본문이 텍스트 블록이므로 실제로 원하는 모든 문자열이 가능합니다.

  ``{{ job_metadata }}``는 실행 중인 작업을 설명하는 필드를 포함하는 사전으로 렌더링됩니다. 모든 경우 ``{{ job_metadata }}``에 다음 필드가 포함됩니다.

  • id

  • name

  • url

  • created_by

  • started

  • finished

  • status

  • traceback

  참고

  현재는 {{ job_metadata }} 내의 개별 필드를 쿼리할 수 없습니다. 알림 템플릿에서 ``{{ job_metadata }}``을 사용하면 모든 데이터가 반환됩니다.

  생성된 사전은 다음과 같습니다.

  {"id": 18,
   "name": "Project - Space Procedures",
   "url": "https://host/#/jobs/project/18",
   "created_by": "admin",
   "started": "2019-10-26T00:20:45.139356+00:00",
   "finished": "2019-10-26T00:20:55.769713+00:00",
   "status": "successful",
   "traceback": ""
  }
  

  작업에서 ``{{ job_metadata }}``가 렌더링되면 다음과 같은 추가 필드가 포함됩니다.

  • inventory

  • project

  • playbook

  • credential

  • limit

  • extra_vars

  • hosts

  
  

  생성된 사전은 다음과 같습니다.

  {"id": 12,
   "name": "JobTemplate - Launch Rockets",
   "url": "https://host/#/jobs/playbook/12",
   "created_by": "admin",
   "started": "2019-10-26T00:02:07.943774+00:00",
   "finished": null,
   "status": "running",
   "traceback": "",
   "inventory": "Inventory - Fleet",
   "project": "Project - Space Procedures",
   "playbook": "launch.yml",
   "credential": "Credential - Mission Control",
   "limit": "",
   "extra_vars": "{}",
   "hosts": {}
  }
  

  워크플로우 작업에서 ``{{ job_metadata }}``가 렌더링되면 다음과 같은 추가 필드가 포함됩니다.

  • ``body``(워크플로우 작업의 모든 노드가 나열되고 각 노드와 연결된 작업에 대한 설명이 포함됨)

  
  

  생성된 사전은 다음과 같습니다.

  {"id": 14,
   "name": "Workflow Job Template - Launch Mars Mission",
   "url": "https://host/#/workflows/14",
   "created_by": "admin",
   "started": "2019-10-26T00:11:04.554468+00:00",
   "finished": "2019-10-26T00:11:24.249899+00:00",
   "status": "successful",
   "traceback": "",
   "body": "Workflow job summary:
  
           node #1 spawns job #15, \"Assemble Fleet JT\", which finished with status successful.
           node #2 spawns job #16, \"Mission Start approval node\", which finished with status successful.\n
           node #3 spawns job #17, \"Deploy Fleet\", which finished with status successful."
  }
  

자세한 내용은 `Using variables with Jinja2`_을 참조하십시오.

|At|에서 메시지를 표시하기 위해 올바른 데이터를 검색하려면 유효한 구문이 필요합니다. 지원되는 특성 목록과 적절한 구문 구성은 이 가이드의 사용자 정의 알림에 지원되는 특성 섹션을 참조하십시오.

잘못된 구문을 사용하거나 사용할 수 없는 필드를 참조하는 알림 템플릿을 생성하면 오류의 종류를 나타내는 오류 메시지가 표시됩니다. 알림의 사용자 정의 메시지를 삭제하면 기본 메시지가 해당 위치에 표시됩니다.

참고

사용자 정의 메시지를 편집하지 않고 알림 템플릿을 저장하면(또는 편집한 후 기본값으로 되돌리기) 세부 정보 화면에서 기본값을 가정하고 사용자 정의 메시지 테이블을 표시하지 않습니다. 값을 편집하고 저장하면 전체 테이블이 세부 정보 화면에 표시됩니다.

26.6. 알림 활성화 및 비활성화¶

작업 실행이 끝날 때 성공 또는 실패를 알리는 것 외에도 특정 작업이 시작될 때 알리는 알림을 선택할 수 있습니다. 다음은 고려해야 할 몇 가지 동작입니다.

• 워크플로우 템플릿(WFJT)에 시작 시 알림이 활성화되어 있고 해당 워크플로우 내의 작업 템플릿(JT)에도 시작 시 알림이 활성화되어 있는 경우 두 가지 모두에 대한 알림을 받게 됩니다.

• WFJT 내의 여러 JT에서 실행되도록 알림을 활성화할 수 있습니다.

• 분할된 작업 템플릿(SJT) 시작 시 실행되도록 알림을 활성화할 수 있으며 각 슬라이스에서 알림을 생성합니다.

• 작업 시작 시 실행되도록 알림을 활성화한 후 해당 알림이 삭제되면 JT는 계속 실행되지만 오류 메시지가 표시됩니다.

다음 리소스의 알림 탭에서 작업 시작, 작업 성공, 작업 실패 또는 이들의 조합에 대한 알림을 활성화할 수 있습니다.

• 작업 템플릿

• 워크플로우 템플릿

• 프로젝트(아래 예 참조)

• 인벤토리 소스

• 조직

승인 노드가 있는 워크플로우 템플릿의 경우 시작, 성공, 실패 외에도 특정 승인 관련 이벤트를 활성화하거나 비활성화할 수 있습니다.

이러한 유형의 노드 작업에 대한 자세한 내용은 :ref:`ug_wf_approval_nodes`를 참조하십시오.

26.7. 알림을 위한 host 호스트 이름 구성¶

:ref:`System Settings <configure_tower_system>`에서 서비스의 기본 URL 필드에 있는 ``https://server.example.com``을 선호하는 호스트 이름으로 교체하여 알림 호스트 이름을 변경할 수 있습니다.

라이센스를 새로 고치면 알림 호스트 이름도 변경됩니다. |at|를 새로 설치할 때는 알림 호스트 이름을 설정할 필요가 없습니다.

26.8. 알림 API¶

started, success 또는 error 끝점을 사용합니다.

/api/v2/organizations/N/notification_templates_started/
/api/v2/organizations/N/notification_templates_success/
/api/v2/organizations/N/notification_templates_error/

또한 ../../../N/notification_templates_started 끝점에는 다음에 대한 GET 및 POST 동작이 있습니다.

• 조직

• 프로젝트

• 인벤토리 소스

• 작업 템플릿

• 시스템 작업 템플릿

• 워크플로우 작업 템플릿