☰

Wie kann ich neue Docker-Images automatisch von Dockerhub in Kubernetes bereitstellen?

tag-icon • tag-icon kubernetes deployment
Wie kann ich neue Docker-Images automatisch von Dockerhub in Kubernetes bereitstellen?

Ich suche nach einer CD-Lösung für meinen K8s-Cluster. Nachdem ich nun ein Commit mit dev-*dem Tag gepusht habe, erstellt Dockerhub ein neues Image mit dem Tag dev-latest. Hier ist meine Bereitstellungskonfiguration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-image-backend-local-deployment
  labels:
    app: my-image
    type: web
spec:
  replicas: 2
  minReadySeconds: 15
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 1
  selector:
    matchLabels:
      app: my-image
  template:
    metadata:
      labels:
        app: my-image
    spec:
      imagePullSecrets:
        - name: regcred
      containers:
      - name: backend
        image: cosmicfruit/my-image:dev-latest
        imagePullPolicy: IfNotPresent
        envFrom:
        - secretRef:
            name: my-image-backend-local-secret
        ports:
        - containerPort: 8000
        readinessProbe:
          httpGet:
             path: /flvby
             port: 8000
          initialDelaySeconds: 10
          periodSeconds: 5
      - name: celery
        image: cosmicfruit/my-image:dev-latest
        imagePullPolicy: IfNotPresent
        workingDir: /code
        command: ["/code/run/celery.sh"]
        envFrom:
        - secretRef:
            name: my-image-backend-local-secret
      - name: redis
        image: redis:latest
        imagePullPolicy: IfNotPresent

Ich möchte, dass neue Bilder automatisch in den Pods bereitgestellt werden, kann aber keine entsprechende Lösung finden.

UPD Ich möchte, dass meine Bilder automatisch bereitgestellt werden, nachdem ein neues Bild mit dev-0.1.*dem Tag (wobei * eine Zahl ist) in die Registrierung übertragen wurde. Ich möchte nichts tun, nachdem Code übertragen und in das Bild integriert wurde. Ich habe einige Projekte von CD Foundation entdeckt: Jenkins X, Spinnaker und Tekton, und ich denke, einige davon können mir bei der Umsetzung meiner Idee helfen, aber es wäre toll, sie ohne ein weiteres Haustier in meinem Zoo umzusetzen.

Antwort1

Bildreferenz und Manifeste

Kubernetes verwaltet Bereitstellungen, beispielsweise mithilfe einer fortlaufenden Bereitstellungsstrategie, wenn Ihr kind: DeploymentManifest geändert wird.

Nach dem Pushen eines Commits mit dem Tag dev-* erstellt Dockerhub nun ein neues Image mit dem Tag dev-latest

Das Hauptproblem dabei ist, dass Sie dieDasselbeTag-Name für jedes Bild. Das bedeutet, dass Ihr kind: DeploymentManifest istnichtaktualisiert, wenn Ihr Image aktualisiert wird, sodass Kubernetes keine neue fortlaufende Bereitstellung initiiert, da im Manifest keine Änderungen vorhanden sind.

Eine bewährte Vorgehensweise besteht darin, bei jedem Pushen eines Images einen eindeutigen Image-Tag zu verwenden und dann das kind: DeploymentManifest mit diesem neuen Image-Tag-Namen zu aktualisieren, sodass Kubernetes automatisch eine neue fortlaufende Bereitstellung auslöst.

Einige Image-Registries können so konfiguriert werden, dass sie "unveränderliche Tag-Namen" verwenden. Dies bedeutet, dass Siedurchgesetztum für jedes erstellte Image immer einen eindeutigen Tag-Namen zu verwenden. Alternativ können Sie denvollständiges Bild-Digestim kind: DeploymentManifest, sodass Sie eine eindeutige Bildreferenz haben, auch wenn der Tag-Name derselbe ist (Image Digest ist ein Hash des Inhalts).

In Summe:

  • Verwenden Sie für jeden Build eindeutige Image-Tagnamen
  • Aktualisieren Sie das kind: DeploymentManifest mit dem neuen Tag-Namen
  • Bewahren Sie das kind: DeploymentManifest (und andere YAML-Manifeste) in der Versionskontrolle auf, z. B. Git
  • Verwenden Sie im Manifest ggf. den vollständigen Image Digest, wenn Sie auf das Bild verweisen.

Prozess und Automatisierung

Das Manifest kann auf verschiedene Weise aktualisiert und auf den Cluster angewendet werden. Es wird jedoch empfohlen, das aktualisierte Manifest nach jeder Änderung immer in einem Git-Repository zu speichern, bevor es auf den Cluster angewendet wird. Auf diese Weise erhalten Sie eine gute Nachverfolgung der Änderungen und können bei Fehlern leichter zu einer funktionierenden Version zurückkehren.

Neben den oben beschriebenen Schritten ist eine weitere wichtige Vorgehensweise die VerwendungAutomatisierungdafür. Nach jeder Änderung am Git-Repository sollte ein automatisierter Prozess ausgelöst werden, der die Arbeit erledigt, vorzugsweise ohne manuelle Schritte. Historisch gesehen war Jenkins hierfür ein beliebtes Tool, aber es ist veraltet und nicht dafür ausgelegt, in einer Containerumgebung gut zu laufen. Ich empfehle jetzt die Verwendung eines Tools wieGitHub-Aktionen,Google Cloud Buildoder ein modernes System innerhalb des Kubernetes-Clusters, wieTekton-Pipelines

Erstellen und Bereitstellen einer Pipeline mit Tekton

Wenn Sie Tekton in Ihrem Kubernetes-Cluster verwenden möchten, können Sie das Projekt wie folgt strukturieren:

  1. Git-Push von Codeänderungen in ein Code-Repository
  2. ATekton-Auslöserempfängt ein Ereignis vom Git-System und initiiert ein neues PipelineRun.
  3. DerTekton-Pipelineenthält Schritte zum Git-Clone, zum Erstellen des Codes, zum Ausführen von Tests und zum Erstellen und Pushen eines Images. Das Ergebnis ist ein Image Digest oder Label. Dann haben Sie eine letzte Aufgabe in der Pipeline, die, wenn alle vorherigen Aufgaben erfolgreich waren, das kind: DeploymentManifest mit dem neuen Image Digest aktualisiert und mit den Manifesten per Git-Push in ein Repository überträgt.
  4. Eine Bereitstellungspipeline wird ausgelöst, die die Manifeste auf den Cluster anwendet (möglicherweise mithilfe einer Bereitstellungsstrategie Ihrer Wahl, fortlaufender Bereitstellung, schrittweiser Bereitstellung oder Canary-Bereitstellung).

Buchempfehlungen

  • Kubernetes einsatzbereit2. Auflage (von 2019) - sie enthält ein neues Kapitel:18. Organisieren Sie Ihre BewerbungDarin wird beschrieben, wie Bereitstellungen mit Manifesten und Versionskontrolle verwaltet werden.

  • Kontinuierliche Bereitstellung- ein klassisches Buch über die VerwendungPipelines erstellen und bereitstellenund Automatisierung.

Alternativen

Ich habe einige Projekte der CD Foundation entdeckt: Jenkins X, Spinnaker und Tekton, und ich denke, einige davon können mir bei der Umsetzung meiner Idee helfen, aber es wäre toll, sie ohne ein weiteres Haustier in meinem Zoo umzusetzen.

Bereitstellungen auf Kubernetesdürfenkann ohne deklarative Manifeste erfolgen, sondern mitimperative Befehleohne Versionskontrolle, aber das istwirklich entmutigtfür eine professionelle Umgebung. Es ist wichtig, dies auf deklarative und reproduzierbare Weise zu tun, obwohl die Einrichtung und Konfiguration automatisierter Pipelines einige Zeit in Anspruch nimmt.

Antwort2

Endlich habe ich das tolle Tool „keel.sh“ entdeckt, das genau das tut, was ich von der CD für Kubernetes erwarte

verwandte Informationen