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

En esta guía, se describe un conjunto de prácticas recomendadas para la integración continua y la entrega continua (CI/CD) en Google Kubernetes Engine (GKE). Estas prácticas abordan una amplia gama de temas, desde el control de la fuente hasta las estrategias de implementación. Estas prácticas recomendadas son específicas de GKE y aún se aplican las prácticas recomendadas generales de CI/CD. Para obtener más información, consulta 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 sus cambios de código de nuevo en una rama principal con la mayor frecuencia posible. Está destinado a permitir fallas más rápidas, ya que expone problemas lo antes posible en el proceso. Por lo general, los desarrolladores que envían los cambios de código activan las canalizaciones de CI. La canalización incluye los pasos para validar esos cambios, como el análisis con lint, las pruebas y las compilaciones. Por lo general, una canalización de CI produce un artefacto que puedes implementar en etapas posteriores del proceso de implementación.

Crea canalizaciones que habiliten una iteración rápida

El tiempo que transcurre desde que un desarrollador realiza un cambio de código y el momento que tienes una versión de la aplicación en ejecución debe ser lo más breve posible. Esta velocidad es muy importante durante el desarrollo en las ramas de funciones que involucran una iteración rápida por parte de los desarrolladores. Lo ideal sería que las canalizaciones de CI se ejecuten en menos de 10 minutos. Si eso no es posible, crea dos tipos de canalizaciones de CI:

  • Canalizaciones rápidas: Por lo general, estas canalizaciones se ejecutan en 10 minutos o menos. Estas canalizaciones son para ramas de funciones y no deben interpretarse como completas. Las canalizaciones rápidas pueden producir artefactos inestables.

  • Canalizaciones completas: Estas canalizaciones pueden tardar más de 10 minutos en ejecutarse y ejecutan pruebas y verificaciones más detalladas. Las canalizaciones completas se ejecutan en solicitudes de extracción o combinación y se confirman en la rama principal.

Sigue las prácticas recomendadas para compilar contenedores

Si deseas crear imágenes más pequeñas y resilientes, y facilitar la compilación y ejecución de los contenedores, asegúrate de seguir las prácticas recomendadas para compilar contenedores.

Prueba las imágenes de contenedor

Como parte de las canalizaciones de CI, asegúrate de ejecutar todas las pruebas requeridas en el código y compilar artefactos. Estas pruebas deben incluir pruebas de unidades, funcionales, de integración y de carga o rendimiento.

También es importante probar la estructura de las imágenes de contenedor compiladas. Probar la estructura garantiza que todos los comandos se ejecuten como esperas dentro del contenedor. Las pruebas también te permiten verificar que los archivos específicos estén en la ubicación correcta y que tengan el contenido correcto.

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

Establece la seguridad anticipada en las canalizaciones

Debes realizar balances y controles de seguridad lo antes posible en el ciclo de vida del desarrollo. Cuando encuentras riesgos de seguridad antes de compilar artefactos o realizar la implementación, puedes reducir el tiempo y el costo a fin de abordar estos riesgos.

Para ayudar a lograr la detección temprana, puedes implementar las siguientes medidas de seguridad en las canalizaciones:

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

  • Implementar el análisis con lint y el análisis del código estático de forma anticipada en la canalización. Esta prueba te ayuda a encontrar debilidades, como no escapar entradas, aceptar datos de entrada sin procesar para consultas de SQL o vulnerabilidades en el código.

  • Analizar la imagen del contenedor compilada para detectar vulnerabilidades con el análisis de vulnerabilidades.

  • Evitar que las imágenes que contienen vulnerabilidades se implementen en los clústeres mediante la autorización binaria. La autorización binaria requiere una suscripción a GKE Enterprise. Para proporcionarte una mayor confianza en las imágenes producidas, la autorización binaria también te permite exigir certificaciones por entidades o sistemas diferentes. Por ejemplo, estas certificaciones pueden incluir lo siguiente:

    • El análisis de vulnerabilidades aprobado
    • Las pruebas de control de calidad aprobadas
    • La aprobación del propietario del producto

Entrega continua

La entrega continua (CD) te permite liberar el código en cualquier momento. La CD opera en el artefacto que producen las canalizaciones de CI. Las canalizaciones de CD pueden ejecutarse durante mucho más tiempo que las canalizaciones de CI, en especial si usas estrategias de implementación más elaboradas, como las implementaciones azul-verde.

Usa la metodología de GitOps

GitOps es el concepto de infraestructura declarativa que se almacena en los repositorios de Git y las herramientas de CI/CD para implementar esa infraestructura en el entorno. Cuando usas una metodología de GitOps, garantizas que todos los cambios en las aplicaciones y los clústeres se almacenen en repositorios de origen y que siempre sean accesibles.

Usar metodologías de GitOps te ofrece las siguientes ventajas:

  • Puedes revisar los cambios antes de que se implementen a través de solicitudes de combinación o extracción.
  • Tienes una ubicación única que puedes usar para hacer referencia al estado de las aplicaciones y los clústeres en cualquier momento.
  • Las instantáneas de los clústeres y las aplicaciones facilitan la recuperación cuando hay fallas.

Para obtener más información sobre la metodología de GitOps y los diferentes patrones que puedes usar en los repositorios de origen, consulta Conceptos de GitOps.

Algunas herramientas comunes que se usan en la infraestructura declarativa son Terraform de Hashicorp y Config Connector de Google Cloud. Si deseas adquirir experiencia práctica para administrar la infraestructura con GitOps y otras herramientas, prueba el instructivo Administra la infraestructura como código con Terraform, Cloud Build y GitOps. Para aprender a administrar aplicaciones en el estilo de GitOps, prueba la entrega continua tipo GitOps con Cloud Build.

Promueve imágenes de contenedor, en lugar de volver a compilarlas

Las imágenes de contenedor no se deben volver a compilar una vez que pasen por las diferentes etapas de una canalización de CI/CD. Volver a compilar puede introducir pequeñas diferencias en las ramas del código. Estas diferencias pueden hacer que la aplicación falle en la producción o genere la adición accidental del código no probado en la imagen del contenedor de producción. A fin de garantizar que la imagen del contenedor que probaste sea la imagen de contenedor que implementas, es mejor compilar una sola vez y, luego, promover los entornos. En esta recomendación, se supone que conservas la configuración específica del entorno separada de los paquetes, como se indica en las prácticas recomendadas para compilar contenedores.

Considera usar patrones de implementación y prueba más avanzados

GKE te ofrece la flexibilidad de implementar y probar las aplicaciones mediante varios patrones. El patrón de implementación que elijas depende en gran medida de los objetivos empresariales. Por ejemplo, es posible que debas 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 el público general.

Algunos de los diferentes patrones de implementación disponibles para ti incluyen los siguientes:

  • Vuelve a crear una implementación: Reduces por completo la escala de la versión de la aplicación existente antes de escalar verticalmente la versión nueva.

  • Implementación de la actualización progresiva: Actualizas un subconjunto de instancias de la aplicación en ejecución en lugar de actualizar todas a la vez. Luego, actualizas de forma progresiva más instancias de la aplicación en ejecución hasta que estén todas actualizadas.

  • Implementación azul-verde: Implementas un conjunto paralelo adicional de instancias en las instancias de producción existentes con una versión actualizada de la aplicación. Cambia el tráfico a las instancias nuevas cuando estés listo para implementar.

Para obtener más información sobre estas estrategias, consulta Estrategias de implementación y prueba de aplicaciones.

Clústeres separados para diferentes entornos

La separación de los entornos es una consideración importante para cualquier destino de implementación. Lo ideal sería tener clústeres separados para cada uno de los siguientes entornos:

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

  • Entornos de producción previa (etapa de pruebas o control de calidad): Estos entornos deben parecerse al entorno de producción de la mejor manera posible. Se usan para realizar pruebas a gran escala de cambios, como pruebas de integración, carga, rendimiento o regresión.

  • Entorno de producción: Aquí es donde se ejecutan las cargas de trabajo de producción y los servicios y aplicaciones para el usuario.

Para obtener más información sobre estos entornos, consulta la sección sobre entornos en Kubernetes y los desafíos de la entrega continua de software.

Mantén los entornos de producción previa cerca de la producción

Lo ideal es que los clústeres de producción previa sean idénticos a los clústeres de producción, pero por razones de costos los clústeres de producción previa se pueden reducir a réplicas. Mantener los clústeres similares garantiza que se realicen pruebas en las mismas condiciones o en condiciones similares a las de la producción. La paridad entre clústeres de producción previa y de producción también reduce la probabilidad de fallas inesperadas debido a diferencias de entornos cuando se implementa a la producción.

La infraestructura declarativa y GitOps te ayudan a lograr una paridad más cercana de los entornos, ya que puedes duplicar la configuración del clúster subyacente con mayor facilidad. Para garantizar que los entornos tengan condiciones similares para las políticas y las opciones de configuración, también puedes usar herramientas como el Sincronizador de configuración.

Prepárate para las fallas en producción

Ninguna cantidad de pruebas puede garantizar el comportamiento adecuado de la aplicación en producción. Las fallas pueden deberse a casos de perímetro con datos que no se consideraron o patrones de acceso de los usuarios que no se probaron. Es importante supervisar la aplicación en producción y contar con mecanismos de implementación y reversión automatizados para que puedas reaccionar y corregir errores o interrupciones con rapidez. Usar estrategias de implementación más sólidas te permite reducir el impacto de los problemas y afectar a la menor cantidad de usuarios finales cuando surgen problemas en la producción.

Resumen de la lista de tareas

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

Área Tareas
Integración continua
Entrega continua

¿Qué sigue?