GKE上にAirflowを構築する
概要
TerraformとHelmを使用して、gcloudコマンドやkubectlコマンドを使わずに、Rodel van Rooijen氏のMediumの記事に沿ってGKE上にAirflowクラスタを作成します。
TerraformとHelmのコードは下記のGitHubリポジトリに置いてます。
元の記事とは異なる点がいくつかあるので、ご注意ください。
- Airflow Web UIはインターネットに公開されます。
- KubernetesのPersistent Volumeを手動で作成 (
kubectl apply) する必要はありません。KubernetesのPersistent Volume ClaimによってCompute Diskが自動的に作成されます。詳細はPersistent volumes and dynamic provisioning(永続ボリュームと動的プロビジョニング)を参照してください。 - ログはPodのライフサイクル中のみ利用可能です。ログを永続化したい場合は、Airflow Helm: Manage logs(Airflow Helm:ログの管理)を参照してください。
- Compute Engine DiskはDAGファイルの管理には使用されません。DAGファイルを効率的に管理したい場合は、Airflow Helm: Manage DAGs files(Airflow Helm:DAGファイルの管理)を参照してください。
terraform applyの前に準備すること
terraform applyするには、以下のコマンドラインツールを準備する必要があります。
- gcloud
- docker
- kubectl
- helm
また、下記の点にご注意ください。
- Terraformのコードは、GKEの認証情報を上書きするために
~/.kubeディレクトリを削除します。必要であれば、事前に~/.kubeディレクトリをバックアップしてください。 - Terraformの適用前にGCPプロジェクトが作成済みであり、必要なGCP APIがすべて有効になっている必要があります。
注意事項
下記の点において本番環境レベルのコードではありません。
- デフォルトのVPCネットワークは、カスタムVPCに置き換えるべきです。
- Cloud SQLのパスワードは、Terraformの変数ではなく、Secret Managerなどのより安全な方法で管理すべきです。
- Terraformのstateファイルは、ローカル環境ではなく、GCS (Google Cloud Storage) に保存すべきです。
- Git-syncを使ったDAGファイルの管理の方が便利です。
- ログはPodのライフサイクル中のみ利用可能です。
このAirflow環境は、DAGの開発などに利用できるとは思います。
ハマったところ
Airflow Helm chartには2つの種類があります。公式Helm chartとコミュニティ版です。
それを理解してない状態で調べたので、色々とごちゃごちゃに理解してしまい、時間がかかってしまいました。
このリポジトリでは公式Helm chartを使用してます。
気づき
開発中に気づいたことのメモ。
- Compute Engine DiskはPVC (Persistent Volume Claim) のReadWriteManyアクセスモードをサポートしてない。
standards-rwoStorage Classは、PVC作成直後にCompute Engine Diskを作成しない。
参考資料
Deploying Airflow on GKE using Helm
Workload Identity in GKE with Terraform
Dynamic Provisioning and Storage Classes in Kubernetes
Persistent volumes and dynamic provisioning
Apache Airflow ETL in Google Cloud
Alternative: link Kubernetes ServiceAccounts to IAM
Deploying Airflow on Google Kubernetes Engine with Helm
Deploying Airflow on Google Kubernetes Engine with Helm — Part Two