OpenStackに挑戦する勇気はありますか?OSADで自動デプロイを体験してみよう

これは非常に良い問いです。理由はいくつもあります。第一に、OpenStackは今や大きなバズワードであり、自分をIT業界の「それなりの人間」だと思っている人なら誰もが「これを使うべきだ」と口を揃えます。「クラウド」という言葉と同じように、抵抗は無駄だと。第二に、仮想化技術に関わるものなので、学んでおいて損はないかもしれません。

第三、第四、そしてそれ以降の理由については、この記事を読み進めれば明らかになるでしょう。しかし基本的な前提として、「OpenStackに手を出せるのか?出すべきなのか?」という問いがあります。ここでは、技術的な直感に優れ、OpenStackのような技術に触れてきた経験豊富な視点からこの問いに向き合い、この技術の始め方をご紹介します。

※画像はWikipediaより引用(CC BY-SA 3.0ライセンス)

期待と現実のギャップ

さて、OpenStackということになりました。しかし、大手ホスティング事業者3〜4社を除いて、実際に使っている人を本当にご存知でしょうか?誰もが話題にしているのに、実生活での具体的な活用例はほとんど見かけません。これは私の好奇心を大いにかき立てました。なぜなのか?

当然興味をそそられた私は、OpenStackの旅に出ることにしました。短期間でこの技術をマスターし、皆さんの役に立つチュートリアルをいくつか提供できるかどうか試すためです。ところがすぐに、このソフトウェアは決して甘く見てはいけない代物であり、どんなに直感に優れた技術者でも謙虚にならざるを得ないほどのパワーを持っていることが判明しました。そこで私は方針を転換し、ステップバイステップのガイドを紹介する代わりに、「OpenStackには果たして存在意義があるのか」という根源的な問いと、期待と厳しい現実とのギャップを埋める試みへと舵を切ったのです。

OpenStackは難しい

実際、何時間にも及ぶ苦痛のコマンドライン作業の末、私は悟りました。OpenStackはKVMやDockerのように簡単には手懐けられません。いくつかの簡単な例、manページの熟読、シェルでの試行錯誤だけでは、使い始めることすらままなりません。OpenStackは雪を頂いた山のような存在で、こちらはビーチサンダルで登ろうとしているようなものです。

触れば触れるほど、これは途方もなく複雑で過剰設計されたソリューションだということが分かってきました。いじって何かを成し遂げようとすればするほど、それは逃げていき、魅力を失い、「存在意義とは何か」という哲学的問いだけが深まっていくのです。

やってはいけないこと

OpenStackの始め方をお見せする前に、いくつか重要なポイントを整理しておく必要があります。まず、アーキテクチャについて。高度に複雑で、高度にモジュール化されており、各小さなコンポーネントが名前と機能の両面で独立したサービスとして動作します。今日では、コンポーネントが多いことが良いことだと考えられているからです。

画像はopenstack.org公式ドキュメントより引用(クリックで拡大)

次に、ビジネス上の関連性です。なぜOpenStackを使いたいのでしょうか?OpenStackは何よりもまずインフラストラクチャサービスです。ビジネスを運営することが目的なら、OpenStackを「知る」必要はなく、単に「使え」ばよいのです。さらに自問してください。この技術の学習に投資できる十分な時間、資金、スキル、人員がありますか?どれくらい早く必要で、どれくらい深く理解する必要がありますか?何を達成しようとしているのか?OpenStackのプロバイダーになるのか、それとも利用者なのか?ビジネスで使うなら、その規模は?仮想マシン数十台?数百台?数千台?数万台?

この重要な観点は、バズワードに飛びつきたくてうずうずしている無自覚なマネージャーたちによってしばしば見落とされます。彼らはサービスの「構築」と「利用」の違いを曖昧にし、インフラをビジネスであるかのように扱うことで、自分自身と従業員を混乱させます。するとOpenStackはますます意味をなさなくなります。人々はOpenStackを動かすことに必死になり、その上で別の何かを動かそうとして、数ヶ月の無駄な努力の末に挫折してしまうのです。だからこそ、OpenStackは使用スペクトラムの両端——大規模展開か、まったくなしか——にしか存在しないのです。

やるべきこと

さて、理由について触れましたが、いくつか挙げました。さらに追加しましょう。OpenStackが意味を持つのは、技術の最前線に立ちたい場合です。プライベートクラウドやパブリッククラウドを構築したい場合、サービスプロバイダーになりたい場合、そしてクラウド分野での習熟と主導権を確立したい場合——それがビジネスの副次的な目的であっても正当な目標となり得ます。

また、単にソフトウェアをテストしたり、その上で何かを動かしたいだけの場合にも役立ちます。ブラックボックス的なソリューションとして扱ってもいいですし、初歩的な理解を身につけておけば、問題が起きたときにトラブルシューティングできます。

さて、大きな疑問は「どうやって始めるか」です。前述の通り、手動でのセットアップは悲惨です。数冊の本、数週間の時間、そして膨大なコマンド入力——ユーザー、グループ、ロール、データベース、ネットワークブリッジ、コンテナなど、数え切れないほどの細かな要素を作成する必要があります。

私たちはそのすべてをスキップしたい。通常なら段階的な学習プロセスをお勧めしますが、OpenStackは複雑すぎてそれが通用しません。まずは自動化された仕組みですべてを稼働させ、自動セットアップを盲目的に信じるところから始めます。完全かつ成功裏に設定できたら、ゆっくりと来た道を振り返っていくのです。

OpenStack Ansible Deployment(OSAD)

Webで検索すれば、OpenStackの管理・デプロイの「聖杯」を自称するソリューションが何十個も見つかるでしょう。そうです、こうしたツールが存在するのは、OpenStackが使いにくすぎるからです。根本的な問題を修正する代わりに、インターネットは使いやすくしたり監視したりするための場当たり的なオーバーレイソリューションで溢れています。コンテナ界隈と似ていますね。OSADはそうしたコミュニティプロジェクトの一つですが、他にもFuel、Inception、TripleO、Compass、PackStackなど、実に多くの類似ツールがあります。このチュートリアルではOSADに焦点を当て、今後他の類似ツールも取り上げていきます。ちなみに筆者はこのプロジェクトに関わっているため、偏りを感じたら遠慮なくこの記事を無視してください。

基本セットアップ

技術的には、コマンドを2つ実行するだけです。1つ目はGitHubリポジトリからマスタースクリプトを取得すること、2つ目はAnsibleセットアップを実行することです。この奇妙な小道具が何なのか気になる方のために説明すると、Ansibleは構成管理ツールです。Puppet、Chef、CFEngineなどと同様に、対象マシンへのソフトウェアポリシーと設定のデプロイを自動化するために設計されています。デプロイのロジックはYAML言語構文を使用したPlaybookと呼ばれるファイルに記述されます。ソフトウェアはPlaybookを解析し、SSH経由で必要な設定をターゲットホストに配信します。これがAnsibleの基本的な仕組みです。

注意!

ここではAnsibleの動作詳細には深入りせず、何をするもので、どう振る舞うのかを簡潔に紹介します。構文はかなり直感的で、仕組みを理解すればOSADのymlファイルのロジックも追えるようになるはずです。オンラインドキュメントからのPlaybookサンプルを見てみましょう:

---
- hosts: webservers
vars:
    http_port: 80
    max_clients: 200
remote_user: root
tasks:
- name: ensure apache is at the latest version
    yum: pkg=httpd state=latest
- name: write the apache config file
    template: src=/srv/httpd.j2 dest=/etc/httpd.conf
    notify:
    - restart apache
- name: ensure apache is running (and enable it at boot)
    service: name=httpd state=started enabled=yes
handlers:
    - name: restart apache
      service: name=httpd state=restarted

ここには何があるのでしょうか?Playbookを順番に見ていきましょう:

hosts: このPlaybookをどのホストで実行するかを定義するディレクティブです。
vars: Webサーバー用に設定する変数(ポート番号や最大クライアント数など)を定義します。
remote_user: Playbookのタスクを実行するユーザー(root)を定義します。
tasks: ホスト条件が一致したときに実行する内容を定義します。
- name: ensure apache is at... タスク名を定義します。短い説明でも長い説明でも構いませんが、説明的なタイトル形式の長めの名前の方が理解しやすくなります。
yum: httpdパッケージの最新版をインストールします。
template: サーバー側の設定テンプレートをWebサーバーにコピーし、すべて同じhttpd.confファイルを使うようにします。
notify: 上記のアクションが正常に完了した場合に発火する「restart apache」というトリガーを宣言します。つまり、事後アクションを定義するわけです。
- name: ensure apache is running... このタスクはApacheを起動時に有効化し、実行されていない場合はサービスを開始します。
handlers: サービスの再起動を処理します。設定ファイルのコピーが完了した場合のみ実行されるようにするのが理にかなっています。その後、httpdサービスに必要なアクションを適用します。

これでAnsible Playbookの仕組みが簡単に分かったと思います。OSADをデプロイした後は、提供されているymlファイルを眺めてセットアップ内容を探索できます。コンテナやブリッジなど、複雑な要素がたくさん出てきますが、それこそが狙いです。混乱を避けて、最初は他人に整理してもらうのです。

始めてみよう

ともあれ、私たちの素敵な2つのコマンドはこちら:

bash <(curl https://git.openstack.org/cgit/stackforge/os-ansible-deployment/
plain/scripts/run-aio-build.sh)

/opt/stackforge/os-ansible-deployment/openstack-ansible setup-everything.yml

これでセットアップが開始され、ハードウェアにもよりますが40〜50分程度かかります。快適に動かすには十分なCPU、メモリ、ディスク容量が必要ですが、思ったより少なくて済みます。4コア、8GB RAM、40GBディスクあれば十分で、まともなノートPCでも十分に対応できます。ただし、優れたパフォーマンスは期待しないでください。

...
+ unset -f deactivate
+ exit 0

/opt/stackforge/os-ansible-deployment
----------------------------------------------------------------

- [ Run Time = 2422 seconds || 40 minutes ]
----------------------------------------------------------------

- [ Status: Success ]
----------------------------------------------------------------
+ cat
++ ip -o -4 addr show dev eth0
++ awk -F '[ /]+' '/global/ {print $4}'
+ chmod +x /etc/update-motd.d/20-openstack
+ cat
++ pwd
+ chmod +x /etc/update-motd.d/21-galera

上記のような出力が表示されれば、初期セットアップは成功しています。

Novaで遊んでみる

次の論理的なステップは、実際にコマンドを1つか2つ実行できることを確認することです。システム上のスタック全体を精査するのは難しいかもしれませんが、ネットワークインターフェースが大量に表示されるはずです。コンテナ生成時に作成されるブリッジや仮想デバイスも含まれます。Dockerで見た光景に少し似ています。

Novaコマンドは長くて見苦しいので、コマンドを実行するたびにすべてを入力するよりも、環境変数をいくつか設定しておく方が賢明です:

nova --os-user-name admin --os-password secrete --os-tenant-name admin --os-auth-url
https://172.29.236.100:5000/v2.0 hypervisor-list
+----+---------------------+-------+---------+
| ID | Hypervisor hostname | State | Status |
+----+---------------------+-------+---------+
| 1 | server-001 | up | enabled |
+----+---------------------+-------+---------+

というわけで、環境変数を設定しましょう:

export OS_USERNAME=admin
export OS_PASSWORD=secrete
export OS_TENANT_NAME=admin
export OS_AUTH_URL=https://172.29.236.100:5000/v2.0

これで、短縮版のnovaコマンドでホストを起動できます。基本的には、イメージ、フレーバー、名前を指定するだけです。認証情報ももちろん必要ですが、それは先ほど設定済みです。同様に重要な点として、仮想マシンに接続するためにはSSHキーとファイアウォールルールが必要になります。なければ動きません。

nova secgroup-add-rule default tcp 22 22 0.0.0.0/0
nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0

nova keypair-add Dedoimedo > dedoimedo.pem
chmod 0600 dedoimedo.pem

出力情報にはホストのデフォルト自動生成パスワードが含まれており、実行中のホスト一覧からIPアドレスを取得できます。あとは単純なSSH接続です。成功すれば、奇跡的にOpenStackを稼働させることができ、最初の関門を突破したことになります。

ping -c 1 172.29.248.13
PING 172.29.248.13 (172.29.248.13) 56(84) bytes of data.
64 bytes from 172.29.248.13: icmp_seq=1 ttl=64 time=0.634 ms

--- 172.29.248.13 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.634/0.634/0.634/0.000 ms

ssh -i dedoimedo.pem cirros@172.29.248.14
The authenticity of host '172.29.248.14 (172.29.248.14)'
can't be established. RSA key fingerprint is 5b:cf:ed:99:b8:a9:2a:2f:ce:58:f0:3c:eb:db:7c:c1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.29.248.14' (RSA) to the list of known hosts.

遭遇しうる問題

手動の道を選んでも、自動セットアップを選んでも、あちこちで問題に遭遇する可能性があります。このセクションでは、OpenStackやAnsible、あるいはその両方を扱う際に直面しがちな一般的な問題を詳しく解説します。

openstack-ansible setup-everything.yml
Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e @/etc/openstack_deploy/user_variables.yml "
ERROR: Inventory script (inventory/dynamic_inventory.py) had an execution error: Traceback (most recent call
last):
File "/openstack/os-ansible-deployment/playbooks/inventory/
dynamic_inventory.py", line 21, in <module>
import netaddr
ImportError: No module named netaddr

重要なPythonモジュールが不足しているので、インストールが必要です:

pip install netaddr
Collecting netaddr
/usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/
packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This
prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more
information, see https://urllib3.readthedocs.org/en/latest/
security.html#insecureplatformwarning.
InsecurePlatformWarning
Downloading netaddr-0.7.14-py2.py3-none-any.whl (1.5MB)
100% | | 1.5MB 312kB/s
Installing collected packages: netaddr
Successfully installed netaddr-0.7.14

OpenStack Ansible Deploymentフレームワークを操作していると、All in One(AIO)ビルドに関するエラーが表示されることがあります。すべて順調で動くはずだと思っていても、SSHの問題を示している場合があります:

GATHERING FACTS ***************************************************************
fatal: [aio1] => SSH Error: data could not be sent to the remote host. Make sure this host can be reached
over ssh

TASK: [apt_package_pinning | Add apt pin preferences]
***************************************************************
FATAL: no hosts matched or all hosts have already failed -- aborting

これらのエラーは次の2つのバグに起因する可能性があるため、該当箇所を確認してください。また、3つ目の典型的なエラーは、空でないディレクトリにリポジトリをクローンしようとした場合に発生します:

+ git clone -b master https://github.com/stackforge/os-ansible-deployment.git
/opt/stackforge/os-ansible-deployment
fatal: destination path '/opt/stackforge/os-ansible-deployment' already exists and is not an empty directory.

さらなる学習リソース

このチュートリアルがあなたの洗練された好みには物足りなかった場合は、以下も参考にしてください:

興味深いかもしれないスライド資料もあります。

Red Hat Distribution of OpenStack(RDO)

Mirantis OpenStack Deployment and Management - Fuel

まとめ

ご覧の通り、OpenStackにはあまりにも多くの亜種が存在します。ある意味、複雑で活気がありながら混乱を招くLinuxの世界を、独自の四次元に再現しているようなものです。何らかの標準が確立され、コミュニティに均衡がもたらされるまで、おそらく長い10年間、バズワードと名前の羅列に耐え続けることになるでしょう。OSADは悪くありませんが、Ubuntu 14.04 + LXCベースであり、本番環境ではRed HatやCentOSのようなものを望むかもしれません。もっともな話で、つまり他のセットアップやツールもテストすべきだということです。ただ、それはOpenStackで楽しい洗礼を受けた後に試せばよいことです。

そうは言っても、技術の嵐が過ぎ去るのを何年も待ちたくないなら、目的がビジネスであれ趣味であれ、今すぐOpenStackで遊び始めることができます。何をしようと、最初のステップは圧倒されるものです。だからこそ、必ず補助フレームワークを手に入れてから、核心技術へと遡っていくべきなのです。

OSADは決して簡単で完璧な存在ではありませんが、良質な例です。しかし、OpenStack単体が提供するものよりは何光年も先を行っており、実際に使えるレベルにあり、期待される技術的直感を多少なりとも取り戻してくれます。このチュートリアルが皆さんの前進の一助となれば幸いです。簡単ではないし、散漫で、筆者自身あまり好きではありません。それでも、手持ちのツールでできる最善の方法でしょう。要するに、考えすぎないこと、手動セットアップを避けること、Ansibleを採用すること、初回のエラーをいくつか修正すること、そしてNovaとその仲間たちに慣れることです。しばらく経ったら、OpenStackに戻って、怪物を飼い慣らすまで少しずつ調整していきましょう。今回のガイドは以上です。

追伸：筆者はこのテーマを、アイルランド・ダブリンで開催された今年のCloudOpenカンファレンスで、もっと楽しくエンターテインングな形で発表しました。詳細はマウスをクリックすれば確認できます。さあ、どうぞ。

それでは、また。

Windows 10でDockerを使いこなす！導入からトラブル対処までの入門ガイド

VagrantとCoreOSでクラスタを構築する方法――ネットワーキング設定の徹底解説

Firefoxを使うべき理由 ― 選択の自由とブラウザ競争の未来
私はおよそ15年間、Firefoxを使い続けてきました。その間、Firefoxは美しいプロジェクトへと成長し、素晴らしい拡張機能の宝庫となりました。しかし、その後は競合他社と同じ道を辿ったことで、かつて持っていた核心的な優位性を失いながら、徐々に存在感を薄めていきました。それでもなお、Firefoxは私のメインブラウザであり続けています。そして私に尋ねるなら――あなたもFirefoxをメインブラウザにすべきです。この記事では、その理由をお話しします。メモリ消費量や起動時間のわずかな差、スマートフォンでの見た目の美しさといった日常的な話ではありません。重要なのは「選択」、選択の自由、そして競争
Mozilla Ubiquity 徹底解説――コマンド一つでウェブを操る革新的Firefox拡張機能
世間を席巻するWeb 2.0ブームについて、私は決して熱狂的な信奉者ではありません。しかし……Mozilla Ubiquityは、そんな旧来の価値観に固執しがちな私の心すらも打ち抜いてしまったのです。新しい、洗練されている、そしてウェブそのものに統合されている。本来なら私が好むはずのないもののはずなのに、なぜか気に入ってしまったのです。Mozilla Ubiquityは、ここ数年のインターネット界に登場した中で最も革新的で実用的なソリューションのひとつです。まだバージョン0.1前後という発展途上の段階であるにもかかわらず、この記事を書かずにはいられませんでした。この「赤ちゃん」が成長しきった姿