Primeiro, senti a necessidade de postar uma nova resposta por causa dos seguintes problemas sutis com as respostas existentes e depois de receber uma pergunta sobre meu comentário na resposta do @ qwertzguy . Aqui estão os problemas com as respostas atuais:
- A resposta aceita pelo @MatthieuCerda definitivamente não funciona de maneira confiável, pelo menos não nas instâncias de VPC que verifiquei. (Nas minhas instâncias, recebo um nome de VPC para
hostname -d, que é usado para DNS interno, e não qualquer coisa com "amazonaws.com" nele.)
- A resposta mais votada de @qwertzguy não funciona em novas instâncias m5 ou c5 , que não possuem esse arquivo. A Amazon não documenta esse comportamento, altere o AFAIK, embora a página de documento sobre este assunto diga "... Se / sys / hypervisor / uuid existir ...". Perguntei ao suporte da AWS se essa alteração foi intencional, veja abaixo †.
- A resposta do @Jer não funciona necessariamente em todos os lugares porque a
instance-data.ec2.internalpesquisa de DNS pode não funcionar. Em uma instância VPC do Ubuntu EC2 em que acabei de testar, vejo: o
$ curl http://instance-data.ec2.internal
curl: (6) Could not resolve host: instance-data.ec2.internal
que faria com que o código que confia nesse método conclua falsamente que não está no EC2!
- A resposta a ser usada
dmidecode no @tamale pode funcionar, mas depende de você a.) Ter dmidecodedisponível em sua instância eb) ter capacidade de root ou sem sudosenha a partir do seu código.
- A resposta para verificar / sys / devices / virtual / dmi / id / bios_version do @spkane é perigosamente enganosa! Eu verifiquei uma instância do Ubuntu 14.04 m5 e obtive uma
bios_versiondas 1.0. Esse arquivo não está documentado no documento da Amazon , então eu realmente não confiaria nele.
- A primeira parte da resposta de @ Chris-Montanaro para verificar um URL de terceiros não confiável e usar
whoisno resultado é problemática em vários níveis. Observe que o URL sugerido nessa resposta é uma página 404 agora! Mesmo se você encontrasse um serviço de terceiros que funcionasse, seria comparativamente muito lento (comparado à verificação de um arquivo localmente) e possivelmente teria problemas de limitação de taxa ou problemas de rede, ou talvez sua instância do EC2 nem sequer tenha acesso à rede externa.
- A segunda sugestão na resposta de @ Chris-Montanaro para verificar http://169.254.169.254/ é um pouco melhor, mas outro comentarista observa que outros provedores de nuvem disponibilizam o URL de metadados dessa instância, portanto, você deve ter cuidado para evitar falsos positivos. Além disso, ainda será muito mais lento que um arquivo local. Vi essa verificação ser especialmente lenta (alguns segundos para retornar) em instâncias muito carregadas. Além disso, lembre-se de passar um argumento
-mou --max-timecurl para evitar que ele fique paralisado por muito tempo, especialmente em uma instância não-EC2 em que esse endereço possa levar a lugar nenhum e travar (como na resposta de @ algal ).
Além disso, não vejo que alguém tenha mencionado o fallback documentado da Amazon de verificar o arquivo (possível) /sys/devices/virtual/dmi/id/product_uuid.
Quem sabia que determinar se você está executando o EC2 pode ser tão complicado ?! OK, agora que temos (a maioria) dos problemas relacionados às abordagens listadas, aqui está um snippet de bash sugerido para verificar se você está executando no EC2. Eu acho que isso deve funcionar geralmente em quase todas as instâncias do Linux, instâncias do Windows são um exercício para o leitor.
#!/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
Obviamente, você pode expandir isso com ainda mais verificações de fallback e incluir paranóia sobre o manuseio, por exemplo, um falso positivo /sys/hypervisor/uuidaconteça para começar com "ec2" por acaso e assim por diante. Mas esta é uma solução suficientemente boa para fins de ilustração e provavelmente quase todos os casos de uso não patológicos.
[†] Recuperei esta explicação do suporte da AWS sobre a alteração para instâncias c5 / m5:
As instâncias C5 e M5 usam uma nova pilha de hipervisor e os drivers do kernel associados não criam arquivos no sysfs (que é montado em / sys) como os drivers Xen usados pelos outros tipos de instância / antigos . A melhor maneira de detectar se o sistema operacional está sendo executado em uma instância do EC2 é considerar as diferentes possibilidades listadas na documentação que você vinculou .