HAEJUN RECORDS

Airflow의 Docker Compose 구성

8 min read

Summary

  • Airflow 공식 docker-compose.yaml은 웹서버·스케줄러·워커·DB·큐 등 여러 서비스로 구성된다.
  • 각 서비스 블록은 이미지·볼륨·의존성 설정을 통해 컨테이너 실행 방법을 정의한다.
  • docker compose up -d 후 docker ps로 YAML의 서비스와 실제 컨테이너를 매칭할 수 있다.

들어가며

앞선 노트에서 Docker의 이미지·컨테이너·Compose 개념을 나누어 살펴봤다. 이번에는 Airflow 공식 docker-compose.yaml을 펼쳐 놓고, 각 개념이 실제 구성에서 어떻게 연결되는지 확인한다.

Airflow 공식 Compose 구성

Airflow 공식 문서가 제공하는 Compose 파일은 다음과 같은 서비스로 구성된다.

Airflow Compose 서비스 목록

services:
  postgres:            # 메타데이터 DB
  redis:               # 태스크 큐
  airflow-webserver:   # 웹 UI
  airflow-scheduler:   # DAG 스케줄링
  airflow-worker:      # 실제 태스크 실행
  airflow-triggerer:   # 비동기 트리거 처리
  airflow-init:        # 최초 1회 초기화

각 서비스는 하나의 역할을 맡으며, Compose는 그 설정에 따라 컨테이너를 실행한다. 예를 들어 airflow-webserver는 웹 UI를 제공하고, postgres는 Airflow 메타데이터를 저장한다.

이 구성은 CeleryExecutor 방식을 전제로 한다. 태스크를 여러 워커에 나누어 처리하므로 작업을 전달할 메시지 브로커인 redis와 실제 작업을 처리할 airflow-worker가 필요하다. 소규모로 LocalExecutor를 사용하면 redis와 worker 없이 스케줄러가 직접 태스크를 실행한다.

Airflow 버전에 따라 서비스 이름은 달라질 수 있다. 예를 들어 airflow-webserver가 airflow-api-server로 바뀌거나 airflow-dag-processor가 추가될 수 있으므로, 정확한 목록은 사용 중인 Airflow 버전의 공식 문서에서 확인한다.

Fig 1. Airflow Compose에서 이미지와 컨테이너가 서비스별로 연결되는 구조
Fig 1. Airflow Compose에서 이미지와 컨테이너가 서비스별로 연결되는 구조

서비스별 개념 정리

각 서비스 설정을 앞서 배운 이미지·볼륨·종속성·실행 환경 개념과 연결해 살펴본다.

이미지

서비스는 이미지에서 컨테이너를 만든다. 예를 들어 airflow-scheduler 서비스는 다음 이미지로 실행된다.

Airflow 스케줄러 이미지 설정

airflow-scheduler:
  image: ${AIRFLOW_IMAGE_NAME:-apache/airflow:2.9.0}

airflow-scheduler는 서비스 이름이고, apache/airflow:2.9.0은 컨테이너 실행에 사용하는 이미지다. 같은 이미지라도 Compose 설정에 따라 서로 다른 역할의 컨테이너로 실행할 수 있다. (참고: 이미지와 컨테이너의 관계는 이미지와 컨테이너 실습에서 확인)

볼륨

볼륨은 컨테이너를 삭제하거나 다시 만들어도 데이터를 유지하고, 호스트와 컨테이너 사이에서 파일을 공유할 때 사용한다.

Airflow 디렉터리 연결 설정

volumes:
  - ./dags:/opt/airflow/dags
  - ./logs:/opt/airflow/logs
  - ./config:/opt/airflow/config
  - ./plugins:/opt/airflow/plugins

로컬 프로젝트 폴더의 dags, logs, config, plugins를 컨테이너 내부 경로와 연결한다. 따라서 컨테이너를 다시 만들어도 로컬에 저장된 DAG 코드와 로그를 유지할 수 있다. (참고: 볼륨 연결 방식은 볼륨 연결하기에서 확인)

서비스 종속성

Airflow 서비스는 DB와 메시지 큐에 의존한다. depends_on으로 필요한 서비스의 실행 순서를 선언할 수 있지만, 서비스가 실제로 준비됐는지까지 자동으로 보장하지는 않는다.

Airflow 스케줄러 종속성 설정

airflow-scheduler:
  depends_on:
    postgres:
      condition: service_healthy
    redis:
      condition: service_healthy

이 설정은 postgres와 redis가 정상 상태인 뒤에 airflow-scheduler를 실행하도록 한다. (참고: Compose의 서비스 종속성과 준비 상태는 서비스 종속성과 준비 상태에서 확인)

실행 환경

같은 Compose 파일을 사용하더라도 컨테이너가 실행되는 위치에 따라 Docker 실행 환경은 달라진다.

  • Windows와 Mac: Docker Desktop이 제공하는 WSL2 또는 경량 VM 위에서 실행
  • Linux 서버: Docker Engine 위에서 직접 실행

실행 환경은 다르지만 Compose 파일의 서비스 구성은 같은 방식으로 사용할 수 있다. (참고: Docker Desktop과 Engine의 관계는 Windows와 Mac의 리눅스 계층에서 확인)

실행하고 확인하기

Airflow Compose 실행 및 컨테이너 확인

docker compose up -d
docker ps

먼저 docker compose up -d로 Compose 파일에 정의한 서비스를 백그라운드에서 실행한다. 이어서 docker ps의 NAMES 컬럼에서 airflow-webserver-1, airflow-scheduler-1 같은 컨테이너 이름을 확인한다.

컨테이너 이름의 앞부분은 YAML에 정의한 서비스 이름과 대응한다. 이 과정을 통해 YAML의 서비스 정의가 실제 컨테이너로 실행됐는지 확인할 수 있다.

시리즈 정리

앞선 네 편에서 Docker의 실행 단위와 여러 컨테이너를 관리하는 방법을 단계적으로 살펴봤다. 이 글에서는 그 개념이 Airflow 공식 Compose 구성에서 어떻게 결합되는지 확인했다.

순서주제핵심 내용
1편Docker 기본 개념VM과 컨테이너 비교, 이미지와 컨테이너의 관계
2편Docker Desktop과 EngineEngine의 실행 역할, Desktop과 Linux 실행 환경
3편이미지와 컨테이너 실습pull, run, 볼륨을 활용한 이미지·컨테이너 실습
4편Docker ComposeYAML 파일로 여러 서비스와 실행 설정 관리
5편Airflow 실전Airflow의 Compose 서비스와 실제 컨테이너 연결

Airflow의 docker-compose.yaml을 볼 때 서비스·이미지·볼륨·종속성 설정을 구분해 읽을 수 있다면, 앞서 배운 Docker 개념을 실제 구성에 적용한 것이다.

Reference

Backlinks

Graph View