3.2. トラブルシューティングガイド

3.2.1. インストール

3.2.1.1. 特定のバージョンのAnsibleを インストール

Red Hat Enterprise LinuxやCentOSでは、Ansibleをyumコマンドかpipコマンドでインストールすることができます。

そのため、ICEがサポートするバージョンのAnsibleがインストールできなくなることがありますが、この場合はpipコマンドでICEがサポートするバージョンのAnsibleをインストールしてください。

例えば、Ansible 2.2.0.0をインストールするには、以下のコマンドを実行します。

$ sudo curl -kL https://bootstrap.pypa.io/get-pip.py | sudo python
$ sudo yum install -y gcc python-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gdbm-devel wget libffi-devel sshpass
$ sudo pip install ansible==2.2.0.0

3.2.1.2. ssd-copy-idに失敗する

NEC Cloud IaaSや AWS EC2などでは、sshdの設定で証明書による認証のみ許可し、パスワードによるログインを許可しません。そのため、ssh-copy-idに失敗してしまいます。

このような場合、下記いずれかの方法で対処してください。

  • SSHログイン用の秘密鍵がすでに存在する1 (対象のBackendサーバで共通の秘密鍵の場合)
    ansible-playbookコマンドを実行する際に–private-keyオプションで秘密鍵を指定する。
    (秘密鍵がprivate_key.pemの場合)
$ chmod 400 private_key.pem
$ ansible-playbook --private-key=private_key.pem -i hosts_inventory site.yml
  • SSHログイン用の秘密鍵がすでに存在する2 (対象のBackendサーバ毎に秘密鍵が異なる)
    下記のようにhosts_inventoryに各サーバ毎にansible_ssh_private_key_fileオプションを指定する。
    [mq_servers]
192.168.1.1 ansible_ssh_private_key_file=private_key1.pem

[db_servers]
192.168.1.2 ansible_ssh_private_key_file=private_key2.pem

[api_servers]
192.168.1.3 ansible_ssh_private_key_file=private_key3.pem
  • 上記以外の場合
    ssh-keygenコマンドで生成したid_rsa.pubを該当のBackendサーバに転送・コピーし下記のように手動で追加します。
    $ cd ~/.ssh
$ cat id_rsa.pub >> authorized_keys
$ chmod 0600 authorized_keys

3.2.1.3. Ansible管理サーバと同一ホスト上に ICE Backendをセットアップ

Ansible管理サーバとBackendサーバを同一のホストで行う場合にはSSH向けの設定をする必要がありません。

下記のようにhost_inventoryにansible_connection=localを設定することで、SSH向けの設定をすることなくセットアップする事ができます。

[mq_servers]
localhost ansible_connection=local

[db_servers]
localhost ansible_connection=local

[api_servers]
localhost ansible_connection=local

3.2.1.4. Backendサーバの既存ユーザを利用してセットアップを行う

Backendサーバにすでにパスワードなしでsudoを実行可能なユーザが存在する場合、 下記のようにhosts_inventoryにansible_userを設定することができます。

[mq_servers]
192.168.100.1     ansible_user=ec2-user

[db_servers]
192.168.100.1     ansible_user=ec2-user

[api_servers]
192.168.100.1     ansible_user=ec2-user

ansible_connectionやansible_userのパラメータはスペース区切りで組み合わせて指定することもできます。

3.2.1.5. [backendapi : write yaml file] タスクに失敗する

  • 現象

    後述のバージョンのAnsibleでは、Ansibleの不具合によりplaybookの実行に失敗します。

    この不具合によりタスクが失敗した場合は、次のメッセージが出力されます。

    TASK [backendapi : write yaml file] ********************************************
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: RepresenterError: cannot represent an object: basePath
fatal: [192.168.122.1: FAILED! => {"failed": true, "msg": "Unexpected failure during module execution.", "stdout": ""}

    このメッセージが出力された場合は、Ansibleを不具合が無いバージョンに変更してplaybookを実行してください。

  • 対象バージョン Ansible 2.2.1.0, 2.1.4.0

3.2.1.6. [common : install the latest version of OpenSSL] タスクに失敗する

  • 現象

    Ansible 2.7.0.0では Ansibleの不具合によりplaybookの実行に失敗します。

    この不具合によりタスクが失敗した場合は、次のメッセージが出力されます。

    TASK [common : install the latest version of OpenSSL] *****************************************************************************
fatal: [192.168.122.169]: FAILED! => {"changed": false, "msg": "Error accessing repos: Error getting repository data for , repository not

    このメッセージが出力された場合は、Ansibleを不具合が無いバージョンに変更してplaybookを実行してください。

3.2.1.7. IPv6 を無効にしたサーバでICE Backendのインストールに失敗する

/etc/sysctl.conf で次のような設定を行うことでIPv6の使用を無効化している場合、
インストール時にRabbitMQの起動に失敗しAnsibleによるセットアップが失敗します。
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

この事象が発生したとき、セットアップ対象のサーバのsyslogに下記のようなログが出力されます。

epmd[11215]: epmd: failed to bind socket
rabbitmq-server[11064]: Protocol 'inet_tcp': register/listen error: econnrefused

RabbitMQが利用するepmdプロセスが必ずIPv6のソケットを使用するため、そのバインドに失敗しています。

/etc/sysctl.confに次のような設定を追加し、ループバックアドレスだけはIPv6が利用できるように修正してください。 設定を反映させるためにsudo sysctl -pを実行します。

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 0

3.2.1.8. Windows環境にICE Coreをインストールすると「対象のパスが長すぎます」というエラーで失敗する

Windowsの最大ファイルパス長の制限を超える、深い階層/長い名前のフォルダにICE Coreをセットアップしようとした場合に発生します。

ICE Coreのファイル展開先フォルダを浅い階層(例: C:\ice)にセットアップするよう変更してください。

展開先を変更できない場合、下記方法でWindows OS側の制限を緩和してください。

  1. gpedit (または gpedit.msc) を管理者として実行します。

  2. ローカル コンピューターポリシー の下記階層の設定を表示します。

    コンピューターの構成 > 管理用テンプレート > システム > ファイルシステム

  3. Win32 の長いパスを有効にする を編集し、「有効」に設定します。

3.2.2. SSL/TLS設定

SSL終端設定したポートに対するアクセスで問題が発生している場合、 まずはOpenSSLがインストールされたサーバから該当のポートにアクセスできることを確認してください。

$ openssl s_client -connect ＜ホスト＞:＜ポート＞

3.2.2.1. MQTT over TLS に接続できない

  • openssl コマンドで接続した場合に、”CONNECTED”出力後に応答が無くなる
$ openssl s_client -connect ＜ホスト＞:＜ポート＞
CONNECTED(00000003)

RabbitMQに設定した証明書ファイルがRabbitMQのプロセスからアクセスできることと、 証明書ファイルのオーナーを確認してください。

既定値ではrabbitmqユーザでRabbitMQのプロセスを起動しています。 各ファイルのオーナーがrabbitmqユーザでない場合は、下記コマンドによってファイルのオーナーをrabbitmqに変更してください。

$ sudo chown rabbitmq:rabbitmq ＜証明書のパス＞ ＜サーバ証明書のパス＞ ＜サーバ鍵のパス＞

3.2.2.2. ホスト名が変わる環境でRabbiMQのユーザ情報が消える

RabbitMQでは認証に使用するユーザ情報などをNODENAMEという単位で永続化します。このNODENAMEはホスト名を元に決定されます。

そのため、RabbitMQが稼働するサーバのホスト名が変わるとNODENAMEも変更されて、playbook実行時に設定したユーザ情報が取得できなくなります。

これにより、エッジ等からRabbitMQのMQTTトピックに接続したときに、ユーザ/パスワードの認証に失敗してMQTTのpublishとsubscribeができなくなります。

この問題はユーザが意図的にホスト名を変更しなくても、AWSのEC2インスタンスようなサーバ起動のたびにホスト名が変わる環境でも発生します。

この問題の発生を抑制するためにNODENAMEを固定化するには、/etc/rabbitmq/rabbitmq-env.confを作成して、次を定義します。

NODENAME=rabbit@localhost

また、NODENAMEを固定化によりplaybookでRabbitMQに設定したユーザ情報等が見えなくなります。

見えなくなった情報を復旧するには次のコマンドを実施します。

$ rabbitmqctl add_user ＜RabbitMQ管理ユーザ＞ ＜RabbitMQ管理ユーザのパスワード＞
$ rabbitmqctl set_user_tags ＜RabbitMQ管理ユーザ＞ administrator
$ rabbitmqctl delete_user guest
$ rabbitmqctl add_user ＜MQTTユーザ＞ ＜MQTTユーザのパスワード＞
$ rabbitmqctl set_permissions ＜MQTTユーザ＞ ".*" ".*" ".*"