O uso do CasC com F5 permitiria uma configuração de terminal de rede com versão e opcionalmente dinâmica, economizando tempo e reduzindo riscos.
Esta ferramenta suporta isso? Os arquivos de configuração única (termo SCF, F5) são o veículo para fazer isso?
Respostas:
Sim, os F5 oferecem suporte à configuração como código. Historicamente, o F5 criou um dispositivo para gerenciar a Configuração como código chamado "Enterprise Manager", que gerenciava pragmaticamente o ponto de extremidade do cliente F5s (LTMs, etc.) usando a API XML do iControl.
Eles descobriram rapidamente que esse dispositivo de gerenciamento era terrível e adicionaram uma API REST mais robusta aos dispositivos clientes para gerenciar dispositivos (LTMs, etc .; também com a marca iControl), que é muito mais fácil de usar e mais flexível, e então começou a construir um substituto para o Enterprise Manager da marca BIG-IQ.
O ponto é que você pode gerenciar a mesma API usando essa interface REST. Veja o tutorial no DevCentral . Geralmente, é possível encontrar a sintaxe REST exata e as chamadas no site do DevCentral em uma base por versão como esta para o TMOS 12.1.0 .
De um modo geral, NÃO é recomendável usar um SCF (arquivo de configuração único) praticamente por alguns motivos. Primeiro, ele não possui arquivos de suporte, como certificados e chaves para seus perfis SSL ou scripts (chamados de monitores de integridade "externos"), etc. uma estrutura em pasta. Eles não se consolidam bem em um arquivo SCF. Na verdade, seria melhor escrever scripts TMOS. Uma das razões pelas quais o F5 mudou do comando bigpipe para o shell do TMOS é que ele poderia ser script, onde o bigpipe não poderia ser facilmente script. Mas, novamente, a API REST é preferida. Os SCFs são realmente um legado da versão 9 do TMOS e não envelheceram bem e funcionam mal na versão 12. Uma razão significativa para isso é devido às alterações no emparelhamento de HA entre V10 e V11 quando elas mudaram para uma arquitetura em cluster. Realmente causou estragos na usabilidade dos SCFs.
O Puppet, na verdade, possui um módulo para gerenciar F5s se você usar essa ferramenta de gerenciamento de configuração e o salt tiver um corredor para ele - ambos usando a API REST se você usar uma dessas ferramentas de gerenciamento de configuração.
James, você está certo em que o BIG-IQ substituiu o Enterprise Manager. No entanto, como o Enterprise Manager, o BIG-IQ é para gerenciamento de 'dispositivo / recurso'. Para integrar diretamente via APIs REST ou a ferramentas / cadeias de ferramentas de automação de terceiros, consulte o F5 iWorkflow (gateway de API extensível e programável).
A equipe por trás do iWorkflow está focada em 'modelos de serviços' e 'catálogos de serviços'. Essas são ótimas maneiras de criar rapidamente 'interfaces declarativas' que você pode acessar com chamadas REST únicas, em vez de chamar centenas de 'interfaces imperativas' (pontos finais REST individuais) para executar a mesma tarefa.
A mudança para um modelo declarativo o salvará de MUITAS dores de cabeça no futuro e oferecerá melhor suporte à automação e integração com linhas de tubulação de CI / CD. A ÚLTIMA coisa que você deseja é mover todas as nuances de sua infraestrutura para o próprio canal de automação !! A abstração através da interface declarativa o protegerá daquele poço de desespero.
Com interfaces declarativas REST +, você tem um modelo de Infraestrutura como Código muito mais simples, na medida em que mantém apenas blobs JSON para os modelos de serviço, e não arquivos de configuração monolíticos. GANHE DUAS VEZES!
Dê uma olhada em chamar iApps (modelos de serviços F5) a partir da API REST. Aqui está um curso de treinamento on-line gratuito:
http://f5-automation-labs.readthedocs.io/en/latest/
Chase = Correto! DESCANSE todo o caminho!