Migration et restauration
Migrez ou restaurez la configuration d'un système PowerShell Universal.
Il est souvent souhaitable de migrer la configuration d'un serveur PowerShell Universal d'une machine à une autre. Cela peut être dû à un changement d'infrastructure ou à une restauration à partir d'une sauvegarde. Cela peut également concerner des mises à niveau du système d'exploitation ou une maintenance générale du centre de données.
Ce document explique les étapes nécessaires pour migrer la configuration de PowerShell Universal vers une autre machine.
Nous recommandons d'arrêter le service PowerShell Universal avant d'effectuer la migration ou la restauration.
Stop-Service 'PowerShellUniversal'Selon le type de migration ou de restauration, il est possible que vous n'ayez pas besoin d'effectuer toutes ces actions.
Données de configuration
Les fichiers de données de configuration sont stockés dans %ProgramData%\UniversalAutomation\Repository par défaut. Ils comprennent des fonctionnalités telles que les API, les scripts et les applications. L'ensemble du répertoire est nécessaire au bon fonctionnement de la configuration du système cible.
Vous pouvez copier le dossier manuellement ou via PowerShell. Assurez-vous d'inclure tous les sous-répertoires.
Copy-Item $ENV:ProgramData\UniversalAutomation\Repository \\newServer\C$\ProgramData\UniversalAutomation\Repository -RecurseBase de données
La migration de la base de données dépend du type de base de données utilisé.
SQLite
Vous devrez copier le fichier de base de données SQLite vers l'emplacement de base de données configuré ou par défaut. Sur une installation par défaut, il s'agit de %ProgramData%\UniversalAutomation\database.db. Le compte de la machine cible ou le compte de service devra avoir un accès en lecture et en écriture à ce fichier de base de données.
Copy-Item $ENV:ProgramData\UniversalAutomation\database.db \\newServer\C$\ProgramData\UniversalAutomation\database.db Si vous effectuez une restauration à partir d'une sauvegarde, vous devrez peut-être rétrograder le schéma si vous avez mis à niveau la version.
SQL et PostgreSQL
Ces bases de données étant stockées en dehors du serveur PowerShell Universal, vous n'avez pas besoin d'effectuer de migration de la base de données elle-même. Vous devrez vous assurer que le serveur cible dispose d'un accès réseau à l'hôte SQL.
Si vous effectuez une restauration à partir d'une sauvegarde, vous devrez peut-être rétrograder le schéma si vous avez mis à niveau la version.
Paramètres de l'application
Le fichier appsettings.json de PowerShell Universal est nécessaire pour fournir les paramètres de serveur appropriés à la plateforme. Par défaut, il est stocké dans %ProgramData%\PowerShellUniversal\appsettings.json. Vous devrez le copier sur le nouveau serveur au même emplacement.
Ce fichier contient des paramètres de configuration tels que le certificat HTTP, l'authentification, les paramètres de synchronisation git, les options de configuration de l'API et bien plus encore.
Les fichiers appsettings.json ne changent pas entre les mises à niveau et vous n'aurez probablement pas besoin d'effectuer cette action lors d'une restauration.
Coffres de secrets
PowerShell Universal inclut 3 coffres de secrets intégrés qui peuvent nécessiter une migration. Le coffre de base de données est inclus dans la migration de la base de données et ne nécessite pas d'étapes supplémentaires. Si vous effectuez une restauration, il est peu probable que vous deviez effectuer ces opérations de restauration, à moins que les coffres de secrets ne soient corrompus.
PSUSecretStore
Le coffre PSUSecretStore utilise le module SecretStore de Microsoft. Ce module stocke les secrets sur disque à l'aide d'un chiffrement symétrique. Une clé de chiffrement par défaut est incluse avec les installations de PowerShell Universal. Si la clé a été mise à jour, la nouvelle clé se trouvera dans le fichier appsettings.json que vous avez migré à l'étape précédente. Vous devrez également déplacer le magasin de secrets physique vers le système de fichiers du nouveau serveur.
Le module SecretStore utilise un emplacement de stockage spécifique à l'utilisateur pour garantir que les listes de contrôle d'accès (ACL) sont appliquées aux fichiers eux-mêmes. Vous devrez vous assurer de copier le contenu du coffre vers le compte de l'utilisateur qui exécutera PowerShell Universal sur le nouveau système.
BuiltInLocalVault
Le coffre BuiltInLocalVault est uniquement disponible sur Windows et utilise le Gestionnaire d'informations d'identification pour stocker les secrets. Vous devrez recréer ces secrets dans le magasin du Gestionnaire d'informations d'identification sur le nouveau système.
Dans le Gestionnaire d'informations d'identification, vous trouverez les secrets PowerShell stockés avec le préfixe ps:.
Bien qu'il ne soit pas possible d'extraire les informations d'identification directement depuis l'interface utilisateur du Gestionnaire d'informations d'identification, vous pouvez utiliser les modules Secret Management directement. Pour récupérer des secrets, vous pouvez procéder comme suit.
Sur le nouveau serveur, vous pouvez effectuer l'opération inverse en appelant Set-Secret. Notez que ces commandes doivent être exécutées sous le compte de service exécutant PowerShell Universal afin de les stocker correctement dans le compte du Gestionnaire d'informations d'identification de l'utilisateur.
Authentification
Certains types d'authentification nécessiteront une configuration en dehors de PowerShell Universal. À moins que vous ne déplaciez la machine exécutant PowerShell Universal ou que vous ne changiez les URL accessibles, vous n'aurez pas besoin d'effectuer ces actions.
OpenID Connect
Assurez-vous que les URL de connexion appropriées sont configurées dans votre fournisseur d'identité (par exemple Azure AD ou Okta) si le nom d'hôte du serveur change. Sans URL de connexion correctement configurées, les utilisateurs ne pourront pas se connecter au nouveau système.
Windows
L'authentification Windows nécessite la configuration d'un SPN pour le compte de service exécutant le service PowerShell Universal. Assurez-vous que ce SPN est en place avant de tenter d'utiliser l'authentification Windows avec le nouveau système.
Autres ressources et considérations
Il peut exister d'autres ressources utilisées par PowerShell Universal sur le système qui doivent être prises en compte lors de la migration ou de la restauration des serveurs. En règle générale, vous n'aurez pas à vous soucier de ces ressources lors d'une restauration, car elles devraient rester les mêmes si la machine n'a pas changé.
Modules PowerShell
Variables d'environnement
Privilèges des comptes locaux
Autorisations du système de fichiers
Configuration du proxy
Certificats
Clés SSH Git ou informations d'identification
Paramètres DNS
Fichiers de l'application
Une fois toutes les étapes suivantes effectuées, vous pouvez maintenant installer PowerShell Universal sur le nouveau serveur. Si vous effectuez une rétrogradation lors d'une restauration, veuillez suivre la documentation Rétrogradation.
MSI \ Kestrel
Le package MSI pour PowerShell Universal installe la plateforme en tant que service Windows qui héberge son propre serveur web appelé Kestrel. Pour installer le service, téléchargez le MSI et exécutez-le. Nous recommandons d'utiliser exactement la même version que le serveur source.
Lors de l'installation du MSI, laissez tous les paramètres par défaut. Nous recommandons de laisser le champ du compte de service vide et de décocher la case indiquant de démarrer le service PowerShell Universal une fois l'installation terminée.
Une fois l'installation terminée, le service sera créé mais ne sera pas en cours d'exécution. Ouvrez le Gestionnaire de contrôle des services (services.msc) et définissez le compte de service pour le service PowerShell Universal. Démarrez le service.
Débogage des problèmes
Lors de la migration d'un service PowerShell Universal, vous pouvez rencontrer des problèmes résultant de différences de configuration entre les deux systèmes. Voici les endroits où chercher plus d'informations.
Observateur d'événements
Si le service démarre puis s'arrête, il peut y avoir un problème d'accès à la base de données. Nous recommandons de consulter le journal des applications dans l'Observateur d'événements. PowerShell Universal signalera deux erreurs d'application incluant .NET dans leur nom. La deuxième de ces deux erreurs fournira une exception lisible par l'utilisateur avec plus de détails.
Journaux système
PowerShell Universal écrira les journaux système dans le répertoire %ProgramData%\PowerShellUniversal. Recherchez les chaînes commençant par [ERR] pour obtenir plus d'informations sur les problèmes liés à l'installation.
Notifications
Après avoir migré le service, vérifiez s'il existe des notifications d'erreur susceptibles d'indiquer une mauvaise configuration du système.
Mis à jour
Ce contenu vous a-t-il été utile ?