¿Cómo implementar automáticamente nuevas imágenes de Docker desde Dockerhub a Kubernetes?

¿Cómo implementar automáticamente nuevas imágenes de Docker desde Dockerhub a Kubernetes?

Estoy buscando una solución de CD para mi clúster k8s. Ahora, después de realizar una confirmación con dev-*etiqueta, Dockerhub crea una nueva imagen etiquetada como dev-latest. Aquí está mi configuración de implementación:

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

Quiero que las nuevas imágenes se implementen automáticamente en los pods, pero no encuentro una solución relevante.

UPD Me gustaría que mis imágenes se implementen automáticamente después de que dev-0.1.*se envíe al registro una nueva imagen con la etiqueta (donde * es un número). No quiero hacer nada después de que el código haya sido insertado e integrado en la imagen. Descubrí algunos proyectos de CD Foundation: Jenkins X, Spinnaker y Tekton y supongo que algunos de ellos pueden ayudarme a implementar mi idea, pero sería genial implementarlo sin una mascota más en mi zoológico.

Respuesta1

Referencia de imagen y manifiestos.

Kubernetes gestiona las implementaciones, por ejemplo, utilizando una estrategia de implementación continua cada vez que kind: Deploymentse cambia su manifiesto.

Ahora, después de realizar una confirmación con la etiqueta dev-*, dockerhub crea una nueva imagen etiquetada como dev-latest

El principal problema con esto es que usas elmismonombre de etiqueta para cada imagen. Esto significa que su kind: Deploymentmanifiesto esnose actualiza cuando se actualiza su imagen, por lo que Kubernetes no inicia una nueva implementación continua, ya que no hay cambios en el manifiesto.

Una buena práctica es utilizar una etiqueta de imagen única cada vez que envía una imagen y luego actualizar el kind: Deploymentmanifiesto con este nuevo nombre de etiqueta de imagen, de modo que Kubernetes active automáticamente una nueva implementación continua.

Algunos registros de imágenes se pueden configurar para usar "nombres de etiquetas inmutables", esto significa que estáhecho cumplirutilizar siempre un nombre de etiqueta único para cada imagen creada. Alternativamente, puede utilizar elResumen de imagen completoen el kind: Deploymentmanifiesto, para que pueda tener una referencia de imagen única incluso si el nombre de la etiqueta es el mismo (Image Digest es un hash del contenido).

En resumen:

  • Utilice nombres de etiquetas de imagen únicos para cada compilación
  • Actualiza el kind: Deploymentmanifiesto con el nuevo nombre de etiqueta.
  • Mantenga el kind: Deploymentmanifiesto (y otros manifiestos yaml) en el control de versiones, por ejemplo, Git
  • Considere utilizar el resumen de imagen completo en el manifiesto cuando haga referencia a la imagen.

Proceso y automatización

Actualizar el manifiesto y aplicarlo al clúster se puede realizar de varias maneras diferentes, pero se recomienda almacenar siempre el manifiesto actualizado en un repositorio Git después de cada cambio, antes de aplicarlo al clúster. De esta manera, se obtiene una buena trazabilidad de lo que ha cambiado y es más fácil volver a una versión funcional si algo falla.

Con los pasos necesarios descritos anteriormente, otra práctica importante es utilizarautomatizaciónpara esto. Después de cada cambio en el repositorio de Git, active un proceso automatizado para realizar el trabajo, preferiblemente sin ningún paso manual. Históricamente, Jenkins ha sido una herramienta popular para esto, pero tiene su edad y no está diseñado para funcionar bien en un entorno de contenedores. Ahora recomiendo usar una herramienta comoAcciones de GitHub,Construcción de la nube de Googleo un sistema moderno dentro del clúster de Kubernetes, comoTuberías Tekton

Construya e implemente Pipeline usando Tekton

Si elige utilizar Tekton en su clúster de Kubernetes, puede estructurar el proyecto de esta manera:

  1. Git push de cambio de código a un repositorio de código
  2. AGatillo Tektonrecibe un evento del sistema Git e inicia un nuevo PipelineRun.
  3. ElOleoducto Tektoncontiene pasos para git-clone, compilar el código, ejecutar pruebas y crear y enviar una imagen. El resultado es un resumen o etiqueta de imagen. Luego, tiene una última tarea en proceso que, si todas las tareas anteriores se realizaron correctamente, actualiza el kind: Deploymentmanifiesto con el nuevo resumen de imágenes y git-push a un repositorio con los manifiestos.
  4. Se activa una canalización de implementación que aplica los manifiestos al clúster (quizás usando una estrategia de implementación de su elección, implementación continua, implementación gradual o implementación canaria).

Recomendaciones de libros

  • Kubernetes en funcionamiento2.a edición (de 2019): contiene un nuevo capítulo:18. Organizando tu solicitudque describe cómo gestionar implementaciones con manifiestos y control de versiones.

  • Entrega continua- un libro clásico sobre cómo utilizarconstruir e implementar tuberíasy automatización.

Alternativas

Descubrí algunos proyectos de CD Foundation: Jenkins X, Spinnaker y Tekton y supongo que algunos de ellos pueden ayudarme a implementar mi idea, pero sería genial implementarlo sin una mascota más en mi zoológico.

Implementaciones en Kubernetespoderhacerse sin utilizar manifiestos declarativos y en su lugar hacerse concomandos imperativossin ningún cambio controlado por la versión, pero esto esrealmente desanimadopara un ambiente profesional. Es importante hacer esto de forma declarativa y reproducible, aunque las canalizaciones automatizadas tardan algún tiempo en instalarse y configurarse.

Respuesta2

Finalmente descubrí la increíble herramienta "keel.sh" que hace exactamente lo que espero del CD para Kubernetes.

información relacionada