本連載ではこれまでにも第483回「UbuntuとOpenNebulaでもういちどクラウド環境を構築してみよう」などで、クラウド構築・管理ツールであるOpenNebulaを紹介してきました。今回はこのOpenNebulaをコマンド一発で導入できる「miniONE」を紹介しましょう。
OpenNebulaとminiONE
OpenNebulaはプライベートクラウドを構築・管理するためのソフトウェアです。プライベートクラウドの構築・管理ツールといえばOpenStackが有名ですが、OpenNebulaはそれよりも古くから存在し、Eucalyptusと同じぐらいの歴史を持っています。さらに、もともとはKVMベースのツールだったものの、最近ではLXDやFirecrackerをサポートしたり、Kubernetes、Docker Hubとの連携もできるようになるなど、日進月歩なクラウドインフラストラクチャーのテクノロジーに追随しています。先日には広く使われるようになったことをうけて、よりサポートを充実させたエンタープライズ版をアナウンスするなど、今ではもう単なる「OpenStackの代替」だけでは表せない存在になりました。
OpenNebulaについては大田さんが本連載でも何度か取り上げています。第484回で紹介した5.4に比べると、現在のバージョンは5.12[1]まであがってはいるものの、インストール方法や使用感はそこまで大きく変わっていません。引き続きリストアップした記事のうち、5.0以降の話が参考になるはずです。
今回紹介するのはOpenNebulaのインストーラーである「miniONE」です。miniONEを実行することで、システムシステム上にバックエンドからフロントエンドに至るまでOpenNebulaに必要なパッケージ・ソフトウェアをコマンド一発で「まるっと一式」インストールしてくれます。身も蓋もない言い方をすると、OpenStackで言うところのDevStackやMicroStack、Kubernetesで言うところのMinikubeやMickroK8sみたいなものです。
miniONEを使うと、ほんの数分でOpenNebula環境が整います。しかもインストーラーそのものは単一ファイルのシェルスクリプトとして構築されているため、「インストーラーのインストール」も不要です。さらにKVMだけでなく、LXDやFirecrackerにも対応しています。ただしその仕組み上、プロダクション用途や大規模で柔軟な構築には向きません。あくまで「とりあえずOpenNebulaが動くマシンが欲しい」場合にのみ役に立つツールだと考えておきましょう。
今回はこのminiONEを使って、OpenNebulaをインストールしてみます。
miniONEの実行
最初にminiONEをダウンロードした上で、そのシェルスクリプトを管理者権限で実行します。
少し待てばインストールを実行するかの確認メッセージが表示されるので「yes」と答えてください。
あとはしばらく放置すると、インストールが完了し、ウェブインターフェース用のURLとアカウント情報が表示されます。ウェブブラウザーからログインすれば、ウェブインターフェース(Sunstone)経由でOpenNebulaを管理できるようになります。
これだけです。これだけで、今回の記事で伝えたかった「OpenNebulaは簡単にインストールできる」の説明が完了しました。それでは皆さん、良いOpenNebulaライフを。
……と終わるわけにもいかないので、もう少し詳しく説明しましょう。まずはminioneスクリプトについて簡単に紹介したあと、遭遇しやすいトラブルとその回避方法を紹介します。まずはminiONEの実行環境についてです。仮想マシンの管理システムである以上、OpenNebulaを動かすためにはそれなりのスペックが必要です。
- KVMを動かすなら仮想化支援機構が動くCPU
- 4GiB以上のメモリー
- 20GiB以上のストレージ
- インストールするための管理者権限
上記は最低限必要なスペックとなります。KVMではなくLXDを使うならもう少し余裕はあるものの、十分なストレージ容量が必要であること自体は変わりありません。
さらにminiONEには各種コマンドラインオプションによって、インストール時の挙動を変更できます。
ヘルプメッセージに初期設定値も含めて記述してあるので、どのような設定かはおおよそイメージできるでしょう。
前述の例だと「--marketapp-name='Ubuntu 20.04'
」を指定していました。これは何かと言うと、構築時にダウンロードするMarketPlaceの仮想マシンイメージです。OpenNebulaでは構築済みのイメージをMarketPlaceとして公開しています。OpenNebulaでインスタンスを構築する際は、多種多様なアプリ(構築済みイメージ)から必要なものを選択し、それをベースにすることが一般的です。miniONEでは、構築時に必ずアプリをひとつダウンロードすることになっているようです。
初期設定値は「CentOS 7」です。ただしこれは8GiB強と若干サイズが大きいため、先ほどのコマンドでは2GiB程度で済む「Ubuntu 20.04」を選択しています。
インストール中は特に何もすることはありません。ただひたすらホストにパッケージをインストールしたり、ネットワーク設定をしたりする様を眺めているだけです。最初のほうで一度確認メッセージが表示されますが、これすらも「--yes
」オプションを付けておけば、問い合わせが来ることすらなくなります。
インストール時の完全なログは次のとおりです。おおよそどんなことをしているかが把握できるでしょう。
oneadminアカウント
miniONEでインストールした場合、OpenNebulaの管理ユーザーとして「oneadminユーザー」が作成されます。CLIからOpenNebulaを操作するためのコマンド(だいたい「oneXXX」な名前)は、このユーザー経由で実行することになります。
たとえばダウンロード済みのイメージを表示する「oneimage list
」は一般ユーザーで実行すると次のようにエラーになります。
それに対して、oneadminアカウント経由だと次のように表示されます。
また作成した仮想マシンインスタンスにログインする際のSSH鍵もoneadminアカウントに紐付けられています。インスタンス作成後、とりあえずログインしたい場合は次のように実行すると良いでしょう。
OpenNebulaをCLIから操作するのであれば、ターミナルマルチプレクサーなどのウィンドウで「sudo -i -u openadmin bash
」などと実行して、openadminアカウントのシェルインスタンスを作っておくと便利です。
ちなみにウェブインターフェース(Sunstone)からであれば、VNC経由のコンソールログインも可能です。そちらの場合、rootアカウントのパスワードはminioneコマンドの「--vm-password
」で指定された値となります。
もちろん、パスワードなどの設定はインスタンス作成時に調整可能です。
OpenNebulaのアンインストール
「--purge
」オプションで、インストールした環境をまっさらにできます。
おおよそは元通りにしてくれるのですが、すべてキレイになるというわけでもなさそうです。たとえばapt-key
で追加したOpenNebulaのリポジトリ鍵はそのまま残るため、必要に応じて手動で削除してください。具体的にはapt-key list
コマンドで表示される「OpenNebula Repository」の鍵ID(pubとuidの間の行に現れる十六進文字列)を「sudo apt-key del "鍵ID"
」とします。表示される鍵IDは空白を含んでいるためダブルクオーテーションでくくる必要があります。
もしminiONEによるインストール途中で失敗した場合などは、そのまま再実行するとエラー終了するようになります。「--force
」オプションによる強制再実行も可能ではあるのですが、「--purge
」で一度クリーンにしておいたほうが安全でしょう。
トラブルシューティング
miniONEはシェルスクリプトとして作成されています。中身は比較的シンプルですので、何か問題があればとりあえずスクリプトを読むと良いでしょう。また、場合によっては自分で挙動を変更してしまう手もあります。
デバッグログを仕込む際に注意すべきなのは、miniONEは各処理を関数化した上で、check
関数経由で実行しているという点です。
この関数はコマンド(miniONE内の関数)の実行をリトライしながら、それにに伴う標準出力・標準エラー出力を一時ファイルに記録した上で、状況に応じて出力するかどうかを判断しています。結果としてスクリプト内部のコマンドやデバッグログはリアルタイムでは表示されませんし、スクリプトが途中で失敗すると状況を把握しづらくなります。
どうしても「うまく動かない」場合は、まずこのcheck
関数の挙動を把握した上で、目的に合わせてよりデバッグしやすい形に変更すると良いでしょう[2]。
また、ネットワーク環境によっては次のふたつのケースで常に失敗する可能性があります。
- 「Image download reached timeout」と表示されてエラー終了する
- 「Exporting [XXX] from Marketplace to local datastore」が表示されたあとに無言で終了する
前者は、MarketPlaceの仮想マシンイメージのダウンロードが5分(300秒)以上かかった場合に発生します。Ubuntuだと2GiB程度、CentOSだと8GiB程度になるためネットワークによってはここでタイムアウトエラーが発生します。インストール時にダウンロードしない選択肢はないようなので、より小さなイメージを選択するか、スクリプトの中の次の変数の値をより大きな数字に変更して回避してください。
後者はMarketPlaceのメタデータの同期待ちで発生するようです。具体的には次のコードの部分です。
OpenNebulaのインストール直後はメタデータの同期ができていないのか、「openmarketapp list
」で表示されるアプリの数が少なく表示されます。時間が経つごとに増えていって、最終的に400個ぐらいで安定します。スクリプトの中では、その同期待ちの時間の上限を30秒と決め打ちしていますが、環境に寄ってはもう少しかかることもあるようです。
「Exporting [XXX] from Marketplace to local datastore」が表示されたあとに無言で終了する場合は、ここの「seq 30
」をもう少し長めに取ると良いでしょう。
LXDのGUIとしてOpenNebulaを使えるのか
miniONEにはLXD実行環境を用意するための「--lxd
」オプションも用意されています。これはminiONEはLXDの公式サイトでも紹介されている手順です。ただ、試してみたところ、「そのまま」だとうまく動くようには作られていないようでした。
OpenNebulaのLXD対応は、第484回「UbuntuとOpenNebulaでKVMとLXDのインスタンスを起ち上げてみよう」でも紹介されています。miniONEも、そこに説明された方法をほぼ踏襲してはいるものの、すべてが同じというわけではありません。そもそも、第484回でも言及しているように、OpenNebulaのLXD対応はrootfsイメージをダウンロードしてきてそれを使うというタイプのものなので、通常のLXDの挙動を期待するといろいろとはまります。
現時点ではあくまで「そういうものがある」ぐらいに受け取っておいたほうがいいでしょう[3]。