Export d’une VM d’un ESX vers une EC2 AWS

mardi, décembre 11, 2018
By Emmanuel RAMI in AWS (erami@capdata-osmozium.com) [5 article(s)]

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 :

Fichier MA_VM.ova dans c:\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 :

aws configure

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 :

Le rôle nommé vmimport a été créé avec succès

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"
    }
}
]
La création de l’image est en cours, le status est à Pending.

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 ….

Nous sommes à 28% de progression, l’étape de conversion de l’OVA en AMI est en cours.

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. 

La tâche est terminée.

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 nouvelle EC2 sera taggé “ma_vm_windows_7”

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.

la VM est ainsi créé

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.

 

Le couple user/password sera semblable à ce qui existait sur l’ESX 

 

 

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 :




Cliquer pour partager cet article sur Viadeo
Cliquer sur "CAPTURER" pour sauvegarder cet article dans Evernote Clip to Evernote

Tags: , , ,

Leave a Reply