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. # Migration depuis Amazon SageMaker Studio Classic **Important** Les politiques IAM personnalisées qui permettent à Amazon SageMaker Studio ou Amazon SageMaker Studio Classic de créer des SageMaker ressources Amazon doivent également accorder des autorisations pour ajouter des balises à ces ressources. L’autorisation d’ajouter des balises aux ressources est requise, car Studio et Studio Classic balisent automatiquement toutes les ressources qu’ils créent. Si une politique IAM autorise Studio et Studio Classic à créer des ressources mais n'autorise pas le balisage, des erreurs « AccessDenied » peuvent se produire lors de la tentative de création de ressources. Pour de plus amples informations, veuillez consulter [Fournir des autorisations pour le balisage des ressources d' SageMaker IA](security_iam_id-based-policy-examples.md#grant-tagging-permissions). [AWS politiques gérées pour Amazon SageMaker AI](security-iam-awsmanpol.md)qui donnent des autorisations pour créer des SageMaker ressources incluent déjà des autorisations pour ajouter des balises lors de la création de ces ressources. Lorsque vous ouvrez Amazon SageMaker Studio, l'interface utilisateur Web est basée sur l'expérience par défaut choisie. Amazon SageMaker AI prend actuellement en charge deux expériences par défaut différentes : l'expérience Amazon SageMaker Studio et l'expérience Amazon SageMaker Studio Classic. Pour accéder aux dernières fonctionnalités d'Amazon SageMaker Studio, vous devez migrer les domaines existants depuis l'expérience Amazon SageMaker Studio Classic. Lorsque vous migrez votre expérience par défaut de Studio Classic vers Studio, vous ne perdez aucune fonctionnalité et vous pouvez toujours accéder à l’IDE Studio Classic dans Studio. Pour en savoir plus sur les avantages supplémentaires de l’expérience Studio, consultez [Amazon SageMaker Studio](studio-updated.md). **Note** Pour les clients existants qui ont créé leur compte avant le 30 novembre 2023, Studio Classic peut être l’expérience par défaut. Vous pouvez activer Studio comme expérience par défaut à l'aide de la AWS Command Line Interface (AWS CLI) ou de la console Amazon SageMaker AI. Pour plus d’informations sur Studio Classic, consultez [Amazon SageMaker Studio classique](studio.md). Pour les clients ayant créé leur compte après le 30 novembre 2023, nous recommandons d'utiliser Studio comme expérience par défaut, car il contient divers environnements de développement intégrés (IDEs), notamment l'IDE Studio Classic, et d'autres nouvelles fonctionnalités. JupyterLab 3 a atteint sa date de fin de maintenance le 15 mai 2024. Après le 31 décembre 2024, vous ne pourrez créer de nouveaux blocs-notes Studio Classic que sur JupyterLab 3 pour une période limitée. Cependant, après le 31 décembre 2024, l' SageMaker IA ne fournira plus de correctifs pour les problèmes critiques sur les ordinateurs portables Studio Classic sur JupyterLab 3. Nous vous recommandons de migrer vos charges de travail vers la nouvelle expérience Studio, qui prend en charge JupyterLab 4. + Si Studio est votre expérience par défaut, l’interface utilisateur est similaire aux images fournies dans [Présentation de l'interface utilisateur d'Amazon SageMaker Studio](studio-updated-ui.md). + Si Studio Classic est votre expérience par défaut, l’interface utilisateur est similaire aux images fournies dans [Présentation de l'interface utilisateur Amazon SageMaker Studio Classic](studio-ui.md). Pour effectuer la migration, vous devez mettre à jour un domaine existant. La migration d’un domaine existant de Studio Classic vers Studio nécessite trois phases distinctes : 1. **Migration de l’interface utilisateur de Studio Classic vers Studio** : tâche ponctuelle et peu exigeante qui nécessite la création d’un domaine de test pour s’assurer que Studio est conforme aux configurations réseau de votre organisation avant de migrer l’interface utilisateur du domaine existant de Studio Classic vers Studio. 1. **(Facultatif) Migration des images personnalisées et des scripts de configuration de cycle de vie** : tâche de taille moyenne visant à migrer vos images personnalisées et vos scripts LCC de Studio Classic vers Studio. 1. **(Facultatif) Migration des données de Studio Classic vers Studio** : tâche complexe qui requiert l’utilisation d’ AWS DataSync pour migrer les données du volume Amazon Elastic File System de Studio Classic vers un volume Amazon EFS ou Amazon Elastic Block Store cible. 1. **(Facultatif) Migrer les flux de données de Data Wrangler dans Studio Classic** : tâche unique et peu exigeante pour migrer vos flux de données de Data Wrangler dans Studio Classic vers Studio Classic, auquel vous pouvez ensuite accéder dans la dernière version de Studio via Canvas. SageMaker Pour de plus amples informations, veuillez consulter [Migration des flux de données depuis Data Wrangler](studio-updated-migrate-data.md#studio-updated-migrate-flows). Les rubriques suivantes montrent comment effectuer ces phases pour migrer un domaine existant de Studio Classic vers Studio. ## Migration automatique Entre juillet 2024 et août 2024, nous mettons automatiquement à niveau l’expérience de destination par défaut des utilisateurs vers la nouvelle expérience Studio. Cela remplace uniquement l’interface utilisateur de destination par défaut par l’interface utilisateur Studio mise à jour. L’application Studio Classic reste accessible depuis la nouvelle interface utilisateur de Studio. Pour vous assurer que la migration fonctionne correctement pour vos utilisateurs, consultez [Migration de l’interface utilisateur de Studio Classic vers Studio](studio-updated-migrate-ui.md). En particulier, veillez à ce que : + le rôle d’exécution du domaine dispose des autorisations appropriées ; + l’expérience de destination par défaut soit définie sur Studio ; + le réseau Amazon VPC du domaine, le cas échéant, soit configuré sur Studio à l’aide du point de terminaison de VPC Studio. Toutefois, si vous devez continuer à utiliser Studio Classic comme interface utilisateur par défaut pendant une durée limitée, définissez explicitement l’expérience de destination sur Studio Classic. Pour de plus amples informations, veuillez consulter [Définition de Studio Classic en tant qu’expérience par défaut](studio-updated-migrate-ui.md#studio-updated-migrate-revert). **Topics** + [ ## Migration automatique ](#studio-updated-migrate-auto) + [ # Conditions préalables requises complètes pour migrer l’expérience Studio ](studio-updated-migrate-prereq.md) + [ # Migration de l’interface utilisateur de Studio Classic vers Studio ](studio-updated-migrate-ui.md) + [ # (Facultatif) Migration d’images personnalisées et de configurations de cycle de vie ](studio-updated-migrate-lcc.md) + [ # (Facultatif) Migration des données de Studio Classic vers Studio ](studio-updated-migrate-data.md) # Conditions préalables requises complètes pour migrer l’expérience Studio La migration de l’expérience par défaut de Studio Classic vers Studio est gérée par l’administrateur du domaine existant. Si vous n’êtes pas autorisé à définir Studio comme expérience par défaut pour le domaine existant, contactez votre administrateur. Pour migrer votre expérience par défaut, vous devez disposer des autorisations d'administrateur ou au moins des autorisations nécessaires pour mettre à jour le domaine existant Gestion des identités et des accès AWS (IAM) et Amazon Simple Storage Service (Amazon S3). Remplissez les conditions préalables suivantes avant de migrer un domaine existant de Studio Classic vers Studio. + Le Gestion des identités et des accès AWS rôle utilisé pour effectuer la migration doit être associé à une politique comportant au moins les autorisations suivantes. Pour plus d’informations sur la création de politiques IAM, consultez [Création de politiques IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_create.html). **Note** La version de Studio inclut des mises à jour des politiques AWS gérées. Pour de plus amples informations, veuillez consulter [SageMaker Mises à jour des politiques AWS gérées par l'IA](security-iam-awsmanpol.md#security-iam-awsmanpol-updates). + Autorisations requises pour la phase 1 : + `iam:CreateServiceLinkedRole` + `iam:PassRole` + `sagemaker:DescribeDomain` + `sagemaker:UpdateDomain` + `sagemaker:CreateDomain` + `sagemaker:CreateUserProfile` + `sagemaker:ListApps` + `sagemaker:AddTags` + `sagemaker:DeleteApp` + `sagemaker:DeleteSpace` + `sagemaker:UpdateSpace` + `sagemaker:DeleteUserProfile` + `sagemaker:DeleteDomain` + `s3:PutBucketCORS` + Autorisations requises pour la phase 2 (facultatives, seulement si vous utilisez des scripts de configuration de cycle de vie) : Aucune autorisation supplémentaire n’est nécessaire. Si le domaine existant possède des configurations de cycle de vie et des images personnalisées, l’administrateur disposera déjà des autorisations requises. + Autorisations requises pour la phase 3 utilisant Amazon Elastic File System personnalisé (facultatives, seulement en cas de transfert de données) : + `efs:CreateFileSystem` + `efs:CreateMountTarget` + `efs:DescribeFileSystems` + `efs:DescribeMountTargets` + `efs:DescribeMountTargetSecurityGroups` + `efs:ModifyMountTargetSecurityGroups` + `ec2:DescribeSubnets` + `ec2:DescribeSecurityGroups` + `ec2:DescribeNetworkInterfaceAttribute` + `ec2:DescribeNetworkInterfaces` + `ec2:AuthorizeSecurityGroupEgress` + `ec2:AuthorizeSecurityGroupIngress` + `ec2:CreateNetworkInterface` + `ec2:CreateNetworkInterfacePermission` + `ec2:RevokeSecurityGroupIngress` + `ec2:RevokeSecurityGroupEgress` + `ec2:DeleteSecurityGroup` + `datasync:CreateLocationEfs` + `datasync:CreateTask` + `datasync:StartTaskExecution` + `datasync:DeleteTask` + `datasync:DeleteLocation` + `sagemaker:ListUserProfiles` + `sagemaker:DescribeUserProfile` + `sagemaker:UpdateDomain` + `sagemaker:UpdateUserProfile` + Autorisations requises pour la phase 3 utilisant Amazon Simple Storage Service (facultatives, seulement en cas de transfert de données) : + `iam:CreateRole` + `iam:GetRole` + `iam:AttachRolePolicy` + `iam:DetachRolePolicy` + `iam:DeleteRole` + `efs:DescribeFileSystems` + `efs:DescribeMountTargets` + `efs:DescribeMountTargetSecurityGroups` + `ec2:DescribeSubnets` + `ec2:CreateSecurityGroup` + `ec2:DescribeSecurityGroups` + `ec2:DescribeNetworkInterfaces` + `ec2:CreateNetworkInterface` + `ec2:CreateNetworkInterfacePermission` + `ec2:DetachNetworkInterfaces` + `ec2:DeleteNetworkInterface` + `ec2:DeleteNetworkInterfacePermission` + `ec2:CreateTags` + `ec2:AuthorizeSecurityGroupEgress` + `ec2:AuthorizeSecurityGroupIngress` + `ec2:RevokeSecurityGroupIngress` + `ec2:RevokeSecurityGroupEgress` + `ec2:DeleteSecurityGroup` + `datasync:CreateLocationEfs` + `datasync:CreateLocationS3` + `datasync:CreateTask` + `datasync:StartTaskExecution` + `datasync:DescribeTaskExecution` + `datasync:DeleteTask` + `datasync:DeleteLocation` + `sagemaker:CreateStudioLifecycleConfig` + `sagemaker:UpdateDomain` + `s3:ListBucket` + `s3:GetObject` + Accès aux AWS services depuis un environnement terminal sur : + Votre machine locale utilisant la AWS CLI version`2.13+`. Utilisez la commande suivante pour vérifier la AWS CLI version. ``` aws --version ``` + AWS CloudShell. Pour plus d'informations, voir [Qu'est-ce que c'est AWS CloudShell ?](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html) + Depuis votre ordinateur local ou AWS CloudShell exécutez la commande suivante et entrez vos informations AWS d'identification. Pour plus d'informations sur les AWS informations d'identification, voir [Comprendre et obtenir vos AWS informations d'identification](https://docs.aws.amazon.com/IAM/latest/UserGuide/security-creds.html). ``` aws configure ``` + Vérifiez que le processeur JSON léger est installé dans l'environnement du terminal. jq jqest nécessaire pour analyser les AWS CLI réponses. ``` jq --version ``` Si jq n’est pas installé, installez-le à l’aide d’une des commandes suivantes : + ``` sudo apt-get install -y jq ``` + ``` sudo yum install -y jq ``` # Migration de l’interface utilisateur de Studio Classic vers Studio La première phase de migration d'un domaine existant implique la migration de l'interface utilisateur d'Amazon SageMaker Studio Classic vers Amazon SageMaker Studio. Cette phase n’inclut pas la migration des données. Les utilisateurs peuvent continuer à utiliser leurs données de la même manière qu’avant la migration. Pour en savoir plus sur la migration des données, consultez [(Facultatif) Migration des données de Studio Classic vers Studio](studio-updated-migrate-data.md). La phase 1 comprend les étapes suivantes : 1. Mettez à jour les autorisations de création d’applications pour les nouvelles applications disponibles dans Studio. 1. Mettez à jour la configuration de VPC pour le domaine. 1. Mettez à niveau le domaine pour utiliser l’interface utilisateur de Studio. ## Conditions préalables Avant de suivre ces étapes, veillez à respecter les conditions préalables requises dans [Conditions préalables requises complètes pour migrer l’expérience Studio](studio-updated-migrate-prereq.md). ## Étape 1 : Mise à jour des autorisations de création d’applications Avant de migrer le domaine, mettez à jour le rôle d’exécution du domaine pour autoriser les utilisateurs à créer des applications. 1. Créez une Gestion des identités et des accès AWS politique avec l'un des contenus suivants en suivant les étapes de la section [Création de politiques IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_create.html) : + Utilisez la politique suivante pour accorder des autorisations pour tous les types d’applications et tous les espaces. **Note** Si le domaine utilise cette politique `SageMakerFullAccess`, il n’est pas nécessaire d’effectuer cette action. `SageMakerFullAccess` accorde les autorisations permettant de créer toutes les applications. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "SMStudioUserProfileAppPermissionsCreateAndDelete", "Effect": "Allow", "Action": [ "sagemaker:CreateApp", "sagemaker:DeleteApp" ], "Resource": "arn:aws:sagemaker:us-east-1:111122223333:app/*", "Condition": { "Null": { "sagemaker:OwnerUserProfileArn": "true" } } }, { "Sid": "SMStudioCreatePresignedDomainUrlForUserProfile", "Effect": "Allow", "Action": [ "sagemaker:CreatePresignedDomainUrl" ], "Resource": "arn:aws:sagemaker:us-east-1:111122223333:user-profile/${sagemaker:DomainId}/${sagemaker:UserProfileName}" }, { "Sid": "SMStudioAppPermissionsListAndDescribe", "Effect": "Allow", "Action": [ "sagemaker:ListApps", "sagemaker:ListDomains", "sagemaker:ListUserProfiles", "sagemaker:ListSpaces", "sagemaker:DescribeApp", "sagemaker:DescribeDomain", "sagemaker:DescribeUserProfile", "sagemaker:DescribeSpace" ], "Resource": "*" }, { "Sid": "SMStudioAppPermissionsTagOnCreate", "Effect": "Allow", "Action": [ "sagemaker:AddTags" ], "Resource": "arn:aws:sagemaker:us-east-1:111122223333:*/*", "Condition": { "Null": { "sagemaker:TaggingAction": "false" } } }, { "Sid": "SMStudioRestrictSharedSpacesWithoutOwners", "Effect": "Allow", "Action": [ "sagemaker:CreateSpace", "sagemaker:UpdateSpace", "sagemaker:DeleteSpace" ], "Resource": "arn:aws:sagemaker:us-east-1:111122223333:space/${sagemaker:DomainId}/*", "Condition": { "Null": { "sagemaker:OwnerUserProfileArn": "true" } } }, { "Sid": "SMStudioRestrictSpacesToOwnerUserProfile", "Effect": "Allow", "Action": [ "sagemaker:CreateSpace", "sagemaker:UpdateSpace", "sagemaker:DeleteSpace" ], "Resource": "arn:aws:sagemaker:us-east-1:111122223333:space/${sagemaker:DomainId}/*", "Condition": { "ArnLike": { "sagemaker:OwnerUserProfileArn": "arn:aws:sagemaker:us-east-1:111122223333:user-profile/${sagemaker:DomainId}/${sagemaker:UserProfileName}" }, "StringEquals": { "sagemaker:SpaceSharingType": [ "Private", "Shared" ] } } }, { "Sid": "SMStudioRestrictCreatePrivateSpaceAppsToOwnerUserProfile", "Effect": "Allow", "Action": [ "sagemaker:CreateApp", "sagemaker:DeleteApp" ], "Resource": "arn:aws:sagemaker:us-east-1:111122223333:app/${sagemaker:DomainId}/*", "Condition": { "ArnLike": { "sagemaker:OwnerUserProfileArn": "arn:aws:sagemaker:us-east-1:111122223333:user-profile/${sagemaker:DomainId}/${sagemaker:UserProfileName}" }, "StringEquals": { "sagemaker:SpaceSharingType": [ "Private" ] } } }, { "Sid": "AllowAppActionsForSharedSpaces", "Effect": "Allow", "Action": [ "sagemaker:CreateApp", "sagemaker:DeleteApp" ], "Resource": "arn:aws:sagemaker:*:*:app/${sagemaker:DomainId}/*/*/*", "Condition": { "StringEquals": { "sagemaker:SpaceSharingType": [ "Shared" ] } } } ] } ``` ------ + Comme Studio présente un ensemble étendu d’applications, les utilisateurs peuvent avoir accès à des applications qui n’étaient pas affichées auparavant. Les administrateurs peuvent limiter l'accès à ces applications par défaut en créant une politique Gestion des identités et des accès AWS (IAM) qui refuse des autorisations pour certaines applications à des utilisateurs spécifiques. **Note** Le type d’application peut être `jupyterlab` ou `codeeditor`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenySageMakerCreateAppForSpecificAppTypes", "Effect": "Deny", "Action": "sagemaker:CreateApp", "Resource": "arn:aws:sagemaker:us-east-1:111122223333:app/domain-id/*/app-type/*" } ] } ``` ------ 1. Attachez la politique au rôle d’exécution du domaine. Pour obtenir des instructions, suivez les étapes décrites dans [Ajout d’autorisations d’identité IAM (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console). ## Étape 2 : Mise à jour de la configuration de VPC Si vous utilisez votre domaine en mode `VPC-Only`, assurez-vous que la configuration de votre VPC répond aux exigences relatives à l’utilisation de Studio en mode `VPC-Only`. Pour de plus amples informations, veuillez consulter [Connect Amazon SageMaker Studio dans un VPC à des ressources externes](studio-updated-and-internet-access.md). ## Étape 3 : Mise à niveau vers l’interface utilisateur de Studio Avant de migrer votre domaine existant de Studio Classic vers Studio, nous vous recommandons de créer un domaine de test à l’aide de Studio avec les mêmes configurations que votre domaine existant. ### (Facultatif) Création d’un domaine de test Utilisez ce domaine de test pour interagir avec Studio, tester des configurations de mise en réseau et lancer des applications avant de migrer le domaine existant. 1. Obtenez l’ID de domaine de votre domaine existant. 1. Ouvrez la console Amazon SageMaker AI à l'adresse [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/). 1. Dans le panneau de navigation de gauche, développez **Configurations d’administrateur** et choisissez **Domaines**. 1. Choisissez le domaine existant. 1. Sur la page **Détails du domaine**, choisissez l’onglet **Paramètres du domaine**. 1. Copiez l’**ID de domaine**. 1. Ajoutez l’ID de domaine de votre domaine existant. ``` export REF_DOMAIN_ID="domain-id" export SM_REGION="region" ``` 1. Utilisez `describe-domain` pour obtenir des informations importantes sur le domaine existant. ``` export REF_EXECROLE=$(aws sagemaker describe-domain --region=$SM_REGION --domain-id=$REF_DOMAIN_ID | jq -r '.DefaultUserSettings.ExecutionRole') export REF_VPC=$(aws sagemaker describe-domain --region=$SM_REGION --domain-id=$REF_DOMAIN_ID | jq -r '.VpcId') export REF_SIDS=$(aws sagemaker describe-domain --region=$SM_REGION --domain-id=$REF_DOMAIN_ID | jq -r '.SubnetIds | join(",")') export REF_SGS=$(aws sagemaker describe-domain --region=$SM_REGION --domain-id=$REF_DOMAIN_ID | jq -r '.DefaultUserSettings.SecurityGroups | join(",")') export AUTHMODE=$(aws sagemaker describe-domain --region=$SM_REGION --domain-id=$REF_DOMAIN_ID | jq -r '.AuthMode') ``` 1. Validez les paramètres. ``` echo "Execution Role: $REF_EXECROLE || VPCID: $REF_VPC || SubnetIDs: $REF_SIDS || Security GroupIDs: $REF_SGS || AuthMode: $AUTHMODE" ``` 1. Créez un domaine de test en utilisant les configurations du domaine existant. ``` IFS=',' read -r -a subnet_ids <<< "$REF_SIDS" IFS=',' read -r -a security_groups <<< "$REF_SGS" security_groups_json=$(printf '%s\n' "${security_groups[@]}" | jq -R . | jq -s .) aws sagemaker create-domain \ --domain-name "TestV2Config" \ --vpc-id $REF_VPC \ --auth-mode $AUTHMODE \ --subnet-ids "${subnet_ids[@]}" \ --app-network-access-type VpcOnly \ --default-user-settings " { \"ExecutionRole\": \"$REF_EXECROLE\", \"StudioWebPortal\": \"ENABLED\", \"DefaultLandingUri\": \"studio::\", \"SecurityGroups\": $security_groups_json } " ``` 1. Une fois le domaine de test `In Service`, utilisez l’ID du domaine de test pour créer un profil utilisateur. Ce profil utilisateur est utilisé pour lancer et tester des applications. ``` aws sagemaker create-user-profile \ --region="$SM_REGION" --domain-id=test-domain-id \ --user-profile-name test-network-user ``` #### Test des fonctionnalités de Studio Lancez le domaine de test à l’aide du profil utilisateur `test-network-user`. Nous vous suggérons de tester minutieusement l’interface utilisateur de Studio et de créer des applications pour tester les fonctionnalités de Studio en mode `VPCOnly`. Testez les flux de travail suivants : + Créez un nouvel JupyterLab espace, un nouvel environnement de test et une nouvelle connectivité. + Créez un nouvel éditeur de code basé sur Code-OSS, Visual Studio Code – Open Source Space, un nouvel environnement de test et une nouvelle connectivité. + Lancez une nouvelle application Studio Classic, un nouvel environnement de test et une nouvelle connectivité. + Testez la connectivité d’Amazon Simple Storage Service en testant les actions de lecture et d’écriture. Si ces tests sont réussis, mettez à niveau le domaine existant. Si vous rencontrez des échecs, nous vous recommandons de résoudre les problèmes d’environnement et de connectivité avant de mettre à jour le domaine existant. #### Nettoyage des ressources du domaine de test Après avoir migré le domaine existant, nettoyez les ressources du domaine de test. 1. Ajoutez l’ID du domaine de test. ``` export TEST_DOMAIN="test-domain-id" export SM_REGION="region" ``` 1. Répertoriez toutes les applications figurant dans le domaine qui sont en cours d’exécution. ``` active_apps_json=$(aws sagemaker list-apps --region=$SM_REGION --domain-id=$TEST_DOMAIN) echo $active_apps_json ``` 1. Analysez la liste JSON des applications en cours d’exécution et supprimez-les. Si les utilisateurs ont tenté de créer une application pour laquelle ils n’ont pas d’autorisations, il est possible que certains espaces ne soient pas capturés dans le script suivant. Vous devez supprimer manuellement ces espaces. ``` echo "$active_apps_json" | jq -c '.Apps[]' | while read -r app; do if echo "$app" | jq -e '. | has("SpaceName")' > /dev/null; then app_type=$(echo "$app" | jq -r '.AppType') app_name=$(echo "$app" | jq -r '.AppName') domain_id=$(echo "$app" | jq -r '.DomainId') space_name=$(echo "$app" | jq -r '.SpaceName') echo "Deleting App - AppType: $app_type || AppName: $app_name || DomainId: $domain_id || SpaceName: $space_name" aws sagemaker delete-app --region=$SM_REGION --domain-id=$domain_id \ --app-type $app_type --app-name $app_name --space-name $space_name echo "Deleting Space - AppType: $app_type || AppName: $app_name || DomainId: $domain_id || SpaceName: $space_name" aws sagemaker delete-space --region=$SM_REGION --domain-id=$domain_id \ --space-name $space_name else app_type=$(echo "$app" | jq -r '.AppType') app_name=$(echo "$app" | jq -r '.AppName') domain_id=$(echo "$app" | jq -r '.DomainId') user_profile_name=$(echo "$app" | jq -r '.UserProfileName') echo "Deleting Studio Classic - AppType: $app_type || AppName: $app_name || DomainId: $domain_id || UserProfileName: $user_profile_name" aws sagemaker delete-app --region=$SM_REGION --domain-id=$domain_id \ --app-type $app_type --app-name $app_name --user-profile-name $user_profile_name fi done ``` 1. Supprimez le profil utilisateur de test. ``` aws sagemaker delete-user-profile \ --region=$SM_REGION --domain-id=$TEST_DOMAIN \ --user-profile-name "test-network-user" ``` 1. Supprimez le domaine de test. ``` aws sagemaker delete-domain \ --region=$SM_REGION --domain-id=$TEST_DOMAIN ``` Après avoir testé les fonctionnalités de Studio avec les configurations de votre domaine de test, migrez le domaine existant. Lorsque Studio est l’expérience par défaut pour un domaine, Studio est l’expérience par défaut pour tous les utilisateurs de ce domaine. Toutefois, les paramètres de l’utilisateur ont priorité sur les paramètres du domaine. Par conséquent, si l’expérience par défaut d’un utilisateur est définie sur Studio Classic dans ses paramètres utilisateur, cet utilisateur aura Studio Classic comme expérience par défaut. Vous pouvez migrer le domaine existant en le mettant à jour depuis la console SageMaker AI AWS CLI, le ou AWS CloudFormation. Choisissez l’un des onglets suivants pour afficher les instructions appropriées. ### Définissez Studio comme expérience par défaut pour le domaine existant à l'aide de la console SageMaker AI Vous pouvez définir Studio comme expérience par défaut pour le domaine existant à l'aide de la console SageMaker AI. 1. Ouvrez la console Amazon SageMaker AI à l'adresse [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/). 1. Dans le panneau de navigation de gauche, développez **Configurations d’administrateur** et choisissez **Domaines**. 1. Choisissez le domaine existant pour lequel vous souhaitez activer Studio comme expérience par défaut. 1. Sur la page **Détails du domaine**, développez **Activer le nouveau Studio**. 1. (Facultatif) Pour afficher les détails des étapes nécessaires à l’activation de Studio comme expérience par défaut, choisissez **Afficher les détails**. La page affiche les éléments suivants. + Dans la section **Présentation de SageMaker Studio**, vous pouvez voir les applications incluses ou disponibles dans l'interface Web de Studio. + Dans la section **Processus d’habilitation**, vous pouvez consulter les descriptions des tâches de flux de travail permettant d’activer Studio. **Note** Vous devrez migrer vos données manuellement. Pour obtenir des instructions sur la migration de vos données, consultez [(Facultatif) Migration des données de Studio Classic vers Studio](studio-updated-migrate-data.md). + Dans la section **Rétablir l’expérience Studio Classic**, vous pouvez voir comment revenir à Studio Classic après avoir activé Studio comme expérience par défaut. 1. Pour commencer le processus d’activation de Studio comme expérience par défaut, choisissez **Activer le nouveau Studio**. 1. Dans la section **Spécifier et configurer le rôle**, vous pouvez consulter les applications par défaut qui sont automatiquement incluses dans Studio. Pour empêcher les utilisateurs d’exécuter ces applications, choisissez le rôle Gestion des identités et des accès AWS (IAM) dont la politique IAM refuse l’accès. Pour en savoir plus sur la façon de créer une stratégie pour limiter l’accès, consultez [Étape 1 : Mise à jour des autorisations de création d’applications](#studio-updated-migrate-limit-apps). 1. Dans la section **Choisir le compartiment S3 par défaut pour attacher la politique CORS**, vous pouvez autoriser Studio à accéder aux compartiments Amazon S3. Le compartiment Amazon S3 par défaut, dans ce cas, est le compartiment Amazon S3 par défaut pour votre environnement Studio Classic. Dans cette étape, vous pouvez effectuer les opérations suivantes : + Vérifiez le compartiment Amazon S3 par défaut du domaine auquel attacher la politique CORS. Si votre domaine ne possède pas de compartiment Amazon S3 par défaut, SageMaker AI crée un compartiment Amazon S3 auquel est attachée la politique CORS appropriée. + Vous pouvez inclure 10 compartiments Amazon S3 supplémentaires auxquels attacher la politique CORS. Si vous souhaitez inclure plus de 10 compartiments, vous pouvez les ajouter manuellement. Pour plus d’informations sur la façon d’attacher manuellement la politique CORS à vos compartiments Amazon S3, consultez [(Facultatif) Mise à jour de votre politique CORS pour accéder aux compartiments Amazon S3](#studio-updated-migrate-cors). Pour continuer, cochez la case à côté de **Acceptez-vous de remplacer toute politique CORS existante sur les compartiments Amazon S3 sélectionnés ?** 1. La section **Migrer les données** contient des informations sur les différents volumes de stockage de données pour Studio Classic et Studio. Vos données ne seront pas migrées automatiquement via ce processus. Pour obtenir des instructions sur la migration de vos données, les configurations du cycle de vie et les JupyterLab extensions, consultez[(Facultatif) Migration des données de Studio Classic vers Studio](studio-updated-migrate-data.md). 1. Une fois que vous avez terminé les tâches de la page et vérifié votre configuration, choisissez **Activer le nouveau Studio**. ### Définissez Studio comme expérience par défaut pour le domaine existant à l'aide du AWS CLI Pour définir Studio comme expérience par défaut pour le domaine existant à l’aide de l’ AWS CLI, utilisez l’appel [update-domain](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sagemaker/update-domain.html). Vous devez définir `ENABLED` comme valeur pour `StudioWebPortal` et définir `studio::` comme valeur pour `DefaultLandingUri` dans le cadre du paramètre `default-user-settings`.  `StudioWebPortal` indique si l’expérience Studio est l’expérience par défaut et `DefaultLandingUri` indique l’expérience par défaut vers laquelle l’utilisateur est dirigé lorsqu’il accède au domaine. Dans cet exemple, la définition de ces valeurs au niveau du domaine (dans `default-user-settings`) fait de Studio l’expérience par défaut pour les utilisateurs du domaine. Si un utilisateur du domaine a le paramètre `StudioWebPortal` défini sur `DISABLED` et le paramètre `DefaultLandingUri` défini sur `app:JupyterServer:` au niveau de l’utilisateur (dans `UserSettings`), cela a priorité sur les paramètres du domaine. En d’autres termes, cet utilisateur aura Studio Classic comme expérience par défaut, quels que soient les paramètres du domaine. L’exemple de code suivant montre comment définir Studio en tant qu’expérience par défaut pour les utilisateurs du domaine : ``` aws sagemaker update-domain \ --domain-id existing-domain-id \ --region Région AWS \ --default-user-settings ' { "StudioWebPortal": "ENABLED", "DefaultLandingUri": "studio::" } ' ``` + Pour obtenir votre `existing-domain-id`, utilisez les instructions suivantes : **Pour obtenir `existing-domain-id`** 1. Ouvrez la console Amazon SageMaker AI à l'adresse [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/). 1. Dans le panneau de navigation de gauche, développez **Configurations d’administrateur** et choisissez **Domaines**. 1. Choisissez le domaine existant. 1. Sur la page **Détails du domaine**, choisissez l’onglet **Paramètres du domaine**. 1. Copiez l’**ID de domaine**. + Pour vous assurer que vous utilisez le bon nom Région AWS de domaine, suivez les instructions suivantes : **Pour obtenir `Région AWS`** 1. Ouvrez la console Amazon SageMaker AI à l'adresse [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/). 1. Dans le panneau de navigation de gauche, développez **Configurations d’administrateur** et choisissez **Domaines**. 1. Choisissez le domaine existant. 1. Sur la page **Détails du domaine**, vérifiez qu’il s’agit du domaine existant. 1. Développez la liste Région AWS déroulante en haut à droite de la console SageMaker AI et utilisez l' Région AWS identifiant correspondant à droite de votre Région AWS nom. Par exemple, `us-west-1`. Après avoir migré votre expérience par défaut vers Studio, vous pouvez autoriser Studio à accéder aux compartiments Amazon S3. Par exemple, vous pouvez inclure l’accès à votre compartiment Amazon S3 par défaut de Studio Classic et à des compartiments Amazon S3 supplémentaires. Pour ce faire, vous devez attacher manuellement une configuration CORS ([Cross-Origin Resource Sharing](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)) aux compartiments Amazon S3. Pour plus d’informations sur la façon d’attacher manuellement la politique CORS à vos compartiments Amazon S3, consultez [(Facultatif) Mise à jour de votre politique CORS pour accéder aux compartiments Amazon S3](#studio-updated-migrate-cors). De même, vous pouvez définir Studio comme expérience par défaut lorsque vous créez un domaine à l' AWS CLI aide de l'appel [create-domain](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sagemaker/create-domain.html).  ### Définissez Studio comme expérience par défaut pour le domaine existant à l'aide du AWS CloudFormation Vous pouvez définir l’expérience par défaut lors de la création d’un domaine à l’aide d’ AWS CloudFormation. Pour un modèle de CloudFormation migration, consultez la section [Modèles iAc de SageMaker Studio Administrator](https://github.com/aws-samples/sagemaker-studio-admin-iac-templates/tree/main?tab=readme-ov-file#phase-1-migration). Pour plus d'informations sur la création d'un domaine à l'aide de CloudFormation, consultez [Création d'un domaine Amazon SageMaker AI à l'aide](https://github.com/aws-samples/cloudformation-studio-domain?tab=readme-ov-file#creating-sagemaker-studio-domains-using-cloudformation) de CloudFormation. Pour plus d'informations sur la ressource de domaine prise en charge par AWS CloudFormation, voir [AWS: : SageMaker AI : :Domain](https://docs.aws.amazon.com//AWSCloudFormation/latest/UserGuide/aws-resource-sagemaker-domain.html#cfn-sagemaker-domain-defaultusersettings). Après avoir migré votre expérience par défaut vers Studio, vous pouvez autoriser Studio à accéder aux compartiments Amazon S3. Par exemple, vous pouvez inclure l’accès à votre compartiment Amazon S3 par défaut de Studio Classic et à des compartiments Amazon S3 supplémentaires. Pour ce faire, vous devez attacher manuellement une configuration CORS ([Cross-Origin Resource Sharing](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)) aux compartiments Amazon S3. Pour en savoir plus sur la façon d’attacher manuellement la politique CORS à vos compartiments Amazon S3, consultez [(Facultatif) Mise à jour de votre politique CORS pour accéder aux compartiments Amazon S3](#studio-updated-migrate-cors). ### (Facultatif) Mise à jour de votre politique CORS pour accéder aux compartiments Amazon S3 Dans Studio Classic, les utilisateurs peuvent créer, répertorier et charger des fichiers dans des compartiments Amazon Simple Storage Service (Amazon S3). Pour prendre en charge la même expérience dans Studio, les administrateurs doivent attacher une configuration CORS ([Cross-Origin Resource Sharing](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)) aux compartiments Amazon S3. Cela est nécessaire, car Studio passe des appels Amazon S3 depuis le navigateur Internet. Le navigateur invoque CORS au nom des utilisateurs. Par conséquent, toutes les demandes adressées aux compartiments Amazon S3 échouent, sauf si la politique CORS est attachée aux compartiments Amazon S3. Vous devrez peut-être attacher manuellement la politique CORS aux compartiments Amazon S3 pour les raisons suivantes. + S’il existe déjà un compartiment par défaut Amazon S3 auquel n’est pas attachée la bonne politique CORS lorsque vous migrez l’expérience par défaut du domaine existant vers Studio. + Si vous utilisez le AWS CLI pour migrer l'expérience par défaut du domaine existant vers Studio. Pour plus d'informations sur l'utilisation du AWS CLI pour effectuer la migration, consultez[Définissez Studio comme expérience par défaut pour le domaine existant à l'aide du AWS CLI](#studio-updated-migrate-set-studio-updated-cli). + Si vous souhaitez attacher la politique CORS à d’autres compartiments Amazon S3. **Note** Si vous prévoyez d'utiliser la console SageMaker AI pour activer Studio comme expérience par défaut, les politiques CORS existantes des compartiments Amazon S3 auxquels vous associez la politique CORS seront annulées lors de la migration. Pour cette raison, vous pouvez ignorer les instructions manuelles suivantes. Toutefois, si vous avez déjà utilisé la console SageMaker AI pour effectuer la migration et que vous souhaitez inclure d'autres compartiments Amazon S3 auxquels associer la politique CORS, suivez les instructions manuelles suivantes. La procédure suivante montre comment ajouter manuellement une configuration CORS à un compartiment Amazon S3. **Pour ajouter une configuration CORS à un compartiment Amazon S3** 1. Vérifiez qu'il existe un compartiment Amazon S3 Région AWS identique au domaine existant portant le nom suivant. Pour obtenir des instructions, consultez [Visualisation des propriétés d’un compartiment Amazon S3](https://docs.aws.amazon.com//AmazonS3/latest/userguide/view-bucket-properties.html). ``` sagemaker-region-account-id ``` 1. Ajoutez une configuration CORS avec le contenu suivant au compartiment Amazon S3 par défaut. Pour obtenir des instructions, consultez [Configuration du partage des ressources entre origines multiples (CORS)](https://docs.aws.amazon.com//AmazonS3/latest/userguide/enabling-cors-examples.html). ``` [ { "AllowedHeaders": [ "*" ], "AllowedMethods": [ "POST", "PUT", "GET", "HEAD", "DELETE" ], "AllowedOrigins": [ "https://*.sagemaker.aws" ], "ExposeHeaders": [ "ETag", "x-amz-delete-marker", "x-amz-id-2", "x-amz-request-id", "x-amz-server-side-encryption", "x-amz-version-id" ] } ] ``` ### (Facultatif) Migrer de Data Wrangler dans Studio Classic vers Canvas SageMaker Amazon SageMaker Data Wrangler existe en tant que fonctionnalité autonome dans l'expérience Studio Classic. Lorsque vous activez Studio comme expérience par défaut, utilisez l'application [Amazon SageMaker Canvas](https://docs.aws.amazon.com/sagemaker/latest/dg/canvas.html) pour accéder à la fonctionnalité Data Wrangler. SageMaker Canvas est une application dans laquelle vous pouvez entraîner et déployer des modèles d'apprentissage automatique sans écrire de code, et Canvas fournit des fonctionnalités de préparation des données optimisées par Data Wrangler. La nouvelle expérience Studio ne prend pas en charge l’interface utilisateur classique de Data Wrangler, et vous devez créer une application Canvas si vous souhaitez continuer à utiliser Data Wrangler. Vous devez toutefois posséder les autorisations nécessaires pour créer et utiliser des applications Canvas. Procédez comme suit pour associer les politiques d'autorisation nécessaires au rôle AWS IAM de votre domaine SageMaker AI ou de votre utilisateur. **Pour accorder des autorisations pour les fonctionnalités de Data Wrangler dans Canvas** 1. Associez la politique AWS gérée [AmazonSageMakerFullAccess](https://docs.aws.amazon.com/sagemaker/latest/dg/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonSageMakerFullAccess)au rôle IAM de votre utilisateur. Pour une procédure expliquant comment attacher des politiques IAM à un rôle, consultez [Ajout des autorisations d’identité IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console) dans le *Guide de l’utilisateur AWS IAM*. Si cette politique d’autorisation est trop permissive pour votre cas d’utilisation, vous pouvez créer des politiques délimitées qui incluent au moins les autorisations suivantes : ``` { "Sid": "AllowStudioActions", "Effect": "Allow", "Action": [ "sagemaker:CreatePresignedDomainUrl", "sagemaker:DescribeDomain", "sagemaker:ListDomains", "sagemaker:DescribeUserProfile", "sagemaker:ListUserProfiles", "sagemaker:DescribeSpace", "sagemaker:ListSpaces", "sagemaker:DescribeApp", "sagemaker:ListApps" ], "Resource": "*" }, { "Sid": "AllowAppActionsForUserProfile", "Effect": "Allow", "Action": [ "sagemaker:CreateApp", "sagemaker:DeleteApp" ], "Resource": "arn:aws:sagemaker:region:account-id:app/domain-id/user-profile-name/canvas/*", "Condition": { "Null": { "sagemaker:OwnerUserProfileArn": "true" } } } ``` 1. Associez la politique AWS gérée [AmazonSageMakerCanvasDataPrepFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerCanvasDataPrepFullAccess.html)au rôle IAM de votre utilisateur. Après avoir attaché les autorisations nécessaires, vous pouvez créer une application Canvas et vous connecter. Pour de plus amples informations, veuillez consulter [Commencer à utiliser Amazon SageMaker Canvas](canvas-getting-started.md). Lorsque vous êtes connecté à Canvas, vous pouvez accéder directement à Data Wrangler et commencer à créer des flux de données. Pour plus d’informations, consultez [Préparation des données](canvas-data-prep.md) dans la documentation de Canvas. ### (Facultatif) Migrer du pilote automatique dans Studio Classic vers Canvas SageMaker [Amazon SageMaker Autopilot](https://docs.aws.amazon.com/sagemaker/AWSIronmanApiDoc/integ/npepin-studio-migration-autopilot-to-canvas/latest/dg/autopilot-automate-model-development.html) existe en tant que fonctionnalité propre à l'expérience Studio Classic. Lorsque vous passez à l'expérience Studio mise à jour, utilisez l'application [Amazon SageMaker Canvas](https://docs.aws.amazon.com/sagemaker/latest/dg/canvas.html) pour continuer à utiliser les mêmes fonctionnalités d'apprentissage automatique (AutoML) via une interface utilisateur (UI). SageMaker Canvas est une application dans laquelle vous pouvez entraîner et déployer des modèles d'apprentissage automatique sans écrire de code, et Canvas fournit une interface utilisateur pour exécuter vos tâches AutoML. La nouvelle expérience Studio ne prend pas en charge l’interface utilisateur classique d’Autopilot. Vous devez créer une application Canvas si vous souhaitez continuer à utiliser les fonctionnalités AutoML d’Autopilot via une interface utilisateur. Vous devez toutefois posséder les autorisations nécessaires pour créer et utiliser des applications Canvas. + Si vous accédez à SageMaker Canvas depuis Studio, ajoutez ces autorisations au rôle d'exécution de votre domaine SageMaker AI ou de votre profil utilisateur. + Si vous accédez à SageMaker Canvas depuis la console, ajoutez ces autorisations au rôle AWS IAM de votre utilisateur. + Si vous accédez à SageMaker Canvas via une [URL présignée](https://docs.aws.amazon.com/sagemaker/latest/dg/setting-up-canvas-sso.html#canvas-optional-access), ajoutez ces autorisations au rôle IAM que vous utilisez pour accéder à Okta SSO. Pour activer les fonctionnalités AutoML dans Canvas, ajoutez les politiques suivantes à votre rôle d’exécution ou à votre rôle d’utilisateur IAM. + AWS politique gérée : [`CanvasFullAccess`.](https://docs.aws.amazon.com/sagemaker/latest/dg/security-iam-awsmanpol-canvas.html#security-iam-awsmanpol-AmazonSageMakerCanvasFullAccess) + Politique en ligne : ``` { "Sid": "AllowAppActionsForUserProfile", "Effect": "Allow", "Action": [ "sagemaker:CreateApp", "sagemaker:DeleteApp" ], "Resource": "arn:aws:sagemaker:region:account-id:app/domain-id/user-profile-name/canvas/*", "Condition": { "Null": { "sagemaker:OwnerUserProfileArn": "true" } } } ``` **Pour attacher des politiques IAM à un rôle d’exécution** 1. **Trouvez le rôle d'exécution associé à votre profil utilisateur SageMaker AI** 1. Dans la console SageMaker AI[https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/), accédez à **Domains**, puis choisissez votre domaine SageMaker AI. 1. L’ARN du rôle d’exécution est répertorié sous *Rôle d’exécution* sur la page **Détails de l’utilisateur** de votre profil utilisateur. Notez le nom du rôle d’exécution dans l’ARN. 1. Dans la console IAM [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/), sélectionnez **Rôles**. 1. Recherchez votre rôle par nom dans le champ de recherche. 1. Sélectionnez le rôle. 1. Ajoutez des politiques au rôle 1. Dans la console IAM [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/), sélectionnez **Rôles**. 1. Recherchez votre rôle par nom dans le champ de recherche. 1. Sélectionnez le rôle. 1. Dans l’onglet **Autorisations**, accédez au menu déroulant **Ajouter des autorisations**. 1. + Pour les politiques gérées : sélectionnez **Attacher des politiques**, recherchez le nom de la politique gérée que vous souhaitez attacher. Sélectionnez la politique, puis choisissez **Ajouter des autorisations**. + Pour les politiques intégrées : sélectionnez **Créer une politique en ligne**, collez votre politique dans l’onglet JSON, choisissez Suivant, nommez votre politique, puis choisissez **Créer**. Pour une procédure expliquant comment attacher des politiques IAM à un rôle, consultez [Ajout des autorisations d’identité IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console) dans le *Guide de l’utilisateur AWS IAM*. Après avoir attaché les autorisations nécessaires, vous pouvez créer une application Canvas et vous connecter. Pour de plus amples informations, veuillez consulter [Commencer à utiliser Amazon SageMaker Canvas](canvas-getting-started.md). ## Définition de Studio Classic en tant qu’expérience par défaut Les administrateurs peuvent revenir à Studio Classic en tant qu’expérience par défaut pour un domaine existant. Vous pouvez le faire via l’ AWS CLI. **Note** Lorsque Studio Classic est défini en tant qu’expérience par défaut au niveau d’un domaine, Studio Classic est l’expérience par défaut pour tous les utilisateurs de ce domaine. Toutefois, les paramètres au niveau de l’utilisateur ont priorité sur les paramètres au niveau du domaine. Ainsi, si l’expérience par défaut d’un utilisateur est définie sur Studio, cet utilisateur aura Studio comme expérience par défaut. Pour revenir à Studio Classic comme expérience par défaut pour le domaine existant à l'aide du AWS CLI, utilisez l'appel [update-domain](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sagemaker/update-domain.html). Dans le cadre du champ `default-user-settings`, vous devez définir : + la valeur `StudioWebPortal` sur `DISABLED` ; + la valeur `DefaultLandingUri` sur `app:JupyterServer:`. `StudioWebPortal` indique si l’expérience Studio est l’expérience par défaut et `DefaultLandingUri` indique l’expérience par défaut vers laquelle l’utilisateur est dirigé lorsqu’il accède au domaine. Dans cet exemple, la définition de ces valeurs au niveau du domaine (dans `default-user-settings`) fait de Studio Classic l’expérience par défaut pour les utilisateurs du domaine. Si un utilisateur du domaine a le paramètre `StudioWebPortal` défini sur `ENABLED` et le paramètre `DefaultLandingUri` défini sur `studio::` au niveau de l’utilisateur (dans `UserSettings`), cela a priorité sur les paramètres au niveau du domaine. En d’autres termes, cet utilisateur aura Studio comme expérience par défaut, quels que soient les paramètres au niveau du domaine. L’exemple de code suivant montre comment définir Studio Classic en tant qu’expérience par défaut pour les utilisateurs du domaine : ``` aws sagemaker update-domain \ --domain-id existing-domain-id \ --region Région AWS \ --default-user-settings ' { "StudioWebPortal": "DISABLED", "DefaultLandingUri": "app:JupyterServer:" } ' ``` Appliquez les instructions suivantes pour obtenir votre `existing-domain-id`. 1. Ouvrez la console Amazon SageMaker AI à l'adresse [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/). 1. Dans le panneau de navigation de gauche, développez **Configurations d’administrateur** et choisissez **Domaines**. 1. Choisissez le domaine existant. 1. Sur la page **Détails du domaine**, choisissez l’onglet **Paramètres du domaine**. 1. Copiez l’**ID de domaine**. Pour obtenir votre`Région AWS`, suivez les instructions suivantes afin de vous assurer que vous utilisez le bon nom Région AWS de domaine. 1. Ouvrez la console Amazon SageMaker AI à l'adresse [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/). 1. Dans le panneau de navigation de gauche, développez **Configurations d’administrateur** et choisissez **Domaines**. 1. Choisissez le domaine existant. 1. Sur la page **Détails du domaine**, vérifiez qu’il s’agit du domaine existant. 1. Développez la liste Région AWS déroulante en haut à droite de la console SageMaker AI et utilisez l' Région AWS identifiant correspondant à droite de votre Région AWS nom. Par exemple, `us-west-1`. # (Facultatif) Migration d’images personnalisées et de configurations de cycle de vie Vous devez mettre à jour vos images personnalisées et vos scripts de configuration du cycle de vie (LCC) pour qu'ils fonctionnent avec le modèle d'exécution local simplifié d'Amazon SageMaker Studio. Si vous n’avez pas créé d’images personnalisées ou de configurations de cycle de vie dans votre domaine, ignorez cette phase. Amazon SageMaker Studio Classic fonctionne dans un environnement partagé avec : + une application `JupyterServer` exécutant le Jupyter Server ; + des blocs-notes Studio Classic exécutés sur une ou plusieurs applications `KernelGateway`. Studio s’est éloigné d’un environnement divisé. Studio exécute l'éditeur de code JupyterLab and, basé sur les applications Code-OSS, Visual Studio Code - Open Source dans un modèle d'exécution local. Pour plus d'informations sur le changement d'architecture, consultez [Boostez la productivité sur Amazon SageMaker Studio](https://aws.amazon.com/blogs//machine-learning/boost-productivity-on-amazon-sagemaker-studio-introducing-jupyterlab-spaces-and-generative-ai-tools/). ## Migration des images personnalisées Vos images personnalisées Studio Classic existantes peuvent ne pas fonctionner dans Studio. Nous vous recommandons de créer une nouvelle image personnalisée répondant aux exigences d’utilisation dans Studio. La sortie de Studio simplifie le processus de création d'images personnalisées en fournissant[SageMaker Politique de prise en charge des images de studio](sagemaker-distribution.md). SageMaker Les images AI Distribution incluent des bibliothèques et des packages populaires pour l'apprentissage automatique, la science des données et la visualisation de l'analyse des données. Pour obtenir la liste des images de SageMaker distribution de base et les informations relatives au compte Amazon Elastic Container Registry, consultez[Amazon SageMaker Images disponibles pour une utilisation avec les blocs-notes Studio Classic](notebooks-available-images.md). Pour générer une image personnalisée, effectuez l’une des opérations suivantes. + Étendez une image de SageMaker distribution avec des packages et des modules personnalisés. Ces images sont préconfigurées avec un éditeur JupyterLab de code, basé sur Code-OSS, Visual Studio Code - Open Source. + Créez un fichier Dockerfile personnalisé en suivant les instructions fournies dans [Apporter votre propre image (BYOI)](studio-updated-byoi.md). Vous devez installer JupyterLab et le serveur CodeServer open source sur l’image pour la rendre compatible avec Studio. ## Migration des configurations de cycle de vie En raison du modèle d'exécution local simplifié de Studio, nous vous recommandons de migrer la structure de votre Studio Classic LCCs existant. Dans Studio Classic, vous devez souvent créer des configurations de cycle de vie distinctes pour les applications KernelGateway et JupyterServer. Étant donné que les KernelGateway applications JupyterServer et s'exécutent sur des ressources de calcul distinctes dans Studio Classic, Studio Classic LCCs peut être de l'un ou l'autre type : + JupyterServerLCC : Ils régissent LCCs principalement les actions personnelles d'un utilisateur, notamment la configuration du proxy, la création de variables d'environnement et l'arrêt automatique des ressources. + KernelGatewayLCC : ils LCCs régissent les optimisations de l'environnement des ordinateurs portables Studio Classic. Cela inclut la mise à jour des versions du package numpy dans le noyau `Data Science 3.0` et l’installation du package snowflake dans le noyau `Pytorch 2.0 GPU`. Dans l’architecture Studio simplifiée, vous n’avez besoin que d’un seul script LCC qui s’exécute au démarrage de l’application. Bien que la migration de vos scripts LCC varie en fonction de l'environnement de développement, nous vous recommandons de combiner JupyterServer et KernelGateway LCCs de créer un LCC combiné. LCCs in Studio peut être associé à l'une des applications suivantes : + JupyterLab + Éditeur de code Les utilisateurs peuvent sélectionner la configuration LCC pour le type d’application correspondant lors de la création d’un espace ou utiliser la configuration LCC par défaut définie par l’administrateur. **Note** Les scripts existants d’arrêt automatique de Studio Classic ne fonctionnent pas avec Studio. Pour un exemple de script d'arrêt automatique de Studio, consultez la section [Exemples de configuration du cycle de vie de SageMaker Studio](https://github.com/aws-samples/sagemaker-studio-apps-lifecycle-config-examples). ### Considérations relatives à la refactorisation LCCs Tenez compte des différences suivantes entre Studio Classic et Studio lorsque vous refactorisez votre. LCCs + JupyterLab et les applications Code Editor, une fois créées, sont exécutées comme `sagemaker-user` avec `UID:1001` et`GID:101`. Par défaut, `sagemaker-user` dispose des autorisations nécessaires pour assumer sudo/root des autorisations. KernelGatewayles applications sont exécutées `root` par défaut. + SageMaker Les images de distribution qui s'exécutent dans JupyterLab les applications de l'éditeur de code et de l'éditeur de code utilisent le gestionnaire de packages Debian basé sur`apt-get`. + Les applications Studio JupyterLab et Code Editor utilisent le gestionnaire de Conda packages. SageMaker L'IA crée un Python3 Conda environnement de base unique lorsqu'une application Studio est lancée. Pour en savoir plus sur la mise à jour des packages dans l’environnement Conda de base et la création de nouveaux environnements Conda, consultez [JupyterLab guide de l'utilisateur](studio-updated-jl-user-guide.md). En revanche, toutes les applications KernelGateway n’utilisent pas Conda comme gestionnaire de packages. + L' JupyterLab application Studio utilise`JupyterLab 4.0`, tandis que Studio Classic utilise`JupyterLab 3.0`. Vérifiez que toutes les extensions JupyterLab que vous utilisez sont compatibles avec `JupyterLab 4.0`. Pour plus d'informations sur les extensions, consultez la section [Compatibilité des extensions avec la JupyterLab version 4.0](https://github.com/jupyterlab/jupyterlab/issues/14590). # (Facultatif) Migration des données de Studio Classic vers Studio Studio Classic et Studio utilisent deux types de volumes de stockage différents. Studio Classic utilise un volume Amazon Elastic File System (Amazon EFS) unique pour stocker les données de tous les utilisateurs et de tous les espaces partagés dans le domaine. Dans Studio, chaque espace possède son propre volume Amazon Elastic Block Store (Amazon EBS). Lorsque vous mettez à jour l'expérience par défaut d'un domaine existant, SageMaker AI monte automatiquement un dossier dans un volume Amazon EFS pour chaque utilisateur d'un domaine. Par conséquent, les utilisateurs peuvent accéder aux fichiers depuis Studio Classic dans leurs applications Studio. Pour de plus amples informations, veuillez consulter [Montage automatique d’Amazon EFS dans Studio](studio-updated-automount.md). Vous pouvez également désactiver le montage automatique Amazon EFS et migrer manuellement les données pour permettre aux utilisateurs d’accéder aux fichiers depuis Studio Classic dans les applications Studio. Pour ce faire, vous devez transférer les fichiers des répertoires personnels des utilisateurs aux volumes Amazon EBS associés à ces espaces. La section suivante fournit des informations sur ce flux de travail. Pour plus d’informations sur la désactivation du montage automatique Amazon EFS, consultez [Désactivation du montage automatique Amazon EFS](studio-updated-automount-optout.md). ## Migration manuelle de toutes vos données depuis Studio Classic La section suivante explique comment migrer toutes les données de votre volume de stockage Studio Classic vers la nouvelle expérience Studio. Lorsque vous migrez manuellement les données, le code et les artefacts d’un utilisateur de Studio Classic vers Studio, nous vous recommandons l’une des approches suivantes : 1. Utilisation d’un volume Amazon EFS personnalisé 1. Utilisation d’Amazon Simple Storage Service (Amazon S3) Si vous avez utilisé Amazon SageMaker Data Wrangler dans Studio Classic et que vous souhaitez migrer vos fichiers de flux de données, choisissez l'une des options de migration suivantes : + Si vous souhaitez migrer toutes les données de votre volume de stockage Studio Classic, y compris vos fichiers de flux de données, consultez [Migration manuelle de toutes vos données depuis Studio Classic](#studio-updated-migrate-data-all) et suivez la section **Utilisation d’Amazon S3 pour migrer les données**. Passez ensuite à la section [Importation des fichiers de flux dans Canvas](#studio-updated-migrate-flows-import). + Si vous souhaitez uniquement migrer vos fichiers de flux de données et aucune autre donnée de votre volume de stockage Studio Classic, passez à la section [Migration des flux de données depuis Data Wrangler](#studio-updated-migrate-flows). ### Conditions préalables Avant de suivre ces étapes, veillez à respecter les conditions préalables requises dans [Conditions préalables requises complètes pour migrer l’expérience Studio](studio-updated-migrate-prereq.md). Vous devez également suivre les étapes fournies dans [Migration de l’interface utilisateur de Studio Classic vers Studio](studio-updated-migrate-ui.md). ### Choix d’une approche Tenez compte des éléments suivants lorsque vous choisissez une approche pour migrer vos données Studio Classic. **Avantages et inconvénients de l’utilisation d’un volume Amazon EFS personnalisé** Dans cette approche, vous utilisez une AWS DataSync tâche Amazon EFS-to-Amazon EFS (ponctuelle ou cadence) pour copier des données, puis vous montez le volume Amazon EFS cible sur les espaces d'un utilisateur. Cela permet aux utilisateurs d’accéder aux données depuis Studio Classic dans leurs environnements informatiques Studio. Avantages : + Seules les données du répertoire de base de l’utilisateur sont visibles dans les espaces de l’utilisateur. Aucune pollinisation croisée des données n’intervient. + La synchronisation entre le volume Amazon EFS source et un volume Amazon EFS cible est plus sûre que le montage direct du volume Amazon EFS source géré par SageMaker AI dans des espaces. Cela permet d’éviter tout impact potentiel sur les fichiers utilisateur du répertoire de base. + Les utilisateurs ont la possibilité de continuer à travailler dans les applications Studio Classic et Studio, tout en ayant leurs données disponibles dans les deux applications si AWS DataSync est configuré à une cadence régulière. + Il est inutile de recourir à des envois (push) et extractions (pull) répétés avec Amazon S3. Inconvénients : + Aucun accès en écriture au volume Amazon EFS cible monté dans les espaces de l’utilisateur. Pour obtenir un accès en écriture au volume Amazon EFS cible, les clients doivent monter le volume Amazon EFS cible sur une instance Amazon Elastic Compute Cloud et fournir les autorisations appropriées aux utilisateurs pour écrire dans le préfixe Amazon EFS. + Nécessite de modifier les groupes de sécurité gérés par l' SageMaker IA pour autoriser les flux entrants et sortants du système de fichiers réseau (NFS). + Coûte plus cher que d’utiliser Amazon S3. + Si vous [migrez des flux de données depuis Data Wrangler dans Studio Classic](#studio-updated-migrate-flows), vous devez suivre les étapes d’exportation manuelle des fichiers de flux. **Avantages et inconvénients de l’utilisation d’Amazon S3** Dans cette approche, vous utilisez une AWS DataSync tâche Amazon EFS-to-Amazon S3 (ponctuelle ou cadence) pour copier des données, puis vous créez une configuration de cycle de vie pour copier les données de l'utilisateur depuis Amazon S3 vers le volume Amazon EBS de son espace privé. Avantages : + Si la configuration LCC est attachée au domaine, les utilisateurs peuvent choisir d’utiliser la configuration LCC pour copier les données dans leur espace ou d’exécuter l’espace sans script LCC. Cela donne aux utilisateurs le choix de copier leurs fichiers uniquement dans les espaces dont ils ont besoin. + Si une AWS DataSync tâche est configurée à une cadence, les utilisateurs peuvent redémarrer leur application Studio pour obtenir les derniers fichiers. + Les données étant copiées sur Amazon EBS, les utilisateurs disposent d’autorisations d’écriture sur les fichiers. + Le stockage Amazon S3 est moins cher qu’Amazon EFS. + Si vous [migrez des flux de données depuis Data Wrangler dans Studio Classic](#studio-updated-migrate-flows), vous pouvez ignorer les étapes d'exportation manuelle et importer directement les flux de données dans SageMaker Canvas depuis Amazon S3. Inconvénients : + Si les administrateurs doivent empêcher la pollinisation croisée, ils doivent créer des politiques Gestion des identités et des accès AWS au niveau de l’utilisateur pour garantir que les utilisateurs ne peuvent accéder qu’au préfixe Amazon S3 qui contient leurs fichiers. ### Utilisation d’un volume Amazon EFS personnalisé pour migrer les données Dans cette approche, vous utilisez un Amazon EFS-to-Amazon EFS AWS DataSync pour copier le contenu d'un volume Amazon EFS Studio Classic sur un volume Amazon EFS cible une seule fois ou selon une cadence régulière, puis vous montez le volume Amazon EFS cible sur les espaces d'un utilisateur. Cela permet aux utilisateurs d’accéder aux données depuis Studio Classic dans leurs environnements informatiques Studio. 1. Créez un volume Amazon EFS cible. Vous allez transférer les données vers ce volume Amazon EFS et monter ce dernier sur l’espace d’un utilisateur correspondant à l’aide d’un montage au niveau du préfixe. ``` export SOURCE_DOMAIN_ID="domain-id" export AWS_REGION="region" export TARGET_EFS=$(aws efs create-file-system --performance-mode generalPurpose --throughput-mode bursting --encrypted --region $REGION | jq -r '.FileSystemId') echo "Target EFS volume Created: $TARGET_EFS" ``` 1. Ajoutez des variables pour le volume Amazon EFS source actuellement attaché au domaine et utilisé par tous les utilisateurs. Les informations Amazon Virtual Private Cloud du domaine sont requises pour garantir que le service Amazon EFS cible est créé dans le même réseau Amazon VPC et le même sous-réseau, avec la même configuration de groupes de sécurité. ``` export SOURCE_EFS=$(aws sagemaker describe-domain --domain-id $SOURCE_DOMAIN_ID | jq -r '.HomeEfsFileSystemId') export VPC_ID=$(aws sagemaker describe-domain --domain-id $SOURCE_DOMAIN_ID | jq -r '.VpcId') echo "EFS managed by SageMaker: $SOURCE_EFS | VPC: $VPC_ID" ``` 1. Créez une cible de montage Amazon EFS dans le même réseau Amazon VPC et le même sous-réseau que le volume Amazon EFS source, avec la même configuration de groupes de sécurité. La cible de montage met quelques minutes à être disponible. ``` export EFS_VPC_ID=$(aws efs describe-mount-targets --file-system-id $SOURCE_EFS | jq -r ".MountTargets[0].VpcId") export EFS_AZ_NAME=$(aws efs describe-mount-targets --file-system-id $SOURCE_EFS | jq -r ".MountTargets[0].AvailabilityZoneName") export EFS_AZ_ID=$(aws efs describe-mount-targets --file-system-id $SOURCE_EFS | jq -r ".MountTargets[0].AvailabilityZoneId") export EFS_SUBNET_ID=$(aws efs describe-mount-targets --file-system-id $SOURCE_EFS | jq -r ".MountTargets[0].SubnetId") export EFS_MOUNT_TARG_ID=$(aws efs describe-mount-targets --file-system-id $SOURCE_EFS | jq -r ".MountTargets[0].MountTargetId") export EFS_SG_IDS=$(aws efs describe-mount-target-security-groups --mount-target-id $EFS_MOUNT_TARG_ID | jq -r '.SecurityGroups[]') aws efs create-mount-target \ --file-system-id $TARGET_EFS \ --subnet-id $EFS_SUBNET_ID \ --security-groups $EFS_SG_IDS ``` 1. Créez les emplacements source et destination Amazon EFS pour la AWS DataSync tâche. ``` export SOURCE_EFS_ARN=$(aws efs describe-file-systems --file-system-id $SOURCE_EFS | jq -r ".FileSystems[0].FileSystemArn") export TARGET_EFS_ARN=$(aws efs describe-file-systems --file-system-id $TARGET_EFS | jq -r ".FileSystems[0].FileSystemArn") export EFS_SUBNET_ID_ARN=$(aws ec2 describe-subnets --subnet-ids $EFS_SUBNET_ID | jq -r ".Subnets[0].SubnetArn") export ACCOUNT_ID=$(aws ec2 describe-security-groups --group-id $EFS_SG_IDS | jq -r ".SecurityGroups[0].OwnerId") export EFS_SG_ID_ARN=arn:aws:ec2:$REGION:$ACCOUNT_ID:security-group/$EFS_SG_IDS export SOURCE_LOCATION_ARN=$(aws datasync create-location-efs --subdirectory "/" --efs-filesystem-arn $SOURCE_EFS_ARN --ec2-config SubnetArn=$EFS_SUBNET_ID_ARN,SecurityGroupArns=$EFS_SG_ID_ARN --region $REGION | jq -r ".LocationArn") export DESTINATION_LOCATION_ARN=$(aws datasync create-location-efs --subdirectory "/" --efs-filesystem-arn $TARGET_EFS_ARN --ec2-config SubnetArn=$EFS_SUBNET_ID_ARN,SecurityGroupArns=$EFS_SG_ID_ARN --region $REGION | jq -r ".LocationArn") ``` 1. Autorisez le trafic entre les montages du système de fichiers réseau (NFS) source et cible. Lorsqu'un nouveau domaine est créé, l' SageMaker IA crée 2 groupes de sécurité. + Groupe de sécurité entrant NFS avec trafic entrant uniquement. + Groupe de sécurité sortant NFS avec trafic sortant uniquement. Les systèmes NFS source et cible sont placés dans les mêmes groupes de sécurité. Vous pouvez autoriser le trafic entre ces supports depuis le AWS Management Console ou AWS CLI. + Autoriser le trafic en provenance du AWS Management Console 1. Connectez-vous à la console Amazon VPC AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) 1. Choisissez **Security Groups**. 1. Recherchez l’ID du domaine existant sur la page **Groupes de sécurité**. ``` d-xxxxxxx ``` Les résultats devraient renvoyer deux groupes de sécurité incluant l’ID de domaine dans leur nom. + `security-group-for-inbound-nfs-domain-id` + `security-group-for-outbound-nfs-domain-id` 1. Sélectionnez l’ID du groupe de sécurité entrant. Cela ouvre une nouvelle page de détails sur le groupe de sécurité. 1. Sélectionnez l’onglet **Règles sortantes**. 1. Sélectionnez **Modifier les règles sortantes**. 1. Mettez à jour les règles sortantes existantes ou ajoutez-en une nouvelle avec les valeurs suivantes : + **Type** : NFS + **Protocole** : TCP + **Plage de ports** : 2049 + **Destination** : security-group-for-outbound -nfs- \$1 *domain-id* *security-group-id* 1. Sélectionnez **Enregistrer les règles**. 1. Sélectionnez l’onglet **Règles entrantes**. 1. Sélectionnez **Modifier les règles entrantes**. 1. Mettez à jour les règles entrantes existantes ou ajoutez une nouvelle règle sortante avec les valeurs suivantes : + **Type** : NFS + **Protocole** : TCP + **Plage de ports** : 2049 + **Destination** : security-group-for-outbound -nfs- \$1 *domain-id* *security-group-id* 1. Sélectionnez **Enregistrer les règles**. + Autoriser le trafic en provenance du AWS CLI 1. Mettez à jour les règles entrantes et sortantes des groupes de sécurité avec les valeurs suivantes : + **Protocole** : TCP + **Plage de ports** : 2049 + **ID de groupe** : ID de groupe de sécurité entrant ou ID de groupe de sécurité sortant ``` export INBOUND_SG_ID=$(aws ec2 describe-security-groups --filters "Name=group-name,Values=security-group-for-inbound-nfs-$SOURCE_DOMAIN_ID" | jq -r ".SecurityGroups[0].GroupId") export OUTBOUND_SG_ID=$(aws ec2 describe-security-groups --filters "Name=group-name,Values=security-group-for-outbound-nfs-$SOURCE_DOMAIN_ID" | jq -r ".SecurityGroups[0].GroupId") echo "Outbound SG ID: $OUTBOUND_SG_ID | Inbound SG ID: $INBOUND_SG_ID" aws ec2 authorize-security-group-egress \ --group-id $INBOUND_SG_ID \ --protocol tcp --port 2049 \ --source-group $OUTBOUND_SG_ID aws ec2 authorize-security-group-ingress \ --group-id $OUTBOUND_SG_ID \ --protocol tcp --port 2049 \ --source-group $INBOUND_SG_ID ``` 1. Ajoutez les groupes de sécurité entrants et sortants aux cibles de montage Amazon EFS source et cible. Cela permet le trafic entre les deux montages Amazon EFS. ``` export SOURCE_EFS_MOUNT_TARGET=$(aws efs describe-mount-targets --file-system-id $SOURCE_EFS | jq -r ".MountTargets[0].MountTargetId") export TARGET_EFS_MOUNT_TARGET=$(aws efs describe-mount-targets --file-system-id $TARGET_EFS | jq -r ".MountTargets[0].MountTargetId") aws efs modify-mount-target-security-groups \ --mount-target-id $SOURCE_EFS_MOUNT_TARGET \ --security-groups $INBOUND_SG_ID $OUTBOUND_SG_ID aws efs modify-mount-target-security-groups \ --mount-target-id $TARGET_EFS_MOUNT_TARGET \ --security-groups $INBOUND_SG_ID $OUTBOUND_SG_ID ``` 1. Créez une AWS DataSync tâche. Cela renvoie un ARN de tâche qui peut être utilisé pour exécuter la tâche à la demande ou dans le cadre d’une cadence régulière. ``` export EXTRA_XFER_OPTIONS='VerifyMode=ONLY_FILES_TRANSFERRED,OverwriteMode=ALWAYS,Atime=NONE,Mtime=NONE,Uid=NONE,Gid=NONE,PreserveDeletedFiles=REMOVE,PreserveDevices=NONE,PosixPermissions=NONE,TaskQueueing=ENABLED,TransferMode=CHANGED,SecurityDescriptorCopyFlags=NONE,ObjectTags=NONE' export DATASYNC_TASK_ARN=$(aws datasync create-task --source-location-arn $SOURCE_LOCATION_ARN --destination-location-arn $DESTINATION_LOCATION_ARN --name "SMEFS_to_CustomEFS_Sync" --region $REGION --options $EXTRA_XFER_OPTIONS | jq -r ".TaskArn") ``` 1. Démarrez une AWS DataSync tâche pour copier automatiquement les données de la source Amazon EFS vers le montage Amazon EFS cible. Cela ne conserve pas les autorisations POSIX du fichier, qui permettent aux utilisateurs de lire à partir du montage Amazon EFS cible, mais pas d’y écrire. ``` aws datasync start-task-execution --task-arn $DATASYNC_TASK_ARN ``` 1. Montez le volume Amazon EFS cible sur le domaine au niveau racine. ``` aws sagemaker update-domain --domain-id $SOURCE_DOMAIN_ID \ --default-user-settings '{"CustomFileSystemConfigs": [{"EFSFileSystemConfig": {"FileSystemId": "'"$TARGET_EFS"'", "FileSystemPath": "/"}}]}' ``` 1. Remplacez chaque profil utilisateur par un préfixe `FileSystemPath`. Le préfixe inclut l'UID de l'utilisateur, créé par SageMaker l'IA. Cela garantit que les utilisateurs n’ont accès qu’à leurs données et empêche la pollinisation croisée. Lorsqu’un espace est créé dans le domaine et que le volume Amazon EFS cible est monté sur l’application, le préfixe de l’utilisateur remplace le préfixe du domaine. Par conséquent, l' SageMaker IA monte uniquement le `/user-id` répertoire sur l'application de l'utilisateur. ``` aws sagemaker list-user-profiles --domain-id $SOURCE_DOMAIN_ID | jq -r '.UserProfiles[] | "\(.UserProfileName)"' | while read user; do export uid=$(aws sagemaker describe-user-profile --domain-id $SOURCE_DOMAIN_ID --user-profile-name $user | jq -r ".HomeEfsFileSystemUid") echo "$user $uid" aws sagemaker update-user-profile --domain-id $SOURCE_DOMAIN_ID --user-profile-name $user --user-settings '{"CustomFileSystemConfigs": [{"EFSFileSystemConfig":{"FileSystemId": "'"$TARGET_EFS"'", "FileSystemPath": "'"/$uid/"'"}}]}' done ``` 1. Les utilisateurs peuvent ensuite sélectionner le système de fichiers Amazon EFS personnalisé lors du lancement d’une application. Pour plus d’informations, consultez [JupyterLab guide de l'utilisateur](studio-updated-jl-user-guide.md) ou [Lancement d’une application d’éditeur de code dans Studio](code-editor-use-studio.md). ### Utilisation d’Amazon S3 pour migrer les données Dans cette approche, vous utilisez une AWS DataSync tâche Amazon EFS-to-Amazon S3 pour copier le contenu d'un volume Amazon EFS Studio Classic dans un compartiment Amazon S3 une seule fois ou à une cadence normale, puis vous créez une configuration de cycle de vie pour copier les données de l'utilisateur depuis Amazon S3 vers le volume Amazon EBS de son espace privé. **Note** Cette approche ne fonctionne que pour les domaines qui ont accès à Internet. 1. Définissez l’ID du volume Amazon EFS source à partir du domaine contenant les données que vous migrez. ``` timestamp=$(date +%Y%m%d%H%M%S) export SOURCE_DOMAIN_ID="domain-id" export AWS_REGION="region" export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) export EFS_ID=$(aws sagemaker describe-domain --domain-id $SOURCE_DOMAIN_ID | jq -r '.HomeEfsFileSystemId') ``` 1. Définissez le nom du compartiment Amazon S3 cible. Pour en savoir plus sur la création d’un compartiment Amazon S3, consultez [Création d’un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html). Le compartiment utilisé doit avoir une politique CORS telle que décrite dans [(Facultatif) Mise à jour de votre politique CORS pour accéder aux compartiments Amazon S3](studio-updated-migrate-ui.md#studio-updated-migrate-cors). Les utilisateurs du domaine doivent également disposer des autorisations pour accéder au compartiment Amazon S3. Dans cet exemple, nous copions des fichiers vers un préfixe nommé `studio-new`. Si vous utilisez un compartiment Amazon S3 unique pour migrer plusieurs domaines, utilisez le préfixe `studio-new/` pour restreindre les autorisations aux fichiers à l’aide d’IAM. ``` export BUCKET_NAME=s3-bucket-name export S3_DESTINATION_PATH=studio-new ``` 1. Créez une politique de confiance qui autorise AWS DataSync l'utilisateur à assumer le rôle d'exécution de votre compte. ``` export TRUST_POLICY=$(cat < Si vous avez déjà utilisé Amazon SageMaker Data Wrangler dans Amazon SageMaker Studio Classic pour des tâches de préparation des données, vous pouvez migrer vers le nouvel Amazon SageMaker Studio et accéder à la dernière version de Data Wrangler dans Amazon Canvas. SageMaker Data Wrangler in SageMaker Canvas vous offre une expérience utilisateur améliorée et un accès aux dernières fonctionnalités, telles qu'une interface en langage naturel et des performances plus rapides. Vous pouvez vous connecter à SageMaker Canvas à tout moment pour commencer à utiliser la nouvelle expérience Data Wrangler. Pour de plus amples informations, veuillez consulter [Commencer à utiliser Amazon SageMaker Canvas](canvas-getting-started.md). Si vous avez enregistré des fichiers de flux de données dans Studio Classic sur lesquels vous travailliez auparavant, vous pouvez intégrer Studio, puis importer les fichiers de flux dans Canvas. Vous disposez des options suivantes pour la migration : + Migration en un clic : lorsque vous vous connectez à Canvas, vous pouvez utiliser une option d’importation unique qui migre tous vos fichiers de flux en votre nom. + Migration manuelle : vous pouvez importer manuellement vos fichiers de flux dans Canvas. Depuis Studio Classic, exportez les fichiers vers Amazon S3 ou téléchargez-les sur votre ordinateur local. Ensuite, vous vous connectez à l'application SageMaker Canvas, vous importez les fichiers de flux et vous poursuivez vos tâches de préparation des données. Le guide suivant décrit les conditions préalables à la migration et explique comment migrer vos fichiers de flux de données à l’aide de l’option manuelle ou en un clic. ### Conditions préalables Passez en revue les conditions préalables suivantes avant de commencer à migrer vos fichiers de flux. **Étape 1. Migration du domaine et octroi des autorisations** Avant de migrer des fichiers de flux de données, vous devez suivre les étapes spécifiques du [Migration depuis Amazon SageMaker Studio Classic](studio-updated-migrate.md) guide pour vous assurer que le rôle d'exécution AWS IAM de votre profil utilisateur dispose des autorisations requises. Avant de continuer, suivez les rubriques [Conditions préalables requises](studio-updated-migrate-prereq.md) et [Migration de l’interface utilisateur de Studio Classic vers Studio](studio-updated-migrate-ui.md), qui décrivent comment accorder les autorisations requises, configurer Studio en tant que nouvelle expérience et migrer votre domaine existant. Plus précisément, vous devez disposer des autorisations nécessaires pour créer une application SageMaker Canvas et utiliser les fonctionnalités de préparation des données SageMaker Canvas. Pour obtenir ces autorisations, vous pouvez : + Ajoutez la [ AmazonSageMakerCanvasDataPrepFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSageMakerCanvasDataPrepFullAccess.html)politique à votre rôle IAM, ou + Joignez une politique de minimisation des autorisations, comme indiqué dans la section **(facultatif) Migrer de Data Wrangler dans Studio Classic vers SageMaker Canvas de** la page. [Migration de l’interface utilisateur de Studio Classic vers Studio](studio-updated-migrate-ui.md) Assurez-vous d'utiliser le même profil utilisateur pour Studio et SageMaker Canvas. Après avoir rempli les conditions requises décrites dans le guide de migration, vous devriez disposer d'un nouveau domaine avec les autorisations requises pour accéder à SageMaker Canvas via Studio. **Étape 2. (Facultatif) Préparation d’un emplacement Amazon S3** Si vous effectuez une migration manuelle et que vous prévoyez d’utiliser Amazon S3 pour transférer vos fichiers de flux au lieu d’utiliser l’option de téléchargement local, vous devez disposer d’un compartiment Amazon S3 dans votre compte que vous souhaitez utiliser pour stocker les fichiers de flux. ### Méthode de migration en un clic SageMaker Canvas propose une option d'importation unique pour migrer vos flux de données de Data Wrangler dans Studio Classic vers Data Wrangler dans Canvas. SageMaker Tant que vos applications Studio Classic et Canvas partagent le même volume de stockage Amazon EFS, vous pouvez effectuer la migration en un clic depuis Canvas. Ce processus rationalisé élimine le besoin d’étapes manuelles d’exportation et d’importation, et vous pouvez importer tous vos flux en une seule fois. Utilisez la procédure suivante pour migrer l’ensemble de vos fichiers de flux : 1. Ouvrez votre dernière version de Studio. 1. Dans Studio, dans le volet de navigation de gauche, choisissez le menu déroulant **Données**. 1. Dans les options de navigation, choisissez **Data Wrangler**. 1. Sur la page **Data Wrangler**, choisissez **Exécuter dans Canvas**. Si vous avez correctement configuré les autorisations, cela crée une application Canvas pour vous. L’application Canvas peut prendre quelques minutes avant d’être prête. 1. Lorsque l’application Canvas est prête, choisissez **Ouvrir dans Canvas**. 1. Canvas s’ouvre à la page **Data Wrangler** et une bannière apparaît en haut de la page indiquant Importez vos flux de données depuis Data Wrangler dans Studio Classic vers Canvas. Il s’agit d’une importation unique. En savoir plus. Dans la bannière, choisissez **Tout importer**. **Avertissement** Si vous fermez la bannière de notification, vous ne pourrez plus la rouvrir ni utiliser la méthode de migration en un clic. Une notification contextuelle apparaît, indiquant que Canvas importe vos fichiers de flux depuis Studio Classic. Si l’importation est entièrement réussie, vous recevez une autre notification indiquant qu’un nombre `X` de fichiers de flux ont été importés, et vous pouvez voir vos fichiers de flux sur la page **Data Wrangler** de l’application Canvas. Tous les fichiers de flux importés portant le même nom que les flux de données existants dans votre application Canvas sont renommés avec un suffixe. Vous pouvez ouvrir un flux de données pour vérifier qu’il s’affiche comme prévu. Si l’importation de l’un de vos fichiers de flux échoue, vous recevez une notification indiquant que l’importation a partiellement réussi ou qu’elle a échoué. Choisissez **Voir les erreurs** dans le message de notification pour consulter les messages d’erreur individuels et obtenir des conseils sur la manière de reformater les fichiers de flux mal formatés. Après avoir importé vos fichiers de flux, vous devriez pouvoir continuer à utiliser Data Wrangler pour préparer les données dans SageMaker Canvas. ### Méthode de migration manuelle Les sections suivantes décrivent comment importer manuellement vos fichiers de flux dans Canvas au cas où la méthode de migration en un clic ne fonctionnerait pas. #### Exportation des fichiers de flux depuis Studio Classic **Note** Si vous avez déjà migré vos données Studio Classic vers Amazon S3 en suivant les instructions fournies dans [(Facultatif) Migration des données de Studio Classic vers Studio](#studio-updated-migrate-data), vous pouvez ignorer cette étape et passer directement à la section [Importation des fichiers de flux dans Canvas](#studio-updated-migrate-flows-import) dans laquelle vous importez vos fichiers de flux depuis l’emplacement Amazon S3 où vos données Studio Classic sont stockées. Vous pouvez exporter vos fichiers de flux en les enregistrant sur Amazon S3 ou en les téléchargeant sur votre ordinateur local. Lorsque vous importez vos fichiers de flux dans SageMaker Canvas à l'étape suivante, si vous choisissez l'option de téléchargement local, vous ne pouvez télécharger que 20 fichiers de flux à la fois. Si vous avez un grand nombre de fichiers de flux à importer, nous vous recommandons d’utiliser Amazon S3 à la place. Suivez les instructions fournies dans [Méthode 1 : utilisation d’Amazon S3 pour transférer les fichiers de flux](#studio-updated-migrate-flows-export-s3) ou [Méthode 2 : utilisation de votre ordinateur local pour transférer les fichiers de flux](#studio-updated-migrate-flows-export-local) pour continuer. ##### Méthode 1 : utilisation d’Amazon S3 pour transférer les fichiers de flux Avec cette méthode, vous utilisez Amazon S3 comme intermédiaire entre Data Wrangler dans Studio Classic et Data Wrangler dans SageMaker Canvas (accessible via la dernière version de Studio). Vous exportez les fichiers de flux de Studio Classic vers Amazon S3, puis à l’étape suivante, vous accédez à Canvas via Studio et vous importez les fichiers de flux depuis Amazon S3. Assurez-vous de disposer d’un compartiment Amazon S3 préparé comme emplacement de stockage pour les fichiers de flux. Utilisez la procédure suivante pour exporter vos fichiers de flux de Studio Classic vers Amazon S3 : 1. Ouvrez Studio Classic. 1. Ouvrez un nouveau terminal en procédant comme suit : 1. Dans la barre de navigation supérieure, choisissez **Fichier**. 1. Dans le menu contextuel, survolez **Nouveau**, puis sélectionnez **Terminal**. 1. Par défaut, le terminal doit s’ouvrir dans votre répertoire de base. Accédez au dossier contenant tous les fichiers de flux que vous souhaitez migrer. 1. Utilisez la commande suivante pour synchroniser tous les fichiers de flux à l’emplacement Amazon S3 spécifié. Remplacez `{bucket-name}` et `{folder}` par le chemin d’accès à l’emplacement Amazon S3 de votre choix. Pour plus d'informations sur la commande et les paramètres, consultez la commande de [synchronisation](https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html) dans le manuel de référence des AWS AWS CLI commandes. ``` aws s3 sync . s3://{bucket-name}/{folder}/ --exclude "*.*" --include "*.flow" ``` Si vous utilisez le vôtre AWS KMS key, utilisez plutôt la commande suivante pour synchroniser les fichiers et spécifiez votre ID de clé KMS. Assurez-vous que le rôle d’exécution IAM de l’utilisateur (qui doit être le même rôle que celui utilisé dans **Étape 1 : Migration du domaine et octroi des autorisations** de la rubrique précédente [Conditions préalables requises](#studio-updated-migrate-flows-prereqs)) a été autorisé à utiliser la clé KMS. ``` aws s3 sync . s3://{bucket-name}/{folder}/ --exclude "*.*" --include "*.flow" --sse-kms-key-id {your-key-id} ``` Vos fichiers de flux doivent maintenant être exportés. Vous pouvez vérifier votre compartiment Amazon S3 pour vous assurer que les fichiers de flux se sont synchronisés avec succès. Pour importer ces fichiers dans la dernière version de Data Wrangler, suivez les étapes décrites dans [Importation des fichiers de flux dans Canvas](#studio-updated-migrate-flows-import). ##### Méthode 2 : utilisation de votre ordinateur local pour transférer les fichiers de flux Cette méthode vous permet de télécharger les fichiers de flux depuis Studio Classic sur votre ordinateur local. Vous pouvez télécharger les fichiers directement ou les compresser sous forme d’archive zip. Ensuite, vous décompressez le fichier zip localement (le cas échéant), vous vous connectez à Canvas et vous importez les fichiers de flux en les chargeant depuis votre ordinateur local. Utilisez la procédure suivante pour télécharger vos fichiers de flux à partir de Studio Classic : 1. Ouvrez Studio Classic. 1. (Facultatif) Si vous souhaitez compresser plusieurs fichiers de flux dans une archive zip et les télécharger tous en une seule fois, procédez comme suit : 1. Dans la barre de navigation supérieure de Studio Classic, choisissez **Fichier**. 1. Dans le menu contextuel, survolez **Nouveau**, puis sélectionnez **Terminal**. 1. Par défaut, le terminal s’ouvre dans votre répertoire de base. Accédez au dossier contenant tous les fichiers de flux que vous souhaitez migrer. 1. Utilisez la commande suivante pour compresser les fichiers de flux dans le répertoire actuel sous forme de fichier zip. La commande exclut tous les fichiers cachés : ``` find . -not -path "*/.*" -name "*.flow" -print0 | xargs -0 zip my_archive.zip ``` 1. Téléchargez l’archive zip ou les fichiers de flux individuels sur votre ordinateur local en procédant comme suit : 1. Dans le volet de navigation de gauche, choisissez **Explorateur de fichiers**. 1. Recherchez le fichier que vous souhaitez télécharger dans l’explorateur de fichiers. 1. Cliquez avec le bouton droit sur le fichier, puis, dans le menu contextuel, sélectionnez **Télécharger**. Le fichier doit être téléchargé sur votre ordinateur local. Si vous les avez compressés sous forme d’archive zip, extrayez les fichiers localement. Une fois les fichiers extraits, pour importer ces fichiers dans la dernière version de Data Wrangler, suivez les étapes décrites dans [Importation des fichiers de flux dans Canvas](#studio-updated-migrate-flows-import). #### Importation des fichiers de flux dans Canvas Après avoir exporté vos fichiers de flux, accédez à Canvas via Studio et importez les fichiers. Utilisez la procédure suivante pour importer les fichiers de flux dans Canvas : 1. Ouvrez votre dernière version de Studio. 1. Dans Studio, dans le volet de navigation de gauche, choisissez le menu déroulant **Données**. 1. Dans les options de navigation, choisissez **Data Wrangler**. 1. Sur la page **Data Wrangler**, choisissez **Exécuter dans Canvas**. Si vous avez correctement configuré les autorisations, cela crée une application Canvas pour vous. L’application Canvas peut prendre quelques minutes avant d’être prête. 1. Lorsque l’application Canvas est prête, choisissez **Ouvrir dans Canvas**. 1. Canvas s’ouvre à la page **Data Wrangler**. Dans le volet supérieur, choisissez **Importer des flux de données**. 1. Pour **Source de données**, choisissez **Amazon S3** ou **Chargement local**. 1. Sélectionnez vos fichiers de flux dans votre compartiment Amazon S3 ou chargez les fichiers depuis votre ordinateur local. **Note** Pour le chargement local, vous pouvez charger un maximum de 20 fichiers de flux à la fois. Pour les importations plus importantes, utilisez Amazon S3. Si vous sélectionnez un dossier à importer, tous les fichiers de flux figurant dans les sous-dossiers sont également importés. 1. Choisissez **Importer les données**. Si l’importation réussit, vous recevez une notification indiquant qu’un nombre `X` de fichiers de flux ont été importés avec succès. Si l'importation de vos fichiers de flux échoue, vous recevez une notification dans l'application SageMaker Canvas. Choisissez **Voir les erreurs** dans le message de notification pour consulter les messages d’erreur individuels et obtenir des conseils sur la manière de reformater les fichiers de flux mal formatés. Une fois l'importation de vos fichiers de flux terminée, rendez-vous sur la page **Data Wrangler** de l'application SageMaker Canvas pour afficher vos flux de données. Vous pouvez essayer d’ouvrir un flux de données pour vérifier qu’il s’affiche comme prévu.