Cinq façons de préparer votre migration vers Red Hat Ansible Automation Platform 2

Red Hat® Ansible® Automation Platform 2 propose une architecture repensée, de nouveaux outils et une expérience améliorée mais familière pour les équipes chargées de l'automatisation. Lorsque vous planifiez votre stratégie de migration, passez en revue cette liste de contrôle afin de préparer une transition en douceur vers Ansible Automation Platform 2.

Votre environnement présente des configurations uniques, et il est crucial d'effectuer une évaluation technique approfondie avant la migration.

• Analysez votre installation actuelle d'Ansible Automation Platform 1.x, y compris les modèles de déploiement en place, les intégrations et tout aspect susceptible de compliquer la migration.
• Déterminez les changements à apporter pour répondre aux exigences techniques d'Ansible Automation Platform 2.
• Évaluez l'état de préparation des parties prenantes en vue de la planification et de l'exécution de la migration.
• Assurez la conformité, l'application des politiques de sécurité et les audits.

Ansible Automation Platform 2 introduit de nouvelles exigences qui influenceront votre stratégie de migration. Nous recommandons une approche progressive si le respect de ces exigences demande un effort important à votre entreprise.

• Automation Controller 4 (qui remplace Ansible Tower) n'est compatible qu'avec PostgreSQL 12. PostgreSQL 10 n'est pas pris en charge.
• Pour les installations en environnement physique et virtuel, Ansible Automation Platform 2 nécessite Red Hat Enterprise Linux® 8 (x86_64).
• Les environnements virtuels Python sont remplacés par des environnements d'exécution Automation Execution Environment.
• Les outils de migration d'Ansible Automation Platform 2 prennent en charge la dernière version d'Ansible Automation Platform 1.x.
• Ansible Automation Platform 2 inclut Ansible Core 2.9, ce qui permet d'assurer la compatibilité des playbooks, ainsi que les dernières versions grâce aux environnements d'exécution.

Votre plan doit tenir compte des conséquences de la migration sur l'ensemble de l'entreprise. Voici nos recommandations :

• Réalisez une analyse coûts-avantages montrant le coût initial de la migration, les économies potentielles au fil du temps et les nouveaux revenus dégagés.
• Identifiez les parties prenantes externes et internes et assurez leur disponibilité.
• Effectuez une analyse des risques pour comprendre les effets de la migration sur les processus métier et la distribution de services.
• Définissez les délais, les étapes et les résultats du projet.
• Évaluez les efforts requis pour gérer le changement ainsi que les besoins en formation.
• Établissez les critères de réussite de la migration et les indicateurs de mesure nécessaires.

Dans votre plan de migration, il est important d'évaluer les contenus Ansible Automation Platform existants (les rôles et playbooks Ansible, les collections de contenus Ansible Content Collections et les modules) et aussi de tester leur compatibilité avec Ansible Automation Platform 2. La procédure d'évaluation comprendra, au minimum, les étapes suivantes :

• Test et mise à jour des contenus d'automatisation pour assurer leur compatibilité avec Ansible Core 2.9 ou version ultérieure
• Prise en compte des exigences techniques liées à l'automatisation via Ansible Core 2.9 avec des contenus groupés par rapport à Ansible Core et des collections certifiées ou compatibles dans des environnements d'exécution
  • La migration vers les collections Ansible Content Collections n'est pas obligatoire avec Ansible Core 2.9, mais fortement recommandée.
• Planification, test et migration des environnements virtuels Python (venvs) vers des environnements d'exécution
  • Déterminez si vous avez besoin d'environnements d'exécution personnalisés pour exécuter vos contenus Ansible en fonction des dépendances requises.
  • Aidez-vous des outils fournis par Ansible Automation Platform 2 pour la migration.
  • Renseignez-vous pour savoir comment migrer des environnements virtuels Python vers des environnements Automation Execution Environment.
• Conservation, transformation ou suppression des contenus d'automatisation existants (adoption d'un modèle basé sur des collections ou suppression des contenus inutiles, par exemple)

Votre plan de migration doit prévoir l'intégration des systèmes déjà en place. Il doit également évaluer les éventuels effets sur votre modèle d'exploitation actuel. Posez-vous les questions suivantes lorsque vous planifiez votre migration :

Workflows de promotion du contenu

• Quelle version des environnements Automation Execution Environment correspond à mon modèle ? (Par exemple, version test, version intermédiaire, dernière version et numéro de version)
• Quelle structure de référentiel d'Automation Hub (registre de conteneurs) convient le mieux à mon entreprise ? (Par exemple, des référentiels distincts pour les tests, le développement et la production pour les collections Ansible Content Collections)
• Est-il préférable d'utiliser l'instance hébergée d'Automation Hub ou l'instance privée ? Qui va gérer cette instance ?

Adoption de la plateforme

• De quelle aide les parties prenantes externes ont-elles besoin pour adopter et utiliser la plateforme ?
• Quelle est la formation nécessaire pour intégrer toutes les parties prenantes ?
• Qui sera responsable de la gestion des environnements d'exécution et des collections de contenus ? Cette tâche sera-t-elle assurée au niveau de chaque division ou centralisée ?

Gestion du cycle de vie des environnements d'exécution

• Comment gérer et distribuer les fichiers de définition ansible-builder ?
• Comment mettre à jour et assurer la sécurité de mes environnements d'exécution ? Quel est le plan d'intervention de sécurité pour corriger les CVE (Common Vulnerabilities and Exposures) et rester conforme ?

Gestion du cycle de vie de la plateforme

• Comment déployer de nouveaux clusters et respecter les exigences minimales ?
• Comment mettre à niveau mes clusters ? Quelle est la fréquence des mises à niveau dans mon entreprise ?
• Quelles sont les exigences non fonctionnelles et en quoi vont-elles affecter ma conception ? (Par exemple, les sauvegardes, la gestion des configurations, la récupération après sinistre et la haute disponibilité)

Pour en savoir plus, consultez l'article de blog New reference architecture: Deploying Red Hat Ansible Automation Platform 2.1.