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: Deployment
se 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: Deployment
manifiesto 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: Deployment
manifiesto 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: Deployment
manifiesto, 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: Deployment
manifiesto con el nuevo nombre de etiqueta. - Mantenga el
kind: Deployment
manifiesto (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:
- Git push de cambio de código a un repositorio de código
- AGatillo Tektonrecibe un evento del sistema Git e inicia un nuevo
PipelineRun
. - 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: Deployment
manifiesto con el nuevo resumen de imágenes y git-push a un repositorio con los manifiestos. - 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.