서버 단위의 배포
전통적인 방식
서버(인스턴스) 내에서 동작, 새로운 배포를 위해 인스턴스 전체에 대해 배포 작업 이뤄짐
하나의 서버 인스턴스(물리 서버 or VM)에 애플리케이션 직접 설치되고 실행됨
이 서버는 OS, 네트워크 설정, 의존성, 런타임 환경 모두 포함/ 애플리케이션 이 환경 위에서 동작
단점
- 복잡한 관리: 업데이트나 설정 변경 복잡
- 확장성 제한: 새로운 서버 인스턴스 준비, 동일한 환경 복제 ⇒ 시간 많이 걸리고 리소스 낭비될 수 있음
- 유연성 부족: 하나의 서버에 여러 애플리케이션 설치 ⇒ 충돌 발생할 수 있음/ 환경 분리 어려움
컨테이너 단위의 배포
- Traditional Deployment: 온프레미스 환경
- Virtualized Deployment: 온프레미스 환경에서 발전 But, 하드웨어를 가상화 → 무거움
- Container Deployment: 불필요한 운영체제와 Hypervisor 생략 가능(효율적으로 가상화 환경 운영 가능)
컨테이너라는 더 작은 단위로 애플리케이션 패키징
~> 인스턴스 하나에 여러 개의 애플리케이션 or 서비스를 컨테이너 단위로 배포할 수 있음
여러 개의 EC2 인스턴스를 클러스터로 묶어 관리
Kubernetes: 각 컨테이너의 상태 모니터링, 필요한 경우 자동으로 재배포 or 확장하는 기능 제공
Docker(도커)
- Docker engine: 이미지, 네트워크, 디스크 등을 관리하는 역할
- containerd: runC와 같은 OCI 구현체를 이용해 컨테이너를 관리해주는 daemon
- 두 프로그램이 각각 돌아가기 때문에 도커 엔진을 재시작해도 각 이미지에 영향 X
컨테이너 기술 사용 → 애플리케이션 독립적, 이식성 높은 방식으로 패키징 할 수 있게 해줌
애플리케이션과 의존성을 함께 패키징 But, OS 레벨에서 격리되며 더 가벼움 ~> 빠른 시작과 종료 가능, 여러 컨테이너를 하나의 호스트에서 실행 O
로컬에서 작성한 애플리케이션 → 도커 이미지 ~> 어디서나 동일한 환경에서 실행 O ⇒ 일관된 배포 환경
⇒ 도커) 컨테이너 증가 → 관리의 필요성 느껴져 등장한 개념 But, 도커 또한 서비스 커질수록 양 증가 → 관리 어려움
→ 보조를 위해 오케스트레이션 툴이 필요: 쿠버네티스
이미지
- 실행 가능한 소프트웨어 패키지
- 변경되지 않고 재사용 가능
- 애플리케이션 코드, 라이브러리, 종속성, 실행 환경 등으로 구성
- 특정 애플리케이션을 실행하기 위해 필요한 모든 파일을 포함
컨테이너
- 이미지의 실행 인스턴스 = 이미지가 실제로 실행되어 동작하는 상태
- 동적으로 변경될 수 있음(↔ 이미지)
⇒ 이미지: 애플리케이션을 실행하는 데 필요한 모든 구성 요소를 포함하고 있는 템플릿
/ 컨테이너: 그 템플릿을 기반으로 실제로 실행되고 있는 환경
볼륨
데이터를 지속적으로 저장하고 관리하기 위해 사용되는 특별한 디렉터리
브릿지 네트워크
- Docker 컨테이너 간의 통신을 위한 가상의 스위치 역할
- 동일한 브릿지 네트워크에 연결된 컨테이너는 서로 직접 통신할 수 있으며, 외부 네트워크와도 연결할 수 있음
- 도커에서 기본적으로 생성되는 네트워크 유형, 컨테이너 간의 통신을 허용
- 각 컨테이너는 IP 주소를 부여받고 서로 이름으로도 접근할 수 있음
docker compose(도커 컴포즈)
단일 서버에서 여러개의 컨테이너 → 하나의 서비스로 정의 ⇒ 컨테이너의 묶음으로 관리할 수 있는 작업 환경을 제공하는 관리 도구
여러 개의 컨테이너가 하나의 어플리케이션으로 동작할 때 도커 컴포즈 사용 X → 테스트하려면 각 컨테이너를 하나씩 생성
ex. 웹 어플리케이션을 테스트하려면 웹 서버 컨테이너, 데이터베이스 컨테이너 두 개의 컨테이너를 각각 생성
- 여러 컨테이너를 정의하고 관리하는 도구
- docker-compose.yml 파일 ~> 애플리케이션의 서비스, 네트워크, 볼륨을 쉽게 구성하고 배포할 수 있음
⇒ 도커 컴포즈를 사용하여 user-service와 item-service를 정의하고,
이들을 동일한 브릿지 네트워크에 연결하면 각 컨테이너가 서로 통신
