멀티 컨테이너 서비스를 위한 docker compose
멀티 컨테이너 서비스 구성
wordpress 와 mysql 을 이용한 web application
- 다음과 같은 구조의 2-tier 구성을 docker run을 통해 수행해돔
IP:8888 접속
docker-compose 작성
docker compose는
- 여러번의 docker CLI를 실행하지 않고, 한번에 관련 애플리케이션들을 YAML 파일로 구성하여 내부 환경 구성과 속성을 실행 할 수 있음
- 설정 값을 캐싱하기 때문에 재시작 시 변경이 없다면 캐싱된 정보를 그대로 사용하여 빠른 서비스 실행을 보장 할 수 있음
- YAML 코드에 포함된 애플리케이션들은 동일 네트워크에 포함되기 때문에 복잡한 연결 구성 없이 쉽게 API 통신이 가능한 장점도 갖게 됨
docker compose YAML 코드 작성과 CLI
- docker compose 는 kubernetes 와 같이 컨테이너 오케스트레이션 및 컨테이너화 된 애플리케이션 관리에 사용되는 도구
- 다중 컨테이너 Docker 애플리케이션을 정의하고 실행하기 위한 도구, YAML 파일을 사용하여 애플리케이션 서비스 수행
- docker compose CLI 를 이용하여 모든 서비스의 라이프 사이클 관리
docker compose?
- 응집력 있는 애플리케이션으로 함께 작동하는 여러 컨테이너를 실행하려는로컬 개발 및 테스트 환경을 위해 설계된 도구
- 응집력? 공통성?
- 하나의 웹 애플리케이션을 생성하는 3-Tier 환경을 예로 듦
- 애플리케이션 데이터를 저장하기 위해 MySQL 데이터베이스를 설정하고, API 애플리케이션 설정을 위해 backend 단에 Springboot, Flask, Node.js 등을 구성
- 사용자 인터페이스 (Frontend) 구성을 위해 Node.js, React, Angular 등의 웹 프레임워크를 선택해 구성할 수 있음
- docker compose YAML 코드는 여러개의 docker run 실행과 유사하며 네트워크, 볼륨 등을 한번에 생성할 수 있음
- 기본 이미지, 노출된 포트, 환경 변수, 컨테이너 간의 종속성 등을 포함하는 컨테이너들에 대한 구성 지정
- docker compose 로 실행된 컨테이너들은 독립된 네트워크로 구성되므로 컨테이너간 통신이 쉬움
- docker compose 3단계 프로세스
- Dockerfile 작성으로 배포하고자 하는 애플리케이션의 환경 정의 (선택)
- docker-compose.yaml 하나 이상의 컨테이너 서비스를 실행 할 수 있도록 서비스 정의 (yml)
- docker compose up 명령으로 YAML 코드로 정의된 서비스를 시작하고 실행
- 장점
- 서로 다른 OS 환경이라도 동일한 환경구성이 가능 (이식성)
- 동일한 환경을 사용하기 때문에 개발환경에 이슈가 발생해도 팀간 소통이 쉬움
- 복잡한 환경도 YAML 코드로 스크립트화 할 수 있기 때문에 자동화 가능
- docker compose CLI 이용해 쉽게 "멀티 컨테이너 애플리케이션"을 관리할 수 있음
- 단점
- 동시에 다수의 컨테이너 서비스를 수행하는 경우 (MSA) 자원 활용률이 순간 높아 질 수 있음
- docker compose 사용은 충분한 docker container 기술에 대한 이해도가 필요함
YAML 코드는?
- 사람이 쉽게 읽을 수 있는 데이터 직렬화 언어 (위 → 아래) 로 구성 파일 작성에 주로 사용
- 일반적으로 설계 상 가장 먼저 실행되야하는 애플리케이션을 먼저 작성하고, 의존성을 갖는 데이터베이스 및 하위 애플리케이션 작성
- 클러스터 환경인 경우 마스터 노드를 먼저 작성하고 그 다음 데이터 노드들을 이어서 작성
- 그 다음 전체 애플리케이션에 필요한 네트워크, 볼륨, 캐시 등의 기반 환경까지 코드에 모두 설정 할 수 있음
- 서비스 전체를 하나의 docker-compose.yaml 로 작성이 가능함
- 쉽게 읽고 이해할 수 있도록 설계되어 프로그래밍 언어로 사용되거나, 클라우드 자동 환경 배포 도구 (IaC 환경 구성)로 많이 사용
YAML | JSON |
YAML Ain't Markup Language | JavaScript Object Notation |
주석 사용 가능 | 주석 사용 불가 |
한글 등의 유니코드를 그대로 사용 가능 | 한글 등의 멀티 바이트 문자는 인코딩 수행 |
주로 환경 구성 등의 설정 파일 작성 시 사용 | 주로 API 작성 시 사용 |
version: '3.8' services: mydb: image: mariadb:10.4.6 |
{ "version": "3.8", "service": { "mydb": { "image": "mariadb:10.4.6" } } } |
YAML 코드 문법적 특징
- 중괄호, 대괄호, 닫기 태그 또는 따옴표과 같은 통상적인 형식 기호는 없음
- Python 스타일의 들여쓰기를 사용해 구조를 결정하고 중첩 표시함
- 시스템 전반에서 이식성을 유지하기 위해 들여쓰기 탭문자를 허용하지 않고, 그대로의 공백 문자를 원하는 공백 * n 으로 규칙성 있게 사용함
- YAML 코드는 key, value 중심으로 작성되고, 숫자형, 문자형, Boolean 형을 지원함
- #: 주석
- ---: 문서의 시작 (선택)
- ...: 문서의 끝 (선택)
- key: python dictionary 자료형의 key와 동일
- value: python dictionary 자료형의 value와 동일
- 계층 구조는 부모-자식 간의 레벨을 규칙성 있는 들여쓰기로 엄격하게 구분함
YAML 코드 작성
docker-compose.yaml 파일 작성은 해당 프로젝트의 최상위 디렉터리에 위치, 하위 프로그램의 설정과 연관성을 코드화 함
version
- docker-compose.yaml 코드의 첫줄은 version 명시 (순서 무관)
- version 명령은 docker engine release와 연관되는 Compose file format임 (https://docs.docker.com/compose/compose-file/compose-versioning)
- 현재 Docker 엔진에 맞는 버전을 사용하고, 만약 version이 맞지 않는 경우 다음과 같은 오류가 나옴
- 원인은
- 작성한 버전과 현재 docker compose 또는 Docker 엔진 릴리즈가 적합하지 않는 경우
- docker compose 도구가 오래된 경우, 새로운 버전으로 업데이트 수행
- 버전 문제가 아닌 들여쓰기의 공백 수가 하위 레벨과 맞지 않아서 발생하는 경우
services
- docker compse 는 컨테이너 대신 service 개념을 사용하고, 상위의 version 명령과 동일 레벨로 작성되며 다중 컨테이너 서비스 실행을 목적으로 하기 때문에 복수형으로 작성
- services 하위에는 실행될 컨테이너 서비스를 작성하고, 하위 레벨에 Docker 명령 실행과 유ㅜ사하게 컨테이너 실행에 필요한 옵션들을 작성함
- build: docker compose 실행 시 빌드 될 Dockerfile 명시
- container_name
- 생략 시 자동으로 부여, "디렉터리명_서비스명_n"
- docker run 의 --name 옵션과 동일
- ports
- 서비스 내부 포트와 외부 호스트 포트를 지정하여 바인드, 외부 노출 포트 지정
- docker run의 -p 옵션과 동일
- expose
- 호스트 운영체제와 직접 연결하는 포트를 구성하지 않고, 서비스만 포트를 노출, 링크로 연결된 컨테이너 서비스와 서비스 간의 통시만 필요한 경우에 사용
- networks
- 최상위 레벨의 networks 에 정의된 네트워크 이름을 작성
- docker run --net (--network) 옵션과 동일
- volumes
- 서비스 내부 디렉터리와 호스트 디렉터리를 연결하여 데이터 지속성 설정
- docker run의 -v (--volume) 옵션과 동일
- environment
- 서비스 내부 환경 변수 설정
- 환경 변수가 많은 경우, 파일 (*.env) 로 만들어 env_file 옵션에 파일명을 지정 → env_file: ./envfile.env
- docker run의 -e 옵션과 동일
- command
- 서비스가 구동 이후 실행할 명령어 작성
- docker run의 마지막에 작성되는 명령어
- restart
- 서비스 재시작 옵션 지정
- docker run의 --restart 옵션과 동일
- depends_on
- 서비스간의 종속성을 의미하며 먼저 실행해야 하는 서비스를 지정하여 순서 지정
- 이 옵션에 지정된 서비스가 먼저 시작됨
- scale
- 해당 서비스의 복제 컨테이너 수 지정 (V2) → (V3) deploy.replicas로 변경
- 여전히 scale 명령으로 수행하고자 하면, docker-compose --compatibility up -d
networks
- 다중 컨테이너들이 사용할 최상위 네트워크 키들을 정의하고 이하 하위 서비스 단위로 이 네트워크를 선택 할 수 있음
- driver: 서비스의 컨테이너가 브리지 네트워크가 아닌 다른 네트워크를 사용하도록 설정
- ipam: IPAM (IP Address Manager) 를 위해 사용할 수 잇는 옵션으로 subnet, ip, gateway 범위 설정
- external: 기존의 네트워크 사용하도록 설정
volumes
- 데이터의 지속성을 유지하기 위해 최상위 레벨에 볼륨을 정의하고, 서비스 레벨에서 볼륨명과 서비스 내부의 디렉터리를 바인드 함
- docker volume create 와 동일하게 Docker 가 관리하는 /var/lib/docker/volume에 자동 배치됨
- "docker volume ls" 명령과 "docker volume inspect 볼륨명" 으로 확인 가능
healthcheck
- 컨테이너 서비스의 상태를 체크하는 명령
- 예
- 컨테이너 서비스 시작 후 30초 부터 1분마다
- 웹 서비스가 10초 이내에 기본 페이지를 응답해야 하고
- 실패 시 3회 재시도 수행함
'다시 웹, 백엔드로 > CICD' 카테고리의 다른 글
Nodejs 환경 Image build (0) | 2024.08.14 |
---|---|
Docker 플랫폼 환경 구성 (0) | 2024.08.13 |
docker 엔진 설치와 구성 확인 (0) | 2023.09.11 |
Ubuntu linux 환경 구성 (0) | 2023.09.08 |
Docker 플랫폼 환경 구성 (0) | 2023.09.06 |