본문으로 건너뛰기
cccskills
무료GitHub에 공개

managed-airflow-migrations

Provides guidance for migrating Apache Airflow DAGs in Managed Service for Apache Airflow (MSAA; formerly Cloud Composer). Covers migration to Airflow 2.11.1 (MSAA Gen 2 and 3) and Airflow 3 (MSAA Gen 3), including environment inspection, GCS download/upload and scanning patterns for breaking changes. Use when migrating the DAG code to newer Airflow version. Don't use when checking DAG run failures unrelated to code migration.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

연동 도구Google Cloud
설치 방법 보기

포함된 파일(4)

  • SKILL.md11.6 KB
  • references/airflow-3.md8.0 KB
  • references/environment-inspection.md2.9 KB
  • references/local-development-environment.md919 B

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Managed Service for Apache Airflow (formerly Cloud Composer) Migration Guide

This skill guides you through the process of adjusting Airflow DAGs from an existing Managed Service for Apache Airflow (formerly Cloud Composer) environment (or available locally) to make them compatible with Airflow 2.11.1 (MSAA Gen 2 or 3) or Airflow 3 (MSAA Gen 3).


Phase 1: Discovery & Download

Before making any changes, download the existing DAG files if explicitly requested. Inspect the source environment to confirm source version only if explicitly requested. For detailed instructions about environment inspection and downloading files check references/environment-inspection.md.


Phase 2: Target Version & Dependency Mapping

2.1 Airflow 2.11.1+ Dependency Mapping

If migrating to Airflow 2.11.1 (MSAA Gen 2) or Airflow 3, use the list below to trace the version progression of key dependencies. The list covers changes needed to get to Airflow 2.11.1. Take them into account when migrating from Airflow 2 (earlier than 2.11.1) to Airflow 3.

Composer 2.10.0 (Airflow 2.10.2)

  • Google Provider: 10.26.0
  • SSH Provider: 3.14.0
  • HTTP Provider: 4.13.3
  • Breaking Changes: Baseline for oldest fully documented source.

Composer 2.15.3 (Airflow 2.10.5)

  • Google Provider: 18.0.0
  • SSH Provider: 4.1.4
  • HTTP Provider: 5.3.4
  • Breaking Changes:
    • SSH Provider 4.0.0: Hook timeout removed; get_conn() context manager.
    • HTTP Provider 5.0.0: SimpleHttpOperator -> HttpOperator.
    • Google Provider 11.0.0: BigQueryExecuteQueryOperator removed.
    • Google Provider 12.0.0: Legacy Data Pipeline operators removed.
    • Google Provider 13.0.0: AutoMLBatchPredictOperator removed.
    • Google Provider 17.0.0: BigQueryCreateEmptyTableOperator and BigQueryCreateExternalTableOperator removed; Life Sciences operators removed.
    • Google Provider 18.0.0: Legacy DV360 operators removed.

Composer 2.16.1 (Airflow 2.10.5)

  • Google Provider: 19.0.0
  • SSH Provider: 4.1.6
  • HTTP Provider: 5.5.0
  • Breaking Changes: Google Provider 19.0.0: AutoML operators removed (use Vertex AI).

Composer 2.17.0 (Target Airflow 2.11.1)

  • Google Provider: 20.0.0
  • SSH Provider: 5.0.0
  • HTTP Provider: 6.0.2
  • Breaking Changes:
    • SSH Provider 5.0.0: sshtunnel removed (native tunneling).
    • HTTP Provider 6.0.0: JSON serialization.
    • Google Provider 20.0.0: ADLS Gen2 migration.

2.2 Airflow 3 Migration

If migrating to Airflow 3 (MSAA Gen 3), note that this is a major version upgrade with significant changes, including:

  • Decoupled Task SDK (imports change from airflow to airflow.sdk).
  • Removal of direct metadata DB access.
  • Renaming of Dataset to Asset.
  • Removal of SubDAGs and SLAs.
  • Changes to context variables availability.

Take into account all applicable changes within Airflow 2 (e.g. when migrating from Airflow 2.10.2, apply changes needed to move to Airflow 2.11.1 and Airflow 3 migration changes on top of that).


Phase 3: Analysis & Remediation (Scanning Downloaded Files)

Run the scan commands from the root of your local workspace (./migration_workspace unless indicated otherwise).


3.1 Airflow 2.11.1 Core & Dependency checks

Use these scans if migrating to Airflow 2.11.1+ (intermediate step when migrating to Airflow 3).

3.1.1 Dataset Scheduling (Airflow 2.11.0)

  • Change: DAGs scheduled on datasets only trigger if events occur while the DAG is unpaused.
  • Scan Command: grep -rn "Dataset(" ./dags
  • Remediation: You MUST document that these DAGs must remain unpaused to catch events, or plan manual triggers for catch-up.

3.1.2 HTML in Descriptions (Airflow 2.11.0)

  • Change: Raw HTML in DAG docs / params is escaped by default.

  • Scan Command:

    grep -rn -E "doc_md.*<|doc_md.*>|description.*<|description.*>" ./dags
    
  • Remediation: Convert HTML to Markdown, or set AIRFLOW__WEBSERVER__ALLOW_RAW_HTML_DESCRIPTIONS=True in target.

3.1.3 Teardown Tasks (Airflow 2.10.5)

  • Change: Teardowns always run when a DAG is marked failed.
  • Scan Command: grep -rn "as_teardown" ./dags
  • Remediation: Ensure teardown tasks are idempotent.

3.1.4 Pendulum 3 Upgrade (Airflow 2.11.0)

  • Change: Period renamed to Interval, testing helpers removed.

  • Scan Command (Code):

    grep -rn -E "pendulum\.Period|pendulum\.period" ./dags
    
  • Scan Command (Tests):

    grep -rn -E "\.test\(|set_test_now\(" ./tests 2>/dev/null || true
    
  • Remediation: Replace Period with Interval, and period(...) with interval(...).


3.2 Path A: Airflow 2.11.1 Provider Package Scan

3.2.1 SSH Provider (SSH 4.0.0 & 5.0.0)

  • Scan Command (Timeout): grep -rn "SSHHook" ./dags | grep "timeout"
  • Scan Command (Context Manager): grep -rn "with SSHHook" ./dags
  • Scan Command (Tunnel Attributes): grep -rn "\.get_tunnel" ./dags
  • Remediation:
    • Replace timeout with conn_timeout in SSHHook.
    • Replace with hook as conn: with with hook.get_conn() as conn:.
    • Use get_tunnel() as context manager: with hook.get_tunnel(...) as tunnel:.

3.2.2 HTTP Provider (HTTP 5.0.0 & 6.0.0)

  • Scan Command: grep -rn "SimpleHttpOperator" ./dags
  • Remediation: Replace SimpleHttpOperator with HttpOperator.

3.2.3 Google Provider (v11 to v20)

  • Scan Command (BigQuery query):

    grep -rn "BigQueryExecuteQueryOperator" ./dags
    
    • Remediation: Replace with BigQueryInsertJobOperator (use configuration dict).
  • Scan Command (BigQuery table):

    grep -rn -E "BigQueryCreateEmptyTableOperator|BigQueryCreateExternalTableOperator" ./dags
    
    • Remediation: Replace with BigQueryCreateTableOperator (use table_resource dict).
  • Scan Command (AutoML):

    grep -rn -E "AutoMLTrainModelOperator|AutoMLPredictOperator|AutoMLCreateDatasetOperator|AutoMLBatchPredictOperator" ./dags
    
    • Remediation: Migrate to Vertex AI operators.
  • Scan Command (Dataflow):

    grep -rn -E "CreateDataPipelineOperator|RunDataPipelineOperator" ./dags
    
    • Remediation: Replace with DataflowCreatePipelineOperator/DataflowRunPipelineOperator.
  • Scan Command (Life Sciences):

    grep -rn "LifeSciencesRunPipelineOperator" ./dags`
    
    • Remediation: Migrate to Google Cloud Batch operators (BatchCreateJobOperator).
  • Scan Command (ADLS to GCS): grep -rn "ADLSToGCSOperator" ./dags

    • Remediation: Ensure file_system_name is provided.

3.3 Airflow 3 Migration checks

Use instructions from references/airflow-3.md when migrating to Airflow 3.


Phase 4: Deployment & Verification

Perform deployment and verification steps only if explicitly requested to do so.

4.1 Static Verification (when migrating to Airflow 3)

After applying code changes for Airflow 3, verify syntax correctness. If available in the development environment, run static lint checks:

ruff check {target_dag_file} --select AIR30

Resolve any reported deprecation warnings before finalization. If ruff is not available, recommend installing one.

4.2 Deployment to MSAA

4.2.1 Get Target GCS Bucket Path (only when requested)

gcloud composer environments describe <TARGET_ENV> \
    --location <TARGET_REGION> \
    --format="value(config.dagGcsPrefix)"

Expected Output: gs://<target-bucket-name>/dags

4.2 Upload Modified DAGs and Bucket Dependencies (Only when requested)

Perform this step only if explicitly requested to do so. Copy the modified DAGs and any backed-up bucket dependencies from your local workspace to the target GCS bucket. If you skipped the inspection step, ensure you have the correct <target-bucket-name>.

  1. Upload DAGs:

    gcloud storage cp -r ./dags/* gs://<target-bucket-name>/dags/
    
  2. Upload Other Bucket Dependencies (If applicable):

    gcloud storage cp -r ./migration_workspace/<dependency-folder> gs://<target-bucket-name>/<dependency-folder>
    

4.3 Verify DAGs via Airflow CLI

Perform this step only if explicitly requested to upload modified DAGS to a target environment (and after uploading).

You can verify that your DAGs have been successfully uploaded, parsed, and registered by the Airflow scheduler in the target environment using the Airflow CLI.

  1. List Registered DAGs: Run the following command to list all DAGs registered in the target environment. Verify that your migrated DAGs appear in this list.

    gcloud composer environments run <TARGET_ENV> \
        --location <TARGET_REGION> \
        dags list
    
  2. Check for Import Errors: If some DAGs are missing from the list, or to ensure there are no parsing issues, check for import errors:

    gcloud composer environments run <TARGET_ENV> \
        --location <TARGET_REGION> \
        dags list-import-errors
    

    Expected Output:

    • If there are no errors, the command will output No data found.
    • If there are errors, it will list the file path and the traceback of the error.

Note: It may take a couple of minutes for the Airflow scheduler to parse the new files and for changes to reflect in these commands.

4.4 Verify in Cloud Logging

Perform this step only if explicitly requested to upload modified DAGS to a target environment (and after uploading). Monitor Cloud Logging for the target environment to detect any runtime errors or import errors.

Run the following query in the GCP Cloud Logging Console (or via gcloud logging read):

resource.type="cloud_composer_environment"
resource.labels.environment_name="<TARGET_ENV>"
log_id("airflow-scheduler")
severity>=ERROR

Appendix: Local Environment Verification

If you want to verify your changes locally before deploying to the target environment, you can use the Composer Local Development CLI tool (composer-dev). Use references/local-development-environment.md as a reference for interactions with local development environments.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Configures best-practice alerting policies for AI agents using OpenTelemetry (OTel) metrics, generating output as Terraform (.tf) configuration files. Use when analyzing, writing, or deploying alerting policies to monitor agent latency, error rates, token usage, and quality metrics. Don't use for standard infrastructure monitoring unrelated to AI agents, or when the agent is not instrumented with OpenTelemetry (for Reliability, Cost, Safety, Security alerts). NOTE: Reliability, Cost, Safety, and Security alerts use generic OTel metrics and work across runtimes (such as Cloud Run, Vertex AI). Quality alerts rely on Vertex AI Online Monitors and are strictly bound to Vertex AI deployments.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

vaila-multimodaltoolbox/vaila212026년 10월 19일 업데이트

Deploy open models or custom weights from Model Garden to Agent Platform endpoints, check the status of an in-progress deployment operation, or clean up resources by undeploying models and deleting endpoints. Use when asked to actively deploy a model, list the Model Garden CATALOG of available models, check if a specific model is deployable (`gcloud ai model-garden models list-deployment-config`), query deployment cost, troubleshoot deployment errors (like quota limits), or undeploy/clean up endpoints. Also use when copying and deploying a 1P Tuned Model. Don't use for pure listing/discovery questions of the form "is X deployed?", "list my endpoints", or "which regions have models running?" — for those use `agent-platform-endpoint-management`. Don't use for public Vertex AI deployments (use the `vertex-deploy` skill) or for running model evaluations (use the `agent-platform-eval-flywheel` skill).

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

vaila-multimodaltoolbox/vaila212026년 10월 19일 업데이트

Manages Agent Platform serving endpoints. Use when you need to create, list, describe, update, or delete serving endpoints for model deployment on Agent Platform. Also use when troubleshooting endpoint permission, quota, or resource busy errors. Don't use for deploying models to endpoints or for running model evaluations.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

vaila-multimodaltoolbox/vaila212026년 10월 19일 업데이트

Measures and improves the quality of AI models and agents on Google Cloud using the Eval Quality Flywheel methodology. Use when evaluating an agent or model, building an eval dataset, picking or writing evaluation metrics, analyzing failures, comparing results before and after a fix, or when guidance is needed on Agent Platform eval methodology — including dataset schema, LLM-as-judge scoring, and common failure causes. For fine-tuning, use agent-platform-tuning. For general production deployment, use agent-platform-deploy.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

vaila-multimodaltoolbox/vaila212026년 10월 19일 업데이트

Connects to and performs inference with Google Cloud Agent Platform GenAI models, including First-Party Gemini models and Third-Party OpenMaaS models (Llama, DeepSeek, Qwen, etc.). Use when asked to perform inference, ask a model a question, run a test prompt, execute chat completions, or generate code for calling Gemini or OpenMaaS models, authenticate with GenAI SDK, OpenAI SDK, or legacy Agent Platform SDK, configure base URLs and global/regional endpoints, or troubleshoot 429 Resource Exhausted (DSQ), 400 User Validation, or 404 Not Found errors. Don't use for deploying models to endpoints or for running model evaluations.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

vaila-multimodaltoolbox/vaila212026년 10월 19일 업데이트

Guides agents and users through migrating from Gemini API in Google AI Studio to Gemini Enterprise Agent Platform (formerly Vertex AI). Use this skill when moving applications to Google Cloud, to leverage Cloud credits, or to unify inferencing with other Cloud infrastructure (IAM, billing, telemetry).

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

vaila-multimodaltoolbox/vaila212026년 10월 19일 업데이트

vaila-multimodaltoolbox의 스킬 모두 보기

이 스킬의 문제 신고