Translate

2013年9月10日火曜日

CloudStackにおけるrealhostipの役割についてのwiki文書を翻訳してみる


コンソールProxy VMが使用しているrealhostip.com、
こっちでDNS設定していないのに勝手にDNS正引きして
コンソールを表示(したり、表示できなかったり)することを
疑問に思っていた。

CloudStack wiki をちょこちょこみていると
ふと

Role of realhostip in CloudStack

なるページを見つけた。

ので、ちょっと翻訳してみた。
正直ちょっとくせがあるので、正確に翻訳できたかは不明。
なので参照の際はくれくれもat your own riskでお願いします。

--------

CloudStackにおけるrealhostipの役割


どのようにrealhostip DNS名はCloudStack内で正確に処理されているのか、という質問を定期的にうけます。realhostip.comドメインは、異なるカスタマサイト内のすべてのCloudStackインストレーション間でHTTPS通信を動作させるために存在しますが、管理者無しでどうやってデプロイ環境の変更のためにSSL認証をロードしているのかを心配しているのです。

SSL認証はCloudStackシステムVMでHTTP接続を行う際に使用されています。例えば、コンソール proxy VM やセカンダリストレージVMなど、両方内部のHTTPサーバで使っています。
realhostip.com SSL認証は、すべての*.realhostip.com DNS名が認証を使用するとみなすワイルドカードアドレスでサインされています。各CloudStackカスタマは各々の環境を持つため、各カスタマの環境はそれぞれにシステムVMを保有し、各システムVMはそれぞれにIPアドレスを保有することになります。

異なるカスタマ間のすべてのインスタンスに適用するためある1つの認証を使用する場合、CloudStackによってホストされるダイナミックDNSサービスの提供する解決方法を漏らしてしまいますが、DDNSサービスは基本的に「xxx-xxx-xxx-xxx.realhostip.com to IP address xxx.xxx.xxx.xxx」というDNS名からIPアドレスまでのフォームに変換します。

CloudStackは各環境のIPアドレスをコントロールしているので、SSL認証が必要な時はいつでも、カスタマが環境を実行中であることは重要ではなく、そのようなDDNSサービスが有効なので、いつでも絶えず変更されるIPアドレス上でサフィックスがrealhostip.comであるドメインの割り当てが可能となります、これがすべてのCloudStack実行環境間である1つのSSL認証が一般的に適用可能とする我々のトリックです。

これらのケースの殆どでは、主な目的が(サイト認証の正確性ではなく)セキュアなコミュニケーションチャネルを確立することであるため、DNS名の醜さがエンドユーザに対して見せることはなありません、しかしながら、カスタマが面倒を見るケースもあり、それゆえ、コンソールproxy VMはユーザに対してユーザ自身のSSL証明書を使用するためのカスタマイズ可能な方法を提供します。

ケルビン

--------

そうかセキュアな通信をするためにSSL証明書が必要で、
証明書を作成するには何がしかのFQDNが必要になり、
それで*.realhost.comというワイルドカード証明書を作ったわけか。

で内部でDDNS機能を持たせてそこで名前解決させていた、と。

どうも文章がただしければ、こっちでSSL証明書やドメイン名はかえられるようだけど..

たしかにちょっとトリッキーな使い方してるなあ..

ご参考まで。

CloudStackにおけるドメイン、アカウント、ユーザ、そしてプロジェクトをどう使うか

CloudStackを本格的に使用する場合、ドメイン、アカウント、ユーザを作成しなくてはならないが、それらについてまず理解しておく必要がある。

そこで、以下のサイトを翻訳してみた。

Accounts, Domains, and Admin explained


以下、翻訳した文章である。
(参照の際はat your own riskでお願いします)

ここから--------

アカウント、ドメイン、管理者の説明


ドメインは複数のアカウントを保有する事ができます。各アカウントは複数のユーザを保有することができる。リソースの所有権はアカウントにひも付けされます。ユーザとは、丁度銀行口座において異なる利用者が銀行口座に対して参照権限をもつような、アカウントリソースへアクセススするための単なる同義語です。それぞれのユーザパスワードを持ちますが、同一の預金口座資金を使用します。CloudStack UIでアカウントやユーザを作成することで、より深く理解できるでしょう。

詳細

  • 1つのユーザは1つのアカウントにのみ所属することができます。同じユーザが複数のアカウントに所属することはできません。
  • どんなドメインレベルでアカウントを作成する場合でも、アカウントは、管理者(admin)と利用者(user)の2つのタイプがあります。もしアカウントが管理者(admin)の場合はそのドメインのドメイン管理者となります、そしてもしアカウントが利用者(user)である場合はそのドメインの一般ユーザとなります。
  • ROOTレベルで作成された管理者(admin)はルート管理者(ROOT admin)と呼称されます。ROOTがトップドメインなので、ルート管理者はすべてのリソースに対する操作特権を保有することとなります。
  • ユーザ名は所属するアカウントのドメイン内で一意となります。異なるドメイン(サブドメイン含む)であれば同じユーザ名が存在してもかまいません。
  • ドメイン名はフルパスが一意であれば同じドメイン名をつけることができます(例:ROOT/d1の場合、ROOT/foo/d1やROOT/bar/d2)。
  • リソースは、アカウント内の個々のユーザではなく、1つのアカウントの所属となります。課金やリソース制限などはゆーざごとではなくアカウントごとに管理されます。
  • CloudStackは、管理者(admin)アカウント、ドメイン管理者(domain-admin)アカウント、ユーザアカウントの3つの異なるタイプのアカウントの作成を許しています。すべてのロール(管理者(admin)、ドメイン管理者(domain admin)、ユーザ(user))はアカウントレベルに割り当てられます。CloudStack UI上で作成してそれぞれの違いを理解して下さい。
  • あるアカウントのすべてのユーザは同じ特権を保有します。1つのアカウントの役割ベースのユーザは存在しません。
  • 同一ドメインに複数の管理者を保有することができます。すべてのドメインはROOTドメイン以下に作成されます。

ここまで--------


アカウントは、いわゆるパーティパターンの"パーティ"に相当し、個人1名をあらわすことも部署などのグループを表すこともできる設計になっている。
ドメインもグループを表す論理単位なのだが、ドメイン間でのリソースが共用できないようなので、それこそクラウドビジネスでIaaSとしてCloudStackリソースを提供する際の契約単位とかに利用するため設計されたのだろう。
社内IaaSで他社が出てこない場合は、1つのドメインでも運用はできそうだが、ルートドメインにインスタンス数上限などのリソース制約が切れない以上、ルート以外に1つドメインは切っておいたほうが良い。

アカウント、ドメインも複数の人間が参加する組織や団体をあらわす論理単位だけど、CloudStackには"プロジェクト"という論理単位も存在する。

このプロジェクトについても理解しておく必要があるため、CloudStack wikiをさがしてみた。
するとQ&Aに以下のドキュメントを発見した。

Accounts, Domains, and Projects oh my!

以下、翻訳した文章である。
(こちらも、参照の際はat your own riskでお願いします)


ここから--------

アカウント、ドメイン、そしてプロジェクト、なんとまあ!



ドメイン


ドメインは(会社や団体など)組織の単位とほぼ同じです。ドメインは、(一般的に)リソースを所有していませんが、しかしドメインはドメイン範囲内のすべてのアカウントに対しリソース制限を強制することができます。ドメインはプロジェクトやアカウントを収容することができます、しかしドメインは本当にドメイン自身だけでインスタンス、ボリューム、他のリソースなどを所有しません。ドメインは、インスタンス、ボリューム、ネットワーク、スナップショット、テンプレートなどのようなリソースを所有できるその他のもののための器(コンテナ)です。ドメインは親ドメインに対して一意でなくてはなりませんが、その他のドメインの子であるなら(同じドメイン名を)繰り返すことができます(ROOT/dom1/sub1とROOT/dom2/sub1は"sub1"が一意ではありませんがそれぞれの親が一意であるため使用することができます)。

ルート(ROOT)ドメイン


ルートドメインは、すべてのドメインがルートドメインの子となるため、少々特殊です。ルートドメインの管理者アカウントは、すべての子ドメインに所属する(すべてのドメインの意、なぜならすべてのドメインはルート(ROOT)の子であるため)その他のリソースを(API経由で)操作する権限を保有しています。このためルートドメインの管理者アカウントは全体管理権限を保有することとなります。

本文書記述時点では、CloudStackはロールベースアクセス制御(RBAC)をサポートしていませんが、2つのレベルのパーミッション、管理者(admin)と利用者(user)が存在しています。アカウント名は1つのドメイン内で一意でなくてはなりませんが、すべてのドメインに対して一意でなくてもかまいません(joe@foo.tldとjoe@bar.tldは、"joe"が一意ではありませんが、foo.tldとbar.tldが一意ではないため、使用することができます)。

管理者アカウント


管理者アカウントはドメイン管理権限を保有しています。管理者アカウントは、ルート管理者により対象のドメインに対しドメイン制約(許可されるインスタンス数、ボリューム数など)を強制されていますが、多くの特権を保有しています。例えば、ドメイン管理者はドメイン内にアカウントを追加や、ユーザのAPIキーを生成する事ができます。自身のドメインのサブドメインを作成したり、ドメイン内のリソース利用状況をレポートする事もできます。

利用者アカウント


利用者アカウントは新規のリソース(インスタンス、ボリューム、スナップショットなど)を作成する権限を保有していますが、管理特権はとても少ないです。アカウントはAPIキーを生成できませんし、アカウントへユーザを追加することもできません、参照することだけは可能です。利用者アカウントが使用できるすべてのコマンドリストはAPIガイドを参照して下さい。

ユーザ名、パスワード、APIキー


ユーザ名、パスワード、APIキーはアカウントに属します。Web UI からユーザ名とパスワードを用いて、(そしてもしAPIキーが生成されているのであれば、APIキーを用いて)ログインします。ユーザ名は所属するドメイン内で一意でなくてはなりません(foo.tldドメイン範囲内の2つのユーザは同じユーザ名を持つことはできません-2つのjoo@foo.tldユーザを持つことはできません)が、異なるドメインであれば可能です(joe@foo.tldとjoe@bar.tld)。ユーザはリソースを所有することはできません、所属するアカウントが所有するリソースへの操作やアクセスといった単純な使い方のみです。ユーザは個別のパーミッションを保有することができません、ユーザが所属するアカウントのパーミッションを受け継ぎます。

アカウントとリソース


アカウントはリソースを所有します。アカウントはリソースを所有します、重要なので二度いいました。もしアカウントを削除したならば、所有していたすべてのリソース(インスタンス、ボリューム、スナップショットなど)は同様に削除されます。利用状況はアカウントレベルでも追跡されます。このため、課金やチャージバック目的のためにusageモジュールが有効である場合、アカウントレベルでのリソース使用状況のレポーティングが有効となります。

プロジェクト


プロジェクトはアカウントに似ていますが、アカウントとは違い特別な一面を持っています。プロジェクトはリソースの制御を複数のアカウントで共有することができます。リソース自身(インスタンス、ボリューム、スナップショットなど)はプロジェクトにより所有され、同一ドメイン内の複数のアカウントによる操作が許可されます。このため、ある組織内の複数の部署で取り組んでいる共同業務があるのであれば、プロジェクトを作成し他のアカウント(組織内の部署)を招待することで共同業務への参加を促すことができます。プロジェクトでは1つのアカウントはプロジェクト管理権限を委任しなければなりません。プロジェクト管理者は、対象ドメイン内の他のアカウントを招待したりアクセスを取り消す権限があります。プロジェクト管理者のみが対象のプロジェクトの操作権限を保有し、その他の(対象プロジェクトにアクセス可能な)アカウントに対する権限(例えば、許可されているインスタンス数やボリューム数、スナップショット数など)を保有していません。プロジェクト管理者が1つだけである間は、対象のプロジェクトが所有しているがそれに参加している個々のアカウントではないプロジェクトによって作成されたすべてのリソースであるため、影響を及ぼさないでアカウント間で移動することができます。


ここまで--------

翻訳しているとき業務としてのプロジェクトとCloudStackの論理単位であるプロジェクトが混ざっていて読みにくい..


CloudStackの論理単位である"プロジェクト"は、ドメイン内の複数のアカウントでリソースを共有でき、しかもまだ参加していないアカウントを"招待"することができる。
なので、プロジェクトは実業務上のプロジェクトと同じ考え方で切るほうがよいだろう。
ただ、usage server を使う場合は、アカウントとプロジェクトという単位以外では使用状況が追跡できないということは、システム監査などがうるさい企業で使用する場合は1アカウント=人間1人にして、1アカウント=1ユーザを守って管理していったほうがよいかもしれない。

とすると1企業内で使用する場合の例として

CloudStack 論理単位 実際の割り当て
ルート管理者 CloudStack管理を担当する人
ドメイン 会社名で1つ切る
ドメイン管理者 アカウントやリソース分配を管理する人
アカウント 社員1名
ユーザ 社員1名→LDAPユーザと対応
プロジェクト 社内の実プロジェクトと同じ単位、ドメイン管理者に作ってもらう
プロジェクト管理者 実プロジェクトの責任者アカウント、1名のみ。社員1名に紐付けないアカウントでも、責任者となる社員1名に割り当てても良い


とか..かな。

プロジェクト管理者のプロジェクトビューのダッシュボード画面にはアカウントタブがあり、このタブの中でプロジェクト管理者権限を他のアカウントへ渡したり、(既存の)アカウントをプロジェクトメンバとして追加したりできます。

ちなみに以下のタイプモデルは、CloudStack4.1.1の管理コンソールを眺めて個人的に書いたものです。



図の中のアカウントの役割の管理者は"admin"、一般利用者は"user"をあらわしています。また、プロジェクトでの役割のプロジェクト管理者は"Admin"、一般プロジェクトメンバは"Regular"をあらわしています。

役割を表す構造がすこしきもちわるいので、ひょっとしたら将来的には関係主体・関係主体ロールのパターンに変更になるかもしれませんね。となると画面仕様も変更になるかも..まあ、想像ですが..

この図も参照の際はat your own riskでお願いします。

SONYのAIコアライブラリ NNabla の概要を調べてみる

ソニーがAIライブラリをオープンソース公開したという記事を読んだ。 ソニー、ディープラーニングのコアライブラリを無償公開 https://japan.cnet.com/article/35103402/ トップサイトが https://nnabla.org/ja/ ...