Docker

• 도커의 주요 특징은 컨테이너화
• 컨테이너 : 애플리케이션과 그 실행에 필요한 모든것 (라이브러리, 시스템 도구, 코드, 런타임 등)을 포함하는 표준화 된 유닛
  • 이식성: 컨테이너는 어떤 환경(개발 / 테스트 / 프로덕션)에서도 동일하게 실행 가능

도커 이미지란?

• 컨테이너를 생성하기 위한 템플릿
• 구성: 애플리케이션 코드, 런타임, 시스템 도구, 라이브러리 등을 포함한다.
  • 불변성: 이미지는 읽기 전용이며 한번 생성되면 변경되지 않는다.

도커 이미지와 컨테이너의 관계

• 이미지는 컨테이너의 '정적' 상태
• 컨테이너는 이미지의 '실행 중인' 인스턴스
• 하나의 이미지로 여러개의 컨테이너를 실행 할 수 있다.

Dockerfile 의 역할

• 도커파일에는 아래와 같은 것들이 들어간다.

1. 환경 준비
   • Node.js 환경을 기반으로 필요한 도구들을 설치한다.
2. 애플리케이션 코드 포함
   • 애플리케이션 코드를 이미지 내부로 복사한다
3. 의존성 설치 및 빌드
4. 실행 명령어 정의 ( 컨테이너 실행 시 해당 코드를 실행할 명령 지정)

그럼 만들어진 이미지는 어디로 푸시하나?

• AWS ECR(Elastic Container Registry)을 주로 사용한다.
• ECR 을 사용하는 이유
  • 이미지 버전 관리: 각 빌드마다 새로운 이미지 버전을 생성하고 저장할 수 있다.
  • 배포 용이성: ECS, AWS EKS(Elastic Kubernetes Service) 등 AWS 의 컨테이너 서비스와 쉽게 통합된다.
• ECR 은 그냥 도커 이미지를 저장하는 레지스트리.
• 애플리케이션이 실행되지는 않고, 마치 깃헙이 코드를 저장하는것과 비슷하다고 보면 됨

실서버 실행은?

• 실서버 실행은 EC2 혹은 ECS, EKS 와 같은 서비스에서 실행된다.
  • 요 서비스들이 ECR 에서 이미지를 가져와서 실제로 컨테이너를 실행한다.
• 즉 워크플로우는 아래와 같다고 보면 됨.
  • 도커 이미지 빌드
  • 빌드 된 이미지를 ECR 에 푸시 (저장)
  • EC2, ECS 또는 EKS 가 ECR 에서 이미지를 풀
  • 이 서비스들이 실제로 컨테이너를 실행하여 애플리케이션 구동함

도커 빌드 및 배포 과정 간략하게

• 개발자가 코드를 변경하고 Git 저장소에 푸시한다.
• CI/CD 파이프라인(예: Jenkins, GitHub Actions)이 트리거된다.
• 파이프라인이 새 도커 이미지를 빌드한다.
• 빌드된 이미지를 ECR(Elastic Container Registry)에 푸시한다.
• CI/CD 파이프라인이 쿠버네티스 매니페스트 파일(또는 Helm 차트)을 업데이트하여 새 이미지 버전을 참조하도록 한다.
• 업데이트된 매니페스트 파일이 Git 저장소에 커밋된다.
• GitOps 도구(예: ArgoCD, Flux)가 Git 저장소의 변경을 감지한다.
• GitOps 도구가 변경된 매니페스트를 EKS 클러스터에 적용한다(kubectl apply 또는 유사한 명령 사용).
• EKS의 쿠버네티스 컨트롤 플레인이 새로운 매니페스트를 처리하고, 필요한 변경사항을 팡가한다.
• EKS가 ECR에서 새 이미지를 가져와 새로운 파드(컨테이너)를 생성하거나 기존 파드를 업데이트한다.
• 새로운 파드가 시작되고 이전 버전의 파드는 점진적으로 정료된다(롤링 업데이트의 경우).
• 트래픽이 새로운 버전의 애플리케이션으로 전환된다.
• 모니터링 시스템이 새 버전의 성능과 helth 상태를 확인한다.