다시 웹, 백엔드로/CICD

멀티 컨테이너 서비스를 위한 docker compose

EnoughTT 2024. 8. 15. 23:00

멀티 컨테이너 서비스를 위한 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단계 프로세스

  1. Dockerfile 작성으로 배포하고자 하는 애플리케이션의 환경 정의 (선택)
  2. docker-compose.yaml 하나 이상의 컨테이너 서비스를 실행 할 수 있도록 서비스 정의 (yml)
  3. 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