최종 프로젝트 : 감자쇼핑
DockerFile 수정
최적화와 가독성 향상, 이미지 사이즈 축소 등 다양한 이점을 고려하여 멀티스테이지 빌드 접근법을 dockerfile에 도입하였다.
####################
# Build Stage
####################
# Node.js 기반 이미지 선택
FROM --platform=linux/amd64 node:20.11.0 as build
# 애플리케이션 디렉토리 생성
WORKDIR /usr/src/app
# 애플리케이션 의존성 파일 복사
COPY package*.json ./
# package-lock*.json 대신 package*.json 사용으로 수정
# 패키지 설치
RUN npm install --verbose
# 애플리케이션 소스 복사 (src 폴더와 나머지 필요한 파일만 복사)
COPY src ./src
COPY tsconfig*.json ./
COPY nest-cli.json ./
# 애플리케이션 빌드
RUN npm run build --verbose
####################
# Production Stage
####################
FROM --platform=linux/amd64 node:20.11.0 as production
# 애플리케이션 디렉토리 생성
WORKDIR /usr/src/app
# 빌드 결과물과 패키지 파일 복사
COPY --from=build /usr/src/app/dist ./dist
COPY --from=build /usr/src/app/package*.json ./
# 프로덕션 의존성 설치 전에 CI 환경 변수 설정
ENV CI=true
# 프로덕션 의존성 설치
RUN npm install --only=production
# 애플리케이션 시작
CMD ["node", "dist/main"]
기존에 통으로 빌드만 하던 도커파일을 프로덕션과 빌드 단계로 분리하였다. 도입 후 실제로 이미지 사이즈가 1G에서 500메가바이트로 축소됨.
이 단계에서 몇 가지 에러가 났는데, husky 관련 명령어를 다음과 같이 수정하였다.
# package.json
// 기존
"prepare": "husky"
//수정후
"prepare": "if [ -z \"$CI\" ]; then husky install; fi"husky, 개발 의존성 중 하나가 프로덕션 설치 과정에서 실행되려고 하지만, --only=production 옵션으로 인해 개발 의존성이 설치되지 않아서 발생하는 문제였다. 프로덕션 빌드에 포함시키기에는 husky라는 모듈이 적합하지 않기 때문에(코드 개선을 위한... 의존성이다.) prepare 스크립트 수정으로 해결하였음. 이를 위해서 dockerfile에 환경 변수 CI를 지정해 줌.
docker build -t potato-app .
docker run -it -p 3000:3000 --env-file .env potato-app Cloud Security
VPC : Virtual Private Network
가상 프라이빗 네트워크. 완전 독립된 서버 환경을 만들어 주는 것. (분리)
availablity zone
VPC(같은 지역) 안의 zone. 이 안에 여러 Subnet들이 작은 네트워크로 쪼개져 있다.
Subnets?
작은 VPC...
로드 밸런서(Load Balancer)
네트워크 트래픽이나 애플리케이션 요청을 여러 서버 간에 분산시켜 처리하는 기능을 가진 시스템이나 소프트웨어. 이를 통해 단일 서버에 가해지는 부하를 줄이고, 전체 시스템의 처리 능력을 향상시킨다.
- Listener Rules
- HTTP -> PORT (HTTP redirect to 443)
- Target Groups
- 여러 서버에 분산해서 요청을 보내는 로드 밸런서... (Private IP로) 그래서 리다이렉트할 IP를 알고 있어야 함
- 그 IP들을 모아놓은 게 target groups
- 서버를 생성하고 추가하고 삭제할 때마다 타깃 그룹을 업데이트 해줘야 함.
Security Groups
-> 방화벽!
-> 필요 이상으로 오픈하면 외부에 노출되는 취약점이 생길 수 있음.
AWS에서는 EC2 같은 서버들에 다 적용할 수 있다. 보안 그룹은 하나 만들어서 여러 서버에 부착할 수 있음.
규칙이 크게 두 가지로 나뉜다.
1. 인바운드
- Allow all from same SG
- 외부에서 요청해서 들어올 때
2. 아웃바운드
- Allow all
- 내부에서 외부로 서드파티 API 요청 같은 거 보내기
로드 밸런서에도 적용...그러나 같은 시큐리티 그룹을 설정해줘야 내부 안에서 문제 없이 VPC끼리 통신을 핼 수 있다. 보안 그룹이 다르면 같은 VPC임에도 불구하고 요청을 보낼 수 없음.
근데 반대로 퍼블릭 아이피를 쓰고, 같은 시큐리트 그룹을 쓴다면 HTTPS 적용 없이 들어올 수 있는 위험이 생김
컨테이너 오케스트레이션
여러 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화하는 과정. 컨테이너화된 애플리케이션을 운영하는 데 있어서, 컨테이너의 수명 주기를 관리하고, 대규모로 컨테이너를 효율적으로 운영하기 위한 다양한 작업을 포함한다. 컨테이너 오케스트레이션은 일반적으로 클러스터 내에서 여러 서버(노드) 간에 컨테이너를 자동으로 배포하고, 균형을 맞추며, 관리하는 복잡한 작업을 단순화!
Graceful shutdown? 무중단 배포.
Kubernetes / ECS / EB(Elastic Beanstalk)
Kubernetes
오픈 소스. 손이 좀 더 많이 감. 클라우드에 있는 로드 밸런서를 써야 하고, 설정을 전부 해줘야 하는 번거로움이 있음.
ECS
오픈 소스 아님. AWS에서만 쓸 수 있다. 대신 AWS의 인프라에서 잘 돌아가게끔 만들어져서 좀 간편하다. AWS에서 돌린다고 가정하면 좀 더 저렴한 듯...
EB
컨테이너 오케스트레이션은 아니고... 배포 서비스 중 하나. EC2를 관리해줘야 함.
고급 기능과 이식성이 중요하다면 Kubernetes를 선택하는 것이 좋다.
AWS 서비스와의 통합과 간편한 관리를 원한다면 Amazon ECS!
빠르게 배포하고 쉬운 관리를 원하는 경우(특히 AWS 생태계 내에서) AWS Elastic Beanstalk이 적합함.
