Premièrement, j’ai ressenti le besoin de publier une nouvelle réponse en raison des problèmes subtils suivants avec les réponses existantes et après avoir reçu une question à propos de mon commentaire sur la réponse de @ qwertzguy . Voici les problèmes avec les réponses actuelles:
- La réponse acceptée de @MatthieuCerda ne fonctionne certainement pas de manière fiable, du moins pas sur les instances de VPC que j'ai vérifiées. (Sur mes instances, je reçois un nom de VPC pour
hostname -d, qui est utilisé pour le DNS interne, mais pas avec "amazonaws.com".)
- La réponse la plus votée de @qwertzguy ne fonctionne pas sur les nouvelles instances m5 ou c5 , qui ne possèdent pas ce fichier. Amazon néglige de documenter ce changement de comportement autant que je sache, bien que la page de documentation sur ce sujet indique "... Si / sys / hypervisor / uuid existe ...". J'ai demandé à l'assistance d'AWS si ce changement était intentionnel, voir ci-dessous †.
- La réponse de @Jer ne fonctionne pas nécessairement partout car la
instance-data.ec2.internalrecherche DNS peut ne pas fonctionner. Sur une instance de VPC Ubuntu EC2 que je viens de tester, je vois:
$ curl http://instance-data.ec2.internal
curl: (6) Could not resolve host: instance-data.ec2.internal
ce qui ferait que le code s’appuyant sur cette méthode conclurait à tort qu’il ne s’agissait pas de EC2!
- La réponse à utiliser à
dmidecode partir de @tamale peut fonctionner, mais dépend de vous: a)) avoir dmidecodeà votre disposition sur votre instance, et b.) Avoir sudoune capacité root ou sans mot de passe à partir de votre code.
- La réponse à vérifier / sys / devices / virtual / dmi / id / bios_version de @spkane est dangereusement trompeuse! J'ai vérifié une instance Ubuntu 14,04 m5 et obtenu un exemple
bios_versionde 1.0. Ce fichier n'est pas du tout documenté dans la documentation d'Amazon , je ne le ferais donc vraiment pas.
- La première partie de la réponse de @ Chris-Montanaro visant à vérifier une URL tierce non fiable et à utiliser
whoissur le résultat pose problème à plusieurs niveaux. Notez que l'URL suggérée dans cette réponse est une page 404 en ce moment! Même si vous trouviez un service tiers qui fonctionnait, il serait comparativement très lent (par rapport à la vérification locale d'un fichier) et risquerait peut-être de rencontrer des problèmes de limitation de débit ou de réseau, ou votre instance EC2 n'a peut-être même pas accès réseau extérieur.
- La deuxième suggestion dans la réponse de @ Chris-Montanaro de vérifier http://169.254.169.254/ est un peu meilleure, mais un autre intervenant note que d'autres fournisseurs de cloud offrent cette URL de métadonnées d'instance disponible. Vous devez donc faire attention à éviter les faux points positifs. En outre, il sera toujours beaucoup plus lent qu'un fichier local. J'ai vu cette vérification être particulièrement lente (plusieurs secondes pour revenir) sur des instances très chargées. De plus, vous devez vous rappeler de passer un
-mou --max-timeargument curl pour éviter la pendaison pendant très longtemps, en particulier sur une instance non-EC2 où cette adresse peut conduire à nulle part et se bloquer (comme dans la réponse de @ algale ).
En outre, je ne vois pas que quiconque ait mentionné le recours documenté d'Amazon consistant à rechercher le fichier (possible) /sys/devices/virtual/dmi/id/product_uuid.
Qui savait que déterminer si vous utilisiez EC2 pouvait être si compliqué?! OK, maintenant que nous avons (la plupart) des problèmes avec les approches énumérées, voici un extrait de code suggéré pour vérifier si vous utilisez bien EC2. Je pense que cela devrait fonctionner généralement sur presque toutes les instances Linux, les instances Windows étant un exercice pour le lecteur.
#!/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
Évidemment, vous pourriez élargir ceci avec encore plus de vérifications de substitution et inclure la paranoïa au sujet de la gestion, par exemple d'un faux positif /sys/hypervisor/uuidpour commencer avec "ec2" par hasard, etc. Mais il s’agit là d’une solution suffisante pour illustrer notre propos et probablement pour presque tous les cas d’utilisation non pathologiques.
[†] Vous avez obtenu cette explication du support AWS à propos de la modification des instances c5 / m5:
Les instances C5 et M5 utilisent une nouvelle pile d'hyperviseur et les pilotes de noyau associés ne créent pas de fichiers dans sysfs (monté sur / sys), contrairement aux pilotes Xen utilisés par les autres types d'instance / anciens . Le meilleur moyen de détecter si le système d'exploitation s'exécute sur une instance EC2 consiste à prendre en compte les différentes possibilités répertoriées dans la documentation que vous avez liée .