O Declarative Onboarding é o irmão do AS3, e a divisão entre eles é o jeito mais limpo de manter os dois na cabeça: o AS3 configura os serviços de aplicação de Camada 4-7 em um BIG-IP que já está na rede, e o DO faz o onboarding de Camada 1-3 que o coloca lá. Licenciamento, provisionamento de módulos, DNS e NTP, VLANs e self IPs e rotas, contas de usuário, e o cluster que junta caixas em um par de alta disponibilidade são todos trabalho do DO. Esta ferramenta renderiza cada declaração de volta para você do jeito que a documentação descreve.
Cole o JSON que você faz POST em /mgmt/shared/declarative-onboarding e ela primeiro diz que tipo de documento é: uma declaração Device pura, que é o que você envia direto a um BIG-IP, ou um wrapper de requisição class DO carregando um targetHost, que é o que você envia a um BIG-IQ para provisionar um dispositivo remotamente. Ela lê as opções de topo, o schemaVersion, async, webhook e label, e então percorre o único tenant que uma declaração DO pode ter, que o schema exige que se chame Common.
A caminhada é agrupada pela fase em que o DO efetivamente provisiona, porque a ordem é a intuição que vale carregar: licenciamento e provisionamento habilitam os módulos dos quais todo o resto depende, a identidade do sistema como hostname e DNS e NTP e usuários é a base, a rede constrói o plano de dados de VLANs e self IPs e rotas, e o cluster junta a caixa provisionada aos seus pares. Cada classe é nomeada e explicada a partir da referência de schema da F5, e uma classe que esta ferramenta não reconhece ainda é reportada em vez de descartada.
Três pegadinhas documentadas são aplicadas mecanicamente em vez de deixadas em uma nota de rodapé. O hostname pode ser definido em Common ou dentro de uma classe System, mas não em ambos, e declará-lo duas vezes é sinalizado. Um SelfIp que omite allowService é sinalizado com a nota de versão que importa: o DO 1.36 mudou esse padrão de default para none, então um self IP que antes herdava gerenciamento-mais-serviços-padrão agora não permite nada até você dizer o contrário. E um usuário root sem seu oldPassword é sinalizado, porque o DO não consegue trocar a senha do root sem a existente. A ferramenta também mostra o comportamento do async: async: true retorna um 202 com um id de tarefa imediatamente, e você consulta essa tarefa com GET até concluir.
Isto é um explicador de estrutura e verificador de sanidade, não um validador completo de JSON-Schema; a F5 publica o schema do DO para validação no VS Code, e uma declaração que passa aqui ainda pode ser rejeitada pelo próprio DO. Tudo roda localmente, nada do que você cola sai da página, e nada aqui jamais contata um BIG-IP ou um BIG-IQ.