タグ: Linux Page 18 of 29

概要

検証の続き。

• Ansibleサーバのインストール
• Ansibleサーバにクライアントを設定

まで完了したので、Playbookを書いてみます。

Playbookサンプル

単純に、Webサーバ（apache2）を再起動するためのymlを書きます。

• WebRestart.yml

---
- name: Restart Apache2 Service
  hosts: clients
  become: yes  
  tasks:
    - name: Restart Apache2
      service:
        name: apache2
        state: restarted

Playbook実行失敗

• Playbook実行

ansible-playbook WebRestart.yml

• 実行結果抜粋

fatal: [IP]: FAILED! => {"ansible_facts": {}, "changed": false, "failed_modules": {"setup": {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"}, "failed": true, "module_stderr": "Shared connection to IP closed.\r\n", "module_stdout": "sudo: パスワードが必要です\r\n", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1, "warnings": ["Platform linux on host IP is using the discovered Python interpreter at /us

• サービス再起動のためには管理者権限が必要
• 管理者権限への昇格のためのパスワードが書かれていない

ため、この結果となりました。

回避策

• Ansibleのクライアントにrootログインする
• sudoの昇格時にパスワードを不要とする

の2つはセキュリティ的によろしくありません。

• Ansible Vaultで暗号化

は、暗号化→複合化の手間を伴います。そこで、単純に

ansible-playbook --ask-become-pass WebRestart.yml 

とすることで、Playbook実行時にリモートホストのSudoパスワードを尋ねられるようになり、上記Playbookも正常に実行できました。

回避策の更に回避策

効率化を図るとはいえ、Playbook実行時に

ansible-playbook --ask-become-pass 

とオプションをつけるのは面倒です。更に回避策を考えます。

Case1. セッション時のみ有効なエイリアスをつける

alias ansible-playbook='ansible-playbook --ask-become-pass'

を作業前に実行。これで、

ansible-playbook

と実行するだけで

ansible-playbook --ask-become-pass

が得られます。この方法は一回限り有効な手段。サーバの設定を余り変えたくないときに有効な手段です。

Case2. .bashrcにエイリアスを付与する。

echo "alias ansible-playbook='ansible-playbook --ask-become-pass'" | tee -a ~/.bashrc

source ~/.bashrc

Case1を永続的に付与する手法です。運用者での合意が取られているなら、メンテナンス的にも楽だと言うことでこの方法を採ります。

概要

複数のサーバー管理を効率化するため、Ansibleサーバをインストールします。

前提・概要

今回は検証のため、単純構成。

1. Ansibleのホスト
2. Ansibleのクライアント

の2台構成であり、両方とも同じネットワークに属しています。

また、OSは共にUbuntu20.04です。

本項では、「Ansibleのホストサーバ」の設定を行います。

Ansibleホストの設定 (Ubuntu20.04)

Ansibleをインストールします。

sudo aptitude update
sudo aptitude install ansible
# 筆者はapitudeの方が好みです。必要に応じてaptを利用してください。

ホスト～クライアント間のSSH鍵を生成します。

Ansibleホスト～クライアント間はSSHで通信を行うので、鍵のペアを作成します。また、ローカルネットワークのためパスワードは省きます。

• 鍵作成

ssh-keygen -t ecdsa -b 521
# 後続のプロンプトは全て空Enterにします。

ssh-copy-id [Ansibleホストのユーザ名]@[AnsibleクライアントのIPアドレス]
# Ansibleホストのユーザ名のパスワードを入力して鍵を登録します。

• SSH通信確認

ssh [Ansibleホストのユーザ名]@[AnsibleクライアントのIPアドレス]
# SSHログインを確認します。

exit
# ログアウトします。

Ansibleホスト側の設定

• 設定ファイルのコピー(ansible.cfg)

sudo cp -pi /etc/ansible/ansible.cfg /path/to/backup/directory/ansible.cfg.$(date +%Y%m%d)
# 任意のバックアップディレクトリを指定します。

diff -u /etc/ansible/ansible.cfg /path/to/backup/directory/ansible.cfg.$(date +%Y%m%d)
# 差分がないことでバックアップを確認します。

• 設定ファイル修正

以下のファイルを、教義・信仰に沿ったエディタで編集します。

/etc/ansible/ansible.cfg

• 編集内容

[defaults]
inventory      = /etc/ansible/hosts
remote_user    = your_username
private_key_file = /home/your_username/.ssh/id_ecdsa
# 上述した鍵ペアの「秘密鍵」の方を指定します。your_usernameはそれを作成したユーザ名です。

Ansibleホストインベントリの編集

• 設定ファイルのコピー(ホストインベントリ)

sudo cp -pi /etc/ansible/hosts /path/to/backup/directory/ansible_host.$(date +%Y%m%d)
# 任意のバックアップディレクトリを指定します。

diff -u /etc/ansible/hosts /path/to/backup/directory/ansible_host.$(date +%Y%m%d)
# 差分がないことでバックアップを確認します。

• 設定ファイル修正

以下のファイルを、教義・信仰に沿ったエディタで編集します。

/etc/ansible/hosts

• 編集内容

[clients]
[クライアントのIPアドレス] ansible_ssh_user=[ホストのユーザ名]

Ansibleの設定確認

以下のコマンドを実行します。

ansible clients -m ping

次の結果が返ってくれば成功です。

（クライアントのIP）  | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

※以下のようなメッセージは今のところ無視して大丈夫です。

discovered Python interpreter at /usr/bin/python3, but future
installation of another Python interpreter could change this. See
https://docs.ansible.com/ansible/2.9/reference_appendices/interpreter_discovery.html for more information.

これで、Ansibleサーバの簡単な検証が行えました。

クライアント側の設定やplaybookの作成は今後、実施していきます。