Airflow 공식 Docker 이미지를 사용하는 서버로 onGCP 구축
Airflow 배경 사용
당사(주식회사 unerry)는 다른 회사와 데이터 인수인계를 진행하고 있습니다.
이러한 협업이 시작된 당초 다른 사건마다 마이크로의 실례 서버를 구축하고 클라우드 펀션+클라우드 Schedule을 사용했다.
그러나 사건이 늘어날 때 문제가 되는 것은 고장 등으로 데이터가 지연돼 제공되지 않을 경우 개별 시행상황에 따라 각 매뉴얼에 대량 재집행하는 데 시간이 걸린다는 점이다.
Airflow는 excution입니다.날짜라는 개념이 있어서 과거의 업무의 재집행은 쉽다.1
또 DAG의 일람표로 여러 작업을 관리할 수 있어 기쁘다는 점이 도입의 계기가 됐다.
이런 느낌이에요.2
GCP에는 경영진의 Cloud Composier가 있습니다.
네, 그런데 이거 비싸요.도쿄 지역이라면 작은 구성이라도 한 달에 500달러 정도가 든다.
당사는 데이터 협업 이외에도 정기적으로 비교적 무거운 분석 처리3를 진행하지만 R언어나 조개껍질을 사용한다면 반드시 파이톤으로 처리하는 것은 아닙니다.관리 임무를 수행할 수 있으면 좋겠기에 GCE에 에어플로우를 만들어 사용했다.4
기본적으로 파이썬 처리이고 에어플로우를 병렬 처리한 후 CPU를 사용한다.이 경우 Cloud Composier도 선택 항목으로 나열됩니다.5
GCP에서 사용되는 리소스
HTTPS용
에어플로우의 Docker 이미지의 사용자 정의, Container-optimized OS의cloud-init, 데이터베이스 초기화.다른 특별한 일이 없기 때문에, 사랑을 끊는다.
Airflow의 Docker 이미지 사용자 정의
공식 이미지에 따라 조작할 수 있지만 실제 적용에는 다음과 같은 내용이 추가됐다.
Clean-logs.sh를 포함하지만 빈 디렉터리를 삭제할 수 없습니다 6
FROM apache/airflow:2.2.2
USER root
RUN echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" > /etc/apt/sources.list.d/google-cloud-sdk.list && \
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key --keyring /usr/share/keyrings/cloud.google.gpg add - && \
apt-get update && \
apt-get install -y google-cloud-sdk
COPY --chown=airflow:root custom-clean-logs.sh /custom-clean-logs
RUN chmod a+x /custom-clean-logs
USER airflow
custom-clean-logs.sh#!/usr/bin/env bash
set -euo pipefail
readonly DIRECTORY="${AIRFLOW_HOME:-/usr/local/airflow}"
readonly RETENTION="${AIRFLOW__LOG_RETENTION_DAYS:-15}"
trap "exit" INT TERM
readonly EVERY=$((15*60))
echo "Cleaning logs every $EVERY seconds"
while true; do
echo "Trimming airflow logs to ${RETENTION} days."
find "${DIRECTORY}"/logs \
-type d -name 'lost+found' -prune -o \
-type f -mtime +"${RETENTION}" -name '*.log' -print0 | \
xargs -0 rm -f
# 公式のclean-logs.shにこれを足しています
echo "Delete empty directories."
find "${DIRECTORY}"/logs -type d -empty -delete
seconds=$(( $(date -u +%s) % EVERY))
(( seconds < 1 )) || sleep $((EVERY - seconds))
done
Container-Optimzed OS용 cloud-initcloud-init.yml의 내용을 VM 실례가 만들어졌을 때의 사용자 정의 메타데이터에 키
user-data
의 값으로 붙여넣습니다.다음은 자사 데이터 협업 에어플로우의 설정 내용이다.7 #cloud-config
# AirflowのDockerイメージがairflowユーザーで動作するためホスト側もairflowユーザーを作成します
users:
- name: airflow
write_files:
# Airflow起動時の環境変数ファイル
- path: /var/airflow/env
content: |
AIRFLOW_HOME=/var/airflow
AIRFLOW__CORE__SQL_ALCHEMY_CONN=mysql+mysqldb://dbuser:dbpassword@cloud_sql_proxy:3306/dbname
AIRFLOW__CORE__EXECUTOR=LocalExecutor
AIRFLOW__CORE__PARALLELISM=4
AIRFLOW__WEBSERVER__BASE_URL=
AIRFLOW__WEBSERVER__WORKERS=2
AIRFLOW__WEBSERVER__ENABLE_PROXY_FIX=True
owner: airflow:airflow
# AIRFLOW_HOME: DAGやログなどの配置場所になります。お好みで。
# AIRFLOW__CORE__SQL_ALCHEMY_CONN: データベースの接続設定です。
# AIRFLOW__CORE__EXECUTOR: 一台構成かつ並列実行したいのでLocalExecutorを指定します。
# AIRFLOW__CORE__PARALLELISM: 並列数はマシンスペックと相談で。デフォルトの32で低スペックマシンだとメモリ不足で死にます。
# AIRFLOW__WEBSERVER__BASE_URL: デフォルトはhttp://localhost:8080なのですが、空にしておかないとタスクのログが見れません。
# AIRFLOW__WEBSERVER__WORKERS: デフォルトは4ですが、そんなに必要ないと思うのでケチってます。
# AIRFLOW__WEBSERVER__ENABLE_PROXY_FIX: ロードバランサ用の設定です。
# systemd のユニットファイル - Cloud SQL Proxy
- path: /etc/systemd/system/cloud_sql_proxy.service
content: |
[Unit]
Description=Cloud SQL Proxy daemon
After=network.target
[Service]
ExecStart=/usr/bin/docker run --name=cloud_sql_proxy --rm --net=db gcr.io/cloudsql-docker/gce-proxy:latest /cloud_sql_proxy -instances=abechan-no-project-id:asia-northeast1:airflow=tcp:0.0.0.0:3306
ExecStop=/usr/bin/docker stop cloud_sql_proxy
Restart=on-failure
# systemd のユニットファイル - Airflow WebServer
- path: /etc/systemd/system/airflow-webserver.service
content: |
[Unit]
Description=Airflow webserver daemon
After=network.target
[Service]
Environment="HOME=/home/airflow"
ExecStartPre=/usr/bin/docker-credential-gcr configure-docker
ExecStart=/usr/bin/docker run --name=airflow-server --rm --net=db -p 80:8080 --env-file=/var/airflow/env -v /var/airflow:/var/airflow gcr.io/abechan-no-project-id/airflow-custom:2.2.2 airflow webserver
ExecStop=/usr/bin/docker stop airflow-server
Restart=on-failure
# systemd のユニットファイル - Airflow Scheduler
- path: /etc/systemd/system/airflow-scheduler.service
content: |
[Unit]
Description=Airflow scheduler daemon
After=network.target
[Service]
Environment="HOME=/home/airflow"
ExecStartPre=/usr/bin/docker-credential-gcr configure-docker
ExecStart=/usr/bin/docker run --name=airflow-scheduler --rm --net=db --env-file=/var/airflow/env -v /var/airflow:/var/airflow gcr.io/abechan-no-project-id/airflow-custom:2.2.2 airflow scheduler
ExecStop=/usr/bin/docker stop airflow-scheduler
Restart=on-failure
# systemd のユニットファイル - Airflow のログ削除シェル
- path: /etc/systemd/system/airflow-clean-logs.service
content: |
[Unit]
Description=Airflow clean-logs daemon
After=network.target
[Service]
Environment="HOME=/home/airflow"
ExecStartPre=/usr/bin/docker-credential-gcr configure-docker
ExecStart=/usr/bin/docker run --name=airflow-clean-logs --rm --env-file=/var/airflow/env -v /var/airflow:/var/airflow gcr.io/abechan-no-project-id/airflow-custom:2.2.2 bash /custom-clean-logs
ExecStop=/usr/bin/docker stop airflow-clean-logs
Restart=on-failure
runcmd:
- mkdir -p /var/airflow/scripts # BashOperatorから叩きたいシェルの置き場所
- mkdir -p /var/airflow/dags # DAGのディレクトリ
- mkdir -p /var/airflow/logs # ログのディレクトリ
- usermod -u 50000 airflow # コンテナからホスト側ボリュームを見た時にパーミッションエラーになるので、AirflowのDockerイメージのユーザーIDにあわせています
- groupmod -g 50000 airflow # ↑と同じ理由でグループID
- chown -R airflow:airflow /var/airflow/
- docker images -aq | xargs docker rmi # インスタンスを再起動した時に最新のイメージ(キャッシュされたものではなく)を取得したいのでインスタンス起動時に削除しています
# => こうしておくとDockerイメージのタグをlatestなどで固定していてもインスタンスの再起動で更新を反映できます
- docker network create -d bridge db # AirflowのコンテナからCloud SQL Proxyのコンテナに接続するためのブリッジ
- systemctl daemon-reload # 以下、systemd関連
- systemctl start cloud_sql_proxy.service
- systemctl start airflow-webserver.service
- systemctl start airflow-scheduler.service
- systemctl start airflow-clean-logs.service
데이터베이스 초기화Container-Optimzed OS의 VM 인스턴스에 로그인한 후 bash 셸에서 Airflow 이미지를 시작합니다.
docker run -it --rm --net=db --env-file=/var/airflow/env -v /var/airflow:/var/airflow gcr.io/abechan-no-project-id/airflow-custom:2.2.2 bash
Airflow 컨테이너에서 데이터베이스를 초기화하고 관리자 사용자 만들기
airflow db init
airflow users create -u abechan -p password -r Admin -e mail@address -f firstname-is-secret -l lastname-is-abechan
처음엔 에어플로우의 취미를 기르기 어렵다고 생각했지만, 습관의 문제 때문에 지금 없어서는 안 될 도구로 편리하다.소량의 관리가 힘들다는 고민이 많으신 분들은 도입을 고려해 봐도 될까요?
파이톤에 리눅스에 직접 설치할 수 있지만 Docker 이미지는 환경 변수를 통해 다양한 제어를 할 수 있어 쉽게 구축할 수 있어 추천합니다.
취미가 강하다↩
데이터 협업을 위한 에어플로우이며, 이 외에 배치 처리를 분석하는 에어플로우↩가 한 대 더 있다.
이러한 분석 처리에서 Airflow에서 규격을 높이는 VM 실례를 일시적으로 구축하고 처리가 끝난 후 실례를 삭제한다↩
Airflow에서 수행되는 로트는 주로 Cloud Function/Cloud Run/자주 실행되는 VM 인스턴스+SSH 원격 실행 등을 통해 처리↩
실제로 Cloud Composier를 사용하는 곳도 있습니다(자세한 내용은 비밀로 해주세요)↩
운용 후 디스크 사용량이 조금씩 증가하는 현상을 만났다↩
문장은 일부 정보의 마스크와 낡은 부분의 최신화↩를 사용했다
Reference
이 문제에 관하여(Airflow 공식 Docker 이미지를 사용하는 서버로 onGCP 구축), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/abechan0212/items/80889eb16a5453b701c8텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)