Я собираюсь использовать Packer для создания некоторых из наших виртуальных машин, и я тщательно проработал пример Вот. Когда я пытаюсь запустить packer build
command я получаю следующую ошибку:
==> amazon-ebs: Ошибка при запуске исходного экземпляра: указанный тип экземпляра может использоваться только в VPC. Для выполнения запроса требуется идентификатор подсети или идентификатор сетевого интерфейса. (VPCResourceNotSpecified)
Я решил эту проблему (см. Править), но, копая, я обнаружил эта страница заявив, что я также могу использовать экземпляр Amazon, но вместо этого он рекомендует использовать сборку amazon-ebs.
У меня вопрос, есть ли недостатки в использовании amazon-instance вместо amazon-ebs или наоборот? Кажется, что отливы будет намного легче раскручивать и поддерживать. Так ли это? Теряю ли я что-нибудь, используя одно или другое?
редактировать Проблема, с которой я столкнулся, была связана не с разрешениями, а с наличием instance_type
из "t2.micro"
вместо того "m3.medium"
. Я все же хотел бы знать недостатки ebs vs instance.
EBS использует сетевое хранилище для корневого устройства вашего экземпляра EC2, легко развернуть экземпляр и создать AMI с помощью EBS, поскольку том уже доступен за пределами вашего экземпляра. EBS также позволяет использовать корневое устройство большего размера - более 8 ГБ.
Экземпляр-хранилища (или эфемерные) корневые устройства несколько более устойчивы, поскольку они не полагаются на сетевое соединение, но для них сложнее создать AMI: вы должны загрузить ключи на машину, запускаемую упаковщиком, связать корневое устройство, загрузить его в S3, а затем создайте AMI, используя корзину S3. Корневые устройства с хранилищем экземпляров обычно имеют размер около 8 ГБ, что также может быть недостатком.
Мне нравится придерживаться инстанса EC2 в инстанс-хранилище в качестве личного предпочтения - по анекдотическим случаям, когда я был поражен тем, что EC2 не работает, это было в значительной степени из-за проблем с EBS.