Developers Haven

(DH)블로그는 개발자들이 기술 정보를 찾아볼 수 있는 안식처가 되고 싶음을 희망하여 시작하게 되었습니다. 공부한 내용과 성장 과정을 기록해두었으니 편히 둘러보시길 바랍니다.

Welcome to DH's Blog

[기술공부]/Apache Airflow

[Airflow] docker-compose.yaml에 대해 알아보기

DH’s Blog 2024. 1. 18. 10:51
반응형

 

 

 

docker-compose.yaml 이란 도커 컨테이너를 생성할 때 스크립트로 컨테이너 설정을 관리할 수 있는 도커 기능 중 하나이다. 이 파일은 key, value 형태로 구성되며 컨테이너들에게 설정하고 싶은 내용을 입력하게 된다. 컨테이너 관련 작업을 하다보면 docker-compose.yaml 파일을 자주 이용하게 되는데 이번 시간에는 이 파일의 구조에 대해 자세히 알아보도록 하자.

 

* 도커를 올릴 때(sudo docker compose up -d ) docker-compose.yaml 스크립트 내용을 통해 컨테이너가 생성된다.

 

1. docker-compose.yaml 파일 구성

가장 기본적으로 아래와 같은 내용으로 구성되어 있고, 각 내용에 대해 필요한 설정값을 key: value 형태로 지정하게 된다. (ex. restart: always → 해당 컨테이너가 죽은 경우 항상 재기동하겠다는 설정)

├── docker-compose.yaml
     └── version : yaml 파일 버전 정보를 의미(옵션)
     └── x-airflow-common : 컨테이너들에게 공통적으로 적용할 설정
     └── services : 컨테이너로 실행할 service 정의
     └── volumes : 컨테이너에 할당할 volume 정의
     └── networks : 컨테이너에 연결할 network 정의
# docker-compose.yaml

x-airflow-common:
  &airflow-common
  image: airflow_custom
    ...
  environment:
    ...
  volumes:
    ...
  user: "${AIRFLOW_UID:-50000}:0"
  depends_on:
    &airflow-common-depends-on
    redis:
      condition: service_healthy
    postgres:
      condition: service_healthy

services:
  postgres:
  image: postgres:13
  ...
        
volumes:
  postgres-db-volume:
  postgres-custom-db-volume:

networks:
  network_custom:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.28.0.0/16
          gateway: 172.28.0.1

 

 

 

2. [x-airflow-common]에 대하여

Extension Fields라고 부르며 컨테이너들에게 공통적으로 적용할 설정을 정의한 부분이다. 명칭 앞에 & 기호를 표시하고 하단에 공통적으로 적용할 내용을 명시하게 된다.

x-airflow-common

 

 

3. [services]에 대하여

컨테이너로 설정할 서비스들을 의미하며 컨테이너에 사용할 이미지 / os 환경변수 / volume / restart 방식 등을 정의할 수 있다. postgres 서비스에 대한 예시를 가지고 세부 내용을 정리해보았다.

services:
  postgres:
    # postgres 13 version 이미지 사용(로컬에 없을 경우 자동으로 다운로드 진행)
    image: postgres:13
    
    # postgres에 설정할 os 환경변수
    environment:
      POSTGRES_USER: airflow
      POSTGRES_PASSWORD: airflow
      POSTGRES_DB: airflow
    
    # 해당 컨테이너와 연결할 로컬 파일 시스템 경로
    # 컨테이너는 재기동시 내부 데이터가 사라짐(휘발성) --> postgres(DB) 데이터가 저장되는 곳을 로컬 데이터와 연결시킴으로써 컨테이너 재기동을 해도 데이터가 남아있게됨 
    volumes:
      - postgres-db-volume:/var/lib/postgresql/data
    
    # 컨테이너 healthcheck
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "airflow"]
      interval: 10s
      retries: 5
      start_period: 5s
      
    # 컨테이너가 죽었을 때 재기동할 시점
    # always --> 컨테이너가 죽으면 항상 재기동하겠음을 의미
    restart: always
    
    # 컨테이너 접속 포트(로컬에서 접속할 포트:서비스가 실제 가지고 있는 포트) --> 외부와 연결할 포트를 맵핑
    # 컨테이너 간에 동일 포트를 가지고 있어도 로컬에서 접속할 포트를 다르게 지정하면 --> 해당 로컬 접속 포트를 통해 컨테이너 접속 가능 
    # (참고) 외부와의 연결없이 내부 컨테이너들 간의 연결을 위해서는 ports 대신 expose를 지정함
    ports:
      - 5431:5432
      
    # 컨테이너 network 정보 
    networks:
      network_custom:
        ipv4_address: 172.28.0.4

services - postgres 설정

 

 

 

4. [volumes & networks]에 대하여

(1) volume이란?

: 컨테이너에 쓰인 데이터는 휘발성으로 컨테이너를 내리면 데이터도 사라지게 된다. 이를 해결하기 위해서 컨테이너의 생명주기와 상관없이 데이터를 영속적으로 저장할 수 있도록 제공하는 기능 중 하나가 volume이다. postgres와 같은 DB의 경우에는 도커 재기동과 상관없이 데이터를 계속 저장할 수 있어야 하며 이러한 상황에 volume을 이용하게 된다.

 

(2) network란?

: 원래 컨테이너는 서로 격리된 환경에서 실행되며 다른 컨테이너들과의 통신이 불가능하다. 이를 해결하기 위해 컨테이너들을 하나의 도커 네트워크로 연결시킴으로써 컨테이너 간의 통신이 가능해지게 된다. 쉽게 생각하면, 서로의 IP주소와 포트를 이용하여 컨테이너 간의 통신이 가능해질 수 있음을 의미한다.

networks:
  # 네트워크이름
  network_custom:
    # 가장 기본이 되는 bridge 방식
    driver: bridge 
    ipam:
      driver: default
      config:
          # 네트워크 성능 개선을 위해 네트워크 IP주소를 그룹(subnet)으로 나누어 관리한다.
          # gateway는 서비스들의 IP, 포트 정보를 알고 있고 gateway를 통해서 서비스 간 통신이 이뤄진다.
        - subnet: 172.28.0.0/16 
          gateway: 172.28.0.1

volumes & networks

 

 

 

 

 

 

처음 docker-compose.yaml 파일을 열어보았을 때는 이게 어떤 내용을 담고 있는지 이해가 잘 되지 않았다. 하지만 최상단 key를 기준으로 내용을 뜯어보니 컨테이너의 어떤 부분을 설정한 것인지에 대해 조금씩 이해할 수 있었다. 이번 시간에는 전반적인 구조를 알아보았고, 다음 시간에는 실제 mariaDB 컨테이너를 올리기 위해 파일을 어떻게 수정해야 하는지에 대해 알아볼 예정이다.

 

 

 

 

 

반응형