Pertama, saya merasa perlu memposting jawaban baru karena masalah halus berikut dengan jawaban yang ada, dan setelah menerima pertanyaan tentang komentar saya pada jawaban @ qwertzguy . Inilah masalah dengan jawaban saat ini:
- The jawaban yang diterima dari @MatthieuCerda pasti tidak bekerja andal, setidaknya tidak pada setiap kasus VPC saya diperiksa terhadap. (Dalam contoh saya, saya mendapatkan nama VPC untuk
hostname -d, yang digunakan untuk DNS internal, bukan apa pun dengan "amazonaws.com" di dalamnya.)
- Jawaban dengan pilihan tertinggi dari @qwertzguy tidak berfungsi pada instance m5 atau c5 baru , yang tidak memiliki file ini. Amazon lalai mendokumentasikan perubahan perilaku ini AFAIK, meskipun halaman dokumen tentang hal ini mengatakan "... Jika / sys / hypervisor / uuid ada ...". Saya bertanya dukungan AWS apakah perubahan ini disengaja, lihat di bawah †.
- The jawaban dari @Jer tidak selalu bekerja di mana-mana karena
instance-data.ec2.internalDNS lookup mungkin tidak bekerja. Pada contoh Ubuntu EC2 VPC yang baru saja saya uji, saya melihat:
$ curl http://instance-data.ec2.internal
curl: (6) Could not resolve host: instance-data.ec2.internal
yang akan menyebabkan kode mengandalkan metode ini untuk menyimpulkan itu bukan pada EC2!
- The Jawaban untuk menggunakan
dmidecode dari @tamale dapat bekerja, tetapi bergantung pada Anda.) Memiliki dmidecodetersedia pada contoh Anda, dan b.) Memiliki akar atau sudokemampuan sandi-kurang dari dalam kode Anda.
- The jawaban untuk memeriksa / sys / perangkat / virtual / DMI / id / bios_version dari @spkane yang berbahaya menyesatkan! Aku memeriksa satu Ubuntu 14.04 m5 misalnya, dan mendapat
bios_versiondari 1.0. File ini tidak didokumentasikan sama sekali di dokumen Amazon , jadi saya benar-benar tidak akan bergantung padanya.
- Bagian pertama dari jawaban dari @ Chris-Montanaro untuk memeriksa URL pihak ketiga yang tidak dapat diandalkan dan digunakan
whoispada hasilnya bermasalah pada beberapa level. Perhatikan URL yang disarankan dalam jawaban itu adalah halaman 404 sekarang! Bahkan jika Anda menemukan layanan pihak ke-3 yang bekerja, itu akan relatif sangat lambat (dibandingkan dengan memeriksa file secara lokal) dan mungkin mengalami masalah pembatasan tingkat atau masalah jaringan, atau mungkin instance EC2 Anda bahkan tidak memiliki akses jaringan luar.
- Saran kedua dalam jawaban dari @ Chris-Montanaro untuk memeriksa http://169.254.169.254/ sedikit lebih baik, tetapi komentator lain mencatat bahwa penyedia cloud lain membuat URL metadata instance ini tersedia, jadi Anda harus berhati-hati untuk menghindari false positif. Juga masih akan jauh lebih lambat daripada file lokal, saya telah melihat pemeriksaan ini sangat lambat (beberapa detik untuk kembali) pada contoh yang banyak dimuat. Juga, Anda harus ingat untuk meloloskan argumen
-matau --max-timemenggulung agar tidak menggantung untuk waktu yang sangat lama, terutama pada contoh non-EC2 di mana alamat ini dapat mengarah ke mana-mana dan menggantung (seperti dalam jawaban @ algal ).
Juga, saya tidak melihat bahwa ada orang yang menyebutkan mundurnya Amazon yang didokumentasikan untuk memeriksa file (mungkin) /sys/devices/virtual/dmi/id/product_uuid.
Siapa yang tahu bahwa menentukan apakah Anda menggunakan EC2 bisa sangat rumit ?! Oke, sekarang kami memiliki (sebagian besar) masalah dengan pendekatan terdaftar yang tercantum, berikut ini cuplikan bash yang disarankan untuk memeriksa apakah Anda menjalankan EC2. Saya pikir ini harus bekerja secara umum pada hampir semua contoh Linux, contoh Windows adalah latihan untuk pembaca.
#!/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
Jelas, Anda dapat memperluas ini dengan lebih banyak lagi fallback cheque, dan menyertakan paranoia tentang penanganan, mis. Salah positif /sys/hypervisor/uuidterjadi mulai dengan "ec2" secara kebetulan dan sebagainya. Tetapi ini adalah solusi yang cukup baik untuk tujuan ilustrasi dan mungkin hampir semua kasus penggunaan non-patologis.
[†] Dapatkan kembali penjelasan dari dukungan AWS ini tentang perubahan untuk instance c5 / m5:
Mesin virtual C5 dan M5 menggunakan tumpukan hypervisor baru dan driver kernel yang terkait tidak membuat file di sysfs (yang dipasang di / sys) seperti yang dilakukan oleh driver Xen yang digunakan oleh tipe instance lain / lama . Cara terbaik untuk mendeteksi apakah sistem operasi berjalan pada instance EC2 adalah dengan memperhitungkan berbagai kemungkinan yang tercantum dalam dokumentasi yang Anda tautkan .