Zum Inhalt

Init Container und Jobs

ohMyHelm unterstützt Init Container und Jobs für Setup-Tasks, die vor dem Start des Hauptcontainers ausgeführt werden müssen.

Übersicht

Komponente Beschreibung Lebenszyklus
Init Container Läuft vor dem Hauptcontainer Beendet sich nach Abschluss
Job Einmalige Ausführung eines Tasks Wird nach Erfolg nicht neu gestartet

Init Container

Init Container werden verwendet, um Vorbereitungsarbeiten durchzuführen, bevor der Hauptcontainer startet.

Basis-Konfiguration

chart:
  initContainer:
    enabled: true
    image: busybox:latest
    command:
      - sh
      - -c
      - "echo 'Waiting for database...' && sleep 10"

Warten auf einen Service

chart:
  initContainer:
    enabled: true
    image: busybox:latest
    command:
      - sh
      - -c
      - |
        until nc -z postgres.default.svc.cluster.local 5432; do
          echo "Waiting for PostgreSQL..."
          sleep 2
        done
        echo "PostgreSQL is ready!"

Mit Umgebungsvariablen

chart:
  initContainer:
    enabled: true
    image: myapp/migrations:latest
    env:
      - name: DATABASE_URL
        valueFrom:
          secretKeyRef:
            name: db-credentials
            key: url
    command:
      - /app/run-migrations.sh

Jobs

Jobs sind für einmalige Tasks wie Datenbank-Migrationen oder Setup-Scripts.

Basis-Konfiguration

chart:
  job:
    enabled: true
    image: myapp/migrations:latest
    command:
      - /app/migrate.sh

Gleiche Image-Referenz

Wenn Ihr Job dasselbe Image wie der Hauptcontainer verwendet, können Sie chart.job.image leer lassen. ohMyHelm verwendet dann automatisch das Container-Image.

Job mit Backoff-Limit

chart:
  job:
    enabled: true
    image: myapp/setup:latest
    backoffLimit: 3
    command:
      - /app/setup.sh

Init Container mit Job-Abhängigkeit

Standardmäßig wartet der Init Container darauf, dass der Job abgeschlossen ist, bevor der Hauptcontainer startet:

chart:
  # Job führt Migrationen aus
  job:
    enabled: true
    image: myapp/migrations:latest
    command:
      - /app/run-migrations.sh

  # Init Container wartet auf Job-Abschluss
  initContainer:
    enabled: true
    # Wartet automatisch auf Job-Completion

  # Hauptcontainer startet erst nach Init Container
  container:
    image: myapp/api:latest

Ablauf:

  1. Job startet und führt Migrationen aus
  2. Init Container wartet auf Job-Abschluss (Exit Code 0)
  3. Init Container beendet sich erfolgreich
  4. Hauptcontainer und Sidecar starten

Vollständiges Beispiel

chart:
  enabled: true
  fullnameOverride: "my-api"

  # Setup-Job für Datenbank-Migrationen
  job:
    enabled: true
    image: myapp/migrations:v1.0.0
    env:
      - name: DATABASE_URL
        valueFrom:
          secretKeyRef:
            name: db-credentials
            key: url
    command:
      - python
      - manage.py
      - migrate

  # Init Container für zusätzliche Checks
  initContainer:
    enabled: true
    image: busybox:latest
    command:
      - sh
      - -c
      - |
        echo "Checking external dependencies..."
        until nc -z redis.default.svc.cluster.local 6379; do
          sleep 2
        done
        echo "All dependencies ready!"

  # Hauptcontainer
  container:
    image: myapp/api:v1.0.0
    ports:
      - name: http
        containerPort: 8000

Best Practices

  1. Verwenden Sie Init Container für schnelle Vorbereitungsarbeiten
  2. Verwenden Sie Jobs für langläufige Setup-Tasks
  3. Setzen Sie Timeouts für Init Container, um Endlos-Schleifen zu vermeiden
  4. Loggen Sie ausführlich in Init Containern für besseres Debugging
  5. Verwenden Sie backoffLimit bei Jobs, um Wiederholungsversuche zu begrenzen

Siehe auch