Zuerst hatte ich das Bedürfnis, eine neue Antwort zu schreiben, weil die vorhandenen Antworten folgende subtile Probleme aufwiesen und nachdem ich eine Frage zu meinem Kommentar zur Antwort von @ qwertzguy erhalten hatte . Hier sind die Probleme mit den aktuellen Antworten:
- Die akzeptierte Antwort von @MatthieuCerda funktioniert definitiv nicht zuverlässig, zumindest nicht auf VPC-Instanzen, die ich überprüft habe. (Auf meinen Instanzen erhalte ich einen VPC-Namen für
hostname -d, der für internes DNS verwendet wird, und nichts mit "amazonaws.com".)
- Die am höchsten bewertete Antwort von @qwertzguy funktioniert nicht auf neuen m5- oder c5-Instanzen , die diese Datei nicht haben. Amazon versäumt es, diese Verhaltensänderung AFAIK zu dokumentieren, obwohl auf der Dokumentseite zu diesem Thema "... If / sys / hypervisor / uuid exists ..." steht. Ich habe den AWS-Support gefragt, ob diese Änderung beabsichtigt ist, siehe unten †.
- Die Antwort von @Jer funktioniert nicht unbedingt überall, da die
instance-data.ec2.internalDNS-Suche möglicherweise nicht funktioniert. Auf einer Ubuntu EC2 VPC-Instanz, auf der ich gerade getestet habe, sehe ich:
$ curl http://instance-data.ec2.internal
curl: (6) Could not resolve host: instance-data.ec2.internal
Dies würde dazu führen, dass Code, der sich auf diese Methode stützt, fälschlicherweise zu dem Schluss kommt, dass es sich nicht um EC2 handelt!
- Die von @tamale zu verwendende
dmidecode Antwort mag funktionieren, hängt jedoch davon ab, dass Sie a.) dmidecodeAuf Ihrer Instanz verfügbar sind und b.) Über Root- oder sudokennwortlose Funktionen in Ihrem Code verfügen .
- Die Antwort auf / sys / devices / virtual / dmi / id / bios_version von @spkane ist gefährlich irreführend! Ich habe eine Ubuntu 14.04 m5-Instanz überprüft und eine
bios_versionvon 1.0. Diese Datei ist auf dem Amazon- Dokument überhaupt nicht dokumentiert , daher würde ich mich wirklich nicht darauf verlassen.
- Der erste Teil der Antwort von @ Chris-Montanaro zum Überprüfen einer unzuverlässigen Drittanbieter-URL und zum Verwenden
whoisdes Ergebnisses ist auf mehreren Ebenen problematisch. Beachten Sie, dass die in dieser Antwort vorgeschlagene URL derzeit eine 404-Seite ist! Selbst wenn Sie einen 3rd-Party - Service finden taten der Arbeit getan hat, wäre es vergleichsweise seinen sehr langsam ( im Vergleich zu einer Datei lokal Überprüfung) und möglicherweise in geschwindigkeitsbegrenzenden Probleme oder Netzwerkprobleme führen, oder möglicherweise Ihre EC2 - Instanz noch nicht einmal außerhalb des Netzwerkzugriffs.
- Der zweite Vorschlag in der Antwort von @ Chris-Montanaro , http://169.254.169.254/ zu überprüfen, ist etwas besser, aber ein anderer Kommentator merkt an, dass andere Cloud-Anbieter diese Instanz-Metadaten-URL zur Verfügung stellen. Sie müssen also vorsichtig sein, um Falsches zu vermeiden Positive. Außerdem wird es immer noch viel langsamer als eine lokale Datei sein. Ich habe gesehen, dass diese Überprüfung bei stark belasteten Instanzen besonders langsam ist (mehrere Sekunden bis zur Rückkehr). Sie sollten auch daran denken, ein
-moder ein --max-timeArgument an curl zu übergeben, um zu vermeiden, dass es sehr lange hängen bleibt, insbesondere in einer Nicht-EC2-Instanz, in der diese Adresse möglicherweise nirgendwohin führt und hängen bleibt (wie in der Antwort von @ algal ).
Ich sehe auch nicht, dass irgendjemand Amazon als dokumentierten Fallback für die Überprüfung der (möglichen) Datei erwähnt hat /sys/devices/virtual/dmi/id/product_uuid.
Wer hätte gedacht, dass die Entscheidung, ob Sie mit EC2 arbeiten, so kompliziert sein könnte ?! OK, jetzt, da wir (die meisten) Probleme mit den aufgelisteten Ansätzen haben, ist hier ein vorgeschlagenes Bash-Snippet, um zu überprüfen, ob Sie mit EC2 arbeiten. Ich denke, das sollte generell auf fast allen Linux-Instanzen funktionieren, Windows-Instanzen sind eine Übung für den Leser.
#!/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
Offensichtlich könnten Sie dies mit noch mehr Fallback-Checks erweitern und Paranoia über den Umgang mit z. B. einem /sys/hypervisor/uuidzufälligen Fehlalarm von "ec2" einschließen und so weiter. Dies ist jedoch eine ausreichend gute Lösung für Illustrationszwecke und wahrscheinlich für fast alle nicht-pathologischen Anwendungsfälle.
[†] Diese Erklärung zur Änderung für c5 / m5-Instanzen wurde vom AWS-Support zurückgegeben:
Die C5- und M5-Instanzen verwenden einen neuen Hypervisor-Stack, und die zugehörigen Kerneltreiber erstellen keine Dateien in sysfs (das unter / sys eingehängt ist) wie die Xen-Treiber, die von den anderen / älteren Instanztypen verwendet werden . Der beste Weg, um festzustellen, ob das Betriebssystem auf einer EC2-Instanz ausgeführt wird, besteht darin, die verschiedenen Möglichkeiten zu berücksichtigen, die in der von Ihnen verknüpften Dokumentation aufgeführt sind .