Skip to Content
Data EngineeringAirflow 1.x CLI와 Cloud Composer 명령 실행
📊 Data Engineering2018년 10월 25일

Airflow 1.x CLI와 Cloud Composer 명령 실행

#airflow#data-engineering#cli#gcp#flamingo
Airflow 1.x 설치와 외부 연동2 / 3
Airflow 1.x의 DAG·Task 조회와 실행 명령, Cloud Composer에서 gcloud로 명령과 인자를 전달하는 방식을 함께 정리합니다.
← 이전 글: Airflow 1.x 설치와 LocalExecutor 설정다음 글: Airflow·Cloud Composer API와 외부 연동 플러그인 검토 →

Airflow를 외부 도구에서 조회하고 실행하는 방법을 조사하며 CLI 명령을 정리했습니다. 아래는 당시 Airflow 1.x의 명령 이름입니다. 이후 버전의 명령 구조와는 구분해서 읽어야 합니다.

REST API가 필요한 범위를 제공하는지 확인할 때도 CLI의 동작은 비교 기준이 됐습니다. 다만 CLI 출력은 텍스트이므로 외부 서비스에서 사용하려면 결과 형식과 오류를 함께 처리해야 합니다.

DAG와 Task 조회

명령용도
airflow list_dags [-r]DAG 목록, -r로 DagBag 보고서 출력
airflow list_tasks {dag_id}DAG의 Task 목록
airflow dag_state {dag_id} {execution_date}지정 시점 DAG 실행 상태
airflow task_state {dag_id} {task_id} {execution_date}지정 Task Instance 상태

DAG와 Task 정의를 조회하는 것과 특정 실행의 상태를 조회하는 것은 다릅니다. 상태 명령에서는 실행 시점도 함께 지정합니다.

실행과 스케줄 관리

명령용도
airflow trigger_dag {dag_id}DAG 수동 실행 요청
airflow pause {dag_id}스케줄링 일시 정지
airflow unpause {dag_id}스케줄링 재개
airflow run {dag_id} {task_id} {execution_date}단일 Task Instance 실행
airflow test {dag_id} {task_id} {execution_date}Task 테스트 실행
airflow delete_dag {dag_id}해당 DAG의 메타데이터 DB 기록 삭제

test는 Task 코드를 실행하는 명령입니다. 외부 작업에 아무 영향도 없는 모의 실행으로 해석해서는 안 됩니다. delete_dag도 DAG 파일을 편집하는 명령이 아니라 관련 DB 기록을 지우는 동작입니다.

Cloud Composer의 인자 전달

Cloud Composer에서는 gcloud composer environments run을 통해 명령을 전달했습니다. 다음은 환경 이름을 예시로 바꾼 당시 명령입니다.

bash
gcloud composer environments run example-composer \
  --location us-central1 \
  list_dags -- -r

-- 앞은 gcloud의 옵션이고 뒤는 Airflow 명령에 전달할 인자입니다. 위 예시의 -r은 gcloud 옵션이 아니라 list_dags의 report 옵션입니다.

아래에서는 로컬 명령과 Composer 호출을 비교해 인자를 구분합니다. API를 조사한 내용은 Airflow와 Composer API 지원 범위에 정리했습니다.

로컬 명령과 Composer 인자 비교

Cloud Composer에서 Airflow CLI를 호출하는 방법을 조사하며 정리한 기록입니다. 로컬의 airflow 명령을 그대로 실행하는 대신 gcloud composer environments run에 환경과 리전을 지정하고 Airflow 하위 명령을 전달했습니다.

예시는 당시 Airflow 1.x의 list_dags 명령 기준입니다. Composer 이미지의 Airflow 버전이 바뀌면 하위 명령 이름과 사용 가능한 옵션도 확인해야 합니다.

gcloud와 Airflow 인자 구분

로컬에서는 다음 명령으로 DAG 보고서를 조회합니다.

bash
airflow list_dags -r

Composer에서는 아래처럼 전달했습니다. 환경 이름은 예시입니다.

bash
gcloud composer environments run example-composer \
  --location us-central1 \
  list_dags \
  -- -r

example-composer와 --location은 실행할 Composer 환경을 정합니다. list_dags는 Airflow 하위 명령이고, -- 뒤의 -r은 그 명령에 전달할 인자입니다.

인자를 잘못 나누면 Airflow에 전달하려던 옵션을 gcloud가 해석할 수 있습니다. 명령 이름뿐 아니라 어느 프로그램이 각 인자를 받는지 구분하는 것이 필요했습니다.

환경 상태와 작업 상태

Composer 환경이 실행 중인 것과 DAG가 정상으로 실행된 것은 다릅니다. 환경 조회는 Composer API에서, DAG와 Task 확인은 해당 Airflow의 API나 CLI에서 다루는 구조로 봤습니다.

위의 조회·실행 명령을 Composer에서 사용할 때도 관리형 환경과 Airflow 작업의 상태를 구분해야 했습니다.

당시 조사 범위

이 기록에는 gcloud 호출 예시와 필요한 CLI 목록이 남아 있습니다. 모든 Oozie 파이프라인을 Composer로 이관했다거나 마이그레이션 효과를 측정한 결과는 아닙니다.

관리형 서비스를 사용해도 개별 작업의 정의와 실행 상태는 따로 확인해야 했습니다. Composer 환경을 제어하는 API와 Airflow 명령을 나눠 조사한 이유입니다.

참고 자료

Last updated on