Я видел этот ответ для увеличения объемов EBS, но я бы хотел уменьшить одну.
Образы сервера Ubuntu по умолчанию составляют 15 ГБ, в то время как мне действительно нужно максимум 2 ГБ (я использую другой объем для данных). Есть ли способ уменьшить размер тома?
У меня был тот же вопрос, что и у вас, поэтому я придумал, как это сделать.
Во-первых, я сделал это из 32-разрядной ОС Ubuntu с поддержкой EBS из региона Восток США, другие ОС или образы могут работать по-другому. Однако я подозреваю, что с вами все будет в порядке, если вы используете файловую систему ext *. Это может работать в других файловых системах, но вам придется выяснить, как изменить их размер самостоятельно.
Шаги в основном:
Присоедините два тома к работающему экземпляру, первый на основе снимка, который вы хотите сжать, а второй - пустой том с новым размером, до которого вы хотите сжать.
Проверьте файловую систему первого тома и исправьте ошибки.
Уменьшите файловую систему на первом томе так, чтобы она была ровно настолько большой, насколько это необходимо для хранения данных.
Скопируйте файловую систему с первого тома на второй.
Разверните файловую систему на втором томе до максимального размера.
Убедитесь, что все в порядке, проверив второй том на наличие ошибок.
Сделайте снимок второго тома.
Создайте образ машины на основе снимка второго тома, который вы только что сделали.
Сначала вам нужно получить некоторую информацию от ami, которого вы хотите уменьшить. В частности, вам понадобится идентификатор ядра и идентификатор виртуального диска, если таковой имеется (сжатый мной образ не имел виртуального диска). Вся эта информация должна быть доступна из консоли управления aws в окне AMI.
Идентификатор ядра выглядит как kia-xxxxxxxx, идентификатор моментального снимка выглядит как snap-xxxxxxxx, а идентификаторы виртуального диска выглядят как RIA-xxxxxxxx.
Затем запустите экземпляр Linux. Я запустил экземпляр Ubuntu. Если хотите, вы можете использовать экземпляр t1.micro. Для выполнения следующих шагов не потребуется много энергии.
После того, как машина заработает, прикрепите снимок, который вы записали на первом шаге. В моем случае я прикрепил его к / dev / sdf
Затем создайте новый том нужного размера. В моем случае я создал том 5 ГБ, так как именно до этого размера я хотел его уменьшить. Не создавайте этот новый том из снимка. Нам нужен новый пустой том. Затем прикрепите его к работающему экземпляру, в моем случае я прикрепил его как / dev / sdg
Затем подключите ssh к машине, но не монтируйте подключенные тома.
На этом этапе я допустил ошибку на стороне паранойи и решил проверить файловую систему на большом томе, просто чтобы убедиться, что ошибок нет. Если вы уверены, что их нет, можете пропустить этот шаг:
$ sudo e2fsck -f /dev/sdf
Затем я изменил размер файловой системы на большом томе так, чтобы он был размером с данные на диске:
$ sudo resize2fs -M -p /dev/sdf
-M сжимает его, а -p печатает прогресс.
Resize2fs должен сказать вам, насколько велика файловая система shrunkin. В моем случае он дал мне размер в блоках 4K.
Теперь скопируем файловую систему shrunkin на новый диск. Мы собираемся скопировать данные фрагментами по 16 МБ, поэтому нам нужно выяснить, сколько фрагментов по 16 МБ нам нужно скопировать. Вот где приходит на помощь этот уменьшенный размер файловой системы.
В моем случае сжатая файловая система была чуть более 1 ГБ, потому что я установил много других программ в базовой системе Ubuntu, прежде чем делать снимок. Я, вероятно, мог бы уйти, просто скопировав размер файловой системы с округлением до ближайших 16 МБ, но я хотел перестраховаться.
Итак, 128 раз по 16 МБ = 2 ГБ:
$ sudo dd if=/dev/sdf ibs=16M of=/dev/sdg obs=16M count=128
Я копировал блоками по 16 МБ, потому что с EBS вы платите за каждое чтение и запись, поэтому я хотел минимизировать их количество как можно больше. Не знаю, повлияло ли это на это, но, вероятно, это не повредило.
Затем нам нужно изменить размер файловой системы, которую мы только что скопировали на новый том, чтобы она использовала все доступное пространство на томе.
$ sudo resize2fs -p /dev/sdg
Наконец, проверьте его, чтобы убедиться, что все в порядке:
$ sudo e2fsck -f /dev/sdg
Это все, что нам нужно сделать на этой машине, хотя смонтировать новый том просто в качестве теста не помешает. Однако этот шаг почти наверняка необязателен, поскольку e2fsck должен был выявить любые проблемы.
Теперь нам нужно сделать снимок нового тома и создать на его основе AMI. Мы закончили с машиной, так что вы можете отключить ее, если хотите.
Убедитесь, что небольшой том отключен, если вы его смонтировали, а затем сделайте его снимок. Опять же, вы можете сделать это в консоли управления.
Последний шаг требует инструментов командной строки ec2.
РЕДАКТИРОВАТЬ:
Поскольку этот ответ был опубликован, консоль AWS позволяет вам просто щелкнуть снимок правой кнопкой мыши и выбрать «Создать образ из снимка». Вам все равно нужно будет выбрать соответствующий идентификатор ядра. Если его нет в списке, убедитесь, что вы выбрали подходящую архитектуру.
Мы используем приложение 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
Конечно, вам нужно заменить идентификатор ядра на тот, который вы записали в начале, а идентификатор моментального снимка - на тот, который вы создали на предыдущем шаге. Вам также необходимо указать его на свой секретный ключ (называемый sk.pem) выше и ваш сертификат x509 (называемый cert.pem). Вы, конечно, можете выбрать все, что хотите, для названия и описания.
Надеюсь это поможет.
Да, мне тоже это было интересно. Следующее руководство является излишним, но я думаю, что оно содержит необходимые инструменты: http://www.linuxconfig.org/Howto_CREATE_BUNDLE_UPLOAD_and_ACCESS_custom_Debian_AMI_using_ubuntu
Вместо установки на новый образ диска, как указано выше, должна быть возможность запустить большой AMI, создать новый EBS, присоединить EBS к работающему экземпляру и скопировать работающий AMI в новый EBS. Наконец, зарегистрируйте новый EBS как AMI.
Взгляните на это сообщение в блоге, чтобы узнать больше, особенно на комментарий freremark: 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
Надеюсь, это кому-то поможет