프로그래밍 「 리눅스 편」DevOps를 위한 Slack 워크플로 예시

Slack의 원본, Michael Bladowski의 수정

Slack에서 Pro 또는 Enterprise 플랜을 실행하는 경우 이것이 흥미로울 수 있습니다. Slack에는 워크플로라는 것이 있습니다.

거의 모든 것에 사용할 수 있습니다. 이 게시물을 통해 이러한 워크플로와
웹훅 수신 기능을 사용하는 방법에 대한 매우 기본적이고 간단한 예를 보여 드리고자 합니다.

여러 서버를 관리하는 DevOps 팀이라고 가정해 보겠습니다.
누군가, 귀하 또는 귀하의 팀원이 서비스를 중지할 때 다음 사항을 알아두면 됩니다.

• 이런 일이 일어 났을 때
• 사람이 일부러 그랬다면
• 서비스가 다시 실행 중일 때

서버에있는 누군가가 다음을 수행하고 있다고 가정 해 봅시다.

systemctl stop cron

다음과 같은 채널 중 하나에서 메시지를 보려면 다음 단계를 따르세요.

이것은 독일어의 예입니다

따라서 이 (독일어) 예에서 채널의 모든 사람은 다음과 같은 알림을 받게 됩니다.

이봐, 서버 XYZ의 Cron-Daemon이 중지되었습니다! (작업이 끝날 때마다 시작하는 것을 잊지 마십시오)"

그리고 당신이 할 때 :

systemctl start cron

보고 싶은 것:

이것은 독일어의 예입니다

다음과 같은 메시지가 표시됩니다.

이봐, 서버 XYZ의 Cron-Daemon이 돌아와 다시 실행됩니다!

자, 이것이 얼마나 쉬운지 설명하겠습니다.

• "서비스 XYZ가 다운되었습니다"라는 워크플로우를 만듭니다.
• "웹훅"을 선택하십시오.

Slack 워크플로 만들기

'다음'을 누르기만 하면 되지만 나중에 채널 메시지에서 사용할 수 있는 '매개변수'를 제공하는 것은 사용자의 몫입니다.

첫 번째 부분은 이 워크플로를 시작하는 "트리거"일 뿐이므로 "단계 추가"를 누릅니다. 하지만 지금은 워크플로가 비어 있습니다. 그래서 우리는 주요 부분을 추가해야합니다 : 서버에 메시지 보내기 :

우리는 "메시지 보내기"를 선택합니다.

여기서는 실제로 웹훅에 의해 트리거되는 메시지를 만듭니다.

완료되면 모든 단계를 다시 반복하지만 2 라운드에서는 "서비스가 온라인 상태이며 다시 실행 중입니다"라는 메시지가 생성됩니다.

 

중요하다: Webhook-URL을 검색하지 마세요, 워크플로가 게시될 때까지 얻을 수 없습니다. 일단 그것들이 있으면 여기에서 얻을 수 있습니다.

이제 우리가 어디에 있는지 요약 해 보겠습니다.

• SLACK에서 서비스가 다운되었음을 알리는 웹훅 URL을 호출하여 시작하는 워크플로 하나를 만들었습니다
• SLACK에서 서비스가 다시 작동 중이라는 웹훅 URL을 호출하여 시작하는 두 번째 워크플로를 만들었습니다

따라서 다음과 같은 두 개의 웹훅 URL이 있습니다.

https://hooks.slack.com/workflows/ABCDEF/ABCDEF/12323123/ihhiofweqhofi

나는 말할 수 있었다 : 자, 당신이 원하는 곳에서이 URL을 트리거하고 재미있게 보내십시오.

그러나 하나 또는 다른 DevOp가 좋아할만한 구체적인 예를 보여주고 싶습니다.

Linux 서버로 작업 중이고 이미 언급한 호출을 통해 서비스가 시작 및 중지되었다고 가정해 보겠습니다 systemctl start/stop service

우분투 서버가 있다고 가정 해 봅시다. 모든 서비스 (보통)에는 다음과 같은 파일이 있습니다.

/lib/systemd/system/{service}.service

so when we talk about "cron" we should see a file called:

/lib/systemd/system/cron.service

이 파일은 다음과 같을 수 있습니다.

[Unit]
Description=Regular background program processing daemon
Documentation=man:cron(8)
After=remote-fs.target nss-user-lookup.target

[Service]
EnvironmentFile=-/etc/default/cron
ExecStart=/usr/sbin/cron -f $EXTRA_OPTS
IgnoreSIGPIPE=false
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target

"man systemd.service"라고 부르면 여기에서 가능한 것을 볼 수 있습니다.
여기서 할 수 있는 일은 매우 멋지며, 이러한 서비스 구성은 매우
유연하고 강력합니다.

우리가 필요로하는 두 가지 간단한 열쇠가 있습니다.

• ExecStartPost (실행 시작 포스트)
• ExecStopPost (실행 중지)

짐작할 수 있듯이 :

ExecStartPost: 서비스가 시작된
"후" 명령 실행 ExecStopPost: 서비스가 중지된 "후" 명령 실행

그래서 아래에 추가합니다.[Service]

ExecStartPost=-curl -s -I "https://hooks.slack.com/workflows/ABCDEFGH/SG7837GUGU/463989938774395593/weopijqfopjweop" > /dev/null
ExecStopPost=-curl -s -I "https://hooks.slack.com/workflows/ABCDEFGH/SG7837GUGU/463989105651380516/wiopqejfopjqwepofj" > /dev/null

참고 : "curl"앞의 "-"는 종료 코드를 무시하고 항상 0을 반환합니다.
(이것을 호출하는 방법과 출력 및 오류를 처리하는 방법은 사용자에게 달려 있습니다.)

파일을 수정한 후 다음을 잊지 마십시오. systemctl daemon-reload

이 두 줄을 서비스 구성에 추가하면 서비스가 중지되고 다시 시작될 때 팀에 알릴 수 있습니다.

이 설정은 5 분 밖에 걸리지 않으며 이러한 워크 플로가 얼마나 강력한지, 일상 업무에서 어떻게 사용할 수 있는지에 대해 꽤 잘 알 수 있습니다.

 

말했듯이 가능성은 무한하며 이전에 Slack 워크플로를 사용한 적이 없다면 이번이 마지막이 아닐 것이라고 확신합니다 ;-) Zapier를 이 게임에 ☺ 도입하면 어떤 일이 일어날지 상상해 보세요