En este documento se describe un framework para implementar procesos de integración continua y entrega continua (CI/CD) modernos en una plataforma de entrega de software de varios equipos que usa Google Kubernetes Engine.
Después, puedes iterar en la plataforma para mejorar aún más el rendimiento del desarrollo y las operaciones, como la velocidad de lanzamiento, la fiabilidad de la plataforma y el tiempo de recuperación tras fallos.
Este documento forma parte de una serie:
CI/CD modernas con GKE: un framework de distribución de software (este documento)
CI/CD modernas con GKE: crear un sistema de CI/CD (arquitectura de referencia)
CI/CD modernas con GKE: aplicar el flujo de trabajo de desarrollo
Este documento está dirigido a arquitectos empresariales y desarrolladores de aplicaciones, así como a equipos de seguridad de TI, DevOps y Site Reliability Engineering. Es útil tener cierta experiencia con las herramientas y los procesos de implementación automatizada para entender los conceptos de este documento.
Ventajas de la CI/CD moderna
CI/CD es un enfoque de desarrollo de software que te permite automatizar las fases de compilación, prueba y despliegue del desarrollo de software mediante una serie de herramientas y procesos repetibles.
Además de la automatización de la CI/CD, Kubernetes y los contenedores han permitido a las empresas lograr mejoras sin precedentes en la velocidad de desarrollo y despliegue. Sin embargo, aunque la adopción de Kubernetes y de contenedores está aumentando, muchas organizaciones no aprovechan al máximo las ventajas en cuanto a velocidad de lanzamiento, estabilidad y eficiencia operativa porque sus prácticas de CI/CD no aprovechan al máximo Kubernetes ni abordan los problemas de operaciones y seguridad.
Un enfoque de CI/CD verdaderamente moderno debe abarcar más que la automatización. Para aprovechar al máximo las mejoras en velocidad y seguridad, así como la potencia de Kubernetes y los contenedores, debes optimizar la incorporación de aplicaciones, las prácticas de CI/CD y los procesos operativos.
Gracias a la infraestructura coherente que ofrece la plataforma de GKE, los métodos de CI/CD uniformes y las prácticas recomendadas de implementación, tu organización puede obtener las siguientes ventajas para el desarrollo y las operaciones:
Reducir el plazo de entrega de los cambios.
Permite que los equipos de operaciones y seguridad creen y actualicen las prácticas recomendadas para aprovisionar aplicaciones y políticas de aprovisionamiento en toda la plataforma.
Simplifica la incorporación de aplicaciones proporcionando a los equipos proyectos iniciales totalmente funcionales y desplegables que incluyan las prácticas recomendadas de tu organización.
Reducir el tiempo necesario para restaurar el servicio.
Gestiona toda la configuración de forma declarativa mediante GitOps para simplificar la auditoría, la reversión y la revisión.
Estandariza las metodologías de implementación y monitorización en toda la organización para reducir el tiempo necesario para identificar los factores que contribuyen a un problema que afecta a un servicio.
Aumentar la frecuencia de los despliegues.
Asegúrate de que los desarrolladores de aplicaciones puedan iterar de forma independiente en sus propios entornos de pruebas de desarrollo (o zonas de aterrizaje) sin interferir entre sí.
Usa GitOps para las implementaciones, la gestión de lanzamientos mejorada y el seguimiento de cambios.
Implementa medidas de protección para que los equipos de servicio puedan hacer implementaciones con frecuencia.
Crea un proceso de lanzamiento progresivo para implementar de forma coherente en entornos de preproducción, lo que dará a los desarrolladores la confianza que necesitan para implementar cambios en producción.
Para ver cómo se aplican estas ventajas y conceptos en GKE y CI/CD, consulta los demás documentos de esta serie:
Evaluar la preparación para adoptar un enfoque moderno
Antes de implementar herramientas y procesos de CI/CD modernos con GKE, debes evaluar si tu organización y tus equipos están preparados para adoptar una nueva plataforma.
Rasgos de la organización
Para adoptar una plataforma moderna, tu empresa debe contar con el siguiente apoyo de los equipos directivos y técnicos:
Patrocinador del equipo directivo. Adoptar una plataforma de lanzamiento de software suele ser una tarea ardua que llevan a cabo varios equipos multidisciplinares. El proceso suele dar lugar a cambios en las funciones y responsabilidades, así como en las prácticas de desarrollo de software. Para adoptar estas herramientas y técnicas con éxito, necesitas el apoyo de uno o varios miembros del equipo directivo. Los patrocinadores más eficaces son aquellos que consideran estos cambios como un proceso de mejora continua y quieren dar autonomía a sus equipos en lugar de gestionarlos.
Alineación de la estrategia técnica y empresarial. Recomendamos que tus equipos empresariales y técnicos se pongan de acuerdo en las cuatro métricas clave de envío de software definidas por DevOps Research and Assessment (DORA): plazo de entrega de los cambios, frecuencia de despliegue, tiempo para restaurar el servicio e índice de fallos por cambios. Si se ponen de acuerdo en estas métricas, los equipos empresariales y técnicos de tu empresa tendrán un objetivo común, lo que les permitirá calcular conjuntamente el retorno de la inversión, ajustar el ritmo de cambio y modificar el nivel de inversión.
Recursos Para tener éxito, los equipos que desarrollan prácticas de CI/CD modernas y crean cadenas de herramientas necesitan los recursos necesarios: tiempo, personas e infraestructura. Estos equipos necesitan tiempo para probar y seleccionar los mejores procesos y herramientas. Lo ideal es que estos equipos representen muchas funciones diferentes en el proceso de entrega de software y puedan incorporar otros recursos de toda la organización. Por último, los equipos necesitan poder aprovisionar infraestructura, incluidos recursos en la nube y herramientas de software.
Apertura a la adopción de nuevas herramientas. Las herramientas y técnicas de CI/CD modernas suelen incluir nuevas herramientas y procesos. Los equipos deben experimentar con esos procesos y herramientas y estar abiertos a adoptarlos. Es necesario un ciclo de comentarios para que los equipos de la plataforma puedan recibir información de los equipos de aplicaciones, operaciones y seguridad que la utilizan.
Preparación cultural. Para implementar y adoptar correctamente un sistema de CI/CD moderno con GKE, la organización y los equipos técnicos que desarrollen el sistema deben estar preparados para cambiar su forma de trabajar y colaborar. Por ejemplo, los equipos de desarrollo y operaciones deben estar dispuestos a asumir más responsabilidad en materia de seguridad, y los equipos de seguridad y operaciones deben estar dispuestos a optimizar los procesos de aprobación de cambios.
Capacidades técnicas
Para adoptar una estrategia de CI/CD moderna, tus equipos también deben estar preparados técnicamente de las siguientes formas:
Experiencia con contenedores. Los equipos que adoptan enfoques de CI/CD modernos deben tener cierta experiencia con los contenedores. Lo ideal es que esta experiencia incluya técnicas de desarrollo para crear imágenes de contenedor y combinar contenedores para crear sistemas más grandes.
Estrategia de integración continua. Los equipos deben tener experiencia con herramientas de integración continua (como Jenkins, TeamCity, Bamboo y CircleCI) y realizar integración continua y pruebas automatizadas. Recomendamos que las organizaciones planifiquen cómo mejorar aún más esos procesos.
Automatización de despliegues. Los equipos deben tener cierta experiencia en automatización de implementaciones. Algunos ejemplos de herramientas de implementación automatizada son los scripts de shell básicos, Terraform, Chef o Puppet. Es fundamental tener conocimientos básicos sobre las herramientas y los procesos de implementación automatizados para optimizar y automatizar las implementaciones.
Arquitecturas orientadas a servicios. Aunque no es un requisito previo para adoptar procesos de CI/CD modernos, la adopción de arquitecturas más modulares y orientadas a servicios debe ser un objetivo a largo plazo de las organizaciones que quieran adoptar herramientas y técnicas de CI/CD modernas con GKE. Se ha demostrado que las arquitecturas basadas en servicios mejoran la velocidad y la fiabilidad.
Control de versiones moderno. Las herramientas de control de versiones modernas, como Git, permiten a los equipos establecer flujos de trabajo como el desarrollo basado en el tronco, las ramas de funciones y las solicitudes de combinación.
Diseñar CI/CD modernas con GKE
En esta sección se describe una plataforma de distribución de software y sus componentes. Para mejorar el rendimiento de la distribución de software, debes implementar CI/CD y otras prácticas recomendadas técnicas que permitan a los equipos lanzar versiones rápidamente y operar de forma eficiente.
En esta sección también se describe la infraestructura necesaria para admitir el ciclo de vida de la entrega de software y cómo gestionar esa infraestructura de forma coherente con GKE. Por último, en esta sección se proporciona un ejemplo de flujo de trabajo de entrega de software y se muestra cómo los repositorios de inicio simplifican la incorporación y la implementación de prácticas recomendadas. Se han revisado los siguientes aspectos que hay que tener en cuenta para el diseño:
Plataforma de distribución de software. El marco y las funciones técnicas que constituyen la base de un proceso de lanzamiento de aplicaciones fiable y de alta velocidad.
Infraestructura de la plataforma. Los componentes de infraestructura y las consideraciones de gestión que necesitas para crear la plataforma y ejecutar tus aplicaciones.
Flujo de trabajo de entrega de software. Cómo colaboran los equipos para crear, probar y desplegar código de forma más eficiente.
Repositorios de código. Repositorios que realizan varias funciones, como almacenar la lógica empresarial real, la configuración específica de la aplicación y el código para crear la infraestructura. También pueden ser repositorios iniciales que faciliten la adopción de prácticas recomendadas y ayuden a mantener la coherencia en los procesos automatizados.
Zonas de aterrizaje de aplicaciones. Entidad lógica que permite a los desarrolladores desplegar y repetir sus aplicaciones de forma autónoma usando las protecciones que hayas implementado.
Modelo operativo. Herramientas, procesos y métodos técnicos para gestionar la infraestructura y las aplicaciones que componen la plataforma.
Gestión. Procesos y consideraciones que debes mantener y gestionar en la plataforma de lanzamiento de software.
Plataformas de distribución de software
Una plataforma de distribución de software unifica las herramientas y agiliza los procesos necesarios para crear, distribuir, implementar y operar aplicaciones.
La responsabilidad de mantener la configuración, la estabilidad, el tiempo de actividad y la escalabilidad de una aplicación varía entre los operadores, los equipos de seguridad y los equipos de desarrollo, pero todos los componentes y equipos deben trabajar conjuntamente para acelerar los lanzamientos. Aunque en este documento se describen métodos para mejorar la gestión del control de fuentes y la observabilidad de las aplicaciones, se centra principalmente en la integración continua (CI), la entrega continua (CD) y la gestión de la configuración.
Para crear una plataforma de distribución de software completa, necesitas cada componente del siguiente diagrama:
Cada uno de estos componentes proporciona funciones al sistema y a las aplicaciones que se ejecutan en la plataforma:
Monitorización de la infraestructura. El nivel básico de monitorización necesario al aprovisionar para verificar el correcto funcionamiento de los clústeres de Google Kubernetes Engine (GKE), las instancias de máquinas virtuales y otra infraestructura necesaria para que las aplicaciones funcionen.
Orquestación de contenedores. Plataforma que coordina la implementación y el funcionamiento de aplicaciones basadas en contenedores. Algunos ejemplos de plataformas de orquestación de contenedores son Kubernetes, GKE o GKE Enterprise.
Registro de contenedores. El almacenamiento y el control de acceso de las imágenes de contenedor.
CI. Proceso de aplicación de tareas automatizadas a una aplicación antes de su implementación. Las tareas de integración continua suelen incluir la compilación, el empaquetado y las pruebas. Los tipos de tareas varían en función de la aplicación y la organización.
CD. Procesos de despliegue altamente automatizados y aplicados con alta frecuencia. Algunas metodologías son las aprobaciones manuales, los despliegues Canary, los despliegues azul-verde o los despliegues continuos.
Política. Políticas de configuración de seguridad e infraestructura definidas por los equipos de operaciones y seguridad, y aplicadas y cumplidas de forma continua por la plataforma.
Gestión del código fuente. Por ejemplo, el almacenamiento controlado por versiones de código, archivos de configuración y definiciones de políticas. En un sistema de CI/CD moderno, la gestión del código fuente suele ser Git.
Gestión de la configuración: Sistema que se usa para almacenar y aplicar la configuración de la aplicación en diferentes entornos.
Observabilidad de aplicaciones. El registro, la monitorización, las alertas y el seguimiento a nivel de aplicación que usan los equipos de desarrollo, operaciones y seguridad para solucionar problemas y verificar el correcto funcionamiento de las aplicaciones.
Infraestructura de la plataforma
Para crear una plataforma de lanzamiento de software escalable, necesitas clústeres de Kubernetes para el desarrollo, entornos de preproducción y varios clústeres de producción. Los clústeres pueden cumplir muchas funciones diferentes:
Desarrollo En estos clústeres, los desarrolladores realizan implementaciones ad hoc de sus aplicaciones para hacer pruebas y experimentos.
El entorno de la aplicación.
Preproducción. En cada entorno de preproducción de tu flujo de trabajo, debes tener un clúster de Kubernetes para alojar tus aplicaciones. Estos clústeres deben ser similares a los de producción para que puedas reducir o eliminar las diferencias entre los entornos y, de este modo, mejorar las tasas de éxito de las implementaciones.
Producción: Estos clústeres ejecutan tus cargas de trabajo de producción. Debes usar varios clústeres distribuidos geográficamente. De esta forma, se mejora la fiabilidad frente a los fallos de la infraestructura y se reducen los problemas de las operaciones del segundo día, como las actualizaciones y el escalado de los clústeres.
En el siguiente diagrama se muestra la arquitectura de alto nivel:
En esta arquitectura, los clústeres de cada entorno se gestionan mediante Config Sync. Es fundamental que la configuración de los clústeres sea coherente, ya que así los equipos de desarrollo, operaciones y seguridad tienen la certeza de que los entornos de preproducción y producción funcionan de forma similar. Puedes usar Config Sync para almacenar y aplicar configuraciones comunes en toda tu flota de clústeres. Una vez que la configuración de tu clúster se haya estandarizado, se pueda auditar y sea escalable, podrás centrarte en el flujo de trabajo de entrega de software y en la incorporación y la implementación de aplicaciones.
Las implementaciones en clústeres de desarrollo, de preproducción y de producción se gestionan a través de los flujos de procesamiento de CI/CD de la aplicación. La gestión del control de versiones sirve como punto de coordinación para el código y la configuración de la aplicación. Las canalizaciones de CI/CD y las imágenes de contenedor de una aplicación están aisladas en el entorno de esa aplicación. Para inicializar los repositorios de aplicaciones y de configuración, utiliza repositorios de inicio y herramientas automatizadas. Por ejemplo, puedes usar Cloud Build para ejecutar Terraform y así incorporar e inicializar nuevas aplicaciones automáticamente.
Despliega las aplicaciones en sus propias zonas de aterrizaje en cada clúster para que estén aisladas en la red y en la identidad. Para inicializar las zonas de aterrizaje de aplicaciones en los distintos entornos, usa Config Sync. Para que los clústeres de producción parezcan un único clúster, usa Cloud Service Mesh o Multi Cluster Ingress para crear una malla de red que abarque varios clústeres.
Flujo de trabajo de envío de software
Un componente fundamental de la plataforma de envío de software es el sistema de integración continua y entrega continua (CI/CD). Cuando los creadores de plataformas empiezan a definir el proceso de CI/CD, deben asegurarse de que cada componente produzca o consuma artefactos que se ajusten a una interfaz estandarizada. El uso de una interfaz estandarizada simplifica la sustitución de componentes cuando se lanza al mercado una implementación mejor.
Cuando creas una plataforma para aplicaciones contenerizadas, puedes usar las tres interfaces estandarizadas entre 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:
Este flujo de trabajo funciona de la siguiente manera:
Los desarrolladores confirman el código de su aplicación en los repositorios de código.
El sistema de integración continua prueba el código, crea un artefacto de imagen Docker y almacena el artefacto en un registro.
Cuando el artefacto esté listo para implementarse, se añadirá una referencia a la configuración de la aplicación.
La configuración de la aplicación se convierte a un formato legible por Kubernetes y se almacena en un repositorio de código. Las actualizaciones de este repositorio activan una pipeline de implementación que implementa los artefactos en un entorno de desarrollo integrado.
Una vez que se han completado las pruebas en el entorno de desarrollo integrado, los operadores promueven el despliegue al entorno de preproducción.
Una vez que se han asegurado de que la aplicación funciona correctamente en el entorno de preproducción, los operadores obtienen las aprobaciones en la canalización de implementación y promocionan la versión al entorno de producción.
Cuando los operadores hacen cambios en las configuraciones base, esos cambios se aplican en toda la organización. Cuando los operadores confirman los cambios en sus repositorios, se pueden activar automáticamente las actualizaciones de la configuración de la aplicación (y las implementaciones posteriores). O bien, los cambios de los operadores se pueden recoger la próxima vez que los desarrolladores implementen sus cambios.
Paralelamente, los ingenieros de seguridad pueden implementar y ajustar políticas que definan lo que se puede implementar y, a continuación, confirmar esas políticas en su repositorio de políticas.
Con la 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ía y revisión antes de que se puedan aplicar. En este modelo declarativo, los archivos de configuración se almacenan en un repositorio de Git, lo que le permite mantener un registro de los cambios, revertir los despliegues fallidos y ver el impacto potencial de los cambios propuestos.
En la arquitectura de referencia asociada, se usa kustomize para controlar las configuraciones de las aplicaciones de tu organización. La herramienta kustomize
permite a los operadores crear las llamadas bases de configuraciones de aplicaciones que
pueden ajustar tus equipos de desarrollo sin tener que añadir ni cambiar ningún código
en la base. Al definir configuraciones base, los equipos de plataforma pueden crear y mejorar las prácticas recomendadas de la organización. Los operadores y los desarrolladores pueden iterar en sus implementaciones de forma independiente. Los desarrolladores aplican las prácticas recomendadas configuradas por los operadores. Cuando los operadores tienen que implementar una nueva práctica recomendada para la organización, hacen el cambio en la base y este se incorpora automáticamente en la próxima implementación de los desarrolladores.
Repositorios de código
Los repositorios de código fuente son la base 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 de todos los cambios del sistema ofrece varias ventajas:
Capacidad de auditoría integrada. Los commits contienen información sobre cuándo, qué y quién ha cambiado el sistema.
Un proceso de restauración simplificado. La función de revertir de Git te permite volver a un estado anterior del sistema.
Gestión de versiones. Puedes etiquetar confirmaciones de Git para indicar una versión del estado del sistema.
Transacciones. Debes resolver explícitamente los conflictos de estado y revisarlos antes de poder 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:
En las siguientes secciones se explica cómo utilizan los operadores, los desarrolladores y los ingenieros de seguridad el repositorio de Git en un sistema de CI/CD moderno.
Repositorios de operadores
Los repositorios gestionados por operadores contienen prácticas recomendadas de CI/CD y configuración de aplicaciones para ayudar a tus equipos a incorporar aplicaciones y, al mismo tiempo, adoptar prácticas recomendadas de la organización desde el principio. Con los operadores gestionando los repositorios, los desarrolladores pueden consumir cualquier actualización 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. En el primer repositorio, los operadores mantienen las prácticas recomendadas de la canalización de CI/CD compartida. En este repositorio, los operadores proporcionan a los desarrolladores una biblioteca de tareas predefinidas que pueden usar para crear sus pipelines. Los repositorios de aplicaciones de los desarrolladores heredan automáticamente estas tareas y la lógica que contienen, por lo que no es necesario copiarlas manualmente. Estos son algunos ejemplos de las tareas que puedes estandarizar en toda la organización:
Creación y almacenamiento de artefactos
Metodologías de prueba para varios idiomas
Pasos de la implementación
Comprobaciones de políticas
Análisis de seguridad
El segundo repositorio que mantienen los operadores almacena las prácticas recomendadas para configurar una aplicación. En el contexto de GKE, las prácticas recomendadas implican asegurarse de que haya una forma de gestionar 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 base para diferentes tipos de aplicaciones, lo que ofrece a los desarrolladores una forma sencilla de implementar sus aplicaciones de acuerdo con las prácticas recomendadas de la organización.
Repositorios de aplicaciones
Los repositorios de aplicaciones almacenan la lógica empresarial de la aplicación y cualquier configuración especializada que necesite la aplicación para funcionar correctamente.
Los operadores pueden crear y mantener prácticas recomendadas de forma codificada, y los desarrolladores pueden usarlas. Para ello, los desarrolladores hacen referencia a las tareas de CI/CD y a las bases de aplicaciones que los operadores han creado en sus propios repositorios. Una vez que los desarrolladores hayan hecho los cambios, los operadores pueden personalizar aún más la implementación de la aplicación añadiendo configuraciones específicas del entorno, como URLs de bases de datos o etiquetas y anotaciones de recursos.
Estos son algunos ejemplos de los artefactos que puedes almacenar en repositorios de aplicaciones:
Código fuente de la aplicación
Un
Dockerfileque describe cómo compilar y ejecutar la aplicaciónDefinición del flujo de procesamiento de CI/CD
Extensiones o modificaciones de las bases de configuración de la aplicación creadas por los operadores
Repositorios de infraestructura como código
Los repositorios de infraestructura como código almacenan el código para crear la infraestructura necesaria para ejecutar las aplicaciones. La infraestructura puede incluir plataformas de redes y de orquestación de contenedores, como GKE. Normalmente, los administradores de infraestructura son los propietarios de estos repositorios. Los operadores pueden actualizarlos para implementar las prácticas recomendadas.
Estos 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 de la API declarativa.
Extensiones o modificaciones de las plantillas de infraestructura base creadas por el equipo de infraestructura.
Repositorios de configuración y políticas
Garantizar una plataforma segura y coherente es una prioridad absoluta tanto para los operadores como para los ingenieros de seguridad.
Configuración
La configuración centralizada te permite propagar los cambios de configuración por todo el sistema. Estos son algunos de los elementos de configuración habituales que puede gestionar de forma centralizada:
Espacios de nombres de Kubernetes
Cuotas
Controles de acceso basados en roles (RBAC)
Políticas de red
Debes aplicar este tipo de configuraciones de forma coherente en todos tus clústeres para que los equipos de aplicaciones no hagan un uso inadecuado de la infraestructura. Usar un repositorio de Git para almacenar la configuración puede mejorar procesos como la auditoría y la implementación de la configuración mediante métodos como GitOps. Herramientas como Config Sync pueden simplificar el proceso de aplicar configuraciones de forma uniforme en toda tu infraestructura.
Política
Como los desarrolladores pueden ampliar las configuraciones base que crean los operadores, necesitas una forma de limitar los recursos creados en los clústeres que componen la plataforma. En algunos casos, puede crear una política que permita a los desarrolladores crear recursos solo si estos cumplen requisitos específicos. Por ejemplo, puede crear objetos de servicio de Kubernetes que no se puedan configurar para el balanceo de carga externo.
En la arquitectura de referencia asociada, se usa Policy Controller para aplicar las políticas.
Repositorios de inicio
Los repositorios de inicio ayudan a adoptar las prácticas recomendadas de CI/CD, infraestructura y desarrollo en toda la plataforma. Los repositorios de inicio pueden reducir considerablemente el coste asociado a la adopción de prácticas recomendadas. A su vez, las prácticas recomendadas ayudan a aumentar la velocidad de las funciones, la fiabilidad y la productividad del equipo. En la arquitectura de referencia asociada, hay varios repositorios de inicio para configuraciones de CI, CD y Kubernetes, así como aplicaciones e infraestructuras de inicio de Go, Java y Python.
Integración continua
Las organizaciones suelen tener un conjunto estándar de tareas que se aplican a las aplicaciones durante la integración continua. Por ejemplo, en la implementación de referencia, el conjunto base de fases de CI es el siguiente: compilar código y crear una imagen de contenedor. Como estas fases se definen en el repositorio de inicio, se aplican de forma uniforme en toda la plataforma. Los equipos de aplicaciones pueden añadir pasos adicionales.
Entrega continua
Al igual que la integración continua, el proceso de entrega continua suele tener un conjunto estándar de pasos para desplegar aplicaciones en los entornos de desarrollo, preproducción y producción. Independientemente de las metodologías de implementación que se utilicen, el repositorio de inicio permite a los equipos de la plataforma aplicar esas metodologías de forma uniforme en las aplicaciones y los entornos. En la implementación de referencia, el proceso de despliegue incluye lanzamientos para desarrollo, despliegues de preproducción, un despliegue de producción en varios clústeres y aprobaciones manuales para el despliegue de producción mediante Cloud Deploy.
Configuración de la aplicación
Para que una plataforma de envío de software sea eficaz, necesitas una forma uniforme y coherente de aplicar la configuración de la aplicación. Al usar herramientas como kustomize y repositorios de inicio para las configuraciones de Kubernetes, las plataformas pueden proporcionar una base coherente para la configuración de las aplicaciones. Por ejemplo, en la implementación de referencia, la configuración base kustomize inicializa los repositorios del entorno de la aplicación con un conjunto base de configuraciones que funcionan correctamente. Los equipos de cada aplicación pueden adaptar las configuraciones a sus necesidades.
Aplicaciones de inicio
Las aplicaciones de inicio pueden ayudarte a reducir la sobrecarga asociada a la adopción de prácticas recomendadas, como las de observabilidad y contenedores.
Observabilidad. Para que una aplicación funcione de forma eficiente y fiable, debe tener en cuenta los registros, las métricas y los rastreos. Las aplicaciones de inicio ayudan a los equipos a desarrollar sus proyectos en marcos y estrategias que fomentan la observabilidad.
Prácticas recomendadas sobre contenedores Cuando crees aplicaciones en contenedores, debes crear imágenes de contenedor pequeñas y limpias. Entre las prácticas recomendadas para contenedores se incluyen empaquetar una sola aplicación en una imagen, eliminar las herramientas innecesarias de la imagen e intentar activamente producir imágenes pequeñas a partir de imágenes base mínimas.
La arquitectura de referencia proporciona una aplicación básica de Go, una aplicación básica de Java y una aplicación básica de Python como punto de partida. Debes añadir aplicaciones de inicio personalizadas para los lenguajes, las pilas de tecnología y los tipos de aplicaciones que desarrollen tus equipos.
Repositorios de inicio de infraestructura
Los repositorios de inicio de infraestructura incluyen el código preescrito necesario para crear diferentes componentes de infraestructura. Estos repositorios usan plantillas y módulos estándar, según lo decidido por el equipo de infraestructura.
Por ejemplo, en la implementación de referencia, la plantilla de plataforma contiene el código inicial para crear un Google Cloud proyecto, una nube privada virtual y un clúster de GKE. Normalmente, los equipos de infraestructura usan esta plantilla para gestionar la infraestructura que utilizan varios equipos de aplicaciones como recurso compartido. Del mismo modo, infra-template contiene código de infraestructura básico que puede necesitar una aplicación, como una base de datos de Cloud Storage o Spanner. Normalmente, los equipos de aplicaciones usan esta plantilla para gestionar la infraestructura de sus aplicaciones.
Repositorios de plantillas compartidos
Los repositorios de plantillas compartidas proporcionan plantillas de tareas estándar que cualquier miembro de una organización puede reutilizar. Por ejemplo, módulos de infraestructura como código, como los módulos de Terraform, que se pueden usar para crear recursos de infraestructura, como redes y computación.
Zonas de aterrizaje de aplicaciones
Si usas CI/CD compartido, configuración de aplicaciones compartida y políticas y configuraciones coherentes en todos los clústeres, puedes combinar estas funciones para crear zonas de aterrizaje de aplicaciones.
Una zona de aterrizaje es una entidad lógica protegida que permite a los desarrolladores implementar sus aplicaciones y hacer iteraciones en ellas. Las zonas de aterrizaje de aplicaciones usan las protecciones que has implementado para que los desarrolladores puedan trabajar de forma autónoma. Para cada aplicación, crea un espacio de nombres de Kubernetes en cada clúster de cada entorno (por ejemplo, de producción, desarrollo o staging). 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 zonas de aterrizaje:
Modelo operativo
Cuando operas una plataforma de distribución de software con CI/CD modernos, es importante mantener los entornos, la infraestructura y los procesos de forma coherente y actualizada. Por lo tanto, debes planificar y elegir cuidadosamente el modelo operativo de la plataforma. Puedes elegir entre varios modelos, como clústeres como servicio, planos o una infraestructura multiinquilino.
Como es importante mantener una infraestructura coherente, limitar la dispersión y permitir que los equipos se centren en ofrecer aplicaciones, te recomendamos que implementes una infraestructura multiinquilino. Al desplegar aplicaciones en una infraestructura multiinquilino, los equipos de aplicaciones no tienen que gestionar la infraestructura, y los equipos de operadores y de seguridad pueden centrarse en mantener la coherencia de la infraestructura.
Consideraciones sobre la infraestructura multicliente
Cuando creas una plataforma de distribución de software multiempresa, hay varios aspectos que puedes incluir en ella:
Aislamiento de cargas de trabajo. El concepto de zonas de aterrizaje de aplicaciones es proporcionar un marco para aislar las cargas de trabajo. Las zonas de aterrizaje son una combinación de espacios de nombres, políticas de red y RBAC. Todas estas políticas deben gestionarse y aplicarse de forma centralizada a través de Config Sync.
Monitorización del uso del arrendatario. Para obtener desgloses de costes de etiquetas y espacios de nombres concretos de un clúster, puedes usar la medición del uso de GKE. La medición del uso de GKE monitoriza la información de las solicitudes de recursos y el uso de los recursos de las cargas de trabajo de un clúster, que puedes filtrar por espacios de nombres y etiquetas. Cuando habilitas la medición del uso de GKE en el clúster multiinquilino, los registros de uso de recursos se escriben en una tabla de BigQuery. Puede exportar métricas específicas de un arrendatario a conjuntos de datos de BigQuery en el proyecto del arrendatario correspondiente. Los auditores pueden analizar esas métricas para determinar los desgloses de costes.
Cuotas de recursos. Para asegurarte de que todos los arrendatarios que comparten un clúster tengan un acceso justo a los recursos del clúster, debes aplicar cuotas de recursos. Crea una cuota de recursos para cada espacio de nombres en función del número de pods que implemente cada arrendatario y de la cantidad de memoria y CPU que requiera cada pod.
Varios clústeres para cada entorno. Para mejorar la fiabilidad de las aplicaciones y las plataformas, debes usar varios clústeres en cada entorno de preproducción y producción. Si tienes varios clústeres disponibles, puedes implementar aplicaciones individualmente en los clústeres para añadir niveles de validación canary. Además, tener varios clústeres reduce las preocupaciones relacionadas con el ciclo de vida de la gestión y las actualizaciones de los clústeres.
Registro y monitorización específicos del arrendatario. Para investigar las operaciones de sus aplicaciones, los inquilinos necesitan acceder a los registros y las métricas. En un entorno multiempresa, el registro y la monitorización deben ser específicos de la aplicación. Para las métricas y la monitorización, puedes usar Google Cloud Managed Service para Prometheus y Grafana en cada espacio de nombres. En el caso de los registros, debe crear un receptor para exportar las entradas de registro a conjuntos de datos de BigQuery y, a continuación, filtrar los conjuntos de datos por espacio de nombres de inquilino. Los arrendatarios podrán acceder a los datos exportados en BigQuery.
Para obtener más información sobre la infraestructura de varios propietarios, consulta el artículo Prácticas recomendadas para empresas sobre clústeres con varios propietarios.
Límites de aislamiento
Varias empresas crean y usan una plataforma de distribución de software, por lo que es importante que haya límites de aislamiento adecuados entre los diferentes componentes de la plataforma. Los límites de aislamiento ayudan a crear una plataforma sólida, ya que proporcionan las siguientes características:
Separar responsabilidades. Cada equipo gestiona los recursos de sus límites de aislamiento sin preocuparse del 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 los flujos de trabajo de CI/CD y el código de la aplicación.
Control de acceso granular. Si los recursos están segregados por límites de aislamiento, usa el control de acceso granular para limitar el acceso.
Reduce las zonas afectadas. Puedes hacer cambios en un componente de forma independiente sin que afecte a otros componentes.
Reduce los errores manuales. Como el control de acceso es granular, puedes evitar errores manuales, como desplegar accidentalmente en un clúster de producción desde un entorno de desarrollo.
Estos límites de aislamiento pueden existir entre diferentes aplicaciones, entre la infraestructura y las aplicaciones, o incluso entre los diferentes entornos de una aplicación.
Gestión
El objetivo principal de las plataformas de envío de software y los sistemas de CI/CD modernos es mejorar la eficiencia del proceso de envío de software en general. En cuanto a la gestión de la plataforma, hay dos aspectos principales que debes tener en cuenta: la incorporación de aplicaciones, que suele pertenecer a la categoría de gobernanza, y el desarrollo y el mantenimiento continuos de la plataforma (es decir, tratar la plataforma como un producto).
Incorporación y gestión de aplicaciones
El objetivo de adoptar metodologías y herramientas de CI/CD modernas es optimizar el proceso de lanzamiento y la incorporación de nuevos servicios. La incorporación de nuevas aplicaciones debe ser un proceso sencillo que puedas llevar a cabo con la mínima intervención de los equipos de operaciones y seguridad. Esto no significa que los equipos de operaciones y seguridad no participen, sino que su aportación inicial desde el punto de vista del despliegue y la seguridad se gestiona automáticamente a través del proceso de aprovisionamiento. Una vez que se han incorporado, los equipos de operaciones y seguridad se incluyen de forma natural en el proceso de lanzamiento a través de solicitudes de combinación, actualizaciones de políticas y la aplicación de prácticas recomendadas.
Te recomendamos que crees alguna automatización para incorporar una nueva aplicación. Esto puede incluir la creación de repositorios de código, flujos de procesamiento de CI/CD, zonas de aterrizaje y cualquier infraestructura necesaria para la aplicación. La automatización desacopla las complejas dependencias de los equipos de desarrollo de otros equipos de la organización y proporciona a los desarrolladores autonomía para autogestionar una aplicación. De esta forma, los desarrolladores pueden empezar a iterar en el código de la aplicación muy rápido y no perder tiempo en realizar tareas que no sean escribir el código. La automatización debe permitir que los desarrolladores ejecuten la aplicación en un entorno de desarrollo. Para llevar la aplicación a entornos superiores, deben participar otros equipos y seguir el proceso de revisión.
En la arquitectura de referencia asociada, esta automatización se denomina "Application Factory".
Plataforma como producto
El flujo de trabajo de CI/CD es un producto de software, pero sus usuarios son los equipos de desarrollo, operaciones y seguridad. Teniendo esto en cuenta, la plataforma requiere los mismos roles y procesos de desarrollo de software, como los propietarios de productos, el marketing (aunque sea interno), los bucles de comentarios de los usuarios y los ciclos de desarrollo de funciones.
Implementar CI/CD con GKE
Cuando empieces a implementar CI/CD moderno con GKE en la organización, será fundamental elegir las mejores aplicaciones piloto. Los equipos de desarrollo, operaciones y seguridad también deben tener en cuenta otros factores mientras trabajan, que se analizan en esta sección.
Seleccionar una aplicación piloto
Elegir las primeras aplicaciones que se van a migrar a la plataforma puede ser un primer paso difícil. Los servicios que procesan datos o gestionan solicitudes, pero no almacenan datos, son buenos candidatos para las pruebas piloto. Por ejemplo, las capas de almacenamiento en caché, los front-ends web o las aplicaciones de procesamiento basadas en eventos. Normalmente, estas aplicaciones son más resistentes a las pequeñas interrupciones y a los errores de implementación que pueden producirse en cualquier momento al trabajar con nuevas técnicas de gestión de la implementación y la configuración. A medida que los equipos adquieran más experiencia con la CI/CD y empiecen a disfrutar de las ventajas de la fiabilidad y la velocidad, podrás empezar a migrar los servicios principales a la plataforma de distribución de software.
Consideraciones para desarrolladores
Cuando trabajas con un proceso de desarrollo de CI/CD moderno, las funciones, los cambios y las implementaciones pueden producirse con mayor frecuencia y de forma más asíncrona. Los equipos de desarrollo deben ser conscientes de cómo afectan los cambios a los sistemas posteriores o dependientes y cómo se prueban esos cambios. Las vías de comunicación entre los equipos de desarrollo, operaciones y seguridad deben ser fluidas. Es recomendable invertir en mejores prácticas de control de versiones tanto para las aplicaciones como para los contratos de datos mediante los que se comunican los diferentes servicios. Además de mejorar los métodos de comunicación y el control de versiones, implementar funciones en pequeños fragmentos y utilizar ramas y marcas de funciones puede mejorar la forma en que pruebas y lanzas funciones.
Consideraciones para los operadores
Con una plataforma de lanzamiento de software, los equipos de operaciones deben funcionar más como equipos de desarrollo. En lugar de crear funciones orientadas al exterior, crean herramientas y procesos internos que facilitan el desarrollo, la implementación y el funcionamiento de las aplicaciones orientadas al exterior. El equipo de la plataforma, así como los equipos de desarrollo y seguridad, utilizan las herramientas de la plataforma. Los operadores deben crear herramientas que les ayuden a lanzar nuevas versiones de las aplicaciones y a restaurar las versiones anteriores en caso de que se produzcan errores en las aplicaciones o fallos en las implementaciones. Los operadores también deberían centrarse más en crear sistemas de monitorización y alertas para detectar fallos de forma proactiva y enviar alertas en consecuencia.
Consideraciones del equipo de seguridad
Los equipos de seguridad deben trabajar para que la seguridad sea una responsabilidad compartida entre ellos y los equipos de operaciones y desarrollo. Este patrón se conoce como shift left en materia de seguridad, en el que la seguridad de la información (InfoSec) participa en las primeras fases del proceso de desarrollo, los desarrolladores trabajan con herramientas aprobadas previamente y las pruebas de seguridad se automatizan. Además de estas técnicas, puedes definir y aplicar políticas de seguridad de forma programática con Policy Controller. La combinación de técnicas y herramientas permite que la seguridad se aplique de forma más proactiva.
Siguientes pasos
Prueba a implementar aspectos de esta arquitectura de CI/CD moderna.
Más información sobre las prácticas recomendadas para configurar la federación de identidades
Consulta Kubernetes y los retos de la entrega continua de software.
Información sobre los patrones de monitorización y almacenamiento de registros para despliegues híbridos y multinube.