Planification de votre parcours de mise à niveau vers Red Hat Ansible Automation Platform 2.6

Le lancement de Red Hat Ansible Automation Platform 2.6 constitue une étape majeure. Avant de commencer la mise à niveau, trois points clés doivent être connus afin de faciliter la transition :

• Cette version constitue la dernière à proposer un programme d'installation basé sur RPM. Red Hat Ansible Automation Platform 2.6 utilisant la méthode RPM est disponible uniquement pour Red Hat Enterprise Linux 9. Le programme d'installation RPM sera retiré après cette version. Red Hat Ansible Automation Platform 2.7 prendra uniquement en charge une méthode d'installation conteneurisée, l'opérateur Red Hat OpenShift ou nos services cloud. Le moment est donc venu d'entamer la transition.
• Red Hat Ansible Automation Platform 2.6 constitue une version pivot. Tout parcours de mise à niveau vers les versions futures de la plateforme doit passer par la version 2.6. Il s'agit d'une étape incontournable.
• RHEL 8 n'est plus pris en charge. Si vous utilisez toujours RHEL 8, une migration vers RHEL 9 (ou RHEL 10) s'avère nécessaire avant d'effectuer la mise à niveau vers Red Hat Ansible Automation Platform 2.6.

Planification de la mise à niveau

Lors de la planification de la transition vers Red Hat Ansible Automation Platform 2.6, deux considérations importantes doivent orienter le plan de mise à niveau :

Un seul changement peut intervenir à la fois. Qu'il s'agisse du système d'exploitation, de la méthode d'installation ou de la version du produit, le programme d'installation gère uniquement un changement par exécution. Ce fonctionnement implique parfois plusieurs exécutions du programme. Consultez la documentation officielle pour obtenir des précisions sur le fonctionnement de cette approche.

Dans la plupart des cas, une nouvelle installation s'avère nécessaire. Hormis quelques scénarios spécifiques, tels que la mise à niveau de la version 2.5 vers la version 2.6 sur la même architecture ou certains déploiements d'opérateurs Red Hat OpenShift, le déploiement d'une nouvelle instance Red Hat Ansible Automation Platform 2.6 suivi de la migration de la configuration est requis.

Cette situation soulève une question clé : Comment importer une configuration existante dans la nouvelle instance ? La réponse repose sur le fait que la configuration de Red Hat Ansible Automation Platform réside dans une base de données PostgreSQL. La stratégie de mise à niveau concerne la manière de faire évoluer ces données.

Méthodes de mise à niveau

Deux voies permettent d'accéder à Ansible Automation Platform 2.6 : une migration centrée sur la base de données ou une migration centrée sur les API. Le choix dépend de l'environnement, des exigences et des compromis acceptables.

Une approche centrée sur la base de données traite Red Hat Ansible Automation Platform comme un système stateful dont les données constituent la source de vérité. Une approche centrée sur les API traite la plateforme selon le principe de la configuration en tant que code (CaC), où la source de vérité réside dans les fichiers de configuration. Consultez le tableau ci-dessous pour évaluer les aspects techniques de chaque approche :

Migrations centrées sur la base de données

Les migrations centrées sur la base de données constituent la voie documentée et entièrement prise en charge qui préserve et migre l'intégralité de la base de données durant le processus de mise à niveau. Le défi ? La « danse de la mise à niveau » Que vous passiez de RHEL 8 à RHEL 9, d'un système RPM à un système conteneurisé ou d'Ansible Automation Platform 2.4/2.5 à la version 2.6, c Chacune de ces étapes nécessite sa propre infrastructure. 

Ce processus peut exiger le provisionnement et la gestion de nombreux environnements intermédiaires. Selon le point de départ, l'objectif final de la migration et l'envergure de l'environnement (donc la taille de la base de données), cette tâche peut s'avérer chronophage.

Une mise en garde importante : Si cette complexité vous incite à adopter les services cloud gérés d'Ansible Automation Platform, sachez que le chargement d'une base de données vers ces services nécessite l'ouverture d'un ticket d'assistance. Ce processus est documenté ici. L'exécution autonome de cette opération nécessite l'utilisation de l'approche centrée sur les API.

Migration centrée sur les API

Red Hat ne prend pas officiellement en charge cette approche, bien que les composants individuels permettant cette technique de migration soient pris en charge. Toutefois, cette méthode s'avère plus rapide, en particulier pour les environnements de grande taille. Comme il s'agit d'un passage unique vers la plateforme cible, les installations intermédiaires ne sont pas nécessaires.

Cette méthode consiste à exporter la configuration d'Ansible Automation Platform à l'aide d'appels d'API afin de la stocker localement, par exemple dans des fichiers de configuration ou une base de données temporaire. Vous pouvez ensuite modifier ces fichiers selon vos besoins, puis les restaurer sur une autre plateforme, également via l'API. Cette méthode présente également un avantage secondaire : Elle introduit la configuration en tant que code (CaC) dans le flux de travail. Cela fournit une base pour gérer la plateforme à l'aide des méthodes CaC à l'avenir.

Les compromis ? L'historique des tâches sera perdu (perte atténuée par un agrégateur de journaux externe) et les secrets devront être gérés avec précaution (risque atténué grâce à un gestionnaire de secrets externe). La modification des fichiers de configuration exportés peut s'avérer nécessaire pour garantir un formatage correct lors de l'importation, notamment pour les objets private automation hub et Event-Driven Ansible.

Note concernant les secrets

La base de données de configuration stocke les secrets de notification et d'authentification, puis les chiffre à l'aide de la clé SECRET_KEY de la base de données. En raison de ce chiffrement, l'API n'exporte pas ces valeurs. Par conséquent, l'accès aux secrets de votre configuration nécessite un accès root au serveur de base de données. Comme cette opération expose les secrets en texte brut, vous devez les manipuler avec une extrême prudence, par exemple en les chiffrant à nouveau dans un coffre-fort Ansible. 

Toutefois, l'utilisation d'un gestionnaire de secrets externe, tel que HashiCorp Vault, élimine ce problème car ces secrets ne résident pas dans Ansible Automation Platform. Par ailleurs, s'il n'y a que peu de secrets à gérer, renseigner directement les secrets dans la nouvelle plateforme peut s'avérer tout aussi simple.

Éléments à prendre en compte pour les deux méthodes

Quel que soit le chemin choisi, gardez ce point à l'esprit : Les intégrations externes et les jetons d'API nécessiteront probablement une attention particulière. 

Ansible Automation Platform 2.5 a introduit l'automation gateway (passerelle d'automatisation), une interface unifiée qui connecte le contrôleur d'automatisation, Ansible automation hub et le contrôleur Event-Driven Ansible au sein d'une interface unique. Ce changement a déplacé de nombreux points de terminaison d'API vers de nouveaux chemins. Bien que la version 2.6 assure la rétrocompatibilité de ces points d'accès d'intégration, les versions futures nécessiteront une mise à jour de ces derniers. En outre, la plateforme devra régénérer et redistribuer la plupart des jetons. Il conviendra peut-être de provisionner des serveurs supplémentaires et de mettre à jour les équilibreurs de charge vers le nouveau service de passerelle.

Bases de données gérées en externe

Les clients qui disposent de bases de données gérées en externe doivent prendre en compte d'autres éléments.  Premièrement, Ansible Automation Platform 2.4 utilise Postgres 13. Cette version passe à Postgres 15 pour la version 2.5 et à PostgreSQL 15 pour la version 2.6. Ansible Automation Platform 2.6 prend également en charge les bases de données PostgreSQL 16 et 17 fournies par les clients. Cette procédure de mise à niveau de la base de données constitue un élément clé de la migration et du cycle de mise à jour. Elle explique pourquoi les clients ne peuvent pas réutiliser leur base de données existante sans suivre ce processus.  Concernant Ansible Automation Platform 2.5 et ses versions ultérieures, les bases de données fournies par les clients doivent activer les composants internationaux pour Unicode (ICU). Cette option est disponible, mais non activée par défaut, chez la plupart des grands fournisseurs tels que EDB, Amazon Web Services Relational Database Service (AWS RDS) et Azure SQL Database. Cette compatibilité de base de données explique l'impossibilité de simplement mettre à jour le schéma dans une base de données existante.

Compatibilité des playbooks

Lors de la mise à niveau d'Ansible Automation Platform, la version d'ansible-core fournie dans l'environnement d'exécution par défaut monte également en version. Il reste possible d'exécuter d'anciens environnements d'exécution sur des versions plus récentes de la plateforme afin d'assurer la rétrocompatibilité. Toutefois, Red Hat encourage fortement la mise à niveau pour profiter des nouvelles fonctionnalités et des correctifs de sécurité.

La mise à niveau des environnements d'exécution implique le passage à une nouvelle version d'Ansible core, ce qui peut entraîner certains changements.  Voici les principaux changements à prévoir :

Passage d'Ansible Automation Platform 2.4 à 2.6 (passage d'ansible-core 2.15 à 2.16)

Il s'agit d'une mise à niveau mineure. Le changement le plus notable réside dans le fait que certaines alertes dans les instructions conditionnelles constituent désormais des erreurs. Au-delà de ce point, l'impact demeure minime.

Passage à ansible-core 2.18 (environnement d'exécution facultatif dans Ansible Automation Platform 2.6) Cet environnement d'exécution facultatif pris en charge pour Ansible Automation Platform 2.6 apporte des changements nettement plus importants. Précisément :

• Les versions 2.7 et 3.6 de Python sur les nœuds cibles ne sont plus prises en charge. Cet environnement d'exécution ne permet donc plus de cibler des hôtes RHEL 6. L'automatisation des hôtes RHEL 7 avec Ansible Automation Platform nécessite Python 3.8 (disponible via Red Hat Software Collections).
• L'environnement d'exécution inclut désormais la version 3.11 de Python. Les bibliothèques Python personnalisées et tierces doivent être mises à jour vers des bibliothèques compatibles avec la version 3.11.
• Le nettoyage des « dead batteries » (modules obsolètes) de Python est en cours. La PEP 594 prévoit la suppression des bibliothèques non maintenues, non sécurisées et obsolètes de la bibliothèque standard au cours des prochaines versions de Python. Les avertissements d'obsolescence commencent avec Python 3.11 ; certaines bibliothèques disparaissent dans la version 3.12, et la suppression massive intervient dans la version 3.13.

Pour la grande majorité des personnes utilisant nos solutions, ce point ne constitue pas une préoccupation immédiate, mais il convient de prêter attention aux avertissements d'obsolescence dès maintenant afin de préparer la transition.

Pour obtenir des détails complets sur les versions d'ansible-core prises en charge, consultez la politique d'assistance officielle de Red Hat.

La transition vers Ansible Automation Platform 2.6 représente bien plus qu'une simple mise à jour de version, il s'agit d'une étape stratégique qui prépare l'arrivée de la prochaine génération d'automatisation. Le choix d'une stratégie de migration adaptée à votre infrastructure actuelle permet de maintenir la résilience et la sécurité de votre automatisation, tout en anticipant les évolutions futures.

Ressources supplémentaires

• Article : Automatisation des mises à niveau d'Ansible Automation Platform 2.6 avec Python, AsyncIO et les opérations en masse
• Notes de version et documentation d'Ansible Automation Platform.
• Nouveautés d'Ansible Automation Platform