CI/CD moderna con Anthos: 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 (IC/EC) en una plataforma de entrega de software de varios equipos que usa Anthos.

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 Anthos, los métodos uniformes de IC/EC 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 Anthos y CI/CD, consulta los otros documentos de esta serie:

Evaluación de la preparación para un enfoque moderno

Antes de implementar herramientas y procesos de CI/CD moderna con Anthos, 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 A fin de tener éxito con la implementación y la adopción de un sistema CI/CD moderna con Anthos, 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 Anthos. 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 Anthos

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 Anthos. 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. Los repositorios que realizan varias funciones: repositorios de código que almacenan la configuración específica de la lógica empresarial y de la aplicación, y repositorios de inicio que facilitan la adopción de las prácticas recomendadas y mantienen la coherencia entre 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 Anthos.
  • 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 en entornos de producción y preproducción.
  • 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

A fin de compilar una plataforma de entrega de software escalable, necesitas clústeres de Kubernetes para herramientas compartidas, 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.
  • Herramientas compartidas. Este clúster es responsable de ejecutar la infraestructura compartida necesaria a fin de ejecutar sistemas, como almacenamiento de código fuente, herramientas de integración continua y herramientas de implementación.
  • 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 Anthos Config Management. 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 Anthos Config Management para almacenar y aplicar la configuración y las políticas 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.

Administra tus implementaciones en los clústeres de etapa de pruebas y de producción a través del clúster de herramientas compartidas. El clúster de herramientas compartidas sirve como repositorio central y punto de coordinación para el código de la aplicación, la configuración de la aplicación, la CI/CD y las imágenes de contenedor. Puedes inicializar los repositorios de aplicación y configuración mediante repositorios de inicio y herramientas automatizadas. Por ejemplo, puedes usar las herramientas de línea de comandos para incorporar e inicializar aplicaciones nuevas de forma automática.

En el clúster de desarrollo, otorgarás a los desarrolladores su propio espacio de nombres para cada aplicación, lo que les permite iterar de forma independiente en sus aplicaciones. Del mismo modo, 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. Inicializarás las zonas de destino de la aplicación en todos los entornos con Anthos Config Management y usarás Anthos Service Mesh para que los clústeres de producción parezcan un clúster mediante la creación de una malla de redes que abarcará 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 las implementaciones en un entorno de preproducción.
  5. Después de que la configuración se almacena en el repositorio de código, los operadores revisan los cambios y los fusionan en la rama principal. En ese punto, la configuración se implementa en el entorno de producción.
  6. 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.
  7. 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 con facilidad y ver el impacto potencial de los cambios propuestos.

En la arquitectura de referencia, debes usar kustomize y kpt 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 funcionalidad 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 Anthos, 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

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 Anthos Config Management 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, usas Anthos Config Management para aplicar políticas.

Repositorios iniciales

Los repositorios de inicio ayudan a adoptar la CI/CD 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, el clúster de herramientas compartidas incluye repositorios de inicio de muestra para CI, CD, configuraciones de Kubernetes y una aplicación inicial de Go.

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 conjunto base de etapas de CI son los siguientes: código de compilación, ejecución de pruebas de unidades y compilación de 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 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 implementaciones de producción previa, una implementación de producción en varios clústeres y aprobaciones manuales para la implementación de producción.

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 compartida 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. Si deseas obtener más información, consulta Recomendaciones para compilar contenedores.

La arquitectura de referencia proporciona una aplicación básica de Go como punto de partida. Debes agregar aplicaciones de inicio personalizadas para los lenguajes, pilas de tecnología y tipos de aplicaciones que desarrollan tus equipos.

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 control de calidad 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 mediante Anthos Config Management.
  • 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, debes implementar una instancia de Prometheus y Grafana en cada espacio de nombres. También puedes exportar las métricas a Google Cloud's operations suite mediante un contenedor prometheus-stackdriver-sidecar. 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.

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.

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 funciones 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 Anthos

Cuando comiences a implementar CI/CD moderna con Anthos 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 de manera programática la política de seguridad con Anthos Config Management. La combinación de técnicas y herramientas coloca la aplicación de seguridad en una posición más proactiva.

¿Qué sigue?