CI/CD moderna con GKE: un marco de trabajo de entrega de software

En este documento, se describe un marco de trabajo para implementar procesos modernos de integración continua y entrega continua (CI/CD) en una plataforma de entrega de software de varios equipos que usa Google Kubernetes Engine.

Luego, puedes iterar en la plataforma a fin de mejorar aún más el rendimiento para el desarrollo y las operaciones, incluida la velocidad de lanzamiento, la confiabilidad de la plataforma y el tiempo de recuperación ante fallas.

Este documento forma parte de una serie:

Este documento está dirigido a arquitectos empresariales y desarrolladores de aplicaciones, así como a los equipos de ingeniería de confiabilidad de sitios, DevOps y seguridad de TI. Es útil tener experiencia en herramientas y procesos de implementación automatizados para comprender los conceptos de este documento.

Un caso de CI/CD moderna

La CI/CD es un enfoque de desarrollo de software que te permite automatizar las fases de compilación, prueba y, también, implementación de desarrollo de software mediante una serie de herramientas y procesos repetidos.

Además de la automatización de CI/CD, Kubernetes y contenedores permitieron que las empresas obtengan mejoras sin precedentes en la velocidad de desarrollo y de implementación. Aun así, incluso a medida que crece la adopción de contenedores y Kubernetes, muchas organizaciones no aprovechan por completo los beneficios de la velocidad de la actualización, la estabilidad y las eficiencias operativas, ya que sus prácticas de CI/CD no aprovechan al máximo Kubernetes o abordan operaciones y problemas de seguridad.

Un enfoque de CI/CD realmente moderna necesita abarcar más que solo automatización. Para obtener todos los aspectos de la velocidad y seguridad, y usar potencia de Kubernetes y los contenedores, debes optimizar la integración de las aplicaciones, las prácticas de CI/CD y los procesos operativos.

Tu organización puede obtener los siguientes beneficios en relación con el desarrollo y las operaciones gracias a la infraestructura coherente que ofrece la plataforma de GKE, los métodos uniformes de CI/CD y las prácticas recomendadas de implementación:

  • Reducir el plazo de entrega para los cambios.

    • Permitir que los equipos de operaciones y seguridad creen y actualicen las prácticas recomendadas para aprovisionar aplicaciones y la política de aprovisionamiento en toda la plataforma.

    • Para simplificar la integración de aplicaciones, brinda a los equipos la funcionalidad completa y los proyectos de inicio implementables que tengan las prácticas recomendadas integradas de tu organización.

  • Disminuir el tiempo requerido para restablecer el servicio

    • Administrar toda la configuración de forma declarativa con GitOps para auditorías, reversión y revisión simplificadas.

    • Estandarizar las metodologías de implementación y supervisión en toda la organización para reducir el tiempo que lleva identificar los factores colaboradores de un problema que afecta el servicio.

  • Aumentar la frecuencia de implementación.

    • Asegurarse de que los desarrolladores de aplicaciones puedan iterar de forma independiente en sus propias zonas de pruebas de desarrollo (o zonas de destino) sin interferir entre sí.

    • Usar GitOps para la implementación, mejoras en la administración de versiones y el seguimiento de cambios.

    • Implementar vías de seguridad para que los equipos de servicio puedan implementar con frecuencia.

    • Crear un proceso de lanzamiento progresivo a fin de implementar de manera coherente en entornos de producción previa, lo que brinda la confianza a los desarrolladores para implementar cambios en la producción.

Para ver cómo se abordan estos conceptos, conceptos con GKE y CI/CD, consulta los otros documentos de esta serie:

Evalúa la preparación para un enfoque moderno

Antes de implementar herramientas y procesos de CI/CD moderna con GKE, debes evaluar si tu organización y los equipos están listos para adoptar una plataforma nueva.

Rasgos organizacionales

Adoptar una plataforma moderna requiere la siguiente asistencia de tu líder de negocios y equipos técnicos:

  • Patrocinador de liderazgo. Adoptar una plataforma de entrega de software suele ser un gran esfuerzo realizado por varios equipos multifuncionales. El proceso suele dar como resultado cambios en las funciones y responsabilidades, así como en las prácticas de desarrollo de software. Para tener éxito en la adopción de estas herramientas y técnicas, necesitas una gran asistencia de uno o más miembros del equipo líder. Los patrocinadores de liderazgo más eficaces son aquellos que ven estos cambios como un proceso continuo de mejora y desean capacitar a sus equipos en lugar de administrarlos.

  • Alineación técnica y de estrategia comercial. Recomendamos que tus equipos comerciales y equipos técnicos se alinean en las cuatro medidas clave de entrega de software que define Investigación y evaluación de DevOps (DORA): plazo de entrega para los cambios, frecuencia de implementación, tiempo a fin de restablecer el servicio y cambio en la tasa de fallas. Alinear esas medidas les brinda a tus equipos comerciales y técnicos un objetivo común, lo que les permite calcular de forma conjunta el retorno de la inversión, ajustar la tasa de cambio y modificar el nivel de inversión.

  • Recursos Para tener éxito, los equipos que desarrollan prácticas de CI/CD moderna y compilan cadenas de herramientas necesitan los recursos necesarios: tiempo, infraestructura y personas. Estos equipos necesitan tiempo para probar y seleccionar los mejores procesos y herramientas. Lo ideal sería que estos equipos representen diversas funciones diferentes en el proceso de entrega de software y puedan incorporar otros recursos en toda la organización. Por último, los equipos necesitan la capacidad de aprovisionar infraestructura, incluidos los recursos en la nube y las herramientas de software.

  • Amplitud para adoptar nuevas herramientas. Las herramientas y técnicas de CI/CD modernas suelen acompañar las nuevas herramientas y procesos. Los equipos deben experimentar con esos procesos y herramientas y estar dispuestos a adoptarlos. Se necesita un Ciclo de reacción para que los equipos de la plataforma puedan escuchar a los equipos de aplicaciones, operaciones y seguridad que usan la plataforma.

  • Preparación cultural Para tener éxito con la implementación y la adopción de un sistema CI/CD moderna con GKE, la organización y los equipos técnicos que desarrollan el sistema deben estar preparados para cambiar la forma en que operan y trabajan juntos. Por ejemplo, los equipos de desarrollo y operaciones deben estar dispuestos a trabajar con más responsabilidad para la seguridad, y los equipos de seguridad y operaciones deben estar dispuestos a simplificar los procesos de aprobación de cambios.

Capacidades técnicas

Adoptar un enfoque de CI/CD moderna también requiere que tus equipos estén técnicamente preparados de las siguientes maneras:

  • Experiencia en contenedores. Los equipos que adoptan enfoques de CI/CD moderna necesitan cierta experiencia en los contenedores. Lo ideal es que esta experiencia incluya técnicas de desarrollo para compilar imágenes de contenedor y combinar contenedores a fin de compilar sistemas más grandes.

  • Estrategia de integración continua. Los equipos necesitan cierta experiencia en herramientas de CI (como Jenkins, TeamCity, Bamboo y CircleCI) y realizar algunas integraciones continuas y pruebas automatizadas. Recomendamos a las organizaciones que planifiquen mejorar aún más esos procesos.

  • Automatización de la implementación. Los equipos necesitan cierta experiencia en la automatización de implementaciones. Algunos ejemplos de herramientas de implementación automatizadas incluyen secuencias de comandos de shell básicas, Terraform, Chef o Puppet. Tener un conocimiento del modelo de referencia de las herramientas y los procesos de implementación automatizados es fundamental para optimizar y automatizar las implementaciones.

  • Arquitecturas orientadas al servicio. Si bien no es un requisito para la adopción de procesos de CI/CD moderna, la adopción de arquitecturas modulares y orientadas al servicio debe ser un objetivo a largo plazo de las organizaciones. que desean adoptar herramientas y técnicas CI/CD moderna con GKE. Se demostró que las arquitecturas basadas en servicios mejoran la velocidad y la confiabilidad.

  • Control de fuente moderno. Las herramientas de control de código fuente modernas, como Git, permiten a los equipos establecer flujos de trabajo como desarrollo basado en troncales, ramas de funciones y solicitudes de combinación.

Diseña CI/CD modernas con GKE

En esta sección, se describe una plataforma de entrega de software y sus componentes. Para mejorar el rendimiento de la entrega de software, debes implementar CI/CD y otras prácticas recomendadas técnicas que permiten a los equipos realizar lanzamientos con rapidez y operar de manera eficiente.

En esta sección, también se analiza la infraestructura necesaria para admitir el ciclo de vida de la entrega de software y cómo administrar esa infraestructura de forma coherente con GKE. Por último, en esta sección, se proporciona un ejemplo del flujo de trabajo de entrega de software y se muestra cómo los repositorios de inicio simplifican la integración y la implementación de las prácticas recomendadas. Se revisan las siguientes consideraciones de diseño:

  • Plataforma de entrega de software. Es el framework y las capacidades técnicas que forman la base de un proceso de lanzamiento de aplicaciones de alta velocidad confiable.

  • Infraestructura de la plataforma. Son los componentes de la infraestructura y las consideraciones de administración que necesitas para compilar la plataforma y ejecutar tus aplicaciones.

  • Flujo de trabajo de entrega de software. Cómo trabajan los equipos en conjunto para compilar, implementar y probar el código de forma más eficiente.

  • Repositorios de código. Repositorios que realizan varias funciones, incluido el almacenamiento de la lógica empresarial real, la configuración específica de la aplicación y el código para crear infraestructura. También podrían ser repositorios iniciales que facilitar la adopción de prácticas recomendadas y ayudar a mantener la coherencia en los procesos automatizados.

  • Zonas de destino de las aplicaciones. Una entidad lógica que permite a los desarrolladores implementar y, luego, iterar de manera autónoma en sus aplicaciones mediante la infraestructura de defensa que implementaron.

  • Modelo operativo. Herramientas, procesos y métodos técnicos para administrar la infraestructura y las aplicaciones que conforman la plataforma.

  • Administración. Procesos y consideraciones que necesitas para mantener y administrar la plataforma de entrega de software.

Plataformas de entrega de software

Una plataforma de entrega de software unifica las herramientas y optimiza los procesos necesarios para compilar, entregar, implementar y operar aplicaciones.

La responsabilidad de mantener la configuración, la estabilidad, el tiempo de actividad y el escalamiento de una aplicación varían según los operadores, la seguridad y los equipos de desarrolladores. Sin embargo, todos los componentes y equipos deben trabajar en conjunto para acelerar los lanzamientos. Aunque este documento describe métodos para mejorar la administración del control de la fuente y la observabilidad de la aplicación, se enfoca principalmente en la integración continua (CI), la entrega continua (CD) y la administración de configuración.

Para compilar una plataforma completa de entrega de software, necesitas cada componente en el siguiente diagrama:

Equipos especiales pueden compartir o realizar la administración de la plataforma.

Cada uno de estos componentes proporciona funcionalidad para el sistema y las aplicaciones que se ejecutan en la plataforma:

  • Supervisión de la infraestructura. El nivel de supervisión necesario para el aprovisionamiento a fin de verificar el funcionamiento correcto de los clústeres de Google Kubernetes Engine (GKE), instancias de máquina virtual (VM) y otras infraestructuras necesarias para que funcionen las aplicaciones.

  • Organización de contenedores. Es la plataforma que coordina la implementación y el funcionamiento de las aplicaciones basadas en contenedores. Algunos ejemplos de plataformas para la organización de contenedores son Kubernetes, GKE o GKE Enterprise.

  • Container Registry. Control de almacenamiento y acceso para imágenes de contenedor.

  • CI. Proceso de aplicación de tareas automatizadas a una aplicación antes de la implementación. Las tareas de CI generalmente incluyen la compilación, el empaquetado y las pruebas. Los tipos de tareas varían según la aplicación y la organización.

  • CD. Procesos de implementación que están altamente automatizados y aplicados con frecuencia alta. Las metodologías de ejemplo incluyen aprobaciones manuales, implementación de versiones canary, implementaciones azul-verde o implementaciones progresivas.

  • Políticas. Políticas de seguridad y configuración de la infraestructura definidas por los equipos de operaciones y seguridad y que la plataforma aplica de manera continua.

  • Administración del código fuente: Por ejemplo, el almacenamiento controlado por versiones para códigos, archivos de configuración y definiciones de políticas. En un sistema de CI/CD moderna, la administración del código fuente suele ser Git.

  • Administración de configuración. El sistema que se usa para almacenar y aplicar la configuración de la aplicación para distintos entornos.

  • Observabilidad de la aplicación. Los registros a nivel de la aplicación, la supervisión, la alerta y el seguimiento que los equipos de desarrolladores, de operadores y de seguridad usan para solucionar y verificar la operación correcta de las aplicaciones.

Infraestructura de la plataforma

Para compilar una plataforma de entrega de software escalable, necesitas clústeres de Kubernetes para desarrollo, entornos de producción previa y varios clústeres de producción. Los clústeres pueden entregar muchas funciones diferentes:

  • Desarrollo. En estos clústeres, los desarrolladores realizan implementaciones ad hoc de sus aplicaciones para realizar experimentos y pruebas.

  • El entorno de aplicaciones.

    • Producción previa. Por cada entorno de producción previa en tu flujo de trabajo, debes tener un clúster de Kubernetes para alojar tus aplicaciones. Estos clústeres deben parecerse a los clústeres de producción, de modo que puedas reducir o eliminar las diferencias entre los entornos y, como resultado, mejorar las tasas de éxito de la implementación.

    • Producción. Estos clústeres ejecutan tus cargas de trabajo de producción. Debes usar varios clústeres distribuidos geográficamente. Esto mejora la confiabilidad de las fallas de infraestructura y facilita las preocupaciones de las operaciones del Día 2, como el escalamiento y la actualización del clúster.

En el siguiente diagrama, se muestra la arquitectura de alto nivel: Tres clústeres abarcan dos regiones de Google Cloud.

En esta arquitectura, administras los clústeres para cada entorno a través de Sincronizador de configuración. La configuración coherente del clúster es fundamental porque brinda a los equipos de desarrolladores, operadores y seguridad la confianza de que los entornos de producción previa y producción operan de forma similar. Puedes usar el Sincronizador de configuración para almacenar y aplicar opciones de configuración comunes en tu flota de clústeres. Después de que la configuración del clúster esté estandarizada, auditable y escalable, puedes enfocarte en el flujo de trabajo de entrega de software y en la integración y la implementación de las aplicaciones.

Administras tus implementaciones en clústeres de desarrollo, etapa de pruebas y producción a través de la de CI/CD de tu aplicación. La administración del control de origen funciona como el punto de coordinación para el código de la aplicación y la configuración. Las canalizaciones de CI/CD y las imágenes de contenedor de una aplicación se aíslan en su entorno. Puedes inicializar los repositorios de aplicación y configuración mediante repositorios de inicio y herramientas automatizadas. Por ejemplo, puedes usar Cloud Build para ejecutar Terraform para incorporar e inicializar aplicaciones nuevas de forma automática.

Implementarás aplicaciones en sus propias zonas de destino en cada clúster, para que las aplicaciones estén aisladas de la red y de la identidad. Al usar el Sincronizador de configuración, inicializarás las zonas de destino de aplicación en todos los entornos. Además, usarás Cloud Service Mesh o Ingress de varios clústeres para hacer que los clústeres de producción parezcan un clúster cuando crees una malla de redes que abarque varios clústeres.

Flujo de trabajo de entrega de software

Un componente central de la plataforma de entrega de software es el sistema de CI/CD. Cuando los compiladores de plataformas comienzan a definir el proceso de CI/CD, necesitan asegurarse de que cada componente produzca o use artefactos que cumplan con una interfaz estandarizada. El uso de una interfaz estandarizada simplifica el reemplazo de componentes cuando llega una mejor implementación al mercado.

Cuando creas una plataforma para aplicaciones alojadas en contenedores, puedes usar las tres interfaces estandarizadas entre los componentes: repositorios de Git, imágenes de Docker y manifiestos de Kubernetes. Estas interfaces te permiten crear una canalización de CI/CD reutilizable y flexible con un flujo de trabajo de desarrollo, compilación y lanzamiento, como se muestra en el siguiente diagrama:

Las etapas del flujo de trabajo incluyen la confirmación, la generación, la salida y el almacenamiento.

Este flujo de trabajo funciona de la siguiente manera:

  1. Los desarrolladores confirman el código de la aplicación en los repositorios de código.

  2. El sistema de CI prueba el código, crea un artefacto de imagen de Docker y almacena la imagen en un registro.

  3. Una vez que el artefacto está listo para su implementación, se le agrega una referencia a la configuración de la aplicación.

  4. La configuración de la aplicación se renderiza en un formato legible en Kubernetes y se almacena en un repositorio de código. Las actualizaciones de este repositorio activan una canalización de implementación que implemente los artefactos en un entorno de desarrollo integrado.

  5. Una vez realizadas las pruebas en el entorno de desarrollo integrado, los operadores promueven la implementación en el entorno de preproducción.

  6. Después de asegurarse de que la aplicación funciona como se espera en el entorno de preproducción, los operadores obtienen las aprobaciones en la canalización de implementación y promueven el lanzamiento al entorno de producción.

  7. Cuando los operadores realizan cambios en las configuraciones base, estos se aplican en toda la organización. A medida que los operadores confirman los cambios en sus repositorios, las actualizaciones de configuración de aplicaciones (y las implementaciones posteriores) se pueden activar de manera automática. Como alternativa, los cambios de los operadores se pueden obtener la próxima vez que los desarrolladores implementen sus cambios.

  8. Al mismo tiempo, los ingenieros de seguridad pueden implementar y ajustar las políticas que definen lo que se puede implementar y, luego, confirmarlas en su repositorio de políticas.

Mediante una metodología de GitOps, puedes requerir un enfoque declarativo para cualquier cambio en las aplicaciones y los clústeres. Con este enfoque, todos los cambios están sujetos a auditorías y revisiones antes de que puedan aplicarse. En este modelo declarativo, debes almacenar tus archivos de configuración en un repositorio de Git, que te permita mantener un registro de cambios, revertir implementaciones fallidas y ver el impacto potencial de los cambios propuestos.

En la arquitectura de referencia asociada, debes usar kustomize para controlar las configuraciones de la aplicación en tu organización. La herramienta kustomize permite que los operadores creen bases de aplicaciones que los equipos de desarrollo pueden ajustar sin necesidad de agregar o cambiar el código en la base. Mediante la definición de configuraciones base, los equipos de la plataforma pueden crear y, luego, iterar sobre las prácticas recomendadas para la organización. Los operadores y los desarrolladores pueden iterar en sus implementaciones de forma independiente, y los desarrolladores apliquen las prácticas recomendadas que configuran los operadores. Cuando los operadores necesiten implementar una práctica recomendada nueva para la organización, realizarán el cambio en la base y este se incorporará automáticamente en la siguiente implementación de los desarrolladores.

Repositorios de código

Los repositorios de código fuente son el centro del sistema de CI/CD. Los operadores, los desarrolladores y los ingenieros de seguridad tienen sus propios repositorios para propagar los cambios en la plataforma. Usar un repositorio de Git como base para todos los cambios en el sistema proporciona diversos beneficios:

  • Auditabilidad integrada. Las confirmaciones contienen información sobre cuándo, qué y quién cambió el sistema.

  • Un proceso de reversión simplificado. La capacidad de reversión de Git te permite revertir a un estado anterior del sistema.

  • Control de versiones. Puedes etiquetar confirmaciones de Git para denotar una versión del estado del sistema.

  • Transacciones. Debes resolver los conflictos de estado de forma explícita y revisarlos antes de que puedas integrar los cambios en el estado.

En el siguiente diagrama, se muestra cómo interactúan varios equipos con un repositorio centralizado para todos los cambios:

Los repositorios incluyen aquellos para prácticas recomendadas y configuración de aplicaciones y plataformas.

En las siguientes secciones, se explica cómo los ingenieros, ingenieros y desarrolladores de seguridad emplean el repositorio de Git en un sistema de CI/CD moderna.

Repositorios de operadores

Los repositorios administrados por operadores contienen recomendaciones para la configuración de CI/CD y la configuración de la aplicación a fin de ayudar a los equipos a incorporar aplicaciones y adoptar las prácticas recomendadas desde el principio. Con los operadores que administran repositorios, los desarrolladores pueden consumir las actualizaciones de las prácticas recomendadas de la organización con la menor interrupción posible en su flujo de trabajo.

Los operadores pueden codificar las prácticas recomendadas de sus organizaciones en dos repositorios. El primer repositorio es el lugar en el que los operadores mantienen las prácticas recomendadas de canalización de CI/CD compartidas. En este repositorio, los operadores proporcionan a los desarrolladores una biblioteca de tareas predefinidas que pueden usar para compilar sus canalizaciones. Los repositorios de la aplicación de los desarrolladores heredan automáticamente estas tareas y la lógica que las contiene. Las tareas no necesitan copiarse de forma manual. Estos son algunos ejemplos de las tareas que puedes estandarizar en toda la organización:

  • Construcción y almacenamiento de artefactos

  • Metodologías de prueba para varios lenguajes

  • Pasos para la implementación

  • Verificaciones de políticas

  • Análisis de seguridad

El segundo repositorio que los operadores mantienen almacena las prácticas recomendadas para configurar una aplicación. En el contexto de GKE, las prácticas recomendadas son una manera de garantizar una forma de administrar los manifiestos declarativos en el modelo de recursos de Kubernetes. Estos manifiestos describen el estado previsto de la aplicación. Los operadores pueden crear configuraciones básicas para diferentes tipos de aplicaciones, lo que proporciona a los desarrolladores una ruta optimizada a fin de implementar sus aplicaciones de acuerdo con las prácticas recomendadas de la organización.

Repositorios de las aplicaciones

Los repositorios de las aplicaciones almacenan la lógica empresarial de la aplicación y cualquier configuración especializada que se necesite para que la aplicación funcione de forma correcta.

A medida que los operadores crean y mantienen las prácticas recomendadas de manera codificada, los desarrolladores pueden usarlas. Para ello, los desarrolladores hacen referencia a las tareas de CI/CD y las bases de aplicaciones que los operadores crearon en sus propios repositorios. Después de realizar los cambios, los operadores pueden personalizar aún más la implementación de la aplicación mediante el agregado de configuraciones específicas del entorno, como URL de bases de datos o etiquetas de recursos y anotaciones.

Los siguientes son algunos ejemplos de los artefactos que puedes almacenar en repositorios de aplicaciones:

  • Código fuente de la aplicación

  • Un Dockerfile que describe cómo compilar y ejecutar la aplicación

  • La definición de la canalización de CI/CD

  • Extensiones o modificaciones en las bases de configuración de la aplicación los operadores crearon

Infraestructura como repositorios de código

La infraestructura como repositorios de código almacena el código para compilar la infraestructura necesaria para ejecutar las aplicaciones. La infraestructura puede incluir redes y plataformas de organización de contenedores, como GKE. Por lo general, los administradores de infraestructura son propietarios de estos repositorios. Los operadores pueden actualizarlos para implementar las prácticas recomendadas.

Los siguientes son algunos ejemplos de los artefactos que puedes almacenar en repositorios de aplicaciones:

  • Código de lenguaje declarativo (Terraform, Pulumi) que representa objetos de infraestructura

  • Secuencias de comandos de Shell o Python que complementan las definiciones declarativas de la API.

  • Extensiones o modificaciones en las plantillas de infraestructura base creadas por el equipo de infraestructura.

Repositorios de configuración y políticas

Garantizar una plataforma con prioridad y seguridad mejorada es una de sus prioridades principales para los operadores y los ingenieros de seguridad.

Configuración

La configuración centralizada te permite propagar los cambios de configuración en todo el sistema. Los siguientes son algunos elementos de configuración comunes que puedes administrar de forma centralizada:

  • Espacios de nombres de Kubernetes

  • Cuotas

  • Controles de acceso basados en funciones (RBAC)

  • Políticas de red

Debes aplicar de forma coherente estos tipos de configuraciones en tus clústeres para que los equipos de aplicaciones no usen de forma inadecuada o abusen de la infraestructura. Usar un repositorio de Git para almacenar la configuración puede mejorar los procesos, como la auditoría y la implementación de la configuración a través de métodos como GitOps. Las herramientas como el Sincronizador de configu pueden simplificar el proceso de configuración uniforme de opciones en toda tu infraestructura.

Política

Debido a que los desarrolladores pueden extender las configuraciones base que crean los operadores, necesitas una forma de restringir los recursos creados en los clústeres que conforman la plataforma. En algunos casos, puedes crear una política que permita a los desarrolladores crear recursos solo si esos recursos cumplen con requisitos específicos; por ejemplo, crear objetos de servicio de Kubernetes que no puedan configurarse para el balanceo de cargas externo.

En la arquitectura de referencia asociada, debes usar Policy Controller para aplicar las políticas.

Repositorios iniciales

Los repositorios de inicio ayudan a adoptar la CI/CD, la infraestructura y las prácticas recomendadas de desarrollo en toda la plataforma. Los repositorios de inicio pueden reducir en gran medida el costo asociado con la adopción de las prácticas recomendadas. Las prácticas recomendadas, a su vez, ayudan a aumentar la velocidad, la confiabilidad y la productividad del equipo. En la arquitectura de referencia asociada, hay varios repositorios de inicio para la CI, la CD, las configuraciones de Kubernetes, Go, Java e infraestructura y aplicaciones de inicio de Python.

Integración continua

Por lo general, las organizaciones tienen un conjunto estándar de tareas que se aplican a las aplicaciones durante la CI. Por ejemplo, en la implementación de referencia, el parámetro conjunto básico de etapas de CI los siguientes: compilar código y compilar una imagen de contenedor. Debido a que esas etapas se definen en el repositorio de inicio, se aplican de manera uniforme en toda la plataforma. Los equipos de aplicaciones individuales pueden agregar pasos adicionales.

Entrega continua

Al igual que la CI, el proceso para la CD suele tener un conjunto estándar de pasos a fin de implementar aplicaciones a través de los entornos de desarrollo, producción previa y producción. Sin importar las metodologías de implementación empleadas, el repositorio de inicio permite que los equipos de plataforma apliquen esas metodologías de manera uniforme en aplicaciones y entornos. En la implementación de referencia, el proceso de implementación incluye lanzamientos para el desarrollo, implementaciones de preproducción, una implementación de producción en varios clústeres y aprobaciones manuales para las implementación de producción con Cloud Deploy.

Configuración de la aplicación

Para que una plataforma de entrega de software sea efectiva, necesitas una manera uniforme y coherente de aplicar la configuración de la aplicación. Mediante las herramientas como kustomize y los repositorios de inicio para las configuraciones de Kubernetes, las plataformas pueden proporcionar una base coherente para la configuración de la aplicación. Por ejemplo, en la implementación de referencia, la configuración base kustomize inicializa los repositorios de entorno de aplicaciones con un conjunto de configuraciones base conocido. Luego, los equipos de aplicaciones individuales pueden adaptar las configuraciones a sus necesidades.

Aplicaciones de inicio

Las aplicaciones de inicio pueden ayudarte a reducir la sobrecarga asociada con las prácticas recomendadas, por ejemplo, la observabilidad y las prácticas recomendadas de contenedores.

  • Observabilidad. A fin de operar de manera eficiente una aplicación y ayudar a garantizar su confiabilidad, las aplicaciones deben tener en cuenta el registro, las métricas y los seguimientos. Las aplicaciones de inicio ayudan a los equipos a compilar en frameworks y estrategias que promueven la observabilidad.

  • Prácticas recomendadas de contenedores. Cuando compilas aplicaciones alojadas en contenedores, debes compilar imágenes de contenedor pequeñas y limpias. Las prácticas recomendadas para contenedores incluyen empaquetar una sola aplicación en una imagen, quitar las herramientas innecesarias de la imagen y tratar de producir de forma activa imágenes pequeñas a partir de imágenes base mínimas.

La arquitectura de referencia proporciona una app básica de Go, una app básica de Java y una app básica de Python como punto de partida. Debes agregar aplicaciones de inicio personalizadas para los lenguajes, pilas tecnológicas y tipos de aplicaciones que desarrollan tus equipos.

Repositorios de inicio de la infraestructura

Los repositorios de inicio de infraestructura vienen con el código escrito previamente necesario para crear diferentes componentes de infraestructura. Estos repositorios usan plantillas y módulos estándar según lo decida el equipo de infraestructura.

Por ejemplo, en la implementación de referencia, platform-template contiene el código de partida para compilar un proyecto de Google Cloud, una nube privada virtual y un clúster de GKE. Por lo general, los equipos de infraestructura usan esta plantilla para administrar la infraestructura que usan varios equipos de aplicaciones como un recurso compartido. De manera similar, la plantilla de infraestructura contiene un código de infraestructura básico que una aplicación puede requerir, por ejemplo, una base de datos de Cloud Storage o una de Cloud Spanner. Por lo general, los equipos de aplicaciones usan esta plantilla para administrar la infraestructura de sus aplicaciones.

Repositorios de plantillas compartidas

Los repositorios de plantillas compartidas proporcionan plantillas de tareas estándar que cualquier persona en una organización puede reutilizar. Por ejemplo, la infraestructura como módulos de código, como los módulos de Terraform, que se pueden usar para crear recursos de infraestructura como redes y procesamiento.

Zonas de destino de las aplicaciones

Cuando usas CI/CD compartida, la configuración de la aplicación compartida y las políticas y configuraciones coherentes en todos los clústeres, puedes vincular estas capacidades a fin de crear zonas de destino de la aplicación.

Una zona de destino es una entidad lógica bloqueada que permite a los desarrolladores implementar e iterar en sus aplicaciones. Las zonas de destino de las aplicaciones usan los recorridos de protección que implementas para que los desarrolladores puedan operar de forma autónoma. En cada aplicación, debes crear un espacio de nombres de Kubernetes en cada clúster de cada entorno (por ejemplo, para la producción, el desarrollo o la etapa de pruebas). Esta coherencia ayuda a los operadores a depurar y mantener los entornos a lo largo del tiempo.

En el siguiente diagrama, se ilustra el concepto de las zonas de destino:

El clúster de GKE incluye tres espacios de nombres para diferentes entornos y cargas de trabajo.

Modelo operativo

Cuando operas una plataforma de entrega de software con CI/CD moderna, es importante mantener los entornos, la infraestructura y los procesos coherentes y actualizados. Por lo tanto, debes planificar y elegir con cuidado el modelo operativo de la plataforma. Puedes elegir entre varios modelos, como clústeres como servicios, planos o una infraestructura de multiusuario.

Debido a que es importante mantener una infraestructura coherente, limitar la subutilización y permitir que los equipos se enfoquen en entregar aplicaciones, te recomendamos que implementes una infraestructura de multiusuarios. La implementación de aplicaciones en una infraestructura de multiusuarios quita la necesidad de que los equipos de aplicaciones administren la infraestructura y permite que los equipos de operadores y la seguridad se enfoquen en mantener la infraestructura coherente.

Consideraciones para la infraestructura de multiusuarios

Cuando compilas una plataforma de entrega de software de multiusuarios, puedes considerar varias aspectos en la plataforma:

  • Aislamiento de la carga de trabajo. El concepto de las zonas de destino de la aplicación es proporcionar un framework para aislar las cargas de trabajo. Las zonas de destino son una combinación de espacios de nombres, políticas de red y RBAC. Todas estas políticas deben administrarse y aplicarse de manera centralizada con el Sincronizador de configuración.

  • Supervisión del uso de usuarios. Para obtener los desgloses de costos de espacios de nombres y etiquetas individuales en un clúster, puedes usar la medición del uso de GKE. La medición del uso de GKE realiza un seguimiento de la información sobre las solicitudes de recursos y el uso de recursos para las cargas de trabajo de un clúster, que puedes filtrar aún más por espacios de nombres y etiquetas. Cuando habilitas la medición del uso de GKE en el clúster multiusuario, los registros de uso de recursos se escriben en una tabla de BigQuery. Puedes exportar métricas específicas de usuarios a conjuntos de datos de BigQuery en el proyecto de usuario correspondiente y los auditores pueden analizar esas métricas para determinar desgloses de costos.

  • Cuotas de recursos. Para garantizar que todas las instancias que comparten un clúster tengan acceso legítimo a los recursos del clúster, debes aplicar cuotas de recursos. Crea una cuota de recursos para cada espacio de nombres según la cantidad de Pods que implemente cada usuario y la cantidad de memoria y CPU que requiere cada Pod.

  • Varios clústeres para cada entorno. Si deseas mejorar la confiabilidad de la aplicación y de la plataforma, debes usar varios clústeres para cada entorno de producción previa y producción. Con varios clústeres disponibles, puedes lanzar aplicaciones de forma individual en clústeres para niveles adicionales de validación de la versión canary. Además, tener varios clústeres alivia las preocupaciones relacionadas con el ciclo de vida de la administración y las actualizaciones de clústeres.

  • Registro y supervisión específicos del usuario. Para investigar las operaciones de sus aplicaciones, los usuarios necesitan acceso a los registros y las métricas. En un entorno de multiusuario, el registro y la supervisión deben ser específicos de la aplicación. Para las métricas y la supervisión, puedes usar Google Cloud Managed Service para Prometheus y Grafana para cada espacio de nombres. En el caso de los registros, debes crear un receptor para exportar entradas de registro a conjuntos de datos de BigQuery y, luego, filtrar los conjuntos de datos por espacio de nombres de usuario. Los usuarios pueden acceder a los datos exportados en BigQuery.

A fin de obtener más información sobre una infraestructura de multiusuarios, consulta Prácticas recomendadas para arquitecturas multiusuario empresariales.

Límites de aislamiento

Varios equipos compilan y usan una plataforma de entrega de software, lo que hace que sea importante tener límites de aislamiento adecuados entre los diferentes componentes de la plataforma. Los límites de aislamiento ayudan a compilar una plataforma sólida, ya que proporcionan las siguientes características:

  • Separación de responsabilidades. Cada equipo administra los recursos en sus límites de aislamiento sin preocuparse por el resto. Por ejemplo, el equipo de infraestructura solo es responsable de mantener los clústeres de GKE. Los operadores o desarrolladores solo son responsables de mantener las canalizaciones de CI/CD y el código de la aplicación.

  • Control de acceso detallado. Si los recursos están segregados por límites de aislamiento, usa un control de acceso detallado para limitar el acceso.

  • Reduce las áreas afectadas. Puedes realizar cambios en un componente de forma independiente sin afectar a los demás.

  • Reduce los errores manuales. Debido a que el control de acceso es detallado, puedes evitar errores manuales, como realizar una implementación accidental en un clúster de producción desde un entorno de desarrollo.

Estos límites de aislamiento pueden existir entre diferentes aplicaciones, infraestructura y aplicaciones, o incluso entre los distintos entornos de una aplicación.

Administración

El objetivo principal de las plataformas de entrega de software y los sistemas de CI/CD modernas es mejorar la eficiencia del proceso de entrega de software general. En términos de administración de la plataforma, tienes dos consideraciones principales: la integración de la aplicación, que, por lo general, está dentro de la categoría de administración. desarrollo y mantenimiento continuo de la plataforma (es decir, tratar la plataforma como un producto).

Integración y administración de aplicaciones

El objetivo de adoptar las herramientas y la metodología de CI/CD modernas es optimizar el proceso de lanzamiento y la integración de servicios nuevos. Integrar aplicaciones nuevas debe ser un proceso sencillo que puedes realizar con la entrada mínima de los equipos de operaciones y de seguridad. Esto no significa que los equipos de operaciones y seguridad no están involucrados, pero que su entrada inicial desde una perspectiva de seguridad e implementación se maneja automáticamente a través del proceso de aprovisionamiento. Una vez incorporadas, los equipos de operaciones y de seguridad se incluyen naturalmente en el proceso de lanzamiento a través de solicitudes de combinación, actualizaciones de políticas y aplicación de las prácticas recomendadas.

Se recomienda crear cierta automatización para incorporar una aplicación nueva. Esto puede incluir la creación de repositorios de código, canalizaciones de CI/CD, zonas de destino y cualquier infraestructura necesaria para la aplicación. La automatización separa las dependencias complejas que tienen los equipos de desarrollo de otros equipos de la organización y les brinda a los desarrolladores la autonomía para realizar el autoservicio de una aplicación. Esto permite a los desarrolladores comenzar a iterar en el código de la aplicación muy rápidamente y no perder tiempo en realizar otras tareas además de escribir el código. La automatización debe permitir a los desarrolladores ejecutar la aplicación en un entorno de desarrollo. Para llevar la aplicación a entornos superiores, se debe involucrar a otros equipos y se debe seguir el proceso de revisión.

En la arquitectura de referencia asociada, esta automatización se conoce como Application Factory.

Plataforma como producto

El flujo de trabajo de CI/CD es un producto de software, con la excepción de que los usuarios del producto son equipos de desarrollo, operaciones y seguridad. Por lo tanto, la plataforma requiere los mismos procesos y roles de desarrollo de software, como propietarios de productos, marketing (uso interno), ciclos de reacción de los usuarios y ciclos de desarrollo de las funciones.

Implementa CI/CD con GKE

Cuando comiences a implementar CI/CD moderna con GKE en la organización, es fundamental elegir las mejores aplicaciones piloto. Los equipos de desarrollo, operaciones y seguridad también deben considerar otros factores mientras trabajan, que se analiza en esta sección.

Selecciona una aplicación de prueba piloto

Elegir las primeras aplicaciones para pasar a la plataforma puede ser un primer paso difícil. Los buenos candidatos para los pilotos son los servicios que procesan datos o manejan solicitudes, pero no almacenan datos, como las capas de almacenamiento en caché, frontends web o aplicaciones de procesamiento basadas en eventos. Por lo general, estas aplicaciones son más resistentes a pequeñas cantidades de errores de implementación y tiempo de inactividad que pueden ocurrir cada vez que trabajas con técnicas de administración de implementación y configuración nuevas. A medida que los equipos obtienen más experiencia en CI/CD y comienzan a experimentar beneficios en la confiabilidad y la velocidad, puedes comenzar a mover los servicios principales a la plataforma de entrega de software.

Consideraciones para desarrolladores

Cuando trabajas en un proceso de desarrollo de CI/CD moderna, las funciones, los cambios y las implementaciones pueden ocurrir tanto con una mayor frecuencia como de forma más asíncrona. Los equipos de desarrollo deben saber cómo afectan los cambios a los sistemas descendentes o dependientes, y cómo se prueban esos cambios. Las rutas de comunicación entre los equipos de desarrollo, operaciones y seguridad deben ser fluidas. Se recomienda invertir en mejores prácticas de control de versiones para las aplicaciones y los contratos de datos que comunican los diferentes servicios. Además de mejorar los métodos de comunicación y el control de versiones, la implementación de características en fragmentos pequeños y el uso de ramas de funciones y marcas puede mejorar la forma de probar y lanzar funciones.

Consideraciones del operador

Con una plataforma de entrega de software, los equipos de operaciones deben funcionar más como los equipos de desarrollo. En lugar de compilar funciones externas a nivel externo, compilan herramientas y procesos internos que facilitan el desarrollo, la implementación y el funcionamiento de las aplicaciones externas. Su propio equipo y los equipos de seguridad y desarrollo usan las herramientas de la plataforma. Los operadores deberían compilar herramientas que ayuden a lanzar nuevas versiones de aplicaciones y también revertirlas en caso de errores de aplicación o errores de implementación. Los operadores también deben poner más énfasis en la compilación de sistemas de supervisión y alertas para detectar fallas de forma proactiva y alertar según corresponda.

Consideraciones sobre los equipos de seguridad

Los equipos de seguridad deberían trabajar para hacer que la seguridad sea una responsabilidad compartida entre los equipos de operaciones y de desarrollo. Por lo general, este patrón se denomina desplazamiento a la izquierda sobre la seguridad, en el que la seguridad de la información (InfoSec) se involucra en las primeras etapas del proceso de desarrollo, los desarrolladores trabajan con herramientas probadas con anterioridad y las pruebas de seguridad están automatizadas. Además de esas técnicas, puedes definir y aplicar la política de seguridad con Policy Controller de manera programática. La combinación de técnicas y herramientas coloca la aplicación de seguridad en una posición más proactiva.

¿Qué sigue?