2012/09/27 #ssmjp おうちOpenStack

おうちOpenStack20120927 ssmjp

th0x0472

お約束twitter th0x0472

blog httpth0x0472atwebryinfo

自宅にOpenStack環境を構築中(現在進行形)

そのとき調べたこととか考えたことをシェアしますよ

ゆるゆるですお手柔らかにお願いします

OpenStackって何

オープンソースで開発されてるクラウド(構築andor管理)ソフトウェア

本家から引用ldquoOpenStack is a cloud operating system that controls large pools of compute storage and networking resourcesrdquo

お約束の情報源本家WikiとかDocumentとかhttpwwwopenstackorgBlueprintとかhttpslaunchpadnetopenstack日本OpenStackユーザ会httpopenstackjpあとコードはGitHubhttpsgithubcomopenstack

クラウド

クラウドって一言で言ってもイロイロあるよね

ありますね

NISTによる定義もうあちこちで引用されまくってるけどService model

Software as a Service (SaaS)Platform as a Service (PaaS)Infrastructure as a Service (IaaS)

Deployment modelPrivate CloudPUblic Cloud

httpcsrcnistgovpublicationsnistpubs800-145SP800-145pdf

日本語版もある

英語は勘弁してという僕みたいなへなちょこのために

IPAが日本語版を用意してくれてます

httpwwwipagojpsecurityfy23reportstech1-tga_07html

でOpenStackはどれService model は IaaSですね

Deployment model は特に縛りはないけどそのままではPublicは厳しそう素だと課金できないからね

でもHPのCloudはOpenStackだそうです中の人超がんばったに違いない

コトの始まりをNASAが作っていたnovaRackSpaceが作っていたswiftが元になっています

nova - 仮想マシンを提供してくれます

swift - 分散オブジェクトストレージを提供してくれます

OpenStackとしての開発は2010年7月開始らしい

AWSに当てはめると

ぶっちゃけ過ぎですが

役割的には

nova = EC2

swift = S3

ってことでいいと思う

今あるプロジェクトnova - 仮想マシン担当

horizon - Webユーザインターフェイス担当

glance - OSイメージ管理担当

keystone - 認証担当

swift - 分散オブジェクトストレージ担当

まだまだ増えるよ

Quantam - SDN担当

Cinder - ブロックデバイス担当

この2つは新リリースから

新リリース

Folsomといいます

今晩か明日リリースらしい太平洋標準時 20120927らしい

リリースサイクル今は春と秋年2回半年ごとにリリースするポリシーらしい

20121 とか 20122 とか ltリリース年gtltNogt

でもコードネームで呼ばれることが圧倒的におおい

歴代リリースAustin (201010)Bexar (20112)Cactus (20114)Diablo (20119)Essex (20124) lt- ウチは今コレ

Folsom (20129) lt- 次はコレ

Grizzly (2013春)

コードネーム

リリースのコードネームは地名を投票で選んでつけるそうです

Folsomは画像検索するとスゴイらしい（先日のユーザ会の方の発表OSC TokyoFallで知りました）

コードネーム万歳nova とかもコードネームですよ

nova = OpenStack Computehorizon = OpenStack Dashboardglance = OpenStack Imagekeystone = OpenStack Identityswift = OpenStack Object StorageCinderとQuantamはどうなるんだろ

プロセスはこんなかんじ$ ps aux | grep nov[a] | grep python

nova ～(中略)～ usrbinpython usrbinnova-cert --flagfile=etcnovanovaconf

nova ～(中略)～ usrbinpython usrbinnova-network --flagfile=etcnovanovaconf

nova ～(中略)～ usrbinpython usrbinnova-compute --flagfile=etcnovanovaconf --flagfile=etcnovanova-computeconf

nova ～(中略)～ usrbinpython usrbinnova-api --flagfile=etcnovanovaconf

nova ～(中略)～ usrbinpython usrbinnova-objectstore --flagfile=etcnovanovaconf

nova ～(中略)～ usrbinpython usrbinnova-scheduler --flagfile=etcnovanovaconf

nova ～(中略)～ usrbinpython usrbinnova-console --flagfile=etcnovanovaconf

nova ～(中略)～ usrbinpython usrbinnova-consoleauth --flagfile=etcnovanovaconf

分かること

Pythonで動いてる

一口に nova といってもいろんなコンポーネントがある

いろんなnovaよく見るのはこのあたりnova-apinova-certnova-computenova-networknova-objectstorenova-schedulernova-volume

ほかにも

nova-console

nova-consoleauth

nova-vnc

で何が言いたいの

一言で「仮想マシン担当」っていってもイロイロあるんですよ

仮想マシンを動作させるホストを決定したり

仮想マシンに割り当てるIPアドレス用意したり

仮想マシンのディスク(ブロックデバイス)用意したり

仮想マシンのコンソールをWebUIに組み込んだり

肝心の仮想化は既存のハイパーバイザー使ってます

KVM - Kernel-based Virtual MachineLXC - Linux Containers (through libvirt)QEMU - Quick EMUlatorUML - User Mode LinuxVMWare ESXESXi 41 update 1Xen - Xen Citrix XenServer and Xen Cloud Platform (XCP)

つづきはWebで

詳しくはこのあたり参照で

httpdocsopenstackorgtrunkopenstack-computeadmincontenthypervisorshtml

FolsomでHyper-V 20082012 が復活するらしい

とはいえ

僕はKVMしか使ったことないです(自慢できることじゃない)

ハイパーバイザーによって機能差有りhttpwikiopenstackorgHypervisorSupportMatrix

KVMとXenが中心っぽい

で動いてるところ

VNCでコンソールもOK

蛇足だけどインスタンスのVNCの出力がWebUIに埋め込まれてるんだけどWebSocket使ってます

こんなかんじ[KVMVNC Server] -ltvncgt- [novnc] -ltWebSocketgt- [Web Browser]

Webブラウザ上の描画はHTML5のCanvasらしい

僕はHTML5分かりませんけどね

実際どうよマウスぽちぽちぼちぼちテキスト入力で仮想マシンをどんどん作れる

ネットワークとかあんまり考えなくてOK

（まぁ今できることは限られてるけど）（そのへんはQuantamに期待）

他にもイロイロ

WebUIお手軽です

でもタルイよね

そんなあなたにAPI

最近のクラウドってだいたいAPIもってる

というか猫も194780子も

当然OpenStackもAPIを持っています

こんな本も出ましたAmazon Web Servicesプログラミング

APIの基礎からElastic Beanstalkの利用まで天下のOrsquoREILLYさまから

yen3360-

2012年09月 発行 348ページISBN978-4-87311-581-8

買ってみましたでもまだ読んでいません

でもまだ読んでいません

大事なことなので二度言いました

僕のライフが尽きるので

さっさと結論にいこうと思います

APIを使うといろいろ便利（な予感）

便利ツールとか

便利アプライアンスとか

自分でAPIたたくコード書いたり

重要なのは

もちろん「 自分でAPIたたくコード書いたり」

自分でAPIたたいたり

他人が書いたAPIたたくコード読んだり

いろいろあるけど

コードに慣れることと

サーバ周りをAPIをたたいて操作するって感覚を身につける

この2つが大切かな～と個人的に思います

どっかで聞いたよね

というか先月のssmjpで

kawamucho 先生がNW方面からそんなお話してましたよね

はいたぶん同じことです

もっと振り返ると今年の初めにniftyさんがCROSSってイベントやりました

そこで気になったキーワード「プログラマブルなインフラ」

色々な領域のエンジニアがクロスするってのもあったと思うけどクロスと言うよりボーダレスだと思う

イロイロあるけど

おしまい

ご清聴ありがとうございました