Prácticas recomendadas para la integración y entrega continuas en Google Kubernetes Engine

En esta guía se describen una serie de prácticas recomendadas para la integración y la entrega continuas (CI/CD) en Google Kubernetes Engine (GKE). Estas prácticas abarcan una amplia gama de temas, desde el control de versiones hasta las estrategias de implementación. Estas prácticas recomendadas son específicas de GKE, pero las prácticas recomendadas generales de CI/CD siguen siendo válidas. Para obtener más información, consulta los artículos Tecnología de DevOps: integración continua y Tecnología de DevOps: entrega continua.

Integración continua

La integración continua (CI) es una práctica en la que los desarrolladores integran todos los cambios de código en una rama principal con la mayor frecuencia posible. Su objetivo es permitir que los errores se produzcan más rápido, ya que expone los problemas lo antes posible en el proceso. Los flujos de procesamiento de CI suelen activarse cuando los desarrolladores envían cambios en el código. La canalización incluye pasos para validar esos cambios, como la comprobación de errores, las pruebas y la compilación. Una canalización de CI suele generar un artefacto que puedes implementar en fases posteriores del proceso de implementación.

Crea flujos de trabajo que permitan iterar rápidamente

El tiempo que transcurre entre el momento en que un desarrollador hace un cambio en el código y el momento en que tienes una versión de la aplicación en funcionamiento debe ser lo más breve posible. Esta velocidad es especialmente importante durante el desarrollo en ramas de funciones que implican una iteración rápida por parte de los desarrolladores. Lo ideal es que tus pipelines de CI se ejecuten en menos de 10 minutos. Si no es posible, crea dos tipos de flujos de procesamiento de CI:

  • Pipelines rápidos: suelen ejecutarse en 10 minutos o menos. Estas canalizaciones son para ramas de funciones y no están pensadas para ser exhaustivas. Los flujos de trabajo rápidos pueden dar lugar a artefactos inestables.

  • Pipelines completos: estos pipelines pueden tardar más de 10 minutos en ejecutarse y realizan pruebas y comprobaciones más exhaustivas. Las canalizaciones completas se ejecutan en solicitudes de combinación o de extracción, y en confirmaciones en la rama principal.

Probar imágenes de contenedor

Como parte de tus flujos de procesamiento de CI, asegúrate de ejecutar todas las pruebas necesarias en tu código y en los artefactos de compilación. Estas pruebas deben incluir pruebas unitarias, funcionales, de integración y de carga o rendimiento.

También es importante probar la estructura de las imágenes de contenedor creadas. Al probar la estructura, te aseguras de que todos los comandos se ejecuten como esperas en tu contenedor. Las pruebas también te permiten comprobar que los archivos específicos están en la ubicación correcta y tienen el contenido adecuado.

Para probar tus imágenes de contenedor, puedes usar el framework Container Structure Tests.

Establece la seguridad al principio de los flujos de trabajo

Implementa controles de seguridad lo antes posible en el ciclo de vida del desarrollo. Si detectas los riesgos de seguridad antes de crear artefactos o de implementar, puedes reducir el tiempo y el coste necesarios para abordar estos riesgos.

Para conseguir una detección temprana, puedes implementar las siguientes medidas de seguridad en tus flujos de procesamiento:

  • Exige que los expertos en la materia revisen el código integrado en tu repositorio de producción.

  • Implementa el análisis estático de código y el linting al principio del flujo de procesamiento. Estas pruebas te ayudan a detectar puntos débiles, como la falta de escape de entradas, la aceptación de datos de entrada sin procesar para consultas SQL o vulnerabilidades en tu código.

  • Analiza las vulnerabilidades de la imagen de contenedor compilada con el análisis de vulnerabilidades.

  • Evita que se desplieguen en tus clústeres imágenes que contengan vulnerabilidades mediante la autorización binaria. Para usar Autorización binaria, se necesita una suscripción a GKE Enterprise. Para que tengas más confianza en las imágenes generadas, la autorización binaria también te permite requerir atestaciones de diferentes entidades o sistemas. Por ejemplo, estas certificaciones podrían incluir lo siguiente:

    • Ha superado el análisis de vulnerabilidades
    • Ha superado las pruebas de control de calidad
    • Firma del propietario del producto

Entrega continua

La entrega continua (CD) te permite lanzar código en cualquier momento. La entrega continua se basa en el artefacto producido por las pipelines de integración continua. Los flujos de procesamiento de CD pueden ejecutarse durante mucho más tiempo que los de CI, sobre todo si utilizas estrategias de despliegue más elaboradas, como los despliegues azul-verde.

Usar la metodología GitOps

GitOps es el concepto de infraestructura declarativa almacenada en repositorios de Git y las herramientas de CI/CD para implementar esa infraestructura en tu entorno. Cuando usas una metodología GitOps, te aseguras de que todos los cambios en tus aplicaciones y clústeres se almacenen en repositorios de origen y estén siempre accesibles.

Si utilizas metodologías GitOps, disfrutarás de las siguientes ventajas:

  • Puedes revisar los cambios antes de que se implementen mediante solicitudes de combinación o extracción.
  • Tienes una única ubicación que puedes usar para consultar el estado de tus aplicaciones y clústeres en cualquier momento.
  • Las instantáneas de tus clústeres y aplicaciones facilitan la recuperación cuando se producen fallos.

Algunas de las herramientas más habituales para la infraestructura declarativa son Terraform de Hashicorp y Config Connector de Google Cloud. Para practicar cómo gestionar la infraestructura con GitOps y otras herramientas, consulta el tutorial Gestionar la infraestructura como código con Terraform, Cloud Build y GitOps. Para saber cómo gestionar aplicaciones al estilo de GitOps, prueba la guía Entrega continua tipo GitOps con Cloud Build.

Promocionar imágenes de contenedor en lugar de recompilarlas

Las imágenes de contenedor no se deben volver a compilar a medida que pasan por las diferentes fases de un flujo de procesamiento de CI/CD. La recompilación puede introducir pequeñas diferencias entre las ramas de código. Estas diferencias pueden provocar que tu aplicación falle en producción o que se añada código sin probar por error en la imagen del contenedor de producción. Para asegurarte de que la imagen de contenedor que has probado es la que vas a desplegar, lo mejor es compilarla una vez y promocionarla en tus entornos. En estas recomendaciones se da por hecho que mantienes la configuración específica de cada entorno separada de los paquetes.

Considera la posibilidad de usar patrones de implementación y pruebas más avanzados

GKE te ofrece la flexibilidad de desplegar y probar tus aplicaciones con varios patrones. El patrón de implementación que elijas dependerá en gran medida de tus objetivos de negocio. Por ejemplo, puede que necesites implementar cambios sin tiempo de inactividad o implementar cambios en un entorno o en un subconjunto de usuarios antes de que una función esté disponible para todos.

Estos son algunos de los patrones de implementación disponibles:

  • Recrear una implementación: reduces por completo la versión de la aplicación actual antes de aumentar la nueva versión.

  • Implementación de actualizaciones continuas: actualizas un subconjunto de instancias de la aplicación en ejecución en lugar de actualizar todas las instancias de la aplicación en ejecución a la vez. Después, actualiza progresivamente más instancias de la aplicación en ejecución hasta que se hayan actualizado todas.

  • Implementación azul-verde: implementas un conjunto paralelo adicional de instancias en tus instancias de producción con una versión actualizada de tu aplicación. Cuando esté listo para implementar, cambie el tráfico a las nuevas instancias.

Clústeres independientes para diferentes entornos

La separación de entornos es un factor importante en cualquier destino de implementación. Lo ideal es que tengas clústeres independientes para cada uno de los siguientes entornos:

  • Entorno de desarrollo: es el entorno en el que tus desarrolladores implementan aplicaciones para realizar pruebas y experimentos. Estas implementaciones requieren la integración con otras partes de la aplicación o del sistema (por ejemplo, una base de datos). Los clústeres de este entorno suelen tener menos puertas y los desarrolladores tienen más control sobre su configuración.

  • Entornos de preproducción (staging o control de calidad): estos entornos deben parecerse lo máximo posible al entorno de producción. Se usan para hacer pruebas a gran escala de cambios como pruebas de integración, de carga, de rendimiento o de regresión.

  • Entorno de producción: es el entorno en el que se ejecutan tus cargas de trabajo de producción y las aplicaciones y los servicios orientados a los usuarios.

Mantener los entornos de preproducción lo más parecidos posible a los de producción

Lo ideal es que los clústeres de preproducción sean idénticos a los de producción, pero, por motivos de costes, pueden ser réplicas a menor escala. Si los clústeres son similares, las pruebas se realizarán en condiciones iguales o parecidas a las de producción. La paridad entre los clústeres de preproducción y producción también reduce la probabilidad de que se produzcan fallos inesperados debido a diferencias en el entorno al implementar en producción.

La infraestructura declarativa y GitOps te ayudan a conseguir una mayor paridad entre tus entornos, ya que puedes duplicar más fácilmente la configuración de tu clúster subyacente. Para asegurarte de que tus entornos tengan condiciones similares para las políticas y las configuraciones, también puedes usar herramientas como Config Sync.

Prepararse para los fallos en producción

Ninguna cantidad de pruebas puede garantizar el comportamiento adecuado de tu aplicación en producción. Los errores pueden deberse a casos límite con datos que no se han tenido en cuenta o a patrones de acceso de los usuarios que no se han probado. Es importante monitorizar tu aplicación en producción y tener mecanismos de reversión e implementación automatizados para poder reaccionar rápidamente y corregir errores o interrupciones. Si usas estrategias de implementación más sólidas, podrás reducir el impacto de los problemas y afectar a menos usuarios finales cuando surjan problemas en producción.

Resumen de la lista de comprobación

En la siguiente tabla se resumen las tareas que te recomendamos que realices cuando uses una canalización de CI/CD en GKE:

Área Tasks
Integración continua
Entrega continua

Siguientes pasos