En pocas palabras, la idea detrás de los lanzamientos canary es entregar una nueva versión de software solo a una fracción de los usuarios, analizar los resultados y decidir si continuar o no. Si los resultados no están alineados con las expectativas, retroceder; si es así, aumente la cantidad de usuarios expuestos hasta que todos los usuarios se beneficien de la nueva versión.  En esta publicación, me gustaría detallar brevemente esta introducción, explicar diferentes formas de definir la fracción y mostrar cómo ejecutarla con  Apache APISIX.  Introducción a los lanzamientos canarios.  El término "canario" proviene de la industria minera del carbón. Durante la minería, no es raro que se liberen gases tóxicos: en un espacio pequeño y cerrado, puede significar una muerte rápida. Peor aún, el gas puede ser inodoro, por lo que los mineros lo respirarían hasta que fuera demasiado tarde para irse. El monóxido de carbono es bastante común en las minas de carbón y no es detectable por los sentidos humanos.  Por esta razón, los mineros trajeron canarios bajo tierra. Si el canario caía muerto repentinamente, había muchas posibilidades de que se hubiera roto esa bolsa de gas y ya era hora de abandonar el lugar.  Hace años, adoptamos este enfoque para lanzar una nueva versión de software. La analogía es la siguiente: los mineros son el equipo de operaciones que implementa la versión, el canario consta de todas las herramientas para medir el impacto de la liberación y el gas es un error (crítico).  La parte más crucial es que   del lanzamiento, incluidas las tasas de falla, los códigos de estado HTTP, etc., y compararlos con los de la versión anterior. Está fuera del alcance de esta publicación, pero nuevamente, es fundamental si desea beneficiarse de las versiones canary. La segunda parte más importante es la capacidad de retroceder rápidamente si la nueva versión tiene errores. debe medir el impacto  Lanzamientos canarios frente a indicadores de funciones  Tenga en cuenta que las versiones canary no son la única forma de gestionar el riesgo de publicar código nuevo. Por ejemplo, las marcas de funciones son otra forma popular:  El enfoque canary ofrece el conjunto completo de funciones en la nueva versión del componente.  Los indicadores de funciones también implementan el componente, pero los parámetros de configuración dedicados permiten activar y desactivar cada función individualmente.  Los indicadores de funciones representan un enfoque más ágil (en el verdadero sentido de la palabra) hacia las reversiones. Si una característica de cada 10 tiene errores, no es necesario cancelar la implementación de la nueva versión; solo desactivas la función de errores. Sin embargo, este superpoder tiene el costo de una complejidad adicional del código base, independientemente de si depende de productos de terceros o lo implementa usted mismo.  Por otro lado, Canary requiere una canalización de implementación madura para poder implementar y cancelar la implementación a voluntad.  Aproximaciones a las liberaciones canarias  La idea detrás de las versiones canary es permitir que solo una fracción de usuarios acceda a la nueva versión. La mayoría de las definiciones canarias sólo definen "fracción" como un porcentaje de usuarios. Sin embargo, hay más.  El primer paso puede ser permitir que solo los usuarios examinados verifiquen que la implementación en el entorno de producción funciona como se esperaba. En este caso, puede reenviar sólo un conjunto específico de usuarios internos,   , evaluadores, a la nueva versión. Si conoces a las personas de antemano y el sistema autentica a los usuarios, puedes configurarlo por identidad; de lo contrario, debe recurrir a alguna forma genérica,   , encabezados HTTP -   . por ejemplo por ejemplo X-Canary: Let-Me-Go-To-v2  Recuerde que debemos monitorear los sistemas antiguos y nuevos para detectar discrepancias. Si no aparece nada, es un momento excelente para aumentar el grupo de usuarios reenviados a la nueva versión. Supongo que comes tu propia comida para perros,   ; Los miembros del equipo utilizan el software que están desarrollando. Si no tiene, por ejemplo, un sitio de comercio electrónico para automóviles de lujo, puede omitir esta sección. es decir  Para aumentar la fracción de usuarios y al mismo tiempo limitar los riesgos, ahora podemos proporcionar indiscriminadamente la nueva versión a los usuarios internos. Podemos configurar el sistema para reenviar a la nueva versión según la IP del cliente para hacer esto. En una época en la que la gente trabajaba en el sitio, era fácil ya que sus IP estaban en un rango específico. El control remoto no cambia mucho ya que los usuarios probablemente accedan a la red de la empresa a través de una VPN.  Nuevamente, supervise y compare en este punto.  Los nueve metros completos  En este punto, todo debería funcionar como se espera para los usuarios internos, ya sean algunos o todos. Pero así como ningún plan sobrevive al contacto con el enemigo, ningún uso puede imitar toda la diversidad de una carga de trabajo de producción. En definitiva, debemos dejar que los usuarios habituales accedan a la nueva versión, pero de forma controlada, tal y como hemos ido aumentando progresivamente el número de usuarios hasta ahora: empezar con una pequeña fracción, monitorizarla y, si todo está bien, aumentar la fracción. .  Aquí se explica cómo hacerlo con Apache APISIX. Apache APISIX ofrece una arquitectura basada en complementos y proporciona un complemento que satisface nuestras necesidades, es decir, el complemento   . traffic-split  El complemento   se puede utilizar para dirigir dinámicamente partes del tráfico a varios servicios Upstream. traffic-split  Esto se hace configurando   , que son reglas personalizadas para dividir el tráfico, y   , que es un conjunto de Upstreams a los que dirigir el tráfico. match weighted_upstreams  --  tráfico dividido  Comencemos con algunos upstreams básicos, uno para cada versión:   upstreams: - id: v1 nodes: "v1:8080": 1 - id: v2 nodes: "v2:8080": 1  Podemos usar el complemento   para reenviar la mayor parte del tráfico a v1 y una fracción a v2: traffic-split   routes: - id: 1 uri: "*" #1 upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: #2 - upstream_id: v2 #3 weight: 1 #3 - weight: 99 #3  Definir una ruta general  Configurar cómo dividir el tráfico; aquí, pesas  Reenvíe el 99% del tráfico a v1 y el 1% a v1. Tenga en cuenta que los pesos son relativos entre sí. Para lograr 50/50, puedes establecer pesos 1 y 1, 3 y 3, 50 y 50, etc.  Nuevamente, monitoreamos todo y nos aseguramos de que los resultados sean los esperados. Luego, podemos aumentar la fracción del tráfico reenviado a v2,   : por ejemplo   routes: - id: 1 uri: "*" upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: - upstream_id: v2 weight: 5 #1 - weight: 95 #1  Aumentar el tráfico a v2 al 5%  Tenga en cuenta que Apache APISIX recarga los cambios en el archivo anterior cada segundo. Por lo tanto, divide el tráfico casi en tiempo real. Alternativamente, puede utilizar la API de administración para lograr lo mismo.  Lanzamientos más controlados  En lo anterior, pasé de usuarios internos a una fracción de usuarios externos. Quizás liberar a todos los usuarios internos sea un riesgo demasiado grande en su organización y necesite aún más control. Tenga en cuenta que en este caso puede configurar aún más el complemento   . traffic-split   routes: - id: 1 uri: /* upstream_id: v1 plugins: traffic-split: rules: - match: - vars: [["http_X-Canary","~=","Let-Me-Go-To-v2"]] #1 - weighted_upstreams: - upstream_id: v2 weight: 5 - weight: 95  Solo divida el tráfico si el encabezado HTTP   tiene el valor configurado. X-Canary  El siguiente comando siempre reenvía a v1:   curl http://localhost:9080  El siguiente comando también reenvía siempre a v1:   curl -H 'X-Canary: Let-Me-Go-To-v1' http://localhost:9080  El siguiente comando divide el tráfico según los pesos configurados,   , 95/5: es decir   curl -H 'X-Canary: Let-Me-Go-To-v2' http://localhost:9080  Conclusión  Esta publicación explica las versiones canary y cómo se puede configurar una a través de Apache APISIX. Puede comenzar con varias rutas con diferentes prioridades y pasar al complemento   . Este último incluso se puede configurar aún más para permitir casos de uso más complejos. traffic-split  El código fuente completo de esta publicación se puede encontrar en   . GitHub   Para llegar más lejos:   Implementación de solución canary release basada en Apache APISIX   Lanzamiento Canary en Kubernetes con Apache APISIX Ingress   Lanzamiento fluido de Canary usando el controlador de ingreso APISIX con Flagger  Publicado originalmente en   el 3 de diciembre de 2023 A Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Este audio es producido en el idioma original de la historia!

Implementación de versiones Canary con Apache APISIX

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Una breve introducción a la teoría del cerebro de Boltzmann

El modelo Bitcoin UTXO, impulsando un ecosistema único

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Una breve introducción a la teoría del cerebro de Boltzmann

El modelo Bitcoin UTXO, impulsando un ecosistema único

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps