今日はAnsibleでGCEを触りました。
先に参考リンクを貼っていますが、色々見ている通り結構ハマリました。
先に参考リンクを貼っていますが、色々見ている通り結構ハマリました。
参考にしたの
- [公式]Google Cloud Platform Guide(英語)
- [公式]GCE Module
- [公式]Demo: Ansible and Google Compute Engine
- [Qiita]AnsibleでGCEインスタンスを管理する
- [Qiita]AnsibleでGCEロードバランシング
- [Speaker Deck]Google Compute Engine and Ansible(英語)
環境
- 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」をダウンロードしておきます。
「HTTP from curl.haxx.se: cacert.pem」をダウンロードしておきます。
3. 認証情報の作成
3.1. Compute Engine用の証明書ファイルを作成する
Developer Consoleにて
Compute Engineを使う対象のProjectの「APIと認証」> 「認証情報」から「新しいクライアント IDを作成」を押して、
サービスアカウントとして、新しいクライアントIDを作成
作成後「新しいP12キーを作成」から認証ファイルをダウンロード
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などが変わってしまう為、
接続先情報を取得するのに必要です。
Inventoryを作成することができます。
例えばGCEの場合instanceを立てるごとにipなどが変わってしまう為、
接続先情報を取得するのに必要です。
GCE用のDynamic 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
のパスを指定するか、secrets.pyに記述したような情報を直接記載するかが選べます。
気になり毎
GCE Dynamic Inventoryを利用するとGCEインスタンスをタグごとにInventoryにまとめてくれたりします。
例えば、4インスタンス(www1,www2,db1,db2)作成してあり、それぞれ2台ずつ
GCE Dynamic Inventoryを利用すると
またzoneやrigionごとのinventoryも作成してくれるため、非常にplaybookが書きやすくなります。
例えば、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.で利用することができます。
つまりまだGCEインスタンスが作成されていない場合は、webserverもdbserverも存在しないため、
2.,3.でtag_webserver inventoryを利用することができないようです。
※playbookが起動する前に、既にGCEインスタンスが作成されている場合は2.,3.で利用することができます。
この辺りはちょろっと微妙だな~と思っています。
実際には2.の手前でDynamic Inventoryを利用してInventoryをリロードして、
2.,3.の工程で利用したいところですが、なんとなーくその辺を探してもなさそうです。
※あったらだれかおしえてくだしぃ
実際には2.の手前でDynamic Inventoryを利用してInventoryをリロードして、
2.,3.の工程で利用したいところですが、なんとなーくその辺を探してもなさそうです。
※あったらだれかおしえてくだしぃ
そうなるとインスタンスを立てて、その後ミドルの設定のようなplaybookは2回起動するか、
分ける必要があります。
分ける必要があります。
自前でリロードするmoduleを書けばいいのかもですが...
5. playbookを作成
上記を踏まえて以下の感じになります。
ポイントはDynamic Inventoryを利用して
ただ前述したとおりインスタンスがまだ存在しない場合は、
2回起動しないと思っている状態になりません。
tag_webserver
というinventoryを使ってるラ変です。ただ前述したとおりインスタンスがまだ存在しない場合は、
2回起動しないと思っている状態になりません。
なお
- "vars/instance.yml"
- "vars/gce_auth.yml"
は以下の感じです。
6. 起動を作成
あとは普通に起動します。
6. 起動を作成
あとは普通に起動します。
$ ansible-playbook -i inventory/ master.yml
まとめ
まだまだサンプルが少ないのと、実際に利用されている感じが無いのが厳しいところですね。。。
そもそもGoogle Compute Engine自体がコレ系のセットアップツール(Deployment Manager)をもっているようで(limited previewですが)
この手のサードパーティ製のツールはどこまで対応されるんだっけ?という雰囲気もあるので
仕方ないといえば仕方ないのですが...
この手のサードパーティ製のツールはどこまで対応されるんだっけ?という雰囲気もあるので
仕方ないといえば仕方ないのですが...
0 件のコメント:
コメントを投稿