Po pierwsze, czułem potrzebę opublikowania nowej odpowiedzi z powodu następujących subtelnych problemów z istniejącymi odpowiedziami i po otrzymaniu pytania o mój komentarz do odpowiedzi @ qwertzguy . Oto problemy z obecnymi odpowiedziami:
- Odpowiedź akceptowaną z @MatthieuCerda zdecydowanie nie działa niezawodnie, a przynajmniej nie na jakichkolwiek przypadkach VPC Sprawdziłem przeciw. (W moich instancjach otrzymuję nazwę VPC
hostname -d, która jest używana do wewnętrznego DNS, a nie do niczego z „amazonaws.com”).
- Najwyższej głosowało odpowiedź od @qwertzguy nie działa na nowych instancji M5 lub C5 , które nie mają tego pliku. Amazon zaniedbuje dokumentowanie tego zachowania AFAIK, chociaż strona dokumentu na ten temat mówi „... Jeśli / sys / hypervisor / uuid istnieje ...”. Poprosiłem AWS o wsparcie, czy zmiana była zamierzona, patrz poniżej †.
- Odpowiedź od @Jer niekoniecznie działają wszędzie, ponieważ
instance-data.ec2.internalwyszukiwanie DNS może nie działać. Na instancji Ubuntu EC2 VPC, na której właśnie testowałem, widzę:
$ curl http://instance-data.ec2.internal
curl: (6) Could not resolve host: instance-data.ec2.internal
co spowodowałoby, że kod polegający na tej metodzie błędnie stwierdziłby, że nie ma go na EC2!
- Odpowiedź do korzystania
dmidecode z @tamale może działać, ale opiera się na was.) O dmidecodedostępne na przykład, i b.), Mający korzenie lub sudozdolność hasłem mniej z poziomu kodu.
- Odpowiedź sprawdzić / sys / devices / virtual / DMI / id / bios_version z @spkane jest niebezpiecznie mylące! Sprawdziłem jeden Ubuntu 14.04 wystąpienie M5 i dostał
bios_versionod 1.0. Ten plik w ogóle nie jest udokumentowany w dokumentacji Amazon , więc naprawdę nie polegałbym na nim.
- Pierwsza część odpowiedzi @ Chris-Montanaro, aby sprawdzić niewiarygodny adres URL innej firmy i użyć
whoiswyniku jest problematyczna na kilku poziomach. Uwaga: adres URL sugerowany w tej odpowiedzi to teraz strona 404! Nawet jeśli znalazłeś usługę innej firmy, która działała, byłaby stosunkowo bardzo wolna (w porównaniu do lokalnego sprawdzania pliku) i prawdopodobnie napotkałaby problemy ograniczające szybkość lub problemy z siecią, a może nawet twoja instancja EC2 nie ma zewnętrzny dostęp do sieci.
- Druga sugestia w odpowiedzi @ Chris-Montanaro, aby sprawdzić http://169.254.169.254/, jest nieco lepsza, ale inny komentator zauważa, że inni dostawcy usług w chmurze udostępniają ten adres URL metadanych instancji, dlatego należy uważać, aby uniknąć fałszywego pozytywne. Ponadto nadal będzie znacznie wolniejszy niż plik lokalny. Widziałem, że ta kontrola jest szczególnie wolna (kilka sekund do powrotu) w przypadku mocno załadowanych instancji. Powinieneś również pamiętać o przekazaniu argumentu
-mlub --max-timecurl, aby uniknąć zawieszania się przez bardzo długi czas, szczególnie w przypadku instancji innej niż EC2, gdzie ten adres może prowadzić do nikąd i zawiesić się (jak w odpowiedzi @ algal ).
Nie widzę też, aby ktokolwiek wspominał o udokumentowanym wycofaniu się Amazon z sprawdzania (możliwego) pliku /sys/devices/virtual/dmi/id/product_uuid.
Kto wiedział, że ustalenie, czy korzystasz z EC2, może być tak skomplikowane ?! OK, teraz, gdy mamy (większość) problemów z wymienionymi podejściami na liście, oto sugerowany fragment bash, aby sprawdzić, czy korzystasz z EC2. Myślę, że powinno to ogólnie działać na prawie wszystkich instancjach Linuksa, instancje Windows są ćwiczeniem dla czytelnika.
#!/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
Oczywiście można to rozszerzyć o jeszcze więcej kontroli rezerwowych i uwzględnić paranoję dotyczącą radzenia sobie np. Z fałszywym pozytywnym /sys/hypervisor/uuidskutkiem, by zacząć od „ec2” przez przypadek i tak dalej. Ale jest to wystarczająco dobre rozwiązanie do celów ilustracyjnych i prawdopodobnie prawie wszystkich niepatologicznych przypadków użycia.
[†] Otrzymałem to wyjaśnienie od wsparcia AWS dotyczące zmiany dla instancji c5 / m5:
Instancje C5 i M5 używają nowego stosu hiperwizora, a powiązane sterowniki jądra nie tworzą plików w sysfs (który jest montowany w / sys), jak robią to sterowniki Xen używane przez inne / starsze typy instancji . Najlepszym sposobem na wykrycie, czy system operacyjny działa na instancji EC2, jest uwzględnienie różnych możliwości wymienionych w połączonej dokumentacji .