Dans le monde des conteneurs, la configuration déclarative est reine
La transformation numérique à l’intérieur est essentielle pour permettre la transformation numérique à l’extérieur. L’un des composants fondamentaux de la transformation numérique interne est l’automatisation, qui repose fortement sur le plan de contrôle . Le plan de contrôle est l'endroit où l'automatisation se produit. À l’époque de l’informatique, nous l’appelions « réseau de gestion » et utilisions des protocoles comme SNMP pour assurer la surveillance, la configuration et le contrôle.
Aujourd’hui, le réseau de gestion existe toujours, du moins théoriquement, en tant que support sur lequel nous effectuons les mêmes tâches via le plan de contrôle. Le plan de contrôle est un terrain encombré d'API, de nœuds maîtres et même de files d'attente de messages qui permettent aux composants individuels d'un système distribué complexe de se gérer (presque) automatiquement. Elle est de plus en plus axée sur les événements, ce qui nécessite un changement de mentalité par rapport aux modèles de commandement et de contrôle centralisés du passé, qui reposaient principalement sur des modèles impératifs de gestion. Autrement dit, un système central donne des instructions implicites aux composants à l’aide d’appels d’API spécifiques qui provoquent des modifications. Les environnements d’aujourd’hui, en revanche, s’appuient sur des modèles déclaratifs qui répartissent la responsabilité de leur propre changement.
Dans aucun système cela n’est plus évident que dans les environnements conteneurisés. De l’extérieur, de tels systèmes semblent être presque de nature malveillante ; les messages et les événements sont publiés et déclenchés à volonté, sans aucun chef suprême pour déterminer qui ou quoi doit réagir à eux. Le plan de contrôle n’est plus tant une question de contrôle que de distribution sur un plan qui est davantage un maillage que les architectures en étoile des systèmes de gestion archaïques. Dans le monde traditionnel, nous utilisions des API et des protocoles pour appliquer des modifications aux composants. Dans le monde numérique et conteneurisé, nous utilisons des API pour extraire les informations nécessaires à un composant pour qu'il puisse se modifier.
Ce nouveau monde est réactif et évite le modèle impératif (piloté par API) du plan de contrôle traditionnel, s'appuyant plutôt sur un modèle déclaratif plus ouvert pour atteindre l'état final automatisé souhaité.
Cela n’est pas surprenant. Alors que nous adoptons de plus en plus une approche axée sur les logiciels pour tout (sous le nom de DevOps, Cloud et NFV), nous devons simultanément faire face à une échelle opérationnelle massive. Un modèle de gestion impératif en étoile n'est pas efficace car la charge de tous les changements repose sur un contrôleur central capable de communiquer via un ensemble déroutant d'API avec un groupe presque illimité de composants. Il s’agit d’un modèle « push », dans lequel le gestionnaire (contrôleur) pousse les modifications vers chaque composant affecté. Cela devient le goulot d’étranglement qui fait la réussite ou l’échec de l’ensemble du système.
Nous avons besoin d’un modèle piloté par événements qui repose sur l’extraction par les composants pour pouvoir évoluer et alléger la charge du contrôleur. Cela implique que les composants souhaitant participer à ce plan de contrôle doivent maîtriser un modèle de configuration déclarative. Plutôt que d’imposer des changements via une API (mode impératif), les conteneurs nous obligent à extraire les modifications via des configurations déclaratives. Les fournisseurs de composants (logiciels libres ou commerciaux) doivent s’abonner correctement aux modifications, puis extraire immédiatement les informations nécessaires à leur mise en œuvre.
Si cela vous évoque l’infrastructure en tant que code, c’est normal. Les configurations déclaratives sont essentiellement du code, ou du moins des artefacts de code. L’automatisation s’appuie de plus en plus sur le principe qui sépare la configuration de son service. Dans un modèle idéal, ces configurations déclaratives restent totalement agnostiques. Autrement dit, elles seraient lisibles par n’importe quel produit, commercial ou open source, capable de prendre en charge ce service. Par exemple, une configuration déclarative décrivant le service adéquat (serveur virtuel) et les applications constituant son ensemble de ressources pourrait être interprétée et mise en œuvre par le service X ou le service Y.
Les fichiers de ressources Kubernetes illustrent bien un modèle de configuration déclaratif où vous décrivez ce que vous souhaitez, sans préciser comment y parvenir. Cela contraste nettement avec les systèmes qui s'appuient sur des API d'infrastructure nécessitant une connaissance approfondie – parfois intime – de la manière d'obtenir les résultats désirés.
Le modèle déclaratif vous permet aussi de considérer l'infrastructure comme du bétail. Si un élément tombe en panne, vous pouvez simplement le supprimer et lancer une nouvelle instance. Toute la configuration nécessaire reste dans le fichier de ressources ; il n’y a pas de bouton « sauvegardez votre travail ou il sera perdu » car il n’y a rien à sauvegarder. Cette infrastructure est presque immuable et conçue pour être remplacée rapidement. Elle est essentielle dans les systèmes qui changent au rythme des minutes, voire des secondes, pour réduire au maximum les conséquences d’une panne.
À mesure que nous évoluons de plus en plus vers des systèmes automatisés à grande échelle et – oserais-je dire ? – sécurisés, nous devrons adopter des modèles déclaratifs pour la gestion de la myriade d’appareils et de services composant le chemin de données des applications, sinon nous risquons d’être ensevelis sous une avalanche de dettes opérationnelles résultant de méthodes manuelles d’intégration et d’automatisation.