Translate

2013年12月11日水曜日

CloudStack4.2.0用の簡単なUIプラグインを作ってみる

※本投稿は、CloudStack Advent Calendar 12月11日のエントリです。


CloudStack4.2.0から管理サーバのWeb UIに対してプラグインが作れる
ようになった。
リリースノートにはUIプラグインの作り方については
詳しくはDeveloper Guideを読んでね」と書いてあった。

しかしDeveloper Guideが4.2.0リリースされて1ヶ月以上経つのに
ちっともでてこない..

なので、自分でちょっと管理サーバのWebコンテンツ内を
覗いてみることにした。

管理サーバのWebコンテンツディレクトリ内には

/usr/share/cloudstack-management/webapps

が管理サーバWeb UIのコンテンツが入っている。

更に下の

/usr/share/cloudstack-management/webapps/client/plugins

というディレクトリをみてみると、
plugins.jstestPluginディレクトリがおいてあった。


plugins.js上のcloudstack.plugins
プラグイン名を入れれば、
その名前のディレクトリ上のJavaScriptを読んでくれそうだな
と直感的にわかれよ、ということらしい。

むかしCloudStackのAPIを呼び出すURL文字列を作成する
AppEngineアプリ

CloudStack API Creator
https://cloudstacktools.appspot.com/

CloudStack API Creatorサイト作成に関する投稿
http://fight-tsk.blogspot.jp/2013/03/cloudstack-apiurl.html

を作ったのでこれをなんちゃってプラグインにしてみることにした。




まずプラグインIDを決める(apiUrlCreatorにした)。

そして、

/usr/share/cloudstack-management/webapps/client/plugins/plugins.js



    (function($, cloudStack) {
      cloudStack.plugins = [
         'testPlugin',
         'apiUrlCreator'
      ];
    }(jQuery, cloudStack));


と書き換え、

testPluginディレクトリを丸々

/usr/share/cloudstack-management/webapps/client/plugins/

ディレクトリ下にプラグインIDとおなじディレクトをつくってコピーして

/usr/share/cloudstack-management/webapps/client/plugins/apiUrlCreator
/usr/share/cloudstack-management/webapps/client/plugins/apiUrlCreator/apiUrlCreator.js
 
(testPlugin.jsをリネーム)
/usr/share/cloudstack-management/webapps/client/plugins/apiUrlCreator/apiUrlCreator.css (testPlugin.cssをリネーム)
/usr/share/cloudstack-management/webapps/client/plugins/apiUrlCreator/config.js
/usr/share/cloudstack-management/webapps/client/plugins/apiUrlCreator/icon.png


を作成し(念のためroot.rootで同じパーミッションにしておき)、

cofig.js は以下のソースに書き換え、

(function (cloudStack) {
  cloudStack.plugins.apiUrlCreator.config = {
    title: 'API URL String creator Plugin',
    desc: 'To create URL string with CloudStack API',
    externalLink: 'http://fight-tsk.blogspot.jp/',
    authorName: 'Hara Hara Development',
    authorEmail: 'SammoHungGambou@gmail.com'
  };
}(cloudStack));

apiUrlCreator.jsも以下のソースに書き換え、

(function (cloudStack) {
  cloudStack.plugins.apiUrlCreator = function(plugin) {
    plugin.ui.addSection({
      id: 'apiUrlCreator',
      title: 'API URL Creator',
      preFilter: function(args) {
        return true;//isAdmin();
      },      show: function() {
        return $('<div>').css('width', '100%').css('height', '700px').css('overflow', 'auto').html('<iframe height="98%" width="100%" src="https://cloudstacktools.appspot.com/" />');
      }
    });
  };
}(cloudStack));

最後に

service cloudstack-management restartをかけて
管理サーバWeb UIを使って一般ユーザ(ロールがuser)でログインすると..

左下に「プラグイン」と「API URL Creator」ってのができた。





以下の画面スナップは「プラグイン」を押下したところ。
現時点で有効なプラグイン情報が表示されていて、
今回作成した「API URL String creator plugin」も表示されている。




「API URL String Creator Plugin」を選択すると、
config.jsに書いた詳細情報がでてくる。




次に左側のメニューの一番下の「API URL Creator」の方をクリックすると
以下のスナップのようにGoogle App Engine上のWebサイトが表示される。



高さがあふれたのはご愛嬌..


apiUrlCreator.jspreFilterで常にtrueを返すようにすれば
一般ユーザも見えるプラグインになる。

<プラグインID>.js というファイルのshow部分
divタグにhtmlを埋め込むサンプルコード部分)を、
うまく書き換えてやれば複雑なプログラムも組むことができる。

DOM対象となる実際のHTMLファイルのdivタグにidが振られていないので
jQueryの呼び出しをそのまま使った。
#一つ上にid=shadowというdivタグがあって
#こっちを操作してやろうとしたらうまく行かなかった

UIプラグイン作成の鍵はCloudStack側が用意している
plugin.ui.addSessionというJavaScript関数。

この使い方のドキュメントがあればもっといろいろできるのに..


今回プラグイン関連ファイルをさわっているうちに
iframeが使えるがわかったので
前に作ったApp Engineサイトを流用したが、
同じコンテンツ内にServlet/JSPなりを書いてアプリを組む
なんてことも可能だろう。


CloudStackはAPIがREST通信なので同じサーバでなくてももちろん可能だが、
どうせならログイン中のユーザIDの権限でAPI操作できるような
JavaScriptを組みたい。



にしても..最近はJavaScriptを直接書く技術が必要なケースが増えてきた。
jQueryとかいちいちGoogleって書いていると生産性が悪いし..




企業内でCloudStackを使用する場合、
足りないのは利用などの申請系のワークフローと
課金機能なんだけど..

..誰か作ってくれんかなあ..

2013年11月12日火曜日

ガラポンTVを使ってみる

前から気になっていたガラポンTVを購入した。


ガラポンTVは、
ワンセグ局全局を内蔵もしくは外付けHDDへ記録するサーバで
価格は最近はだいたい約4万円前後で販売されている。

Regzaサーバは地デジを記録するので内蔵4TBでせいぜい1週間が
いいところだが、このガラポンTVはワンセグなので
画像は荒くはなるが記録する時間は内蔵ストレージだけで2週間、
3TB HDDを増設すれば90日間録画することができる。

Regzaサーバは同一セグメント内で他デバイスで再生可能であるのに対し、
ガラポンTVはユニバーサルプラグアンドプレイ対応のルータを使っていれば
外部のインターネット回線経由で再生が可能である。
但し特殊なポートを通信に使用しているため、
プロクシ経由での視聴はポートフォワーディングなどを行わない限りできない。

ルータのWAN側がグローバルIPアドレスであれば、
DHCPでの割り当てであっても屋外からも視聴できる。

どうもガラポンTVがIPアドレス変更を認識すると
ガラポンTVサイトへ変更されたことを伝達するしくみになっているらしい。

なので
屋外から視聴する場合は一旦ガラポンTVサイトへログインしてから
自宅のガラポンTVへ接続するので、
DHCPであっても受信可能なのだとおもう。


Regzaは画像品質重視であるのに対して
ガラポンTVは記録期間重視で
iPhoneやAndroidなどのスマートフォン、
iPadなどのデバイスでも視聴可能だ。
#無料の専用アプリが用意されている


私の自宅はインターネットマンションで
ユニバーサルプラグアンドプレイ対応のルータ経由で
使用しているが、
こんな環境であっても屋外からLTE回線で
iPhoneでTVを見ることができる。




自宅では無線LANで同一セグメントにつないでいたiPad経由で設定を行ったが
ルータの設定変更などややこしいルーティング関連の設定は自動だった。
#ユニバーサルプラグアンドプレイでないルータとか一部のルータは
#個別せってし無くてはならない

時間も30分くらいかな。
#一番長いのがワンセグのチャンネル検索だったがそのほかはほとんど時間がかからなかった。
必要なのは同軸ケーブルとLANケーブル(両方同梱されていない)。




国内の動画サイトは海外からの利用が不可な場合が多いが
このガラポンTVを使えば海外常駐者でもブロードバンド環境さえあれば
いつでも日本のTVを視聴することができる、というのが宣伝文句だ。

でもインドに半年いたけど
国内にあるサーバまでは距離が遠すぎて
回線速度が確保できなかった。
ニコニコ動画は当時国内サーバしかなかったので
ぶつぶつきれてしまいほぼ使い物にならず
もっぱらyoutubeへアップされた番組をちょこちょこみていた。

回線品質の良い国なら使い物になるかな..
くらいで思っていたほうが良いと思う。



本音を言えばストレージをクラウド上においてほしいところなのだけど、
たぶんTV業界の既得権益ホルダーな人たちがやいのやいのいうから
できないのだとおもう。
もしそうなっちゃったら
「TVの電波、いらないんじゃないの?」ってなっちゃうからね。

..生きてる間は難しそうだなあ..

2013年10月23日水曜日

CloudStack4.2.0をインストールしたら、システムVMがStartingのままになる




CloudStack4.2.0のdebパッケージが配置されていたので、
早速Ubuntu Server12.04LTSにインストールしてみた。

4.0/4.1/4.1.1/4.1.1-1と全く同じ手順でインストールを行い、
管理コンソールからいざ「ゾーンの有効化」をはじめると..

Secondary Storage VM、Console Proxy VM両方共「Starting」のままで
いくら待っても起動しない。
/var/log/cloudstack/management以下のログを見ると
Exceptionが発生していた。

システムVMが上がらない系の問題は
CloudStackインストールを試す人はぼぼかならず引っかかるが
その際の動きは微妙に違う。

多いのは起動→失敗→インスタンス作り直し→起動→失敗..を繰り返し
VMの名前の数字がどんどん上がっていくパターン。
#こっちはNFSのマウントオプションにミスが有ることが多い

今回はこれとは違うので、mountオプションの問題ではなさそうだ。


いろいろためしたがうまくいかない..

..で、ふと管理コンソールに「領域」という概念が増えていることに気づく。
もしかしたらVMのテンプレート自体がかわっとのかもしれない..

Install Guideを読んでみると..



4.5.9 Prepare the System VM Templateの記述で
cloud-install-sys-mount-tmpltコマンドの
KVMのテンプレートURLが

http://download.cloudstack.com/templates/acton/acton-systemvm-02062012.qcow2.bz


でなく

http://d21ifhcun6b1t2.cloudfront.net/templates/4.2/systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2

になっとる..



..気づくのに、1ヶ月かかった..

2013年10月8日火曜日

CloudStack4.2.0がやっとUbuntu Server12.04LTSでapt-getできるようになった

10月はじめに4.2.0がリリースされていたのだが、
何度かトライしたが、
Ubuntuのapt-getコマンドで取得できるような環境はまだできあがっていなかった。

しかたないのでdebファイルを直接入手してdpkg -iでインストールしていたが、
さきほどようやくapt-get/aptitudeできるようになった。

でも、ダウンロード速度が..遅すぎ..
cloudstack-managementなんて137MBしかないのに
1時間どころじゃない..
みんなやっているから?!

ソースから構築するのがスピード的には一番よさそうだ..



CloudStack4.2.0自体はまだしっかり試していないが、
管理コンソールに「アフィニティグループ」と「領域」の2つのメニューが増えていた。

領域はリージョンのことで、
別のDCにあるCloudStackを操作する時にサーバ指定を変えるなどかなと想像できるが..

アフィニティグループねえ..小集団で全員管理者とかかな?

もうちょっと調べてみるか..


p.s.

ちなみにインストールは4.1とほぼかわらないが
プライマリ指定のときゾーン全体にしてNFSサーバを登録するとエラーになるので
クラスタ指定でインストールすれば素直にセットアップがとおる。

ただし、ひっかかるのがSystem VMのテンプレートをダウンロードしてくる所。
URLが変わっているのだ。

それに気づかずに、4.1時代のテンプレートをセカンダリストレージにおいてしまうと、
例の「ゾーン有効化直後System VMが上がらない(ずーっと2つともStarting)」状態
に陥る。

# /usr/share/cloud-common/scripts/storage/secondary/cloud- 
install-sys-tmplt -m /mnt/secondary -u  
http://d21ifhcun6b1t2.cloudfront.net/templates/4.2/systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2  
-h kvm -F
 
ご注意を。 

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でお願いします。

2013年8月15日木曜日

CloudStack wikiのDevCloudのページの一部を翻訳してみる

All in Oneサーバを頑張って作っていたのだけど
いろいろあって心が折れたので、
DevCloudに転がることにしました。

で、何も見ないでセットアップしたら
なにやらUbuntuがあがって..

..その次何したらいいかさっぱりわからない..


ということでCloudStackのwikiにある
DevCloudという章だけをまず読んでみようと思い
翻訳してみました。

以下翻訳した文章ですが、
参照の際はAt your own riskでお願いします。


-------

はじめに


DevCloudは、VirtualBox(オープンソースtype-2もしくはデスクトップハイパバイザ)上で動作するOVAイメージとして提供される仮想アプライアンスで、CloudStack開発やテスト用として利用することができます。オリジナルのDevCloudはRAMが2GB必要で、VirtualBoxの仮想マシンとして実行するxen.orgのXenサーバがのっているUbuntu Preciseとして動作します。

開発者はCloudStackアーティファクト(jars, wars)やファイルをDevCloudへビルド、デプロイしたり、DevCloud内部でデータベースをデプロイし管理サーバを起動することができます。開発者はDevCloud内部で動作するCloudStackを使ってDevCloudをホストとして追加することなども可能です。現在ではDevCloudは多くの方に利用されており、特にApache CloudStackの初期リリース(4.0.0-incubating)の間などにリリーステストのために利用されています。


VirtualBox/KVM/Fusion?


DevCloudはVirtualBox(やXenServer)もしくはKVMハイパバイザどちらでも使用出来ます。これらのハイパバイザのウチ1つを選択することだけ必要です、そして次に以下のVirtualBoxもしくはLinux KVMのセットアップ章に従って下さい。

XenServerをネストされたハイパバイザで動作させたい場合は、 「CloudStack 開発のために Fusion を使用した XenServer ハイパバイザ」を参照して下さい。
https://cwiki.apache.org/confluence/display/CLOUDSTACK/XenServer+Hypervisor+for+CloudStack+Development+using+Fusion


セットアップ(VirtualBox)


1. DevCloud2.0仮想アプライアンスを入手します

イメージはこのサイトに記載されたプロセスで生成されています。

注意:約900MBあります。


2. VirtualBox4.2もしくは最新版をインストールします

3. 未定義の場合(もしくはVirtualBoxをインストールしたばかりの場合)は、VirtualBox上に"ホストオンリー"ネットワークを作成・設定します

3.1 ネットワークを作成するためには、VirtualBoxの「ファイル」→「環境設定」→「ネットワーク」を選びホストオンリーネットワークを追加してください(訳者注:右上の+マークの着いたNICアイコンを押す)。するとcboxnet0などのような名前で作成されます。(Windowsのみ:ホストオンリーネットワークの追加は実行しなくて構いません、3.2へ進んで下さい)

3.2 3.1で作成したネットワークを設定するために、(訳者注:VirtualBox Host-Only Ethernet Adapterを)右クリックし"ホストオンリーネットワークを編集"を選択して下さい。そしけ"DHCPサーバ"タブ上の"サーバを有効化"のチェックを外して下さい。

3.3 (Windowsのみ)OSの「スタート」→「管理ツール」→「セキュリティが強化されたWindowsファイアウォール」を選択して下さい。「Windowsファイアウォールのプロパティ」(中央のパネル「概要」ブロックの一番下)をクリックし、各プロファイル(ドメイン、パブリック、プライベート)タブの状態欄にある「カスタマイズ」ボタンを押して下さい。そして「VirtualBox Host-Only Network」のチェックを外します。そうすることで、ウィンドウズファイアウォールの通信ブロックは発生しません。

4. DevCloud ova イメージをVirtualBoxへインポートします


4.1 PAEモードがアクティブであるか確認します。(VirtualBoxの)「仮想マシン」→「設定」→「システム」→「プロセッサ」タブを選択し、「PAE/NXを有効化」がチェックされていることを確認します。

(訳者注:インポートは、VirtualBoxの「ファイル」→「仮想アプライアンスのインポート」→「アプライアンスを開く」からovaイメージファイルを選択し、「次へ」→「インポート」を実行します)

5. DevCloud 仮想マシンを開始します(Windowsの場合、vboxnet0を使用していないという注意が表示されることがありますので、デフォルトのホストオンリーネットワークを使用するように編集して下さい)


6. 仮想マシンブート後、ユーザ名「root」パスワード「password」でログインします

 ネットワーク
 DevCloudのデフォルトIPが192.168.56.10となっています。
 (複数のDevCloudを実行させたいなど)もしIPアドレスを変更したい場合は
 /etc/network/interfacesを変更してリブートして下さい。

7. ラップトップ上で管理サーバを動かします:


7.1 必要な場合は、「CloudStack開発環境のセットアップ」を実行します。

7.2 最新のマスタコードをチェックアウトします

7.3 ラップトップ上で管理サーバを起動します:


 mvn -P developer,systemvm clean install
 mvn -P developer -pl developer,tools/devcloud -Ddeploydb
 mvn -pl :cloud-client-ui jetty:run

管理サーバが起動するまで待機します。

8. (mysql-connector-pythonがインストール済みで管理サーバが作動中の)DevCloudをデプロイします


 $ pip install mysql-connector-python (#marvin dependancy)
 $ pip install requests (#reqd for marvin deploying the zone)
 $ mvn -P developer -pl tools/devcloud -Ddeploysvr

 # もしくは、上記のコマンドが動作しない場合は、
 # おそらくMAVEN_OPTSを使用してmvnをデバッグモードで動かしています。
 # marvinを試して下さい
 $ cd tools/devcloud; python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg

上記のコマンドで、いくつかのグローバル設定が登録されているtools/devcloud/devcloud.cfgに定義された設定でゾーンがデプロイされます。コマンド実行後は、管理サーバを再起動させ、グローバル設定を反映させるために既に動作させていたシステムVMを削除して下さい。

9. "ssh root@192.168.56.10"をつかってDevCloudをAll in Oneボックスソリューションとして実行することもできます

(git、java、maven、mkisofsなど)すべてのビルドツール、mysql、nfsはプリインストール、セットアップ済みです。ホストOSで管理サーバを実行する方法を推奨します。そしてIntelliJやEclipseを使ってコード実行やデバッグさせながら動かしたりDevCloudをホスト、ストレージ、ネットワークインフラとしてリプレース/代替として使用することもできます。


セットアップ(Linux KVM)

1. 必要条件:KVMモジュール、libvirtユーティリティ(virsh)がインストールされたLinuxマシンを持っていること

2. ここからDevCloud KVMパッケージをダウンロードして下さい

3. devcloud.tarを展開し、自分がインストールしたい場所へ置き、DevCloudディレクトリへcdしてください

4. DevCloudが使用するネットワークを定義します(rootもしくはlibvirt特権ユーザで動作する)

 virsh net-define devcloud-nat-0.xml
 virsh net-define devcloud-nat-1.xml
 virsh net-start devcloud-nat-0
 virsh net-start devcloud-nat-1
 virsh net-autostart devcloud-nat-0
 virsh net-autostart devcloud-nat-1

5. devcloud.xmlを開き、qcow2ファイルのロケーションを各自のシステムに合った場所に変更して下さい

ほかにもいくつかのlibvirtのバージョンに依存する定義などを変更する必要があります。

6. devcloud.xmlを定義し、仮想マシンを開始します

 virsh define devcloud.xml
 virsh start devcloud

7. VirtualBoxセットアップ手順のステップ6から続けて下さい

 


オプション:拡張ネットワークゾーン


ステップ7をスキップして、拡張ネットワークmarvin設定の1つを使用することができます。完全な機能として、これらは各自のdevcloud上のDNSリゾルバをセットアップする必要があります。セットアップすることで、管理ネットワークは名前解決が可能となります:

 $ apt-get install dnsmasq
 $ python tools/marvin/marvin/deployDataCenter.py -i tools/devcloud/devcloud-advanced.cfg


devcloud上で管理サーバを実行したい場合:

 $ apt-get install dnsmasq
 $ python tools/marvin/marvin/deployDataCenter.py -i tools/devcloud/devcloud-advanced_internal-mgt.cfg

次に基本セットアップで説明されているとおり管理サーバを再起動します。

NATネットワーキングモデルの実装であるため、VirtualBox上でこの設定(KVM内の仮想マシン以外)ではConsole proxyは動作しません。
仮想マシンが外部と通信するためにNATを使用している間は、内部のNATネットワーク上のインターフェイスを持たないためアクセスすることができません(10.0.3.2はVirtualBoxスタック内部でありホスト上にはない)。
仮想マシンがどのポートでlistenしているか知っているのであれば、devcloud上からVNCを手動で接続すさせることは可能です(e.g. 192.168.56.10:0)。ホストオンリーネットワークをパブリックとして利用することで迂回することができますが、その場合仮想マシンは物理パブリックアクセスできず、結果何がテストしたいのかということになってしまいます。



DevCloudを用いたインタラクティブデバッギング


Eclipseなどでインタラクティブでバッグングのためにデバッグモードで管理コンソールを動作させることができます。jettyで実行する代わりに:前章のコマンドを実行し、以下のコマンドを実行します。

 export MAVEN_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=n"
 mvn -pl :cloud-client-ui jetty:run
 
 export MAVEN_OPTS=""

トラブルシューティング


グローバル設定のこれらの設定知を確認する:


host(=管理サーバIP)、system.vm.use.local.storage(=true)、適切な管理ネットワークCIDR、secondstorage.allowed.internal.sites

"tiny Linux"テンプレートが選択枝として有効でないのであれば、上記の問題が発生します。

グローバル"host"設定に誤りがあった場合は、仮想マシンのファイル/var/log/cloud/systemvm.logに以下の様なエラーが書き込まれています。

 2013-01-22 18:45:07,987 DEBUG [agent.transport.Request] (StatsCollector-2:null) Seq 1-1613496410: Receive
 2013-01-22 18:45:11,996 INFO  [utils.nio.NioClient] (Agent-Selector:) Connecting to 10.0.3.15:8250


Windowsマシン上の開発:


必ず次の関連パッケージをインストールしなくてはなりません:pythonmysql connector for pythonbash、(cygwinもしくはmsysgitで使用する)tar
もしくは、プロファイル -P developer,systemvm を使用することでスキップ可能です:-P sytemvmを使ってみて下さい。

もしdevcloudが起動に失敗したり、ブラックスクリーンのままであれば、BIOSのVT/VT-d(仮想化テクノロジー)を有効にする必要があります。ブート中にDeleteボタンを押しBIOS設定を変更して下さい。

ランダムなWindowsマシンにいくつかのバグが時々発生します:


(訳者注:えーっ!)

com.cloud.api.doc.ApiXmlDocWriter ClassNotFoundbuild-apidoc.shの以下の行を

 java -cp $CP com.cloud.api.doc.ApiXmlDocWriter -d "$DISTDIR" $*
次のように修正して下さい。
 java -cp .$CP com.cloud.api.doc.ApiXmlDocWriter -d "$DISTDIR" $*

Devcloudノートはいつもアラートを発生させます:git global configautocrlftrueとなっていないか確認してください

'-pl'(ピーエル)を'papa'、'lima'内で使用して下さい、'-p1'(ピーイチ)を使用しないで下さい


maven3を使用して下さい、古いバージョンのものは使用しないで下さい

Ubuntu上にmaven3をインストールする手順は http://superuser.com/a/298063 を参照して下さい。

デフォルトでJettyが存在しない場合、pom.xmlに以下のpluginタグを使って、mavenの処理に含めることができます:

 
  org.mortbay.jetty
  maven-jetty-plugin
  6.1.12
 


mysqlデータベースパスワードとしてNULLをセットする必要があるかもしれません

E.g. http://stackoverflow.com/questions/3032054/how-to-remove-mysql-root-password もし動作しない場合は、rootユーザのパスワードとして非NULL値に変更しファイル incubator-cloudstack/utils/db.properties.override を作成してパスワードを提供し db.root.password を更新して下さい。

もしmavenpythonを発見できない理由でビルドを失敗したのであれば、
 mvn -P developer,systemvm clean install
を実行した結果以下の様なエラーメッセージが表示されます。
 [INFO] Apache CloudStack apidoc Tools .................... SUCCESS [41.071s]
 [INFO] Apache CloudStack Developer Tools ................. SUCCESS [0.125s]
 [INFO] Apache CloudStack Developer Tools: marvin ......... FAILURE [0.158s]
 [INFO] Apache CloudStack Developer Tools: cloudmonkey cli  SKIPPED
 [INFO] ------------------------------------------------------------------------
 [INFO] BUILD FAILURE
 [INFO] ------------------------------------------------------------------------
 [INFO] Total time: 10:28.807s
 [INFO] Finished at: Tue Dec 04 17:16:54 PST 2012
 [INFO] Final Memory: 34M/145M
 [INFO] ------------------------------------------------------------------------
 [ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (compile) on project cloud-marvin: Command execution failed. Cannot run program "python" (in directory "C:\src\asf-acl\incubator-cloudstack\tools\marvin\marvin"): CreateProcess error=2, The system cannot find the file specified -> [Help 1]

以下の方法でビルドして下さい。

 mvn -P systemvm clean install


--------------------

なるほど管理サーバ側は外で構築してもいいし、仮想アプライアンスの中で作ってもいい..か。
XenServer自体使ったことがないから、管理サーバ別だしでやってみるか..


にしても..
ハイパバイザ重ねがけって結局Console Proxyだめなわけね...


2013年8月13日火曜日

【未解決】CloudStack上のコンソール表示しようとしたら、「~.realhostip.com のサーバからの応答が一定時間以内に返ってきませんでした」というエラーが出た

先に書きますが..まだ【未解決】です。

前の記事で書いた環境
単一PC上にCloudStack4.1をインストールして、
いざインスタンスを立ち上げ
コンソール画面を開こうとしたら

前回の記事の環境


「接続がタイムアウトしました
 192-168-XXX-XXX.realhostip.com のサーバからの応答が
 一定時間以内に返ってきませんでした。」

とでてきて接続できない問題が発生した。

グローバル設定の consoleproxy.url.domain
かかれているドメイン名を使ったFQDNなのだけど、
クライアントPC上でlookupするとDHCPで割り当てられた
ルータへいってしまい誰もどこにあるかわからない。

でしらべてみると、

How to Replace realhostip.com with Your Own Domain Name

という記事に、
ゾーン内にbind9(DNS)きってローカルネット側に
192-168-XXX-YYY.realhostip.com192.168.XXX.YYYであると
正引きできるようにすれば良いみたいなことが書かれている。

ドメイン名は上記のグローバル設定変更でかえることができる。


bind9を入れる気力がなかったので.
クライアントPCのhostsに直接書き込んで対処した。

Windows7ならC:\Windows\System32\drivers\etc\hostsを
ノートパッド(管理者権限起動)で
192.168.11.141        192-168-11-141.realhostip.com
192.168.11.142        192-168-11-141.realhostip.com


と男らしく書いていく。

本格的にCloudStack運用する場合はDNSサーバは必要だな..


でもそれだけじゃないな..結局のところ192.168.11.xセグメントに
192.168.11.1と192.168.11.100という2つのルータがつながっているようなもの
なので、これをなんとかするにはきちんとrouteコマンドで処理しとかないと..

routeコマンドで「192.168.11.141~160」へ通信する場合は
192.168.11.100をゲートウェイにしてねという設定を実行し無くてはならない。

ルーティング変更目的でrouteコマンドをWindowsで使用する場合は、
コマンドプロンプトを管理者権限であげること。
(route PRINTでテーブルの状態見るくらいなら通常起動でもOK)

で、ここではたと気づいたのだけど、
CloudStack管理下のセグメントを着る場合はCIDR表記ができるようにしとけばよかった..
そうすればrouteコマンドでプライベートアドレス範囲はこのゲートウェイというように
綺麗に1発で指定できる。
そうしないと192.168.11.141/32から192.168.11.160/32まで2回routeコマンド打たないと
いけなくなるんじゃ..

サブネット計算苦手な人はこちらの計算サイト(IPv4)があります。

IPの範囲指定する場合はできるだけCIDRで切れる範囲を
選ぶようにしよう..

で次にクライアントPC上で以下のrouteコマンドを1つづつ発行した。

route add 192.168.XXX.YYY mask 255.255.255.255 192.168.11.100 metric 1

そして再度管理コンソールからコンソール画面開こうとしたのだけど..
あれ?ひらかない..

CloudStack All in One サーバ(192.168.11.100)からプライベートセグメントへの
ルーティングがない..

管理サーバからは、いくつかネットワーク設定があるが

cloud0: オートナンバ用
cloudbr0: サーバのNICへつながるブリッジ
eth0: 物理的なNICをさす
virbr0: 192.168.122.1(KVMインストールするとできる)

だろうからvnet0~9があやしいのだけど..
どのネットワークがインスタンスが使用しているのかがわからないので
ルーティングしようがない..


うーん、All in Oneサーバはクライアントも兼ねないと駄目かな..

taskselしてUbuntu Desktopインストール
して管理サーバ上でブラウザあげて
そこで管理コンソールを開けるか..


2013年8月12日月曜日

NIC1枚しか無い物理PCへCloudStack4.1をインストールする

前の記事でKVM重ねがけで実現していましたが、
やっぱり残念なので再度KVM重ねがけなしで
管理サーバ、DBサーバ、ストレージ、ホストすべて
1台の物理PCしかもNIC1枚で構築しなおしてみました。


ただ..この環境でセットアップすると
インスタンス作成まではうまくいきますが、
管理コンソール上のコンソール画面が動作しません。

All in Oneサーバ上でブラウザを開いても駄目でした。

詳細は次の記事に書いていますが..
KVM重ねがけの場合は親サーバから各セグメントが見えているので
親サーバ上のブラウザからなら問題なくコンソールは上がるのですが...




0. 用意したもの


・インターネット接続可能なセグメントに接続されたPC1台
 MouseComputer
 Core i7 1.2GHz×8
 HDD 500GB/Mem 8GB
 NIC 1枚(DHCP範囲外で固定IP割り当て、Proxyなし)
 ※PCによってはBIOSでIntelVTを有効化する必要がある
Ubuntu Server 12.04.2LTS CD-ROM
・Buffalo製WZR-HP-G450H
 家庭用ルータ
 デフォルト設定(リセットスイッチ押下→iフィルタオフ)
 LAN側:
  ルータのIP192.168.11.1
  DHCP有効範囲:192.168.11.2~65
  ※66番目以降は自由に固定IPを使える
・インターネット接続
 ルータのWAN側に接続
 プロクシ無しで接続できる
・クライアントPC(ルータにつながり、ブラウザが入っていればOK)

1. OSのインストール

  • Ubuntu Server12.04.2LTS CD-ROMメディアを挿入し電源オン
  • 日本語
  • Ubuntu Serverをインストール(I)
  • はい
  • 日本
  • 日本語
  • 日本語 - 日本語(かな 86) ※各自のキーボードによる
  • Alt + Shift
  • 戻る ※DHCPが引けたが固定IPを振る
  • ネットワークを手動で設定
  • 192.168.11.100
  • 255.255.255.0
  • 192.168.11.1
  • 192.168.11.1
  • william
  • royal ※ドメイン名は適当に変更すること
  • cloud ※OSアカウントは適当に変更すること
  • cloud ※OSアカウントは適当に変更すること
  • cloud ※パスワードは適当に変更すること
  • cloud
  • はい
  • いいえ
  • はい
  • ガイド - ディスク全体を使いLVMをセットアップする
  • SCSI1 (0,0,0) (sda) - 500.1 GB ATA Hitachi HDS72105 ※環境による
  • はい
  • はい
  • 499.8GB ※環境による
  • はい
  • いいえ
  • 空欄で次へ
  • 自動的にアップデートしない ※適宜変更
  • 続ける
  • はい
  • PCからCD-ROMを取り出す
  • 続ける ※再起動
  • cloud ※OSアカウントは適当に変更すること
  • cloud
  • sudo su -
  • cloud
  • vi .profile
 (最終行へ以下の1行を追加)
 export LANG=C
  • exit
  • sudo su -
  • cloud
  • vi /etc/sysctl.conf
 (最終行へ以下の2行を追加)
 net.ipv6.conf.all.disable_ipv6 = 1
 net.ipv6.conf.default.disable_ipv6 = 1
  • sysctl -p
  • vi /etc/apt/sources.list.d/cloudstack.list
 (新規:以下の行を追加)
 deb http://cloudstack.apt-get.eu/ubuntu precise 4.1
  • wget -O - http://cloudstack.apt-get.eu/release.asc|apt-key add -


2. プライマリ/セカンダリストレージ構築

  • aptitude update && aptitude -y dist-upgrade && aptitude -y install ssh openntpd nfs-kernel-server bridge-utils
  • vi /etc/network/interfaces
 (iface eth0 inet static以降を以下のように変更)
 iface eth0 inet manual
 iface cloudbr0 inet static
  address 192.18.11.100
  netmask 255.255.255.0
  network 192.168.11.0
  broadcast 192.168.11.255
  gateway 192.168.11.1
  dns-nameservers 192.168.11.1
  dns-search royal
  bridge-ports eth0
  bridge-stp off
 auto cloudbr0
  • mkdir -p /export/primary /export/secondary
  • vi /etc/exports
 (最終行に以下の1行を追加)
 /export *(rw,async,no_root_squash,no_subtree_check)
  • exportfs -a
  • vi /etc/modprobe.d/nfs_lockd.conf
 (新規:以下の1行を追加)
 options lockd nlm_udpport=32769 nlm_tcpport=32803
  • vi /etc/default/nfs-kernel-server
 (修正前)
 RPCMOUNTDOPTS=--manage-gids
 (修正後)
 RCPMOUNTDOPTS="--port 892"
  • vi /etc/default/nfs-common
 (修正前)
 STATDOPTS=
 (修正後)
 STATDOPTS="--port 662 --outgoing-port 2020"
  • ufw allow 111
  • ufw allow 662
  • ufw allow 32769/udp
  • ufw allow 32803/tcp
  • ufw allow 2049
  • ufw allow 892
  • reboot

3. 管理サーバの構築

  • cloud ※OSへログインするユーザ
  • cloud
  • sudo su -
  • cloud ※聞かれない場合あり
  • aptitude -y install mysql-server cloudstack-management
  • cloud ※MySQLのrootパスワード
  • cloud
  • vi /etc/mysql/my.cnf
 ([mysqld]セクション内に以下の5行を追加)
 innodb_rollback_on_timeout=1
 innodb_lock_wait_timeout=600
 max_connections=350
 log-bin=mysql-bin
 binlog-format = 'ROW'
  • service mysql restart
  • cloudstack-setup-databases cloud:cloud@localhost --deploy-as=root:cloud
  • cloudstack-setup-management
  • mkdir -p /mnt/secondary
  • mount -t nfs 192.168.11.100:/export/secondary /mnt/secondary
  • mount -t nfs 192.168.0.1:/export/secondary /mnt/secondary
  • /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-mount-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm -F
  • umount /mnt/secondary
  • cd /mnt
  • rmdir secondary
  • reboot


4. ホストの構築

  • cloud ※OSログインユーザ
  • cloud
  • sudo su -
  • cloud ※聞かれない場合あり
  • passwd root
  • cloud ※OSのルートパスワードを設定
  • cloud
  • aptutude -y install kvm qemu-utils qemu-kvm libvirt-bin virtinst cloudstack-agent
  • vi /etc/default/libvirt-bin
 (修正前)
 libvirtd_opts="-d"
 (修正後)
 libvirtd_opts="-d -l"
  • vi /etc/init/libvirt-bin.conf
 (修正前:11行目)
 env libvirtd_opts="-d"
 (修正後:11行目)
 env libvirtd_opts="-d -l"
  • vi /etc/libvirtd/libvirtd.conf
 (以下の行をコメントアウト)
 listen_tls = 0
 listen_tcp = 1
 tcp_port = "16509"
 mdns_adv = 0
 (修正前)
 #auth_tcp = "sasl"
 (修正後)
 auth_tcp = "none"
  • service libvirt-bin restart
  • ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/
  • ln -s /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper /etc/apparmor.d/disable/
  • apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd
  • apparmor_parser -R /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
  • ufw allow proto tcp from any to any port 22
  • ufw allow proto tcp from any to any port 3922
  • ufw allow proto tcp from any to any port 1798
  • ufw allow proto tcp from any to any port 16509
  • ufw allow proto tcp from any to any port 5900:6100
  • ufw allow proto tcp from any to any port 49152:49216
  • ufw allow proto tcp from any to any port 9090
  • ufw allow proto tcp from any to any port 8250
  • ufw allow proto tcp from any to any port 8080
  • vi /etc/idmapd.conf
 (修正前)
 #Domain = localdomain
 (修正後)
 Domain = royal
  • vi /etc/sudores
 (11行目に以下の1行を追加し強制保存
 Defaults:cloud !requiretty
  • reboot

5. ゾーンの構築

※クライアントPCをルータの無線LANに接続(優先でもOK)
 DHCPにより192.168.11.2~65のいずれか1つ割り当てられる
※インターネットオプションでプロクシなし設定にしておく
  • ブラウザを起動
  • http://192.168.11.100:8080/client を開く
  • Language欄を「Japanese」に変更
  • ユーザ名「admin
  • パスワード「password
  • ドメインは空欄のまま
  • 「ログオン」ボタン押下

  • 「CloudStackを使用したことがあるので、このガイドをスキップする」押下

  • 「インフラストラクチャ」押下


  • ゾーンの「すべてを表示」押下


  • 「+ゾーンの追加」押下


  • 「基本」をチェック
  • 「Next」押下


  • 名前に「zone01」と入力
  • DNS1に「192.168.11.1」と入力 ※publicネットワークのDNS(NAT)として
  • 内部DNS1に「192.168.11.1」と入力 ※privateネットワークのDNS(NAT)として
  • ハイパーバイザを「KVM」に変更
  • 「Next」押下


  • 管理の「Edit」押下


  • KVMトラフィックラベルに「cloudbr0」と入力 ※privateネットワーク
  • 「OK」押下


  • ゲストの「Edit」押下


  • KVMトラフィックラベルに「cloudbr0」と入力 ※publicネットワーク
  • 「OK」押下


  • トラフィックの種類上の「ストレージ」アイコンをドラッグしてPhysical Network 1の破線部内へドロップ
  • ストレージの「Edit」押下


  • KVMトラフィックラベルに「cloudbr0」と入力 ※storageネットワーク
  • 「OK」押下
  • 「Next」押下


  • ポッド名に「pod01」と入力 ※privateネットワークの情報を設定
  • 予約済みシステムゲートウェイに「192.168.11.1」を入力
  • 予約済みシステムネットマスクに「255.255.255.0」を入力
  • 予約済み開始システムIPアドレスに「192.168.11.121」を入力
  • 予約済み終了システムIPアドレスに「192.168.11.140」を入力
  • 「Next」押下


  • ゲストゲートウェイに「192.168.11.1」を入力 ※publicネットワークの情報を設定
  • ゲストネットマスクに「255.255.255.0」を入力
  • ゲストの開始IPアドレスに「192.168.11.141」を入力 ※非DHCPなので4より上を適当に割り当てる
  • ゲストの終了IPアドレスに「192.168.11.160」を入力
  • 「Next」押下


  • ゲートウェイに「192.168.11.1」と入力 ※storageネットワークセグメントで記述
  • ネットマスクに「255.255.255.0」と入力
  • VLANは空欄のままにする
  • 開始IPアドレスに「192.168.11.161」と入力
  • 終了IPアドレスに「192.168.11.180」と入力
  • 「追加」押下


  • 「Next」押下


  • クラスタ名に「cluster01」と入力
  • 「Next」押下


  • ホスト名に「192.168.11.100」と入力 ※privateネットワークのIPアドレス
  • ユーザ名に「root」と入力
  • パスワードに「cloud」と入力
  • ホストタグは空欄のままにする
  • 「Next」押下


  • 名前に「primary01」と入力
  • プロトコルは「nfs」のままにする
  • サーバーに「192.168.11.100」と入力 ※本来はホストのIPアドレスをstorageネットワークアドレスで記述
  • Pathに「/export/primary」と入力
  • ストレージタグは空欄のままにする
  • 「Next」押下


  • NFSサーバーに「192.168.11.100」と入力 ※本来はホストのIPアドレスをstorageネットワークアドレスで記述
  • パスに「/export/secondary」と入力
  • 「Next」押下


  • 「Launch zone」押下 ※時間が少し掛かる
※ゾーンを有効化するかのダイアログが表示される

  • 「はい」押下
※管理コンソール画面に戻る

  • 右の「インフラストラクチャ」を押下


  • 「更新」を押下
  • システムVMの「すべてを表示」を押下


  • 2つのVMが存在し、ステータスが両方「Running」になるまで待機(結構時間がかかる)


  • 画面左の「テンプレート」を押下


  • 「CentOS 5.5(64-bit) no GUI (KVM)」をクリック


  • 準備完了欄が「Yes」となるまで待機(すこじ時間がかかる)

6. テスト

※Ubuntu Server12.04.2LTSのISOイメージを取り込み、インスタンスを起動するところまで

6.1 ISOイメージの取り込み

※管理コンソールが立ち上がり、adminでログイン済みの状態

  • 画面左の「テンプレート」を押下


  • 画面上のビューの選択を「ISO」に変更


  • 画面右上の「+ISOの登録」を押下


ここではUbuntuサイトを指しているので、特にグローバル設定変更は不要。
もし192.168.11.100上にApache2をインストールしてローカルのHTTPサーバ
からダウンロードしたい場合は、
secstorage.allowed.internal.sites」にCIDR表記でIP範囲指定する。
例えば「192.168.11.0/24」とすればよい。
  • ゾーンは「All Zone」のままにする
  • 起動可能はチェックのままにする
  • OSの種類を「Ubuntu 12.04 (64-bit)」に変更する
  • 抽出可能のチェックはないままとする
  • パブリックをチェックする
  • おすすめをチェックする
  • 「OK」押下
  • 「Ubuntu Server 12.04.2 LTS」をクリックする
  • 準備完了欄が「Yes」になるまで待機(更新ボタンで再表示して確認する)

6.2 インスタンス作成

  • 画面左の「インスタンス」を押下する
  • 画面右上の「+インスタンスの追加」を押下
  • ゾーンの選択は「zone01」のままとする
  • ISOまたはテンプレートの選択は「ISO」をチェック
  • 「次へ」押下
  • おすすめタブのUbuntu Server 12.04.2 LTSがチェックされているままとする
  • Hypervisorは「KVM」のままとする
  • 「次へ」押下
  • 「Small Instance」をチェックしたままにする
  • 「次へ」押下
  • 「Small」をチェックしたままにする
  • 「次へ」押下
  • 「default」をチェックする
  • 名前(オプション)欄に「Test」と入力する
  • グループへの追加(オプション)欄を空欄のままとする
  • 「VMの起動」押下
  • 画面左の「インスタンス」を押下する
  • 「Test」をクリックし、詳細タブの一番上にアイコン群がならぶまで待機する
  • アイコン群の右端のアイコン(コンソールの表示)をクリックする
  • ※UbuntuのインストーラのLanguage選択が出ればOK、あとは継続するかは適宜

以上



【注意】
最初にも書きましたが、インスタンスまでは作成されますが
コンソール画面をひらくとエラーになります。
現在調査中です。


最初、1つのLANに複数のセグメントを混ぜようかと思ったが、
KVMかさねがけによるKMのNAT設定を使ったなんちゃってルーティングがないので
同一セグメントを切り分けして設定した。

cloudbr0というブリッジを1つ作成し、
192.168.11.2~192.168.11.65はそのままルータのDHCP割り当てさせておき、
192.168.11.121~192.168.11.140 を管理ネットワーク(private)に、
192.168.11.141~192.168.11.160をゲストネットワーク(public)に、
192.168.11.161~192.168.11.180storageネットワークに
固定IP領域をそれぞれに割り振る。

このため3つのネットワークの
デフォルトゲートウェイは192.168.11.1
サブネットは255.255.255.0
DNSサーバはNATなのでルータのLAN側IPアドレス192.168.11.1
割り当てる。



やはりSecondary Storage VMで起動停止を繰り返す問題は、
渡しの場合ufwコマンドで設定するポートが足りなかったのだと思う。





Google Colab相当の環境をローカルPC上のDocker Composeで実現する

 Docker Composeの有料版に、お金を払いたくない ^H^Hが使えない ため古いゲーミングPC(GeForce3080)にDocker Composeを入れてその上のコンテナでGoogle Colab相当のノート操作ができないかためしてみた: コンテナイメージとして a...