Öncelikle, mevcut cevaplarla ilgili şu ince problemlerden dolayı yeni bir cevap göndermem gerektiğine ve @ qwertzguy'ün cevabı üzerine yorumum hakkında bir soru aldıktan sonra hissettim . İşte mevcut cevaplarla ilgili problemler:
- Kabul cevap @MatthieuCerda dan kesinlikle en az değil ben karşı kontrol herhangi VPC örneklerinde, güvenilir çalışmaz. (Örneklerimde,
hostname -d
içinde "amazonaws.com" olan hiçbir şey değil, dahili DNS için kullanılan bir VPC adı alıyorum.)
- @Qwertzguy tarafından verilen en yüksek oyu alan cevap , bu dosyaya sahip olmayan yeni m5 veya c5 örnekleri üzerinde çalışmaz . Her ne kadar, bu davranış değişikliği AFAIK belgelemek ihmal Amazon doc sayfa bu konuda yazıyor "... Eğer / sys / hiper yönetici / Uuid var ...". AWS'den bu değişikliğin kasıtlı olup olmadığını sordum, aşağıya bakınız †.
- @Jer gelen cevap çünkü ille her yerde çalışmıyor
instance-data.ec2.internal
DNS arama çalışmayabilir. Yeni test ettiğim bir Ubuntu EC2 VPC örneğinde, şunu gördüm:
$ curl http://instance-data.ec2.internal
curl: (6) Could not resolve host: instance-data.ec2.internal
bu yönteme dayanan kodun yanlışlıkla EC2'de olmadığı sonucuna varmasına neden olacak!
- Cevap kullanmak
dmidecode
işe yarayabilir @tamale gelen ama senin bir dayanmaktadır.) Sahip dmidecode
). Örneğiniz ve b geçerli kök veya sahip sudo
Kodunuzdaki içinden parola az yeteneği.
- Cevap / sys / cihazlarını kontrol etmek için sanal / / dmi / id / bios_version @spkane gelen tehlikeli yanıltıcıdır! Bir Ubuntu 14.04 m5 örneğini kontrol ve var
bios_version
içinde 1.0
. Bu dosya Amazon'un belgesinde belgelenmemiş , bu yüzden gerçekten ona güvenmezdim.
- Güvenilmez bir üçüncü taraf URL’sini kontrol etmek ve sonucu kullanmak için @ Chris-Montanaro’dan gelen cevabın ilk kısmı
whois
birkaç düzeyde sorunlu. Bu cevapta önerilen URL’nin şu anda 404 sayfa olduğunu unutmayın! Eğer çalışma yaptı 3. taraf hizmetini buldunuz bile, nispeten olacağını çok (yerel bir dosyayı kontrol ile karşılaştırıldığında) yavaş ve muhtemelen hız kısıtlayıcı sorunları veya ağ sorunları çalıştırmak, ya da muhtemelen EC2 örneği bile yoktur dış ağ erişimi.
- İkinci öneri Chris-Montanaro @ gelen cevap kontrol etmek http://169.254.169.254/ biraz daha iyi olmakla birlikte, yanlış önlemek için dikkatli olmak zorunda başka yorumcu notları diğer bulut sağlayıcıları, bu örnek meta URL'nin kullanılabilir olması olduğunu pozitifler. Ayrıca hala yerel bir dosyadan çok daha yavaş olacaktır, bu kontrolün ağır yüklü örneklerde özellikle yavaş (geri dönmek için birkaç saniye) olduğunu gördüm. Ayrıca, çok uzun bir süre boyunca asılı kalmamak için kıvrılmaya karşı bir argüman
-m
veya --max-time
argüman iletmeyi hatırlamalısınız , özellikle bu adresin hiçbir yere yol açıp asabileceği EC2 dışı bir örnekte ( @ algal'in cevabında olduğu gibi ).
Ayrıca, kimsenin Amazon'un (olası) dosyayı kontrol etmenin belgelenmiş belgeselinden bahsettiğini de göremiyorum /sys/devices/virtual/dmi/id/product_uuid
.
EC2'de çalışıp çalışmadığınızı belirlemenin bu kadar karmaşık olabileceğini kim bilebilirdi ?! Tamam, şimdi listelenen yaklaşımlarla ilgili sorunların çoğuna sahibiz, işte EC2'de çalışıp çalışmadığınızı kontrol etmek için önerilen bir bash pasajı. Bunun genellikle hemen hemen tüm Linux örneklerinde çalışması gerektiğini düşünüyorum, Windows örnekleri okuyucu için bir egzersizdir.
#!/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
Açıkçası, bunu daha fazla geri dönüş kontrolüyle genişletebilir ve /sys/hypervisor/uuid
şans eseri "ec2" ile başlayan bir yanlış pozitifin ele alınmasıyla ilgili paranoya da dahil edebilirsiniz . Ancak bu, gösterim amacıyla ve muhtemelen neredeyse tüm patolojik olmayan kullanım durumlarında yeterince iyi bir çözümdür.
[†] Bu açıklamayı AWS desteğinden c5 / m5 örnekleri için yapılan değişiklik hakkında geri aldım:
C5 ve M5 örnekleri, yeni bir hiper yönetici yığını kullanır ve ilişkili çekirdek sürücüleri , diğer / eski örnek türleri tarafından kullanılan Xen sürücüleri gibi sysfs'te (/ sys'ye monte edilmiş) dosyalar oluşturmaz . İşletim sisteminin bir EC2 örneğinde çalışıp çalışmadığını saptamanın en iyi yolu, bağladığınız belgelerde listelenen farklı olasılıkları hesaba katmaktır .