helm-chart

작성자: astronomer

Helm 차트 작업에 사용 - 차트 생성, 기존 차트 수정, 값 설계, 테스트. Astronomer APC 저장소의 경우 docs/architecture.md를 참조하세요…

npx skills add https://github.com/astronomer/astronomer --skill helm-chart

Helm Chart Work Guide

Working on the Astronomer APC Chart

APC is an umbrella chart: templates live at the umbrella level (under templates/ and charts/<chart>/templates/), sub-charts are tightly coupled and not intended to be used standalone, and a single values.yaml controls the entire platform. See docs/architecture.md for the installation modes (unified / control / data), per-mode component inventory, and cross-plane communication.

For testing, use the chart-tests skill — it covers render_chart(), sub-chart values nesting, parametrized tests, and uv run pytest usage.

Template layout

Three filename styles coexist in this repo. When adding a new template, follow whichever style the surrounding chart already uses — we do not retroactively rename existing files.

Style 1 — component-prefixed bare files. Used in single-component sub-charts: alertmanager, external-es-proxy, external-secrets, grafana, kube-state, pgbouncer, prometheus, vector. Filenames are <chart>[-feature]-<k8s_object>.yaml directly under templates/.

charts/alertmanager/templates/alertmanager-statefulset.yaml
charts/prometheus/templates/prometheus-alerts-configmap.yaml
charts/vector/templates/vector-daemonset.yaml

Style 2 — bare object-name files. Used in sub-charts derived from upstream third-party charts: postgresql, nats, prometheus-postgres-exporter. Filenames are just <k8s_object>.yaml. Keep this style for these charts so future re-syncs with upstream stay easy.

charts/postgresql/templates/statefulset.yaml
charts/nats/templates/configmap.yaml
charts/prometheus-postgres-exporter/templates/deployment.yaml

Style 3 — sub-component subdirectories. Used in charts that contain multiple distinct sub-components: astronomer (Houston, Commander, Astro UI, Registry, Pilot, …), nginx (controlplane / dataplane variants), elasticsearch (master / data / client / curator / exporter), airflow-operator (rbac / manager / webhooks / …). Each sub-component lives in its own subdirectory and the sub-component name is repeated in the filename — the redundancy keeps the file identifiable from its basename alone.

charts/astronomer/templates/commander/commander-deployment.yaml
charts/astronomer/templates/houston/api/houston-deployment.yaml
charts/nginx/templates/controlplane/nginx-cp-deployment.yaml
charts/elasticsearch/templates/master/es-master-statefulset.yaml

In all three styles: lowercase with hyphens, helpers live in _helpers.yaml (or _helpers.tpl), and the K8s object kind (deployment, configmap, networkpolicy, service, serviceaccount, role, rolebinding, ingress, …) is part of the filename so resources are easy to locate.

Probe customization

Every container should expose livenessProbe and readinessProbe as overridable values so operators can tune health checks for their environments (slow-starting components, alternative probe methods, higher failure thresholds).

# In the deployment template
{{- if .Values.myComponent.livenessProbe }}
livenessProbe: {{ tpl (toYaml .Values.myComponent.livenessProbe) $ | nindent 12 }}
{{- else }}
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
{{- end }}

# In values.yaml
myComponent:
  # -- Custom liveness probe configuration (overrides default)
  livenessProbe: {}
  # -- Custom readiness probe configuration (overrides default)
  readinessProbe: {}

Values Documentation

Use helm-docs comment pattern:

# -- Brief description of what this value does
# @default -- value
myKey: value

myObject:
  # -- Nested key description
  nestedKey: value

Template Helpers

Define common patterns in _helpers.tpl:

{{- define "myapp.labels" -}}
helm.sh/chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
app.kubernetes.io/name: {{ .Chart.Name }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- end }}

Schema Validation

Create values.schema.json:

{
  "$schema": "https://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "replicaCount": {
      "type": "integer",
      "minimum": 1,
      "description": "Number of replicas"
    }
  }
}

Best Practices

  1. Reference Helm Chart Best Practices
  2. Use helpers for reusable patterns
  3. Provide sensible security defaults
  4. Include comprehensive values documentation
  5. Add values.schema.json for IDE support
  6. All changes must pass pre-commit checks with prek run --all-files

Labels & Annotations

# ✓ GOOD: Standard Kubernetes labels
metadata:
  labels:
    app.kubernetes.io/name: {{ include "myapp.name" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}
    helm.sh/chart: {{ include "myapp.chart" . }}

# ❌ BAD: Non-standard labels
metadata:
  labels:
    app: myapp
    version: v1

Versioning Strategy

Semantic Versioning for Charts

MAJOR.MINOR.PATCH

MAJOR: Breaking changes (incompatible values schema changes)
MINOR: New features (backward compatible)
PATCH: Bug fixes (backward compatible)

Version Bump Guidelines

Change TypeVersion BumpExample
Breaking values changeMAJORimage.name → image.repository
Remove deprecated fieldMAJORRemove legacyMode
New optional featureMINORAdd metrics.enabled
New templateMINORAdd servicemonitor.yaml
Bug fixPATCHFix label selector
DocumentationPATCHUpdate README
Dependency update (minor)PATCHPostgreSQL 12.1.0 → 12.1.5
Dependency update (major)MINOR+PostgreSQL 11.x → 12.x

Chart.yaml Version Management

# Chart version (your release)
version: 2.1.0

# App version (upstream application)
appVersion: "3.5.2"

Dependency Management

Adding Dependencies

# Chart.yaml
dependencies:
  - name: postgresql
    version: "12.x.x" # Use range for flexibility
    repository: https://charts.bitnami.com/bitnami
    condition: postgresql.enabled

Dependency Commands

# Update dependencies
helm dependency update mychart/

# Build dependencies (download to charts/)
helm dependency build mychart/

# List dependencies
helm dependency list mychart/

Chart.lock Management

# Chart.lock (auto-generated, commit to git)
dependencies:
  - name: postgresql
    repository: https://charts.bitnami.com/bitnami
    version: 12.1.6
digest: sha256:abc123...
generated: "2024-01-15T10:30:00Z"

Dependency Version Ranges

# Exact version
version: "12.1.6"

# Patch range (12.1.x)
version: "~12.1.0"

# Minor range (12.x.x)
version: "^12.0.0"

# Greater than
version: ">=12.0.0"

# Range
version: ">=12.0.0 <13.0.0"

Import Values from Dependencies

dependencies:
  - name: postgresql
    version: "12.x.x"
    repository: https://charts.bitnami.com/bitnami
    import-values:
      - child: primary.service
        parent: database
      # Or import all
      - child: null
        parent: postgresql

Upgrade Strategies

Non-Breaking Upgrades

# Add new fields with defaults
newFeature:
  enabled: false # Default to off for existing users

Breaking Changes

# 1. Deprecate in MINOR release
# values.yaml
legacyField: ""  # @deprecated Use newField instead

# 2. Add migration helper
{{- if .Values.legacyField }}
{{- fail "legacyField is deprecated, please use newField" }}
{{- end }}

# 3. Remove in MAJOR release

Upgrade Testing

# Test upgrade from previous version
helm upgrade myrelease mychart/ \
  --dry-run \
  --debug \
  -f old-values.yaml

# Diff changes
helm diff upgrade myrelease mychart/ -f values.yaml

Testing

How Helm Tests Work

  1. Define test pods in templates/ with helm.sh/hook: test annotation
  2. Install chart with helm install or helm upgrade
  3. Run tests with helm test RELEASE_NAME
  4. Helm creates pods, executes them, reports results

Test passes: Pod exits with code 0 Test fails: Pod exits with non-zero code

Test Annotations

AnnotationPurpose
helm.sh/hook: testMarks pod as a test (runs during helm test)
helm.sh/hook: test-successRuns after successful release
helm.sh/hook: test-failureRuns after failed release
helm.sh/hook-weight:Controls execution order (lower = first)
helm.sh/hook-delete-policy:Controls cleanup (hook-succeeded, never)

Test Analysis: What to Test

Resource TypeTest Considerations
ServicesEndpoint reachability, DNS, correct ports
Deployments/StatefulSetsPod readiness, replica count, rollout status
IngressRoute reachability, TLS certificates
ConfigMaps/SecretsValues present, mounted correctly
PVCsVolume mounted, read/write access
CRDsCustom resource creation, reconciliation

Test Categories

CategoryPurposeExamples
SmokeQuick "is it alive"Service health, pod readiness
FunctionalVerify specific behaviorAPI responses, database connectivity
IntegrationVerify external interactionsUpstream services, third-party APIs
Data ValidationVerify deployed stateConfigMap content, environment variables

Basic Test Pod Structure

apiVersion: v1
kind: Pod
metadata:
  name: "{{ .Release.Name }}-test-connectivity"
  annotations:
    helm.sh/hook: test-success
    helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded
spec:
  containers:
    - name: test
      image: curlimages/curl:8.7.1
      command:
        - sh
        - -c
        - |
          set -e
          curl -f http://myapp-service:8080/health
  restartPolicy: Never

Best practices:

  • Use restartPolicy: Never
  • Use lightweight images (curlimages/curl, busybox, alpine)
  • One test pod tests one thing well
  • Exit code 0 = pass, non-zero = fail
  • Pin images to specific versions, never use latest

Common test images:

  • curlimages/curl:8.7.1 - HTTP endpoint checks
  • busybox:1.36 - Basic shell utilities
  • bitnami/kubectl:1.29 - Kubernetes API queries
  • postgres:16-alpine - Database connectivity

Test Examples

Service Connectivity Test

apiVersion: v1
kind: Pod
metadata:
  name: "{{ .Release.Name }}-api-test"
  annotations:
    helm.sh/hook: test-success
    helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded
spec:
  containers:
    - name: api-test
      image: curlimages/curl:8.7.1
      command:
        - sh
        - -c
        - |
          set -e
          # Test main endpoint
          curl -f http://{{ .Release.Name }}-service:8080/health || exit 1
          # Verify response content
          curl -s http://{{ .Release.Name }}-service:8080/health | grep -q "status.*ok" || exit 1
          {{- if .Values.auth.enabled }}
          # Test authenticated endpoint
          curl -f http://{{ .Release.Name }}-service:8080/secure \
            -H "Authorization: Bearer {{ .Values.auth.testToken }}" || exit 1
          {{- end }}
  restartPolicy: Never

Configuration Validation Test

apiVersion: v1
kind: Pod
metadata:
  name: "{{ .Release.Name }}-config-test"
  annotations:
    helm.sh/hook: test-success
spec:
  containers:
  - name: config-test
    image: busybox:1.36
    command:
    - sh
    - -c
    - |
      set -e
      test -f /app/config.yaml || exit 1
      grep -q "logLevel: {{ .Values.logLevel }}" /app/config.yaml || exit 1
      grep -q "database:" /app/config.yaml || exit 1
  volumeMounts:
  - name: config
    mountPath: /app/config.yaml
    subPath: config.yaml
  volumes:
  - name: config
    configMap:
      name: {{ include "myapp.fullname" . }}-config
  restartPolicy: Never

Deployment Readiness Test

apiVersion: v1
kind: Pod
metadata:
  name: "{{ .Release.Name }}-readiness-test"
  annotations:
    helm.sh/hook: test-success
spec:
  serviceAccountName: {{ include "myapp.fullname" . }}-test-sa
  containers:
  - name: kubectl-test
    image: bitnami/kubectl:1.29
    command:
    - sh
    - -c
    - |
      set -e
      kubectl get deployment {{ .Release.Name }} -n {{ .Release.Namespace }} -o json | \
        jq -e '.status.readyReplicas == {{ .Values.replicaCount }}' || exit 1
  restartPolicy: Never

Database Connection Test

apiVersion: v1
kind: Pod
metadata:
  name: "{{ .Release.Name }}-db-test"
  annotations:
    helm.sh/hook: test-success
spec:
  containers:
    - name: db-test
      image: postgres:16-alpine
      command:
        - sh
        - -c
        - |
          set -e
          nc -zv {{ .Values.database.host }} {{ .Values.database.port }} || exit 1
          PGPASSWORD={{ .Values.database.password }} \
          psql -h {{ .Values.database.host }} -p {{ .Values.database.port }} \
                -U {{ .Values.database.user }} -d {{ .Values.database.name }} \
                -c "SELECT 1;" || exit 1
  restartPolicy: Never

Test Organization

mychart/
├── templates/
│   ├── tests/
│   │   ├── test-service-connectivity.yaml
│   │   ├── test-config-validation.yaml
│   │   └── test-readiness.yaml
│   ├── deployment.yaml
│   └── service.yaml

Conditional Testing

Enable/disable tests globally:

{{- if .Values.tests.enabled }}
apiVersion: v1
kind: Pod
metadata:
  name: "{{ .Release.Name }}-test"
  annotations:
    helm.sh/hook: test-success
spec:
  # ...
{{- end }}

In values.yaml:

tests:
  enabled: true

Test specific configurations:

{{- if .Values.metrics.enabled }}
# metrics test
{{- end }}

Test Execution Order

Use helm.sh/hook-weight (lower runs first):

# Test 1: Run first
metadata:
  annotations:
    helm.sh/hook-weight: "-5"

---
# Test 2: Run second
metadata:
  annotations:
    helm.sh/hook-weight: "0"

Running and Debugging

# Run tests
helm test my-release
helm test my-release --logs
helm test my-release --timeout 10m
helm test my-release -n my-namespace

# Debugging
kubectl get pods -n namespace -l helm.sh/hook=test
kubectl logs my-release-test-connectivity -n namespace
kubectl describe pod my-release-test-connectivity -n namespace

Test Design Considerations

Test Independence

Each test should verify one thing well:

# Good: Single focused test
metadata:
  name: "{{ .Release.Name }}-test-health"

# Avoid: Tests multiple unrelated things
metadata:
  name: "{{ .Release.Name }}-test-everything"

Resource Management

Set limits to prevent exhaustion:

spec:
  containers:
    - name: test
      image: curlimages/curl:8.7.1
      resources:
        requests:
          cpu: 100m
          memory: 64Mi
        limits:
          cpu: 200m
          memory: 128Mi

Cleanup Policies

PolicyBehaviorUse Case
hook-succeededDelete after passingNormal operation
neverNever deleteDebugging

For debugging:

metadata:
  annotations:
    helm.sh/hook-delete-policy: never

Error Handling

Provide clear failure messages:

command:
  - sh
  - -c
  - |
    set -e
    if ! curl -f http://service:8080/health; then
      echo "ERROR: Service health check failed"
      echo "Troubleshooting: kubectl get svc, kubectl logs -l app=myapp"
      exit 1
    fi

Security

Use least privilege RBAC:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: {{ include "myapp.fullname" . }}-test-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: {{ include "myapp.fullname" . }}-test-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: {{ include "myapp.fullname" . }}-test-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: {{ include "myapp.fullname" . }}-test-role
subjects:
- kind: ServiceAccount
  name: {{ include "myapp.fullname" . }}-test-sa

Don't embed secrets:

# Avoid
command:
  ["curl", "-H", "Authorization: Bearer super-secret-key", "http://service/"]

# Better
env:
  - name: TEST_TOKEN
    valueFrom:
      secretKeyRef:
        name: test-credentials
        key: token

Common Test Failures

SymptomCauseSolution
Image pull errorsWrong image/registryVerify image name and pull secrets
Connection refusedService not readyAdd readiness test, increase timeout
Permission deniedInsufficient RBACAdd service account and role
Command not foundWrong base imageUse image with required tools
TimeoutService startup too slowIncrease timeout or add retry logic

Review & Quality Assurance

Review Checklist

Structure & Organization

  • Standard directory structure followed
  • Chart.yaml has required fields (apiVersion, name, version)
  • README.md exists and is complete
  • NOTES.txt provides useful post-install information
  • .helmignore excludes unnecessary files
  • Templates organized logically

Values Design

  • values.yaml has sensible defaults
  • All values documented with comments
  • values.schema.json validates inputs
  • No hardcoded values in templates
  • Sensitive values use secrets, not configmaps

Security

  • Pod security context defined
  • Container security context defined
  • Service account with minimal permissions
  • Network policies included (if applicable)
  • No privileged containers by default
  • Resource limits defined

Quality

  • Templates pass helm lint
  • Unit tests exist and pass
  • Labels follow Kubernetes conventions
  • Proper use of helpers (_helpers.tpl)
  • Consistent naming conventions

Security Review

Pod Security Checklist

# REQUIRED security settings
podSecurityContext:
  runAsNonRoot: true # ✓ Never run as root
  fsGroup: 1000 # ✓ Set filesystem group
  seccompProfile:
    type: RuntimeDefault # ✓ Use seccomp

securityContext:
  allowPrivilegeEscalation: false # ✓ Block privilege escalation
  readOnlyRootFilesystem: true # ✓ Immutable container
  runAsNonRoot: true # ✓ Non-root user
  runAsUser: 1000 # ✓ Specific UID
  capabilities:
    drop:
      - ALL # ✓ Drop all capabilities

Security Anti-Patterns

# ❌ BAD: Privileged container
securityContext:
  privileged: true

# ❌ BAD: Running as root
securityContext:
  runAsUser: 0

# ❌ BAD: Writable root filesystem
securityContext:
  readOnlyRootFilesystem: false

# ❌ BAD: Host namespaces
hostNetwork: true
hostPID: true
hostIPC: true

# ❌ BAD: Dangerous volume mounts
volumes:
  - name: host
    hostPath:
      path: /

# ❌ BAD: Secrets in environment variables (prefer mounted secrets)
env:
  - name: DB_PASSWORD
    value: "hardcoded-password"

# ❌ BAD: No resource limits
resources: {}

RBAC Review

# ✓ GOOD: Minimal permissions
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch"]
  resourceNames: ["my-config"]  # Even better: specific resources

# ❌ BAD: Overly permissive
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

# ❌ BAD: Cluster-wide access when namespace-scoped sufficient
kind: ClusterRole  # Should be Role if namespace-scoped

Image Security

# ✓ GOOD: Specific tag
image:
  repository: myapp
  tag: "v1.2.3"  # Specific version

# ❌ BAD: Latest tag
image:
  repository: myapp
  tag: "latest"  # Mutable, unpredictable

# ✓ GOOD: Digest pinning for critical apps
image:
  repository: myapp@sha256:abc123...

Automated Review Tools

# Basic linting
helm lint mychart/

# Strict mode
helm lint mychart/ --strict

# With values
helm lint mychart/ -f values-production.yaml


# Best practices
helm template myrelease mychart/ | polaris audit --audit-path -

# Deprecated APIs
helm template myrelease mychart/ | pluto detect -

# NSA security framework
helm template myrelease mychart/ | kubescape scan framework nsa -

Code Review Comments

Severity Levels

LevelDescriptionAction
🔴 CriticalSecurity vulnerability, data loss riskMust fix before merge
🟠 MajorBest practice violation, significant issueShould fix
🟡 MinorStyle, minor improvementNice to have
🔵 SuggestionAlternative approachConsider

Example Review Comments

🔴 **Critical: Security - Privileged Container**
The container is running as privileged which grants full host access.

```yaml
# Current
securityContext:
  privileged: true

# Suggested
securityContext:
  privileged: false
  allowPrivilegeEscalation: false

🟠 Major: Missing Resource Limits No resource limits defined. This can lead to resource starvation.

# Add to values.yaml
resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

🟡 Minor: Use nindent instead of indent nindent handles newlines automatically and is more reliable.

# Current
{{ toYaml .Values.labels | indent 4 }}

# Suggested
{{- toYaml .Values.labels | nindent 4 }}

🔵 Suggestion: Consider using a helper This pattern is repeated in multiple templates. Consider extracting to _helpers.tpl.


---

## CI/CD Integration

### GitHub Actions Workflow

```yaml
name: Helm Chart CI

on:
  push:
    paths:
      - "charts/**"
  pull_request:
    paths:
      - "charts/**"

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: azure/setup-helm@v3
      - name: Lint charts
        run: helm lint charts/*

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: azure/setup-helm@v3
      - name: Install helm-unittest
        run: helm plugin install https://github.com/helm-unittest/helm-unittest
      - name: Run tests
        run: helm unittest charts/*

  template:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: azure/setup-helm@v3
      - name: Template charts
        run: |
          for chart in charts/*; do
            helm template test $chart --debug
          done

  release:
    needs: [lint, test, template]
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Package and push
        run: |
          helm package charts/*
          # Push to registry

Chart Releaser (cr)

# Package and upload to GitHub releases
cr package charts/mychart
cr upload --owner org --git-repo charts
cr index --owner org --git-repo charts --push

Documentation

README Template

# MyApp Helm Chart

![Version: 1.0.0](https://img.shields.io/badge/Version-1.0.0-informational)
![AppVersion: 2.3.1](https://img.shields.io/badge/AppVersion-2.3.1-informational)

## Description

A Helm chart for deploying MyApp on Kubernetes.

## Prerequisites

- Kubernetes 1.23+
- Helm 3.10+
- PV provisioner (if persistence enabled)

## Installing

```bash
helm repo add myrepo https://charts.example.com
helm install myrelease myrepo/myapp
```

## Configuration

| Parameter          | Description        | Default                |
| ------------------ | ------------------ | ---------------------- |
| `replicaCount`     | Number of replicas | `1`                    |
| `image.repository` | Image repository   | `myapp`                |
| `image.tag`        | Image tag          | `""` (uses appVersion) |

## Upgrading

### From 1.x to 2.x

Breaking changes:

- `image.name` renamed to `image.repository`
- Minimum Kubernetes version is now 1.23

Migration:

```yaml
# Old (1.x)
image:
  name: myapp

# New (2.x)
image:
  repository: myapp
  tag: "2.3.4"
```

Auto-Generate Docs (helm-docs)

helm-docs --chart-search-root=charts/

astronomer의 다른 스킬

airflow-state-store
astronomer
Persists task and asset state across retries and DAG runs using Airflow 3.3's AIP-103 key/value stores (`task_state_store`, `asset_state_store`) and the…
creating-openlineage-extractors
astronomer
지원되지 않는 Airflow 연산자와 복잡한 계보 시나리오를 위한 맞춤형 OpenLineage 추출기. 두 가지 접근 방식: 소유한 연산자에 직접 OpenLineage 메서드를 추가(권장)하거나, 수정할 수 없는 타사 연산자를 위한 맞춤형 추출기를 생성합니다. 추출기는 세 지점에서 연산자 실행을 가로챕니다: 정적 계보를 위한 실행 전, 런타임에 결정된 출력을 위한 성공 후, 그리고 선택적으로 부분 계보를 위한 실패 후. airflow.cfg 또는 환경을 통해 추출기를 등록합니다...
debugging-dags
astronomer
체계적인 근본 원인 분석 및 구조화된 조사 워크플로를 통한 실패한 Airflow DAG의 문제 해결. 4단계 진단 프로세스를 안내합니다: 실패 식별, 오류 세부 정보 추출, 컨텍스트 정보 수집, 실행 가능한 수정 단계 제공. 실패를 네 가지 유형(데이터, 코드, 인프라, 종속성)으로 분류하여 조사에 집중하고 적절한 수정을 제안합니다. 로그 검색, 실행 비교, 작업 정리, DAG...을 위한 즉시 사용 가능한 CLI 명령을 제공합니다.
delegating-to-otto
astronomer
Drives Astronomer's Otto agent (`astro otto`) as a delegated sub-agent for Airflow, dbt, and data-engineering work. Use when the user explicitly asks to "use…
deploying-airflow
astronomer
Airflow DAG 및 프로젝트를 배포합니다. 사용자가 코드를 배포하거나, DAG를 푸시하거나, CI/CD를 설정하거나, 프로덕션에 배포하거나, 배포 전략에 대해 질문할 때 사용하세요.
deploying-go-sdk-bundles
astronomer
컴파일된 Airflow Go SDK 번들을 빌드, 패킹 및 배포하여 ExecutableCoordinator가 실행할 수 있도록 합니다. 사용자가 Go 태스크 번들을 컴파일하려고 하거나 요청할 때 사용합니다.
testing-dags
astronomer
포괄적인 실패 진단 기능을 갖춘 Airflow DAG의 반복적인 테스트-디버그-수정 주기. af runs trigger-wait <dag_id>로 시작하여 DAG를 실행하고 완료를 기다립니다. 사전 점검은 필요하지 않습니다. 실패 시 af runs diagnose를 사용하여 포괄적인 실패 요약을 확인하고, af tasks logs를 사용하여 특정 태스크의 오류 세부 정보를 검사합니다. 사용자 정의 구성, 시간 제한 및 재시도 횟수를 지원하며, 명확한 응답 해석으로 성공, 실패 및 시간 초과 시나리오를 처리합니다. 빠른 검증 가능...
tracing-downstream-lineage
astronomer
테이블이나 DAG를 수정하기 전에 다운스트림 데이터 계보를 추적하여 변경 영향을 평가합니다. 소스 코드 검색, 뷰 종속성, BI 도구 연결을 통해 대상 테이블 또는 DAG의 직접적인 소비자를 식별합니다. 테이블에서 대시보드, ML 모델에 이르기까지 모든 다운스트림 영향을 매핑하는 전체 종속성 트리를 구축합니다. 종속성을 중요도(심각, 높음, 중간, 낮음)별로 분류하여 이해관계자 커뮤니케이션 및 테스트의 우선순위를 지정합니다. 위험 평가, 영향을 받는 항목이 포함된 영향 보고서를 생성합니다...