O que há de novo no ADC 0.11 e 0.12?
August 7, 2024
Desde o lançamento do ADC (API Declarative CLI) versão 0.10 há dois meses, temos trabalhado incansavelmente para entregar duas grandes atualizações—as versões 0.11 e 0.12, juntamente com uma série de atualizações de correção direcionadas. Essas atualizações focam principalmente em suportar o Apache APISIX, melhorar funcionalidades existentes e corrigir bugs.
Adicionando Suporte ao Backend do Apache APISIX
A partir do ADC 0.11, foi introduzido suporte experimental para o backend do Apache APISIX.
O ADC agora está integrado com a API Admin do APISIX, permitindo a exportação e sincronização eficiente de recursos. Continuaremos a aprimorar sua usabilidade. A opção de backend apisix
está habilitada por padrão no ADC; os usuários só precisam configurar o endpoint da API Admin e a chave de API para se conectar.
Diferenças Entre o ADC e a API Admin
Por favor, note que o ADC não tem como objetivo alinhar-se completamente com todas as funcionalidades do APISIX, mas sim focar em um conjunto central de funcionalidades e melhores práticas. Acreditamos que investir em funcionalidades que os usuários realmente precisam, em vez de buscar cegamente uma cobertura abrangente, é o caminho para o desenvolvimento do ADC.
Embora o APISIX ofereça um alto grau de flexibilidade de configuração, essa liberdade muitas vezes vem com a complexidade de manutenção a longo prazo. Quando a gestão de configurações é transferida de um mantenedor para outro, o novo mantenedor geralmente enfrenta o desafio de entender a abordagem e o estilo de configuração únicos do mantenedor anterior, em vez de adotar diretamente um conjunto de regras de melhores práticas maduras e amplamente reconhecidas.
Por exemplo, na plataforma APISIX, os usuários podem configurar rotas que não estão diretamente vinculadas a serviços específicos, mas sim especificam recursos de upstream diretamente no nível da rota. No entanto, esse método não é suportado nativamente pelo ADC. Para alinhar-se com normas lógicas e procedimentos operacionais padronizados, a abordagem recomendada é incluir rotas dentro de um serviço específico e definir precisamente os endereços de upstream inline dentro desse serviço.
Por exemplo, em um serviço de produtos, definimos um serviço chamado Product Service
e configuramos o upstream, habilitamos plugins e definimos rotas dentro dele. Nesse modelo, várias rotas podem compartilhar a mesma configuração de upstream e plugin, simplificando muito o processo de configuração.
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"]
O exemplo acima é um formato mínimo para definição de serviço. Além disso, o ADC também suporta funcionalidades avançadas como descoberta de serviços, configurações de timeout, políticas de retry e priorização de rotas, garantindo uma configuração abrangente e flexível.
Dado que o APISIX suporta métodos de configuração mais ricos, o ADC pode encontrar inconsistências ao exportar configurações em comparação com a exibição da API Admin do APISIX, como:
- Rotas que não usam serviços serão agrupadas em um serviço para atender à hierarquia serviço-rota.
- Upstreams referenciados por ID serão inline no ponto de uso.
- Recursos de template de plugin serão substituídos por serviços contendo rotas.
Portanto, os usuários precisam revisar cuidadosamente os arquivos de definição do ADC gerados durante o processo de exportação para garantir que ainda atendam à intenção original.
Por Que o ADC é Recomendado?
Ao usar o Painel do APISIX, os usuários frequentemente precisam realizar operações repetitivas em formulários, o que pode ser tedioso e propenso a erros. Em contraste, usar o ADC para configuração declarativa envolve simplesmente escrever arquivos YAML e executar operações de sincronização. O ADC converterá automaticamente as configurações em chamadas da API Admin, permitindo implantação e gerenciamento rápidos.
Assim, o ADC pode ajudar a simplificar o processo de gerenciamento e implantação, e pode facilmente alcançar cenários de GitOps. Isso envolve gerenciar arquivos de definição YAML via um repositório Git e usar fluxos de trabalho de PR e ferramentas de CI para atualizar automaticamente as configurações. Isso reduz significativamente a quantidade de operações manuais necessárias, evita os problemas presentes no Painel do APISIX e reduz a complexidade de escrever scripts para chamar a API Admin.
Para novos projetos, recomendamos fortemente construir configurações de gateway começando com o ADC. Para projetos existentes, a migração gradual para o gerenciamento via ADC pode ser alcançada exportando e modificando moderadamente as configurações.
Otimização do Backend do API7 Enterprise
Incluído nas versões 0.11/0.12
Nas versões 0.11 e 0.12, implementamos várias otimizações para o backend do API7 para melhorar a experiência do desenvolvedor. O ADC é totalmente compatível com essas melhorias, o que significa que os desenvolvedores só precisam manter sua versão do ADC atualizada para se beneficiar desses aprimoramentos sem qualquer modificação nos arquivos de definição existentes.
Otimizando as Verificações de Definição do ADC
Incluído na versão 0.12
Otimizamos e corrigimos abrangentemente as regras de schema para verificações de definição do ADC para ajudar os desenvolvedores a detectar e evitar efetivamente problemas potenciais de configuração antecipadamente.
JSON Schema
Além disso, agora suportamos a exportação das regras de validação como um JSON Schema para auxiliar editores usando IDEs. Os usuários se beneficiarão de dicas de sintaxe e verificações em tempo real em seus arquivos, melhorando significativamente a eficiência e a qualidade de codificação.
Para desenvolvedores que preferem o Visual Studio Code, habilitar o plugin YAML e adicionar o seguinte comentário no topo do arquivo ativará essa funcionalidade:
# yaml-language-server: $schema=https://raw.githubusercontent.com/api7/adc/main/schema.json
Conclusão
Como mencionado anteriormente em nossos blogs, o ADC será eventualmente open-source. Após seis meses de desenvolvimento interno e múltiplas iterações, o ADC foi completamente reestruturado em uma base de código TypeScript, abandonando completamente o código original em Go. Isso facilita o aprendizado e o desenvolvimento.
Com o lançamento público da versão 0.12 do ADC, convidamos desenvolvedores de todo o mundo a participar de seu desenvolvimento e melhoria. A base de código agora está aberta em https://github.com/api7/adc, e esperamos suas contribuições.