Migrer des charges de travail Linux et PostgreSQL

  • 45 minutes

Ce module vous guide tout au long de la migration d’une charge de travail existante d’un environnement cloud ou local vers Azure. Il couvre la migration du calcul vers une machine virtuelle Azure et des données vers Azure Database pour PostgreSQL. L’application est un exemple indépendant du cloud remplaçant n’importe quelle application du monde réel préparée pour une migration vers le cloud.

Dans cette unité, vous explorez l’avantage d’effectuer les transitions suivantes en bénéficiant des contrôles d’identité et de sécurité fournis par Azure :

  • Passage d’un environnement auto-hébergé (comme à partir d’une base de données ) à une offre de base de données complètement managée
  • Passage d’un calcul bare metal à des machines virtuelles hébergées dans le cloud

Vous explorez également les avantages de la gestion des ressources dans le cloud du point de vue des coûts et du niveau de performance. Et vous découvrez comment calculer et gérer avec précision les coûts avant et après le déploiement, ainsi que l’optimisation du niveau de performance du point de vue du calcul et des données.

Charge de travail et données

Notre charge de travail est une application écrite dans Go qui utilise des données hébergées dans PostgreSQL. Nos données constituent un jeu de données ouvert qui vous permet d’explorer la puissance de la plateforme Postgres et des extensions associées.

Bien que cette application puisse être exécutée facilement dans un conteneur, les parties prenantes ont choisi de ne pas le faire à ce stade. La génération d’un conteneur, le déploiement vers une plateforme de conteneurs ou l’utilisation d’une orchestration de conteneur est actuellement ne sont pas abordées. Il est toutefois possible que la migration vers des conteneurs soit une étape logique dans le futur.

Le référentiel GitHub associé à ce module vous fournit une application et ses données associées. Vous découvrez comment préparer votre application et exporter vos données pour atteindre un état similaire à cet exemple d’application. Vous pouvez également utiliser l’exemple d’application en tant que modèle pour un déploiement entièrement nouveau.

Quel est l’intérêt de migrer cette charge de travail ?

Il est possible que vous vous interrogiez sur les avantages de la migration de cette charge de travail vers le cloud. Voici quelques-unes des propositions de valeur.

Sécurité et conformité

Quand vous faites passer des charges de travail de calcul et de données dans le cloud, elles bénéficient d’une sécurité accrue.

Les machines virtuelles dans Azure bénéficient d’un vaste éventail de fonctionnalités de sécurité et de conformité, notamment les pare-feux, les réseaux virtuels, l’accès juste-à-temps aux machines virtuelles, le chiffrement, le contrôle d’accès en fonction du rôle (RBAC) et l’informatique confidentielle. Azure Database pour PostgreSQL prend en charge de nombreuses fonctionnalités similaires, telles que le chiffrement avec des clés gérées par le client, des certifications de conformité et la prise en charge de Microsoft Defender pour Cloud.

Sécurité des connexions entre vos machines virtuelles et vos bases de données

Lorsque vous intégrez une machine virtuelle à Azure Database pour PostgreSQL, il est essentiel qu’elles puissent se connecter l’une à l’autre d’une façon sécurisée afin de réduire le risque de perte de données.

L’authentification Microsoft Entra vous permet de vous connecter à Azure Database pour PostgreSQL sans mots de passe traditionnels. Au lieu de cela, vous utilisez des identités Microsoft Entra pour votre charge de travail d’application (c’est-à-dire des identités managées), des utilisateurs et des administrateurs via leurs comptes d’utilisateur Microsoft Entra. Cette approche atténue le risque de compromission des informations d’identification utilisées à long terme et celui de permettre à des acteurs malveillants d’accéder à vos données.

Microsoft Entra ID, les identités managées et le contrôle d’accès en fonction du rôle (RBAC) affiné peuvent permettre à votre charge de travail d’application d’accéder aux données et de gérer les ressources dans Azure de façon sécurisée, en suivant le principe des privilèges minimum.

Accès à un calcul hautes performances et économique dans plusieurs régions

Que vous ayez besoin d’un calcul économique pour le développement/test ou les types de calcul les plus récents, les plus performants ou les plus importants disponibles dans le cloud, Azure dispose d’une vaste sélection d’options de calcul pour les machines virtuelles et Azure Database pour PostgreSQL. Vous pouvez effectuer un scale-up et effectuer un scale-down de ces options en fonction des besoins, et elles sont disponibles dans plus de 60 régions dans Azure.

Vous pouvez mettre à l’échelle le calcul verticalement et horizontalement, notamment via des réplicas de base de données et desoptions distribuées telles qu’Azure Cosmos DB pour PostgreSQL. Azure Cosmos DB pour PostgreSQL est un service géré pour PostgreSQL étendu avec la superpuissance open source Citus des tables distribuées. Ce calcul est associé à certaines des options de stockage cloud les plus rapides pour adapter vos besoins en E/S de calcul et de stockage à votre charge de travail.

Gestion des coûts et rentabilité

Vous pouvez optimiser la gestion des coûts et la rentabilité du côté de Linux et de PostgreSQL. Si l’on compare avec des solutions locales, le coût peut souvent être plus adapté et approprié pour votre situation. Vous pouvez dimensionner correctement votre capacité de calcul par rapport à une solution locale. Vous pouvez également gérer facilement l’ensemble de votre flotte afin de l’optimiser avec seulement le calcul et le stockage dont vous avez besoin, et payer uniquement pour ce que vous utilisez dans un modèle de facturation à l’utilisation.

La facturation à l’utilisation permet aux clients de gérer des périodes de forte demande sans devoir payer le coût d’un surapprovisionnement. Elle permet une migration vers des générations de calcul plus efficaces et plus rapides dès qu’elles sont disponibles.

Les clients peuvent également tirer profit d’Azure Hybrid Benefit pour économiser sur les coûts de licences de distributions Linux spécifiques. Pour en savoir plus, consultez Azure Hybrid Benefit pour les machines virtuelles Red Hat Enterprise Linux (RHEL) et SUSE Linux Enterprise Server (SLES).

Les clients peuvent également réduire les coûts (jusqu’à 72 % par rapport à la tarification à l’utilisation) avec des durées d’une ou de trois années pour les machines virtuelles et Azure Reserved Virtual Machine Instances. Pour plus d’informations, consultez La façon dont la remise de réservation Azure est appliquée aux machines virtuelles. La tarification Azure est transparente et prévisible, et vous pouvez utiliser la calculatrice de prix Azure pour estimer vos coûts avant de déployer.

Opérations du jour 2

Les opérations de jour 2 pour les applications déployées (telles que le triage, la surveillance, la mise à jour corrective de sécurité, les sauvegardes et la récupération d’urgence) deviennent plus efficaces grâce à l’automatisation et à la possibilité de mettre à niveau avec un temps d’arrêt potentiellement nul. En outre, vous pouvez gérer votre infrastructure de bout en bout avec des chaînes d’outils standard du secteur d’activité.

Avant de commencer

Ce module est conçu pour vous aider à migrer une charge de travail Linux et PostgreSQL existante vers Azure. Cependant, l’accent n’est pas mis sur l’exportation des données à partir de votre base de données source ni sur la préparation de l’application pour la migration. La raison de cette approche est due au fait qu’il existe de nombreux types de bases de données sources et d’applications que vous pouvez migrer et que le processus pour chacun d’eux est spécifique.

Ce module vous fournit un exemple d’application, des données Postgres, des fichiers binaires et une infrastructure as code que vous pouvez utiliser pour simuler le processus de migration. Une fois la migration simulée effectuée, vous pouvez utiliser la connaissance acquise pour appliquer les mêmes principes à votre propre charge de travail.

Vous utilisez l’exemple d’application, Azure-Samples/tailwind-traders-go, en tant que remplaçant pour le code de l’application à migrer. L’infrastructure Bicep en tant que code, exemples de données Postgres et binaires, et d’autres ressources pour prendre en charge la partie pratique de ce module sont disponibles dans le référentiel GitHub Azure-Samples/linux-postgres-migration .

Pour appliquer cette approche à votre propre charge de travail, vous devez mapper votre application et vos données sources à la structure suivante.

Code de l’application

Vous devez stocker votre code d’application dans un contrôle de code source, de préférence un référentiel dans GitHub.

La migration dans ce module montre le scénario le plus simple de clonage du référentiel directement sur votre machine virtuelle Azure. Dans un scénario réel, vous allez probablement avoir un pipeline de déploiement plus complexe, comme GitHub Actions, qui génère et déploie votre code d’application sur vos ressources de calcul.

Données Postgres

Vous devez stocker vos données Postgres dans un fichier .sql que vous pouvez utiliser pour créer le schéma de base de données et insérer les données. Dans cette migration simulée, vous utilisez un exemple de fichier de données, tailwind.sql, dans le référentiel Azure-Samples/linux-postgres-migration. Vous copiez le fichier dans Stockage Blob Azure, puis vous l’importez dans Azure Database pour PostgreSQL.

Quand vous devez migrer vos propres données, vous les exportez à partir de votre base de données source et les enregistrer dans un fichier .sql. Vous copiez ensuite le fichier dans Stockage Blob, comme indiqué dans ce module.

Fichiers binaires

La plupart des applications ont d’autres fichiers binaires, comme des fichiers multimédias, qui doivent être migrés. Pour l’exemple d’application, vous découvrez comment migrer des images en les copiant à partir de Azure-Samples/linux-postgres-migration vers Stockage Blob.

De même, vous devez copier vos fichiers binaires dans Stockage Blob quand vous migrez votre propre charge de travail. Dans cette instance, le calcul est sans état et l’application a l’autorisation d’accéder aux données binaires directement dans le stockage Blob.

Infrastructure en tant que code (Infrastructure as Code) – Bicep

L’infrastructure as code pour ce module est également stockée dans Azure-Samples/linux-postgres-migration. Elle est conçue pour être une architecture de référence que vous pouvez utiliser telle quelle, avec un minimum de modifications, si vous pouvez rendre vos données et votre application sources conformes à la structure précédemment décrite.

La sécurité est un thème majeur de cette migration, et nous avons choisi certains paramètres de sécurité de façon à faciliter la réalisation de la partie pratique de ce module. Par exemple, Stockage Blob utilise une méthode d’authentification plus sécurisée et sans clés, mais nous autorisons des connexions réseau depuis n’importe quelle adresse IP. Dans un environnement de production, vous allez verrouiller l’accès réseau pour le limiter aux seules adresses IP qui ont besoin d’accéder au compte de stockage.

De même, nous conservons l’option d’ajouter une règle de pare-feu au serveur PostgreSQL afin d’autoriser une adresse IP spécifique. Dans un environnement de production, il est possible que vous désactiviez complètement l’ensemble de l’accès public au serveur.

Différences entre les environnements sources et Azure

Une des principales différences dans la migration d’un autre environnement vers Azure est que vous utilisez entièrement les contrôles de sécurité et d’identité fournis par Azure :

  • Vous utilisez des identités managées pour les machines virtuelles et Azure Database pour PostgreSQL.
  • Vous utilisez Microsoft Entra ID pour l’authentification à la base de données.
  • Vous utilisez Microsoft Entra ID, au lieu de clés SSH (Secure Shell), pour accéder aux machines virtuelles.

Au lieu d’effectuer une migration lift-and-shift, vous profitez de la possibilité de moderniser l’application afin de tirer pleinement parti des fonctionnalités de sécurité et de conformité fournies par Azure.

En local, vous pourrez peut-être utiliser un nom d’utilisateur et un mot de passe pour vous authentifier auprès de votre base de données. Dans Azure, nous présentons comment utiliser l’identité managée de la machine virtuelle pour l’authentification auprès de la base de données. Cette méthode d’authentification est plus sécurisée et réduit le risque de compromission des informations d’identification utilisées à long terme.

L’utilisation d’une identité managée pour l’authentification nécessite souvent des modifications de code dans votre application. Ce module montre comment utiliser la bibliothèque azidentity dans Go afin d’obtenir un jeton pour l’identité managée. La même bibliothèque est disponible dans nos Kits de développement logiciel (SDK) Microsoft.

Créer un compte Azure et installer Azure CLI

Si vous n’avez pas de compte Azure, vous pouvez créer un compte gratuit aujourd’hui. Vous obtenez des crédits que vous pouvez utiliser pour essayer des services Azure payants. Même une fois que vous avez utilisé les crédits, vous pouvez conserver le compte et utiliser les services Azure gratuits.

Pour exécuter les commandes des unités suivantes, vous devez avoir accès à un interpréteur de commandes Bash. Cet interpréteur de commandes peut se situer dans l’une de ces zones :

  • Sur votre ordinateur local. Par exemple, utilisez macOS, Linux, Sous-système Windows pour Linux (WSL) ou Docker.
  • Sur une machine virtuelle. Par exemple, utilisez Multipass ou Azure.
  • Dans le cloud. Par exemple, utilisez Azure Cloud Shell ou GitHub Codespaces.

Pour suivre ce module, vous avez besoin d’Azure CLI. Vous pouvez installer Azure CLI sur votre ordinateur local en suivant les instructions de l’article Installer Azure CLI . Vous devez également installer Git.

Ressources