Amazon EBSボリュームサイズの縮小
私は EBSボリュームの増加に対するこの回答 を見てきましたが、それを縮小したいと思います。
デフォルトのUbuntu Serverイメージは15 GBですが、実際に必要なのは最大2 GBだけです（データ用に別のボリュームを使用しています）。ボリュームのサイズを縮小する方法はありますか？
私はあなたと同じ質問をしたので、それを行う方法を考え出しました。
まず、US-EastリージョンのUbuntu 32ビットEBS-backed AMIからこれを行いました。他のOSまたはイメージは異なる動作をする場合があります。ただし、ext *ファイルシステムを使用している限り、問題はないはずです。他のファイルシステムでも機能するかもしれませんが、自分でサイズを変更する方法を理解する必要があります。
手順は基本的に次のとおりです。
実行中のインスタンスに2つのボリュームを接続します。1つは圧縮したいスナップショットに基づいて、2つ目は圧縮したい新しいサイズの空のボリュームです。
最初のボリュームのファイルシステムを確認し、エラーを修復します。
データを保持するために必要なだけの大きさになるように、最初のボリュームのファイルシステムを縮小します。
最初のボリュームから2番目のボリュームにファイルシステムをコピーします。
2番目のボリュームのファイルシステムを最大サイズに拡張します。
2番目のボリュームにエラーがないか確認して、すべてが適切に見えることを確認します。
2番目のボリュームのスナップショットを作成します。
取得した2番目のボリュームのスナップショットに基づいてマシンイメージを作成します。
最初に、縮小するAMIからいくつかの情報を取得する必要があります。特に、もしあれば、カーネルIDとRAMディスクIDが必要です（私が縮小したイメージにはRAMディスクがありませんでした）。このすべての情報は、AMIウィンドウのaws管理コンソールから入手できます。
カーネルIDはkia-xxxxxxxxのようになり、スナップショットIDはsnap-xxxxxxxxのようになり、ramdisk IDはRIA-xxxxxxxxのようになります。
次に、Linuxインスタンスを起動します。 Ubuntuインスタンスを起動しました。必要に応じて、t1.microインスタンスを使用できます。これらの次のステップを実行するのにそれほど力は必要ありません。
マシンの実行後、最初のステップで書き留めたスナップショットを添付します。私の場合、それを/ dev/sdfにアタッチしました
次に、必要なサイズの新しいボリュームを作成します。私の場合、5GBのボリュームを作成しました。これは、それを縮小したいサイズだからです。この新しいボリュームをスナップショットから作成しないでください。新しい空のボリュームが必要です。次に、実行中のインスタンスにアタッチします。私の場合は、/ dev/sdgとしてアタッチします。
次に、マシンにSSHで接続しますが、接続されたボリュームはマウントしません。
この時点で、私は偏執狂の側に誤りがあり、エラーがないことを確認するためだけに、大容量ボリュームのファイルシステムをチェックすることにしました。何もないと確信している場合は、この手順をスキップできます。
$ Sudo e2fsck -f /dev/sdf
次に、大きなボリュームのファイルシステムのサイズを変更して、ディスク上のデータと同じ大きさになるようにしました。
$ Sudo resize2fs -M -p /dev/sdf
-Mはそれを縮小し、-pは進行状況を出力します。
Resize2fsはshrunkinファイルシステムの大きさを教えてくれるはずです。私の場合、それは私に4Kブロックのサイズを与えました。
次に、shrunkinファイルシステムを新しいディスクにコピーします。データを16MBチャンクでコピーするので、コピーする必要のある16MBチャンクの数を把握する必要があります。ここで、縮小されたファイルシステムのサイズが役に立ちます。
私の場合、スナップショットを取る前に、基本的なUbuntuシステムに他の多くのプログラムをインストールしていたため、縮小されたファイルシステムは1 GBをわずかに超えていました。おそらく、ファイルシステムのサイズを最も近い16MBに切り上げたサイズをコピーするだけで済むでしょうが、安全に再生したかったのです。
つまり、16MBチャンクの128倍= 2GB：
$ Sudo dd if=/dev/sdf ibs=16M of=/dev/sdg obs=16M count=128
16 MBのブロックでコピーしました。これは、EBSでは、読み取りと書き込みのそれぞれに料金がかかるため、それらの数をできるだけ最小限にしたかったからです。このようにしたかどうかはわかりませんが、おそらく害はありませんでした。
次に、新しいボリュームにコピーしたファイルシステムのサイズを変更して、ボリューム上のすべての使用可能なスペースを使用する必要があります。
$ Sudo resize2fs -p /dev/sdg
最後にそれをチェックして、すべてが正常であることを確認します。
$ Sudo e2fsck -f /dev/sdg
このマシンでこれを行う必要があるのはこれだけですが、テストとして、新しいボリュームをマウントするのに支障はありませんでした。ただし、e2fsckで問題が検出されたはずなので、この手順はほぼ確実にオプションです。
新しいボリュームのスナップショットを作成し、それに基づいてAMIを作成する必要があります。これでマシンは完成したので、必要に応じて終了できます。
マウントした場合は、小さいボリュームがマウント解除されていることを確認してから、そのスナップショットを作成します。繰り返しますが、これは管理コンソールで行うことができます。
最後のステップでは、コマンドラインec2ツールが必要です。
編集：
この回答が投稿されたので、AWSコンソールでは、スナップショットを右クリックして[スナップショットからイメージを作成]を選択するだけです。適切なカーネルIDを選択する必要があります。リストに表示されない場合は、適切なアーキテクチャを選択していることを確認してください。
Ec2-registerアプリケーションを使用して、取得したばかりのスナップショットに基づいてAMIを登録するため、取得したばかりのスナップショットからsnap-xxxxxxxxの値を書き留めます。
次に、次のようなコマンドを使用する必要があります。
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
もちろん、カーネルIDを最初に書き留めたものに、スナップショットIDを前のステップで作成したものに置き換える必要があります。また、上記の秘密鍵（sk.pem）とx509証明書（cert.pem）を指す必要があります。もちろん、名前と説明は自由に選択できます。
お役に立てれば。
うん、これも気になった。次のチュートリアルはやり過ぎですが、必要なツールが含まれていると思います： http://www.linuxconfig.org/Howto_CREATE_BUNDLE_UPLOAD_and_ACCESS_custom_Debian_AMI_using_ubunt
上記のように新しいディスクイメージにインストールする代わりに、大きなAMIを起動し、新しいEBSを作成し、EBSを実行中のインスタンスに接続し、実行中のAMIを新しいEBSにコピーすることができます。最後に、新しいEBSをAMIとして登録します。
いくつかの背景、特にフレアマークのコメントについては、このブログ投稿をご覧ください： http://alestic.com/2010/01/public-ebs-boot-amis-for-ubuntu-on-Amazon -ec2
最後に、euca2oolsはec2-AMI-toolsの素晴らしい代替品のようです-euca2oolsには実際のマンページが含まれています！それらはすべてec2- *コマンドと同じ名前で、euca-プレフィックスが付いています。 http://open.eucalyptus.com/wiki/Euca2oolsUsing
一般的なEC2インスタンスで使用されているボリュームのサイズを小さくしたいと思っていました。ここで他の回答と同様の手順を実行しましたが、問題が発生しました。ルートボリュームを縮小するために私がしなければならなかったことはここにあります...
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
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
AWSコンソールに戻る
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
ここで、私が知る限り言及されていない問題に遭遇しました。インスタンスは正常に起動しました。しかし、インスタンスにsshしようとしたとき、接続できませんでした。上記の手順の多くのバリエーションの後で、最終的に、新しくスピンアップしたEC2インスタンスのルートボリュームを使用することを決定しました。
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
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
AWSコンソールに戻る
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
これが誰かを助けることを願っています