CodeZine(コードジン)

特集ページ一覧

Glanceの動作と仕組み~Novaのインスタンスイメージを柔軟に管理

マイクロサービスアーキテクチャが支えるOpenStackの動作と仕組み 第3回

  • LINEで送る
  • このエントリーをはてなブックマークに追加

目次

イメージのメタ情報を管理するglance-registry

Novaはイメージを使ってインスタンスを作成するとき、イメージのメタ情報を参照して、インスタンスを作成するコンピュートノードを適切に選択します。また、ユーザーが利用可能なイメージの一覧を確認したい場合、やはりメタ情報から提供されているイメージの一覧を取得します。

glance-registryは、こうした場合に、イメージのメタ情報をGlance内部のデータベースから取り出したり、逆に格納したりするのが役目です。glance-registryにメタ情報の取り出しや格納を直接リクエストするのは、先に示した図のとおり、glance-apiです。

メタ情報に含まれている情報は以下のとおりです。どのイメージを利用するかを判断するのに十分な情報が提供されます。

id イメージに与えられる一意な識別記号
name イメージに与えられる名前。一覧にした際にイメージの内容を人が理解する際の助けとして利用する
checksum イメージを元に作成するハッシュ情報。取得したイメージが壊れていないことや途中ですりかえられてないことを検証するのに利用する
container_format イメージのコンテナ形式。仮想化技術ごとに利用可能な形式が定められている
disk_format イメージのディスク形式。仮想化技術ごとに利用可能な形式が定められている
file イメージが配置されている場所
min_disk このイメージを元にインスタンスを作る際に最小限必要なディスクサイズ
min_ram このイメージを元にインスタンスを作る際に最小限必要なメモリのサイズ
status イメージの状態。削除中、利用可能といった状態が記述される
self イメージの情報を操作する際にアクセスするエンドポイントのURL
schema イメージのメタデータがどのようにして記述されているのかの解説にアクセスする際のURL
owner イメージが何に所属しているのかの情報。特定のユーザーであったり、テナントであったりする
size イメージの容量
virtual_size イメージ圧縮前のイメージサイズ。Disk Formatによってはイメージは圧縮されているため必ずしもsizeとは一致しない
protected イメージが保護されているか否か。保護されているイメージは上述のownerでなければ削除できない
create_at イメージが作成された日時
description ユーザーがイメージに付加する説明文
tags ユーザーが任意で付加できる追加のメタデータ

コラムglance-apiとglance-registryとを分けて実装する意義

glance-apiはユーザーや他コンポーネントからのリクエストを受け付ける部分。一方、glance-registryはデータベースへのアクセスを司る部分です。

一見すると、単一のコンポーネントにしてしまってもよいように思えます。しかし、glance-registryはデータベースやストレージと関わりを持ちます。そのため、開発はglance-apiとは分離して行いたいところです。

また、データベースやストレージに変更があった場合、glance-registryのみ再起動だけで済みます。glance-apiを再起動する必要がありません。リクエストの受付部分、例えば認可ポリシーに変更があった場合も同様で、glance-apiのみ再起動すればよく、glance-registryを止める必要はありません。

このように、設定の細分化や開発を容易にして品質を向上させるという面においても、マイクロサービスアーキテクチャで作られているということが有効に働きます。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:マイクロサービスアーキテクチャが支えるOpenStackの動作と仕組み

著者プロフィール

あなたにオススメ

All contents copyright © 2005-2022 Shoeisha Co., Ltd. All rights reserved. ver.1.5