Cloud - AWS(3) - EC2 인스턴스에 태그와 역할 부여/파이프라인 구축

2022. 9. 27. 11:52

1. 파이프라인 구축(환경 설정)

1) EC2 인스턴스에 태그 생성

EC2 대시보드로 이동한다
인스턴스로 이동한다

파이프라인 구축 단계에서 인스턴스를 잘 식별하기 위하여 태그를 추가한다
- 인스턴스를 선택한다
- 작업 → 인스턴스 설정 → 태그 관리 순서로 클릭해 이동한다

새로운 태그 추가를 클릭한다
태그의 키 와 값은 자유롭게 작성한다
저장 버튼을 눌러 태그를 생성한다
- 현재는 권한이 없어서 생성이 안되지만 나중에 개인 코드로 해 본다

2) IAM 서비스를 이용해서 EC2 인스턴스에 역할 부여

역할(Role)은 AWS의 개체(서비스, 사용자 등)가 다른 서비스에 접근하게 할 수 있도록 해 준다
- EC2 인스턴스에 역할을 부여하면 다른 AWS 서비스를 호출할 수 있는 권한을 가진다

인스턴스를 선택한다
작업 → 보안 → IAM 역할 수정 순서대로 클릭해 이동한다

IAM 역할을 생성해둔 것이 없으면 새로 생성한다
- '새 IAM 역할 생성'을 클릭해 AWS IAM 서비스로 이동한다

새 창에서 Identity and Access Management(IAM) 화면이 출력된다
'역할 만들기' 를 클릭합니다.

AWS 서비스, EC2를 선택 후 '다음' 버튼을 클릭한다
'다음'을 클릭한다

검색창에 권한을 검색 후 선택한다
- S3를 입력하여 AmazonS3FullAccess를 선택한다
- EC2Role을 입력하여 AmazonEC2RoleforAWSCodeDeploy를 선택한다
- SSM을 입력하여 AmazonSSMFullAccess를 선택한다
'다음'을 클릭한다

역할에 이름을 입력한다

태그 추가를 클릭한다
키에 "Name"을, 값(선택 사항)에 "EC2forCodeDeploy"를 입력한다
'다음: 검토'를 클릭한다

'역할 만들기'를 클릭한다
역할이 생성된다

IAM 메인 화면으로 이동한다
역활 -> EC2를 검색한다
EC2forCodeDeploy 자체를 선택한다

신뢰 관계를 편집한다
- 해당 역할을 취할 수 있는 서비스나 사용자를 명시한다
- 역활에서 생성한 access 할 수 있는 서비스를 신뢰 관계에서 명시함으로써 역할이 명확하게 완성된는 것이다

처음 편집 화면으로 들어가면 "Service"의 값으로 "ec2.amazonaws.com"만 할당되어 있다
- 화면과 같이 대괄호를 작성하고 내부에 "codedeploy.ap-northeast-2.amazonaws.com" 값을 추가한다

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "ec2.amazonaws.com",
                    "codedeploy.ap-northeast-2.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

EC2 인스턴스 화면으로 돌아와서 IAM에 생성한 역할을 저장한다
- 이제 EC2는 S3, CodeDeploy에 접근할 수 있다

EC2 인스턴스가 적절한 보안 그룹을 갖고 있는지 확인한다
EC2 대시 보드에서 인스턴스로 이동한다
보안 탭을 클릭한다
보안 그룹을 클릭해 이동한다

보안그룹의 인바운드 규칙에 8080과 443 포트가 포함되어 있는지 확인한다
- 포함되어있지 않다면, [ 인바운드 규칙 편집 ] 버튼을 클릭해 수정 화면으로 이동하여 추가한다
- 8080번 포트는 서버 배포를 위해 필요한다
- 443 포트는 CodeDeploy-Agent의 정상적인 작동을 위해 필요하다

사용자 지정 TCP에
- 포트범위를 8080으로
- 소스를 위치 무관으로 추가한다
HTTPS 유형에서
- 소스를 위치 무관으로 추가한다
'규칙 저장' 을 클릭한다

저장 후 22, 8080, 443 포트가 포함되어 있는지 확인한다
EC2 인스턴스의 세팅이 완료되었다

2. 부여받은 IAM User 권한과 리소스를 활용하여 파이프라인 구축

1) 배포 자동화를 위한 EC2 인스턴스의 역할(IAM Role) 확인

EC2 인스턴스에는 태그와 IAM Role이 설정되어 있다

역할이 가지고 있는 권한은 아래와 같다
- EC2 인스턴스의 Name은 해당 인스턴스에 Name을 키로 갖는 태그 값과 동일하다
- 별도의 태그를 추가하지 않고, 이후에도 이 인스턴스의 Name 태그 값을 이용해 검색한다

EC2 인스턴스에 연결되어있는 IAM 역할은 아래 이미지와 같은 권한을 가지고 있다
- 추가되어있는 권한과 신뢰관계가 'EC2 인스턴스에 태그와 역할 부여'에서 진행한 내용과 동일한지 확인한다

발급받은 EC2 인스턴스를 통해 연결되어있는 보안 그룹을 클릭해 이동한다

모든 인스턴스에 동일한 보안그룹이 적용되어 있다
- 보안그룹 인바운드 규칙이 'EC2 인스턴스에 태그와 역할 부여'에서 진행한 내용과 동일한지 확인한다

3. EC2를 활용한 파이프라인 구축

1) Local 환경 설정

구축에 활용할 로컬 환경의 'be-sprint-deployment/DeployServer' 경로에 appspec.yml 파일을 추가한다
- appspec.yml은 배포 자동화를 도와주는 CodeDeploy-Agent가 인식하는 파일이다

version: 0.0
os: linux

files:
  - source: /
    destination: /home/ubuntu/build

hooks:
  BeforeInstall:
    - location: server_clear.sh
      timeout: 3000
      runas: root
  AfterInstall:
    - location: initialize.sh
      timeout: 3000
      runas: root
  ApplicationStart:
    - location: server_start.sh
      timeout: 3000
      runas: root
  ApplicationStop:
    - location: server_stop.sh
      timeout: 3000
      runas: root

로컬 환경의 'be-sprint-deployment/DeployServer' 경로에 buildspec.yml 파일을 추가한다
- buildspec.yml은 배포 자동화에서 빌드를 담당하는 CodeBuild-Agent가 인식하는 파일이다

version: 0.2

phases:
  install:
    runtime-versions:
      java: corretto11
  build:
    commands:
      - echo Build Starting on `date`
      - cd DeployServer
      - chmod +x ./gradlew
      - ./gradlew build
  post_build:
    commands:
      - echo $(basename ./DeployServer/build/libs/*.jar)
artifacts:
  files:
    - DeployServer/build/libs/*.jar
    - DeployServer/scripts/**
    - DeployServer/appspec.yml
  discard-paths: yes

be-sprint-deployment > DeployServer 아래에 scripts 디렉토리를 생성한다
- 4개의 파일을 scripts 아래에 생성한다
: 각 파일은 appspec.yml 파일이 구성하고 있는 배포 수명 주기에 따라서 실행될 예정이다

- initialize.sh 파일을 생성한다

#!/usr/bin/env bash
chmod +x /home/ubuntu/build/**

- server_clear.sh 파일을 생성한다

#!/usr/bin/env bash
rm -rf /home/ubuntu/build

- server_start.sh 파일을 생성한다

#!/usr/bin/env bash
cd /home/ubuntu/build
sudo nohup java -jar DeployServer-0.0.1-SNAPSHOT.jar > /dev/null 2> /dev/null < /dev/null &

- server_stop.sh 파일을 생성한다

#!/usr/bin/env bash
sudo pkill -f 'java -jar'

2) AWS CodeDeploy 설정

AWS CodeDeploy 대시보드로 이동한다
- 애플리케이션으로 이동한다

애플리케이션 생성 버튼을 클릭한다

애플리케이션의 이름을 규칙에 맞게 입력한다
컴퓨팅 플랫폼을 'EC2/온프레미스'로 선택한다
애플리케이션 생성 버튼을 클릭한다

애플리케이션이 생성된다
- 애플리케이션은 배포그룹을 생성해야 한다
- 애플리케이션의 배포 그룹 > 배포 그룹 생성 버튼을 클릭한다

배포 그룹의 이름을 규칙에 맞게 입력한다
서비스 역할을 클릭하여 EC2 인스턴스에 연결되어있는 'BE_EC2RoleForSSM'을 선택한다

환경 구성은 'Amazon EC2 인스턴스'를 선택한다
태그 그룹에는 EC2 인스턴스의 이름인 Name 태그 키와 값을 선택한다

로드 밸런서에서 '로드 밸런싱 활성화' 체크를 해제한다
배포 그룹 생성 버튼을 클릭한다
AWS CodeDeploy 세팅이 완료되었다

3) AWS CodePipeline을 이용한 서버 배포 자동화 파이프라인 구축

CodePipeline 대시보드로 이동한다
파이프라인 생성 버튼을 클릭한다

파이프라인 이름을 규칙에 맞게 입력한다
다음 버튼을 클릭한다

소스 스테이지를 추가한다
- 소스 코드로 사용할 'be-sprint-pratice-deploy' 레포지토리가 GitHub에 저장되어 있다
- 소스 스테이지에서 GitHub를 사용할 수 있으므로, GitHub(버전 2)를 소스 공급자로 선택한다
추가 옵션이 나온다
GitHub에 연결 버튼을 클릭한다

별도의 팝업창이 나타난다
연결 이름을 임의로 입력한다
GitHub에 연결 버튼을 클릭한다

'Amazon Web Services 의 GitHub용 AWS 커넥터는 다음 권한을 요청합니다.'의 팝업창이 나타난다
- 상황에 맞게 선택한다

승인을 하면 GiHub 연결 창이 나타난다
새 앱 설치 버튼을 클릭한다

자신의 GitHub 계정을 클릭한다

자신의 계정으로 로그인 된 GitHub 창이 나타난다
GitHub 화면에서 'Only select repositories(저장소만 선택)'를 선택한다
소스 코드로 이용할 'be-sprint-deployment' 리포지토리를 선택하고 Save(설치) 버튼을 클릭합니다.

자신 계정의 암호를 입력한다

링크가 생성되었다
연결 버튼을 클릭한다

리포지토리 이름을 조금 전 연결한 'be-sprint-deployment'로 지정한다
브랜치 이름은 main로 지정한다
출력 아티팩트 형식은 'CodePipeline 기본값'으로 지정한다
다음 버튼을 클릭한다

빌드 스테이지 추가 창으로 이동된다
빌드 공급자에서 AWS CodeBuild를 클릭한다
- 추가 옵션이 아래에 나타난다
프로젝트 생성 버튼을 클릭한다

빌드 프로젝트 생성 창이 생긴다
프로젝트 이름을 규칙에 맞게 입력한다
운영체제는 Amazon Linux 2를 선택한다
런타임은 Standart를 선택한다
이미지는 aws/codebuild/amazonlinux2-x86_64-standart:3.0을 선택한다

Buildspec 이름에 "DeployServer/buildspec.yml"을 작성한다
CodePipeline으로 계속 버튼을 클릭한다

'CodeBuild에서 be-pair-18을(를) 생성했습니다.'는 문구가 표시된다
다음 버튼을 클릭한다

배포 스테이지 화면으로 이동한다
배포 공급자는 'AWS CodeDeploy'를 선택한다
리전은 '아시아 태평양(서울)'을 선택한다
애플리케이션 이름은 생성해 둔 애플리케이션의 이름을 선택한다
배포 그룹은 생성해 둔 배포 그룹으로 선택한다

모든 단계의 설정을 잘 확인한다
오른쪽 하단의 파이프라인 생성 버튼을 클릭한다

파이프라인이 생성되었다
파이프라인 생성과 동시에 소스 코드의 배포가 자동으로 실행된다

구축한 파이프라인 중 deploy 스테이지에서 실패가 발생하는 경우에는 관련 로그를 확인한다
CodeDeploy-Agent는 파이프라인 실행 때마다 로그를 해당 EC2 instance에 저장한다
터미널에 'cd /opt/codedeploy-agent/deployment-root/deployment-logs' 명령어를 입력한다
- 로그 파일이 저장된 경로로 이동한다
ls 명령어를 입력하여 어떤 파일이 존재하고 있는지 확인한다
codedeploy-agent-deployments.log 라는 파일이 존재하는 것을 확인할 수 있다
nano를 이용해 해당 파일을 열어본다
lifecycle을 돌면서 sh 파일을 실행시킨 로그를 확인할 수 있다
- stderr는 standard error 이며
- stdout은 standard output 이다

프로세스가 실행중인지 확인하려면, sudo lsof -i :(실행한 포트번호) 명령어로 확인이 가능하다

※ 참조 링크

- linux의 standard stream : https://www.putorius.net/linux-io-file-descriptors-and-redirection.html

Linux Fundamentals - I/O, Standard Streams, and Redirection.

An introduction to Linux IO, standard streams, file descriptors, and redirection. Learn the basic operators and how to control stdin, stdout, and stderr.

www.putorius.net

- Bash의 표준 스트림 : https://www.delftstack.com/howto/linux/standard-streams-in-bash/

Standard Streams in Bash

This tutorial explains the standard streams and redirecting output and input to and from a file, respectively.

www.delftstack.com

프로세스가 실행중인지 확인하려면, sudo lsof -i :(실행한 포트번호) 명령어로 확인이 가능합니다.

저작자표시 비영리 변경금지 (새창열림)

'클라우드' 카테고리의 다른 글

Cloud - AWS(4) - RDS (0)	2022.09.27
Cloud - AWS(2) - EC2 인스턴스 생성 (0)	2022.09.27
Cloud - AWS(1) - 계정 생성 (0)	2022.09.27
Cloud - 배포자동화(Automated Deployment) (0)	2022.08.07
Cloud - 배포 컨테이너 - Docker Image (0)	2022.08.07

상상코딩