Se o seu pipeline baixa o RPM e o schema diretamente de uma URL externa a cada execução, vale revisar o que acontece quando essa origem muda, deixa de receber atualizações ou exige outro processo de autenticação.
Na discussão “Changes to DO and AS3 GitHub — no longer monitored”, participantes relataram dificuldades com downloads, schemas e descoberta de versões. A resposta da F5 explicou a centralização da distribuição no <a href://my.f5.com>MyF5</a> e o direcionamento dos chamados aos canais de suporte apropriados.
Isso não deve ser interpretado, isoladamente, como anúncio de descontinuação do AS3 ou do Declarative Onboarding. Entretanto, exige revisar pipelines construídos em torno da distribuição anterior.
A proposta abaixo separa aquisição de software, validação e implantação. O objetivo é conseguir reproduzir uma mudança e investigar uma falha sem depender de descobrir, durante o deploy, qual pacote ou schema estava disponível.
- Separe atualização das extensões e publicação de configurações
Declarative Onboarding e AS3 têm responsabilidades diferentes.
DO é utilizado para configuração declarativa de aspectos de infraestrutura do BIG-IP, conforme os recursos suportados pela versão. AS3 gerencia configurações declarativas dos serviços de aplicação.
Eu manteria três fluxos separados:
- Aquisição, homologação e instalação das extensões.
- Onboarding e alterações de infraestrutura com DO.
- Publicação dos serviços de aplicação com AS3.
Uma alteração de pool não precisa provocar uma atualização do AS3. Da mesma forma, o pipeline de aplicação não deve reaplicar automaticamente uma declaração de onboarding.
Essa separação permite identificar se uma regressão veio da extensão, da configuração de infraestrutura ou da declaração da aplicação.
- Promova um conjunto de artefatos identificado
Para cada mudança, registre:
| Componente | Informação necessária |
|---|---|
| BIG-IP | Versão, build, hotfix e módulos provisionados |
| Extensão | Nome, versão e release do RPM |
| Integridade | SHA-256 do artefato aprovado |
| Schema | Versão, origem e dependências |
| Declaração | Commit e identificação da configuração renderizada |
| Executor | Versões do runner, ferramentas e bibliotecas |
| Destino | Dispositivo e escopo autorizado da alteração |
Obtenha o pacote pelo canal oficial disponível para a versão e publique uma cópia aprovada em um repositório interno com controle de acesso e versionamento imutável.
O pipeline de produção deve consumir esse artefato homologado. Não deve selecionar automaticamente uma nova versão porque ela passou a aparecer em um endereço chamado latest.
Um checksum calculado internamente permite detectar alterações posteriores no arquivo. Ele não comprova, sozinho, sua autenticidade. Registre a procedência e verifique assinaturas ou hashes publicados pelo fornecedor quando disponíveis.
- Trate o schema como uma dependência da mudança
No AS3, $schema e schemaVersion têm funções distintas.
$schema pode orientar a validação e o autocomplete no editor. schemaVersion, na declaração ADC, identifica a versão do schema utilizada pela declaração. Alterar a URL de $schema não atualiza a extensão instalada no BIG-IP.
Mantenha uma cópia identificada do schema correspondente à combinação homologada. Se houver referências externas por $ref, preserve também as dependências necessárias.
Configure o validador do CI para utilizar esse conjunto explicitamente. O simples fato de existir um campo $schema não garante que a ferramenta de validação irá carregá-lo.
A validação precisa responder a três perguntas diferentes:
- O documento é um JSON válido?
- A declaração atende ao schema selecionado?
- A extensão instalada consegue aplicar essa declaração no ambiente de destino?
A aprovação no schema não comprova disponibilidade de módulos, existência de objetos referenciados ou funcionamento da aplicação.
- Confira a extensão instalada antes de enviar a declaração
Utilize os endpoints de informação:
GET /mgmt/shared/appsvcs/info
GET /mgmt/shared/declarative-onboarding/info
Compare os dados retornados com o conjunto aprovado para a mudança.
Exemplo de consulta ao AS3, executado de uma estação administrativa com curl e jq:
curl --silent --show-error --fail \
--cacert /etc/pki/ca-trust/source/anchors/bigip-management-ca.pem \
--user automation \
https://bigip-mgmt.example.com/mgmt/shared/appsvcs/info |
jq .
Nesse exemplo interativo, curl solicita a senha. Em CI, use o mecanismo de segredos do executor e a autenticação suportada pelo ambiente. Não grave credenciais em argumentos fixos, arquivos versionados ou logs.
O certificado de gerenciamento deve ser validado. Usar -k de forma permanente elimina uma verificação importante da identidade do destino.
- Diferencie envio, processamento e conclusão
A resposta ao POST não deve ser o único critério de sucesso.
No AS3, uma submissão assíncrona pode utilizar:
POST /mgmt/shared/appsvcs/declare?async=true
O identificador retornado permite acompanhar o processamento:
GET /mgmt/shared/appsvcs/task/<id>
O pipeline precisa interpretar o estado da tarefa e o resultado de cada tenant envolvido. Uma consulta HTTP bem-sucedida não significa necessariamente que a configuração foi aplicada com sucesso.
No DO, utilize os endpoints e campos definidos na documentação da versão instalada. Não reutilize o parser de resposta do AS3: as estruturas e a semântica de status não são intercambiáveis.
Defina timeout total e intervalo de consulta. Se o runner perder a conexão após o POST, investigue a tarefa e o estado do destino antes de reenviar. Uma falha de transporte não comprova que a alteração foi rejeitada.
- Controle escopo e concorrência
Estabeleça um responsável pela configuração de cada escopo gerenciado.
No AS3, tenant é um agrupamento lógico da declaração; não significa necessariamente um tenant virtualizado no F5OS.
Evite dois pipelines alterando simultaneamente o mesmo tenant AS3. Revise a declaração renderizada antes do envio, incluindo objetos removidos e referências a recursos existentes.
Alterações manuais em objetos gerenciados pela automação precisam de um processo de reconciliação. Caso contrário, o próximo deploy pode reaplicar uma configuração diferente daquela que o operador espera.
Em HA, documente o destino da submissão e o comportamento esperado de ConfigSync. Não envie a mesma mudança aos dois membros por padrão sem validar o procedimento aplicável.
- Valide o serviço depois da tarefa
A conclusão da tarefa demonstra o resultado da operação de configuração. A validação funcional deve verificar o serviço publicado.
Para uma aplicação HTTPS, teste pelo menos:
- Endereço e porta do virtual server.
- Estado dos membros do pool.
- Certificado, cadeia de confiança e SNI.
- Resposta HTTP e conteúdo esperado.
- Persistência ou autenticação, quando utilizadas.
- Contadores de erro e logs relacionados à mudança.
Registre o commit, o identificador da tarefa, os horários e os resultados dos testes. Proteja as evidências que contenham informações sensíveis.
- Defina a recuperação antes do deploy
Mantenha a declaração anterior aprovada e os artefatos necessários para executá-la. Sua reaplicação deve ser testada como uma nova alteração, com suas próprias verificações.
Ela não recupera automaticamente sessões, dados da aplicação ou todos os efeitos de uma atualização de extensão.
Para DO, a recuperação precisa considerar alterações de rede e gerenciamento que possam interromper o acesso remoto. Preveja console e backup adequado ao escopo.
Atualização de RPM e alteração de declaração também exigem planos de recuperação distintos. Não assuma que desinstalar uma extensão ou instalar uma versão anterior restaura o estado dos serviços.
O fluxo que eu adotaria seria:
Aquisição oficial → verificação → repositório interno → homologação → aprovação → implantação → acompanhamento da tarefa → teste funcional.
A pergunta para quem opera AS3 e DO é direta: vocês conseguem repetir um deploy com os mesmos artefatos, schemas e ferramentas utilizados na execução anterior?
Referências