L'uso di CasC con F5 consentirebbe la configurazione dell'endpoint di rete con versione e facoltativamente dinamica, risparmiando tempo e riducendo i rischi.
Questo strumento supporta questo? I file di configurazione singola (SCF, termine F5) sono il veicolo per farlo?
Risposte:
Sì, gli F5 supportano la configurazione come codice. Storicamente, F5 ha creato un'appliance per gestire la configurazione come codice chiamato "Enterprise Manager" che gestiva in modo pragmatico gli endpoint client F5 (LTM, ecc.) Usando l'API XML iControl.
Hanno scoperto piuttosto rapidamente che questa appliance di gestione era terribile e hanno aggiunto un'API REST più solida alle appliance client per la gestione dei dispositivi (LTM, ecc .; anche marcata come iControl) che è molto più facile da usare e più flessibile e quindi hanno iniziato a costruire un sostituto per l'Enterprise Manager marchiato BIG-IQ.
Il punto è che puoi gestire la stessa API usando questa interfaccia REST. Guarda il loro tutorial su DevCentral . Di solito, è possibile trovare la sintassi REST esatta e le chiamate sul sito DevCentral in base alla versione come questa per TMOS 12.1.0 .
In generale, NON è consigliabile utilizzare un SCF (Single Configuration File) praticamente mai per un paio di motivi. In primo luogo, manca qualsiasi file di supporto, come certificati e chiavi per i profili SSL o script (i cosiddetti monitor di integrità "esterni"), ecc. In secondo luogo, viene riprodotto male se si utilizza il partizionamento, poiché le partizioni sono distribuite su più file in una struttura piegata. Questi non si consolidano bene in un file SCF. In realtà sarebbe meglio scrivere script TMOS. Uno dei motivi per cui F5 è passato dal comando bigpipe alla shell TMOS è che potrebbe essere copiato da script dove il bigpipe non poteva essere facilmente copiato. Ma ancora una volta, l'API REST è preferita. Gli SCF sono davvero un'eredità della versione 9 di TMOS e non sono invecchiati bene e funzionano male nella versione 12. Un motivo significativo di ciò è dovuto alle modifiche del peering HA tra V10 e V11 quando sono cambiate in un'architettura cluster. Ha davvero devastato l'usabilità degli SCF.
Puppet ha in realtà un modulo per la gestione di F5 se si utilizza questo strumento di gestione della configurazione e salt ha un corridore per esso - entrambi utilizzano l'API REST se si utilizza uno di questi strumenti di gestione della configurazione.
James, hai ragione nel dire che BIG-IQ ha sostituito Enterprise Manager. Tuttavia, come Enterprise Manager, BIG-IQ è per la gestione di "dispositivi / funzionalità". Per l'integrazione diretta tramite API REST o con strumenti / catene di strumenti di automazione di terze parti, dovresti guardare F5 iWorkflow (gateway API programmabile / estensibile).
Il team dietro iWorkflow si concentra su "modelli di servizi" e "cataloghi di servizi". Questi sono ottimi modi per creare rapidamente "interfacce dichiarative" che puoi colpire con singole chiamate REST, anziché chiamare centinaia di "interfacce imperative" (singoli punti finali REST) per eseguire la stessa attività.
Passare a un modello dichiarativo ti risparmierà MOLTI mal di testa in futuro e supporterà meglio l'automazione e l'integrazione con le tubazioni CI / CD. L'ULTIMA cosa che vuoi è spostare tutte le sfumature della tua infrastruttura nella stessa linea di automazione !! L'astrazione attraverso l'interfaccia dichiarativa ti proteggerà da quella fossa della disperazione.
Con le interfacce dichiarative REST +, hai un'infrastruttura molto più semplice come modello di codice in quanto stai mantenendo solo BLOB JSON per i modelli di servizio e non file di configurazione monolitici. Doppietta!
Dai un'occhiata alla chiamata di iApp (modelli di servizi F5) dall'API REST. Ecco un corso di formazione online gratuito:
http://f5-automation-labs.readthedocs.io/en/latest/
Chase = Corretto! RESTO fino in fondo!