작성
·
275
·
수정됨
0
구글링해보면 Airflow가 전체적으로 2.X 지원을 준비하는 것 같긴 합니다만,
docker-compose로 airflow 2.8.4 docker를 설치하면
SQLAlchemy가 1.4.X가 설치되는 것 같습니다.
저희가 만든 Dags는 내부에 SQLAlchemdy 2.X를 사용해서 DB 접근을 하는 코드가 있는데
Airflow에 SQLAlchemy 2.X를 설치해서 쓰는 방법이 있을까요?
예를 들면, dags를 실행하는 Airflow-worker에 SQLAlchemy 최신 버전을 pip install로 설치한다던지요..
또는 기본 Base가 되는 이미지에 2.X로 업그레이드 시키거나, worker에 2.X를 설치할 때 Airflow의 기존 로직들은 이상이 없을지요?
아니면, 아래처럼 virtual env 방식으로 SQLAlchemy를 설치하는 식으로 사용해야 할까요?
@task.virtualenv(
task_id="virtualenv_python", requirements=["SQLAlchemy==2.0.0"], system_site_packages=False
)
일반적으로 사용하는 방법에 대해 궁금합니다.
감사합니다.
답변 1
0
안녕하세요 강운천님!
Airflow 설치시 requirements.txt 를 통해 의존성을 관리할 수 있습니다.
아래 url (installing from PyPi) 에 들어가보세요.
https://airflow.apache.org/docs/apache-airflow/stable/installation/installing-from-pypi.html
그러면 아래처럼 airflow 설치할 때 --constraint 옵션을 통해 의존성 관리할 수 있고
pip install "apache-airflow[celery]==2.8.4" --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.8.4/constraints-3.8.txt"
https 로 시작하는 부분을 들어가보면 패키지별로 버전이 다 명시되어 있습니다.
따라서 원한다면 저 부분을 복사한 후 WSL 내 디렉토리에 requirements.txt 로 만들어놓고 SQLAlchemy 부분을 원하시는 버전으로 수정 후 파일을 바라보고 설치하게끔 시도해볼 수 있습니다.
--constraints requirements.txt
그러나!
아마도 설치 도중 의존성 문제가 발생할 겁니다.
그래서 airflow 설치는 일단 그대로 하시고 운찬님이 쓴대로 @task.virtualenv 데코레이터를 쓰시는게 가장 좋은 해결방안 같습니다. @task.virtualenv 는 PythonVirtualOperator 를 사용할 수 있게끔 해주는 건데, PythonVirtualOperator보다 데코레이터 사용을 권장합니다. (PythonVirtualOperator는 파이썬 가상환경을 만든 후 실행, 완료 후 삭제하는 오퍼레이터입니다)
그래서 결론은 운찬님이 쓰신대로 @task.virtualenv 를 쓰시는게 가장 적합해 보입니다.
혹시 virtualenv 를 사용해서 기능 구현하는게 어려운 상황이신가요?
어떤 상황인지 알려주시면 저도 같이 고민해보겠습니다. ^^
혹시 이미 custom operator를 만들었고, 큰 기능 변경없이 SQLalchemy 2.x 로 실행하고자 하는 상황이신가요?
말씀하신 방법을 알아보는데 virtualenv를 쓰려면 해당 함수 내에 모든 기능 구현을 해야하는 것처럼 보이네요.
requirement에 등록하는 설치형태가 아닌 다른 모듈(예: src.common.databases)은 import가 안되네요.
Worker docker만 Alchemy 2.0을 설치해보는 방법도 검토해보고 있는데 쉽지 않네요.
(플라스크가 1.4를 요구하네요)