왜 Docker-compose를 사용할까? - TIL230615

📚 KDT WEEK 11 DAY 4 TIL

• Docker-compose
• 실습 1 - Docker-compose 파일이 없을 때
• 실습 2 - Docker-compose 파일이 있을 때

 

---

 

🟥 Docker-compose

docker-compose.yaml : 다수의 도커 컨테이너를 관리하기 위한 환경설정 파일

개별 Container를 따로 관리하는 것보다 훨씬 더 생산성이 높다.

파일에 각 컨테이너별로 이름과 포트포워딩, 도커 볼륨, 환경과 네트워크 구성 등 한번에 기술해뒀다고 생각하면 편하다.

 

따라서 한마디로 여러 개의 도커 컨테이너로 구성된 하나의 앱을 구성할 때에는 굉장히 편리한 파일이다.

그 부분을 실습으로 직접 비교해보겠다.

 

docker volume도 기술되어 있다.

이전 글에서 배웠던 내용을 조금 추가하자면,

이 파일에 docker volume 기능을 사용하기 위해 어떻게 마운트를 할 것인지에 대한 내용도 기술되어 있다.

 

docker-compose.yaml 파일의 일부

docker-compose.yaml을 보면, volumes: 항목에서 docker volume 마운트에 대해 적혀있다.

AIRFLOW_PROJ_DIR은 airflow가 세팅된 폴더를 자동으로 지칭한다.

---

 

 

명령어

• docker-compose build : build 키로 지정된 이미지들 대상으로 빌드
• docker-compose pull : image 키로 지정된 이미지들 대상으로 docker hub에서 가져오기
• docker-compose images : docker-compose로 실행된 컨테이너가 어떤 이미지로 실행되었는지 리스트 출력
• docker-compose push : 한번에 docker hub로 push(권한필요)

 

• docker-compose up : 이미지를 build하거나 받아오고, 도커 컨테이너를 실행하고 시작한다.( build + pull + start )
• docker-compose down : 실행한 모든 도커 컨테이너들을 한번에 멈추고(stop) 삭제(rm)까지 진행
• docker-compose ls : docker-compose 그룹별로 리스트
• docker-compose ps : docker-compose로 실행된 docker container들의 상태 출력

 

 

🟦 다수의 Container로 구성된 예제 프로그램 실행해보기

본 실습은 도커 예제로 제공되는 vote-application을 토대로 실습하였다.

https://github.com/dockersamples/example-voting-app

GitHub - dockersamples/example-voting-app: Example distributed app composed of multiple containers for Docker, Compose, Swarm, a

 

실습을 진행하기 전에 도커 컨테이너와 이미지를 정리해두는 것을 추천한다.

 

# 도커 클린업
docker container rm -f $(docker container ls -aq)
docker image rm -f $(docker image ls -q)

 

위 예제 프로그램에 대해 간략하게 설명하자면, 총 5개의 컨테이너로 구성되는 프로그램이다.

vote, result, worker, redis, postgres

vote와 result는 front-end로써 투표 화면과 투표 결과화면을 제공하고, postgres는 투표 결과 DB 역할을 한다.

vote > redis > worker > postgres > result 순서로 동작한다고 보면 쉽다.

 

일단 다섯개의 컨테이너를 하나로 구성해줄 네트워크를 하나 만들어야 한다.

docker network create mynetwork

mynetwork 라는 이름으로 네트워크를 하나 구성했다.

이 네트워크를 언급한 다섯개의 컨테이너를 run하게 될 때 옵션으로 지정해주면 된다.

 

다섯개의 컨테이너가 필요하므로 다섯번의 docker run이 필요하다.

# Docker file의 위치를 알려 도커를 빌드
docker build -t vote ./vote
docker build -t result ./result
docker build -t worker ./worker

docker run -d --name=vote -p 5001:80 --network mynetwork vote
docker run -d --name=result -p 5002:80 --network mynetwork result
docker run -d --name=worker --network mynetwork worker

# 공식 이미지의 경우 run을 통해 이미지 다운로드
docker run -d --name=redis --network mynetwork redis
docker run --name=db -e POSTGRES_PASSWORD=password --network mynetwork postgres

postgres의 경우 실행하면서 비밀번호 설정이 필요하므로 조금 명령어가 다르다.

나는 vote를 5001 포트로, result를 5002 포트로 열어두었다. 이 부분은 자유다.

 

실행이 완료되면 postgres 컨테이너가 구동되고 있을 것이다.

새로운 터미널을 열어 docker ps를 해보면 5개의 컨테이너가 열려있어야 한다.

 

언급했던 5개의 컨테이너가 열려있다.

 

이제 열었던 포트를 통해 로컬호스트로 접속해보자.

 

vote 화면

 

localhost:5001에 접속하면 vote에 접속되고, 클릭해서 투표도 할 수 있다.

localhost:5002에 접속하면 result 화면이 보이고, 투표 결과를 볼 수도 있다.

 

하지만 투표 결과가 바로바로 투표 결과에 반영되지는 않는다.

왜냐하면 postgres 추가설정이 필요하기 때문이다.. 이 부분이 지금 실습에서 중요한 건 아니므로 넘어가겠다.

 

 

---

 

🟩 이번에는 docker-compose로 간단하게 연결해보기

 

예제 프로그램에도 docker-compose 파일을 제공하지만, 새로운 docker-compose 파일을 간단하게 구성하였다.

 

services:
  vote:
    build: ./vote
    # use python rather than gunicorn for local dev
    command: python app.py
    ports:
      - "5001:80"

  result:
    build: ./result
    # use nodemon rather than node for local dev
    entrypoint: nodemon server.js
    ports:
      - "5002:80"

  worker:
    build: ./worker

  redis:
    image: redis:alpine

  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_USER: "postgres"
      POSTGRES_PASSWORD: "postgres"

docker-compose 파일은 services: 밑으로 각각의 구성할 컨테이너들을 작성하게 된다.

vote, result, worker, redis, db(postgres)로 아까와 같이 5개의 컨테이너를 작성한다.

 

vote, result, worker는 build: 를 통해 각각의 docker file 위치를 알린다.

vote와 result는 포트포워딩이 필요했으니 port: 를 사용한다.

command: 와 entrypoint: 는 docker file에 작성된 CMD와 ENTRYPOINT를 오버라이딩할 때 사용한다.

 

redise와 db는 공식 이미지이므로 image: 를 사용해서 어떤 이미지를 docker hub에서 받아올지 작성하고,

postgres의 경우 환경변수가 필요했으니 environment: 를 통해 해당 사항을 작성한다.

 

이대로 예제 프로그램 폴더에 docker-compose.mac.yml 파일로 저장하였다.

이제는 실행하는 일만 남았다!

 

 

일단 아까 실습했던 내용이 있다면 컨테이너와 이미지 청소를 해두자.

 

# 도커 클린업
docker container rm -f $(docker container ls -aq)
docker image rm -f $(docker image ls -q)

 

그리고 예제 프로그램 폴더에서 다음의 명령어만 입력하면 된다.

 

# docker-compose up
docker-compose -f docker-compose.mac.yml up

 

파일의 이름이 docker-compose.yml 이거나 docker-compose.yaml 이라면 docker-compose up 으로 충분하다.

하지만 나는 새로운 docker-compose 파일을 넣고 이름도 바꿧으니 위의 명령어처럼, -f 옵션을 사용해 이름을 알려야한다.

 

바로 로컬호스트로 접속해서 작동하는지 확인해보자.

 

잘 동작한다!

 

첫 번째 실습에서 사용했던 network가 생략되도 동작하는 이유는, docker-compose에서는 자동으로 하나의 네트워크로 묶어주기 때문이다.

services에 준 이름으로 호스트 이름이 생성되어 이름을 내부 IP로 변환해주어, docker끼리 네트워크 연결된다.

 

⚙️ docker-compose.yml 내용 알아보기

 

0. docker-compose.yml 파일에서 airflow 환경변수 설정하기

x-airflow-common: 
    &airflow-common 
    image: ${AIRFLOW_IMAGE_NAME:-apache/airflow:2.5.1}
    environment:   
        &airflow-common-env   
        AIRFLOW_VAR_DATA_DIR: /opt/airflow/data     
        AIRFLOW__API__AUTH_BACKENDS: 'airflow.api.auth.backend.basic_auth,airflow.api.auth.backend.session'

 

위 내용은 내 airflow의 docker-compose.yml 내용 일부이다.

 

environment에 환경변수를 설정할 수 있는데, 크게 AIRFLOW 뒤의 언더바 개수로 구분된다.

• AIRFLOW_ : airflow의 variables 같은 변수를 미리 만들어둘 수 있다.
  • AIRFLOW_VAR_변수이름 : variables에 : 뒤에 해당하는 내용을 변수이름에 저장한다.
• AIRFLOW__ : airflow.cfg 의 해당 섹션의 값을 변경한다.
  • AIRFLOW__API__AUTH_BACKENDS : airflow.cfg의 api 섹션에 해당하는 auth_backend 값을 변경한다.

airflow.cfg의 경우 AIRFLOW 뒤의 언더바가 두 개, 해당 섹션 다음으로 언더바가 두 개인 것을 주의해야한다.

이 환경변수들은 docker compose up을 하며 자동으로 설정되지만, Airflow 웹 UI와 같은 외부에서 표출되진 않는다.

 

 

 

1. build: 빌드 관련 정보를 넘긴다.

 

ex)

worker:
    build: ./worker

worker:
    build:
        context: ./woker
        dockerfile : Dockerfile.dev
        arg:
            ENVIRONMENT: development
    

 

• context: 도커 파일의 위치를 넘겨 빌드 (첫 번째 예시처럼 줄여쓰기도 함)
• dockerfile: 도커파일의 이름(Dockerfile.yml이 아닌 다른 이름일 때 사용)
• args: 환경변수 넘기기

 

2. depends_on: 어떤 컨테이너가 동작한 후에 해당 컨테이너를 실행하도록 명령

 

ex)

worker:
    depends_on:
        db:
            conditions: service_healthy

 

condition으로 가능 한 값

• service_started : 그 서비스가 시작한 뒤
• service_healthy : 그 서비스의 상태가 정상일 때 ( healthcheck 옵션에 의해)
• service_completed_successfully : 그 서비스가 정상적으로 종료된 후에

 

3. environment: 컨테이너 안에서 실행될 때 환경변수들을 지정 ( 도커파일의 env)

4. networks : 특정 네트워크로 묶고 싶을 때 지정, 네트워크는 service:와 같은 단에서 networks:로 선언한다.

5. volumes: 도커 볼륨 지정, : 을 기준으로 왼쪽에 이름을, 오른쪽에 저장하고 싶은 파일 경로를 지정한다.

 

ex)

db:
    enviroment:
        POSTGRES_USER:"postgres"
        POSTGRES_PASSWORD:"postgres"
    volumes:
        -"db-data:/var/lib/postgresql/data"
    healthcheck:
        test: /healthchecks/postgres.sh
        interval: "5s"
    networks:
        - back-tier

 

여러 서비스에서 공유하는 공통 구성을 만들 때:

ex) airflow의 경우

x-airflow-common:
    &airflow-common
    image: ${AIRFLOW_IMAGE_NAME:-apache/airflow:2.5.1}
    environment:
        &airflow-common-env
        AIRFLOW__CORE__EXECUTOR: CeleryExecutor
        …
        _PIP_ADDITIONAL_REQUIREMENTS: ${_PIP_ADDITIONAL_REQUIREMENTS:-}
    volumes:
        - ${AIRFLOW_PROJ_DIR:-.}/dags:/opt/airflow/dags
        - ${AIRFLOW_PROJ_DIR:-.}/logs:/opt/airflow/logs
        - ${AIRFLOW_PROJ_DIR:-.}/plugins:/opt/airflow/plugins
    user: "${AIRFLOW_UID:-50000}:0"
    depends_on:
        &airflow-common-depends-on
        redis:
            condition: service_healthy
        postgres:
            condition: service_healthy

x-airflow-common : 여러 서비스에서 공유하는 공통 구성을 정의한다, 보통 anchor라고 부름

&airflow-common :별칭 지정, 다른 서비스에서 airflow-common을 불러옴으로써 공통 구성을 가져올 수 있음

 

ex)

airflow-scheduer:
    <<: *airflow-common : airflwo-common