¿Qué hay de nuevo en ADC 0.11 y 0.12?

Desde el lanzamiento de ADC (API Declarative CLI) versión 0.10 hace dos meses, hemos estado trabajando sin descanso para entregar dos actualizaciones importantes: las versiones 0.11 y 0.12, junto con una serie de actualizaciones de parches específicas. Estas actualizaciones se centran principalmente en la compatibilidad con Apache APISIX, la mejora de las funciones existentes y la corrección de errores.

Adición de Soporte para Apache APISIX como Backend

A partir de ADC 0.11, se ha introducido soporte experimental para el backend de Apache APISIX.

ADC ahora está integrado con la API de Administración de APISIX, permitiendo la exportación y sincronización eficiente de recursos. Continuaremos mejorando su usabilidad. La opción de backend apisix está habilitada por defecto en ADC; los usuarios solo necesitan configurar el punto final de la API de Administración y la clave API para conectarse.

Diferencias entre ADC y la API de Administración

Tenga en cuenta que ADC no tiene como objetivo alinearse completamente con todas las funcionalidades de APISIX, sino que se centra en un conjunto de características principales y mejores prácticas. Creemos que invertir en características que los usuarios realmente necesitan, en lugar de perseguir ciegamente una cobertura completa, es el camino para el desarrollo de ADC.

Aunque APISIX ofrece un alto grado de flexibilidad en la configuración, esta libertad a menudo viene con la complejidad del mantenimiento a largo plazo. Cuando la gestión de la configuración se transfiere de un mantenedor a otro, el nuevo mantenedor generalmente enfrenta el desafío de comprender el enfoque y estilo de configuración único del mantenedor anterior, en lugar de adoptar directamente un conjunto de reglas de mejores prácticas maduras y ampliamente reconocidas.

Por ejemplo, en la plataforma APISIX, los usuarios pueden configurar rutas que no están directamente vinculadas a servicios específicos, sino que especifican recursos de upstream directamente en el nivel de la ruta. Sin embargo, este método no es compatible de forma nativa con ADC. Para alinearse con las normas lógicas y los procedimientos operativos estandarizados, el enfoque recomendado es incluir rutas dentro de un servicio específico y establecer direcciones de upstream de manera precisa dentro de ese servicio.

Por ejemplo, en un servicio de productos, definimos un servicio llamado Product Service y configuramos el upstream, habilitamos plugins y establecemos rutas dentro de él. En este modelo, múltiples rutas pueden compartir la misma configuración de upstream y plugins, simplificando enormemente el proceso de configuración.

services:
  - name: Product Service
    upstream:
      type: roundrobin
      nodes:
        - host: product.ecommerce.svc.cluster.local
          port: 443
          weight: 100
      scheme: https
    plugins:
      key-auth: {}
    routes:
      - name: List Products
        uris:
          - /products
        methods: ["GET"]
      - name: Get Product
        uris:
          - /product/*
        methods: ["GET"]

El ejemplo anterior es un formato mínimo para la definición de servicios. Más allá de esto, ADC también admite características avanzadas como la detección de servicios, configuraciones de tiempo de espera, políticas de reintento y priorización de rutas, asegurando una configuración completa y flexible.

Dado que APISIX admite métodos de configuración más ricos, ADC puede encontrar inconsistencias al exportar configuraciones en comparación con la visualización de la API de Administración de APISIX, como:

• Las rutas que no utilizan servicios se agruparán en un servicio para cumplir con la jerarquía servicio-ruta.
• Los upstreams referenciados por ID se incluirán en línea en el punto de uso.
• Los recursos de plantillas de plugins serán reemplazados por servicios que contienen rutas.

Por lo tanto, los usuarios deben revisar cuidadosamente los archivos de definición de ADC generados durante el proceso de exportación para asegurarse de que aún cumplen con la intención original.

¿Por qué se Recomienda ADC?

Al usar el Panel de Control de APISIX, los usuarios a menudo necesitan realizar operaciones repetitivas en formularios, lo que puede ser tedioso y propenso a errores. En contraste, usar ADC para la configuración declarativa implica simplemente escribir archivos YAML y ejecutar operaciones de sincronización. ADC convertirá automáticamente las configuraciones en llamadas a la API de Administración, permitiendo una implementación y gestión rápidas.

Por lo tanto, ADC puede ayudar a simplificar el proceso de gestión e implementación, y puede lograr fácilmente escenarios de GitOps. Esto implica gestionar archivos de definición YAML a través de un repositorio Git y usar flujos de trabajo de PR y herramientas de CI para actualizar automáticamente las configuraciones. Esto reduce significativamente la cantidad de operaciones manuales requeridas, evita los problemas presentes en el Panel de Control de APISIX y reduce la complejidad de escribir scripts para llamar a la API de Administración.

Para nuevos proyectos, recomendamos encarecidamente construir configuraciones de puerta de enlace comenzando con ADC. Para proyectos existentes, se puede lograr una migración gradual a la gestión de ADC exportando y modificando moderadamente las configuraciones.

Optimización del Backend de API7 Enterprise

Incluido en las versiones 0.11/0.12

En las versiones 0.11 y 0.12, hemos implementado varias optimizaciones para el backend de API7 para mejorar la experiencia del desarrollador. ADC es completamente compatible con estas mejoras, lo que significa que los desarrolladores solo necesitan mantener su versión de ADC actualizada para beneficiarse de estas mejoras sin necesidad de modificar los archivos de definición existentes.

Optimización de las Comprobaciones de Definición de ADC

Incluido en la versión 0.12

Hemos optimizado y corregido exhaustivamente las reglas de esquema para las comprobaciones de definición de ADC para ayudar a los desarrolladores a detectar y evitar efectivamente posibles problemas de configuración de antemano.

JSON Schema

Además, ahora admitimos la exportación de las reglas de validación como un JSON Schema para ayudar a los editores que usan IDEs. Los usuarios se beneficiarán tanto de sugerencias de sintaxis como de comprobaciones en tiempo real en sus archivos, mejorando significativamente la eficiencia y calidad de codificación.

Para los desarrolladores que prefieren Visual Studio Code, habilitar el plugin de YAML y agregar el siguiente comentario al inicio del archivo activará esta función:

# yaml-language-server: $schema=https://raw.githubusercontent.com/api7/adc/main/schema.json

Conclusión

Como se mencionó anteriormente en nuestros blogs, ADC eventualmente será de código abierto. Después de seis meses de desarrollo interno y múltiples iteraciones, ADC ha sido completamente reestructurado en una base de código basada en TypeScript, abandonando completamente el código original en Go. Esto lo hace más fácil de aprender y desarrollar.

Con el lanzamiento público de ADC versión 0.12, invitamos a desarrolladores de todo el mundo a participar en su desarrollo y mejora. La base de código ahora está abierta en https://github.com/api7/adc, y esperamos sus contribuciones.