読者です 読者をやめる 読者になる 読者になる

quantum-ns-metadata-proxyの仕組みをメモしておく

VMのcloud-initが公開鍵などのメタデータを取得するための仕組み

OpenStackで作成したVMにcloud-initが仕込まれていると、VMの起動時に公開鍵などのファイル(metadata)をnovaからダウンロード&設定してくれる。これをNetworkNamespaceで分離されているネットワークでも実現するのがquantum-ns-metadadata-proxyみたい。
その名の通り、metadataを取得するためのproxy機能を提供してくれるんだけれども、これがどうなってるのかさっぱりわからなかったので調べてみた。

ざっくりとした構成図と登場人物

nova

VMに対してmetadataを提供する

keystone

nova/quantumのAPIにアクセスするための認可とendpointをquantum-metadata-agentに提供する

quantum-metadata-agent

novaからmetadataを取得してcloud-initに渡す

quantum-ns-metadata-proxy

namespaceの違うquantum-metadata-agentとVMのcloud-initの間を繋ぐproxyサーバ

quantum-ns-metadata-proxyの起動

1 quantum-metadata-agentが起動し、unixdomainsocketを作ってproxyからのリクエストを待ち受ける

2. quantum-dhcp-agentが起動し、quantum-serverが管理しているNetworkNamespace毎に対応するdnsmasqとquantum-ns-metadata-proxyを起動する

metadataはどのように取得されるのか?

図中の(1)-(6)の動きを解説するとこんな感じ。
(1)VMが起動シーケンス中のcloud-initを実行するとquantum-ns-metadata-proxyにhttpリクエストが送られる
(2)quantum-ns-metadata-proxyがunixdomainsocketにconnectしてcloud-initからのリクエストを中継する
(3)quantum-metadata-agentがunixdomainsocket経由でリクエストを受け取る
(4)quantum-metadata-agentがkeystoneにquantum-serverとnova-apiのエンドポイントを問い合わせる
(5)quantum-metadata-agentがquantum-serverに登録されている情報と受け取ったリクエストの情報がマッチしているかどうかをチェックする
(6)nova-apiにmetadata取得リクエストを送る
で、問題なく綺麗に処理流れると nova -> quantum-metadata-agent -> quantum-ns-metadata-proxy -> VM という流れでmetadataが渡されて公開鍵などのmetadataがVMに設定される。