Automatiser les services applicatifs F5 : guide pratique
Introduction
L’automatisation du déploiement et de la gestion de la configuration des équipements de mise à disposition et de sécurité des applications est devenue une pratique quasiment incontournable. Dans le rapport 2017 d’IDG « FutureScape », l’automatisation et la gestion multicloud figuraient parmi les principales initiatives susceptibles d’avoir un impact sur les entreprises d’ici 2021.1 L’automatisation apporte évolutivité, fiabilité et intégration au déploiement des services essentiels de sécurité, d’optimisation et de disponibilité dont les applications ont besoin, et intègre leur mise à disposition aux workflows orchestrés de compilation, de test et de déploiement qui s’imposent comme le modèle dominant de déploiement des applications.
Même une automatisation simple de tâches élémentaires, telles que l’ajout de nouveaux serveurs virtuels ou de membres à un pool, peut permettre aux équipes d’exploitation de proposer des fonctionnalités en libre-service aux responsables d’applications ou à d’autres systèmes automatisés, tout en libérant du temps pour des activités plus productives, comme le développement de la prochaine génération d’outils d’automatisation.
La nécessité d’automatiser prend encore plus d’importance lorsqu’une organisation commence à adopter plusieurs plateformes cloud pour fournir des services informatiques. Lorsque vous cherchez à déployer des services sur plusieurs sites présentant des caractéristiques de plateforme différentes, l’automatisation peut contribuer à limiter l’impact de l’augmentation de la charge opérationnelle et à réduire les erreurs dues à une méconnaissance des nouvelles plateformes.
Mais comment automatiser, et quoi ? Compte tenu de la diversité des modèles opérationnels, des interfaces et des langages, les logiciels d’automatisation peuvent intervenir au niveau d’un seul appareil ou prendre la forme d’outils plus complexes couvrant plusieurs systèmes. Les plateformes cloud d’infrastructure en tant que service (IaaS) proposent leurs propres outils natifs pour déployer des infrastructures et des services virtuels. F5 offre également un éventail d’interfaces et d’options d’orchestration. Si cette diversité d’outils et d’options vous permet d’adopter l’automatisation la mieux adaptée à votre organisation, choisir le bon outil peut s’avérer difficile, et les risques liés à la complexité et à la prolifération des outils sont bien réels.
Dans ce document, nous présenterons les différentes façons d’automatiser le déploiement, la gestion et la configuration des appliances F5 BIG-IP (physiques et virtuelles), ainsi que quelques conseils pour choisir l’approche la mieux adaptée à votre entreprise.
Le cycle de vie de l’automatisation
Le cycle de vie de la fourniture de services applicatifs comporte plusieurs points clés d’automatisation. Selon votre modèle d’infrastructure et vos méthodes de déploiement des applications, vous devrez peut-être tous les mettre en œuvre, ou seulement certains d’entre eux.
Si vous déployez des services sur un BIG-IP physique ou virtuel à haute capacité et mutualisé, les activités d’amorçage et d’intégration ne seront pas prioritaires par rapport au déploiement, à la surveillance et à la mise à jour des configurations des services applicatifs pour les centaines ou milliers d’applications qu’il prend en charge.
Si vous envisagez un modèle de déploiement dans lequel chaque application dispose d’instances BIG-IP dédiées dans plusieurs environnements — y compris, éventuellement, des instances éphémères créées à la demande pour les tests et l’assurance qualité —, l’automatisation des processus d’amorçage et d’intégration est alors tout aussi essentielle que le déploiement des services applicatifs eux-mêmes.
Quel que soit votre environnement et quel que soit le nombre de processus à automatiser, vous devez prendre en compte certains sujets clés.
Automatisation : quelques points clés à prendre en compte
Le spectre de maturité de l’automatisation
L’automatisation couvre un large éventail d’activités. À une extrémité du spectre se trouve le développement de scripts simples écrits en Bash, TMSH, Python ou dans d’autres langages, qui peuvent être exécutés localement afin d’accélérer les opérations de configuration manuelle. À l’autre extrémité se trouve un système complet d’« infrastructure en tant que code », qui associe la gestion du code source, des orchestrateurs de workflows et, éventuellement, plusieurs outils d’automatisation afin de créer un système dans lequel la configuration de l’infrastructure est définie et modifiée au moyen de fichiers texte stockés dans un dépôt. Entre ces deux extrêmes, différentes options permettent de faciliter la gestion du déploiement et de la configuration d’une plateforme BIG-IP.
Mutable ou immuable
La plupart des déploiements BIG-IP actuels peuvent être considérés comme modifiables, ce qui signifie que leur configuration est susceptible d’évoluer au fil du temps. En effet, la plateforme BIG-IP est principalement déployée en tant qu’équipement mutualisé fournissant des services à plusieurs applications. À mesure que de nouvelles applications sont déployées, ou que les applications existantes montent en charge ou nécessitent des services supplémentaires, la configuration de BIG-IP est mise à jour en conséquence. Ce mode de déploiement permet aux équipes d’infrastructure de gérer un ensemble d’infrastructures centralisées qui fournissent des services aux applications à partir d’une plateforme commune.
Cependant, les plateformes BIG-IP sont parfois déployées au sein d’une pile applicative distincte, dans laquelle les services d’une plateforme BIG-IP donnée sont liés à une application ou à un service spécifique. Dans ce cas, nous pourrions considérer la configuration de BIG-IP comme immuable ; autrement dit, la configuration est installée au démarrage ou intégrée à l’image logicielle, et n’est pas modifiée pendant le cycle de vie de l’instance BIG-IP. Les changements de configuration sont effectués en modifiant l’image logicielle ou le contenu du script de l’agent de démarrage, puis en procédant à un nouveau déploiement. Ce modèle est souvent appelé « nuke and pave ». Bien qu’il soit globalement moins répandu, l’apparition de nouveaux modèles de licence BIG-IP prenant en charge les instances par application, d’outils de gestion des licences améliorés et d’outils tels que F5 cloud libs (https://github.com/F5Networks/f5-cloud-libs) (un ensemble de scripts et de bibliothèques Node.js conçus pour faciliter l’intégration d’une plateforme BIG-IP dans un cloud) fait de ce modèle de déploiement une option viable pour les organisations qui ont besoin qu’une application dispose d’une pile isolée et étroitement intégrée, comprenant à la fois le code et l’infrastructure.
Impératif ou déclaratif
Il existe deux modèles conceptuels définissant la manière dont les interfaces d’automatisation sont mises à la disposition des utilisateurs. Les schémas d’automatisation les plus courants de la « première vague » tendent vers un modèle impératif. Dans les modèles d’automatisation impératifs, l’utilisateur doit généralement savoir à la fois ce qu’il souhaite accomplir et quelles étapes précises (habituellement des appels d’API) permettent d’y parvenir. Il lui incombe donc souvent de comprendre les détails de configuration des services avancés, mais aussi de gérer la complexité et les efforts supplémentaires nécessaires à l’intégration de ces services aux outils d’automatisation. Cela revient à commander un sandwich en précisant chacune des opérations nécessaires à sa préparation, plutôt que de simplement demander un sandwich en partant du principe que la personne qui le prépare connaît les opérations requises et l’ordre dans lequel les effectuer.
À l’inverse, une interface déclarative permet aux utilisateurs (humains ou machines) de créer des services en indiquant simplement ce qu’ils souhaitent obtenir. Il n’est pas nécessaire de connaître en détail toutes les étapes requises, car la cible de l’automatisation dispose de workflows préconfigurés ou de modèles de services permettant de générer la configuration en fonction des résultats attendus. Bien qu’une interface déclarative nécessite une configuration initiale légèrement plus complexe, cette complexité est compensée par la simplicité d’utilisation une fois les modèles de services appropriés créés. Il s’agit donc, en règle générale, du mécanisme privilégié pour concevoir des systèmes d’automatisation.
Directement ou via un outil de gestion
Vous devrez également déterminer si les appels d’API d’automatisation doivent être effectués depuis des outils tiers directement vers l’appareil à modifier ou par l’intermédiaire d’un outil de gestion supplémentaire. Les outils de gestion peuvent faire abstraction de certaines opérations et les simplifier, tout en offrant éventuellement des niveaux supplémentaires de contrôle et de journalisation par rapport à une connexion directe à l’entité gérée. Vous devrez toutefois veiller à ce que vos couches de gestion soient hautement disponibles dans les situations où il est essentiel de pouvoir apporter rapidement des modifications.
API, agent de démarrage ou interface en ligne de commande ?
Les appareils BIG-IP sont le plus souvent automatisés via l’API REST, qui expose la majorité des fonctionnalités de BIG-IP au moyen d’un schéma documenté. Les modules fournis par F5 pour les outils d’automatisation tels qu’Ansible utilisent largement l’API REST. L’ajout de la fonctionnalité iControl LX permet également de créer un point de terminaison d’API défini par l’utilisateur, capable d’effectuer une opération en plusieurs étapes à partir d’un seul appel d’API.
Une autre méthode courante pour automatiser la configuration de BIG-IP consiste à utiliser des agents de démarrage, qui s’exécutent au démarrage et peuvent récupérer des informations externes afin de configurer la plateforme BIG-IP. Les agents de démarrage sont souvent utilisés pour effectuer la configuration initiale afin d’« intégrer » les appareils. Ils peuvent également récupérer des scripts et des fichiers de configuration supplémentaires depuis des sites tiers tels que GitHub ou votre propre dépôt. Les agents de démarrage peuvent aussi servir à configurer entièrement une plateforme BIG-IP, en particulier si vous avez opté pour une configuration fixe propre à chaque application.
La configuration de démarrage la plus courante est cloud-init, qui est activé dans toutes les images BIG-IP VE (sauf dans Microsoft Azure), mais qui convient surtout aux déploiements AWS et OpenStack. En complément de cloud-init, F5 fournit un ensemble de bibliothèques de démarrage dans le cloud pour faciliter la configuration de BIG-IP au démarrage.
Si vous choisissez d’utiliser des agents de démarrage pour configurer une plateforme après son démarrage, accordez une attention particulière à la gestion des défaillances. Cela est particulièrement important si des sources externes sont utilisées, notamment lorsqu’une instance est susceptible d’être lancée dans le cadre d’un événement de mise à l’échelle. Si les ressources externes sont indisponibles, comment le système se comportera-t-il ? Des dispositifs « zombies » supplémentaires seront-ils créés pour tenter de répondre à la demande ?
Dans certains cas, les systèmes d’automatisation peuvent agir comme des utilisateurs et exécuter des commandes CLI. Bien que cela puisse parfois résoudre certains problèmes lorsque les appels d’API ne sont pas suffisamment complets, la difficulté à assurer le support et la fragilité de la solution en font généralement une méthode de dernier recours.
Modèles et playbooks
Les modèles et les playbooks permettent d’automatiser les déploiements et de créer des infrastructures présentant un certain degré de standardisation. Un niveau de standardisation approprié rend votre infrastructure plus robuste et plus facile à prendre en charge. Des modèles bien conçus offrent une interface déclarative dans laquelle l’entité à l’origine de la demande (utilisateur ou machine) doit uniquement connaître les propriétés dont elle a besoin, et non les détails de l’implémentation. Effectuer les déploiements exclusivement à l’aide de modèles et résoudre les problèmes uniquement en corrigeant ces modèles peut améliorer la qualité du service, car les problèmes ne doivent généralement être corrigés qu’une seule fois. Les services sont redéployés à partir du nouveau modèle, et les mises à jour apportées à celui-ci empêchent le même problème de se reproduire.
Intégrations de plateforme
Les outils d’intégration aux plateformes permettent d’intégrer la configuration des services BIG-IP à des plateformes telles que les clouds privés ou les systèmes de gestion de conteneurs. Les mécanismes varient selon les plateformes et les implémentations, mais relèvent généralement de trois modèles :
- Substitution des services F5 dans un composant existant de la plateforme
Dans ce modèle, les services F5 sont intégrés à l’aide d’un composant existant de la plateforme, par exemple en utilisant F5 comme routeur OpenShift Container Platform ou en utilisant F5 avec le système OpenStack Load Balancing as a Service (LBaaS). Ces mécanismes nécessitent peu de modifications des procédures opérationnelles, car une interface native de la plateforme est utilisée pour configurer les services, tandis que le pilote fourni et les autres logiciels traduisent de manière transparente les directives de configuration de la plateforme en une configuration F5. Gardez toutefois à l’esprit que seules les fonctionnalités disponibles via l’interface native de la plateforme peuvent être facilement déployées. - Abonnement aux événements de la plateforme
Une autre méthode d’intégration courante consiste à faire en sorte qu’un module logiciel (tel que le Connecteur de conteneurs pour Kubernetes et Mesos) s’abonne aux événements d’une plateforme, puis modifie une configuration en fonction de ces événements. Vous pouvez sélectionner les événements et les services à déployer en ajoutant des balises ou des étiquettes aux applications qui doivent être prises en charge, puis en configurant le logiciel du connecteur pour qu’il surveille les événements comportant les balises requises. - Intégration avec les outils de gestion de plateforme
De nombreuses plateformes de cloud privé disposent de systèmes de gestion conçus pour l’automatisation. VMware, par exemple, propose plusieurs outils de gestion et d’intégration, notamment vRealize Orchestrator (vRO), pour lequel il existe un plug-in tiers permettant de configurer BIG-IP. On peut également citer le plug-in pour le système de création de modèles OpenStack HEAT.
Découverte de services
Bien qu’elle ne constitue pas une solution d’automatisation complète, la découverte de services offre un moyen simple et puissant d’adapter les configurations BIG-IP aux changements de l’environnement. Elle interroge régulièrement le système cloud via une API afin de récupérer une liste de ressources, puis modifie la configuration BIG-IP en conséquence. Cette fonctionnalité est particulièrement utile dans les environnements où les ressources sont configurées dans des groupes de mise à l’échelle automatique, car le répartiteur de charge doit être informé des nouvelles ressources lors de la mise à l’échelle des ressources de calcul back-end. Des composants de découverte de services sont fournis avec les solutions F5 de mise à l’échelle automatique dans le cloud pour AWS et Azure.
Alors, existe-t-il un modèle d’automatisation recommandé par F5 ? Oui et non. Il y a tellement de variables à prendre en compte que des recommandations entièrement prescriptives seraient peu utiles. Nous avons toutefois regroupé les principaux éléments constitutifs dont vous aurez, selon nous, besoin au sein d’une gamme de produits coordonnée.
La chaîne d’outils d’automatisation F5
La gamme de produits F5 Automation Toolchain comprend les composants fondamentaux d’automatisation et d’orchestration qui vous permettent d’intégrer les plateformes F5 BIG-IP aux modèles d’automatisation courants, tels que les chaînes d’outils CI/CD.
La chaîne d’outils d’automatisation F5 comprend les composants clés suivants
- Application Services 3 Extension (AS3) – Services applicatifs BIG-IP L4-L7 déclaratifs
- Extension Declarative Onboarding (DO) – Intégration déclarative L1-L3 de BIG-IP
- Extension Telemetry Streaming (TS) – Diffusion automatisée des données de télémétrie BIG-IP vers les systèmes d’analyse
- API Services Gateway (ASG) – Environnement d’exécution de conteneurs pour les extensions iControl LX personnalisées
La gamme Automation Toolchain est conçue pour gérer le cycle de vie de la fourniture des services applicatifs, depuis le déploiement de la plateforme (via des modèles cloud) jusqu’à l’intégration, la configuration des services, ainsi que la télémétrie et la journalisation avancées afin de garantir les performances des applications en production.
Cette gamme croissante d’outils pris en charge représente l’avenir de l’automatisation des services applicatifs F5. Cela ne signifie toutefois pas qu’il n’existe pas d’autres intégrations ou qu’elles ne sont pas prises en charge. Consultez la section « Autres outils d’automatisation » de ce document.
Extension Application Services 3
L’extension F5 Application Services 3 (AS3) offre un moyen simple et cohérent d’automatiser le déploiement des services applicatifs de couches 4 à 7 sur la plateforme BIG-IP au moyen d’une API REST déclarative. AS3 utilise un modèle objet clairement défini, représenté sous la forme d’un document JSON. L’interface déclarative permet de gérer les déploiements de services applicatifs F5 de manière simple et fiable.
Schéma : l’architecture AS3
L’extension AS3 reçoit et analyse les déclarations, puis effectue les appels appropriés à l’API iControl afin de créer l’état final souhaité sur le système BIG-IP cible. L’extension peut s’exécuter soit sur l’instance BIG-IP, soit via AS3 Container, un conteneur ou une machine virtuelle distincte qui exécute l’extension AS3, puis effectue des appels d’API externes vers le système BIG-IP.
Les appels AS3 peuvent également être effectués via BIG-IQ, qui fournit des fonctionnalités de gestion des licences, d’administration, de visualisation et de contrôle d’accès pour les plateformes BIG-IP, et qui alimente F5 Cloud Edition, une solution proposant à la demande des instances de BIG-IP par application, associées à de puissantes fonctionnalités d’analyse.
Extension d’intégration déclarative
L’extension Declarative Onboarding fournit une interface simple permettant de faire passer une plateforme F5 BIG-IP de son état juste après le démarrage initial à un état prêt pour le déploiement de la sécurité et de la gestion du trafic des applications. Cela comprend les paramètres système tels que l’octroi de licences et le provisionnement, les paramètres réseau tels que les VLAN et les adresses Self IP, ainsi que les paramètres de mise en cluster si vous utilisez plusieurs systèmes BIG-IP.
Une fois le processus de configuration initiale terminé, les services applicatifs peuvent être déployés à l’aide du processus automatisé (ou manuel) de votre choix.
Declarative Onboarding utilise un schéma JSON cohérent avec le schéma AS3 et repose sur une architecture similaire. Declarative Onboarding est fourni sous la forme d’un paquet RPM indépendant de TMOS, qui est installé sur un BIG-IP nouvellement démarré lors de la première étape de la phase d’intégration.
Extension de streaming de télémétrie
BIG-IP est un puissant générateur de données de télémétrie sur les applications, la sécurité et le réseau. Telemetry Streaming fournit une interface déclarative permettant de configurer la diffusion en continu de statistiques et d’événements vers des services tiers tels que :
- Splunk
- Azure Log Analytics
- AWS CloudWatch
- AWS S3
- Graphite
Comme pour les autres membres de la famille Automation Toolchain, la configuration est gérée au moyen d’une interface déclarative reposant sur un schéma JSON simple et cohérent.
Passerelle de services API
La passerelle de services API est une image de conteneur Docker qui permet d’exécuter des extensions iControl LX personnalisées sur une plateforme indépendante de TMOS. Elle peut vous aider à faire évoluer et à gérer vos déploiements F5 en dissociant les opérations de gestion des différentes plateformes BIG-IP.
Modèles cloud – une partie de la solution, mais pas encore de la famille
Les modèles cloud utilisent les fonctions d’automatisation du déploiement des clouds publics et privés pour provisionner et démarrer des appliances virtuelles BIG-IP.
F5 propose actuellement des modèles pris en charge pour les clouds suivants :
- AWS – Modèles CloudFormation
- Azure – Modèles Azure Resource Manager
- Google – Modèles Google Deployment Manager
- VMware - Modèles vCenter
- OpenStack – Modèles d’orchestration Heat
F5 développe activement les modèles cloud afin de couvrir un plus large éventail de scénarios de déploiement. Veuillez soumettre vos signalements de problèmes ou vos demandes de fusion via le dépôt github correspondant.
Outils d’orchestration et de gestion des workflows, et livraison/déploiement continus
Les services applicatifs ne constituent qu’une couche de la pile technologique nécessaire au fonctionnement d’une application. L’intégration, la compilation et le déploiement de tous les composants, depuis la validation du code jusqu’à la mise en production et à la supervision, impliquent un grand nombre d’étapes interdépendantes qui doivent être exécutées dans le bon ordre. L’automatisation de cette tâche incombe aux outils d’orchestration, qui créent des pipelines de workflows composés de tâches et d’outils coordonnés.
La plupart des pipelines commencent par un dépôt de code source qui contient le code de l’application, les tests et la configuration de l’infrastructure.
Avec des outils tels qu’AS3, les modèles cloud et Declarative Onboarding, vous pouvez stocker toutes les informations de configuration nécessaires pour créer et configurer des services applicatifs dans le cadre d’un pipeline de déploiement.
Dans les architectures utilisant des plateformes matérielles ou logicielles BIG-IP mutualisées et persistantes, seule la configuration AS3 devra être gérée dans le dépôt de code de l’application. En revanche, si vous souhaitez lancer à la demande des instances dédiées dans le cadre du processus de déploiement, la gestion des modèles et des déclarations Declarative Onboarding devra faire partie du dépôt de votre application.
Autres outils d’automatisation : guide de ressources
Bien que nous ne puissions pas présenter tous les outils d’automatisation ou d’orchestration imaginables, vous trouverez ci-dessous une liste des outils, cas d’usage et fonctionnalités les plus couramment utilisés par les clients de F5.
---------------
Intégrations linguistiques
Langue
Statut
Exemples et source
Python
Contribution de F5
https://github.com/F5Networks/f5-common-python
Go
Contribution des utilisateurs
https://github.com/f5devcentral/go-bigip
PowerShell
Pris en charge par F5
https://devcentral.f5.com/wiki/icontrol.powershell.ashx
Outils de gestion de la configuration et d’automatisation de l’infrastructure
Outil
Statut
Exemples et source
Ansible
Contribution de F5
https://github.com/F5Networks/f5-ansible
Terraform
Contribution de F5
https://github.com/f5devcentral/terraform-provider-bigip
Puppet
Contribution de F5
https://github.com/f5devcentral/f5-puppet
Chef
Contribution des utilisateurs
https://github.com/target/f5-bigip-cookbook
SaltStack
Tiers
https://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.f5.html
Systèmes de modèles d’infrastructure
Plateforme
Statut
Exemples et source
AWS
Pris en charge par F5
https://github.com/F5Networks/f5-aws-cloudformation
Azure
Pris en charge par F5
https://github.com/F5Networks/f5-azure-arm-templates
Pris en charge par F5
https://github.com/F5Networks/f5-google-gdm-templates
OpenStack
Pris en charge par F5
https://github.com/F5Networks/f5-openstack-hot
------------------
Agents de démarrage et scripts cloud
Cloud-init
Bibliothèques cloud
https://github.com/F5Networks/f5-cloud-libs
--------------------
Intégrations de plateformes
Plateformes de gestion de conteneurs
Plateforme
Statut
Exemples et source
Kubernetes
Pris en charge par F5
https://github.com/F5Networks/k8s-bigip-ctlr
Pivotal Cloud Foundry
Pris en charge par F5
https://github.com/F5Networks/cf-bigip-ctlr
Marathon
Pris en charge par F5
https://github.com/F5Networks/marathon-bigip-ctlr
Red Hat OpenShift
Pris en charge par F5
https://hub.docker.com/r/f5networks/k8s-bigip-ctlr (https://hub.docker.com/r/f5networks/k8s-bigip-ctlr) ou
https://access.redhat.com/containers/?tab=tags#/registry.connect.redhat.com/f5networks/k8s-bigip-ctlr (https://access.redhat.com/containers/?tab=tags#/registry.connect.redhat.com/f5networks/k8s-bigip-ctlr)
Plateformes de cloud privé
Plateforme
Statut
Exemples et source
OpenStack (LBaaS)
Pris en charge par F5
https://github.com/F5Networks/f5-openstack-lbaasv2-driver
OpenStack (Heat)
Pris en charge par F5
https://github.com/F5Networks/f5-openstack-hot
VMware (vRO)
Tiers
https://bluemedora.com/products/f5/big-ip-for-vrealize-operations/
-----------------------
Remarque sur les outils d’orchestration et de gestion des workflows
Les outils et intégrations ci-dessus permettent d’automatiser le déploiement et la configuration de la plateforme BIG-IP afin d’assurer la disponibilité, la sécurité et la mise à l’échelle des applications. Aussi essentiels soient-ils, ces services ne constituent qu’une partie du déploiement d’une application complète. La création coordonnée et testée d’une pile applicative complète comprenant les serveurs, les données, le code applicatif compilé et l’infrastructure nécessite davantage qu’un simple outil d’automatisation.
Vous aurez besoin d’un outil d’orchestration de plus haut niveau, associé à des workflows et intégré à plusieurs systèmes d’automatisation. Ces outils sont le plus souvent utilisés dans le cadre de pratiques d’intégration continue et de livraison continue (CI/CD), pour lesquelles l’automatisation est indispensable dans la quasi-totalité des mises en œuvre. Bien qu’il existe plusieurs outils d’orchestration, Jenkins est sans doute le plus répandu, et des exemples de workflows montrent comment utiliser Jenkins, F5 et Ansible pour intégrer les fonctionnalités d’infrastructure en tant que code de F5 dans un workflow CI/CD. Toutefois, en règle générale, l’outil d’orchestration s’appuie sur l’un des outils d’automatisation de la configuration pour appliquer concrètement les modifications et déployer les services.
Licences
Les plateformes BIG-IP nécessitent une licence pour fonctionner. Il est donc utile d’intégrer l’octroi de licences au chemin critique de l’automatisation. Dans les environnements très dynamiques où les appareils virtuels BIG-IP peuvent devoir être rapidement redimensionnés à la hausse ou à la baisse, ou créés à des fins de test et de développement, les modèles de licence doivent être étudiés avec soin.
Dans le cloud public, une solution consiste à utiliser les versions de BIG-IP facturées à l’usage (disponibles sur les places de marché cloud). Ces instances obtiennent automatiquement leur licence, et les coûts sont facturés par le fournisseur de cloud selon l’utilisation ou la durée d’engagement.
Une autre option consiste à utiliser des pools de licences réutilisables achetées sous forme d’abonnement (ou de licences perpétuelles) conjointement avec F5 BIG-IQ License Manager, qui vous permettra d’attribuer et de révoquer des licences à partir d’un pool.
Vous pouvez automatiser les étapes d’octroi de licences à l’aide d’agents de démarrage et d’appels d’API. Cela nécessite un accès Internet sortant au serveur de licences F5 (même dans le cas de licences à l’usage sur des plateformes cloud).
Quelle solution utiliser et dans quel cas ?
Selon votre organisation, le choix des outils d’automatisation et d’orchestration appropriés peut être très simple ou s’avérer difficile. Il est simple si vous avez déjà adopté un outil ou une méthodologie pour d’autres composants et qu’il vous suffit d’intégrer BIG-IP au système. Même sans intégration à un outil particulier, la richesse de l’API REST iControl, associée aux fonctionnalités d’iControl LX et à cloud-init, permet d’intégrer assez facilement BIG-IP à un outil d’automatisation existant (en particulier avec des modèles iApp, qui permettent de créer une configuration même complexe à l’aide d’un seul appel d’API).
Toutefois, si vous partez de zéro, les choses peuvent être plus complexes. Comme pour le choix de toute autre solution, vous devez commencer par bien cerner vos besoins. Bien que ce document ne puisse pas établir à votre place la liste de vos besoins, voici un ensemble de questions et de recommandations qui vous aideront dans votre évaluation.
Modèle d’automatisation : Un modèle déclaratif sera beaucoup plus simple à utiliser pour les utilisateurs de votre solution d’orchestration. Ceux-ci doivent simplement savoir ce qu’ils veulent, plutôt que de connaître toutes les étapes procédurales permettant d’y parvenir. À l’avenir, la gamme F5 Automation Toolchain constituera le déploiement « modèle » pour les nouveaux sites.
Plateformes et environnements potentiels : Les conteneurs et diverses plateformes cloud feront inévitablement partie intégrante de l’infrastructure applicative — planifiez en conséquence.
Compétences : Disposez-vous déjà de compétences dans certaines des technologies sous-jacentes ? Gardez à l’esprit que ces compétences peuvent exister en dehors de votre service, mais au sein de votre entreprise dans son ensemble. Si tel est le cas, il peut être judicieux de choisir un outil qui utilise un langage déjà adopté par votre organisation.
Maintenabilité : Ne concevez que des systèmes que vous êtes en mesure de prendre en charge. Cela peut sembler évident, mais l’une des clés de la réussite consiste à choisir un niveau de complexité que votre organisation est capable de gérer, afin de maximiser les avantages de l’automatisation sans entraîner de surcharge opérationnelle excessive.
Conclusion
L’automatisation croissante des systèmes informatiques est inévitable. L’adoption d’une approche stratégique pour les principaux services de mise à disposition et de sécurité des applications permettra de garantir que les applications déployées par votre organisation restent sécurisées et disponibles. L’automatisation peut également contribuer à réduire vos coûts d’exploitation, en particulier lorsque vous travaillez sur plusieurs plateformes et clouds publics.
Choisir le bon système d’automatisation peut s’avérer difficile et devrait idéalement s’inscrire dans une démarche collaborative et globale, tenant compte des compétences dont vous disposez ainsi que de votre capacité à assurer la maintenance du système que vous mettez en place. Quelle que soit la solution choisie, vous pouvez compter sur la plateforme BIG-IP et l’expertise de F5 pour vous aider à fournir les services de niveau entreprise dont dépendent vos applications, où qu’elles soient déployées.
Remarque concernant le support F5. F5 assure le support de plusieurs modèles et outils, mais pas de tous. Lorsque des logiciels sont disponibles sur GitHub, seul le code figurant dans les dossiers « supported » des dépôts F5 est pris en charge. Pour les autres logiciels, les politiques de support sont définies dans les fichiers README correspondants.
PUBLIÉ LE 13 MAI 2019