SVX日記

2004|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|

2015-12-23(Wed) openstackはじめの一歩

  openstackの評価、なんてつもりはないのだが、自作のオートパイロット機構「kugutsu」のスクリプトを書いたり、走らせたりするのが楽しくなってしまい、しつこくFedora23とopenstackのインストールを繰り返してきた。んが、いいかげん、何かに活用していきたいので、一段落する意味も込めて、ひと通りの手順をまとめておくことにする。

  まず、OSのインストールはキックスタート。安物のUSBメモリから起動し、起動パラメータに「selinux=0inst.ks=http://server/anaconda-ks.cfg」を追記してウェブ経由でキックスタートファイルを渡す。

  OSのインストールが終わったら、再起動してデスクトップPCからopenstackインストール前の下準備。コントローラに「kugutsuprep_openstack_fed23.kgt troll」コンピュートノードに「kugutsuprep_openstack_fed23.kgt pute」を一撃ずつ、並行して実行させる。

  完了後、コントローラにsshでログインして「packstack--answer-file=answer_file」を一撃。

  完了後、再び、デスクトップPCからopenstackインストール後の処理。コントローラに「kugutsu prep_openstack_fed23.kgt troll -l 219-」を一撃。ブリッジの作成、glance のバックエンドの swift への変更、テナントの作成までが行われる。

  ここからは、openstackのウェブUIで初期設定を行う。やろうと思えば、この処理もkugutsuで実行可能だろうが、ウェブUIは普段の運用で使うものだし、理解のためにも手作業で行う。

  openstackのウェブUIであるDashboard(Horizon)は、コントローラ上のウェブサーバで提供される。具体的には、ブラウザで「http://troll0.itline.jp/dashboard/」にアクセスする。

  まずは、管理者であるadminでログイン、パスワードはコントローラの/root/keystonerc_adminに書いてある。

[root@troll0 ~]# cat keystonerc_admin | grep PASS

  画像の説明

  adminユーザで操作するときに注意が必要なのは、プロジェクト(テナント)利用者としての操作か、openstack管理者としての操作かを意識して区別する必要があるってことだ。前者の場合、左のペインの「プロジェクト」の中、後者の場合、左のペインの「管理」の中の操作となる。特に「ネットワーク」は両方にあるので、これに気づかないとドツボだ。

  一番にやるのは起動イメージのGlanceへの登録(ダウンロード)これは管理者として行うので「管理」の「イメージ」から「イメージの作成」を行う。「名前」は適当に「Fedora23」「イメージの場所」は「http://ftp.iij.ad.jp/pub/linux/fedora/releases/23/Cloud/x86_64/Images/Fedora-Cloud-Base-23-20151030.x86_64.qcow2」「形式」は「qcow2」「パブリック」と「保護」にチェックを入れる「イメージの作成」だ。当然ながら、ダウンロード完了までにはしばらく要する。

  画像の説明 画像の説明

  画像の説明 画像の説明

  画像の説明

  次にやるのはパブリックネットワークの登録。これも管理者として行うので「管理」の「ネットワーク」から「ネットワークの作成」を行う。「名前」は適当に「public」プロジェクトは「admin」プロバイダーネットワーク種別は「VXLAN」セグメントIDは「0」。「共有」と「外部ネットワーク」にチェックを入れる

  画像の説明 画像の説明

  ちなみに、プロバイダーネットワーク種別のVXLANは、packstackのanswer_fileでneutronに設定した以下のパラメータと一致させる必要があるっぽい。

CONFIG_NEUTRON_ML2_TYPE_DRIVERS=vxlan
CONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPES=vxlan

  ネットワーク名「public」をクリックして、ネットワークにサブネットの作成を行う。「サブネット名」は適当に「public_subnet」。「ネットワークアドレス」は物理マシンとして所属しているネットワークアドレスで「172.24.0.0/24」とか「192.168.0.0/24」など。「ゲートウェイIP」は大概ルータだろうから「172.24.0.1」とか「192.168.0.254」など。

  画像の説明 画像の説明

  「IPアドレス割り当てプール」はopenstackとして仮想マシンに付与するためのフローティングIPを割り当てる範囲なので、ルータのDHCPレンジを避ける必要がある。ルータのDHCPレンジが192.168.0.1〜192.168.0.99なら「192.168.0.100,192.168.0.249」とかになる。「DNSサーバ」は大概ルータだろうから「172.24.0.1」とか「192.168.0.254」など。

  画像の説明 画像の説明

  画像の説明

  一応、管理者としての作業は一段落。次はユーザとして作業を行うので、ログアウトし、ログインし直す。もしくは、別のブラウザを開いてもいい。ホントは別のタブで管理者/ユーザの操作を並行して行えるといいのだが、cookieの都合か、同じブラウザだと並行作業ができないようだ。

  kugutsuでユーザテナントの作成を行なっている場合、ユーザが登録済なので「ユーザ名」が「mitsu」と「パスワード」が「mitsu123」でログインできる。

  最初にやるのは、セキュリティ関係。「プロジェクト」の「アクセスとセキュリティ」の「セキュリティグループ」から「セキュリティグループの作成」を行う。

  openstack内で立ち上がる仮想マシン(インスタンス)には、openstackの機能として標準的にパケットフィルタが備わっており、何も考えずインスタンスを立ち上げると何のパケットも通らず、後で首をかしげることになる。そのため、まずはフィルタリングしないセキュリティグループを定義する。

  「名前」は適当に「open」として「ルールの管理」で「ルールの追加」から「ALL ICMP」「ALL ICMP」「ALL TCP」「ALL UDP」の受信を許可するルールを加える。これで、インスタンスの起動時にこの「open」を付与することで、すべてのパケットの送受信が許容されるようになる。

  次は、インスタンスへのsshログインに使うsshキーの登録。「アクセスとセキュリティ」の「キーペア」から「キーペアのインポート」を行う。

  「キーペア名」は適当に「user_host」などとして「公開鍵」に「ssh-rsa AAAAB3Nz...JWgDura3 user@host」みたいなのを貼り付ける。公開鍵は、普段からLinuxで端末作業をしていれば、普段の端末から「cat ~/.ssh/id_rsa.pub」して表示されるものがそれである。Windowsなんかだとsshキーの生成ができないので「キーペアの作成」を行う必要があるかもしれんが……以下、このエントリを参照のこと。

  最後に、フローティングIPをいくつか確保しておく。「アクセスとセキュリティ」の「Floating IP」から「Floating IPの確保」を行う。「プール」は「public」のはず。「IPの確保」を行うと、上述した「IPアドレス割り当てプール」の範囲から、ユーザにフローティングIPが貸し出される。たぶん「172.24.0.201」とかが確保されたはず。これをインスタンスに付与することで、外からインスタンスに直接アクセスが可能になるという寸法だ。ついでなので「172.24.0.202」「172.24.0.203」と余計に確保しておく。

  次にやるのはテナント内ネットワークの構築。「ネットワーク」の「ネットワーク」から「ネットワークの作成」を行う。最初から存在している「public」は、先ほどopenstack管理者として作った外部ネットワークだ。

  「ネットワーク名」は適当に「private1」。「サブネット名」は適当に「private1_subnet」「ネットワークアドレス」は完全に好みなので「192.168.0.0/24」など。「ゲートウェイIP」は後に仮想的に設置するルータのアドレスなので「192.168.0.1」などにしておく。

  「IPアドレス割り当てプール」は内部的に割り当てる範囲なので、適当に「192.168.0.100,192.168.0.199」とかになる。「DNSサーバ」は大概ルータだろうから、上と同じく「172.24.0.1」とか「192.168.0.254」など。

  ネットワークが複数あるのだから、ルータでつなぐ必要がある。「ネットワーク」の「ルータ」から「ルータの作成」を行う。「ルータ名」は適当に「router1」。「外部ネットワーク」は当然「public」。これにより「public」側につながったから、次は「private1」側につなぐ。

  ルータ名「router1」をクリックして「インタフェイス」から「インタフェイスの追加」を行う。「サブネット」は「private1」。「IPアドレス」は「192.168.0.1」。これにより、「private1」が「router1」を介して「public」につながったことになる。先ほど「ゲートウェイIP」として登録したのは、このルータのインタフェイスだったわけだ。この様子は「ネットワーク」の「ネットワークトポロジ」で確認できる……んが、この表示、ちょっと凝り過ぎではないか。ネットワークがゴムひものように表現されており、機器をドラッグするとビョ〜ンボョ〜ンと動く。面白いが、必要性がわからんわ。

  ネットワークが完成したところで、次はストレージ。USBのポータブルハードディスクを買ってきて接続するイメージ。「コンピュート」の「ボリューム」から「ボリュームの作成」を行う。「ボリューム名」は適当に「volume1」。「容量」は「1GB」でいいだろう。

  ボリュームも用意できたところで、いよいよインスタンスの立ち上げ。「コンピュート」の「インスタンス」から「インスタンスの起動」を行う。「インスタンス名」は適当に「carmilla」。「フレーバー」は「m1.small」。「インスタンスのブートソース」は「イメージから起動」。「イメージ名」は「Fedora23」。一番最初にGlanceへ登録した起動イメージ名だ。

  まだ起動はできない。「アクセスとセキュリティ」の設定が必要だ。「キーペア」は「user_host」。「セキュリティグループ」は「open」。いずれも、上記の作業の中で定義したものだ。最後に「ネットワーク」の設定。「private1」を上の「選択済みネットワーク」にドラッグアンドドロップする。そして、ようやく「起動」。

  インスタンス「carmilla」が起動したら「Floating IPの割り当て」を行う。「IPアドレス」は「192.168.0.101」を選択して「割り当て」。これでようやく仮想マシンが利用可能な状態になったわけだ。ついでなので同様にインスタンス「chun-en」「yukikaze」を余計に起動しておく。

  ここで、さっき作ったボリュームをyukikazeに装備してみる。「コンピュート」の「ボリューム」に並ぶ「volume1」の「接続の管理」を行う。「yukikaze」を選択して「ボリュームの接続」だ。

  「ネットワーク」の「ネットワークトポロジ」を見るとなかなかおもしろい状況になっている。

  さて、各インスタンスにログインしてみる。登録した公開鍵を持つ、普段の端末から「