深入理解OpenStack虛擬機器之Metadata
前言:
剛接觸OpenStack的朋友都知道,我們在建立虛擬機器的時候選擇金鑰對,虛擬機器建立完畢後,直接使用ssh無密碼就可以登入到虛擬機器,那麼我們建立的my-key如何就這麼神奇的被放到了虛擬機器中呢?
OpenStack metadata
要理解如何實現的,我們需要先了解OpenStack的metadata。metadata字面上是元資料,主要用來給客戶提供一個可以修改設定OpenStack instence(雲主機)的機制,就像我們想在虛擬機器放置一個公鑰這樣的需求,或者設定主機名等都可以通過metadata來實現。讓我來梳理一下思路:
1.OpenStack有一個叫做Metadata的東東。
2.我們建立虛擬機器時候設定的主機名、金鑰對,都儲存在Metadata中。
3.虛擬機器建立後,在啟動的時候獲取Metadata,並進行系統配置。
虛擬機器如何取到Metadata?
那麼虛擬機器到底是怎麼取到這個metadata呢?讓我們在虛擬機器試試這個。
$ curl http://169.254.169.254/2009-04-04/meta-data
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
instance-action
instance-id
instance-type
local-hostname
local-ipv4
placement/
public-hostname
public-ipv4
public-keys/
reservation-id
是不是有點驚訝,注意到我們請求的IP地址了嗎,169.254.169.254,這是什麼魔法?從哪裡冒出來一個這樣的IP地址,竟然還可以訪問,我們肯定從來沒有配置過類似奇怪的IP地址在任何OpenStack的服務中。
那我們就到虛擬機器裡面去一探究竟,既然能訪問,那麼根據OSI七層模型來理解,一定有到這個IP地址的路由存在吧。
我們使用ip ro li列出虛擬機器路由,可以看到果然有一條路由:169.254.169.254從192.168.57.100出去,那麼誰擁有這個IP地址呢?我們先來控制節點上(當然更嚴謹的說是在執行Neutron-dhcp-agent的節點上)找一找。
# ip netns li qdhcp-ec14e723-ff09-4dab-a9e9-26dc6facc0fd
我們可以看到在控制節點有一個qdhcp的namespace,這個是我們啟動Neutron-DHCP-Agent生成的,我們可以看下它的IP地址是什麼。
它竟然有兩個IP地址,192.168.57.100和169.254.169.254。再繼續往下探索之前,我們先停下來,那麼怎麼設定讓DHCP給虛擬機器推送這個路由呢?答案在我們當時配置DHCP-Agent的時候。
# vim/etc/neutron/dhcp_agent.ini
enable_isolated_metadata = true
有一個Web服務?
好的,由於我們使用的橋接網絡卡,那麼訪問169.254.269.254的請求非常順利的被送到了qdhcp-ec14e723-ff09-4dab-a9e9-26dc6facc0fd這個namespace這裡。那麼需要有一個Web服務監聽在80埠給我們提供吧,我們繼續看:
果然有一個Apache監聽在80埠,為我們默默的提供metadata。所以虛擬機器就是這麼獲取這些資訊的:
獲取使用者注入的key:
獲取主機名
獲取IP地址
現在你終於知道OpenStack建立虛擬機器之後到底是怎麼獲取到這些meta-data資訊了吧。不過別忘了。這個是我們用的cirros的小映象才有的。如果你自己建立一個映象可不會這麼智慧,那麼怎麼辦呢?我相信聰明的你已經想到了最簡單的方案:
在啟動的時候執行一個指令碼。這個指令碼通過訪問meata-data獲取內容,然後設定到系統上。把這個指令碼放到/etc/rc.local中。如果你不想這個指令碼每次都執行,你還可以在執行完畢後,再把自己從/etc/rc.local中移除。
當然還有其它的方案。例如使用cloud-init這個軟體包。
為啥是169.254.169.254?
或許你和我有一樣的疑問,為啥這個meatadata的ip地址是169.254.169.254呢?這個就要提到Amazon了。因為metadata是亞馬遜提出來的。然後大家再給亞馬遜定製各種作業系統映象的時候獲取metadata的api地址就寫的是169.254.169.254。為了這些映象也能在OpenStack上執行,為了相容它。OpenStack就保留了這個地址。其實早期的OpenStack版本是通過iptables NAT來對映169.254.169.254到真實API的IP地址上。不過現在更靈活了,直接在虛擬機器裡面增加了一條路由條目來實現,讓虛擬機器順利的訪問到這個IP地址。
作者:趙班長
文章出處:運維社群(訂閱號ID:cloud-oaas)
推薦閱讀