DevStackを使わないOpenStack開発：openstack-ansible（OSA）活用ガイド

OpenStackのコントリビューターであれば、日々の作業のほとんどをDevStackに頼っていることでしょう。DevStackは長年にわたり、開発・テスト・レビューのための事実上の標準プラットフォームとして使われてきました。この記事では、私がコントリビューターとして参加している「openstack-ansible」というプロジェクトを紹介します。ここ数ヶ月、私はこのプロジェクトをDevStackの代替としてOpenStackのアップストリーム開発に利用していますが、その体験は非常に良好なものでした。

DevStackの何が問題なのか？

openstack-ansibleについて詳しく説明する前に、私がDevStackの代替を探すきっかけとなった理由を簡単にお話しします。全体的に見て、DevStackはよくできたプロジェクトですが、いくつかのアーキテクチャ上の設計判断には不満がありました。

まず第一に、DevStackはモノリシック（一枚岩）なインストーラーを採用している点です。インストールを実行するときは stack.sh を実行すれば、設定したすべてのモジュールがインストールされます。しかし後からモジュールを追加したり削除したりしたい場合は、unstack.sh で一度すべてをアンインストールし、更新した設定で stack.sh を再実行するしかありません。ソースコードに変更を加えた結果、モジュールが不安定に動作してしまうことが何度かありました。そんな状況では再インストールが最も安全な選択肢ですが、DevStackではそれを実現するためにすべてを再インストールするしか方法がないのです。

また、DevStackはすべてのモジュールを開発モードでインストールするため、本番環境のデプロイとは大きく異なる環境が作られます。理想的な開発環境とは、自分が作業対象としているモジュールだけを開発モードでインストールし、それ以外は本番モードでインストールされている状態だと私は考えています。しかし、これはDevStackでは実現できません。

もう一つの悩みの種は、依存関係の一貫性を保つための絶え間ない格闘でした。DevStackでは依存関係がすべてのモジュール間で共有されているため、ある一つのモジュールの依存関係を同期するだけで、他の複数のモジュールの更新が必要になる連鎖反応が起こり得ます。最近のDevStackリリースではモジュールごとの仮想環境を使うことで多少緩和されていますが、それでもOSレベルのパッケージは共有されたままです。

openstack-ansible（OSA）とは？

openstack-ansibleプロジェクトは、Rackspace発のオープンソースイニシアチブで、Ansibleの力を借りてOpenStackをデプロイします。以前はStackForgeで os-ansible-deployment という名前で知られていましたが、その後OpenStackのビッグテント（公式プロジェクト群）に移行しました。

DevStackと同様に、openstack-ansibleもベンダーパッチやアドオンなしで、各サービスをgitリポジトリから直接デプロイします。しかし大きな違いは、openstack-ansibleがOpenStackサービスをLXCコンテナ内にデプロイする点です。これにより、同じノード上でホストされるサービス間で、OSレベルおよびPythonパッケージレベルの完全な分離が実現されます。

DevStackとのもう一つの違いは、openstack-ansibleが本番向けディストリビューションであるという点です。これを使えば、少数ノードの構成から、数百、数千ノード規模の大規模クラスターまで、エンタープライズ級のプライベートクラウドをデプロイできます。

次の図は、openstack-ansibleプライベートクラウドの構造を示したものです：

これを見ると、明らかにマルチノードのプライベートクラウド向けに設計されたこのプロジェクトが、どうやってDevStack並みの手軽さでアップストリーム開発に対応できるのか、疑問に思うかもしれません。ご心配なく！次のセクションで詳しく説明します。

OSA オールインワン（All-In-One）構成

openstack-ansibleのコントリビューター自身も、日常業務やゲーティング（CIテスト）にはシングルノードデプロイを使用しています。こちらの方がはるかに便利で、リソース効率も良いからです。このデプロイ方式なら、クラウドサーバーや仮想マシンの上でOSAを立ち上げることができるため、この特徴を活かせばDevStackに匹敵する使い勝手を実現できます。

残念ながら、OSAのシングルノードデプロイに必要なホスト要件はDevStackより高めです。主にコンテナインフラによるオーバーヘッドが原因です。実用的なインストールを行うには、ホストに16GB以上のRAMと80GB以上のディスク容量が必要です。現時点でサポートされているホストOSはUbuntu 14.04のみとなっています。

OSAがDevStackに対して持つ大きな利点の一つは、コンテナ化アーキテクチャのおかげで、シングルノード環境でも冗長化されたサービスをデプロイできる点です。デフォルトのシングルノード構成では、galera、rabbitmq、keystoneが冗長化されてデプロイされ、ホスト側にはHAProxyがインストールされロードバランシングを担当します。

さあ、実際に手を動かす準備はできましたか？上記スペックを満たす新しいUbuntu 14.04サーバーにアクセスできるなら、以下のコマンドでOSAリポジトリをクローンできます：

# apt-get -y install git
# git clone https://github.com/openstack/openstack-ansible /opt/openstack-ansible

プロジェクトをこのディレクトリにクローンする必要はありません。お好みの場所にクローンしても構いません。

次に、シングルノード用の設定ファイルを生成します。幸い、プロジェクトにはそれを自動で行うスクリプトが付属しています：

# cd /opt/openstack-ansible
# scripts/bootstrap-aio.sh

上記コマンドの実行後、/etc/openstack_deploy ディレクトリにYAML形式の設定ファイルがいくつか生成されます。特に注目すべきは user_secrets.yml ファイルです。このファイルには、インストールで使用されるすべてのパスワードが含まれています。これらのパスワードはランダム生成されるため覚えにくいものですが、私はadminパスワードをよく使うので編集しています。具体的には、

keystone_auth_admin_password: cY3QHwjMLRdSuZMlKI3OvujScCNeIMdH

を次のように変更します：

keystone_auth_admin_password: secrete

残りのパスワードはあまり使わないのでそのままにしていますが、必要になりそうなパスワードは覚えやすいものに変更しておくとよいでしょう。

続いて、ホストにAnsibleをインストールし、使いやすくするためのラッパースクリプトや追加ツールを導入するスクリプトを実行します：

# scripts/bootstrap-ansible.sh

これでホストはOSAのインストールを受け入れる準備が整いました。インストールを実行するAnsibleプレイブックを起動しましょう：

# scripts/run-playbooks.sh

Rackspace Public Cloudのサーバーでは、すべてのプレイブックの実行完了まで約45分かかります。Ansibleを使う嬉しい点は、すべてのタスクが冪等（idempotent）であることです。つまり、プレイブックは何度実行しても問題が起きません。すでに実行済みのタスクは、2回目の実行では何もしません。これは非常に便利で、システムを壊さずに適切な設定ファイルを変更してプレイブックを再実行するだけで、稼働中のシステムを再設定できます。

openstack-ansible クイックツアー

このセクションでは、OSAシングルノード構成の全体像をご紹介します。勇気を出して構築してみた方のために、何がどこにあるのかを把握できるようにしましょう。

まず、Horizonダッシュボードがデプロイされており、ホストのパブリックIPアドレスからアクセスできるはずです。admin アカウントでログインし、パスワードは /etc/openstack_deploy/user_secrets.yml ファイルに入力したものを使用します。このファイルを編集していなかった場合は、ファイルを開いて keystone_auth_admin_password の設定値を確認してください。

前述の通り、すべてのサーバーはLXCコンテナ内にインストールされています。以下のコマンドでコンテナの一覧を表示できます：

root@miguel-lxc-server:~# lxc-ls -f
NAME                                          STATE    IPV4                                        IPV6  AUTOSTART
--------------------------------------------------------------------------------------------------------------------------------
aio1_ceilometer_api_container-c8e825de        RUNNING  10.0.3.203, 172.29.237.195                  -     YES (onboot, openstack)
aio1_ceilometer_collector_container-2da3371f  RUNNING  10.0.3.10, 172.29.238.178                   -     YES (onboot, openstack)
aio1_cinder_api_container-88e59c04            RUNNING  10.0.3.125, 172.29.238.106, 172.29.247.183  -     YES (onboot, openstack)
aio1_cinder_scheduler_container-69d2bec4      RUNNING  10.0.3.4, 172.29.239.79                     -     YES (onboot, openstack)
aio1_galera_container-2f36d624                RUNNING  10.0.3.95, 172.29.237.18                    -     YES (onboot, openstack)
aio1_galera_container-3b8e14d7                RUNNING  10.0.3.18, 172.29.237.166                   -     YES (onboot, openstack)
aio1_galera_container-618973ae                RUNNING  10.0.3.82, 172.29.238.189                   -     YES (onboot, openstack)
aio1_glance_container-4b41140f                RUNNING  10.0.3.21, 172.29.237.77, 172.29.246.233    -     YES (onboot, openstack)
aio1_heat_apis_container-40ec9f3e             RUNNING  10.0.3.193, 172.29.239.6                    -     YES (onboot, openstack)
aio1_heat_engine_container-36e270c9           RUNNING  10.0.3.171, 172.29.239.171                  -     YES (onboot, openstack)
aio1_horizon_container-3497588e               RUNNING  10.0.3.33, 172.29.239.114                   -     YES (onboot, openstack)
aio1_horizon_container-6cac5348               RUNNING  10.0.3.30, 172.29.238.168                   -     YES (onboot, openstack)
aio1_keystone_container-821e7cf8              RUNNING  10.0.3.38, 172.29.238.105                   -     YES (onboot, openstack)
aio1_keystone_container-d63c657e              RUNNING  10.0.3.69, 172.29.239.208                   -     YES (onboot, openstack)
aio1_memcached_container-8baf34d5             RUNNING  10.0.3.158, 172.29.237.135                  -     YES (onboot, openstack)
aio1_neutron_agents_container-21b819b7        RUNNING  10.0.3.233, 172.29.239.130, 172.29.240.182  -     YES (onboot, openstack)
aio1_neutron_server_container-b4279bbe        RUNNING  10.0.3.52, 172.29.239.216                   -     YES (onboot, openstack)
aio1_nova_api_metadata_container-79faf41a     RUNNING  10.0.3.60, 172.29.239.110                   -     YES (onboot, openstack)
aio1_nova_api_os_compute_container-fed67563   RUNNING  10.0.3.231, 172.29.239.17                   -     YES (onboot, openstack)
aio1_nova_cert_container-72f66c56             RUNNING  10.0.3.155, 172.29.237.152                  -     YES (onboot, openstack)
aio1_nova_conductor_container-7d0f1b0f        RUNNING  10.0.3.164, 172.29.239.144                  -     YES (onboot, openstack)
aio1_nova_console_container-62af2918          RUNNING  10.0.3.106, 172.29.238.236                  -     YES (onboot, openstack)
aio1_nova_scheduler_container-e6b79b3b         RUNNING  10.0.3.250, 172.29.236.153                  -     YES (onboot, openstack)
aio1_rabbit_mq_container-0e0fe308             RUNNING  10.0.3.86, 172.29.239.93                    -     YES (onboot, openstack)
aio1_rabbit_mq_container-a4a04124             RUNNING  10.0.3.253, 172.29.237.188                  -     YES (onboot, openstack)
aio1_rabbit_mq_container-b9c6dce6             RUNNING  10.0.3.22, 172.29.238.111                   -     YES (onboot, openstack)
aio1_repo_container-6a8377fc                  RUNNING  10.0.3.102, 172.29.237.47                   -     YES (onboot, openstack)
aio1_repo_container-b92c563a                  RUNNING  10.0.3.223, 172.29.239.251                  -     YES (onboot, openstack)
aio1_rsyslog_container-a6e4f7d4               RUNNING  10.0.3.170, 172.29.237.249                  -     YES (onboot, openstack)
aio1_swift_proxy_container-9f0130d3           RUNNING  10.0.3.20, 172.29.237.227, 172.29.247.52    -     YES (onboot, openstack)
aio1_utility_container-d83fab91               RUNNING  10.0.3.39, 172.29.237.161                   -     YES (onboot, openstack)

このリストを見れば、どのサービスがデプロイされたのか一目瞭然です。lxc-attach コマンドでコンテナの中に入ることができます。特に興味深いのは、リストの一番下にある utility という名前のコンテナです。このコンテナに入るには、次のコマンドを使用します：

# lxc-attach -n aio1_utility_container-d83fab91

utilityコンテナが便利なのは、すべてのOpenStackコマンドラインクライアントがインストールされており、adminアカウント用のすぐに使える openrc ファイルも用意されているからです。以下の例では、openstack コマンドを使ってデプロイ済みのユーザーリストを照会しています：

root@miguel-lxc-server:~# lxc-attach -n aio1_utility_container-d83fab91
root@aio1_utility_container-d83fab91:~# source openrc
root@aio1_utility_container-d83fab91:~# openstack user list
+----------------------------------+--------------------+
| ID                               | Name               |
+----------------------------------+--------------------+
| 2257ddc66d4c41ba8500114944cbb852 | dispersion         |
| 22f1824610b34eb2a6cfaba09b8feb93 | ceilometer         |
| 271f9bd069b2440ebb27c8f460bb3bcf | neutron            |
| 2ecb372f6563410ab8138625c45a72e3 | heat               |
| 35a7c9373ff640c4ba768963c1f53f02 | keystone           |
| 37041c2377c44f5cb84ffafee5bfed6f | cinder             |
| 4b7f43c7c2cc443889cd6b5d90a30e49 | glance             |
| 6ee6a4abb7e64b3d801f2653efb9c9ec | swift              |
| 9b375e06cb0a481a8ed2f94e28e1cb39 | nova               |
| b2b90c7eed704c63bbc8ea0eb23f43c4 | admin              |
| bd3eed1e0cf54b93a0d7c6a7849be778 | stack_domain_admin |
+----------------------------------+--------------------+

コンテナから出てホストに戻るには、exit を入力するかCtrl-Dを押します。

ここでAnsibleのもう一つの素晴らしい機能を紹介しましょう。それは、開発中に誤って壊してしまったサービスを再インストールできることです。やり方は簡単で、該当するコンテナを破棄するだけです：

# lxc-stop -n <container-name>
# lxc-destroy -n <container-name>

壊れたコンテナを破棄した後、プレイブックをもう一度実行すれば、新しいコンテナが代わりとして作成されます。ゼロから全部インストールし直すのに比べれば、わずかな時間で済みます。

開発ワークフロー

実際のところ、OSAオールインワンデプロイをどうやってDevStackの代わりとして使っているのか、気になるところでしょう。プロセスはいくつかの簡単なステップで構成されています：

1. 1. OSA-AIOのデプロイ

   もちろん、すべてはシングルノードのopenstack-ansibleクラウドをデプロイすることから始まります。私は通常、Rackspace Public Cloudのサーバーをホストとして使用していますが、前述のスペックを満たす任意のUbuntu 14.04ホストでも構いません。

2. 2. 対象コンテナへのアタッチ

   次に、先ほど紹介した lxc-attach コマンドを使って、作業したいサービスが動いているコンテナの中に入ります。冗長化されてデプロイされたサービスを扱う場合は、まずHAProxyの設定を編集して、アクティブなコンテナを1つだけにします。選択したコンテナに問題が発生した場合に備えて、残りのコンテナはバックアップとして使えます。

3. 3. 対象サービスの停止

   コンテナでは、私が作業しようとしているサービスの本番バージョンが稼働しています。このサービスは私にとって不要なので、標準の service <name> stop コマンドで停止します。たとえばheat-engineコンテナにいる場合は、service heat-engine stop を実行します。

4. 4. 開発バージョンのクローン

   これで対象サービスを実行する準備が整ったコンテナができたので、実際に作業するコードをクローンします。公式のgitリポジトリ、独自の変更を加えたフォーク、あるいはレビュー作業中であればGerritからのパッチなど、目的に応じて使い分けます。

5. 5. 依存関係の更新

   開発バージョンは、Ansibleプレイブックでインストールされたバージョンとは異なる依存関係を必要とする場合があります。安全のため、コンテナ内で pip install -r requirements.txt を実行します。OSAは独自のプライベートPythonパッケージリポジトリを作成するため、必要なパッケージのバージョンがそこに存在しないことがあります。その場合は、コンテナの /root/.pip/pip.conf ファイルで no-index = False を設定してPyPIへのアクセスを有効化し、再試行します。

6. 6. データベースの同期

   OSAでインストールされた元のバージョンと開発バージョンとの間には、データベースマイグレーションにも差異がある可能性があります。念のため、常にデータベースを同期しておきます。コマンドはサービスによって多少異なりますが、通常は管理スクリプトを db_sync オプション付きで呼び出します。たとえばKeystoneの場合は、keystone-manage db_sync コマンドでデータベースを同期します。

7. 7. 必要に応じて元の設定ファイルを変更

   プレイブックはすべてのサービスの設定ファイルを作成するため、多くの場合、インストーラーが /etc ディレクトリに残した設定をそのまま開発に使えます。作業に関連するカスタム変更が必要な場合は、テキストエディタで手動で行います。

8. 8. 手動で実行、またはサービスとしてインストールして実行

   最後に、開発バージョンを起動します。最も簡単なのは、Pythonアプリケーションを直接実行する方法です。たとえばheat-engineサービスを開発している場合、プロジェクトのルートディレクトリから bin/heat-engine を実行すれば、サービスをフォアグラウンドで起動でき、ログはターミナルに出力されます。サービスの停止はCtrl-Cで行えます。DevStackと同じ要領ですね。

   pdb（コマンドライン）やpudb（インタラクティブ）といったターミナルフレンドリーなデバッガーは、コンテナ内にインストールすれば快適に動作します。PyCharmのような高機能なデバッガーを使いたい場合は、ssh経由でホストからコンテナへリモートデバッグすることも可能です。

   ほとんどのサービスは手動実行だけで、DevStackと同等の快適さで作業できます。唯一の例外は、Pythonスクリプトを直接実行しないサービス、たとえば通常Apache上で動作するKeystoneです。本番環境ではApacheが使われていますが、開発においてはPythonアプリケーションを直接実行するのが完全に安全で、おそらくeventletベースのWebサーバーが起動します。何らかの理由でApacheを使いたい場合は、python setup.py install で開発バージョンをインストールし、service apache2 restart で既存のApacheサービスを再起動するという方法もあります。また、python setup.py develop でインストールしてからホームディレクトリをApacheのサイト設定ファイルに追加すれば、ソースディレクトリからアプリケーションを実行することもできます。

OSA-AIO のメリット

DevStackの代わりにOSAを使ってきた経験は、総じて快適なものでした。何よりも、依存関係の競合がなくなったのが素晴らしいです。OSAでは、あるサービスをリベースして新しい依存関係が必要になっても、他のサービスはそれぞれ自分のコンテナ内にあるため影響を受けません。

また、デプロイ全体をゼロから作り直す必要がある場面もほとんどありません。OpenStackを新しいリリースへ全体アップグレードするときくらいで、日常的な作業では、既存のインストールに対して局所的な更新や修復を行うだけで済みます。コンテナを1つ破棄して、Ansibleにその部分だけを再生成させ、他のサービスには一切触れずに済むのは本当に便利です。

最後に、OSAではシステムのどの部分を開発パッケージとしてインストールするかを選択でき、残りのOpenStackクラウドは本番用にインストール・設定されたまま保てる点が気に入っています。

OSA-AIO のデメリット

もちろん、どんなものにも完璧ではない面があります。OSAでの作業に関する課題についても正直にお伝えしておきます。

OSAはまだ若いプロジェクトであり、DevStackが享受しているような幅広いコミュニティのサポートはありません。これは、OpenStackのコアではないモジュールに取り組む場合に特に重要になります。執筆時点で、OSAがデプロイをサポートしているのは、Keystone、Nova、Neutron、Glance、Cinder、Swift、Heat、Ceilometer、Horizonです。このリストに含まれないモジュールの開発をしたい場合、OSAはあまり役に立たないでしょう。しかし裏を返せば、現在サポートされていないモジュール向けのAnsibleプレイブックを作りたいという人には、コミュニティが温かく迎えてくれるはずです。

一般に、すべてのモジュールで多数の設定オプションがAnsible変数として公開されていますが、唯一の例外があります。Neutronに関しては設定の柔軟性が低く、コンテナやVM間のネットワークトンネルは常にLinux Bridgeを使うように構成されます。たとえばOpen vSwitchを使った作業が必要な場合は、プレイブック実行後に手動で設定を修正する必要があり、これは決して楽な作業ではありません。また、現時点ではNeutronプラグインは一切サポートされていません。

まとめ

openstack-ansibleを使った私のワークフローが、皆さんにとって学びやすく、実践しやすいものであったなら幸いです。この手法は、Heatのアップストリーム機能開発やバグ修正の時間を大幅に節約してくれました。また、KeystoneフェデレーションのデバッグやトラブルシューティングにもOSAを大いに活用してきました。

OSAの利用に興味を持った方は、ぜひ少し調べてみてください。他のOpenStackコントリビューターたちが、それぞれのワークフローにOSAを組み込んだ方法を解説した記事やブログ投稿が数多く見つかるはずです。