黑皮考町

如何重跑 Cloud Composer 上的任務 Retry Cloud Composer Task  想要重跑 Cloud Composer 上的任務可以透過 Airflow Cli 來清除任務狀態, 迫使 Airflow 重新排程這個任務 清除指令, 如下 airflow tasks clear -s ${EXECUTION_DATE} -t ${TASK_ID} -d -y ${DAG_ID}   註：EXECUTION_DATE 的格式是以 ISO-8601 來表示, 所以會長這樣 "2022-07-26T00:00:00+00:00" 由於 Cloud Composer 會將 Airflow 部署在 GKE 上, 若要執行上面的指令, 必須 1. 取得 GKE 得 crendential 2. 找到 Airflow 管理工具的 Pod 執行 Airflow 指令 另一個方法是 使用 gcloud composer 來將指令傳給 Airflow  EXECUTION_DATE ="2022-07-26T00:00:00+00:00" DAG_ID="sysops-daily-backup" TASK_ID ="^result_chk$" gcloud composer environments run \ --location="us-central1" \ --project="stage" sysops tasks clear -- {DAG_ID} -s {EXECUTION_DATE}  -t {TASK_ID} -y -d  -d 是連下游任務的狀態都清除 方法二：在 AirFlow DAG 中使用 retry 機制來清除上游任務的狀態 def clear_upstream_task(context):     execution_date = context.get("execution_date")     clear_tasks = BashOperator(         task_id='clear_tasks',         bash_command=f'airflow

  如何在 GKE 上部署  Gitlab Runner (使用 Helm) 並整合 Workload Identity Gitlab Runner + Helm + workload Identity to deploy Application on GKE 建立 Service Account 給 Gitlab Runner 使用 如果想讓 Gitlab Runner 可以在 GCP  上部署任何應用程式,  必須給他一組有特定權限的 Service Account Gitlab Runner 要使用這個 Service Account, 比較 Hardcore 一點的做法是, 直接下載 Service Account 的 Credential,  再透過 gcloud 指令拿 Credential 去做認證 gcloud auth activate-service-account $SERVICE_ACCOUNT_EMAIL \     --key-file=$CRED  \     --project=$PROJECT    這個做法的缺點是, 需要煩惱如何安全地保管 Credential  比較安全一點的做法是 透過 GKE Workload Identity 將 GKE 裡的 Service Account 與 GCP 上的 Service Account 連結在一起 假設 Gitlab Runner 架構規劃如下: 在 GCP 上總共有三個 Project (cicd/dev/prod), cicd 的 Project 裡有一座 GKE 用來跑 Gitlab Runner, Runner 會將應用程式部署到 dev, 以及 prod 的 App Engine 上 要實現以上的架構 首先 Step 1. 建立 Google Service Account  # Parameters KSA_NAME="gitlab-runner-pd" RUNNER_GSA_PROJECT="cicd" NAMESPACE="gitlab" RUNNER_NAME="gitlab-runner-pd" TOKEN="eZH45H6uQAy1hRLLHksU" gcloud

如何讓在 Airflow 上跑的任務使用 GPU 資源 Step 1. 在既有的 Airflow 下新增有 GPU 的 Pool 使用參數 --accelerator 指定 GPU 的規格 gcloud beta container   node-pools create "gpu-pool" \ --cluster "mlworkflow-24aeef46-gke" \ --zone "us-east1-b" \ --machine-type "n1-standard-4" \ --accelerator "type=nvidia-tesla-p100,count=1" \ --image-type "COS_CONTAINERD" \ --num-nodes "3"  Step 2. 測試 GPU 的功能是否正常 部署一個 Pod 來跑 nvidia-smi 指令 注意: GCP 在建立 GPU 的 Pool 時會自動加上 Taint 資訊如下  spec:   taints:   - effect: NoSchedule     key: nvidia.com/gpu     value: present Pod  的 deployment 要加上 Tolerations cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata:   labels:     run: mig-none-example   name: mig-none-example spec:   tolerations:   - key: "nvidia.com/gpu"     operator: "Exists"     effect: "NoSchedule"   containers:   - image: nvidia/cuda:11.0-base     name: mig-none-example     resources:       limits:         nvidia.com/