Skip to Content
Data EngineeringAirflow 1.x 설치와 LocalExecutor 설정
📊 Data Engineering2018년 12월 17일

Airflow 1.x 설치와 LocalExecutor 설정

#airflow#data-engineering#architecture#security#centos
Airflow 1.x 설치와 외부 연동1 / 3
CentOS 7에서 Airflow 1.x를 설치하고 LocalExecutor와 메타데이터 DB, 서비스 실행, 기존 웹 UI 인증을 설정한 기록입니다.
다음 글: Airflow 1.x CLI와 Cloud Composer 명령 실행 →

Airflow를 설치하면서 정리한 환경과 실행 설정입니다. 당시에는 CentOS 7과 Python 3.6을 사용했고, 테스트용 SequentialExecutor에서 LocalExecutor와 별도 메타데이터 DB를 사용하는 구성을 준비했습니다.

이 글의 명령은 과거 Airflow 1.x 작업 기록입니다. 설치 패키지와 설정 경로, 인증 방식은 해당 버전을 기준으로 읽어야 합니다.

Python과 Airflow 설치

당시에는 IUS 저장소에서 Python 3.6 패키지를 설치했습니다. 아래는 원문에 남아 있는 명령입니다.

bash
sudo yum install -y https://centos7.iuscommunity.org/ius-release.rpm
sudo yum search python3
sudo yum install -y python36u python36u-libs python36u-devel python36u-pip
sudo pip3.6 install --upgrade pip
pip3.6 install apache-airflow

Python 3.6은 당시 선택한 환경입니다. 모든 Airflow 1.x가 Python 3만 요구했다는 뜻은 아닙니다. 설치할 때는 필요한 연동과 Executor에 맞는 추가 패키지도 함께 준비했습니다.

Executor와 메타데이터 DB

기본 구성은 SQLite와 SequentialExecutor였습니다. 한 번에 하나의 Task만 실행하므로 병렬 작업을 위해서는 실행기와 DB 구성을 바꿔야 했습니다.

Executor구성과 역할
SequentialExecutorTask를 순차 실행하는 초기 테스트 구성
LocalExecutor스케줄러가 있는 호스트에서 여러 프로세스로 실행, 별도 브로커 불필요
CeleryExecutor브로커와 워커를 사용해 여러 호스트로 실행 분산

당시 기록에서는 LocalExecutor를 사용했습니다. 메타데이터 DB는 PostgreSQL을 선택했습니다. MySQL 연결에서 UTF-8 관련 문제를 겪었던 것이 선택 이유 중 하나였습니다. 모든 환경에서 한 DB가 우수하다는 비교 결과는 아닙니다.

연결 설정의 형태는 다음과 같습니다. 주소와 계정은 예시입니다.

ini
[core]
executor = LocalExecutor
sql_alchemy_conn = postgresql+psycopg2://airflow:password@db.example.internal:5432/airflow

초기화와 서비스 실행

서비스를 시작하기 전 AIRFLOW_HOME을 지정하고 DB를 초기화했습니다.

bash
export AIRFLOW_HOME=~/airflow
airflow initdb

웹 서버와 스케줄러는 별도 프로세스입니다. 직접 실행할 때의 명령은 다음과 같습니다.

bash
airflow webserver -p 8080
airflow scheduler

systemd 유닛을 준비한 뒤에는 서비스로 실행했습니다. 다음 명령만으로 유닛 파일이 생성되는 것은 아닙니다.

bash
systemctl start airflow-webserver.service
systemctl start airflow-scheduler.service

서비스 환경에도 AIRFLOW_HOME을 지정해야 터미널과 같은 설정을 사용합니다. 당시에는 로그를 확인할 때 systemd 상태와 journal도 함께 봤습니다.

bash
systemctl status airflow-webserver.service
journalctl -u airflow-webserver -f

기존 웹 UI의 비밀번호 인증

당시에는 Flask-Admin 기반 웹 UI의 password_auth를 사용했습니다. FAB 기반 RBAC과는 설정 방법이 다릅니다.

ini
[webserver]
authenticate = True
auth_backend = airflow.contrib.auth.backends.password_auth

계정 생성은 당시 모델과 세션으로 처리했습니다. 아래는 계정 정보를 예시로 바꾸고 비밀번호를 입력받도록 정리한 코드입니다.

python
from getpass import getpass
from airflow import models, settings
from airflow.contrib.auth.backends.password_auth import PasswordUser
 
user = PasswordUser(models.User())
user.username = "admin"
user.email = "admin@example.com"
user.password = getpass("Password: ")
 
session = settings.Session()
try:
    session.add(user)
    session.commit()
finally:
    session.close()

공식 1.10.2 문서도 이 예제를 Flask-Admin용으로 구분하고, FAB 기반 RBAC은 별도 계정 생성 방식을 안내합니다. 웹 UI 인증과 API 인증도 따로 설정하므로 로그인 화면만 확인하고 외부 제어 경로까지 보호됐다고 판단할 수는 없습니다.

참고 자료

Last updated on