web-dev-qa-db-ja.com

OpenStack GlanceはKeystoneとどのように連携し、これらの構成オプションは正確には何のためにありますか？

Keystoneに対して認証するようにGlanceを構成しています。それは機能しますが、いくつかの認証オプションがどのように相互作用するのか正確にはわかりません。

configuring glance のドキュメントから始めましたが、実際にはこれらのオプションのいずれもドキュメント化されていません。 認証ドキュメント を見つけました。これはそれらのいくつかについて説明していますが、実際にはauth_uriをドキュメント化していません。

OpenStackインストールおよびデプロイマニュアル の Glance構成の例 は次のようになります。

[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
service_protocol = http
service_Host = 127.0.0.1
service_port = 5000
auth_Host = 127.0.0.1
auth_port = 35357
auth_protocol = http
auth_uri = http://127.0.0.1:5000/
admin_token = 012345SECRET99TOKEN012345

認証ドキュメント は次のように述べています。

Auth_で始まる変数は、KeystoneAdminサービスを指します。この情報は、認証トークンの有効性についてKeystoneに実際にクエリを実行するためにミドルウェアによって使用されます。

はい。では、auth_uriはauth_Host、auth_port、およびauth_protocolとどのように相互作用しますか？単にauth_uriを提供し、他のオプションを破棄することはできますか？対応するservice_uri構成オプションはありますか？また、auth_uriのポートがservice_portではなく上記の構成のauth_portに対応するのはなぜですか？

Keystoneは、ポート35357を「admin」ポートと呼んでいます。これは、Keystoneの管理（サービス、テナントなどの作成/削除）にのみ必要であることを示唆しています。代わりに、Glanceはこれを「認証」ポートと呼び、別の使用法を示唆しています。ポート5000のサービスによって提供されていない、ポート35357のサービスによって正確に提供されるものは何ですか？

openstackopenstack-keystoneopenstack-glance
4
larsks

最初のチェックアウト： http://docs.openstack.org/ops/OpenStackOperationsGuide.pdf

一目でソースコードを見て...

tools/migrate_image_owners.py

...はauth_uriを参照する唯一のファイルです。

この変数はいたるところにあり、クライアントおよびopenstack全体での認証トークンの処理を支援しているようです。一見しただけでは使用されませんが、ミドルウェアスタックで動作するユーティリティによって使用されます。

キーストーンの5000と35357の違いは...

http://docs.openstack.org/developer/keystone/api_curl_examples.html は、APIの例が両方で機能するかどうかについてかなり明確に説明しています。

ポート5000についての私の理解は、その特定の目的はキーストーンへのパブリックAPI認証を許可することであるため、ユーザーがポート5000を認証できるようにするためだけに35357を公開する必要はないということです。

キーストーンに結びつく各openstackコンポーネントの内部に認証資格がある理由については...正直なところ私はそうではありません。知っている。

ただし、APIv2がグリズリーで登場していることを指摘しておく必要があります。まだ完全には文書化されておらず、keystoneの動作方法にいくつかの根本的な変更が導入され始めます。

2
Matt Joyce