Airflow

Extras/Provider를 포함한 설치와 업그레이드

extra 의존성이 필요하면 아래처럼 AIRFLOW_VERSION과 PYTHON_VERSION을 조합해 constraint URL을 만들고 한 줄로 설치할 수 있다(예시는 async, postgres, google을 포함):

AIRFLOW_VERSION=<version>
PYTHON_VERSION="$(python -c 'import sys; print(f"{sys.version_info.major}.{sys.version_info.minor}")')"
CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-${PYTHON_VERSION}.txt"
pip install "apache-airflow[async,postgres,google]==${AIRFLOW_VERSION}" --constraint "${CONSTRAINT_URL}"

이 명령은 해당 Airflow 버전이 릴리스된 시점에 사용 가능했던 provider 버전을 설치한다. 이후 새로 릴리스된 provider로 올리려면 constraint 없는 별도 pip 명령이 필요하다.

Airflow를 provider와 '함께' 업그레이드하는 것도 같은 패턴이다 — extras를 포함한 constraint 설치 명령을 원하는 새 버전으로 다시 실행하면 apache-airflow와 그 extras에 해당하는 provider가 모두 그 버전 릴리스 시점에 테스트된 조합으로 갱신된다.

Provider를 core와 분리해서 관리하기

새 기능, 버그 수정, 하위 호환성 유지를 위해 provider를 Airflow core와 독립적으로 설치/업그레이드/다운그레이드해야 할 수 있다. Provider는 Airflow core와 별도로 릴리스되므로, Airflow 본체보다 먼저 새 provider 버전이 나오는 경우가 흔하다. Airflow 본체를 아직 최신으로 올리고 싶지 않아도 새 provider만 개별 설치하고 싶을 수 있다.

이런 개별 설치에는 constraint 파일을 사용하지 않는다. 자동화된 환경 구성이라면 Airflow가 (보통 constraint와 함께) 먼저 설치된 뒤, provider 설치를 별도의 후속 명령으로 실행해야 한다 — constraint는 그것이 사용된 그 pip install 명령에만 효력이 있기 때문이다.

pip install "apache-airflow==<version>" "apache-airflow-providers-google==8.0.0"

이렇게 apache-airflow를 원본 이미지와 동일한 버전으로 함께 명시하면, 충돌하는 의존성을 추가할 때 pip이 apache-airflow 자체를 의도치 않게 올리거나 내리는 것을 막을 수 있다.

주의할 점은, provider의 개별 설치/업그레이드/다운그레이드가 모든 Airflow 버전이나 다른 provider와의 조합에서 항상 동작한다고 보장되지는 않는다는 것이다. Provider마다 요구하는 Airflow 최소 버전이 있고, 의존성 버전 제약이 다른 provider와 충돌할 수 있다. 문서는 실제 사례로 10.1.0 이전 버전의 google provider가 protobuf `<=3.20.0`을 요구했던 반면 google이 지원하는 `google-ads` 라이브러리는 protobuf `>=4`를 요구해 두 의존성을 한 환경에 동시에 설치할 수 없었던 경우를 든다.

Provider 없이 Airflow core만 관리하기

provider를 아예 설치하지 않고 Airflow core만 설치/업그레이드하고 싶다면 별도의 `constraints-no-providers` 파일을 사용할 수 있다. 이 파일은 일반 constraint보다 작고 Airflow core에만 의존성을 한정하지만, 환경에 이미 다른 버전의 의존성이나 다른 provider가 설치되어 있다면 충돌을 일으킬 수 있다. 대신 이 명령은 Airflow core만 기준으로 그 릴리스 시점에 호환되는 최신 의존성 버전을 준다.

CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-no-providers-${PYTHON_VERSION}.txt"
pip install "apache-airflow==${AIRFLOW_VERSION}" --constraint "${CONSTRAINT_URL}"

트러블슈팅: PATH 문제와 macOS setproctitle 심볼 오류

'airflow' 명령이 인식되지 않는 문제는 특히 WSL 환경의 Windows에서 자주 발생한다. 이 경우 `~/.local/bin`이 `PATH` 환경변수에 포함되어 있는지 확인하고, 없으면 `PATH=$PATH:~/.local/bin`으로 추가한다. 또는 `python -m airflow`로 모듈 형태로 직접 실행할 수도 있다.

macOS에서 `Symbol not found: _Py_GetArgcArgv` 오류가 발생한다면 호환되지 않는 Python 빌드를 사용 중이라는 뜻일 수 있다. Homebrew로 설치한 Python의 경우, 흔한 원인은 `/usr/local/opt/bin` 아래의 Python을 쓰고 있어서인데, 이 경로는 실제로는 Frameworks 설치본이 아닌 심볼릭 링크 경로다. 근본 원인은 Airflow가 의존하는 `setproctitle` 라이브러리가 비공개(non-public) Python API를 사용하는데, 이 API가 `/usr/local/opt/`(실제로는 `/usr/local/Cellar`로 심볼릭 링크된) 표준 설치본에서는 제공되지 않기 때문이다.

해결책은 Python 라이브러리의 dylib이 실제로 존재하는 Frameworks 버전의 Python을 사용하는 것이다 (예: `/usr/local/opt/python@3.10/Frameworks/Python.framework/Versions/3.10/bin/python3` 경로로 virtualenv를 생성). Python 공식 웹사이트에서 직접 설치하는 것도 대안이다.