Cloud Foundryのロードマップ

February 12, 2013 | by | #cfcrjp, cloudfoundry

github上でCloud Foundryのロードマップが公開されていました。

http://cloudfoundry.github.com/docs/roadmap.html

以下てきとうな和訳

2013年2月

  • TeamEditionが入ったMicro Cloud Foundryのプレビュー版を出すよ
  • 全てのリポジトリでGerritを使うのを止めて、GithubでのPull Requestする形にするよ
  • 整理したドキュメントを出すよ(というか今見てるコレがそう)

下にも出てきますが、次期Cloud Controller(CCngと呼ばれていたもの)もひっくるめて、次期版を「Team Edition」と呼ぶようになったみたいですね。
Gerritでのレビューは少々敷居が高く、パッチを送るのにも躊躇うことがあったので、Githubで統一されたのは嬉しいニュース。ドキュメントの整備は今頃かよ、というツッコミどころはあれど、とても重要だとおもいます。

2013年4月

Routerのアップデート

  • Goで書かれたものに移行。もうnginxは使わない
  • 4倍速いよ
  • WebSocketサポートするよ

gorouterと呼ばれていた、Goで書かれたRouterが投入されるようです。WebSocketサポートは気になりますね。SSL周りの対応はどうなんでしょうね

Cloud Foundry API 2.0をサポートしたCloud Controllerのアップデート

  • “Organizations”や”Spaces”といった概念を使って、チームを作れるようになるよ
  • appsやservicesでチームコラボレーションできるようになるよ
  • カスタムドメイン管理ができるよ
  • ユーザーの管理や権限の管理ができるよ
  • Cloud Controller DBでMySQLがサポートされるよ(今はPostgresのみ)
  • Blob storageはローカルディレクトリとS3をサポート。
  • クオータ設定が強化。
    • アプリケーション数制限
    • メモリ合計値制限
    • サービスの数やタイプの制限
  • Usage eventsを取れるように。監査や課金につかえるんじゃないかな。

CCngの各種変更点がぞろぞろ。やはりチーム対応が大きいでしょうか。

DEAのアップデート

  • Herokuにインスパイアされたbuildpackをサポートするよ
    • 言語やコンテナを簡単にプラットフォームに持ち込めるように。
    • コンテナ化されたbuildpackを使えば、CFのコンポーネントに手を加える必要はないよ
    • MITライセンスなHeroku buildpackのエコシステムに乗っかります
    • 他のbuildpackをフォークしたり手を加えたりして使えるよ。あるいは自分で作ることもできるよ
  • Linuxコンテナでアプリケーションの独立性を担保するよ。
  • Stagerの代わりにDEAでStagingが行われます
    • なので再ステージング無しで環境変数変えられます

Buildpack対応と、コンテナ(Warden)対応が目玉ですね。コンテナ対応で、ようやく「使えるマルチテナント」になる気がします。

Servicesのアップデート

  • 各Servicesのバージョンが上がるよ
    • MongoDB 2.2
    • MySQL 5.5
    • Postgres 9.1
    • RabbitMQ 2.8
    • Redis 2.6
  • 大きなキャパシティをもったServiceを作れるようになります
  • 「アイソレーションオプション」を有効にしたServiceインスタンスを作れるように
    • これはLinuxコンテナの中でServiceインスタンスを動かす仕組み。これによって、セキュリティと収容効率を両立できる。
    • 最大限に独立性を担保するなら、VM分けることもできるよ
  • スナップショットに対応。スナップショットの管理やリストア、ダウンロードができるように

ServicesのWarden対応はあんま追えてないんですが、4月に出てくるんですね・・・。

HealthManagerのアップデート

  • けっこうパフォーマンス上がったわ

CCngとセットな感じですね。

Team Edition Web Portal(エンタープライズ向け)

  • CFのWebUI
  • ユーザー、アプリケーション、サービス、ドメインの管理ができるよ
  • 利用状況の閲覧や管理ができるよ

Enterprise Offeringとあったので、出る出ると言いながらなかなか出てこないCloud Foundry Enterprise(Bento)で提供されるんでしょうか。

UAAのアップデート

  • 起動が簡単になったよ
  • ユーザーの承認や停止が管理できるように

ここの訳、いまいち自信ないです

AWSでより簡単に使えるように

  • 簡単デプロイ
    • いくつかの質問に答え、AWSの認証情報を与えるだけでマルチノードデプロイされるようになるよ
  • BOSHがDHCPサポートするよ
  • BOSHがAWS VPCネットワークに対応するよ

AWSで簡単にデプロイできるようになったようです。BOSHの機能追加でしょうか(イマイチ自分はBOSH追えてないのですが)

VPC対応ということで、プライベートPaaSの構築が容易になりますね。

No Comments »

CloudStackのロゴを分析をしてみる

February 12, 2013 | by | cloudstack

cloudstack_title

どうもこんにちは、jacoです。
1年ほど前、Cloud Foundryロゴの分析をしてみるという変化球な記事を書いたことがあったのですが、意外と好評で、もう一度ああいうの書かないの?という話を頂きました。

というわけで、今回はCloudStackのロゴに使われているフォントを調べてみようと思います。

CloudStackのロゴはサイトを見ているだけでも微妙にバリエーションがあり、どれが正当なものか良く分からないのですが、今回はCloud Monkeyと一緒に使われているものについて分析してみました。コレが一番バランスも良く、キレイなデザインだったので。

分析しよう

さっそく詳しく見てみましょう。特徴的な箇所がいくつか見当たりますね。
cloudstack2

まずフォントについて。「c」や「o」の形を見ると、ジオメトリック・サンセリフ系かな?と感じます。ジオメトリック・サンセリフとは、円や直線といった幾何学的な図形で構成されている書体です。例にも挙げていますが、Futuraが有名ですね。
ただし、完全にジオメトリック・サンセリフとはいえません。「a」や「t」の形、「u」のアーチ部分などは、ヒューマニスト・サンセリフのような特徴が出ています。ヒューマニスト・サンセリフとは、サンセリフの中でもセリフのような骨格を残し、なんとなく人間味を感じさせる書体のことを言います。FrutigerやMyriadが有名です。

Helveticaのようなリアリスト・サンセリフの特徴は今回のものには見受けられませんが、参考までに載せておきます。

あと一つ気になるのが、アセンダライン(アルファベットの小文字の上に飛び出す部分)が不揃いな点です。欧文フォントでこれが揃っていないのは珍しいので、後から手を加えた可能性もありそうですね。

結論

さて、分析の結論です。

CloudStackロゴは、私の敬愛するアドリアン・フルティガー氏の「Avenir」だと思われます。
下の画像は、Avenirを使って再現したものです。

cloudstack3

cloudの部分は、横が95%潰された長体になっています。アセンダラインは多分削ったんだと思うので、似たように削ってみました。右にあるAvenirそのものと比べると、「d」や「l」が多少低くなっていることが分かると思います。

あとはちょこちょこっとカーニングを調整して出来上がり。

Avenirには、フルティガー氏と小林章氏が手を加えた「Avenir Next」というものもあるのですが、CloudStackロゴはAvenirだと思います(自信度70%くらい) Avenir Nextは手持ちに無いため、ちょっと比較ができませんでした。

ちなみに、「Avenir」はフランス語の「未来」という言葉らしいですよ。これがラテン語だと「Futura」だそう。なるほど、フルティガー氏がFuturaを意識しつつ、氏の作ったFrutigerの要素も入れて生まれたものがAvenirだと。納得ですね。

さて。気が向いたら、次はCloudStackのライバルであるアレを調べてみましょうかね。
ではでは

フォントのふしぎ  ブランドのロゴはなぜ高そうに見えるのか?
小林章
美術出版社
売り上げランキング: 4536
書体の研究 for Digital Creators
山王丸 榊
晋遊舎
売り上げランキング: 195393

No Comments »

CloudStackのログイン画面の文字化け解消

December 29, 2012 | by | cloudstack

@Mt_mo1019と申します。

こちら、cloudstack advent calendarの29日目(?)の記事、第2部です。

第1部は前回発生したCloudStackの文字化けの解消方法となります。

ただし、暫定的な対処の可能性もあり、他の画面に影響がでないことを検証できていないので、完全対処でなくてもご容赦ください。

前回URL:http://blog.udcp.net/2012/12/29/devcloud2の導入/

 CloudStackのログイン画面の文字化け解決

第一部で紹介したログイン画面では、左の画面の様に日本語が文字化けしていました。

 

今回はこの文字化けを解消するための記事となります。

 

 

 

 

 

結論

先に結論を記載しますが、本件はCloudStackの画面表示に使う、設定ファイルのエンコーディングが問題でした。

具体的には/incubator-cloudstack/client/WEB-INF/classes/resources配下の設定ファイルになります。

git-hubから取得した時のエンコードは以下の状態です。


root@devcloud:~/incubator-cloudstack/client/WEB-INF/classes/resources# nkf --guess *

messages_fr_FR.properties: BINARY

messages_ja.properties: UTF-8 (LF)

messages.properties: ASCII (LF)

messages_pt_BR.properties: BINARY

messages_ru_RU.properties: UTF-8 (CRLF)

messages_zh_CN.properties: UTF-8 (MIXED NL)

UTF-8で設定されているファイルをASCIIに修正してください。コマンドは以下の通りです。

root@devcloud:~/incubator-cloudstack/client/WEB-INF/classes/resources# nkf -Z [元ファイル] > [出力先ファイル]

出力したファイルを元の/incubator-cloudstack/client/WEB-INF/classes/resources配下に置き換えます。

最終的にこういった形になればよいです。


root@devcloud:~/incubator-cloudstack/client/WEB-INF/classes/resources# nkf --guess *

messages_fr_FR.properties: BINARY

messages_ja.properties: ASCII (LF)

messages.properties: ASCII (LF)

messages_pt_BR.properties: BINARY

messages_ru_RU.properties: ASCII (LF)

messages_zh_CN.properties: ASCII (LF)

置き換えた状態で、ビルド→起動すると、文字化けが改善されます。

ビルド→起動は、incubator-cloudstackディレクトリに移動して以下のコマンドを打ちます。

※今回は環境構築のみなので、時間省略のためにテストを省くコマンドを打っています。

root@devcloud:~/incubator-cloudstack# mvn -Dmaven.test.skip=true -P developer,systemvm clean install
root@devcloud:~/incubator-cloudstack# mvn -P developer -pl developer,tools/devcloud -Ddeploydb
root@devcloud:~/incubator-cloudstack# mvn -pl :cloud-client-ui jetty:run

この状態でブラウザからCloudStackにアクセスします。

修正できました。

ただし、ブラウザのエンコードはShit-JISにしてください。

文字化けしている他言語(中国語、ロシア語)も、同様にブラウザのエンコードを変更することで直ります。

 

 

 

 

 

 

文字化け解決までのプロセス

ここからは、文字化け解消にいたったプロセスを記載します。

 

プロセスの概要

以下の手順を踏んで解析しています。

  1. 画面のソースコードの確認
  2. 該当ラベルの設定ファイルの文字コード確認

また、文字化けの現状整理をしておきます。

  • ログイン画面の文字化けが発生する。
  • http://192.168.56.10:8080/client/にアクセスした際、文字化けする。
  • 文字化けする言語は日本語、簡体字中国語、ロシア語
  • 文字化けしない言語は英語、フランス語、ブラジル語

画面のソースコードの確認

まず、文字化けの発生したソースコードを確認しました。

対象ファイルは/incubator-cloudstack/ui/index.jspです。

左の画面は対象のjspファイルです。

赤く囲んだ箇所が文字化けしている箇所になります。

設定ファイルから画面表示名を取得していることがわかります。

 

 

 

 

Strutsではメッセージの設定ファイルはunicode(ASCII)コードでエンコードしてある必要がるので、そこが文字化けでの原因ではないかと思いました。

該当ラベルの設定ファイルの文字コード確認

それでは、該当の設定ファイルの文字エンコード情報を見てみます。

先述しましたが、/incubator-cloudstack/client/WEB-INF/classes/resources配下の設定ファイルになります。

git-hubから取得した時の文字コードは以下の状態です。


root@devcloud:~/incubator-cloudstack/client/WEB-INF/classes/resources# nkf --guess *

messages_fr_FR.properties: BINARY

messages_ja.properties: UTF-8 (LF)

messages.properties: ASCII (LF)

messages_pt_BR.properties: BINARY

messages_ru_RU.properties: UTF-8 (CRLF)

messages_zh_CN.properties: UTF-8 (MIXED NL)

見事に文字化けしている言語の設定ファイルがUTF-8のエンコードです。

※2byte文字がunicode文字だと見づらいので、utf-8にエンコードしてそのままなのでしょうか?

なので、先述したエンコーディグ対処をすることで解決となりました。

残課題?

この対処をしても、最初のアクセス時は文字化けが発生しました。

これは、index.jspのmetaタグの指定がutf-8のみの指定となっているからだと思います。

親切にするなら、プルダウンで選ばれた言語に応じて、metaタグのエンコード設定を変更する必要があります。

さらに、初回アクセス時はブラウザの言語情報を読みとっているので、言語情報からmetaタグの情報を変更できると、より親切かと思いました。

 

余談ですが、修正パッチは作成できませんでした。。。すみません。

 

以上になります。ありがとうございました。

 

参考

文字コードとブラウザの関係:http://www.mozilla.gr.jp/standards/webtips0022.html

strutsの設定ファイルのエンコード:http://www.javaroad.jp/opensource/js_struts16.htm

No Comments »

DevCloud2の導入

December 29, 2012 | by | cloudstack

@Mt_mo1019と申します。

こちら、cloudstack advent calendarの29日目(?)の記事の第1部です。 次の記事と合わせて2本立てになっております。本記事は以下の1本目のみとなります。記事の概要は以下の通りです。

  1. DevCloud2の導入
  2. CloudStackのログイン画面の文字化け解消(cloudstack advent calendar 25日目の記事の同事象と思われます。):http://blog.udcp.net/2012/12/29/cloudstackのログイン画面の文字化け解消/

1はCloudStackの環境を作ってちょっと触ってみたいけど、ハードの調達や英語読むのが面倒etc…などの理由で諦めることなくCloudStack環境が作成できることを目的としています。

2は1で導入したCloudStackの文字化けが気になって仕方なかったので、ソースの手入れをして応急処置をした内容となりますので、興味がある方はお目通し願います。

 DevCloud2の導入

DevCloud2とは

DevCloud2のcwikiによりますと、 DevCloud2はVirtualBoxのイメージファイルであり、イメージファイルを導入をするだけでCloudStackの開発/試験環境が簡単に作れるもの。 の様です。

要は、ハードを準備しなくても、2GBのメモリの空き容量のあるマシンが1台あれば、ローカルにCloudStack環境が簡単に作れる。ということです。

敷居が下がって素晴らしいです。 早速ですが、導入したいと思います。

大枠の手順

基本的にはDevCloud2のcwiki通りに実施していきます。

  1. DevCloud2のイメージファイルダウンロード
  2. VirtualBoxのインストール
  3. DevCloud2のイメージ取り込み
  4. VirtualBoxの設定
  5. DevCloud2内でのCloudStack環境構築

また、今回使用した環境は以下の通りです。

  • Mac Book Pro
  • OS : OS X  10.8.2
  • メモリ :  8GB

  DevCloud2の具体的な導入手順

DevCloud2のイメージファイルダウンロード

DevCloud2のcwiki内のリンクからダウロードをします。

cwiki : https://cwiki.apache.org/confluence/display/CLOUDSTACK/DevCloud

 

 

 

 

 

 

 

VirtualBoxのインストール

VirtualBoxは4.2以降を推奨しております。 VirtualBoxをダウンロード&インストールしてください。ここではインストール方法は割愛させていただきます。

VirtualBoxのダウンロード : https://www.virtualbox.org/wiki/Downloads

VirtualBoxのイメージ取り込み

インストールしたVirtualBoxを開くと、以下の様な画面が開かれると思います。(既にイメージファイルを取り込んだ状態でのキャプチャとなります。すみません。)

 

この画面から、先ほどダウンロードしたイメージファイルを取り込みます。

 

 

 

ファイル >  仮想アプライアンスのインポート をクリックします。

 

インポート画面が表示されますので、「アプライアンスを開く」を選択して、イメージファイルを選択します。

イメージファイルを選択したら、「続ける」をクリックします。

 

 

 

設定はそのままで、「インポート」をクリックします。

ライセンスの同意を求められる画面が表示されますが、「同意する」をクリックします。

これで、イメージファイルの取り込みは完了です。

 

 

 

 

 

 

VirtualBoxの設定

次に、VirtualBoxのネットワーク設定をします。

Oracle VM VirtualBox マネージャー画面から

VirtualBox > 環境設定… > ネットワーク を選択します。

 

左の様な画面が表示されたら、編集ボタンをクリックして、ネットワークの編集画面を開きます。

 

 

 

DHCPサーバの「サーバーを有効化」のチェックを外します。

 

 

 

 

 

 

 

VirtualBoxの設定は以上となります。

ここで、 インポートしたDevCloud2を起動しておきます。

 

DevCloud2内でのCloudStack環境構築

ここから、CloudStackの環境を整備していきます。

先ほどまででの操作で、起動したDevCloud2環境にsshログインをします。 ※今回はターミナルを利用して実施していますがVirtualBoxのコンソール画面から実施してもよいです。

  • IPアドレス:192.168.56.10
  • ユーザ:root
  • パスワード:password
$ ssh root@192.168.56.10root@192.168.56.10's password:Linux devcloud 3.2.0-4-686-pae #1 SMP Debian 3.2.32-1 i686The programs included with the Debian GNU/Linux system are free software;the exact distribution terms for each program are described in theindividual files in /usr/share/doc/*/copyright.Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extentpermitted by applicable law.

Last login: Thu Dec 27 15:49:44 2012 from 192.168.56.1

root@devcloud:~#

ログインしたら、下記コマンドでgit-hubから最新のCloudStackのコードを取得します。

配布情報URL : http://incubator.apache.org/cloudstack/downloads.html

$ git clone https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git

上記コマンドでソースが取得できたら、incubator-cloudstackディレクトリが作成されます。

incubator-cloudstackディレクトリに移動して、mvnコマンドでビルド→実行まで自動で実施してくれます。コマンドは以下の3つを上から順に実施します。

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

各実行結果は以下の通りです。


root@devcloud:~/incubator-cloudstack# mvn -P developer,systemvm clean install

[INFO] Scanning for projects...

[INFO] ------------------------------------------------------------------------

[INFO] Reactor Build Order:

[INFO]

(中略)

[INFO] CloudStack Dns Notifier Example ................... SUCCESS [1.466s]

[INFO] Apache CloudStack AWS API Bridge .................. SUCCESS [33.549s]

[INFO] Apache CloudStack Client UI ....................... SUCCESS [6.716s]

[INFO] Apache CloudStack Test ............................ SUCCESS [2.450s]

[INFO] Apache CloudStack Developer Tools ................. SUCCESS [0.042s]

[INFO] Apache CloudStack apidoc Tools .................... SUCCESS [14.602s]

[INFO] Apache CloudStack Developer Tools ................. SUCCESS [0.039s]

[INFO] Apache CloudStack Developer Tools: marvin ......... SUCCESS [2.321s]

[INFO] Apache CloudStack Developer Tools: cloudmonkey cli SUCCESS [1.219s]

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 2:32.097s

[INFO] Finished at: Fri Dec 28 17:12:04 UTC 2012

[INFO] Final Memory: 25M/62M

[INFO] ------------------------------------------------------------------------


root@devcloud:~/incubator-cloudstack# mvn -P developer -pl developer,tools/devcloud -Ddeploydb

[INFO] Scanning for projects...

[INFO] ------------------------------------------------------------------------

[INFO] Reactor Build Order:

[INFO]

[INFO] Apache CloudStack Developer Tools

[INFO] Apache CloudStack Developer Tools

[INFO]

[INFO] ------------------------------------------------------------------------

[INFO] Building Apache CloudStack Developer Tools 4.1.0-SNAPSHOT

[INFO] ------------------------------------------------------------------------

[INFO]

(中略)

[INFO] ------------------------------------------------------------------------

[INFO] Reactor Summary:

[INFO]

[INFO] Apache CloudStack Developer Tools ................. SUCCESS [7.933s]

[INFO] Apache CloudStack Developer Tools ................. SUCCESS [0.045s]

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 8.501s

[INFO] Finished at: Fri Dec 28 17:13:41 UTC 2012

[INFO] Final Memory: 12M/30M

[INFO] ------------------------------------------------------------------------


root@devcloud:~/incubator-cloudstack# mvn -pl :cloud-client-ui jetty:run

[INFO] Scanning for projects...

[INFO]

[INFO] ------------------------------------------------------------------------

[INFO] Building Apache CloudStack Client UI 4.1.0-SNAPSHOT

[INFO] ------------------------------------------------------------------------

[INFO]

[INFO] >>> maven-jetty-plugin:6.1.26:run (default-cli) @ cloud-client-ui >>>

(中略)

[INFO] Started Jetty Server

INFO [cloud.cluster.ClusterManagerImpl] (Cluster-Heartbeat-1:) We are good, no orphan management server msid in host table is found

INFO [cloud.cluster.ClusterManagerImpl] (Cluster-Heartbeat-1:) No inactive management server node found

WARN [cloud.cluster.ClusterManagerImpl] (Cluster-Notification-1:) Notifying management server join event took 12 ms

上記の3つ目のコマンドを打つと、event took 〜 msで表示がとまります。

この状態がCloudStackの起動している状態となります。

※停止するときはCtrl + Cを実行してください。

早速、起動確認をしてみます。

ローカルのブラウザで http://192.168.56.10:8080/client/ にアクセスすると、CloudStackのログイン画面が表示されます。

ログイン画面が表示されました。正しく起動しています。

見事に文字化けしていますね…

(ここの対策は次の記事に掲載します。)

現段階では、一番下のプルダウンの一番を上を選択すると英語で表示できるので、それで対処します。

次に、下記のユーザでログインします。

  • ユーザ名:admin
  • パスワード:password
  • ドメイン:空白

Loginボタンを押します。

 

 

 

 

 

無事にログインできました。

 

 

 

 

 

 

 

これで無事にCloudStackの環境ができました。

あとは、煮るなり焼くなり好きにできます。

 

終わりに

今回はDevCloud2を構築しましたが、予想以上に楽に構築できました。

CloudStack環境を触るための敷居が下がったり、環境がおかしくなっても復元しやすかったりと、素敵だなと思いました。

また、おまけ程度に次回記事でCloudStackの文字化け問題を解決したいと思います。(根本解決ではないような気がしますが…)

ここまで読んでいただきありがとうございました。

No Comments »

CloudStack SecurityGroupのはなし

December 26, 2012 | by | cloudstack

こんにちは、 @takaidohigasi です。

本エントリは、CloudStack Advent Calanderの26日目の記事となります。クリスマスまでに25のtipsを、、、ということでしたが、 @kkitase さんに、無理を聞いていただきました。

少し記事が長めですので、目次をざっと目を通していただいてから、
本記事のスコープ -> まとめ -> (もの足りない人) -> SecurityGroupの機能・・・と読み進めていただければと思います。

本記事を読むのにかかる時間 ○ 分

本記事のスコープ

本エントリは、主に、Domain Admin / Domain Userの権限で開発をされる方向けとなります。
また、本エントリの対象であるSecurityGroupの機能は、AWSのEC2を想定したものと考えられ、
提供されるのはCloudStackの中でも一部の構成を取った際のみとなりますのでご注意ください。

ネットワーク構成の分類と、SecurityGroupの位置づけについては、@star76popin さんの
OSC2012のSlide 29, 30に分かりやすく解説されておりますので、合わせてご参照ください。

本来はCloudStack3.0.xおよび、4.0.xを、対象バージョンとしたかったのですが、ローカルのdevcloudの4.0.x環境の構築が間に合わなかったので、今回は、3.0.xにスコープを絞ってご紹介します。本記事が好評であれば、4.0.xでの機能差分の調査についても、追加でご紹介しようと思います。

3.0.xでは、Basic Zone / Shared NetworkにてSecurityGroup機能が利用でき、APIでは、
・ZoneのnetworktypeがBasic (listZonesで確認可能)
・NetworkのNetworkOfferingのguestiptypeがShared (listNetworkOfferingsで確認可能)
によって確認可能です。

Security Group機能について

概要

SecurityGroup機能の概要について、簡単にご説明します(間違ってたらゴメンナサイ)。

SecurityGroupは、仮想マシン(以下、VM)レベルで、L3レイヤでアクセス元などの制御をするものです。
複数のVMに対し、共通のSecurityルールを適用したり、Securityレベルを管理するといった用途に利用されると考えられます。

具体的には、
・あるdomain以下のSecurityGroupが不必要に危険な設定になっていないかを、管理者であるDomain Adminが確認する
・VMの利用目的に応じてSecurityポリシを定め、ポリシ毎にSecurityGroupを設定する
などの利用方法が考えられます。

CloudStack 3.xでは、Basic Zoneでは、VMがインターネットと直接通信するDirect Networkingとなっているため、このようなSecurityに関する機能が必要となります。

Direct Networkingについて

SecurityGroup機能の実装

ingress / egressについて

SecurityGroupでは、基本的に、allowの条件を足していく仕組みとなっています(ruleをauthorizeする、と呼びます)。
CloudStackのSecurityGroupではingress / egress両者に対し、設定を行うことが出来ます。

両者に関しては、初期状態の挙動が異なりますので注意が必要です。
ingressはdeny allとなっているのに対し、egressはallow allとなっています。
また、egressに対しては、ルールを追加すると追加したルール意外はdenyとなるのでegressのruleを最初にauthorizeする際に注意が必要です。
ポリシは異なりますが、合理的な初期状態の設定となっています。

機能実現方法について

Hostのiptablesの設定について実装されているようです。
ソースコードを確認しようと思いましたが、力尽きました。。。
実装部分ご存知の方いらっしゃいましたら、ご案内ください。

データ構造について : VM – SecurityGroup – rule

SecurityGroupはCIDRなどから構成されるruleを持ち、VMはSecurityGroupを持ちます。
VMとSecurityGroupの対応関係は、多対多の構造です。

内容の繰返しになりますが、多対多の構造は下記を意味します。

・ 1VMが複数SecurityGroupを持つことが出来る
・ 1つのSecurityGroupを複数のVMで共用することが出来る

本構造に関しては、下記3テーブルの定義を確認すると理解の助けとなります。

・security_group

description of security_group table

description of security_group table


・security_group_rule
description of security_group_rule table

description of security_group_rule table


・security_group_vm_map
description of security_group_vm_map table

description of security_group_vm_map table

マッピングを制御するテーブルを独立に持つ合理的な構造です。

CIDRをauthorizeする際には、allowd_ip_cidrが、アカウント/SecurityGroupをauthorizeする際には、allowd_network_idが挿入されます(security_group_rule)
本対応関係と、現状のCloudStackの実装の制約上、初期にVMをdeployする際にVMに指定するSecurityGroupの設定が、非常に大切になります。本点に関しては、後程「CloudStackの実装上の制約」にて言及したいと思います。

APIの使い方

SecurityGroup関連のAPIの使い方について、いくつか具体的にご紹介します。
最初に下記の各APIの個別の利用のポイントや、リクエスト発行方法をご紹介し、最後に運用観点で一般的にどのような順番で利用すると良さそうか、についてまとめたいと思います。

以下、 @_bhaisaab さんが開発された、cliツールのcloudmonkeyを使って結果を確認します。
本ツールに関しては、advent calender 2日目に @u1 さんが紹介してしていただいております。
※ authorizeSecurityGroupIngress等に出てくる、usersecuritygrouplistパラメータを含んだリクエストは、入力に”[","]“が含まれており、kick_api.shではURLエンコード・signatureまわりでうまくリクエストが発行出来ないのでご注意ください。

☆ 対象API
deployVirtualMachine
createSecurityGroup
deleteSecurityGroup
authorizeSecurityGroupIngress
revokeSecurityGroupIngress

deployVirtualMachine

SecurityGroup周りを確認します。
Required noの2パラメータが入力可能です。

ポイント
・複数のSecurityGroupが設定出来る
・ID(securitygroupids)または、名前(securitygroupnames)のどちらかを入力する
※ nameの方が制約がゆるいので、IDで指定した方が確実
・Basic Networkのみサポート
・SecurityGroupを指定しない場合は、ユーザ毎に作成されるdefaultのSecurityGroupとmappingされる

API document引用
securitygroupids
comma separated list of security groups id that going to be applied to the virtual machine. Should be passed only when vm is created from a zone with Basic Network support. Mutually exclusive with securitygroupnames

securitygroupnames
comma separated list of security groups names that going to be applied to the virtual machine. Should be passed only when vm is created from a zone with Basic Network support. Mutually exclusive with securitygroupids

createSecurityGroup

deployVirtualMachineをする時にVMにmappingする為の枠を作るAPIです。
使い方は迷うことないと思います。

deleteSecurityGroup

SecurityGroupを削除する為のAPIです。VMとmappingされたSecurityGroupは削除出来ません。
名前かIDを指定するのが通常の利用方法で、IDはGUIから取ってくるか、listSecurityGroupsにて取得します。
本APIも迷うことなく利用出来ると思います。

authorizeSecurityGroupIngress

Ingressのruleをauthorizeする非同期APIです。使い方が難しいです。
API requestのソースはこちらです。

cidrlistまたは、usersecuritygrouplistパラメータが必須であり、
機能としても、CIDRをauthorizeする場合、SecurityGroupをauthorizeする場合に分かれます。
イメージしやすいのがCIDRのauthorizeだと思いますので、まずは、CIDRのauthorizeのAPI発行について説明します。

A) CIDRのauthorize (cidrlist)

1. どのSecurityGroupにauthorizeするかを指定する為に、securitygroupid または securitygroupname を入力します
2. Protocolを指定します
portを指定した場合は、Protocolを指定しないとErrorとなります。
portを指定しない場合はProtocol指定なしでもOKで、その場合はprotocol=allでDBに格納されます。

devcloud> create securitygroup name=secg_test1
securitygroup:
=============
account = takaido-DA
domainid = 103c3c19-7d69-4b3c-a661-732211d8e0c5
id = aefed395-34fb-43d7-81ab-bd5f90f4d6a9
domain = test
name = secg_test1

devcloud> authorize securitygroupingress securitygroupname=secg_test1 startport=22 endport=22  cidrlist=0.0.0.0/0
Async query failed for jobid= 6e3ff1dd-5b14-408f-982c-27b6ebd7d720 
Error 431 Cannot specify startPort or endPort without specifying protocol

3. start_port / end_portを指定します
4. cidrlistを指定します

devcloud> authorize securitygroupingress securitygroupname=secg_test1 startport=22 endport=22  cidrlist=0.0.0.0/0 protocol=TCP
Error on parsing and printing 'authorizesecuritygroupingressresponse'

なんだかresponseのparseにこけてしました。asyncjobのresponseがうまくparse出来てない模様です。
listSecurityGroup APIにて結果を確認します。先程のauthorizeが実施できていることが確認出来ます

devcloud> list securitygroups
count = 2
securitygroup:
=============
account = takaido-DA
domainid = 103c3c19-7d69-4b3c-a661-732211d8e0c5
description = Default Security Group
domain = test
id = 23f1509c-6349-457b-88ff-bbc94296c6b0
name = default
================================================================================
egressrule:
==========
account = takaido-DA
domainid = 103c3c19-7d69-4b3c-a661-732211d8e0c5
name = secg_test1
domain = test
ingressrule:
===========
startport = 22
cidr = 0.0.0.0/0
protocol = tcp
endport = 22
ruleid = 0b318443-9439-4add-b263-7eae4e78a7e5
id = aefed395-34fb-43d7-81ab-bd5f90f4d6a9
================================================================================

一般的な使い方のauthorizeについて、ご紹介しました。
次は、SecurityGroupのauthorizeに関してご紹介します。
何をする為の機能か、どの様に使うのか、いづれも難しいAPIです。

B) SecurityGroupのauthorize (usersecuritygrouplist)

1. 何の為の機能か

AWS互換を狙っていると考えると、あるSecurityGroupにMappingしているHostからのアクセスを1つのルールでauthorizeする為のものであると考えられます。
EC2 AuthorizeSecurityGroupIngress API Document
例えば、DB Serverに対し、同一SecurityGroupがmappingされたVMをauthorizeする場合を考えてみましょう。

Advanced Zoneでは、本考慮は特に意識する必要がありませんが、Basic ZoneでVMを構築した場合に、
SecurityGroupに属するVMの台数分のCIDRをauthorizeする必要があります。

ここでで登場するのがusersecuritygrouplistで、ruleが簡易に記述でき、本来的には非常に有効な機能です。
ただし、EC2ではアカウントまたぎのauthorizeが可能であるのに対し、CloudStackではdomainまたぎのauthorizeは出来ません。
したがって現状では、効果が感じにくい機能だと思われます。

※ 図解した方が分かりやすいと思うので、後日、visualで理解出来る図をuploadします。時間の制約上、手が回りませんでした。

2. 使い方について

明日後日、改めてご紹介します。
(第2部へつづく、、、)

1 Comment »

BOSH – CloudStackとCloud Foundryを繋ぐ架け橋

December 18, 2012 | by | cloudfoundry, cloudstack

どうも、jacoです。ここでは半年ぶりくらいに書く気がします。

今回はCloudStack Advent Calendar jp: 2012に勢いで参加してしまったので、12/18担当として書かせてもらいます。

そういえば去年の今頃は、Cloud Foundry jp Advent Calendarに参加していましたね。

ということで、Cloud FoundryとCloudStackを絡めた内容にしたいと思います。

Cloud FoundryをCloudStackで動かすには?

Cloud Foundryとは何ぞやという話は、このBlogの過去の記事を参照してもらうとして。

Cloud Foundryの特徴の一つとして、「IaaSレイヤーには依存しない」という設計思想が挙げられます。
そう、Cloud FoundryはIaaSは何でも良いのです。当然、CloudStack上でも動くはずですし、実際に商用として動かしています
その他AWSでもvSphereでもOpenStackでも実機でも動くでしょう。

以上!

・・・なんて終わらせてしまうと、AdventCalendar参加者からタコ殴りにされそう。
それでは、IaaSレイヤーに非依存ということは、逆に何が起こりうるか考えてみましょうか。

Cloud Foundryのデプロイの話

Cloud Foundryには、旧来からあるセットアップ方法としてdev_setupというものが用意されています。
これはchef-soloを用いたインストーラーで、必要なリポジトリをローカルにcloneした後、どのコンポーネントをどういう設定で構築するかを記述したymlファイルを食わせてやることで、Cloud Foundryが展開されます。

このあたりの話については、この記事が分かりやすいでしょう。
Cloud Foundryを複数ホストで動かした。その2 dev_setupを使う編

なので、1からCloud Foundryを構築していくには、以下の作業を行っていく必要があるわけですね。

1.VMを作成する
2.VMに最低限必要なものをセットアップする(gitとかzipとかそんなの)
3.リポジトリをCloneしてくる
4.各ノードの役割ごとに設定ファイルを配布する
5.dev_setupを回す

Cloud Foundryを数台規模で組むのであれば、各マシンにリポジトリをcloneしてdev_setup回しても良いのですが、5台を超えたあたりからさすがに面倒になってきます。そこから先は、何らかの方法で自動化が必要でしょう。
VMのテンプレートを使えば、前半はいくらか楽できるかもしれませんが、後半はまた別の仕組みで自動化する必要があります。

IaaSのAPIを駆使してVMを自動で作成し、デプロイツールを使ってCloud Foundryのデプロイを自動化したとしても、難題はまだまだあります。

・リリースエンジニアリング上の問題。例えば、どのノードにどのバージョンのコンポーネントが入っているのかの管理が大変。最新版が入っているはずのノードが古いままだったとか、バージョンを上げたくないノードのバージョンを上げてしまったとか
・VMのテンプレートで楽しようとしても、PaaSのバージョン上がる度にVMテンプレートを作り直していては大変。
・そもそもCloud Foundryはコンポーネントの数も多いので、テンプレートの数も膨大に。
・そもそもIaaSとPaaSのデプロイツールが別々な時点でイケてない

数十台規模であればツールの組み合わせでなんとかなりますが、それ以上を目指すのであれば、上記の課題をクリアしていかなければいけません。

この、リリースエンジニアリングデプロイライフサイクルマネジメントを行っていくためのツールが、BOSHです。

BOSHの話

BOSHは、VMWareがCloud Foundryと共に開発しているオープンソースのツールチェーンです。そういえば、今後Cloud FoundryやBOSHはVMWareではなく、EMC傘下のPivotal Initiativeに移管されるようですね。

ちなみにCloudFoundry.comは、数百台規模のVMを、このBOSHを使って運用しているそう。

githubのリポジトリは https://github.com/cloudfoundry/bosh です。

BOSH のコンポーネントはこのようになっています。

https://github.com/cloudfoundry/oss-docs/blob/master/bosh/documentation/bosh_components.mdより引用。

BOSHのコアにはBOSH Directorというコンポーネントがいて、それがVMの管理を行っています。
各VMの構成情報はDBで管理されており、Cloud Foundryのような分散システムもまとめて管理することができます。
ソースコードやVMのテンプレート(Stemcellと呼ぶ)は、Blobstoreに収納されています。BlobstoreにはS3やEMCのAtmos、それとBOSHが提供するsimple_blobstore_serverを利用可能です。

IaaSレイヤーはBOSH DirectorがCPI(Cloud Provider Interface)と呼ばれるプラグインを経由して、操作を行います。
現状BOSHにはvSphereとAWS向けのCPIが用意されています。プラグイン形式なので、CloudStack APIに対応することも仕組み上は可能です。ただ、CloudStackのAWS互換APIを使えば、それほど積極的にCloudStack CPIを開発する必要性は無さそうです。

ではさっそく、CloudStackにBOSH環境を構築していきましょう・・・ と行きたいところだったのですが、時間的な都合でまだ上手く動かせていません(´;ω;`)
今後数回にわたって、CloudStack+BOSHの記事を上げていきたいと思います。

それと、BOSHについてはyudaiさんのスライドがとても分かりやすいので、参考にしてください。

それでは!

1 Comment »

Cloudstack 4.0 VPC

December 8, 2012 | by | cloudstack

CloudStack Advent Calendar 2013 12/8

はじめて投稿します。

CloudStack Advent calendarに参加しつつ、CloudstackのNetwork modeについてまとめたいと思います。

Cloudstack 4.0から(?) VPC機能が実装されています。

今回はCloudstackのNetworkについてまとめながら、VPCの機能についても書きたいと思います。

  1. CloudstackのZoneとNetwork modeについて
  2. VPC Networkについて
  3. まとめ

 

1. CloudstackのZoneとNetwork modeについて

ZoneとNetworkの話は非常に分かりづらい上にマニュアル上でも明確に説明されていないため、最初に定義をしっかりさせておきます。

Cloudstackでは2種類のZoneが存在します。

  • Basic Zone
  • Advance Zone

Network modeは3種類存在するとします。
それぞれのNetwork mode毎にネットワークアーキテクチャが異なっており、又、VirtualRouter(以降VR)というCloudStackが自動Deployするサーバーが使える機能が異なってきます。
これによって、多様なネットワークの構成を事業者が組み、エンドユーザーにサービスを提供することが出来ます。

  • Shared Network
    VRの機能:DHCP, DNS, User Data
    VLAN: Shared Network毎に1つアサイン。ROOTで指定可能。
    その他:Default Router, FW, PF, NAT,LB,VPNの機能は利用者側が用意する。 一部機能はCloudstackと連携するHWを用いて連携可能。使用可能なアカウントはROOT Adminが決めれる。
  • Isolated Network
    VRの機能:DHCP,DNS, User Data, Default Router, FW, PF, NAT,LB,VPN
    VLAN: Isolated Network毎に1つ。Cloudstackが勝手にアサイン
    その他:VLAN内で払いだされるIPアドレスはCloudstackから払い出し
  • VPC Network
    VPC VRの機能:DHCP, DNS, User Data, Default Router, FW, PF, NAT, LB,VPN
    VLAN:VPC毎に複数アサイン可能。Cloudstackが指定。
    その他:VLAN内で払いだされるIPアドレスはユーザ指定

(VPC Networkは勝手に名付けました、ごめんなさい。)

Basic Zoneが持つことができるNetwork modeはShared Networkのみであり、Shared Networkを1つ使用することができる。(SharedNetworkを使ってるという事は事業者も意識する事は無いですが、設計上はSharedNetworkという位置づけになっています)

Advance Zoneが持つことができるNetwork modeはIsolated, Shared、VPCであり、このZone上のVMは複数のNICを持つ事ができ、NIC毎にNetwork modeを使用した色々な組み合わせが可能です。

例). (※VPC Networkは単独使用のみ)

  • Isolated Network + Shared Network
  • Shared Network + Shared Network
  • Isolated Network + Isolated Network + Shared Network

2. VPC Networkについて

では、Cloudstack 4.0のVPCを動かしたいと思います。

環境は以下の構成で組んでいます。
- Cloudstack 4.0.0
- CentOS 6.3 minimal
- KVM

1. VPCの作成

左のメニューの[ネットワーク]→中央左上のプルダウンメニューから[VPC]を選択→右上の[VPCの追加]

 

Advance Zoneを選択し、使用したいPrivate IPアドレスを登録。

作成完了。

2. Tierの作成

Amazon VPCでいうところのSubnet。Tier毎にVLANとIPアドレス帯が異なる。

VPC listの右の列の「構成」をクリックすると、初回はTier作成の画面となる。

VPC作成時に制定したPrivate IPアドレス帯から使用したいIPアドレス帯を指定。

「新しい階層の追加」を選択することで、Tierを増やすことができる。(Defualtは3つまで)

VPCの機能として以下の機能がGUIから設定可能
- IP アドレス (Source NAT, Static NAT, FW, PF, LBの設定)
- プライベートゲートウェイ (L2でVLANを出す設定)
- サイト間VPN(VPN GWの設定)
- ネットワークACL(FWの設定)

VMのDeployはTierにある「VMの追加」 もしくは メニューのインスタンスからVMを作成し、ネットワークの選択時にVPCを指定する。

 

3. Networkの設定

Tierの画面より左上のIP アドレス を選択して、設定が可能
- IPアドレスの取得
- Static NAT
- FW
- LB
- PF

1-3で、VPCを作成し、Subnetを用意し、そこにVMを作成し、FW,LB,NATなどの設定が可能となります。

本当はここから機能を1つずつ確認していきたかったのですが、cloudstack環境に接続できなくなってしまったので、すべての機能の確認はできません。。。

週明けにでも確認してアップデートしときます。。

3. まとめ

Cloudstack4.0(KVM)で動作を確認したもの

  • VPCの作成
  • Tierの作成
  • Source NAT
  • 異なるTier間の通信 (Inter-VLAN通信)
  • Port forwarding
  • Network ACL
  • VPC VRのHA機能

未確認の機能

  • VPN機能
  • LoadBalancer -  動かないはず…

Cloudstack 4.0(KVM)では以下の機能が正常に動作しません。

  • Static NAT – 設定するとVPC VRから色々なNICが消えて通信不可能になる
  • VPC作成 – 時々、VPC VRのpublic network側のNICが作成されない
  • VM作成 – VPCを作成した後の、最初のdeployは必ず失敗する

Cloudstack 4.0.1ではBug fixが入るため、上記のものは解決する見込みですが、安定したVPC機能はまだ少し時間がかかりそうです。

 

今後以下の機能が欲しいなと個人的に思います。

  • Shared、Isolatedのような複数Networkのアタッチ
  • Security Group
  • Shared、IsolatedのVRでは達成出来ている冗長化
  • VPNのBGPによるルーティング

今回はここまでとさせていただきます。

1 Comment »

CloudStack を参考に、 Fog を眺めてみる

December 4, 2012 | by | cloudstack

CloudStack Advent Calender 12/3

読了時間: 多分5~6分くらい

 

間が空き過ぎてアレな感じですが勢いで CloudStack Advent Calender に手をあげてしまったので、書き殴っておきます。 ※別に Cloudstack  に詳しくも何ともありません。

 

Fog とは、最近流行りの「クラウドサービス」や、その基盤として利用されているパッケージのAPIを、Rubyから気軽に利用できるライブラリ群です。その適用範囲は非常に多岐に渡り、今回の記事の対象となる CloudStack は元より、Amazon Web Services の EC2 や S3 、 joyent 、 Rackspace 、 VMware vSphere 、 Xen Server など、様々なパッケージに対応しています。

 

Fog のソースコードは以下にあります。

https://github.com/fog/fog

 

早速ですが、Fog を使いながらそのコードを追う事で、何となく Fog を理解した気になってみましょう。今回は対象となる CloudStack、Rubyやbundlerなど基本的な環境は揃っている物とします。 (Ruby1.9.3、bundlerがあればとりあえず動きます)

 

今回やる事は以下の通りです。

 

  1. 環境の準備
  2. サンプルコードの作成と、インタフェースの理解
  3. ソースコードの流し読み

 

1.環境の準備

 


 

mkdir fogtest

cd fogtest

bundle init

echo ' gem "fog","1.8.0" ' >> Gemfile

bundle install --path vendor/bundle

ls -al

 

 

これだけで周辺環境の整理は終わりです。後は FogのAPIを呼び出すためのコードを書けば終了です。シェルスクリプト臭い記述ですが気にせず Ruby コードを書きます。

 

2. サンプルコードの作成とインタフェースの理解

Rubyのサンプルコード list_service_info.rb

require 'rubygems'
require 'fog'
require 'pp'

ACCESS_KEY_ID='<アクセスキー>'
SECRET_ACCESS_KEY='<シークレットキー>'
END_POINT='<システムのエンドポイントURI>'

# create a compute connection
cloudstack_uri = URI.parse(END_POINT)

@compute = Fog::Compute.new(
:provider => 'CloudStack',
:cloudstack_api_key => ACCESS_KEY_ID,
:cloudstack_secret_access_key => SECRET_ACCESS_KEY,
:cloudstack_host => cloudstack_uri.host,
:cloudstack_port => cloudstack_uri.port,
:cloudstack_path => cloudstack_uri.path,
:cloudstack_scheme => cloudstack_uri.scheme,
)

# compute operations go here

pp @compute.list_zones
pp @compute.list_templates({'templateFilter' => 'executable'})
pp @compute.list_service_offerings

 

中核になるのは Fog::Compute.new であるのは一目瞭然ですね。

 

END_POINT は例えば以下のような値になります。自分の立てた CloudStackの環境に合わせてください。

 http://<your management server>:8080/client/api 

 

Cloudstack を立てるより外部サイトで試したいなら、Cloudn のアカウントを取得しておもちゃ代わりに使ってみるのもありです (ステマ)

END_POINT=’https://mycloud3.securesites.com/client/api’

 

では軽く叩いて動作を確かめましょう。


 

bundle exec ruby list_service_info.rb

 

 

ここで読み出した list_zones やliste_templates 、 list_service_offeringsに注目しましょう。これらは裏側で該当する CloudStack API を叩いてその基盤に用意されているゾーンやテンプレートの情報、インスタンスサイズの情報を読み出しています。この値を利用する事で、VMの作成に必要な情報を取得する事が出来ます

 

これらの返り値は例えば以下のような形式です。

返り値のサンプル (list_templates)


 

{"listtemplatesresponse"=>
{"count"=>1,
"template"=>
[{"id"=>"**********************",
"name"=>"Hoge VM,
"displaytext"=>"Hoge VM for User",
"ispublic"=>false,
"created"=>"2012-08-21T17:57:06+0900",
"isready"=>true,
"passwordenabled"=>true,
"format"=>"QCOW2",
"isfeatured"=>false,
"crossZones"=>false,
"ostypeid"=>"Fuga",
"ostypename"=>"Fuga64bit",
"account"=>"SampleUser",
"zoneid"=>"Foo",
"zonename"=>"Bar",
"status"=>"Download Complete",
"size"=>XXXXXXXXX,
"templatetype"=>"USER",
"hypervisor"=>"KVM",
"domain"=>"SampleDomain",
"domainid"=>"XXXXXXXXXXXXXXXX",
"isextractable"=>true,
"checksum"=>"XXXXXXXXXXXXXXXX"}]}}

 

 

template がどのような情報を持っているのか、簡単に分かりますね。

 

 

では、受け取った情報を元に、VMを作成してみます。

 

Rubyのサンプルコード deploy_vm.rb


 

require 'rubygems'
require 'fog'
require 'pp'

ACCESS_KEY_ID='<アクセスキー>'
SECRET_ACCESS_KEY='<シークレットキー>'
END_POINT='<システムのエンドポイントURI>'

# create a compute connection
cloudstack_uri = URI.parse(END_POINT)

@compute = Fog::Compute.new(
:provider => 'CloudStack',
:cloudstack_api_key => ACCESS_KEY_ID,
:cloudstack_secret_access_key => SECRET_ACCESS_KEY,
:cloudstack_host => cloudstack_uri.host,
:cloudstack_port => cloudstack_uri.port,
:cloudstack_path => cloudstack_uri.path,
:cloudstack_scheme => cloudstack_uri.scheme,
)

# compute operations go here

pp @compute.deploy_virtual_machine({
'name' => 'fogtestvm',
'serviceOfferingId' => '<インスタンスサイズ>',
'templateId' => 'テンプレートID',
'zoneId' => 'ゾーンID',
})
pp @compute.list_virtual_machines

 

 

<インスタンスサイズ>: list_service_offerings の response にある name を元に id を決める ※有償サービスを利用している場合は、お金が掛かるのでサイズの選択ミスに注意 
<テンプレートID>:list_templates の response にある templatename を元に templateid を決める
<ゾーンID>: list_zones の response にある zonename を元に zoneid を決める

 


 

bundle exec ruby deploy_vm.rb

 

 

list_virtual_machinesの結果を眺めると、 status 情報等も一緒に取れている事が分かります。deploy_virtual_machine の返り値を李ようしてVMを特定する事で、特定のVMのjobの状況などを追う事も出来ます。

 

3.ソースコードの流し読み

 

さて、基本は上記のようにせこせこと接続を作ってはAPIに各種命令を放り込めばいいんじゃないかなと言う感じですが、この辺Fogでは裏側がどうなっているのかソースコードを軽く追ってみます。

 


 

bundle exec gem env

 

 

の GEM PATHSの下に gems/fog-1.8.0/  がありますので、そちらに移動します。

 

 

最初に サンプルコードで require ‘fog’ を入力する事で、gemが走査対象に入ります。次にFog::Compute で newを呼び出すと、fog/compute.rb の Computeモジュールの new メソッドに各種設定情報を入れたハッシュを引数として渡します。この値は例えば 通信相手が AWS なのか Cloudstack なのかを特定する provider や、クラウドスタックのアクセスホストを示す cloudstack_host が該当します。

 

次に、 newで受け取ったオプションからprovider を元に呼び出すComputeサービス(今回の場合は Fog::Compute::Cloudstack)を特定し、関連ファイルを requireします。

 

lib/fog/compute.rb


8 def self.new(attributes)
9 attributes = attributes.dup # prevent delete from having side effects
10 provider = attributes.delete(:provider).to_s.downcase.to_sym
11
12 case provider
13 when :aws
14 require 'fog/aws/compute'

23 require 'fog/cloudstack/compute'
24 Fog::Compute::Cloudstack.new(attributes)

provider自身をdeleteメソッドで取り除いた残りのオプションを、Fog::Compute::CloudStackに引数で渡して CloudStack のオブジェクトを生成します。

 

 

Fog::Compute::CloudStack クラスは Fog:: Service ( lib/fog/core/service.rb )を継承しており、そちらで Option を評価したりした後  Cloudstackが呼び出す service::Realを指定しています。(この辺流し読みなのでちょっと合ってるか怪しい)

 

lib/fog/core/service.rb


55 def new(options={})
56 options = Fog.symbolize_credentials(options)
57 options = fetch_credentials(options).merge(options)
58 validate_options(options)
59 coerce_options(options)
60 setup_requirements
61
62 if Fog.mocking?
63 service::Mock.send(:include, service::Collections)
64 service::Mock.new(options)
65 else
66 service::Real.send(:include, service::Collections)
67 service::Real.send(:include, service::NoLeakInspector)
68 service::Real.new(options)

 

直接呼び出された lib/fog/cloudstack/compute.rb に戻って initialize コンストラクタを見ると、ここでようやく受け取ったオプションから connection を生成している事が分かります。

 

lib/fog/cloudstack/compute.rb


136 class Real
137
138 def initialize(options={})
139 @cloudstack_api_key = options[:cloudstack_api_key]
140 @cloudstack_secret_access_key = options[:cloudstack_secret_access_key]
141 @cloudstack_session_id = options[:cloudstack_session_id]
142 @cloudstack_session_key = options[:cloudstack_session_key]
143 @host = options[:cloudstack_host]
144 @path = options[:cloudstack_path] || '/client/api'
145 @port = options[:cloudstack_port] || 443
146 @scheme = options[:cloudstack_scheme] || 'https'
147 @connection = Fog::Connection.new("#{@scheme}://#{@host}:#{@port}#{@path}", options[:cloudstack_persistent], {:ssl_verify_peer => false})
148 end

 

この実態は呼び出し先の connection を見れば分かる通り、 excon (EXtended http(s) CONnections)

の gem です。

 

lib/fog/core/connection.rb


4 def initialize(url, persistent=false, params={})
5 Excon.defaults[:headers]['User-Agent'] ||= "fog/#{Fog::VERSION}"
6 @excon = Excon.new(url, params)

 


 

bundle exec gem list

 

 

ノリで始めて適当に見ているので、読み間違いがあったらアレな感じですが、大体こんな感じでサービスの選択がされているようです。ちょっと長くなってきたので、今回はここまでにします。

1 Comment »

CloudStack cloudmonkeyを使ってのAPI操作

December 2, 2012 | by | cloudstack

本記事はCloudStack AdventCalender2012の2日目(12/02)の記事になります。

cloudmonkey概要

cloudstack4.0のテスト用ツールとして作られていたcloudmonkeyが公開されました。
このツールを利用することで、CloudStackをAPIで操作する際にCLIでコマンド補完がされたり、色づけされるため、非常に楽にAPIを使っての作業を行う事が出来ます。
本記事で利用方法を紹介します。
ちなみにcwiki上の本家cwikiのcloudmonkeyの記事の方がより詳しいです。
本記事はあくまで入門です。

目次

  • 1. インストール手順
  • 2. 初期設定
  • 3. 使い方(対話式)
  • 4. 使い方(非対話型)
  • 5. cloudmonkeyを使っての操作例
    • 5-1. CloudStackのevnetログを見る
  • 6. 現在、足りてない機能
  • 7. 参考

1. インストール手順

ubuntu12.04での入れ方です。
pip(Python Package Index)を入れて、pip経由でcloudmonkeyを入れれば動作します。

$ sudo apt-get install python-pip -y
$ sudo pip install cloudmonkey

2. 初期設定

cloudstack apiを利用するための設定を行います。
インストールした後にcloudmonkeyコマンドを実行し対話式コンソールを起動すると、初期コンフィグが自動生成されます。

$ cloudmonkey
☁ Apache CloudStack  cloudmonkey 4.0.0. Type help or ? to list commands.

 cloudmonkey> exit
Bye!
$ cat ~/.cloudmonkey_config
[CLI]
protocol = http
asyncblock = true
color = true
prompt =  cloudmonkey>
history_file = /home/u1/.cloudmonkey_history
host = localhost
path = /client/api
port = 8080
apikey = 
secretkey = 
timeout = 3600
log_file = /home/u1/.cloudmonkey_log

上記の~/.cloudmonkey_configを直接編集しても利用可能ですが、対話式のcloudmonkeyコンソール上からsetコマンドで設定することも可能です。
以下は国内でCloudStackでPublic Cloudを提供してる2事業者の設定例です。

Cloudn日本リージョン

 cloudmonkey> set host mycloud3.securesites.com 
 cloudmonkey> set path /client/api
 cloudmonkey> set protocol https
 cloudmonkey> set port 443
 cloudmonkey> set apikey apiキーを入力
 cloudmonkey> set secretkey secretキーを入力

IDCFクラウドサービス(noahcloud.jp)

 cloudmonkey> set host api.noahcloud.jp
 cloudmonkey> set path /portal/client/api
 cloudmonkey> set protocol https
 cloudmonkey> set port 443
 cloudmonkey> set apikey apiキーを入力
 cloudmonkey> set secretkey secretキーを入力

正常に設定が出来ている場合は以下のコマンドを実行した際にレスポンスがあります。
host名やapikeyが間違ってる場合にはエラーが返ってきますので入力値があってるか確認しましょう。

 cloudmonkey> list accounts | grep username
username = ログイン名

# apiキーが間違ってる場合は以下
 cloudmonkey> list accounts
HTTP Error 401: Unauthorized

3. 使い方(対話式)

cloudmonkeyの対話式コンソールの使い方です。
対話式コンソールの強みは大きく2つあります。
コマンドの自動補完と専用の実行ログ(~/.cloudmonkey_history)管理によるコマンド実行履歴の追いやすさです。

自動補完の使い方ですが、実際の利用例で説明します。
以下の実行ログで[[tab]]で入力してある部分がtabキーを実行した部分です。
tabキーを押すことで、必要な入力の値がサジェストされる形になってます。
基本的にはtabキーを押していけば、だいたいやりたいことにたどり着けます。

 cloudmonkey> [[tab]]
EOF        assign     cancel     create     detach     extract    ldap       prepare    reconnect  restart    shell      update
activate   associate  change     delete     disable    generate   list       query      register   restore    start      upload
add        attach     configure  deploy     enable     get        mark       quit       remove     revoke     stop       
api        authorize  copy       destroy    exit       help       migrate    reboot     reset      set        suspend   

 cloudmonkey> list  [[tab]]
accounts                   eventtypes                 networkserviceproviders    securitygroups             traffictypes
alerts                     firewallrules              niciranvpdevicenetworks    serviceofferings           usagerecords
asyncjobs                  hosts                      niciranvpdevices           snapshotpolicies           usagetypes
autoscalepolicies          hypervisorcapabilities     oscategories               snapshots                  users
autoscalevmgroups          hypervisors                ostypes                    sshkeypairs                virtualmachines
autoscalevmprofiles        instancegroups             physicalnetworks           staticroutes               virtualrouterelements
capabilities               ipforwardingrules          pods                       storagenetworkiprange      vlanipranges
capacity                   isopermissions             portforwardingrules        storagepools               volumes
clusters                   isos                       privategateways            supportednetworkservices   vpcofferings
conditions                 lbstickinesspolicies       projectaccounts            swifts                     vpcs
configurations             loadbalancerruleinstances  projectinvitations         systemvms                  vpnconnections
counters                   loadbalancerrules          projects                   tags                       vpncustomergateways
diskofferings              networkacls                publicipaddresses          templatepermissions        vpngateways
domainchildren             networkdevice              remoteaccessvpns           templates                  vpnusers
domains                    networkofferings           resourcelimits             trafficmonitors            zones
events                     networks                   routers                    traffictypeimplementors    

 cloudmonkey> list virtual [[tab]]
virtualmachines        virtualrouterelements  

 cloudmonkey> list virtualmachines  [[tab]]
 account=            groupid=            isAsync=            listall=            pagesize=           storageid=          zoneid=
details=            hostid=             isoid=              name=               podid=              tags=               
domainid=           hypervisor=         isrecursive=        networkid=          projectid=          templateid=         
forvirtualnetwork=  id=                 keyword=            page=               state=              vpcid=  
 
 cloudmonkey> list virtualmachines domainid=ドメインID

ちなみに仮想マシンの情報は以下のように見えます。カラーリングは癖があるので、慣れないと少々見づらいかも。。。

4. 使い方(非対話型)

対話式の他に通常のコマンドラインツールとして実行する事も出来ます。
用途としては、軽く情報を見たいとき(eventログを見る時等)やbashスクリプトでの自動化を行う時などが想定されます。
ただ、この際には対話型のモードとは違って、自動補完機能は動きません。
今後の開発の要件には上がってるみたいですが。。。(bashとzshは開発対象らしい)

$ cloudmonkey list virtualmachines id=7547368e-92fa-42c6-a6f6-111bb807f15c
count = 1
virtualmachine:
==============
domain = ROOT
〜〜〜〜

5. cloudmonkeyを使っての操作例

実際にcloudmonkeyを利用したapi操作例を載せていきます。

5-1. CloudStackのイベントログを見る

list eventsコマンドを利用する事でapikeyが紐付いているアカウントのCloudStackのイベントを取得出来ます。
pageとpagesizeを指定する事で、必要な分のログを見る事が出来ます。
ちなみに上記を指定しない場合、利用しているアカウントのログが全て出力されてしまうため、利用は注意してください。場合によっては量が多すぎコンソールが固まります。

$ cloudmonkey list events page=1 pagesize=1
count = 1
event:
=====
username = admin
account = admin
domainid = a40799f5-ff38-4766-bfe5-bea54aec06f1
description = Successfully completed creating network. Network Id: 291
level = INFO
created = 2012-11-29T03:01:08+0000
domain = ROOT
state = Completed
parentid = 0
type = NETWORK.CREATE
id = 00561803-54ed-4b79-a95c-41f3557971cd

6. cloudmonkeyで現在、足りてない機能

以下の機能は2012/12/02現在、まだありません。
後もう一歩!

  • 非対話型実行時のコマンド補完機能
  • 必須パラメーターの入力例のサジェスト機能
    • これが無いと、apiドキュメントが必要なケースが出てきます。例えばlist templatesを実行した際に必須パラメーターとしてtemplatefilterがあるのですが入力値が固定なためドキュメント見ないと分かりません。
  • Unicodeサポート
    • 日本語文字列などがapiのレスポンスに存在している場合、正常にパースが出来ずにcloudmonkeyが落ちる場合があります。

7. 参考リンク

1 Comment »

OpenShiftの価格が発表されました

June 28, 2012 | by | openshift

cloudfoundry.comの料金発表が近いうちにあるという噂がありますが、先手を取って(?)OpenShiftが料金を発表しました。

Red Hat’s OpenShift PaaS to Offer Enterprise-Grade Support for Developers to Build the World’s Next Innovative Applications
http://nl.redhat.com/about/news/press-archive/2012/6/red-hats-openshift-paas-to-offer-enterprise-grade-support-for-developers-to-build-innovative-applications

他の多くのPaaSと同じく、無料プランと有料プランが用意されます。
無料プランはFreeShift、有料プランはMegaShiftという名前がつくようですね。

まずFreeShiftは3(small)Gearまで利用可能です。これにはオートスケール機能も含まれます。また、コミュニティによるサポート(サポートフォーラム的なものですかね)の利用も可能。既存のOpenShift ベータユーザーは自動的にFreeShiftに移行されます。

有料のMegaShiftは16Gearまで利用可能です。なお、最初の3Gearは課金外とのこと。そして各Gearに1GBのストレージがつきます。あとRedHatによるサポート付き。
これらトータルで月額$42のようです。

こういうサービスではノードの数に応じてリニアに値段が変わるパターンが多いので、決め打ちで$42という価格体系は意外ですねー。

1 Comment »