จะทราบได้อย่างไรว่าเครื่องเป็นอินสแตนซ์ของ EC2

ฉันต้องการเรียกใช้สคริปต์บางตัวในโฮสต์ซึ่งเป็นอินสแตนซ์ของ EC2 แต่ฉันไม่รู้ว่าจะแน่ใจได้อย่างไรว่าโฮสต์นั้นเป็นอินสแตนซ์ของ EC2 จริงๆ

ฉันได้ทำการทดสอบมาแล้ว แต่นี่ไม่เพียงพอ:

• ทดสอบว่าไบนารี ec2_userdata พร้อมใช้งาน (แต่จะไม่เป็นจริงเสมอไป)
• ทดสอบความพร้อมใช้งานของ " http://169.254.169.254/latest/meta-data " (แต่สิ่งนี้จะเป็นจริงเสมอหรือไม่และ "IP มหัศจรรย์" คืออะไร)

มีวิธีง่าย ๆ ในการตรวจสอบว่าโฮสต์เป็นอินสแตนซ์ EC2 หรือไม่: ตรวจสอบการค้นหาย้อนกลับของ IP สาธารณะของคุณ การย้อนกลับของ EC2 นั้นค่อนข้างยากที่จะพลาด

นอกจากนี้หากคุณไม่ได้แก้ไขชื่อโฮสต์ควรกลับด้านของคุณทำให้ง่ายต่อการตรวจสอบมัน

คุณอาจใช้ "magical IP" ที่คุณพูดถึงเนื่องจากเป็นวิธีมาตรฐานในการรับแท็ก EC2 Instance อย่างไรก็ตามหากคุณไม่ได้อยู่ในเครือข่าย EC2 คุณจะต้องรอให้หมดเวลาซึ่งโดยทั่วไปจะไม่ เป็นที่น่าพอใจ...

หากวิธีการเหล่านี้ไม่เพียงพอเพียงทำ whois ของ IP ของคุณและตรวจสอบว่าคุณอยู่ภายในและบล็อก IP ของ Amazon EC2 หรือไม่

แก้ไข: คุณสามารถใช้เปลือกบิตขนาดเล็กนี้:

#!/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

แม้ว่าระวัง [[เป็น bashism] คุณอาจใช้ Python หรือ Perl uniline, YMMV

เปลี่ยนคำตอบของ Hannes เพื่อหลีกเลี่ยงข้อความแสดงข้อผิดพลาดและรวมถึงการใช้ตัวอย่างในสคริปต์:

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

สิ่งนี้ไม่ทำงานในอินสแตนซ์ของ Windows ข้อได้เปรียบเหนือกว่า curl ก็คือมันใกล้เคียงกับทั้ง EC2 และไม่ใช่ EC2 ทันที

ครั้งแรกผมรู้สึกว่าจำเป็นต้องโพสต์คำตอบใหม่เพราะปัญหาที่ลึกซึ้งต่อไปนี้มีคำตอบที่มีอยู่และหลังจากที่ได้รับคำถามเกี่ยวกับฉันแสดงความคิดเห็นใน @ qwertzguy ของคำตอบ นี่คือปัญหาเกี่ยวกับคำตอบปัจจุบัน:

1. คำตอบที่ได้รับการยอมรับจาก @MatthieuCerda แน่นอนไม่ทำงานอย่างน้อยไม่ได้ในกรณีใด ๆ ที่ฉัน VPC ตรวจสอบกับ (ในกรณีของฉันฉันได้รับชื่อ VPC hostname -dซึ่งใช้สำหรับ DNS ภายในไม่ใช่ชื่อ "amazonaws.com" ในนั้น)
2. สูงสุดลงมติคำตอบจาก @qwertzguy ไม่ทำงานบน M5 หรือ c5 ใหม่กรณีที่ไม่ได้มีไฟล์นี้ อเมซอนละเลยการบันทึกพฤติกรรมนี้เปลี่ยน AFAIK แม้ว่าหน้าเอกสารในหัวข้อนี้จะพูดว่า "... หาก / sys / hypervisor / uuid มีอยู่ ... " ฉันถามฝ่ายสนับสนุน AWS ว่าการเปลี่ยนแปลงนี้เป็นการจงใจหรือไม่โปรดดูด้านล่าง†
3. คำตอบจาก @Jerไม่จำเป็นต้องทำงานทุกที่เพราะinstance-data.ec2.internalการค้นหา DNS อาจไม่ทำงาน ในอินสแตนซ์ของ Ubuntu EC2 VPC ที่ฉันเพิ่งทดสอบฉันเห็น: $ curl http://instance-data.ec2.internal curl: (6) Could not resolve host: instance-data.ec2.internal ซึ่งจะทำให้โค้ดที่ใช้วิธีนี้ในการสรุปว่ามันไม่ได้อยู่บน EC2 อย่างผิด ๆ !
4. คำตอบที่จะใช้dmidecodeจาก @tamale อาจทำงานได้ แต่อาศัยอยู่กับคุณ.) มีdmidecodeพร้อมใช้งานบนอินสแตนซ์ของคุณและข.) มีรากหรือsudoความสามารถในการใช้รหัสผ่านน้อยจากภายในรหัสของคุณ
5. คำตอบที่จะตรวจสอบ sys / / อุปกรณ์ / เสมือน / DMI / ID / bios_versionจาก @spkane เป็นอันตรายทำให้เข้าใจผิด! ฉันจะตรวจสอบหนึ่งตัวอย่าง M5 อูบุนตู 14.04 และมีของbios_version 1.0ไฟล์นี้ไม่ได้รับการบันทึกไว้ในเอกสารของ Amazonดังนั้นฉันจะไม่เชื่อถือมัน
6. ส่วนแรกของคำตอบจาก @ Chris-Montanaroเพื่อตรวจสอบ URL ของบุคคลที่สามที่ไม่น่าเชื่อถือและการใช้whoisกับผลลัพธ์นั้นเป็นปัญหาในหลายระดับ โปรดทราบว่า URL ที่แนะนำในคำตอบนั้นคือหน้า 404 ในขณะนี้! แม้ว่าคุณจะพบบริการของบุคคลที่สามที่ทำงานได้ก็จะค่อนข้างช้ามาก (เทียบกับการตรวจสอบไฟล์ในเครื่อง) และอาจพบปัญหาการ จำกัด อัตราหรือปัญหาเครือข่ายหรืออินสแตนซ์ EC2 ของคุณอาจไม่มี การเข้าถึงเครือข่ายภายนอก
7. ข้อเสนอแนะที่สองในคำตอบจาก @ Chris-Montanaroเพื่อตรวจสอบhttp://169.254.169.254/ดีกว่านิดหน่อย แต่ผู้วิจารณ์คนอื่นตั้งข้อสังเกตว่าผู้ให้บริการคลาวด์รายอื่นทำให้ URL เมตาดาต้าอินสแตนซ์นี้พร้อมใช้งานดังนั้นคุณต้องระวัง บวก นอกจากนี้ยังจะช้ากว่าไฟล์ในเครื่องฉันเห็นว่าการตรวจสอบนี้ช้ามาก (หลายวินาทีเพื่อส่งคืน) บนอินสแตนซ์ที่โหลดหนัก นอกจากนี้คุณควรจำไว้ว่าให้ส่งผ่าน-mหรือ--max-timeโต้แย้งเพื่อม้วนงอเพื่อหลีกเลี่ยงการถูกแขวนไว้เป็นเวลานานโดยเฉพาะอย่างยิ่งในกรณีที่ไม่ใช่ EC2 ซึ่งที่อยู่นี้อาจนำไปสู่ที่ใดก็ได้และแขวน (ตามคำตอบของ @ algal )

นอกจากนี้ผมไม่เห็นคนที่ได้กล่าวถึงAmazon ของเอกสารทางเลือกของการตรวจสอบสำหรับ (เป็นไปได้) /sys/devices/virtual/dmi/id/product_uuidไฟล์

ใครจะรู้ว่าการพิจารณาว่าคุณกำลังทำงานบน EC2 อาจซับซ้อนหรือไม่! ตกลงตอนนี้เรามี (ส่วนใหญ่) ของปัญหาเกี่ยวกับวิธีการที่ระบุไว้ในรายการที่นี่เป็นตัวอย่างทุบตีแนะนำเพื่อตรวจสอบว่าคุณกำลังทำงานบน EC2 ฉันคิดว่าสิ่งนี้ควรใช้งานได้กับทุกอินสแตนซ์ Linux เกือบทุกกรณีอินสแตนซ์ของ Windows เป็นแบบฝึกหัดสำหรับผู้อ่าน

#!/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

เห็นได้ชัดว่าคุณสามารถขยายสิ่งนี้ด้วยการตรวจสอบทางเลือกมากขึ้นและรวมถึงความหวาดระแวงเกี่ยวกับการจัดการเช่นการบวกผิด ๆ จาก/sys/hypervisor/uuidการเริ่มต้นด้วย "ec2" โดยบังเอิญและอื่น ๆ แต่นี่เป็นวิธีแก้ปัญหาที่ดีพอสำหรับวัตถุประสงค์ในการอธิบายและอาจเป็นกรณีการใช้ที่ไม่ใช่ทางพยาธิวิทยาเกือบทั้งหมด

[†] กลับคำอธิบายนี้จากฝ่ายสนับสนุน AWS เกี่ยวกับการเปลี่ยนแปลงสำหรับอินสแตนซ์ c5 / m5:

C5 และ M5 กรณีใช้สแต็คไฮเปอร์ไวเซอร์ใหม่และโปรแกรมควบคุมเคอร์เนลที่เกี่ยวข้องไม่ได้สร้างไฟล์ใน sysfs (ซึ่งจะติดตั้งอยู่ที่ sys /) ในขณะที่คนขับรถ Xen ใช้โดยอื่น ๆ / เก่าประเภทเช่นทำ วิธีที่ดีที่สุดในการตรวจสอบไม่ว่าจะเป็นระบบปฏิบัติการที่ทำงานอยู่ในอินสแตนซ์ EC2 คือการบัญชีสำหรับความเป็นไปได้ที่แตกต่างกันที่ระบุไว้ในเอกสารที่คุณเชื่อมโยง

ค้นหาข้อมูลเมตาด้วยชื่อโดเมนภายใน EC2 แทน IP ซึ่งจะส่งคืน DNS ล้มเหลวอย่างรวดเร็วหากคุณไม่ได้อยู่ใน EC2 และหลีกเลี่ยงความขัดแย้งของ IP หรือปัญหาการกำหนดเส้นทาง:

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

ในบาง distros ระบบพื้นฐานมากหรือเร็วมากในขั้นตอนการติดตั้งcurlไม่สามารถใช้ได้ ใช้wgetแทน:

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

หากเป้าหมายคือการบอกว่ามันเป็นอินสแตนซ์ของ EC2 หรืออินสแตนซ์ของคลาวด์ชนิดอื่นเช่น google แล้วก็ใช้dmidecodeงานได้ดีมากและไม่จำเป็นต้องใช้เครือข่าย ฉันชอบสิ่งนี้เทียบกับวิธีอื่น ๆ เพราะเส้นทางเมทาดาทา URL นั้นแตกต่างกันสำหรับ EC2 และ 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

ชื่อโฮสต์มีแนวโน้มที่จะเปลี่ยนเรียกใช้ whois กับ IP สาธารณะของคุณ:

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

หรือกดเมตาดาต้า URL ของ AWS

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

สิ่งนี้ทำงานได้ดีสำหรับโฮสต์ Linux ใน ec2 และไม่ต้องการเครือข่ายและการหมดเวลาที่เกี่ยวข้อง:

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

ใช้งานได้เพราะ Amazon กำหนดรายการนี้เช่น:

$ 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

แต่ฉันไม่รู้ว่าอุปกรณ์พกพานี้มีการกระจายตัวอย่างไร

คำตอบที่รวดเร็ว:

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

ฉันใช้หนึ่งในคำตอบที่โพสต์ที่นี่มานานกว่าหนึ่งปี - แต่มันไม่ทำงานกับอินสแตนซ์ 'c5' ประเภทใหม่ (ฉันกำลังปรับปรุงรุ่นจาก 'c4' ตอนนี้)

ฉันชอบโซลูชันนี้เพราะดูเหมือนว่าโอกาสน้อยที่สุดที่จะทำลายในอนาคต

ในประเภทอินสแตนซ์ที่เก่ากว่าและอันที่ใหม่กว่าไฟล์นี้จะปรากฏและเริ่มต้นด้วย 'EC2' ฉันตรวจสอบบน Ubuntu ที่ทำงานบน VirtualBox (ฉันต้องการการสนับสนุนด้วย) และมีสตริง 'VirtualBox'

ดังโปสเตอร์ก่อนหน้านี้ระบุไว้ (แต่พลาดง่าย) - มีเอกสารของ Amazon เกี่ยวกับวิธีการทำเช่นนี้ - ซึ่งรวมถึงคำตอบของฉัน

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

บางทีคุณสามารถใช้ "facter":

"Facter เป็นห้องสมุดข้ามแพลตฟอร์มสำหรับดึงข้อมูลข้อเท็จจริงของระบบปฏิบัติการอย่างง่ายเช่นระบบปฏิบัติการ, การแจกแจงลินุกซ์หรือที่อยู่ MAC"

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

ตัวอย่างเช่นหากเราพิจารณาข้อเท็จจริงของ 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

หากคุณติดตั้ง curl แล้วคำสั่งนี้จะคืนค่า 0 หากคุณใช้งานภายใน EC2 และไม่เป็นศูนย์หากคุณไม่ได้:

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

พยายามดึงข้อมูลเมตาของ EC2 ที่ประกาศ AMI-ID หากสิ่งนี้ไม่สำเร็จหลังจาก 3 วินาทีมันจะถือว่าไม่ได้ทำงานใน EC2

ปาร์ตี้นี้ช้าไปหน่อย แต่ฉันเจอโพสต์นี้แล้วก็พบเอกสาร AWS นี้:

สำหรับวิธีการระบุและตรวจสอบการเข้ารหัสอินสแตนซ์ EC2 ที่ชัดเจนและมีการเข้ารหัสให้ตรวจสอบเอกสารแสดงตนของอินสแตนซ์รวมถึงลายเซ็นต์ เอกสารเหล่านี้มีอยู่ในทุกอินสแตนซ์ EC2 ที่ที่อยู่ที่ไม่สามารถกำหนดเส้นทางภายในเครื่องได้http://169.254.169.254/latest/dynamic/instance-identity/

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

แน่นอนว่าสิ่งนี้ต้องการค่าใช้จ่ายเครือข่ายแม้ว่าคุณจะสามารถตั้งค่าการหมดเวลาของ curl ดังนี้:

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

ที่ตั้งค่าการหมดเวลาเป็น 5s