Oui, les F5 prennent en charge la configuration en tant que code. Historiquement, F5 a créé une appliance pour gérer la configuration en tant que code appelé «Enterprise Manager» qui gérait de manière pragmatique les points finaux client F5 (LTM, etc.) à l'aide de l'API XML iControl.
Ils ont découvert assez rapidement que cet appareil de gestion était terrible et ont ajouté une API REST plus robuste aux appareils clients pour la gestion des appareils (LTM, etc.; également appelée iControl) qui est beaucoup plus facile à utiliser et plus flexible, puis ont commencé à construire un remplacement pour l'Enterprise Manager de marque BIG-IQ.
Le fait est que vous pouvez gérer cette même API à l'aide de cette interface REST. Voir leur tutoriel sur DevCentral . Habituellement, vous pouvez trouver la syntaxe REST exacte et les appels sur le site DevCentral par version comme celui-ci pour TMOS 12.1.0 .
D'une manière générale, il n'est PAS recommandé d'utiliser un SCF (fichier de configuration unique) à peu près jamais pour deux raisons. Premièrement, il ne contient pas de fichiers de support, tels que des certificats et des clés pour vos profils SSL ou scriptés (soi-disant moniteurs d'intégrité "externes"), etc. Deuxièmement, il joue mal si vous utilisez le partitionnement, car les partitions sont réparties sur plusieurs fichiers dans une structure en dossier. Ceux-ci ne se consolident pas bien dans un fichier SCF. Il serait préférable d’écrire des scripts TMOS. L'une des raisons pour lesquelles F5 est passé de la commande bigpipe au shell TMOS est qu'il pourrait être scripté là où bigpipe ne pourrait pas être facilement scripté. Mais encore une fois, l'API REST est préférée. Les SCF sont vraiment un héritage de la version 9 de TMOS et n'ont pas bien vieilli et fonctionnent mal dans la version 12. Une raison importante à cela est due aux changements dans le peering HA entre V10 et V11 lorsqu'ils sont passés à une architecture en cluster. Cela a vraiment fait des ravages sur l'utilisabilité des SCF.
Puppet a en fait un module pour gérer les F5 si vous utilisez cet outil de gestion de configuration et salt a un runner pour lui - les deux utilisant l'API REST si vous utilisez l'un de ces outils de gestion de configuration.
James, vous avez raison, BIG-IQ a remplacé Enterprise Manager. Cependant, comme Enterprise Manager, BIG-IQ est destiné à la gestion des «périphériques / fonctionnalités». Pour une intégration via les API REST directement, ou vers des outils / chaînes d'outils d'automatisation tiers, vous devriez regarder F5 iWorkflow (passerelle API programmable / extensible).
L'équipe derrière iWorkflow se concentre sur les «modèles de services» et les «catalogues de services». Ce sont d'excellents moyens de créer rapidement des `` interfaces déclaratives '' que vous pouvez frapper avec des appels REST uniques, par opposition à appeler des centaines `` d'interfaces impératives '' (points de terminaison REST individuels) pour effectuer la même tâche.
Le passage à un modèle déclaratif vous évitera de nombreux maux de tête à l'avenir et améliorera la prise en charge de l'automatisation et de l'intégration avec les pipelines CI / CD. La DERNIÈRE chose que vous voulez, c'est de déplacer toutes les nuances de votre infrastructure dans le pipeline d'automatisation lui-même !! L'abstraction via une interface déclarative vous protégera de ce gouffre de désespoir.
Avec les interfaces déclaratives REST +, vous disposez d'une infrastructure en tant que modèle de code beaucoup plus simple dans la mesure où vous ne maintenez que des blobs JSON pour les modèles de service, et non des fichiers de configuration monolithiques. Double-GAGNEZ!
Jetez un œil à l'appel d'iApps (modèles de services F5) à partir de l'API REST. Voici un cours de formation en ligne gratuit:
http://f5-automation-labs.readthedocs.io/en/latest/
Chase = correct! RESTEZ tout le chemin!
la source