По-перше, я відчув необхідність розмістити нову відповідь через наступні тонкі проблеми з існуючими відповідями, і після отримання запитання про мій коментар до відповіді @ qwertzguy . Ось проблеми з поточними відповідями:
- Загальноприйнятий відповідь від @MatthieuCerda безумовно не працює надійно, принаймні не на будь - яких VPC випадках я звіряюся. (У моїх випадках я отримую ім'я VPC
hostname -d, яке використовується для внутрішнього DNS, не що-небудь із "amazonaws.com" в ньому.)
- Відповідь з найбільш високим голосом від @qwertzguy не працює на нових екземплярах m5 чи c5 , у яких цього файлу немає. Amazon нехтує документацією, щоб така поведінка змінила AFAIK, хоча на сторінці документа з цього приводу написано "... Якщо існує / sys / hypervisor / uuid ...". Я запитав підтримку AWS, чи була ця зміна навмисною, див. Нижче †.
- Відповідь від @Jer не обов'язково буде працювати скрізь , тому що
instance-data.ec2.internalDNS пошук не може працювати. На екземплярі VPC Ubuntu EC2, який я щойно перевіряв, я бачу:
$ curl http://instance-data.ec2.internal
curl: (6) Could not resolve host: instance-data.ec2.internal
що призведе до того, що код, покладаючись на цей метод, помилково зробить висновок, що він не на EC2!
- Відповідь використовувати
dmidecode від @tamale може працювати, але покладається на вас.) , Хто має dmidecodeдоступні на вашому екземплярі і б.) , Що мають корінь або sudoбезпарольний здатність з вашого коду.
- Відповідь для перевірки / системи / пристрої / віртуальний / DMI / ID / bios_version з @spkane загрозливо в оману! Я перевірив один Ubuntu 14.04 екземпляр m5, і отримав
bios_versionз 1.0. Цей файл взагалі не задокументований на документі Amazon , тому я б дуже не покладався на нього.
- Перша частина відповіді від @ Chris-Montanaro на перевірку ненадійної сторонньої URL-адреси та використання
whoisрезультату є проблематичною на кількох рівнях. Зверніть увагу, що URL-адреса, запропонована у цій відповіді, зараз - сторінка 404! Навіть якщо ви знайшли сторонню службу, яка працювала, вона була б порівняно дуже повільною (порівняно з перевіркою файлу локально) і, можливо, зіткнулася з обмеженнями швидкості або мережевими проблемами, або, можливо, ваш екземпляр EC2 навіть не має зовнішній доступ до мережі.
- Друга пропозиція у відповіді від @ Chris-Montanaro перевірити http://169.254.169.254/ трохи краще, але інший коментатор зазначає, що інші постачальники хмари роблять доступною URL-адресу метаданих цього примірника, тому вам слід бути обережними, щоб уникнути помилкових позитивні. Крім того, він все ще буде набагато повільніше, ніж локальний файл, я бачив, що ця перевірка є особливо повільною (кілька секунд, щоб повернутися) на сильно завантажених екземплярах. Крім того, вам слід пам’ятати про те, щоб передати аргумент
-mабо --max-timeаргумент для згортання, щоб уникнути його зависання дуже довго, особливо на екземплярі, який не стосується EC2, коли ця адреса може призвести нікуди і зависати (як у відповіді @ algal ).
Крім того, я не бачу, щоб хтось згадав про задокументовану відмову Amazon щодо перевірки (можливого) файлу /sys/devices/virtual/dmi/id/product_uuid.
Хто знав, що визначити, чи ти працюєш на EC2, може бути таким складним ?! Гаразд, тепер, коли у нас є (більшість) проблем із переліченими підходами, ось запропонований фрагмент bash, щоб перевірити, чи працюєте ви на EC2. Я думаю, що це має працювати в основному майже на будь-яких екземплярах Linux, екземпляри Windows - це вправа для читача.
#!/bin/bash
# This first, simple check will work for many older instance types.
if [ -f /sys/hypervisor/uuid ]; then
# File should be readable by non-root users.
if [ `head -c 3 /sys/hypervisor/uuid` == "ec2" ]; then
echo yes
else
echo no
fi
# This check will work on newer m5/c5 instances, but only if you have root!
elif [ -r /sys/devices/virtual/dmi/id/product_uuid ]; then
# If the file exists AND is readable by us, we can rely on it.
if [ `head -c 3 /sys/devices/virtual/dmi/id/product_uuid` == "EC2" ]; then
echo yes
else
echo no
fi
else
# Fallback check of http://169.254.169.254/. If we wanted to be REALLY
# authoritative, we could follow Amazon's suggestions for cryptographically
# verifying their signature, see here:
# https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-identity-documents.html
# but this is almost certainly overkill for this purpose (and the above
# checks of "EC2" prefixes have a higher false positive potential, anyway).
if $(curl -s -m 5 http://169.254.169.254/latest/dynamic/instance-identity/document | grep -q availabilityZone) ; then
echo yes
else
echo no
fi
fi
Очевидно, ви можете розширити це за допомогою ще більше резервних перевірок і включити параноїю щодо обробки, наприклад, помилкового позитиву від /sys/hypervisor/uuidвипадкового початку, починаючи з "ec2" випадково тощо. Але це досить хороше рішення для ілюстративних цілей і, мабуть, майже всіх непатологічних випадків використання.
[†] Повернення цього пояснення з підтримки AWS щодо зміни для екземплярів c5 / m5:
Екземпляри C5 і M5 використовують новий стек гіпервізорів, і пов'язані з ним драйвери ядра не створюють файли в sysfs (який встановлений на / sys), як це роблять драйвери Xen, використовувані іншими / старішими типами екземплярів . Найкращий спосіб виявити, чи працює операційна система на екземплярі EC2, - це врахувати різні можливості, перелічені в документації, яку ви зв'язали .