Forem: HyeonJun

AWS - API Gateway to SQS

HyeonJun — Thu, 17 Aug 2023 02:36:45 +0000

1. IAM 정책 생성

SQS 권한 추가 (ID에는 AWS 계정ID)

2-1. IAM 역할 생성

API Gateway 서비스 선택 후 역할 생성

2-2. IAM 역할 권한 추가

생성한 역할에 정책연결을 통해 생성한 권한 추가

3. API Gateway 생성

REST API 구축
REST API 이름 설정 및 API 생성 (API Gateway 내부에서 dv/prod 등 스테이지 구분 가능)

4-1. 리소스 생성

리소스 이름 지정 + 경로 지정

4-2. 메소드 생성

AWS 서비스 SQS 선택
경로 재정의를 사용하여 SQS로 전송 (경로는 현재 예시 기준 ID/api-gateway-to-sqs 경로 패턴: ${AWS 계정ID}/${SQS-이름})
실행 역할은 위에서 생성한 IAM 역할의 arn 값

5. 메소드 상세 설정

통합 요청 탭에서 HTTP 헤더 설정 및 매핑 템플릿 추가
템플릿

Action=SendMessage&MessageBody=$input.body

6. 테스트

테스트에서 테스트 요청이 가능함.
응답 본문에 messageId 확인 + 경로로 지정한 SQS의 사용가능한 메시지 개수 확인.

FYI.

stage변수 사용방법
- stage 배포 및 stage 변수 추가 후 ${stageVariables.변수명}으로 사용가능.

cf.

AWS EventBridge - pipe

HyeonJun — Mon, 05 Jun 2023 02:33:26 +0000

AWS EventBridge Pipe 란?

특정 소스 (DynamoDB, Kinesis, SQS 등) 다양한 소스에서 이벤트가 발생했을때, 이벤트를 핸들링해서 AWS 서비스(Lambda), 이벤트 버스 또는 API로 전송하는 역할을 합니다.

소스

어떤 AWS 서비스에 pipe가 트리거되게 할지 (이 글은 SQS를 기준으로 작성되었습니다.)

서비스 목록
- Kinesis
- SQS
- DynamoDB
- Amazon MQ
- Apache Kafka
- Amazon MSK

필터링(선택)

트리거된 이벤트에 이벤트 패턴을 비교하여 필터링 처리함.
이벤트 패턴 필터링 문서
예시) SQS body로 넘어오는 값 필터링 하는 법.

{
  "body": {
    "pattern": "AWS",
    "data": {
      "id": "test",
      "name": "test"
    }
  }
}

SQS message body에 pattern 값으로 필터링 하고싶을 경우 이벤트 패턴에 다음과 같이 작성하면 필터링 할 수 있습니다!

{
  "body": {
    "pattern": ["AWS"]
  }
}

보강(선택)

최종 대상에 요청을 전송하기 전에 Lambda 또는 특정 API에 request를 날려서 데이터를 추가로 받아와서 대상에게 요청할때 필요한 값을 보정하는 기능으로 추정
실제 사용해볼 기회는 없었음..

대상

원하는 서비스에 요청을 보내는 곳 (이 글에 작성된 예시는 API 대상 입니다.)

원하는 대상을 선택해서 요청을 전송합니다.

cf. 헤더 파라미터에 Key/Value 를 추가하면 Authorization 값 등 헤더 값을 처리 할 수 있습니다. (소스에서 받은 값도 활용이 가능합니다!)

대상 - 대상 입력 변환기

소스에서 받은 값을 대상에 요청을 보낼때 req.body로 전달함.

Copilot addons

HyeonJun — Mon, 13 Jun 2022 10:42:20 +0000

addons yml 설정하기

기본 템플릿은 아래와 같습니다.
경로는 copilot/{serviceName} 폴더 아래에 addons 폴더를 추가하고 {name}.yml 파일 추가하여서 작성하면됩니다.
최종 경로는 copilot/{serviceName}/addons/{name}.yml가 됩니다.

Parameters:
  App:
    Type: String
  Env:
    Type: String
  Name:
    Type: String

Resources:
  SQSAccessPolicy:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      PolicyDocument:
        Version: 2012-10-17
        Statement:
          - Sid:
            Effect:
            Action:
            Resource:
Outputs:
  SQSAccessPolicyArn:
    Description:
    Value: !Ref SQSAccessPolicy

Parameters는 AWS Copilot에서 항상 요구하는 필수 항목입니다. (참고. copilot-cli)
AWS Copilot always requires the App, Env, and Name parameters to be defined in your template.

Resources는 실제 사용할 AWS Resource PolicyDocument Statement에 사용할 Resource의 Sid, Effect, Action, Resource를 작성하면 됩니다.

Sid: SQS-A
Effect: Allow
Action:
  - sqs:SendMessage
Resource: arn:aws:sqs:ap-northeast-2:000000000000:sqs-a

예를 들어, sqs-a에 sqs message 전송 권한을 주고싶으면 위와 같이 Action에 권한 Resource에는 실제 arn값을 작성하면됩니다. Sid는 StatementId 입니다. (참고. IAM sid)

추가로 sqs-b에 전송 권한을 주고싶다면 아래와같이 작성하면 됩니다.

Sid: SQS-B
Effect: Allow
Action:
  - sqs:SendMessage
Resource: arn:aws:sqs:ap-northeast-2:000000000000:sqs-b

작성된 전체 yml은 아래와 같습니다. IAM 권한은 copilot이 deploy되면서 addons yml에 따라서 자동으로 IAM 권한을 만들어서 설정해줍니다.

Parameters:
  App:
    Type: String
  Env:
    Type: String
  Name:
    Type: String

Resources:
  SQSAccessPolicy:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      PolicyDocument:
        Version: 2012-10-17
        Statement:
          - Sid: SQS-A
            Effect: Allow
            Action:
              - sqs:SendMessage
            Resource: arn:aws:sqs:ap-northeast-2:000000000000:sqs-a
          - Sid: SQS-B
            Effect: Allow
            Action:
              - sqs:SendMessage
            Resource: arn:aws:sqs:ap-northeast-2:000000000000:sqs-b

Outputs:
  SQSAccessPolicyArn:
    Description: "Sqs 메시지 전송 권한"
    Value: !Ref SQSAccessPolicy

기대효과

IAM 권한이 템플릿화 되어서 이상적인 서버 구조가 될 수 있음!!

Copilot Code Pipeline Build Stage Trouble Shooting

HyeonJun — Tue, 24 May 2022 03:50:05 +0000

Pipeline Build Stage Failed (Using Copilot Platform linux/arm64)

해당 에러는 Copilot Platform이 linux/arm64이며, manifest.yml + buildspec.yml 파일을 수정하지 않았을 경우 발생합니다.

Copilot pipelien init를 하여 생성된 manifest.yml + buildspeec.yml 파일의 빌드 이미지는 arm64기반의 이미지가 아니라 일반 linux 기반의 이미지이기 때문에 설정을 통해 arm64 이미지로 맞춰주어야 합니다.

맞춰주지 않게 되면 아래와 같이 resources upload 에러가 발생합니다.

✘ upload resources required for deployment for copilot: build and push image: build Dockerfile at /codebuild/output/path/Dockerfile: building image: exit status 1
Cloudformation stack and config files were not generated. Please check build logs to see if there was a manifest validation error.

해결 방법은 위에서 말했던거처럼 manifest.yml과 buildspec.yml의 빌드 이미지를 arm64로 맞춰주면 됩니다.

먼저 manifest.yml 파일에 (source와 stages 사이에)

build:
  image: aws/codebuild/amazonlinux2-aarch64-standard:2.0

코드를 추가해 빌드 이미지를 설정해줍니다.

buildspec.yml 파일에 기존 아래와 같이 작성되어있는 부분을 변경해줍니다. 이렇게 작성 후 새로 빌드를 실행하게되면 빌드가 정상 작동하는것을 확인할 수 있습니다.

- wget -q https://ecs-cli-v2-release.s3.amazonaws.com/copilot-linux-v1.18.0
- mv ./copilot-linux-v1.18.0 ./copilot-linux

- wget -q https://ecs-cli-v2-release.s3.amazonaws.com/copilot-linux-arm64-v1.18.0
- mv ./copilot-linux-arm64-v1.18.0 ./copilot-linux

참고. github issue, github pr

번외

[Container] 2022/05/16 02:38:00 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: for env in $pl_envs; do
  tag=$(sed 's/:/-/g' <<<"${CODEBUILD_BUILD_ID##*:}-${env}" | rev | cut -c 1-128 | rev)
  for svc in $svcs; do
  ./copilot-linux svc package -n $svc -e $env --output-dir './infrastructure' --tag $tag --upload-assets;
  if [ $? -ne 0 ]; then
    echo "Cloudformation stack and config files were not generated. Please check build logs to see if there was a manifest validation error." 1>&2;
    exit 1;

로그를 보다보면 이런 에러가 붉은 글씨로 떠있어서 해당 에러 메세지를 보면서 어떤 에러인지 유추 하였는데 이부분을 볼 필요가 없었습니다... 살짝만 위로 올려보면 위에 작성한것 처럼 명확한 에러를 보여주는....T^T

What is Dockerizing

HyeonJun — Thu, 12 May 2022 07:58:57 +0000

Dockerizing(도커라이징)은 Docker 컨테이너를 사용하여 애플리케이션을 패키징, 배포 및 실행 하는 과정입니다.

여기서 Docker란 애플리케이션에 필요한 모든 기능을 하나의 패키지로 제공하는 오픈 소스 도구입니다.

도커 컨테이너에서 내가 만든 애플리케이션이 실행되도록 하려면 어떻게 해야 할까요? 바로 Docker Image를 만들면 됩니다!

Docker Image를 만들기 위해 우선 Dockerfile을 작성해야합니다.

$ touch Dockerfile

생성된 Dockerfile에 가장 먼저 어떤 Node 버전을 사용할지 작성하여야 합니다. 이 글에서는 16.15.0 버전을 사용할 예정입니다. (Docker Hub node image) (Docker Image Variants)

#FROM node:<version>
FROM node:16.15.0

이미지 안에 애플리케이션 코드를 넣기 위한 폴더 생성 및 Working Directory 설정

# dir 생성 및 working dir 설정
RUN mkdir -p /app
WORKDIR /app

생성한 app directory에 source code copy (!주의 Dockerfile의 path를 확인해주세요.)

COPY ./ /app

app directory에 dependecy install 및 source code build

RUN yarn install
RUN yarn run tsc

Docker demon에 바인딩할 포트 선택 및 서버 실행 CMD 입력 (!주의 CMD는 package.json에 실행 script에 따라 달라질 수 있습니다.)

# Docker demon에 바인딩할 포트 선택
EXPOSE 3000

# 서버 실행
CMD ["yarn", "start"]

node_modules, yarn-error.log 모듈 및 파일은 복사되지 않도록 .dockerignore 파일 생성(Dockerfile과 같은 경로에 생성!)

Docker Image 빌드

docker build -t <username>/<원하는 docker image명><:tag명> .

위 명령어를 사용해 빌드된 이미지들 리스트를 아래 명령어로 확인 가능!

docker image ls

Docker Image 실행하기

docker run -p 3000:3000 -d <username>/<docker image명>

위 명령어를 통해 build한 Docker Image를 실행할 수 있고 Docker Desktop을 통해 logging 및 관리를 할 수 있다! (CMD로도 가능하다.)

Docker Node Image Variants

HyeonJun — Thu, 12 May 2022 05:58:05 +0000

`node:<version>`

사실상 default 이미지.
요구 사항이 무엇인지 확실하지 않을 때(필요한 이미지가 불확실할때) 사용하는 것이 좋습니다. 이 이미지는 버리는 용도의 컨테이너(소스코드를 마운트하고 앱을 실행하기 위한 컨테이너)로 사용되기도 하고 다른 이미지 빌드용으로 사용될 수도 있습니다.

몇몇 태그들은 bullseye, buster 또는 stretch와 같은 이름을 포함하고 있는 태그들이 있는데 Debian 릴리즈 코드의 이름이고 이 이미지들은 해당 릴리즈 버전 기반의 이미지들 입니다.

이 태그는 buildpack-deps이미지 기반입니다. buildpack-deps는 시스템에 많은 도커 이미지를 가진 도커 사용자를 위해 설계되었습니다. 매우 많은 Debian 패키지들이 있으나, 패키지에서 파생된 이미지가 설치해야 하는 패키지 수가 줄어들어 시스템에 있는 모든 이미지의 전체 크기가 줄어듭니다.

`node:<version>-alpine`

Alpine Linux 프로젝트 기반. Alpine Linux는 대부분의 배포 기반 이미지 보다 작아서 작은 이미지를 만들 수 있음.

이 Variants는 최종 이미지 크기가 가능한 한 작은 것이 주요 목표일 때 유용함.

`node:<version>-slim`

기본 태그에 포함된 공통 패키지를 포함하지 않으며 node를 실행하기 위한 최소한의 패키지만 포함.

Node official Image - dockerhub