Qual a diferença entre iControl REST e AS3?

O AS3 é um wrapper declarativo que roda sobre o iControl REST. Enquanto o iControl REST exige que você gerencie o 'como' (criação passo a passo), o AS3 permite que você defina o 'o quê' (o estado final desejado), e o F5 lida com a sequência e a limpeza.

Quais são os riscos de uma migração parcial para AS3?

O maior desafio é o gerenciamento de estado. Se alguém fizer uma alteração manual via GUI enquanto você estiver usando AS3, a próxima declaração AS3 sobrescreverá essas alterações manuais. Você deve estabelecer o Git como a única fonte da verdade e bloquear o acesso via GUI/CLI.

Posso usar REST/AS3 para configurações de nível de sistema como VLANs e NTP?

Embora você possa usar TMSH para configurar usuários locais, a abordagem moderna é usar a extensão Declarative Onboarding (DO). Isso permite gerenciar configurações de nível de sistema como VLANs, DNS, self-IPs e contas de usuário por meio de uma única declaração JSON.

Existe uma ferramenta para converter configurações TMSH existentes para AS3?

Sim, a extensão BIG-IP para Visual Studio Code é altamente recomendada. Ela inclui um 'AS3 Schema Validator' e um conversor 'TMSH para AS3' que pode ajudar a acelerar sua migração, convertendo configurações existentes em declarações JSON.

Para onde eu realmente envio o payload JSON do AS3?

O endpoint AS3 geralmente é hospedado na interface de gerenciamento em /mgmt/shared/appsvcs/declare. Para ambientes de alto volume, certifique-se de estar executando o BIG-IP versão 15.1 ou posterior para aproveitar as melhorias de desempenho no framework REST.

Como o AS3 lida com implantações multi-cloud?

Para data centers legados, BIG-IP iSeries ou rSeries locais são preferidos. Para ambientes de nuvem, as mesmas declarações AS3 funcionam identicamente em BIG-IP Virtual Editions na AWS, Azure e GCP, tornando-o a ferramenta perfeita para entrega de aplicações em nuvem híbrida.

F5 BIG-IP TMSH para REST/AS3: O Guia de Migração para 2026

A era do gerenciamento do F5 BIG-IP via scripts TMSH imperativos legados e automação frágil baseada em Expect está morta. Se você ainda está acessando via SSH seu chassi VIPRION ou iSeries para executar tmsh create ltm virtual, você não está apenas atrasado—você está acumulando dívida técnica que quebrará seu roteiro de automação para 2026. A indústria mudou definitivamente para o modelo declarativo do Application Services 3 (AS3), e a transição da API iControl REST imperativa para um fluxo de trabalho GitOps puro usando o F5 Automation Toolchain não é mais opcional para engenharia de rede em larga escala.

A Falha Estrutural do TMSH Imperativo

O TMSH (Traffic Management Shell) foi projetado para humanos, não para máquinas. Embora as interfaces iControl SOAP e as primeiras iControl REST fornecessem uma ponte, elas sofriam com o pesadelo da "ordem de operações". Em um script TMSH típico, se você tentar excluir um node antes de removê-lo de seu pool, ou excluir um pool enquanto ele ainda está anexado a um Virtual Server, a transação falha. Isso exige que os engenheiros escrevam uma lógica complexa de tratamento de erros para rastrear as dependências de objetos.

Além disso, o TMSH é notoriamente lento para operações em massa. Sessões SSH serializadas introduzem latência que chamadas RESTful via HTTPS não possuem. Mais importante, o TMSH não oferece validação nativa de estado. Você diz a ele o que fazer, ele tenta, e se falhar no meio, você fica com uma configuração "inacabada" que é um pesadelo para auditar. A mudança para REST e, eventualmente, AS3 permite configurações idempotentes—gerenciamento baseado em estado onde o resultado final é definido, em vez dos passos para alcançá-lo.

Fase 1: Mapeando TMSH para iControl REST

Antes de pular para o AS3, você deve entender como a API REST subjacente mapeia os comandos que você usou por uma década. A API F5 iControl REST segue uma estrutura URI previsível: /mgmt/tm/ltm/.... Por exemplo, um comando TMSH padrão para criar um node:

tmsh create ltm node 10.1.1.50 address 10.1.1.50 description "WebSrv01"

Traduz-se para uma requisição POST para /mgmt/tm/ltm/node com um payload JSON:

{
  "name": "10.1.1.50",
  "address": "10.1.1.50",
  "description": "WebSrv01"
}

Embora isso resolva a sobrecarga do SSH, ainda requer múltiplas chamadas para construir uma stack completa (Node -> Pool -> Virtual Server). É aqui que o playbook de 2026 exige uma mudança para o F5 Automation Toolchain, especificamente a App Services Extension.

Fase 2: Transição para o Modelo Declarativo (AS3)

AS3 (Application Services 3 Extension) é o padrão da indústria para automação F5. Em vez de chamar múltiplos endpoints para construir uma aplicação, você envia uma única declaração JSON para o endpoint /mgmt/shared/appsvcs/declare. O AS3 lida com a lógica de dependência, a ordem de operações e a limpeza de recursos não utilizados.

Considere a "Application" como a unidade atômica de entrega. No AS3, você não gerencia "Virtual Servers"; você gerencia "Tenants" e "Applications". Uma declaração AS3 típica para um VIP HTTPS padrão com uma política LTM e perfil WAF pode se parecer com isto:

{
    "class": "ADC",
    "schemaVersion": "3.0.0",
    "id": "TechLeague_Migration_01",
    "Tenant_Web": {
        "class": "Tenant",
        "App_Secure": {
            "class": "Application",
            "template": "https",
            "serviceMain": {
                "class": "Service_HTTPS",
                "virtualAddresses": ["192.168.10.100"],
                "pool": "web_pool",
                "serverTLS": "tls_common"
            },
            "web_pool": {
                "class": "Pool",
                "monitors": ["http"],
                "members": [{
                    "servicePort": 80,
                    "serverAddresses": ["10.10.1.10", "10.10.1.11"]
                }]
            }
        }
    }
}

Esta declaração é enviada de uma só vez. Se o pool já existe, o AS3 o atualiza. Se um membro precisa ser removido, o AS3 o remove. É por isso que o AS3 é superior ao REST puro: ele é verdadeiramente idempotente.

Fase 3: Construindo o Pipeline de CI/CD (GitOps)

O gerenciamento moderno do F5 deve se assemelhar ao desenvolvimento de software. Sua "Fonte da Verdade" não é mais o arquivo /config/bigip.conf no dispositivo; é um arquivo YAML ou JSON em um repositório Git. Recomendamos um fluxo de trabalho GitLab ou GitHub Actions que dispara a cada pull request.

1. **Linting:** Use o validador de schema AS3 para garantir que o JSON esteja sintaticamente correto.
2. **Staging:** Envie a declaração para um BIG-IP VE (Virtual Edition) rodando em um laboratório de desenvolvimento.
3. **Validação:** Execute testes automatizados curl ou Postman contra o VIP de staging.
4. **Produção:** Após aprovação, o executor de CI emite a requisição POST para os clusters F5 de produção.

Ao usar os padrões do F5 BIG-IP Next precocemente, você prepara sua organização para a próxima geração de hardware F5 (rSeries) e software, que é construída inteiramente sobre essas bases REST/AS3. O hardware da antiga rSeries (r5000/r10000) se beneficia especificamente disso, pois separa a camada F5OS da camada de tenant, tornando a automação obrigatória para escala.

Telemetria e Visibilidade: Indo Além do SNMP

A migração do TMSH não é apenas sobre configuração; é sobre observability. Se você ainda está usando polling SNMP para monitorar seus F5s, você está perdendo dados granulares. A extensão Telemetry Streaming (TS)—parte do Automation Toolchain—permite enviar métricas em tempo real para Splunk, ELK ou Datadog usando um modelo declarativo similar ao AS3.

Pare de escrever scripts Perl personalizados para analisar a saída de show ltm virtual. Em vez disso, configure um consumidor TS para transmitir a saúde dos membros do pool, a latência do SSL handshake e as métricas de throughput diretamente. Isso permite que seu SOC correlacione os logs do F5 com os logs do servidor de aplicação em um único painel.

Gerenciando Persistent e iRules Legados

Um ponto de atrito comum na migração TMSH → REST é o tratamento de iRules complexos. No TMSH, você pode ter centenas de linhas de código Tcl. No AS3, tratamos iRules como objetos "BigIP" que podem ser referenciados ou definidos inline. No entanto, sugerimos mover a lógica dos iRules para as LTM Policies sempre que possível. As Policies são suportadas nativamente no schema AS3 e são significativamente mais performáticas que os iRules porque são compiladas eficientemente no bytecode do TMM (Traffic Management Microkernel).

Para iRules que devem permanecer, use o recurso de codificação base64 no AS3 para garantir que caracteres especiais e quebras de linha não quebrem seu payload JSON. Isso mantém seu repositório Git limpo e legível.

O Veredito de 2026: Desempenho e Custo

Operar um ecossistema BIG-IP via TMSH/SSH escala linearmente com a mão de obra. Você precisa de mais engenheiros para gerenciar mais VIPs. Operar via AS3 e GitOps escala logarithmicamente. Um único engenheiro pode gerenciar mais de 500 Virtual Servers em 20 clusters globais com o mesmo esforço que gerenciar cinco. Para hardware como o iSeries 5800 ou o mais recente rSeries r10900, que pode custar mais de US$ 100 mil a US$ 200 mil, não automatizar significa que você está desperdiçando a capacidade de throughput bruto e multi-tenancy do seu investimento.

Implementamos esses padrões para empresas financeiras da Fortune 500, reduzindo o "Time-to-VIP" delas de 5 dias (ticket manual) para 4 minutos (PR automatizado). Se você busca comparar sua maturidade atual em automação F5 ou precisa de um design de schema AS3 personalizado, explore nossos serviços profissionais em techleague.io.