Infra

첫 번째 도전 - 기본적인 CI/CD 구축 및 1개의 EC2

초기에는 컨테이너에 대한 개념도 부족했고, AWS를 활용하여 flask 서버를 돌려본 게 전부였으며, CI/CD 구축 자체에 대한 경험이 없어서 CI/CD 구축 이후 AWS에 안정적으로 배포하는 것이 목표가 되었다.

vpc, 서브넷 설정 - default vpc 따라감
github actions로 front build
github actions로 back build
초기 public subnet의 RDS private subnet으로 이동 필요
ELK 스택용 인스턴스 생성

웹 서버

HTTP 요청을 읽어서 응답을 해주는 프로그램
상용으로 많이 쓰이는 웹 서버 프로그램은 크게 apache와 nginx 있음.

Apache vs nginx

1. Apache

기본적으로 2가지 방식이 있음.
- Prefork MPM(Multi Processing Module)
  - HTTP 요청이 올 때마다 프로세스 복제해서 각각 별도 프로세스에서 해당 HTTP 요청 처리
- Worker MPM
  - 하나의 HTTP 연결 후, 여러 요청을 처리하기 위해 복제된 프로세스 내에서 여러 쓰레드를 생성해서 여러 HTTP 요청
아무래도 이런 방식은 프로세스를 생성하든 쓰레드를 생성하든 요청에 따라 뭔가를 생성해야한다. 더 좋은 방법이 없을까?

2. Nginx

Event Driven 방식으로 구동
- 하나의 프로세스로 동작하며, HTTP 요청을 event로 비동기식으로 처리함.
  - 대부분의 HTTP 응답은 결국 html 파일을 제공하는 것이므로, IO 작업. IO 작업으로 event를 포워딩하고, 요청 순이 아닌, 요청이 끝난 순으로 처리함.
- HTTP 요청마다 프로세스든 쓰레드등 생성이 필요없으므로, 시스템 자원 관리에 장점이 있음.

결론

Apache와 nginx 중 HTML 파일 사이즈, 어떤 추가 기능을 쓰느냐 등 다양한 조건 때문에 무엇이 더 무조건 성능이 좋다고는 이야기 할 수 없음. 하지만 많은 접속자가 있을 경우, 시스템 자원 관리 효율성 때문에 Nginx가 일반적으로는 성능이 더 좋을 수 있으므로 해당 프로젝트에서는 Nginx를 사용함.

배포 전략

두 번째 도전 - EC2와 ECS 구축

참고

재준님이 알려주신 - 좋은 공식문서

어느 정도 aws 기반 아키텍처 구축에 대한 기본기가 다지고, 컨테이너 개념을 학습한 이후, 해당 기본기를 활용하여 새로운 아키텍처 구축에 도전하였다.

순서

도커

도커란?

다양한 운영체제와 시스템 환경에서 서버 셋업을 위한 작업이 모두 다르고 복잡.

도커는 컨테이너 기반의 가상화 플랫폼이라서, 컨테이너 상에 서버를 셋업 해놓을 수 있음.

그래서 컨테이너를 실행만 하면, 서버 이전이나 서버 패키지 버전 등등으로 일일이 서버 설정할 필요없이, 동일한 서버 셋업 가능.

마이크로 서비스와 DevOps, 도커

각 마이크로 서비스를 도커로 개발
초대용량 서비스 유지보수를 위한 서버 핸들링 (ex. 네트워크 트래픽 관리) => 쿠버네티스

docker image

docker 컨테이너를 생성하기 위한 명령들을 가진 템플릿

docker container

docker 컨테이너가 리눅스 컨테이너 형태로 실행한 상태 (instance)

EC2 도커 실행 환경 구축

sudo yum update -y

sudo yum install docker -y

sudo service docker start

sudo usermod -aG docker ec2-user

aws-cli 설치

처음에는 공식 문서만을 참고했는데, 이 방식으로 하면 계속 --update를 붙여도 1버전대에서 멈춰있었다. 검색을 통해 기존 aws-cli를 삭제하고 설치한 이후, 인스턴스를 나갔다가 다시 들어와보니 설치가 완료되었다.

참고

aws-cli 설치 공식문서

# AWS CLI v1 에서 v2로 업그레이드 해봅시다

# aws 의 위치를 확인합니다.
$ which aws 
/usr/bin/aws

# `ls` 명령을 사용하여 symlink가 가리키는 디렉터리 검색
$ ls -l /usr/bin/aws 
-rwxr-xr-x 1 root root 818  9월 28  2020 /usr/bin/aws

# aws 의 삭제를 위해 파일을 삭제합니다.
$ sudo rm /usr/bin/aws 
$ sudo rm /usr/bin/aws_completer 
$ sudo rm -rf /usr/local/aws-cli

# AWS CLI v2 설치 파일을 다운로드
$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 44.8M  100 44.8M    0     0  59.8M      0 --:--:-- --:--:-- --:--:-- 59.8M

# 패키지의 압축을 풀고 현재 디렉터리 아래에 `aws`라는 디렉터리 생성
$ unzip awscliv2.zip
inflating: aws/dist/awscli/examples/ec2/delete-key-pair.rst
inflating: aws/dist/awscli/examples/ec2/authorize-client-vpn-ingress.rst
inflating: aws/dist/awscli/examples/ec2/delete-network-interface.rst
...

# 설치 프로그램을 실행
$ sudo ./aws/install
You can now run: /usr/local/bin/aws --version

# 설치 위치를 지정
$ ./aws/install -i /usr/local/aws-cli -b /usr/local/bin
Found preexisting AWS CLI installation: /usr/local/aws-cli/v2/current. Please rerun install script with --update flag.

Dockerize

[Front] React Dockerize

[오류] npm Err

[원인]

지속적으로 yarn install/build 과정에서 여러 모듈에서 npm Err가 났다. 이유는 node alpine 이미지를 사용해서 였는데, alpine은 경량화 된 이미지라서 python 등이 설치되어 있지 않고, 이를 사용하는 모듈의 설치가 실패되었다.

[해결]

우선 FROM node:16 이미지를 사용하는 방식으로 해결했다. 하지만 이미지가 거대해져서 좋은 해결방식은 아닌 것 같다. 추후에 더 좋은 방법을 찾아 볼 예정이다.

참고 # [CICD / ECS] CodePipeline으로 ECS Fargate 배포 자동화 #1 - 개요, 아키텍처

# 「초심자」무작정 해보는 ECS 컨테이너 서비스 구축 – 1 (ECR에 이미지 푸시)

p.s 추후에 이 블로그 그림처럼 vpc/subnet 내용 정리하기

https://www.44bits.io/ko/post/getting-started-with-ecs-fargate

AWS ECS fargate를 사용한 Appilication 배포 - 1

ECR

참고

AWS-ECR 사용하기

ECR 레포지토리 생성 ECR 리포지토리를 private하게 만들어주었다.

[오류] github actions -> push -> EOF 에러

[원인]

github actions를 통해 ECR에 로그인하여 ECR로 푸시하는 yaml 파일을 작성하였는데, 계속 원인모를 EOF 에러가 났다. 원인은 permissions를 설정해주지 않아서 였다.

[해결]

레포지토리의 permissions에 들어가서 정책을 편집하여, deploy해야하는 IAM 계정에 push 권한을 부여했다.

정책

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPushAndPull",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::[숫자]:user/[IAM User명]"
        ]
      },
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:BatchGetImage",
        "ecr:CompleteLayerUpload",
        "ecr:GetDownloadUrlForLayer",
        "ecr:InitiateLayerUpload",
        "ecr:PutImage",
        "ecr:UploadLayerPart"
      ]
    }
  ]
}

이미지를 pull 받기 위해 AmazonEC2ContainerRegistryFullAccess 권한 가지는 IAM 사용자 생성
aws configure 해서 해당 액세스키, 비밀번호, 리전 입력
aws ecr get-login --no-include-email --region ap-northeast-2 하면 로그인 할 수 있는 명령어들 출력 이걸 복사해서 로그인 하면 된다.

경건하게 백엔드 도커파일 만들기

자꾸 도커파일 생성에서 hibernate 에러나서 원인 찾으려 하나하나 과정을 적어보려 한다.

우분투 jdk8 이미지 받아오고 컨테이너화

$ docker pull rtfpessoa/ubuntu-jdk8

$ docker run -t -d --name my_temp rtfpessoa/ubuntu-jdk8:latest

[오류] ERROR: JAVA_HOME is set to an invalid directory

[원인]

도커파일 생성을 위해 우분투에서 직접 빌드해보려는 와중에 남.

[해결]

$ readlink -f $(which java)

경로

$ export JAVA_HOME="위 경로에서 bin/java 뺀 경로"

확인

$JAVA_HOME/bin/java -version

했을 때 잘 나오면 됨.

appication.yaml에 DB 주소 넣고
그래들 빌드

$ chmod +x gradlew

$ ./gradlew build

[오류] test FAILED

[원인]

> Task :test FAILED                                                                                                                                                                                                                                               FAILURE: Build failed with an exception.                                                                                                                                                                                                                          * What went wrong:                                                                                                               Execution failed for task ':test'.                                                                                               > There were failing tests. See the report at: file:///home/izero/uplus.com/backend/project/build/reports/tests/test/index.html                                                                                                                                   * Try:                                                                                                                           > Run with --stacktrace option to get the stack trace.                                                                           > Run with --info or --debug option to get more log output.                                                                      > Run with --scan to get full insights.                                                                                                                                                                                                                           * Get more help at https://help.gradle.org                                                                                                                                                                                                                        BUILD FAILED in 15m 5s

test에서 계속 에러가났다.

[해결] 테스트 제외하고 빌드

계속 나를 괴롭혔던 원인..!

테스트 제외하고 빌드하면 된다!

$ ./gradlew build -x test

ls로 build 속 jar 파일이름 확인

$ /build/libs# ls

project-0.0.1-SNAPSHOT.jar

$ java -jar build/libs/project-0.0.1-SNAPSHOT.jar

. ____ _ __ _ _ /\ / ' __ _ () __ __ _ \ \ \ \ ( ( )__ | '_ | '| | ' / ` | \ \ \ \ \/ )| |)| | | | | || (| | ) ) ) ) ' || .__|| ||| |_, | / / / / =========||==============|/=//// :: Spring Boot :: (v2.7.3) 2022-08-30 11:31:43.102 INFO 23088 --- [ main] com.lguplus.project.ProjectApplication : Starting ProjectApplication using Java 1.8.0_342 on ip-172-31-34-43 with PID 23088 (/home/ubuntu/uplus.com/backend/project/build/libs/project-0.0.1-SNAPSHOT.jar started by root in /home/ubuntu/uplus.com/backend/project) 2022-08-30 11:31:43.108 INFO 23088 --- [ main] com.lguplus.project.ProjectApplication : No active profile set, falling back to 1 default profile: "default"

근데 중단이 된다...

jar 파일 my_temp 컨테이너의 home 경로에 복사

$ docker cp *.jar my_temp:home/

my_temp bash로 들어가서 경로 확인

$ docker exec -it my_temp bash

$ /home# ls

project-0.0.1-SNAPSHOT.jar

$ /home# java -jar *.jar

그래도 계속 나는 에러...

#11 75.45 Starting a Gradle Daemon (subsequent builds will be faster)                                                                            #11 171.6                                                                                                                                        #11 171.8 FAILURE: Build failed with an exception.                                                                                               #11 171.9                                                                                                                                        #11 171.9 * What went wrong:                                                                                                                     #11 171.9 Task 'test' not found in root project 'project'.                                                                                       #11 171.9                                                                                                                                        #11 171.9 * Try:                                                                                                                                 #11 171.9 > Run gradlew tasks to get a list of available tasks.

도커파일 만들어봄

FROM adoptopenjdk/openjdk8:ubi AS builder
WORKDIR /home/ec2-user/app
COPY gradlew .                                                                                    =
COPY gradle gradle                                                               
COPY settings.gradle .                                  
COPY src src                     
RUN chmod +x ./gradlew                           
RUN ./gradlew build bootJar             

FROM adoptopenjdk/openjdk8:ubi                                              
COPY --from=builder . .
#EXPOSE 8080
#ENTRYPOINT ["java", "-jar", "app.jar"]

FROM openjdk:8-jdk-alpine AS builder
WORKDIR /home/ec2-user/app
COPY gradlew .
COPY gradle gradle                                                               
COPY settings.gradle .                                  
COPY src src                     
RUN chmod +x ./gradlew                           
RUN ./gradlew build bootJar             

FROM openjdk:8-jdk-alpine                                             
COPY --from=builder build/libs /builds
#EXPOSE 8080
#ENTRYPOINT ["java", "-jar", "app.jar"]

여기까지 했을 때 경로가 /home/ec2-user/app/build/libs # ls project-0.0.1-SNAPSHOT.jar

수정해서 성공한 도커파일

FROM openjdk:8-jdk-alpine AS builder
WORKDIR /home/ec2-user/app
COPY gradlew .
COPY gradle gradle
COPY build.gradle .
COPY settings.gradle .
COPY src src
RUN chmod +x ./gradlew
RUN ./gradlew build -x test

FROM openjdk:8-jdk-alpine
COPY --from=builder /home/ec2-user/app/build/libs/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

swagger 잘 나옴.

Nginx+React+Spring Docker fargate에 배포

참고

https://velog.io/@nayoon-kim/Spring-boot-nginx-docker-ec2-%EC%9E%90%EB%B0%94%EC%84%A4%EC%B9%98%EB%B6%80%ED%84%B0

[AWS] Spring Boot, Nginx, Docker 로 무중단 배포하기 - 1탄

[AWS ECS] ECR 이미지를 ECS로 실행 (컨테이너 실행 및 관리)

작업 정의 생성
BE용 ALB 생성

Fargate vs EC2

개요

- ECS with EC2
AWS 자체 개발하여 제공하는 컨테이너 서비스
    - 장점
    EC2 인스턴스에 대한 full 컨트롤, GPU 인스턴스 활용 용이
    spot 인스턴스 활용 가능하여 최대 90% 비용 절감
    - 단점
    EC2 인스턴스를 직접 관리해야함, 예: 인스턴스에 대한 보안 패치 등을 직접 처리해야함

- ECS with Fargate
AWS 람다와 EC2 기반의 ECS 컨테이너의 중간 쯤에 위치한 서비스, EC2 인스턴스 관리에 대해 걱정 안해도 됨
    - 장점
    관리할 서버가 없음
    CPU/Memory 선택이 상대적으로 좀 더 용이함
    Fargate Spot을 사용하여 70% 절감된 금액으로 이용할 가능성 있음
    - 단점
    awsvpc로 네트워크 옵션이 제한됨

비용 측면

ec2는 t3.micro 시간당 0.013 USD 2vcpu 1GiBt2.micro 시간당 0.0144 USD 1vcpu 1GiB

fargate는 vcpu당 0.04656 USDGB당 0.00511 USD

fargate를 1vcpu 1GB 사용한다면 그 합이 0.05167 USD 정도가 되는데

동급의 ec2에 비해서 많게는 3배까지 비용이 비싸다.

결론

비록 비용적 측면에서 큰 단점이 있지만, 이전에 EC2를 통해서만 구축해봤기에 직접 관리할 부분이 적다는 장점을 가진 ~~fargate를 경험 및 학습적 측면에서 선택해 봤다.~~ fargate를 선택하려고 했으나 stateless한 fargate에서는 카프카 구성이 적합하지 않다고 하여서, 비용측면에서 저렴한 EC2를 선택했다.

배포 전략 선택

ECS에서 자체적으로 2가지의 배포전략을 선택할 수 있었다.

1. 롤링 ( Rolling )

인스턴스를 정해놓은 단위로 교체하는 방식이다. 서비스를 구성하는 총 서버의 댓수가 10대라면 2대씩 롤링 업데이트를 진행하겠다고 한다면, 새로운 버전 2대가 생성되고, 정상적으로 서비스가 가능한 상태일때 트래픽이 2대로 전환되고, 구버전 2대는 서비스에서 제외한다. ( draining ) 이 방식으로 2대씩 순차적으로 새로운 버전으로 교체되는 방식이다. 이 방식은 가용 리소스가 적은 상태에서도 배포가 가능하다. 업데이트 프로세스 동안 두 가지 버전의 컨테이너가 동시에 실행되기 때문에 버전 호환성의 문제가 발생할 수 있다.

2. 블루 그린 ( Blue/Green )

구 버전을 블루 신 버전을 그린이라고 해서 붙여진 이름으로, 동일한 서버를 미리 구축한뒤에 라우팅을 순간적으로 전환하여 새로운 버전을 배포하는 방식이다. 빠른 롤백이 가능한 장점이 있고, 운영 환경을 유지한채로 새롭게 배포될 버전의 테스트도 가능한 구성이 되나, 자원이 두배로 필요하게 되어 비용이 많이 방생하는 단점 도 존재한다.

Fargate SSH 접속

참고

# 9 steps to SSH into an AWS Fargate managed container

ALB 생성 및 Fargate로 로드밸런서 프론트엔드 확인해보기

참고

https://dev.classmethod.jp/articles/lets-make-aws-fargate-first/

Private RDS 터널링 방법

참고

https://velog.io/@ynsoo1225/AWS-Bastion-Host%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%98%EC%97%AC-IntelliJ%EC%97%90%EC%84%9C-Private-Subnet-RDS-%EC%97%B0%EA%B2%B0

ECS 클러스터 생성과정

리눅스 유용한 명령어

- 전체 폴더에서 폴더 찾기
find / -name 폴더명 -type d

요약

계정 기초보안

루트계정의 Access Key를 탈취하여 고비용의 리소스를 생성하거나 고비용의 서비스를 신청하여 단기간에 수만 달러에 달하는 비용을 발생시키는 피해가 발생하므로, 꼭 추가 보안 설정이 필요함.

루트 사용자 MFA 설정

AWS 콘솔에 로그인할 때 아이디/패스워드 외 추가 인증을 더하는 것

루트 사용자 Access Key 삭제

액세스 키는 아이디/패스워드 인증과 동일한 권한을 갖지만 AWS CLI, PowerShell용 도구, AWS SDK 또는 직접 AWS API 호출을 통해 AWS를 프로그래밍 방식으로 호출할 수 있도록 해주는 반드시 필요한 존재이지만 액세스 키가 루트 사용자 권한으로 사용될 때는 그 용도 만큼이나 매우 강력해서 탈취되어 악용하면 광범위한 영역에서 피해를 줄 수 있음. 따라서, 특별한 이유가 없다면 루트 사용자 계정에는 반드시 액세스 키를 삭제하거나 비활성화되어 있어야 함.

IAM 사용자 설정

admin 사용자를 따로 만들어 AdministratorAccess 권한만 부여. 이렇게 빌링 권한을 가지지 않은 사용자를 이용하여, AWS 리소스에 대한 액세스를 안전하게 제어.

웹 서버 - Nginx

Apache와 nginx 중 HTML 파일 사이즈, 어떤 추가 기능을 쓰느냐 등 다양한 조건 때문에 무엇이 더 무조건 성능이 좋다고는 이야기 할 수 없음. 하지만 많은 접속자가 있을 경우, 시스템 자원 관리 효율성 때문에 Nginx가 일반적으로는 성능이 더 좋을 수 있으므로 해당 프로젝트에서는 Nginx를 사용함.

배포 전략

도커

추후 서버 관리의 편의를 위해 도커라이징 하기로 결정함.

Infra

첫 번째 도전 - 기본적인 CI/CD 구축 및 1개의 EC2

웹 서버

Apache vs nginx

1. Apache

2. Nginx

결론

배포 전략

두 번째 도전 - EC2와 ECS 구축

순서

도커

도커란?

마이크로 서비스와 DevOps, 도커

docker image

docker container

EC2 도커 실행 환경 구축

aws-cli 설치

Dockerize

[Front] React Dockerize

[오류] npm Err

[원인]

[해결]

ECR

[오류] github actions -> push -> EOF 에러

[원인]

[해결]

정책

경건하게 백엔드 도커파일 만들기

[오류] ERROR: JAVA_HOME is set to an invalid directory

[원인]

[해결]

[오류] test FAILED

[원인]

[해결] 테스트 제외하고 빌드

Nginx+React+Spring Docker fargate에 배포

Fargate vs EC2

개요

결론

배포 전략 선택

1. 롤링 ( Rolling )

2. 블루 그린 ( Blue/Green )

Fargate SSH 접속

ALB 생성 및 Fargate로 로드밸런서 프론트엔드 확인해보기

Private RDS 터널링 방법

ECS 클러스터 생성과정

리눅스 유용한 명령어

요약

계정 기초보안

웹 서버 - Nginx

배포 전략

도커

Clone this wiki locally