Сначала я почувствовал необходимость опубликовать новый ответ из-за следующих тонких проблем с существующими ответами и после получения вопроса о моем комментарии к ответу @ qwertzguy . Вот проблемы с текущими ответами:
- Общепринятый ответ от @MatthieuCerda определенно не работает надежно, по крайней мере не на каких - либо VPC случаях я сверяюсь. (В моих случаях я получаю имя VPC для
hostname -d, которое используется для внутреннего DNS, а не что-либо с "amazonaws.com" в нем.)
- Высоким проголосовал ответ от @qwertzguy не работает на новых М5 или с5 случаях , которые не имеют этот файл. Amazon пренебрегает документированием этого изменения поведения AFAIK, хотя на странице документа по этому вопросу написано «... Если / sys / hypervisor / uuid существует ...». Я спросил службу поддержки AWS, было ли это изменение преднамеренным, см. Ниже †.
- Ответ от @Jer не обязательно будет работать везде , потому что
instance-data.ec2.internalDNS поиск не может работать. На экземпляре Ubuntu EC2 VPC, на котором я только что тестировал, я вижу:
$ 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в curl, чтобы избежать его зависания в течение очень долгого времени, особенно в случае экземпляра, не относящегося к 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, - это учесть различные возможности, перечисленные в документации, которую вы связали .