본문 바로가기
카테고리 없음

5단계로 진행되는 AWS의 서버리스 Discord 봇 사용하는 방법

by 부동산절대원칙 2022. 6. 12.
반응형

5단계로 진행되는 AWS의 서버리스 Discord 봇 사용하는 방

 

프록시 Lambda를 사용하는 AWS API Gateway의 본문 기반 라우팅 — AWS SAM과 함께 배포

 

Unsplash의 Alexander Shatov 사진

이전 기사에서는 AWS Lambda를 사용하여 Discord 봇을 구축했습니다. AWS Portal의 모든 항목을 클릭했는데 모두 좋았습니다. API 게이트웨이와 "hello world" Lambda를 설정했습니다.

하지만 하나의 작은 세부 사항을 숨겼습니다.

서버리스 애플리케이션을 만든다는 것은 각 의무에 대해 하나의 람다 함수를 만드는 것을 의미합니다. 이를 단일 책임 원칙이라고 합니다. 기사에서 우리는 단 하나의 책임을 가졌습니다. 구경하다:

이제 이 파일에 두 번째 함수를 추가한다고 상상해 보십시오. 그리고 세 번째. 시원한. 그리고 이러한 함수는 아마도 단순히 문자열로 응답하는 것이 아니라 일부 렌더링/계산/무엇이든 수행합니다. 그리고 그들은 더 커집니다. 엄청난.

이제 우리는 서버리스용 주요 안티 패턴인 Lambda Monolith를 구현했습니다.

우리는 각 상호 작용을 다른 Lambda에 위임하여 다양한 Discord 사용자 상호 작용을 처리하고자 합니다. 문제는… Discord가 모든 이벤트를 하나의 끝점으로 보냅니다. API Gateway는 기본적으로 요청 헤더 및 경로를 기반으로 Lambda로 요청을 라우팅할 수 있지만 요청 본문을 통한 라우팅은 쉽지 않고 제한적인 템플릿 매핑을 사용해야 합니다.

요청을 대리할 무언가가 필요합니다.

Proxy API Gateway 및 Proxy Lambda를 사용하여 다음으로 가는 요청을 처리합니다. / 경로(프록시 부분). 그런 다음 이벤트를 Main Lambda로 추가로 분할하는 특수 매개변수를 사용하여 SNS 주제로 라우팅합니다.

우리 솔루션의 아키텍처

이 아키텍처:

  1. 라우팅 중에만 프록시 Lambda를 실행합니다.
    기본 Lambda가 요청을 처리할 때 프록시 Lambda가 실행되지 않습니다(중첩 Lambda에서 발생하는 것처럼).
  2. Proxy와 Main 부분을 분리합니다.
    다른 서버리스 애플리케이션(즉, Discord가 아님)에서 개발, 테스트 및 마이그레이션하는 데 도움이 됩니다.
  3. Proxy Lambda를 Discord 요청 확인을 위한 이상적인 장소로 만듭니다.

데이터 흐름:

  • 사용자가 보낸다 /hello 디스코드 채널에서
  • Discord 앱 서버는 이벤트를 프록시 API 게이트웨이 URL(설정에서 설정)로 보냅니다.
  • Proxy API Gateway는 이벤트를 Proxy Lambda로 보냅니다.
  • Proxy Lambda는 요청을 확인하고 메인 기능이 실행되는 동안 표시될 임시 응답 "Loading..."으로 Discord App Server에 응답합니다. 추가 처리를 위해 명령 이름을 호출하도록 MessageParameter를 설정합니다.
  • SNS(Simple Notification Service)가 이벤트를 수신합니다. MessageParameter를 기반으로 적절한 Lambda로 이벤트를 처리합니다.
  • (단일 책임) Lambda는 이벤트를 처리하고 "Hello from Lambda!"라는 내용의 POST 요청을 보냅니다. Discord 앱 서버의 웹훅으로 돌아갑니다.
  • Discord 앱 서버가 응답을 편집합니다. /hello Discord 채널에서 "Loading..."에서 "Hello from Lambda!"로.

AWS SAM 및 git 리포지토리의 템플릿과 함께 Infrastructure as Code 도구를 사용하여 이 앱을 빌드합니다. 이 상용구를 복제하면 자신의 Lambda를 사용하여 그 이상으로 쉽게 이동할 수 있습니다.

AWS SAM에 대해 들어본 적이 없습니까? 내 다른 기사에서 빠른 요약을 찾으십시오.

요구 사항

1. Discord 앱 만들기

Discord 개발자 포털 → 새 애플리케이션으로 이동합니다.

봇 → 봇 추가

다음을 사용하여 길드(OAuth2 메뉴)에 봇을 초대합니다. Bot, applications.commands , Use Application Commands그리고 Send Messages 특권.

(추가 도움말)

2. 명령어 등록

설정에서 개발자 모드를 활성화하고 길드를 마우스 오른쪽 버튼으로 클릭하여 개발 길드(Discord 서버) ID를 가져옵니다.

Discord 개발자 포털에서 앱 ID와 봇 토큰을 받으세요.

그런 다음 개발을 위해 한 길드에 명령을 등록합니다(즉시).

node register_commands/register.js --env dev --guild-id YOUR_GUILD_ID --bot-token YOUR_BOT_TOKEN --app-id YOUR_APPLICATION_ID

3. 상용구 복제

mkdir serverless-discord-bot && \
cd serverless-discord-bot && \
sam init --location gh:jakjus/serverless-discord-bot

4. AWS에서 애플리케이션 구축 및 배포

sam build && sam deploy --guided

다음을 제외하고 모든 답변은 기본 답변이 될 수 있습니다(Enter 키만 누름).

  1. 메시지가 표시되면 DiscordAppPublicKey1단계의 키를 붙여넣습니다.
  2. 메시지가 표시되면 [Some function] may not have authorization defined, Is this okay? , 로 대답하다 y

5. Discord Webhook URL 설정

이전 명령은 다음을 보여줍니다.

------------------------------------------Outputs------------------------------------------Key                 ProxyGWEndpointDescription         API Gateway endpoint URL to pass 
to Discord Application PortalValue               https://s0meur1.execute-api.zone
-name-1.amazonaws.com/Prod/------------------------------------------

출력의 설명이 모든 것을 말해줍니다.

URL을 복사하여 Discord 개발자 포털의 "상호작용 엔드포인트 URL" 필드에 다시 붙여넣습니다.

상호 작용 끝점 URL 필드입니다.

변경 사항 저장을 클릭합니다.

말하다 /hello 당신의 새로운 봇에.

디스코드 길드 채팅. 슬래시 명령과 상호 작용합니다.

봇은 다음과 같이 응답할 것입니다.

IaaS(Infrastructure as a Code)의 힘, 맞습니까?

함수가 다른 작업을 수행하도록 합니다.

  1. 에서 코드를 변경하십시오. src/handlers/hello-from-lambda.js
  2. 운영 sam build && sam deploy
    동안 입력 값을 저장한 경우 --guided 실행하면 이 플래그 없이 실행하여 값을 재사용할 수 있습니다.

나만의 기능 추가

  1. 에 명령 추가 register_commands/commands.yaml 그리고 다시 등록합니다.
  2. 에서 새 함수에 대한 핸들러 생성 src/handlers/ 비슷하다 hello-from-lambda.js.
  3. 새 핸들러에 대한 참조 추가 template.yaml 유사하게 helloFromLambdaFunction. 변화 Properties.Handler 그리고 Events.SNSEvent.Properties.FilterPolicy.command.

청소

이러한 모든 리소스는 프리 티어에 있습니다. 다음을 사용하여 리소스를 청소하는 것을 잊지 않는 것이 좋습니다.

sam destroy

완료 후.

이 문서에는 다음이 포함됩니다.

  • AWS SAM에서 템플릿을 사용하는 방법을 배웠습니다.
  • 지정된 서버리스 아키텍처 및 그 추론 이해
  • 이벤트를 영원히 수신 대기하는 전체 스택 서버리스 애플리케이션을 AWS에 배포했습니다.
  • 그리고 이제까지
  • 또는 신용 카드가 만료될 때까지

우리가 수행한 설정은 처음에는 파악하기가 매우 어렵습니다. 그렇기 때문에 AWS SAM 및 IaC 관행에서는 한 명의 가난한 사람만 이 모든 과정을 거쳐야 합니다. 그 사람이 바로 나였다.

다음은 상용구 저장소입니다. 기여를 환영합니다.

이 기사를 위해 많은 조사를 했지만 가장 중요한 질문이 여전히 남아 있습니다.

그것으로 무엇을 만들 것인가?

반응형