L’objectif de cet article est de décrire les différentes étapes à suivre afin de pouvoir exporter une VM d’un ESX on-premise et d’effectuer un import vers une solution AWS Elastic Cloud Compute (EC2).
Cette opération s’articulera autour de 3 étapes bien distinctes, à savoir :
- Export de la VM sur l’ESX on premise pour en faire une image OVA
- Définir les droits dans Amazon IAM afin de pouvoir effectuer les opérations d’export / import
- Importer l’image de la VM dans Amazon AWS pour en faire une AMI (Amazon Machine Image).
Export de la VM depuis un ESX on Premise.
Créer une image OVA depuis l’ESX
Avant de se lancer dans un export d’une VM sur un ESX, pensez tout d’abord, à vérifier que vous pourrez vous y connecter en RDP depuis un réseau public ou du moins, depuis un réseau interne à AWS lorsque celle ci sera migrée vers Amazon !
Soit l’on coupe directement le Firewall Windows le temps de l’export :
Ou bien, aller directement dans la configuration de celui ci et autoriser les connexions RDP depuis réseau privé ET public.
Vérifier que le port RDP 3389 est ouvert pour tous
Par la suite, il faudra arrêter la VM pour garantir qu’il n’y ait plus d’écriture sur le disque de l’OS.
Dans notre exemple, ce sera une VM sous Windows 7 SP1 32 bits
On fermera la session, et on arrêtera la VM, puis on passera à l’export dans l’utilitaire ESX Vsphere Client :
On choisira le format OVA pour exporter la VM que l’on nommera ici, MA_VM :
le fichier ainsi exporté se trouvera sur le disque local d’un ordinateur connecté à internet. Nous pourrons alors si on le souhaite, redémarrer notre VM sur notre ESX local.
Configuration AWS
Prérequis
importer une VM dans AWS va sous-entendre d’enregistrer un compte sous AWS avec les services suivants qui seront facturés via la méthode “Pay As You Go” en vigueur chez Amazon, à savoir :
- Un compte AWS qui sera le compte racine de notre accès Cloud.
- Un compte tiers, à partir duquel nous pourrons effectuer les opérations.
- L’utilitaire AWS CLI que l’on utilisera pour définir le rôle pour l’import ainsi que pour les commandes à exécuter.
- Un “bucket” S3 ou l’on enregistrera l’image OVA de notre VM.
Gestion de compte AWS
afin d’effectuer les opérations suivantes, nous choisirons de nous connecter, via la console AWS, sur le compte “racine”, auquel cas, nous aurons les droit SystemAdministrator pour créer un user tiers à qui nous affecterons les policies adequat.
On se connectera sur la console AWS https://console.aws.amazon.com, puis on ira dans les options liés à IAM afin de créer tout d’abord le groupe que l’on nommera par exemple, “capdata_team”, pour le moment, nous n’affecterons aucune stratégie à ce groupe.:
la prochaine étape consistera à créer un nouveau user, que nous appellerons “capdata_user” et l’attacher à ce groupe :
L’écran suivant nous indique les groupes que nous pourrons utiliser pour affecter ce user. On prendra donc Capdata_team.
Puis arrivera l’écran dans lequel nous aurons les informations sur l’Access Key Id et le Secret Key du user. Ceci sera à conserver très précieusement car ils seront nécessaires à la configuration de AWS CLI pour la suite des opérations.
S’il l’on édite le user “capdata_user”, on voit donc qu’il est dans le groupe “Capdata_team” :
L’étape suivante sera effectuer avec AWS CLI, interpréteur de commande que nous pourrons télécharger depuis la console AWS.
configuration via AWS CLI
La configuration se AWS CLI se fera via ligne de commande “cmd” sur un pc local dans laquelle nous renseignerons les Access key ID et Secret Key d’u nutilisateur ayant des pouvoir SystemAdministrator :
On créera ensuite un “bucket” S3 que l’on nommera “mycapdatabucket”. Attention au nom utilisé, celui ci devra être unique sur l’ensemble des régions AWS !!
Une fois ce bucket créé, on pourra alors aller y pousser notre fichier image OVA auparavant généré. A noter que nous pourrons le faire, soit via la console AWS, soit via AWS CLI , exemple avec AWS CLI :
Une fois le fichier OVA envoyé sur un bucket S3, il restera à configurer notre compte “capdata_user” afin qu’il puisse importer une VM.
Le compte capdata_user devra comporter les doits suivants comme le montre ce document JSON :
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:PutAnalyticsConfiguration",
"s3:GetObjectVersionTagging",
"s3:CreateBucket",
"s3:ReplicateObject",
"s3:GetObjectAcl",
"s3:DeleteBucketWebsite",
"s3:PutLifecycleConfiguration",
"s3:GetObjectVersionAcl",
"s3:PutObjectTagging",
"s3:DeleteObject",
"s3:DeleteObjectTagging",
"s3:GetBucketPolicyStatus",
"s3:GetBucketWebsite",
"s3:PutReplicationConfiguration",
"s3:DeleteObjectVersionTagging",
"s3:GetBucketNotification",
"s3:PutBucketCORS",
"s3:GetReplicationConfiguration",
"s3:ListMultipartUploadParts",
"s3:PutObject",
"s3:GetObject",
"s3:PutBucketNotification",
"s3:PutBucketLogging",
"s3:GetAnalyticsConfiguration",
"s3:GetObjectVersionForReplication",
"s3:GetLifecycleConfiguration",
"s3:ListBucketByTags",
"s3:GetInventoryConfiguration",
"s3:GetBucketTagging",
"s3:PutAccelerateConfiguration",
"s3:DeleteObjectVersion",
"s3:GetBucketLogging",
"s3:ListBucketVersions",
"s3:ReplicateTags",
"s3:RestoreObject",
"s3:ListBucket",
"s3:GetAccelerateConfiguration",
"s3:GetBucketPolicy",
"s3:PutEncryptionConfiguration",
"s3:GetEncryptionConfiguration",
"s3:GetObjectVersionTorrent",
"s3:AbortMultipartUpload",
"s3:PutBucketTagging",
"s3:GetBucketRequestPayment",
"s3:GetObjectTagging",
"s3:GetMetricsConfiguration",
"s3:DeleteBucket",
"s3:PutBucketVersioning",
"s3:GetBucketPublicAccessBlock",
"s3:ListBucketMultipartUploads",
"s3:PutMetricsConfiguration",
"s3:PutObjectVersionTagging",
"s3:GetBucketVersioning",
"s3:GetBucketAcl",
"s3:PutInventoryConfiguration",
"s3:GetObjectTorrent",
"s3:PutBucketWebsite",
"s3:PutBucketRequestPayment",
"s3:GetBucketCORS",
"s3:GetBucketLocation",
"s3:ReplicateDelete",
"s3:GetObjectVersion"
],
"Resource": [
"arn:aws:s3:::*/*",
"arn:aws:s3:::mycapdatabucket"
]
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"s3:GetAccountPublicAccessBlock",
"s3:ListAllMyBuckets",
"ec2:CancelImportTask",
"ec2:DescribeImportImageTasks",
"ec2:ImportImage"
],
"Resource": "*"
}
]
}
Le compte racine définit cette stratégie sur la console AWS, soit au niveau du user si nous voulons que celui ci possède ces droits, soit au niveau du groupe “capdata_team”.
Nous choisirons pour le moment, de restreindre ce privilège à notre user ‘capdata_user’ uniquement
Il faudra copier le JSON ci dessus, dans “Ajouter une stratégie en ligne”, puis l’onglet “JSON”..
Puis
Import du fichier OVA pour en faire une AMI
La suite du document consistera à présenter les étapes à suivre afin de générer une nouvelle AMI au sein de AWS à partir de l’image OVA.
Il faudra créer un rôle, que l’on nommera “vmimport” qui permettra d’effectuer cette tâche.
Le service aws “import/export” (vmie.amazonaws.com) qui sera utilisé par l’utilisateur aws capdata_user a besoin de droits spécifiques au niveau de notre bucket «mycapdatabucket »pour récupérer l’image ova provenant de notre esx on premise et également au niveau d’EC2 afin d’en créer une nouvelle AMI aws.
C’est pourquoi il faut établir une relation d’approbation entre le service aws ‘vmie.amazonaws.com’ et un rôle que l’on nommera « vmimport »qu’il pourra endosser afin de profiter de toutes les stratégie que nous allons définir un peu plus loin
Définition de la relation d’approbation entre le service vmie.amazonaws.com et notre rôle vmimport :
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "vmie.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals":{
"sts:Externalid": "vmimport"
}
}
}
]
}Nous enregistrerons ce code JSON dans un fichier nommé “trust-policy.json”. L’utilitaire AWS CLI sera utilisé pour cela :
Les différentes stratégies propres à ce nouveau rôle devront être requises, notamment pour les services EC2 et S3. Un fichier JSON sera également nécessaire pour cela. A noter l’appel, dans la partie “Resource” à notre bucket nommé “mycapdatabucket”. On nommera ce fichier ‘role-policy.json’ :
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket"
],
"Resource":[
"arn:aws:s3:::mycapdatabucket",
"arn:aws:s3:::mycapdatabucket/*"
]
},
{
"Effect":"Allow",
"Action":[
"ec2:ModifySnapshotAttribute",
"ec2:CopySnapshot",
"ec2:RegisterImage",
"ec2:Describe*"
],
"Resource":"*"
}
]
}On définira pour le rôle vmimport, une nouvelle stratégie, nommée également vmimport :
A partir de la, on pourra vérifier, soit via AWS CLI, soit via Console, que notre rôle est prêt et comporte les stratégies nécessaires :
On passera alors à l’étape de création de l’image AMI. On pourra vérifier via la console, par exemple, que le fichier OVA est bien la, et enregistrer dans un autre fichier JSON son emplacement précis. On nommera ce fichier “ma_vm.json” :
[
{
"Description": "MA VM de TEST Windows 7 VA",
"Format": "ova",
"UserBucket": {
"S3Bucket": "mycapdatabucket",
"S3Key": "MY_VM.ova"
}
}
]
Noter bien le nom ImportTaskId, non seulement celui ci sera demandé pour suivre la tâche, mais en plus, il sera utilisé comme nouveau nom de l’AMI Amazon. Si l’on souhaite suivre cette tâche, on exécutera l’option “describe-import-image_tasks“. Différents statuts seront alors visibles, updating, converting, pending, validating ….
Une fois cette import d’image terminé, nous pourrons choisir de retourner vers la console AWS afin de créer notre EC2. On vérifiera la bonne exécution de l’import. Compter un bon 1/4 d’heure environ pour la fin de cette opération.
Dans la console AWS, dans le service EC2, nous validons les AMI ici présentes
On retrouve notre AMI sous le nom lié à sa tâche dans import-image “import-ami-00fc8a76332d1b136”.
A partir de la, on pourra selectionner notre image, clique sur Lancer pour créer une EC2.
Nous arriverons alors directement sur le choix de type d’instance, et non pas sur le choix de l’OS. Ce sera l’OS de notre VM qui sera pris par défaut.
La nouvelle EC2 pourra être créée dans un subnet public afin d’obtenir une adresse IP publique, accessible depuis l’extèrieur en RDP. Les stratégies liés aux security groups auront été bien configurés avant cela.
La volume du disque lié à l’OS sera identique en terme de taille, à ce qui existait sur l’ESX. Un volume EBS sera alors automatiquement créé lors de l’étape de création de l’EC2.
Accessible via l’IP publique 35.180.172.96
Les mots de passe pour se connecter, seront identiques à ceux utiliser sur l’ESX on-premise (exemple, user capdata). L’accès via RDP pourra se faire via cette IP.
Conclusion
Les différentes étapes afin de créer une AMI sur Amazon peuvent, à première vue, sembler être compliquées.
En revanche, la configuration lié au rôle ainsi que les stratégies d’accès ne devra être effectué que lors de la première mise en place d’une opération d’export / import.
Par la suite, une fois ce rôle créé, il pourra être réutilisé pour de futures opérations comme celle ci.
L’avantage d’utiliser un interpréteur de commandes comme AWS CLI est d’interfacer cela avec un développement PowerShell ou bash/ksh, afin de packager des solutions de migrations on-premise -> Cloud de façon automatiques.
Attention tout de même lors de l’import d’une VM avec une version Windows 7 embarqué, il ne sera pas possible d’utiliser directement un agent SSM (Service System Manager) qui s’avère bien utile dans les opérations de récupérations d’instance ou de prise en main via un mode “console”
Emmanuel RAMI
Continuez votre lecture sur le blog :
- AWS : Backup Restore SQL Server RDS vers une EC2 ou On-Premise et vice versa ! (Emmanuel RAMI) [AWSSQL Server]
- SQL Server 2022 Backup / Restore via un bucket S3 sous AWS (Louis PROU) [AWSSQL Server]
- La gestion des connexions RDP sur une EC2 Amazon (Emmanuel RAMI) [AWS]
- AWS Oracle RDS Read Replicas : un Active Dataguard en mode PaaS ? (Emmanuel RAMI) [AWSNon classéOracle]
- Oracle RDS : effectuer des backup RMAN en mode PaaS. (Emmanuel RAMI) [AWSNon classéOracle]