Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Flux de travail de modernisation de SQL Server

Cette section décrit étape par étape le processus complet de modernisation de SQL Server à l'aide de AWS Transform.

Étape 1 : Création d'une tâche de modernisation de SQL Server

Commencez votre parcours de modernisation en créant une nouvelle tâche de transformation dans la console AWS Transform.

Étape 2 : Connexion à la base de données SQL Server

Connect AWS Transform à votre base de données SQL Server pour permettre l'analyse et la conversion des schémas.

Création d'un connecteur de base de données

Étape 3 : Connecter le référentiel de code source

AWS Transform a besoin d'accéder au code source de votre application .NET pour analyser et transformer le code qui interagit avec votre base de données SQL Server. AWS Transform prend en charge trois méthodes pour fournir du code source.

Choisissez votre méthode d'authentification

Configuration d'un connecteur PAT (recommandé)

Avec un connecteur PAT, vous créez un jeton d'accès personnel dans votre fournisseur de code source avec des autorisations personnalisées, vous le stockez en AWS Secrets Manager toute sécurité et AWS Transform le récupère en cas de besoin. Vous êtes responsable de la gestion du cycle de vie des jetons, y compris leur rotation et leur expiration. AWS Transform crée automatiquement le rôle IAM nécessaire avec les autorisations nécessaires pour accéder à votre secret.

Le connecteur PAT prend en charge les fournisseurs suivants, y compris les DNS/URL versions auto-hébergées et personnalisées :

Création d'un jeton d'accès personnel

Créez un PAT dans votre fournisseur de code source. Les autorisations requises varient d'un fournisseur à l'autre. Choisissez l'onglet correspondant à votre fournisseur.

GitHub

Accédez aux paramètres, aux paramètres du développeur, aux jetons d'accès personnels, aux Fine-grained jetons. Sélectionnez les référentiels à transformer et accordez les autorisations suivantes.

Autorisations du référentiel

Autorisations de l'organisation (obligatoires pour les référentiels de l'organisation)

GitLab

Accédez à Modifier le profil, Accédez aux jetons. Sélectionnez les étendues suivantes.

Bitbucket

Accédez aux paramètres du compte, à la sécurité, à la création et à la gestion des jetons d'API. Les étendues requises dépendent du type de jeton.

Workspace/Repository Jeton (ATCT — Auth du porteur, aucun nom d'utilisateur requis)

Jeton d'API de compte (ATAT — authentification de base avec e-mail) ou mot de passe d'application (ATBB — authentification de base avec nom d'utilisateur)

Azure DevOps

Accédez aux paramètres utilisateur, puis aux jetons d'accès personnels. Sélectionnez Étendue définie sur mesure. Pour l'étendue de l'organisation, choisissez Toutes les organisations accessibles (recommandé) ou spécifiez une seule organisation.

Stockez le PAT dans AWS Secrets Manager

Si vous utilisez une clé KMS gérée par le client pour chiffrer votre secret (au lieu de la clé AWS gérée par défaut), vous devez mettre à jour la politique relative aux clés KMS pour permettre à AWS Transform de déchiffrer le secret. Ajoutez la déclaration suivante à votre politique de clés KMS gérée par le client :

{
  "Sid": "Allow AWS Transform to decrypt secrets",
  "Effect": "Allow",
  "Principal": {
    "Service": "transform.amazonaws.com"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": "secretsmanager.REGION.amazonaws.com",
      "kms:EncryptionContext:SecretARN": "YOUR-SECRET-ARN"
    }
  }
}

REGIONRemplacez-le par votre AWS région (par exemple,us-east-1) et YOUR-SECRET-ARN par l'ARN de votre secret. Cette kms:ViaService condition garantit que la clé KMS ne peut être utilisée que via le AWS Secrets Manager service. La kms:EncryptionContext:SecretARN condition limite le déchiffrement à votre secret spécifique.

Pour mettre à jour votre politique relative aux clés KMS :

Configurez le AWS Transformez le travail

AWS Transform crée automatiquement un rôle IAM avec les autorisations requises pour accéder à votre secret.

Rotation et maintenance des jetons

Vous êtes responsable de la rotation des jetons PAT avant leur expiration. Pour faire pivoter un jeton :

Résoudre les problèmes liés au connecteur PAT

Configuration AWS CodeConnections

AWS CodeConnections utilise une intégration de fournisseur géré qui récupère automatiquement les informations d'identification OAuth temporaires via un flux d'autorisation OAuth 2.0. Les autorisations sont configurées dans l'application du fournisseur et entièrement gérées par AWS. Vous n'autorisez l'application qu'une seule fois et vous gérez l' AWS ensemble de la gestion des informations d'identification.

Sélectionnez votre dépôt et votre branche

Approbation de l'accès au référentiel

Pour GitHub certaines autres plateformes, l'administrateur du référentiel doit approuver la demande de connexion :

Étape 4 : créer un connecteur de déploiement (facultatif)

Si vous souhaitez déployer les applications transformées dans votre AWS compte, vous avez la possibilité de sélectionner un connecteur de déploiement.

Configurer le connecteur de déploiement

Approbation du connecteur de déploiement

L'administrateur de votre AWS compte doit approuver la demande de connexion pour le connecteur de déploiement.

Étape 5 : Confirmez vos ressources

Une fois connecté à votre base de données et à votre référentiel, AWS Transform vérifie que toutes les ressources requises sont accessibles et prêtes à être transformées.

Quoi AWS Transform vérifie

Consultez la liste de vérification avant le vol

Étape 6 : Découverte et évaluation

AWS Transform analyse votre base de données SQL Server et votre application .NET pour comprendre l'étendue et la complexité de la modernisation.

Ce qui est découvert

Processus de découverte

Examiner les résultats de découverte

Une fois la découverte terminée, accédez à Découverte et évaluation pour passer en revue :

Analyse de base de données :

Analyse des applications :

Carte des dépendances :

Comprendre l'évaluation de la complexité

AWS Transform classe votre modernisation en trois catégories :

Rapport d’évaluation

AWS Transform génère un rapport d'évaluation détaillé qui inclut :

Vous pouvez télécharger le rapport d'évaluation pour le consulter hors ligne et le partager avec les parties prenantes.

Étape 7 : Générer et revoir le plan de vague

Pour les grands parcs dotés de plusieurs bases de données et applications, AWS Transform génère un plan de vague qui organise la modernisation en groupes logiques.

Qu'est-ce qu'un plan de vagues ?

Un plan par vagues organise votre modernisation en phases (vagues) en fonction de :

Chaque vague contient un groupe de bases de données et d'applications qui peuvent être modernisées ensemble sans rompre les dépendances.

Passez en revue le plan des vagues

Personnalisez le plan de vagues

Vous pouvez personnaliser le plan de vague en fonction des besoins de votre entreprise de deux manières :

À l'aide de JSON :

En utilisant le chat :

Vous pouvez modifier les plans de vagues en discutant avec l'agent et en lui demandant de déplacer les référentiels et les bases de données vers des vagues spécifiques. Cette approche fonctionne bien si vous devez apporter des modifications mineures aux vagues.

Modernisation d'une seule base

Si vous modernisez une seule base de données et une seule application, AWS Transform crée un plan simple en une seule étape. Vous pouvez passer directement à la transformation sans planification des vagues.

Approuver le plan de vagues

Étape 8 : Conversion du schéma

AWS Transform convertit le schéma de votre base de données SQL Server en Aurora PostgreSQL, y compris les tables, les vues, les procédures stockées, les fonctions et les déclencheurs.

Comment fonctionne la conversion de schéma

AWS Transform utilise la conversion de schéma AWS DMS améliorée par l'IA générative pour :

Conversions prises en charge

Converti automatiquement :

Peut nécessiter un examen humain :

Non converti automatiquement :

Lancer la conversion du schéma

Consulter les résultats de conversion

Une fois la conversion terminée, accédez à Revoir la conversion du schéma :

Résumé de la conversion :

Révision par type d'objet :

Passer en revue les éléments d'action

Exemple : conversion de procédures stockées

Serveur SQL T-SQL :

CREATE PROCEDURE GetProductsByCategory
    @CategoryId INT,
    @PageSize INT = 10
AS
BEGIN
    SET NOCOUNT ON;
    
    SELECT TOP (@PageSize)
        ProductId,
        Name,
        Price,
        DATEDIFF(DAY, CreatedDate, GETUTCDATE()) AS DaysOld
    FROM Products
    WHERE CategoryId = @CategoryId
    ORDER BY Name
END

PostgreSQL PL/pgSQL converti :

CREATE OR REPLACE FUNCTION get_products_by_category(
    p_category_id INTEGER,
    p_page_size INTEGER DEFAULT 10
)
RETURNS TABLE (
    product_id INTEGER,
    name VARCHAR(255),
    price NUMERIC(18,2),
    days_old INTEGER
) AS $$
BEGIN
    RETURN QUERY
    SELECT 
        p.product_id,
        p.name,
        p.price,
        EXTRACT(DAY FROM (NOW() - p.created_date))::INTEGER AS days_old
    FROM products p
    WHERE p.category_id = p_category_id
    ORDER BY p.name
    LIMIT p_page_size;
END;
$$ LANGUAGE plpgsql;

Modifications apportées :

Approuver la conversion du schéma

Étape 9 : Migration des données (facultatif)

AWS Transform propose des options pour la migration des données de SQL Server vers Aurora PostgreSQL. La migration des données est facultative et peut être ignorée si vous n'avez besoin que de la transformation du schéma et du code.

Options de migration des données

Option 1 : migration des données de production

Migrez vos données de production réelles à l'aide du AWS DMS :

Option 2 : ignorer la migration des données

Transformez le schéma et le code uniquement :

Configuration de la migration des données

Processus de migration des données de production

Si vous choisissez de migrer les données de production :

Chronologie de la migration :

Validation des données

AWS Transform valide les données migrées à l'aide des contrôles suivants :

Étape 10 : Transformation du code d'application

AWS Transform transforme le code de votre application .NET pour qu'il fonctionne avec Aurora PostgreSQL plutôt qu'avec SQL Server. Il demande un nom de branche cible dans vos référentiels pour valider le code source transformé. Une fois que vous avez saisi le nom de la branche, AWS Transform crée une nouvelle branche et lance la transformation pour qu'elle corresponde à la base de données PostgreSQL.

Ce qui se transforme

Modifications du cadre d'entité :

ADO.NET Changements :

Changements de configuration :

Lancer la transformation du code

Étape 11 : Examiner les résultats de la transformation

Avant de procéder au déploiement, passez en revue les résultats complets de la transformation pour vous assurer que tout est prêt pour les tests.

Vous pouvez télécharger le code transformé depuis la branche du référentiel pour :

Vous pouvez également télécharger le résumé de la transformation pour passer en revue les modifications du langage naturel apportées par AWS Transform dans le cadre de la transformation.

Résumé de la transformation

Générer un rapport de transformation

AWS Transform génère un rapport de transformation complet :

Le rapport inclut :

Étape 12 : Validation et tests

Avant le déploiement en production, vérifiez que l'application transformée fonctionne correctement avec Aurora PostgreSQL.

Types de validation

Validation automatisée : AWS Transform effectue des contrôles automatisés :

Validation humaine : vous devez effectuer des tests supplémentaires :

Exécuter la validation automatique

Liste de contrôle pour les tests

Fonctionnalité de base de données :

Fonctionnalité de l'application :

Intégrité des données :

Rendement :

Étape 13 : Déploiement

Une fois la validation réussie, déployez votre application et votre base de données modernisées en production.

Options de déploiement

Pre-deployment liste de contrôle

Avant le déploiement en production :

Déploiement sur Amazon ECS

Surveiller le déploiement

AWS Transform déploie votre application :

Surveillez la progression du déploiement et vérifiez :

Post-deployment validation

Après le déploiement :

Test de fumée :

Surveillance des performances :

Validation utilisateur :

Procédures de rétrogradation

Si des problèmes surviennent après le déploiement :

Annulation immédiate :

Annulation partielle :

Correctif avancé :

Post-deployment optimisation

Après un déploiement réussi :

Réglage des performances :

Optimisation des coûts :

Configuration de la surveillance :

Documentation :