Migration d’applications

8 minutes

Une fois que vous avez migré votre base de données locale vers Azure, vous devez mettre à jour vos applications existantes pour leur permettre d’accéder à PostgreSQL à son nouvel emplacement.

Le serveur et la base de données d’origine que vous utilisiez localement contiendront les rôles qui définissent les privilèges associés aux utilisateurs, les opérations qu’ils peuvent exécuter et les objets sur lesquels ils effectuent ces opérations. Azure Database pour PostgreSQL utilise les mêmes mécanismes d’authentification et d’autorisation que PostgreSQL s’exécutant en local.

Dans cette unité, vous allez explorer les mises à jour que vous devez apporter à vos applications pour vous connecter à votre instance Azure Database pour PostgreSQL nouvellement migrée.

Créer les rôles d’utilisateur manuellement

Lorsque vous transférez une base de données PostgreSQL vers Azure Database pour PostgreSQL à l’aide d’Azure Database Migration Service, les rôles et les attributions de rôles ne sont pas copiés. Vous devez recréer manuellement les rôles et comptes d’utilisateurs nécessaires pour l’administrateur et les utilisateurs des tables de la base de données cible. Pour effectuer ces tâches, vous utilisez les utilitaires psql ou pgAdmin. Exécutez la commande CREATE ROLE. Utilisez la commande GRANT pour attribuer les privilèges nécessaires à un rôle. Par exemple :

CREATE ROLE myuseraccount WITH LOGIN NOSUPERUSER CREATEDB PASSWORD 'mY!P@ss0rd';
GRANT ALL PRIVILEGES ON DATABASE mydatabase TO myuseraccount;

Notes

Vous pouvez également utiliser la commande createuser de l’invite bash pour créer des rôles PostgreSQL.

Pour afficher les rôles existants dans la base de données locale, exécutez l’instruction SQL suivante :

SELECT rolname
FROM pg_roles;

Vous pouvez utiliser la commande \du dans l’utilitaire psql pour afficher les privilèges attribués aux rôles.

                              List of roles
   Role name   |               Attributes                                   | Member of
---------------+------------------------------------------------------------+-----------
 azureuser     | Superuser, Create DB                                       | {}
 myuseraccount | Create DB                                                  | {}
 postgres      | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

Notes

Notez qu’Azure Database pour PostgreSQL ajoute des rôles propres. Ces rôles incluent azure_pg_admin, azure_superuser et l’utilisateur administrateur que vous avez spécifié lors de la création du service. Vous vous connectez à l’aide de vos comptes d’administrateur, mais les deux autres rôles sont réservés pour une utilisation par Azure : vous ne devez pas essayer de les utiliser.

Reconfigurer les applications

Reconfigurer une application de sorte qu’elle se connecte à Azure Database pour PostgreSQL est un processus simple. Toutefois, il est plus important de déterminer une stratégie pour les applications de migration.

Considérations relatives à la reconfiguration d’applications PostgreSQL

Dans un environnement d’entreprise, les applications s’exécutant sur les mêmes bases de données PostgreSQL peuvent être nombreuses. De même, ces applications peuvent être exécutées par un grand nombre d’utilisateurs. Aussi, vous voulez être assuré que lorsque vous passerez du système existant à Azure Database pour PostgreSQL, vos systèmes fonctionneront toujours, que les utilisateurs pourront continuer à effectuer leurs tâches et que vos opérations stratégiques resteront opérationnelles. Dans le module 1, leçon 2, Considérations relatives à la migration, la plupart des problèmes ont été abordés dans les grandes lignes. Lorsque vous migrez une base de données PostgreSQL vers Azure, il existe des précisions à noter :

Si vous effectuez une migration hors connexion, les données de la base de données PostgreSQL d’origine et les nouvelles bases de données s’exécutant dans Azure risquent de commencer à diverger rapidement si l’ancienne base de données est toujours utilisée. Une migration hors connexion est indiquée si vous mettez un système entièrement à l’arrêt sur une courte période et que vous basculez toutes les applications vers le nouveau système avant de le redémarrer. Cette approche peut ne pas être applicable à un système vital pour l’entreprise. Si vous migrez vers une instance PostgreSQL s’exécutant sur une machine virtuelle Azure, vous configurez la réplication PostgreSQL entre votre système local et celui qui s’exécute dans Azure. La réplication PostgreSQL Native fonctionne dans une seule direction, mais des solutions tierces sont disponibles pour prendre en charge la réplication bidirectionnelle entre les serveurs PostgreSQL (ces solutions ne fonctionnent pas avec Azure Database pour PostgreSQL).
Si vous effectuez une migration en ligne, le service Azure Database pour PostgreSQL configure la réplication de la base de données locale vers la base de données s’exécutant dans Azure. Après le transfert de données initial, la réplication vérifie que les modifications éventuellement apportées à la base de données locale sont copiées dans la base de données dans Azure, mais pas l’inverse.

Dans les deux cas, vous devez veiller à ne pas perdre de données actives du fait d’un remplacement accidentel. Par exemple, dans le scénario en ligne, les modifications dans une application connectée à la base de données s’exécutant dans Azure Database pour PostgreSQL pourraient être remplacées aveuglément par une application utilisant toujours la base de données locale. Avec cela à l’esprit, vous devez envisager les approches suivantes :

Migrez les applications en fonction du type de leur charge de travail. Une application qui accède aux données en lecture seule peut basculer sans risque vers la base de données s’exécutant dans Azure Database pour PostgreSQL ; toutes les modifications apportées par les applications qui utilisent encore la base de données locale seront visibles. Vous pouvez aussi adopter la stratégie inverse si les applications en lecture seule n’ont pas besoin de données entièrement à jour.
Migrez les utilisateurs en fonction du type de leur charge de travail. Cette stratégie est comparable à la précédente, sauf que des utilisateurs peuvent générer uniquement des rapports pendant que d’autres modifient les données. Vous pouvez configurer une même application de sorte qu’elle se connecte à la base de données appropriée en fonction des besoins de l’utilisateur.
Migrez les applications en fonction des jeux de données qu’elles utilisent. Si vos applications n’utilisent pas les mêmes sous-ensembles de données, vous pouvez migrer ces applications séparément.

Reconfiguration d’une application

Pour reconfigurer une application, faites-la pointer vers la nouvelle base de données. La plupart des applications bien écrites vont isoler la logique de connexion (c’est la seule partie du code qui doit être modifiée). Dans de nombreux cas, les informations de connexion peuvent être stockées sous forme d’informations de configuration. Vous n’avez donc que ces informations à mettre à jour.

Vous trouverez les informations de connexion de votre service Azure Database pour PostgreSQL sur le portail Azure, dans la page Chaînes de connexion de votre service. Azure fournit les informations pour de nombreux langages et frameworks de programmation courants.

Ouvrir des ports réseau

Comme nous l’avons vu dans la leçon 1 de ce module, Azure Database pour PostgreSQL est un service protégé qui s’exécute derrière un pare-feu. Les clients ne peuvent pas se connecter tant que leur adresse IP n’est pas reconnue par le service. Vous devez ajouter les adresses IP, ou les plages de blocs d’adresses, des clients exécutant des applications qui doivent se connecter à vos bases de données.

Tester et vérifier les applications

Avant de faire basculer vos applications et vos utilisateurs vers la nouvelle base de données, il est important de vérifier que vous avez tout bien configuré.

Commencez par tester les applications à blanc et connectez-vous sous chaque rôle pour vérifier que les fonctionnalités appropriées sont disponibles.

Ensuite, effectuez des « tests d’imprégnation » pour reproduire le nombre d’utilisateurs exécutant les charges de travail représentatives de manière simultanée sur une période donnée. Supervisez le système et vérifiez que vous avez alloué suffisamment de ressources à votre service Azure Database pour PostgreSQL.

À ce stade, vous pouvez commencer à déployer le système pour les utilisateurs. Il peut être utile d’implémenter une forme de test de contrôle de validité (ou « canari »), où un petit sous-ensemble d’utilisateurs est transféré à son insu vers le système. Vous pourrez ainsi vous faire une idée non biaisée de l’expérience utilisateur avec la nouvelle base de données (inchangée, meilleure ou dégradée).