La ruta de actualización de 5 pasos para DevOps nativo en la nube

Autor |
Editado por Zhang Yu |
Fuente Yachun | Cuenta oficial nativa de Alibaba Cloud

Que es DevOps nativo en la nube

Haga clic para ver el video:https://v.qq.com/x/page/u3220cutt7v.html

Primero usemos el video corto anterior y las siguientes dos imágenes para comprender qué es DevOps nativo en la nube y en qué se diferencia de DevOps.

La imagen de arriba es un puesto de comida. El chef de la imagen está trabajando muy duro para cortar, freír, preparar varios tipos de comida y venderla. Desde la adquisición de materias primas hasta el procesamiento, la venta y la posventa, una o dos personas lo completan. Este es un escenario DevOps muy típico, el equipo maneja todo de un extremo a otro. En este caso, cuando el chef tiene un nivel relativamente alto y una gran capacidad de ventas, se puede lograr una alta eficiencia y un bajo desperdicio. Pero el problema es que será difícil escalar. Debido a que sus procesos no son estándar, requiere que el chef tenga una gran capacidad personal.

Veamos la foto del puesto de comida de Nanjing de arriba. Aunque hay un puesto de comida en el nombre, obviamente no es el puesto de comida que mencionamos anteriormente. Cuando entramos en cualquier puesto de comida de Nanjing, podemos encontrar que los chefs del puesto de comida de Nanjing pueden concentrarse en ofrecer a los clientes mejores platos, desarrollar y probar nuevos platos y probarlos y promocionarlos a través de pequeños grupos de usuarios. Ya sea que el número de usuarios aumente o disminuya, pueden adaptarse rápidamente. La expansión de la tienda también puede ser rápida. Podemos entender esto como DevOps nativo de la nube.

Entonces, ¿qué es exactamente DevOps nativo en la nube? Creemos que DevOps nativo de la nube consiste en hacer un uso completo de la infraestructura nativa de la nube, basada en microservicios / sistemas de arquitectura sin servicio y estándares de código abierto, independientes del lenguaje y el marco, con entrega continua y capacidades inteligentes de autooperación y mantenimiento, para lograr un DevOps más alto que el tradicional. La calidad del servicio y los menores costos de desarrollo y operación permiten que la I + D se concentre en una iteración comercial rápida .

Como se muestra en la figura anterior, DevOps nativo de la nube se basa en dos principios: cumplimiento de estándares abiertos, independencia del lenguaje y del marco; dos fundamentos: arquitectura de microservicio / sin servicio, infraestructura sin servidor BaaS / FaaS; dos capacidades: autooperación inteligente y mantenimiento , Entrega continua. 

• Dos principios: el cumplimiento de estándares abiertos, el lenguaje y el marco no tienen nada que ver. En comparación con un lenguaje específico y un marco específico, puede tener una mayor flexibilidad, un mejor desarrollo y vitalidad cuando la tecnología se actualiza o iteraciones, y puede formar una mejor ecología.

• Dos fundamentos: Basado en microservicios y arquitecturas sin servicio, DevOps puede ser posible; la infraestructura basada en servidores está orientada a los recursos y a la demanda para lograr una mayor flexibilidad.

• Con base en estos dos principios y dos fundamentos, se logran dos capacidades: entrega continua y autooperación y mantenimiento inteligente.

Caso de actualización de DevOps nativo en la nube de Alibaba

Veamos primero un caso de transformación DevOps nativa de la nube de un equipo de Alibaba. Antecedentes del caso: un equipo de comercio electrónico en el extranjero de Ali se enfrenta a muchos desafíos en los mercados extranjeros, como muchos sitios, altos costos de construcción del sitio, cambios rápidos en la demanda, entrega lenta y altos costos de operación y mantenimiento. Cómo actualizar sin problemas a DevOps nativo de la nube para resolver estos problemas y mejorar la eficiencia de la entrega comercial ¿Qué? Esto es lo que hacemos.

1. Malla y sidecar de gobernanza del servicio de actualización de la arquitectura

El primer paso es actualizar la arquitectura. Primero, el código de gobernanza del servicio se sumerge en la parte del sidecar fuera de la aplicación y, al mismo tiempo, la red de servicio se utiliza para transportar capacidades como el enrutamiento ambiental. Como se muestra en la figura anterior, cada punto verde representa un código de aplicación de servicio y cada punto naranja representa un código de gestión de servicio.Estos códigos se almacenan en este contenedor en forma de paquete de dos partes. Con la construcción del sistema de gobierno del servicio, este contiene muchas cosas, como recolección de registros, monitoreo de puntos de enterramiento, intervención de operación y mantenimiento, etc. A este tipo de contenedor lo llamamos contenedor rico. El problema es obvio: incluso si se trata de una actualización o un ajuste de la recopilación de registros, necesitamos actualizar, compilar e implementar la aplicación nuevamente. Sin embargo, esto no tiene nada que ver con la aplicación en sí. Al mismo tiempo, debido a que las preocupaciones no están separadas, un error en la recopilación de registros afectará a la aplicación en sí.

Para permitir que la aplicación se centre más en la aplicación en sí, lo primero que hicimos fue separar todo el código de gobierno del servicio del contenedor de la aplicación y ponerlo en el sidecar, de modo que haya dos códigos de gobierno y aplicación del servicio. En el contenedor. Al mismo tiempo, entregamos algunas de las tareas originales de administración de servicios, como el enrutamiento de prueba y el seguimiento de enlaces, al sidecar Mesh. De esta manera, la aplicación es delgada y la aplicación solo necesita preocuparse por el código de la aplicación en sí.

La ventaja de esto es que la empresa puede centrarse en el código de aplicación relacionado con la empresa sin depender de la gobernanza del servicio.

Este es el primer paso, y este paso es sencillo, porque podemos migrar gradualmente el gobierno del servicio al sidecar sin preocuparnos por el costo excesivo de una migración.

2. Actualización de la arquitectura: desde el desacoplamiento de la construcción, el desacoplamiento de versiones hasta el desacoplamiento de operación y mantenimiento

En el segundo paso, hicimos tres niveles de desacoplamiento: desacoplamiento de construcción, desacoplamiento de liberación y desacoplamiento de operación y mantenimiento.

Aquellos que entienden los microservicios y las arquitecturas sin servicio deben saber que solo cuando una empresa puede desarrollarse, probarse, lanzarse y operarse de forma independiente, la empresa puede funcionar más rápido y mejor. Porque esto minimiza el acoplamiento con otras personas. Pero también sabemos que a medida que los servicios se vuelven cada vez más complejos y las aplicaciones continúan evolucionando, las aplicaciones contendrán cada vez más códigos comerciales. Por ejemplo, en la aplicación de la figura siguiente, algunos códigos son para una empresa específica. Por ejemplo, como aplicación de pago, algunos son para las necesidades específicas de Hema, algunos son para las necesidades específicas de Tmall y algunos son códigos generales. , O código de plataforma, es para todos los escenarios empresariales.

Obviamente, desde la perspectiva de mejorar la eficiencia del desarrollo, las partes comerciales pueden cambiar sus códigos comerciales relacionados para reducir los costos de comunicación y mejorar la eficiencia de la I + D. Pero esto genera un nuevo problema: si una determinada empresa necesita cambios, pero no implica la lógica empresarial general, también es necesario volver completamente a todas las empresas de toda la aplicación. Si hay otros cambios empresariales durante este período de tiempo, Necesitan integrarse y publicar juntos. Si hay muchos cambios en el negocio, todos deben hacer cola para la integración. En este caso, el costo de las pruebas de integración y la comunicación y coordinación es muy alto.

Nuestro objetivo es que cada negocio se pueda desarrollar, lanzar y operar de forma independiente. Para lograr este objetivo sin problemas, lo primero que debemos hacer es desacoplarlos en la fase de construcción. Por ejemplo, para una empresa relativamente independiente, la compilamos como una imagen de contenedor por separado y la colocamos en el contenedor init del pod mediante la orquestación. Cuando se inicia el pod, se monta en el espacio de almacenamiento del contenedor de la aplicación principal.

Pero en este momento, el lanzamiento de la aplicación y la operación y el mantenimiento todavía están juntos, debemos separarlos.

Sabemos que la intimidad de las aplicaciones se puede dividir aproximadamente en tres categorías:

• Super estrecha, en el mismo proceso, comunicación mediante llamadas a funciones.

• Los diferentes contenedores ubicados en el mismo Pod se comunican a través de IPC.

• Están en la misma red y se comunican a través de RPC.

Podemos dividir gradualmente algunos códigos comerciales en servicios RPC o IPC de acuerdo con las características del negocio para que puedan liberarse y operarse de forma independiente.

Hasta el momento hemos completado el desacoplamiento de construcción, desacoplamiento de liberación y desacoplamiento de operación y mantenimiento del contenedor de aplicación.

3. IAC y GitOps

El tercer paso nos fijamos en el estado de desarrollo y operación y mantenimiento. En muchos escenarios de I + D, un problema espinoso es: diferentes entornos y empresas tendrán muchas configuraciones propias y únicas. Durante el lanzamiento, la operación y el mantenimiento, a menudo es necesario modificar y seleccionar la configuración correcta de acuerdo con la situación, y esta configuración y código de aplicación. En realidad, es parte del lanzamiento en sí, y el costo del mantenimiento tradicional a través de la consola será muy alto.

En el contexto de la nube nativa, creemos que IaC (infraestructura como código) y GitOps son mejores opciones. Además de una base de código para cada aplicación, también tenemos un repositorio IaC. Este repositorio contendrá la versión de imagen de la aplicación y toda la información de configuración relacionada. Cuando es necesario publicar cambios de código o cambios de configuración, todos se envían al almacén de IaC en forma de inserción de código. El motor de GitOps puede detectar automáticamente los cambios de IaC y traducirlos automáticamente en configuraciones que cumplan con las especificaciones de OAM, y luego aplicar los cambios al entorno correspondiente según el modelo de OAM. Ya sea que se trate de desarrollo o de operación y mantenimiento, puede conocer qué cambios se han realizado en el sistema a través de la versión del código IaC, y cada lanzamiento está completo.

4. BaaSization de recursos

El último paso es la BaaSization de recursos.

Imaginemos cómo usar los recursos en la aplicación. Por lo general, primero vamos a la consola correspondiente para enviar una solicitud de recursos, describimos las especificaciones y los requisitos de recursos que necesitamos y luego obtenemos la cadena de conexión y la información de autenticación del recurso después de aprobar la aprobación. Agregue la configuración del recurso a la configuración de la aplicación, si luego hay algún cambio, vaya a la consola correspondiente para operarlo y coopere con el lanzamiento del código para su aprobación. Por supuesto, la operación, el mantenimiento y la monitorización de dichos recursos se realizan generalmente en una consola independiente.

Cuando tenemos cada vez más tipos de recursos, los costos de operación y mantenimiento son muy altos, especialmente cuando se construye un nuevo sitio.

Basándonos en el principio de describir los recursos de manera declarativa y usarlos bajo demanda, definimos estos recursos en IaC para simplificar el uso de recursos por parte de todas las aplicaciones. Todos los recursos se describen de forma declarativa, lo que permite una gestión inteligente y el uso de los recursos bajo demanda. Al mismo tiempo, todos nuestros recursos utilizan recursos comunes y protocolos estándar en la nube, lo que reduce en gran medida los costos de migración. De esta forma, migramos gradualmente el equipo empresarial a la infraestructura nativa de la nube.

Por tanto, los dos puntos clave de BaaSization de recursos son:

• Describa de forma declarativa los requisitos de recursos, administre de forma inteligente y utilice según demanda.

• Utilice recursos comunes en la nube para alinear los protocolos estándar.

La eficiencia de la nube impulsa la implementación eficiente de DevOps nativos de la nube

Lo que compartimos anteriormente es la práctica interna de Ali, que se basa en la plataforma de colaboración interna de I + D de Ali, Aone. La versión de nube pública de Aone es Alibaba Cloud Cloud. ¿Cómo implementamos DevOps nativos de la nube a través de los efectos en la nube de Alibaba Cloud?

Del caso anterior, podemos ver que la implementación de DevOps nativo de la nube es un proyecto sistemático, que incluye métodos, arquitectura, colaboración e ingeniería. Entre ellos, la implementación de DevOps nativo de la nube pertenece a la categoría de entrega ajustada.

La imagen de arriba es un diagrama de solución DevOps nativa de la nube con efecto de nube.

Aquí, dividimos a los usuarios en 2 roles:

• Jefe técnico o arquitecto.

• Ingenieros, incluidos desarrollo, pruebas, operación y mantenimiento, etc.

Como director técnico o arquitecto, necesita definir y controlar el comportamiento de I + D de la empresa en su conjunto. Desde una perspectiva amplia, el proceso de I + D incluye cuatro aspectos: operable, observable, manejable y cambiante.

En primer lugar, definirá el modelo de colaboración en I + D de la empresa, por ejemplo, si adoptar I + D ágil o Kanban lean. En segundo lugar, debe dominar la arquitectura general del producto, por ejemplo, qué productos en la nube deben usarse y cómo se coordinan y administran estos productos en la nube. Luego decidirá el modelo de I + D del equipo: cómo colaborar en I + D, cómo controlar la calidad de I + D, etc. En el tercer paso, debe determinar la estrategia de lanzamiento, si usar el lanzamiento en escala de grises o la implementación azul-verde, cuál es la estrategia de escala de grises, etc. Finalmente, es la estrategia de monitoreo del servicio, como a qué plataformas de monitoreo debe acceder el servicio, cómo detectar el estado del servicio, configuración de monitoreo global, etc.

Los ingenieros de desarrollo, pruebas, operación y mantenimiento de primera línea se enfocan en la suavidad y eficiencia del proceso de trabajo. Una vez que la plataforma de colaboración del proyecto de efecto nube recibe un requisito o tarea, se puede codificar, enviar, construir, integrar, publicar y probar a través del efecto nube, e implementar en el entorno de producción y prelanzamiento, y el modo de I + D y la versión configurados por el administrador La estrategia realmente aterrizó. Al mismo tiempo, cada entorno se activa y fluye automáticamente, sin coordinación ni atracción humana.

Los datos generados durante todo el proceso de I + D son un todo orgánico, que puede generar una gran cantidad de información sobre los datos e impulsar al equipo a realizar una mejora continua. Cuando el equipo encuentra cuellos de botella o confusión en el proceso de I + D, también puede obtener asesoramiento de diagnóstico profesional y orientación en I + D del equipo de expertos en eficiencia de la nube.

En resumen, la solución DevOps nativa de la nube de Cloud Efficiency está guiada por la metodología ALPD, basada en las mejores prácticas recomendadas por los expertos y profundamente integrada en la cadena completa de herramientas DevOps para ayudar a las empresas a pasar gradualmente a DevOps nativas de la nube.

A continuación, analizamos un caso específico.

Una empresa de Internet tiene un equipo de I + D de unas 30 personas y no cuenta con personal de operación y mantenimiento a tiempo completo. Sus productos incluyen más de 20 microservicios y decenas de aplicaciones front-end (web, applets, aplicaciones, etc.). Su negocio está creciendo muy rápido.Ante el rápido crecimiento de los clientes y las crecientes demandas, el método de implementación original basado en script basado en Jenkins + ECS ha fallado gradualmente en satisfacer las demandas, especialmente el problema de las actualizaciones de implementación sin tiempo de inactividad. . Como resultado, comencé a necesitar la ayuda de la eficiencia de la nube y finalmente migré por completo a DevOps nativo de la nube de eficiencia de la nube.

Este equipo de I + D se enfrenta a tres grandes problemas:

• Gran número de clientes y muchas necesidades urgentes.

• Sin operación y mantenimiento a tiempo completo, las tecnologías nativas de la nube como K8 tienen un alto umbral de aprendizaje.

• La infraestructura de TI es compleja y requiere mucho tiempo y trabajo para su lanzamiento.

En respuesta a estos problemas, la eficiencia de la nube comienza a partir de tres aspectos: las capacidades básicas , capacidades de liberación, y capacidades de operación y mantenimiento .

Primero, introduzca Alibaba Cloud ACK para actualizar la infraestructura sobre los recursos ECS existentes y transformar la aplicación en contenedores. En términos de gobernanza de servicios y arquitectura de aplicaciones, el segmento de la familia Spring Cloud se simplifica a SpringBoot, y el descubrimiento y la gobernanza de servicios son compatibles con las capacidades estándar de K8.

En segundo lugar, la implementación automática de contenedores se realiza a través de la canalización del efecto nube, y la estrategia de implementación en escala de grises se puede utilizar para lograr una expansión automática en línea en escala de grises y un reinicio automático en caso de falla. Al mismo tiempo, en base a la canalización de eficiencia de la nube, puede lograr un tiempo de inactividad cero y reducir rápidamente cualquier costo, lo que ahorra costos de máquina Al mismo tiempo, se resuelve el problema de la falta de personal de operación y mantenimiento a tiempo completo en la empresa.

En tercer lugar, a través de la línea de ensamblaje automatizada de eficiencia en la nube y el modelo estándar de investigación y desarrollo de protección de sucursales, que incluye revisión de código, inspección de código, puntos de tarjeta de prueba, etc., para mejorar la eficiencia de la retroalimentación y la calidad de publicación.

La siguiente figura es el diagrama de arquitectura de la solución general.

Ruta de actualización de DevOps nativa de la nube

Dividimos la implementación de DevOps nativo en la nube en 5 etapas.

La primera etapa: Toda la entrega manual y operación y mantenimiento . Es nuestra etapa inicial. La arquitectura de la aplicación aún no ha experimentado la transformación del servicio, ni ha utilizado infraestructura en la nube o solo IaaS. No hay integración continua, automatización de pruebas, implementación manual, lanzamiento y operación y mantenimiento manuales. Creo que pocas empresas se quedan en esta etapa.

La segunda etapa: entrega, operación y mantenimiento basados ​​en herramientas . Lo primero que hay que hacer es servir la arquitectura de la aplicación y usar la arquitectura de microservicios para mejorar la calidad del servicio; en segundo lugar, introducir algunas herramientas de I + D, como gitlab, jenkins y otras herramientas estilo isla para resolver algunos problemas. Al mismo tiempo, comenzamos a implementar la integración continua de módulos individuales, pero por lo general no existe un punto de estancamiento de calidad automatizado, y el lanzamiento a menudo es asistido por herramientas automatizadas.

La tercera etapa: entrega continua limitada y operación y mantenimiento automatizados . Mejoramos aún más nuestras capacidades básicas y transformamos nuestra infraestructura en contenedores basados ​​en CaaS. Por otro lado, comenzó a introducir una cadena de herramientas completa para abrir datos de investigación y desarrollo, por ejemplo, utilizando una plataforma de herramientas como DevOps con efecto nube para lograr la interoperabilidad completa de todos los datos. Se puede lograr una implementación continua en términos de capacidades de lanzamiento, pero se requiere una cierta cantidad de intervención manual. En este momento, las pruebas automatizadas se han convertido en algo habitual, se puede observar el servicio en su conjunto y la operación y el mantenimiento pueden estar orientados al servicio y ser declarativos.

La cuarta etapa: entrega continua y autooperación y mantenimiento asistidos manualmente . Además, permitimos que nuestros estudiantes de desarrollo se centraran en el desarrollo empresarial. Primero, comenzamos a adoptar una gran cantidad de arquitecturas sin servicio en la arquitectura de la aplicación y logramos una implementación continua sin supervisión; la escala de grises y la reversión de las versiones se pueden automatizar tanto como sea posible con la intervención . La capacidad de observación se actualiza desde el nivel de la aplicación hasta el nivel empresarial, reconociendo la observabilidad del negocio y pudiendo realizar parte de la autooperación y el mantenimiento con asistencia manual.

La quinta etapa: entrega continua a través del enlace y autooperación y mantenimiento . Este es el objetivo final que buscamos. En esta etapa, todas nuestras aplicaciones e infraestructura adoptan una arquitectura sin servicio y logran una entrega continua sin supervisión de un extremo a otro, incluida la reversión de la versión y la escala de grises también están automatizadas; las instalaciones y los servicios técnicos son completamente autooperados y mantenidos . Los desarrolladores realmente solo necesitan preocuparse por el desarrollo y la iteración del negocio.

Sin embargo, el diablo está en los detalles. Por supuesto, todavía hay muchos problemas que debemos resolver cuando realmente aterrizamos. Con la ayuda de una plataforma de herramientas como Cloud Effect y la consulta de expertos de ALPD, podemos evitar desvíos y lograr nuestros objetivos más rápido. .