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