시골쥐의 공부생활

CI/CD 구축을 위한 단계

  0. ECS fargate 생성 (Cluster, Service, task-definition, task)

1-1. Bitbucket에 코드 업로드 (git)

1-2. Bitbucket <-> slack 연동 (PR 알람 노티를 위함)

2. Bitbucket <-> AWS API Gateway 연동 with Webhook

3. API gateway -> Lambda 호출 

4. Lambda -> S3로 패키지 업로드

5. AWS Codepipeline: S3 -> Codebuild + ECR 연동

6. Codebuild -> Deploy(ECS fargate)

7. ECS <-> LB(ALB) 연동하여 동작 테스트 

이번엔 CI/CD 구축을 위한 위 1-1, 1-2번 절차 포스팅이다.

일단 ci/cd 자체가, 코드를 올려서 그걸 연속적으로 배포해준다는 것인데, 그럼 코드를 올려야 한다.

나는 위 Diagram과 같이 bitbucket을 썼고, bitbucket에서 PR(Pull Request) Merge가 발생할 때마다 이를 slack으로 전송했다.

이번엔 대단한 작업이 딱히 없다 :) 

bitbucket에서 내가 사용할 repository를 생성하고, 그 repo의 설정으로 들어가준다. (Repository settings)

Merge시에만 알람이 가게끔 Merged를 체크해준다.

그리고 Additional configuration에서, 메세지를 노티 받을 Slack의 Channel name과 webhook Uri를 입력해준다.

Webhook Uri는, 내가 메세지를 노티받을 Slack의 channel에 들어가서,

오른쪽 상단의 설정을 누른 후, 통합 > 앱추가 > Incoming webhooks 를 설치하면 나온다.

앱 > 앱 추가

검색 창에 'incoming webhook' 검색, 하단에 '설치' 버튼을 눌러 webhooks을 설치한다.

채널에 포스트에서, 내가 웹훅을 받을 채널을 선택한다. (#clone-prison)

그럼 아래에 웹후크 url이 나오는데, 이 URL을 bitbucket의 Repository settings에 넣으면 된다.

이렇게 저장을 하면, PR Merge시마다 slack으로 노티를 받을 수 있다 :) 

CI/CD 구축을 위한 단계

  0. ECS fargate 생성 (Cluster, Service, task-definition, task)

1-1. Bitbucket에 코드 업로드 (git)

1-2. Bitbucket <-> slack 연동 (PR 알람 노티를 위함)

2. Bitbucket <-> AWS API Gateway 연동 with Webhook

3. API gateway -> Lambda 호출 

4. Lambda -> S3로 패키지 업로드

5. AWS Codepipeline: S3 -> Codebuild + ECR 연동

6. Codebuild -> Deploy(ECS fargate)

7. ECS <-> LB(ALB) 연동하여 동작 테스트 

CI/CD 구축을 위한 첫 번째 절차는, 일단 코드를 배포하기 위한 타겟, 즉 컨테이너를 생성하는 것이다.

이 컨테이너를 관리해주는 게 ECS(Elastic Container Service)인데, ECS 앱을 통해 컨테이너를 생성한다.

컨테이너를 생성하기 위해서는, 

1) 클러스터 생성

2) 작업 정의(Task-definition) 생성

3) 서비스(Service) 생성이 필요하다.

1) 클러스터 생성

EC2가 아닌 Fargate를 생성할 예정이므로, 네트워킹 전용을 고른다.

나중에 태그 값으로 생성 리소스들을 확인해보기 위해 태그도 붙인다.

벌써 클러스터 생성이 완료되었다. 클러스터 생성은 큰 어려움이 없다.

2) 작업 정의(Task-definition) 생성

이제는 이 클러스터 내 컨테이너가 어떤 이미지를 쓰고, 자원들은 얼마나 쓸 것인지 정의하는

작업 정의(Task-Definition)을 생성해야 한다. 왼쪽 메뉴에서 '작업 정의'를 클릭한다. 

역시 Fargate를 생성할 예정이므로 Fargate를 선택한다.

이름, IAM, 컨테이너 정의를 수행한다.

(이미지를 불러오려면 미리 ECR에 이미지를 push 해놨어야 한다.)

앞으로 이 작업 정의를 사용하는 컨테이너는 위 이미지의 태그값을 사용한다. (그러니 신중하게 하자... 변경하려면 다시 생성해야 한다)

그리고 작업정의를 이어서 진행한다.

가벼운 코드이므로 작업 크기는 작게 잡았다.

작업 정의도 완료되었다.

3) 서비스(Service) 생성

다음은 서비스 생성이다.

서비스란 클러스터의 앞단에서 이 클러스터 내 컨테이너를 몇 개 띄울 것인지, scaling은 어떻게 할 것인지(optional),

로드밸런싱 등의 설정을 하는 곳이다.

역시 FARGATE로 시작할 예정이므로 FARGATE로 설정하고, 작업 정의는 2)에서 정의했던 정의를 들고온다.

클러스터는 1)에서 정의한 클러스터를 들고온다.

그리고 패키지가 업데이트될 때마다 롤링업데이트를 진행할 예정으로, 롤링 업데이트를 설정하고

(롤링 업데이트: 패키지 배포시마다 컨테이너 전체에 업데이트를 한 번에 진행하는 게 아니라, 컨테이너를 하나씩 업데이트해서 서비스 중단이 없게끔 하는 업데이트 방식)

로드 밸런싱을 설정한다.

로드 밸런서는 당장은 설정하지 않아도 문제없으나, 결국엔 패키지가 제대로 배포되었는지 확인을 위해(curl을 통해 확인)

LB까지 설정을 진행한다.  

여기서 로드 밸런싱할 컨테이너는 2)에서 만든 작업정의의 컨테이너이므로 Jane-test:3002가 맵핑되어 있다.

이제 로드밸런서에 80포트를 통해 3002번 포트에게 req가 오면, 그걸 Jane-target-grp3이라는 대상으로 보낸다.

사실 :3002를 direct로 사용한다기 보다는, 보통 path를 통해 curl 확인을 하므로 코드에서 설정한 http 경로를 입력한다.

예를들어, 나는 코드에서 아래와 같이 /jane_으로 get을 했을 경우 이렇게 프린트 하라고 정의했기 때문에, 경로를 /jane_으로 입력해준다.

(평가순서는, :80을 사용하는 다른 서비스도 많기 때문에 /path로 분기를 하는데, 어떤 path를 먼저 볼 것인지 하는 우선순위이다.)

이렇게 다 설정을 하면, 서비스도 생성이 완료되었다.

그리고 서비스에 따라 작업(컨테이너)이 생성되었다.

끝!

하루를 삽질했다.... T-T

AWS ALB를 통해 통신을 하려면, 아래와 같이 여러 절차가 필요하다.

1. 코드 내에 health check를 위한 코드가 필요 하고,

2. 각 포트들이 맞아야 한다.

2-1. 코드 내 오픈된 port(위 3001)

2-2. 컨테이너를 생성할 때 설정한 서비스 내 컨테이너 포트(아래 3001),

2-3. LB의 대상그룹(target group) 포트(3001)

2-4. ECS의 서비스 > 보안그룹 내 포트 (3001)

3. ECS task를 수행하는 Role에 LB를 위한 권한 설정 추가

(ElasticLoadBalancingFullAccess)

4. LB의 리스너도 경로가 타겟그룹에 맞게 설정되어 있는지 확인.

이렇게 하면... healthy가 뜬다.... 흑흑

그럼 LB를 통해 통신이 되는지 확인해보자.

bastion에 들어가서 LB의 dns + path로 curl을 날려본다.

[ec2-user@bastion~]$ curl internal-alb-testestsetste.ap-northeast-2.elb.amazonaws.com/jane/health

OK

[ec2-user@bastion~]$ curl internal-alb-testestestset.ap-northeast-2.elb.amazonaws.com/jane

Database printed

[{"id":1,"data":"text1"},{"id":2,"data":"text2"}]

확인 완료!

Amazon ECS(Elastic Container Service)

클러스터에서 컨테이너를 쉽게 실행, 중지 및 관리할 수 있게 해주는 컨테이너 관리 서비스.

간단한 API 호출을 통해 컨테이너 기반 앱을 시작, 중지할 수 있음.

ECS 구성 요소

1. ECR(Elastic Container Repository)

아마존에서 제공하는 컨테이너 이미지 저장소.

ECR에서 이미지 URI를 이용해 빌드한 이미지를 푸쉬하고 가져올 수 있음.

2. 작업 정의(=Task Definition)

 애플리케이션을 구성하는 컨테이너를 설명하는 텍스트(JSON), 태스크를 실행하기 위한 정의.

(태스크는 클러스터에 종속적이지만 Task Definition은 클러스터에 종속적이지 않음)

  - 시작 유형 (Fargate, EC2, External)

  - 사용할 컨테이너 이미지

  - 개방할 포트, CPU/MEM 리소스, 데이터 볼륨 설정 등

3. 작업(Task)

작업 정의에서 정의된 설정으로 인스턴스화 하는 것. 컨테이너를 실행하는 최소 단위로 하나 이상의 컨테이너로 구성됨.

Task는 Cluster에 속한 컨테이너 인스턴스(EC2 Instance)나 Fargate에 배포하게 됨.

4. 서비스(Service)

클러스터에서 지정된 수의 작업을 동시에 실행하고 관리할 수 있게 해주는 구성.

서비스는 Task를 포함하며, Task와 관련된 Auto Scaling, LB(Load Balancing)을 관리.

 - 클러스터, 작업정의, 시작유형, 작업 개수, LB, Auto Scaling, 네트워크 구성, 배포 유형(롤링, 블루/그린 등) 설정

5. 클러스터(Cluster)

작업 또는 서비스의 논리적 그룹. 클러스터를 실행하여 작업을 실행할 수 있음.

 - 클러스터 템플릿 선택(Fargate, EC2, External)

* 시작 유형

Fargate : 컨테이너를 배포하고 관리할 수 있는 서버리스 컴퓨팅 엔진
EC2 : 컨테이너를 배포하고 관리할 수 있는 클라우드 컴퓨팅 플랫폼
External : 컨테이너를 배포하고 관리할 수 있는 온프레미스 서버 또는 가상 머신

* 클러스터에는 두 가지 방식으로 태스크를 실행할 수 있음.

1. 작업 정의(=Task Definition)로 직접 태스크를 실행하는 방식

곧바로 실행되며 실행이 된 후로 더 이상 관리되지 않음. 일회성 명령어라면 한 번 실행된 후 종료되며, 데몬이라면 태스크를 명시적으로 종료할 때까지 컨테이너가 남아 있음. 직접 태스크를 실행하는 방법은 특별한 이유가 있을 때 외에는 거의 사용되지 않음.

2. 서비스(=Service): 하나의 Task Definition(Revision)과 연결됨

- 데몬타입: 모든 컨테이너 인스턴스에 해당하는 태스크가 하나씩 실행됨. 이것은 인스턴스 관리를 위한 용도로 사용됨.

- 리플리카 타입: 실행하려는 태스크의 개수를 지정하여, 이 개수만큼 실행되도록 자동 관리해줌. 이 리플리카 타입이 웹서버를 비롯한 실제 서비스에서 주로 사용됨.

프로세스를 배치하는 경우, 운영자가 직접 어떤 인스턴스에 어떤 프로세스를 언제 배치할지 결정해야 하는데, ECS에서는 서비스가 이 스케쥴링 역할을 담당함. (= 서비스는 각 인스턴스들에 설치된 ecs-client에서 수집된 정보를 기반으로 어디에 어떤 태스크를 언제 실행할지 결정. 즉, 다수의 컨테이너 인스턴스가 있을 시 언제 어디서 태스크가 실행될지 알 수 없음. 서비스가 직접 태스크 배치 스케쥴링을 수행) 

출처

https://tech.cloud.nongshim.co.kr/2021/08/30/%EC%86%8C%EA%B0%9C-amazon-ecs%EB%9E%80/

https://www.44bits.io/ko/post/container-orchestration-101-with-docker-and-aws-elastic-container-service

현상

Codebuild에서 빌드 후 ECR에 image를 push하는 절차 중, 아래와 같이 ECR 관련한 명령이 실패되었다.

해결 방법

이런 것은 권한 문제일 가능성이 크다.

Codebuild에 설정한 역할(Role)에 AmazonEC2ContainerRegistryFullAccess를 추가해준다.

그리고, buildspec.yml에 ecr로 로그인을 위한 아래 커멘드가 존재해야 한다.

$(aws ecr get-login --no-include-email --region ap-northeast-2)

이렇게 하면, 빌드 성공!

현상

AWS codebuild를 통해 빌드를 하고 있는데, buildspec.yml을 읽는 과정에서 아래와 같은 에러가 발생했다.

[Container] 2022/05/31 20:23:56 Running command docker build -t $IMAGE_NAME .
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

[Container] 2022/05/31 20:23:58 Command did not exit successfully docker build -t $IMAGE_NAME . exit status 1
[Container] 2022/05/31 20:23:58 Phase complete: INSTALL State: FAILED
[Container] 2022/05/31 20:23:58 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: docker build -t $IMAGE_NAME .. Reason: exit status 1

해결

다행히 말 그대로 도커 데몬에 연결할 수 없다는 것인데, aws의 troubleshooting 사이트에 올라와 있는 에러였다.

똑같이 따라가본다.

Codebuild > 프로젝트 > 내 프로젝트 > 환경 편집 > 이미지 재정의

난 가장 하단에 '권한이 있음'을 체크하지 않았었다.

이부분을 체크해준다.

그리고 다시 빌드를 했더니, 돌아간다 :)

끝 

(또 다른 이슈 발생,,,)

현상

ci/cd구축을 위해 code pipeline을 생성한 후, source에서 아래와 같은 에러가 발생함.

(제 pipeline은 S3를 통해 pkg를 가져오는 구조입니다.)

권한 부족

The provided role does not have permissions to prform this action.

IAM에서 여러 권한을 줘봤으나 현상은 모두 동일했고, 구글링을 반나절 해본 결과...

S3 bucket > 버킷정책을 확인해보라는 말을 보았다.

그래서 S3 bucket으로 가서, 버킷 정책을 확인했다.

codepipeline에 대한 권한이 없어 codepipeline을 *로 주었고, 생성한 codepipeline의 arn 추가했더니 

아래와 같이 2가지 에러가 발생했다.

Ln 16, Col 4에 언급된 링크를 들어가보면,

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/access-analyzer-reference-policy-checks.html#access-analyzer-reference-policy-checks-error-unsupported-resource-arn-in-policy

Resolving the error (이슈 해결)

일부 리소스 ARN들은 정책이 다른 리소스 타입에 연결된 경우, 리소스 요소를 지원하지 않는다,

예를 들어 AWS KMS ARN은 S3 버킷 정책에서 지원되지 않는다. --> codepipeline 만들 때 KMS를 썼었다. 이걸 제거하자.

결론

그래서 결국엔, codepipeline을 생성할 때, KMS를 사용하지 않고 기본 AWS 관리형 키를 선택한 결과 소스 가져오기가 성공하였다.

휴 일단 소스 가져오기까진 성공!

IAM 이란?

AWS 자격 및 접근 관리(AWS Identity and Access Management, IAM)는 당신의 사용자들이 AWS 리소스에 대하여 가지는 접근 권한을 안전하게 제어할 수 있도록 도와주는 웹 서비스입니다. IAM을 사용하여 누가 AWS 리소스를 이용할 수 있는지(인증:Authentication), 그리고 사용자가 접근 가능한 리소스를 어떤 방식으로 이용할 수 있는지(권한 부여:Authorization)를 제어합니다.

* IAM 사용자 (User)

ROOT: aws 계정을 만들 때 사용한 전자메일 주소와 암호. aws 계정의 모든 리소스에 대한 무제한 접근 권한을 갖고 있음.

루트 사용자가 아닌 특정한 역할(role)을 가진 또는 그룹으로 묶어서 사용자를 지정하기 위한 용도

* IAM 역할(Role)

권한 정책이 부여된 자격(identity), 어떤 자격을 가졌을 때 aws 상에서 수행할 수 있는 작업의 범위.

ex. db를 쿼리한 다음 전자메일로 보내는 람다함수가 있는데, 실수로 db를 변경하지 않도록 읽기 쿼리만 실행할 수 있게 설정.

사용자와 차이점은, 역할은 자격증명(암호 또는 접근 키)를 갖지않음.

* IAM 정책(Policy)

'AWS 리소스'에서 수행할 수 있는 작업을 정의하는 규칙, 규칙들의 집합.

// 모든 S3에 모든 자격 부여

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
  }
}

// Hello-bucket이라는 버킷에서 오직 문자열 Bobs-로 시작하는 파일의 반환만 허용

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::Hello-bucket/*",
    "Condition": {"StringEquals": {"s3:prefix": "Bobs-"}}
}

출처:https://serverless-stack.com/chapters/ko/what-is-iam.html

https://dev.classmethod.jp/articles/what-is-aws-iam-kr/

https://blog.voidmainvoid.net/405

Gitlab에서 PR(Pull Request)이 있을 때마다 AWS의 API Gateway를 호출해서, Lambda까지 연동해본다.

(후속절차가 훨씬 많지만 이번 포스팅의 범위는 여기까지!)

0. 아키텍쳐

Gitlab (에서 이벤트 발생 시) -> API Gateway (호출) -> Lambda (호출) 

1. Lambda 생성

항상 이런 작업을 할 땐 가장 마지막 순서부터 하나씩 만들어놔야 하므로 Lambda를 먼저 생성한다.

event로 뭘 받아올지 궁금하니 event 부터 찍는 간단한 람다를 만들었다. (nodejs)

2. API Gateway에서 HTTP API 또는 REST API 생성

- 본인에 맞는 API를 생성한 후 필요한 리소스, 메소드를 설정, 이후 배포

   (나는 해당 api 호출 시 lambda를 trigger할 예정으로 Lambda함수를 선택해주었다.)

  * Lambda 프록시 통합 사용은, event를 받아올 때 요청 및 세부 정보들을 모두 lambda로 프록시한다고 한다. (옆에 i 누르면 설명 나옴)

- 스테이지 메뉴에 가면, URL이 나온다. 이 URL을 Gitlab의 Webhook 부분에 넣어주면 된다. -> 3번

메서드 요청, 메서드 응답은 API 프론트앤드(클라이언트) <-> API gateway간의 인터페이스이며 

통합 요청, 통합 응답은 API와 백엔드(본인의 경우 Lambda)간 인터페이스임.

클라이언트는 API를 사용해서 메서드 요청을 통해 백엔드 기능에 액세스 함. 

POST / 는 메서드 요청의 payload가 통합 요청의 페이로드와 같은 형식인 경우, 요청 payload를 수정 없이 통합 요청에 전달 가능.

GET / 은 통합 유형을 사용하며 실제 백엔드에 연동되지 않고 통합 요청을 설정하여 정적인 html을 반환함.

3. GitLab 설정

- Gitlab에서 본인이 사용하는 Repository settings에 접속하여 Webhooks 메뉴로 간다.

- 여기 URL에, 1에서 생성한 API의 URL을 복붙해준다. 

- 그리고 마지막, Active 설정.

Test connection을 눌러 ping을 날려보자.

굳

4. API 동작 확인 (Gitlab에서 Comment edited)

 - API가 잘 동작하는지 확인하기 위해, Gitlab의 Pull Request에서 (본인은 이미 있었음) Comment를 수정해본다.

     (위에서 Comment edited 조건 만들기)

 - Comment edited로 인해 API gateway가 호출되고, lambda까지 동작이 되었는지 로그를 확인한다.

   . 람다 >  모니터링 > Cloudwatch에서 로그보기

- 실행 되었다. 이제 event에 어떤 값들이 오는지 알았다.

+ JSON.stringify(event): event를 json format으로 예쁘게 다시 찍어보자

  // JSON.stringify: JavaScript 값이나 객체를 JSON 문자열로 변환

이제 이걸 사용해서 다른 동작들을 만들어보자.  to be continued...

EC2에서 s3에 업로드된 파일을 가져오고 싶을 때, 이렇게 하면 된다.

1. ec2에서 s3에 있는 파일 조회

$ aws s3 ls s3://[파일조회를 원하는 bucket명]

[ec2-user@ip-1-2-3-4 ~]$ aws s3 ls s3://test-bucket

2022-05-25 06:53:01   34174456 test.tar.gz

2. ec2에서 s3에 있는 파일 다운로드

$ aws s3 cp s3://[파일조회 원하는 bucket명]/[파일명] [복사를 원하는 디렉토리]

[ec2-user@ip-1-2-3-4 ~]$ aws s3 cp s3://test-bkt/test.tar.gz ./

download: s3://test-bkt/test.tar.gz to ./test.tar.gz

[ec2-user@ip-1-2-3-4~]$ ls

test.tar.gz

3. s3에서 ec2로 옮기고 싶은 경우는, 2와 반대로 하면된다.

$aws s3 cp [현재 복사 원하는 파일] s3://[업로드 원하는 bucket명]

[root@ip-1-2-3-4 ec2-user]# aws s3 cp test.sh s3://test-bkt

upload: ./test.sh to s3://test-bkt/test.sh       

4. move

는 cp부분만 바꿔서 하면 된다.