Comment savoir si une machine est une instance EC2

J'aimerais exécuter des scripts sur des hôtes qui sont des instances EC2, mais je ne sais pas comment m'assurer que l'hôte est vraiment une instance EC2.

J'ai fait des tests, mais cela ne suffit pas:

• Testez que b2 ec2_userdata est disponible (mais ce ne sera pas toujours vrai)
• Disponibilité de test de " http://169.254.169.254/latest/meta-data " (mais cela sera-t-il toujours vrai? Et quelle est cette "adresse magique"?)

En fait, il existe un moyen très simple de détecter si l'hôte est une instance EC2: vérifiez la recherche inversée de votre adresse IP publique. Les revers de l'EC2 sont assez difficiles à manquer.

De plus, si vous ne le modifiez pas, le nom d’hôte doit être votre inverse, ce qui le rend plus facile à repérer.

Vous pouvez également utiliser "l'adresse IP magique" dont vous avez parlé, car il s'agit en effet du moyen standard d'obtenir les balises d'instance EC2. Toutefois, si vous ne travaillez pas sur un réseau EC2, vous devrez attendre un délai d'expiration, ce qui n'est généralement pas le cas. souhaitable...

Si ces méthodes ne suffisent pas, il suffit de faire un whois de votre adresse IP et de vérifier si vous vous trouvez dans le bloc IP Amazon EC2.

EDIT: Vous pouvez utiliser ce petit bit shell:

#!/bin/bash
LOCAL_HOSTNAME=$(hostname -d)
if [[ ${LOCAL_HOSTNAME} =~ .*\.amazonaws\.com ]]
then
        echo "This is an EC2 instance"
else
        echo "This is not an EC2 instance, or a reverse-customized one"
fi

Attention cependant, [[est un bashisme. Vous pouvez également utiliser un Python ou Perl Uniline, YMMV.

Modification de la réponse de Hannes pour éviter les messages d'erreur et inclure un exemple d'utilisation dans le script:

if [ -f /sys/hypervisor/uuid ] && [ `head -c 3 /sys/hypervisor/uuid` == ec2 ]; then
    echo yes
else
    echo no
fi

Cela ne fonctionne pas dans les instances Windows. L'avantage par rapport au curl est qu'il est presque instantané sur les EC2 et les non-EC2.

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:

1. 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".)
2. 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 †.
3. 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!
4. 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.
5. 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.
6. 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.
7. 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 .

Recherchez les métadonnées par le nom de domaine interne EC2 au lieu de l'adresse IP, ce qui renverra une défaillance DNS rapide si vous n'êtes pas sur EC2 et évite les conflits IP ou les problèmes de routage:

curl -s http://instance-data.ec2.internal && echo "EC2 instance!" || echo "Non EC2 instance!"

Sur certains systèmes, distros très basiques, ou très tôt à des stades de installion boucle ne sont pas disponibles. Utiliser wget à la place:

wget -q http://instance-data.ec2.internal && echo "EC2 instance!" || echo "Non EC2 instance!"

Si l'objectif est de déterminer s'il s'agit d'une instance EC2 OU d'un autre type d'instance de cloud, telle que Google, dmidecodefonctionne très bien et qu'aucun réseau n'est requis. J'aime cela par rapport à d'autres approches car le chemin de l'URL des métadonnées est différent pour EC2 et GCE.

# From a google compute VM
$ sudo dmidecode -s bios-version
Google

# From an amazon ec2 VM
$ sudo dmidecode -s bios-version
4.2.amazon

Les noms d'hôte sont susceptibles de changer, lancez un whois contre votre IP publique:

if [[ ! -z $(whois $(curl -s shtuff.it/myip/short) | grep -i amazon) ]]; then 
  echo "I'm Amazon"
else 
  echo "I'm not Amazon"
fi

ou cliquez sur l'URL de méta-données AWS

if [[ ! -z $(curl -s http://169.254.169.254/1.0/) ]]; then 
  echo "I'm Amazon"
else 
  echo "I'm not Amazon"
fi

Cela fonctionne également bien pour les hôtes Linux dans ec2 et ne nécessite pas le réseau ni les délais d'attente associés:

grep -q amazon /sys/devices/virtual/dmi/id/bios_version

Cela fonctionne car Amazon définit cette entrée comme suit:

$ cat /sys/devices/virtual/dmi/id/bios_version 4.2.amazon

test -f /sys/hypervisor/uuid -a `head -c 3 /sys/hypervisor/uuid` == ec2 && echo yes

mais je ne sais pas à quel point c'est portable dans toutes les distributions.

Réponse rapide:

if [[ -f /sys/devices/virtual/dmi/id/product_uuid ]] && \
    grep -q "^EC2" /sys/devices/virtual/dmi/id/product_uuid
then
    echo "IS EC2"
else
    echo "NOT EC2"
fi

J'utilisais l'une des réponses publiées ici depuis plus d'un an, mais cela ne fonctionnait pas avec les nouveaux types d'instances «c5» (je travaille actuellement à la mise à niveau à partir de «c4»).

J'aime cette solution car elle semble être la moins susceptible de se briser à l'avenir.

Sur les types d'instance les plus anciens et les plus récents, ce fichier est présent et commence par «EC2». J'ai vérifié Ubuntu sous VirtualBox (que je dois également prendre en charge) et il contient la chaîne 'VirtualBox'.

Comme l'a noté une affiche précédente (mais c'était facile à manquer) - il existe une documentation d'Amazon sur les moyens de le faire - qui inclut ma réponse.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html

Peut-être que vous pouvez utiliser "facter":

"Facter est une bibliothèque multi-plateforme permettant de récupérer des informations simples sur le système d’exploitation, telles que le système d’exploitation, la distribution Linux ou l’adresse MAC."

http://www.puppetlabs.com/puppet/related-projects/facter/

Par exemple, si nous examinons le fait ec2 (facter-1.6.12 / lib / facter / ec2.rb):

require 'facter/util/ec2'
require 'open-uri'

def metadata(id = "")
  open("http://169.254.169.254/2008-02-01/meta-data/#{id||=''}").read.
    split("\n").each do |o|
    key = "#{id}#{o.gsub(/\=.*$/, '/')}"
    if key[-1..-1] != '/'
      value = open("http://169.254.169.254/2008-02-01/meta-data/#{key}").read.
        split("\n")
      symbol = "ec2_#{key.gsub(/\-|\//, '_')}".to_sym
      Facter.add(symbol) { setcode { value.join(',') } }
    else
      metadata(key)
    end
  end
end

def userdata()
  begin
    value = open("http://169.254.169.254/2008-02-01/user-data/").read.split
    Facter.add(:ec2_userdata) { setcode { value } }
  rescue OpenURI::HTTPError
  end
end

if (Facter::Util::EC2.has_euca_mac? || Facter::Util::EC2.has_openstack_mac? ||
    Facter::Util::EC2.has_ec2_arp?) && Facter::Util::EC2.can_connect?

  metadata
  userdata
else
  Facter.debug "Not an EC2 host"
end

Si vous avez installé curl, cette commande retournera 0 si vous utilisez EC2 et une valeur différente de zéro si vous n’êtes pas:

curl --max-time 3 http://169.254.169.254/latest/meta-data/ami-id 2>/dev/null 1>/dev/null`

Il tente d'extraire les métadonnées EC2 déclarant l'identificateur AMI-ID. Si cela ne réussit pas au bout de 3 secondes, cela suppose qu’il ne fonctionne pas dans EC2.

Un peu tard pour cette soirée, mais je suis tombé sur ce post et puis j'ai trouvé cette documentation AWS:

Pour une méthode d'identification définitive et vérifiée par cryptographie d'une instance EC2, vérifiez le document d'identité de l'instance, y compris sa signature. Ces documents sont disponibles sur chaque instance EC2 à l'adresse locale non routable http://169.254.169.254/latest/dynamic/instance-identity/

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html

Ceci, bien sûr, nécessite la surcharge du réseau bien que vous puissiez définir le délai d’arrêt de la manière suivante:

curl -s --connect-timeout 5 http://169.254.169.254/latest/dynamic/instance-identity/

Cela définit le délai d'attente à 5 secondes.