Réduction de la taille du volume Amazon EBS

J'ai vu cette réponse pour l'augmentation des volumes d'EBS , mais je voudrais en réduire une.

Les images par défaut du serveur Ubuntu sont de 15 Go alors que je n'ai vraiment besoin que de 2 Go maximum (j'utilise un volume différent pour les données). Existe-t-il un moyen de réduire la taille du volume?

J'avais la même question que vous, alors j'ai trouvé comment le faire.

Tout d'abord, je l'ai fait à partir de l'ami Ubuntu 32 bits soutenu par EBS de la région USA-Est, d'autres systèmes d'exploitation ou images peuvent fonctionner différemment. Cependant, je soupçonne que vous devriez être d'accord, tant que vous utilisez un système de fichiers ext *. Cela pourrait fonctionner sur d'autres systèmes de fichiers, mais vous devrez trouver comment les redimensionner par vous-même.

Les étapes sont essentiellement:

1. Attachez deux volumes à une instance en cours d'exécution, le premier basé sur l'instantané que vous souhaitez réduire et le second un volume vierge ayant la nouvelle taille que vous souhaitez réduire.

2. Vérifiez le système de fichiers du premier volume et réparez les erreurs.

3. Rétrécissez le système de fichiers sur le premier volume afin qu'il ne soit aussi grand que nécessaire pour contenir les données.

4. Copiez le système de fichiers du premier volume au second.

5. Développez le système de fichiers du deuxième volume jusqu'à sa taille maximale.

6. Assurez-vous que tout semble bon en vérifiant le deuxième volume pour les erreurs.

7. Prenez un instantané du deuxième volume.

8. Créez une image de machine basée sur l'instantané du deuxième volume que vous venez de prendre.

Vous devez d'abord obtenir des informations de l'ami que vous souhaitez réduire. En particulier, vous avez besoin de l'ID du noyau et de l'ID du disque virtuel, le cas échéant (l'image que j'ai rétrécie n'avait pas de disque virtuel). Toutes ces informations devraient être disponibles à partir de la console de gestion aws, dans la fenêtre AMI.

L'ID du noyau ressemble à kia-xxxxxxxx, et l'ID d'instantané ressemble à snap-xxxxxxxx, et les ID de disque virtuel ressemblent à RIA-xxxxxxxx.

Ensuite, lancez une instance Linux. J'ai lancé une instance Ubuntu. Vous pouvez utiliser une instance t1.micro si vous le souhaitez. Il ne faut pas beaucoup de pouvoir pour effectuer ces prochaines étapes.

Une fois la machine en cours d'exécution, joignez l'instantané que vous avez noté à la première étape. Dans mon cas, je l'ai attaché à / dev / sdf

Ensuite, créez un nouveau volume, ayant la taille souhaitée. Dans mon cas, j'ai créé un volume de 5 Go, car c'est la taille à laquelle je voulais le réduire. Ne créez pas ce nouveau volume à partir d'un instantané. Nous avons besoin d'un nouveau volume vierge. Ensuite, attachez-le à l'instance en cours d'exécution, dans mon cas, je l'ai attaché en tant que / dev / sdg

Ensuite, ssh dans la machine mais ne montez pas les volumes attachés.

À ce stade, je me suis trompé du côté de la paranoïa, et j'ai choisi de vérifier le système de fichiers sur le grand volume, juste pour m'assurer qu'il n'y avait pas d'erreurs. Si vous êtes sûr qu'il n'y en a pas, vous pouvez ignorer cette étape:

$ sudo e2fsck -f /dev/sdf

Ensuite, j'ai redimensionné le système de fichiers sur le grand volume afin qu'il soit seulement aussi volumineux que les données sur le disque:

$ sudo resize2fs -M -p /dev/sdf

Le -M le réduit et le -p imprime la progression.

Resize2fs devrait vous indiquer la taille du système de fichiers shrunkin. Dans mon cas, cela m'a donné la taille en blocs 4K.

Nous copions maintenant le système de fichiers shrunkin sur le nouveau disque. Nous allons copier les données en blocs de 16 Mo, nous devons donc déterminer combien de blocs de 16 Mo nous devons copier. C'est là que cette taille réduite du système de fichiers entre en jeu.

Dans mon cas, le système de fichiers réduit faisait un peu plus de 1 Go, car j'avais installé beaucoup d'autres programmes sur le système Ubuntu de base avant de prendre un instantané. J'aurais probablement pu m'en tirer en copiant simplement la taille du système de fichiers arrondie au 16 Mo le plus proche, mais je voulais jouer en toute sécurité.

Donc, 128 fois des morceaux de 16 Mo = 2 Go:

$ sudo dd if=/dev/sdf ibs=16M of=/dev/sdg obs=16M count=128

J'ai copié en blocs de 16 Mo car avec EBS, vous payez pour chaque lecture et écriture, donc je voulais en minimiser le plus possible le nombre. Je ne sais pas si le faire de cette façon l'a fait, mais cela n'a probablement pas fait de mal.

Nous devons ensuite redimensionner le système de fichiers que nous venons de copier sur le nouveau volume afin qu'il utilise tout l'espace disponible sur le volume.

$ sudo resize2fs -p /dev/sdg

Enfin, vérifiez-le, pour vous assurer que tout va bien:

$ sudo e2fsck -f /dev/sdg

C'est tout ce que nous devons faire dans cette machine, bien que cela ne puisse pas nuire au montage du nouveau volume, juste comme test. Cependant, cette étape est presque certainement facultative, car e2fsck aurait dû détecter des problèmes.

Nous devons maintenant prendre un instantané du nouveau volume et créer une AMI en fonction de celui-ci. Nous avons terminé avec la machine, vous pouvez donc y mettre fin si vous le souhaitez.

Assurez-vous que le petit volume n'est pas monté si vous l'avez monté, puis prenez-en un instantané. Encore une fois, vous pouvez le faire dans la console de gestion.

La dernière étape nécessite les outils ec2 en ligne de commande.

MODIFIER:

Depuis que cette réponse a été publiée, la console AWS vous permet de simplement cliquer avec le bouton droit sur un instantané et de sélectionner Créer une image à partir d'un instantané. Vous devrez toujours sélectionner l'ID de noyau approprié. S'il n'apparaît pas dans la liste, assurez-vous d'avoir sélectionné l'architecture appropriée.

Nous utilisons l'application ec2-register pour enregistrer une AMI en fonction de l'instantané que vous venez de prendre, alors notez la valeur snap-xxxxxxxx de l'instantané que vous venez de prendre.

Vous devez ensuite utiliser une commande comme:

ec2-register -C cert.pem -K sk.pem -n The_Name_of_Your_New_Image
-d Your_Description_of_This_New_AMI --kernel aki-xxxxxxxx
-b "/dev/sda1=snap-xxxxxxxx" --root-device-name /dev/sda1

Vous devez bien sûr remplacer l'ID du noyau par celui que vous avez noté au début et l'ID de l'instantané par celui que vous avez créé à l'étape précédente. Vous devez également le pointer vers votre clé secrète (appelée sk.pem) ci-dessus et votre certificat x509 (appelé cert.pem). Vous pouvez bien sûr choisir ce que vous voulez pour le nom et la description.

J'espère que cela t'aides.

Ouais, je me suis aussi posé la question. Le tutoriel suivant est exagéré, mais je pense qu'il contient les outils nécessaires: http://www.linuxconfig.org/Howto_CREATE_BUNDLE_UPLOAD_and_ACCESS_custom_Debian_AMI_using_ubuntu

Au lieu d'installer sur une nouvelle image disque comme ci-dessus, il devrait être possible de lancer la grande AMI, de créer un nouvel EBS, d'attacher EBS à l'instance en cours d'exécution et de copier l'AMI en cours d'exécution sur le nouvel EBS. Enfin, enregistrez le nouvel EBS en tant qu'AMI.

Jetez un œil à ce blog pour plus d'informations, en particulier le commentaire de freremark: http://alestic.com/2010/01/public-ebs-boot-amis-for-ubuntu-on-amazon-ec2

Sur une note finale, l'euca2ools semble être un excellent remplacement pour les outils ec2-ami - euca2ools inclut des pages de manuel réelles! Ils ont tous les mêmes noms que les commandes ec2- *, juste avec le préfixe euca-. http://open.eucalyptus.com/wiki/Euca2oolsUsing

Je voulais réduire la taille du volume utilisé par une instance EC2 générale. J'ai suivi des étapes similaires aux autres réponses ici, mais j'ai rencontré un problème. Voici donc ce que je devais faire pour réduire mon volume racine ...

Dans la console AWS

 1. Stop the source EC2 instance
 2. Create a snapshot of the volume you want to shrink
 3. Use the snapshot to create a new 'source' volume
 4. Created a new volume with smaller size (made sure it was big enough for the data on source)
 5. Attached both volumes to any EC2 instance (mine were /dev/sdf = source & /dev/sdg = target)
 6. Start the EC2 instance

Sur l'instance EC2

 7. sudo su -   (everything from here is run as root)
 8. mkdir /source /target
 9. mount -t ext4 /dev/sdf /source
 10. mkfs.ext4 /dev/sdg
 11. mount -t ext4 /dev/sdg /target
 12. rsync -aHAXxSP /source/ /target 
     ** notice that there is no trailing '/' after target if 
       you put one there your data will be copied to 
       /target/source and you will have to move it up a directory
 13. cat /boot/grub/grub.conf  (indicated that grub is using root=LABEL=/)
 14. cat /source/etc/fstab (indicated that fstab was also using LABEL=/)
 15. e2label /dev/sdg /
 16. umount /source
 17. umount /target

De retour dans AWS Console

 18. Stop the instance
 19. Detach ALL volumes from the instance
 20. Attach the 'target' volume to the instance using /dev/sda1 as the device
 21. Start the instance

Voici où nous avons rencontré un problème qui n'a pas été mentionné pour autant que je puisse trouver. L'instance a bien commencé, super! Mais quand j'ai essayé de ssh vers l'instance, je n'ai pas pu me connecter. Après de nombreuses variations des étapes ci-dessus, j'ai finalement décidé d'essayer d'utiliser le volume racine à partir d'une instance EC2 fraîchement lancée.

Dans la console AWS

 1. Create a new EC2 instance with the right sized root volume
 2. Stop the new instance
 3. Detach the /dev/sda1 volume from the new instance
    ** used the 'source' volume from before & the new volume we just detached
 4. Attached both volumes to the original EC2 instance (/dev/sdf & /dev/sdg)
 5. Start the instance with the attached volumes

Sur l'instance EC2

 1. sudo su - 
 2. mkdir /source /target (only need to do this if you don't already have these directories)
 3. mount -t ext4 /dev/sdf /source
 4. mount -t ext4 /dev/sdg /target (no need to create a file system because it is already there)
 5. rsync -aHAXxSP /source/ /target 
 6. umount /source
 7. umount /target

De retour dans AWS Console

 1. Stop the instance
 2. Detach the 'source' and 'target' volumes from instance
 3. Attach the 'target' volume to the instance from step 1 using /dev/sda1 as the device
 4. Start the instance
 5. ** we use an elastic IP so we just reassigned the IP to the new instance

J'espère que cela aide quelqu'un