AnsibleでUnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 79が出る。

Ansibleを使っていて、何かの拍子に上記エラーが出たのでメモ。

UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 79:
ordinal not in range(128)

ググると、ここが見つかった。

対応方法としては、site-packagesディレクトリ内に以下の内容をsitecustomize.pyというファイル名で保存。

import sys
sys.setdefaultencoding('utf-8')

デフォルトエンコードをutf-8に変更すればよい。

Ansibleでmsg: the python mysqldb module is requiredが出る。

AnsibleでMySQLを利用する場合、MySQLモジュールを使うのですが、msg: the python mysqldb module is requiredというエラーメッセージが出ることがあります。
これは、サーバ側にPythonのMySQLライブラリが無い。ということなんですね。AnsibleはサーバにSSHで接続後、プレイブックにあるタスクを一つ一つ一時的なPythonスクリプトに変換して実行しています。これの動作に必要なんですが、解決法として、pipもしくはyumなどでMySQL-Pythonをインストール。というのがググれば出てきます。

大抵これで解決はするのですが、インストールしたにもかかわらず、msg: the python mysqldb module is requiredが出続ける場合、サーバ上のPythonのバージョンを確認してください。

実はOSによっては、Pythonのバージョンによって、MySQL-Python27のようにパッケージ名が異なるものがあります。

デフォルトでインストールされるライブラリがPythonのバージョンに依存していないか確認しましょう。

Ansibleで"No authentication methods available"がでてつながらない

Ansibleで"No authentication methods available"が出て何故かSSHにつながらず、ずいぶん嵌ったのでメモ。

Ansibleで、Hostsファイル（インベントリファイル）にSSH接続情報を設定して、その内容に間違いがないにもかかわらず、何故かSSHで接続できないとき。

ググると、SSHキーのパーミッションがどうとか出てくるのですが、SSHコマンドでは無事接続できる。

で、原因はこちら。

[target_server]
127.0.0.1 anshible_port=2222 anshible_ssh_user=vagrant anshible_ssh_pass=vagrant

お分かりいただけただろうか。正解はansibleです。

これ、焦っているときは本気で気づかないのでたちが悪いです。

AnsibleでPostgreSQLのユーザを作成するときに気をつけること。

このところ、暇があればAnsibleを触っています。

前回まではLAMP構成を作ってみましたが、今回はPostgreSQL環境を構築しようとして、
ユーザ作成で地味にはまったのでメモ。

AnsibleでPostgreSQLのユーザを作成するとき、以下のようにします。
*AnsibleのDocumentより抜粋

# Create rails user, grant privilege to create other databases and demote rails from super user status- postgresql_user: name=rails password=secret role_attr_flags=CREATEDB,NOSUPERUSER

なるほど、role_attr_flagsに割り当てる権限を指定するのだな。
というわけで、次のようにしてみました。

 - name: ユーザ作成
   postgresql_user:
     db: "{{ pgsql_dbname }}"
     name: "{{ pgsql_dbuser }}"
     password: "{{ pgsql_dbpass }}"
     priv: ALL
     encrypted: yes
     state: present
     login_user: postgres
     role_attr_flags: "NOSUPERUSER,NOCREATEDB,NOCREATEUSER,NOCREATEROLE"
   sudo_user: postgres
   sudo: yes

 しかし、これはエラーになります。
何故か？と小一時間悩んだのですが、どうやら、NO_SUPERUSER権限は既にNOCREATEDBなどの権限を有しているため、重複するロールを指定するとエラーになるようです。参考

なので、通常はNO_SUPERUSERだけで事が足りそうです。
自分は明示的に指定したかったので、以下のようにNOSUPERUSERを外しました。

 - name: ユーザ作成
   postgresql_user:
     db: "{{ pgsql_dbname }}"
     name: "{{ pgsql_dbuser }}"
     password: "{{ pgsql_dbpass }}"
     priv: ALL
     encrypted: yes
     state: present
     login_user: postgres
     role_attr_flags: "NOCREATEDB,NOCREATEUSER,NOCREATEROLE"
   sudo_user: postgres
   sudo: yes

Ansibleのグループ変数（？）について調べてみた

AnsibleはInventoryファイルやgroup_vars、プレイブックなどに変数を定義することが出来ます。

しかし、デフォルトでは同名の変数は上書きされてしまいます。
これは、たとえばdbというグループとwebというグループを作り、group_varsでwebとdbそれぞれに変数を定義した場合、それぞれのグループで有効。ではなく、すべてはマージされるということです。

では、どういう優先度でマージされるのでしょう？
っと調べてみたのですが、ハッキリした記述は見つけられませんでした。
また、Ansibleではグループを階層構造にすることが出来ます。
階層化したグループ名に対応するgroup_versもまた有効のようですが、同様に同名の変数が有った場合の優先度が不明です。

というわけで、このようなプレイブックを作成し、実際に動かしてみました。

$ ansible-playbook -i hosts.ini site.yml -c paramiko
PLAY [staging2] ***************************************************************
GATHERING FACTS ***************************************************************
ok: [192.168.0.130]
ok: [127.0.0.1]
TASK: [debug var=hoge] ********************************************************
ok: [127.0.0.1] => {
    "var": {
        "hoge": "web"
    }
}
ok: [192.168.0.130] => {
    "var": {
        "hoge": "db"
    }
}
TASK: [debug var=huga] ********************************************************
ok: [127.0.0.1] => {
    "var": {
        "huga": "www"
    }
}
ok: [192.168.0.130] => {
    "var": {
        "huga": "dbdb"
    }
}
PLAY [staging] ****************************************************************
GATHERING FACTS ***************************************************************
ok: [192.168.0.130]
ok: [127.0.0.1]
TASK: [debug var=hoge] ********************************************************
ok: [127.0.0.1] => {
    "var": {
        "hoge": "vars_hoge"
    }
}
ok: [192.168.0.130] => {
    "var": {
        "hoge": "vars_hoge"
    }
}
TASK: [debug var=huga] ********************************************************
ok: [127.0.0.1] => {
    "var": {
        "huga": "www"
    }
}
ok: [192.168.0.130] => {
    "var": {
        "huga": "dbdb"
    }
}
PLAY [web] ********************************************************************
GATHERING FACTS ***************************************************************
ok: [127.0.0.1]
TASK: [debug var=hoge] ********************************************************
ok: [127.0.0.1] => {
    "var": {
        "hoge": "web"
    }
}
TASK: [debug var=huga] ********************************************************
ok: [127.0.0.1] => {
    "var": {
        "huga": "www"
    }
}
PLAY [db] *********************************************************************
GATHERING FACTS ***************************************************************
ok: [192.168.0.130]
TASK: [debug var=hoge] ********************************************************
ok: [192.168.0.130] => {
    "var": {
        "hoge": "db"
    }
}
TASK: [debug var=huga] ********************************************************
ok: [192.168.0.130] => {
    "var": {
        "huga": "dbdb"
    }
}
PLAY [zaiko] ******************************************************************
GATHERING FACTS ***************************************************************
ok: [192.168.0.130]
ok: [127.0.0.1]
TASK: [debug var=hoge] ********************************************************
ok: [127.0.0.1] => {
    "var": {
        "hoge": "web"
    }
}
ok: [192.168.0.130] => {
    "var": {
        "hoge": "db"
    }
}
TASK: [debug var=huga] ********************************************************
ok: [127.0.0.1] => {
    "var": {
        "huga": "www"
    }
}
ok: [192.168.0.130] => {
    "var": {
        "huga": "dbdb"
    }
}
PLAY RECAP ********************************************************************
127.0.0.1                  : ok=12   changed=0    unreachable=0    failed=0
192.168.0.130              : ok=12   changed=0    unreachable=0    failed=0

グループ名のアルファベット順で上書きされるのかなと思ったのですが、

どうやらそのホストが所属している一番末端のグループが優先ですが、プレイブック内のvarsセクションでの宣言が一番最優先のようです。

Ansibleお為し中・・・

気がついたら今年も残すところあと1ヶ月ですね。

職場でたった一人のインフラ担当者だったりすると、サーバ構築ラッシュが発生すると土日連休ボランティア活動する羽目になるのですが（ぉぉぉ
どうにも手が回りそうにないので、Chefに続いてAnsibleに手を出してみました。

といってもPython書いたことないんですが（笑）

AnsibleはChefと違い、

• サーバに特別なエージェントが不要。サーバ側にはSSHとPythonがインストールされていればいい。
• 基本はプレイブックと呼ばれるYAMLファイルにやりたいことを記述するので、習得が容易。
• Ansible Galaxyとよばれるサービスがあり、大抵のやりたい事はここにあったりする。
• 動かすのにサーバなどが不要。
• Chefほど多くのサーバを管理するのには不向き。（管理サーバがいないので）数台程度

という特徴があります。
特にエージェントレスというのは、Chefと違い、サーバに特別何か仕込まなくて良いので、お客さんの環境にセットアップするとか、不要なものを極力入れたくない場合に便利そうです。
反面エージェントがないということは、サーバの現状を取得するとかが難しい。という面もありますが、Chefと違い繰り返し実行して冪等性を確保。というより、おかしくなったらサーバごと作り変える。という用途に向いています。

Ansibleは習得が容易、というよりChefの登場人物や構成要素が多すぎるという気がしますが（笑）
いくつか用語を知っておく必要が有ります。

• Inventoryファイル
• Ansible実行対象サーバを記したINIファイル（のようなもの）。特徴として複数のサーバをグループとして設定することが出来、複数のサーバに設定を行うことが出来る。
• モジュール
• ファイルをコピーとか、DBを作成とか実際にサーバを操作する機能をもったもの。自作も勿論可能。
• プレイブック
• Chefでいうレシピに相当するもの。複数のモジュールを組み合わせて一連の操作を記述したYAMLファイル。複数に分割してInclude出来たりする。
• 感じ的にはシェルのDSLっぽい感じ。
• ロール
• 権限。という訳ではなく、Chefでいうクックブックに相当するもの。複数のプレイブックをまとめたもの。

まずはこれくらいを押さえておけば良いと思います。
自分もAnsible勉強し始めて1週間程度ですが・・・

ではまずは環境構築です。
自分はCygwin上に構築しました。

インストールにはapt-cygコマンドを使用しますので、もし古いapt-cygをつかわれている場合は以下の要領で最新にしておきます。

wget https://raw.githubusercontent.com/transcode-open/apt-cyg/master/apt-cyg
chmod 755 apt-cyg
mv apt-cyg /usr/bin/

まずはPythonをインストールします。

apt-cyg install python
python -V （Vは大文字）

python 2.7.10

とかと出ればOKです。
次に、easy_installやpipを使うのに必要なビルドツール一式をまとめて入れます。

apt-cyg install patch gcc4-core gcc4-g++ make autoconf automake m4 bison readline openssl-devel libsqlite3-devel libxml2-devel libxslt-devel zlib-devel libncurses-devel libtool ca-certificates

次にansibleをインストールするのに必要なpipというコマンドをインストールする為のeasy_installをインストールして、pipをインストールします。（な、長い・・・）

apt-cyg install python-setuptools
easy_install-2.7 pip

やっと準備が出来たので、ansibleをインストールします。

pip install ansible

練習がてら、Vagrant上にJenkinsサーバを構築するAnsibleを作りましたので、これを例に説明します。

まずルートディレクトリにあるhostsというファイルがInventoryファイルになります。
中身はサーバのグループ名「jenkins_server」と、そのグループに所属しているサーバのIPやSSHで接続するユーザ名などが書いてあります。

次に、site.ymlですが、これはマスタープレイブックと呼ばれる、すべての起点になるプレイブックです。
ちなみに今回の例ではひとつだけですが、本番とステージング用など、複数作ることも可能です。その場合それぞれを指定して実行します。

これの中身ですが、hosts:の箇所が実行させるサーバグループ名になります。これはInventoryファイルのグループ名になります。Allとすると、Inventoryファイル全部が対象になります。

rols:の箇所は該当hostsのサーバに対し実行するロールになります。
（とりあえず、Zabbix-agentの箇所は置いておきます）

rollsディレクトリの配下にはそれぞれロールが配置されています。
全部解説は大変なので、まずはcommonロールを見ていきます。
このロールにはhaldlersとtasksというディレクトリがあります。
tasksディレクトリ内には複数のプレイブックがありますが、その中のmain.ymlというプレイブックがこのロールのマスタープレイブックになり、基点となります。
この中では、installとcreate_userとsshの3つプレイブックをインクルードしています。

install.ymlを見ていきましょう。
この中にあるyum:とかservice:とかがモジュールになり、yumとかserviceコマンドに相当する機能を持っています。
モジュールは複数の引数をもつことがあり、key=varという形で渡したり、YAML形式で渡したりします。

handlersについては、commonロールでは使っていないのですが、jenkinsロールのhandlersには"restart apache"と"restart jenkins"という二つのハンドラが登録されています。
これは、プレイブック内でConfファイルを変更した場合などサービスを再起動したりとか、アプリをインストールしたらサービスに登録して起動させたい場合があります。そのときにnotifyとしてハンドラ名を渡すと、そのハンドラに規定されたモジュールが動作します。（Jenkinsロールのmain.yml22~37行目参照）

あと、プレイブックはYAMLなのでChefと違いプログラムが書けません。しかし、with_itemsという構文を使うことにより、変数itemに配列の値を入れることが出来ます。{{ item }}のように使います。なお、変数名はitem固定のようです。

後最後においておいたzabbix_agentですが、ここにロールはありません。
では何処にあるかというと、Ansible Galaxyのサービスからロールをインポートして利用しています。
Ansible Galaxyのインポート方法は以下のとおりです。

ansible-galaxy install dj-wasabi.zabbix-agent

role:以下の記述は、zabbix-agentロールが要求する引数たちです。
Apacheのロールで使用しているテンプレートですが、Ansibleではjinja2（そう。神社です）というテンプレートエンジンを使用しています。
色々出来るようですが、拡張子はj2にする。{{ value }}で変数を埋め込める。てのを知っていれば設定ファイルを丸まる置換とか出来るのでとりあえずは使えると思います。

最後に、Apacheのプレイブックでcopyモジュールを使ってSSL証明書をコピーしているのですが、コミットするとき、うっかりダミーファイルを置くのを忘れてしまったので、GitHubにあがっていませんが、templateディレクトリではなく、filesというディレクトリを作成し、そこからのパスを指定します。

以上ざっくりですが、自分が一週間合間見てお試しした感じです。
ついでにAWS上にちょっと本格的なLAMP環境を構築するものや、Python書いたことないのに無謀にもAnsibleモジュールを2時間で作成したものとかを置いておきます。