一日一行: AnsibleでGCE(Google Compute Engine)を触る

今日はAnsibleでGCEを触りました。
先に参考リンクを貼っていますが、色々見ている通り結構ハマリました。

参考にしたの

環境

OS X 10.9.4
ansible 1.7
apache-libcloud 0.15.1

やってく

やったのは

GCEのサーバ2台作って
apache入れる

です。
多分上記の参考にした記事を見えればできると思うのですがいくつかハマったのでだらだら書いていきます。

0. ディレクトリ構成

1. apache-libcloud をインストール

pipでインストールします。


$ sudo pip install apache-libcloud

2. CA cert chainの取得

http://curl.haxx.se/docs/caextract.html から
「HTTP from curl.haxx.se: cacert.pem」をダウンロードしておきます。

3. 認証情報の作成

3.1. Compute Engine用の証明書ファイルを作成する

Developer Consoleにて
Compute Engineを使う対象のProjectの「APIと認証」> 「認証情報」から「新しいクライアント IDを作成」を押して、
サービスアカウントとして、新しいクライアントIDを作成
作成後「新しいP12キーを作成」から認証ファイルをダウンロード

ダウンロードしたらpem形式に変換


$ openssl pkcs12 -in {ダウンロードしたp12ファイルパス} -passin pass:notasecret -nodes -nocerts | openssl rsa -out /path/to/pkey.pem

credentialsディレクトリに突っ込んでおく。

3.2. secrets.py (認証情報の設定)

secrets.pyは最初にインストールしたlibcloudが利用する認証情報の設定ファイルで以下の様なフォーマットです。

これをcredentialsディレクトリに入れておきます。

ただAnsibleの公式ドキュメントや、Qiitaの方にはsecrets.pyが書いてあるのだけど、本当に作る必要があるのか疑問があります。

というのもAnsibleのドキュメント上ではこのファイルを作ると、playbook内でmoduleに認証情報を渡す必要がないと書いてあるのですが、
どうもうまくいかない。。。

そもそもこのsecrets.pyは2つの観点で利用されているようです。

gce* moduleがgce apiを叩くための認証情報として利用
Dynamic Inventoryで利用

前者が上記に書いてあるplaybook内でmoduleに認証情報を書かなくて良くなる部分なのですが、
実際に叩いてみると、たとえPTYHONPATHにsecrets.pyが置かれているディレクトリが存在したとしても
import secretsが失敗しているようです。

※ansibleのgce moduleでimport secretsしているのはここ

この編Pythonの知識不足ですね...
もう少し色々やってみますが、、、、

後者は後述します。

4. Inventoryの設定

4.1. ローカルホスト用(hosts)

GCE自体の設定(instanceの設定や、networkの設定)はローカルPCからGCEに対して行うので、
localhostの設定をinventoryに行います。

inventoryディレクトリにhostsファイルを作成し以下のように記述しておきます。

4.2. GCE用のDynamic Inventory

Dynamic Inventoryは動的にInventoryを作成する方法で、任意のスクリプトで、
Inventoryを作成することができます。
例えばGCEの場合instanceを立てるごとにipなどが変わってしまう為、
接続先情報を取得するのに必要です。

GCE用のDynamic Inventoryで利用されるスクリプトは公式レポジトリに置いてあるのでそれを使います。

Ansibleのレポジトリから以下の2つのファイルを持ってきて、
inventoryディレクトリに置いておきます。

plugins/inventory/gce.ini
plugins/inventory/gce.py

※普通にコピペして持ってくるでOKです。

そして、gce.iniを設定します。

4.2.1. gce.iniの設定

gce.iniでは 3.2. secrets.py で作成したsecrets.pyのパスを指定するか、
secrets.pyに記述したような情報を直接記載するかが選べます。

気になり毎

GCE Dynamic Inventoryを利用するとGCEインスタンスをタグごとにInventoryにまとめてくれたりします。
例えば、4インスタンス(www1,www2,db1,db2)作成してあり、それぞれ2台ずつwebserver(www1,www2)とdbserver(db1,db2)というタグがついていた場合、
GCE Dynamic Inventoryを利用すると tag_webserverというinventoryとtag_dbserverというinventoryを自動的に作ってくれます。
またzoneやrigionごとのinventoryも作成してくれるため、非常にplaybookが書きやすくなります。

ただ、このDynamic Invetoryはansible-playbookが起動する際に読み込まれるようで、
少し問題が有ります。

例えば以下の様なplaybookがあるとします。

4台のgceインスタンスを作成(tags: webserver, dbserver)
2台(webserver)にhttpdをインストール
2台(dbserver)にredisをインストール

この時dynamic inventoryは1.の手前で読み込まれるようです。
つまりまだGCEインスタンスが作成されていない場合は、webserverもdbserverも存在しないため、
2.,3.でtag_webserver inventoryを利用することができないようです。
※playbookが起動する前に、既にGCEインスタンスが作成されている場合は2.,3.で利用することができます。

この辺りはちょろっと微妙だな～と思っています。
実際には2.の手前でDynamic Inventoryを利用してInventoryをリロードして、
2.,3.の工程で利用したいところですが、なんとなーくその辺を探してもなさそうです。
※あったらだれかおしえてくだしぃ

そうなるとインスタンスを立てて、その後ミドルの設定のようなplaybookは2回起動するか、
分ける必要があります。

自前でリロードするmoduleを書けばいいのかもですが...

5. playbookを作成

上記を踏まえて以下の感じになります。

ポイントはDynamic Inventoryを利用してtag_webserverというinventoryを使ってるラ変です。
ただ前述したとおりインスタンスがまだ存在しない場合は、
2回起動しないと思っている状態になりません。

なお

"vars/instance.yml"
"vars/gce_auth.yml"

は以下の感じです。

6. 起動を作成

あとは普通に起動します。


$ ansible-playbook -i inventory/ master.yml

まとめ

まだまだサンプルが少ないのと、実際に利用されている感じが無いのが厳しいところですね。。。

そもそもGoogle Compute Engine自体がコレ系のセットアップツール(Deployment Manager)をもっているようで(limited previewですが)
この手のサードパーティ製のツールはどこまで対応されるんだっけ？という雰囲気もあるので
仕方ないといえば仕方ないのですが...

一日一行

2014年8月25日月曜日

AnsibleでGCE(Google Compute Engine)を触る