ansible@ansible-virtual-machine:~/ansible-repo$ ansible all -m ping
The authenticity of host '192.168.219.134 (192.168.219.134)' can't be
established.
ECDSA key fingerprint is SHA256:tEGdORPcNykm0ltty1PSzpUpInJpvthHgeLXXRoX5Wo.
Are you sure you want to continue connecting (yes/no)?
ansible@ansible-virtual-machine:~/ansible-repo$ ansible-playbook -C ntp.yml
[DEPRECATION WARNING]: Instead of sudo/sudo_user, use become/become_user and
make sure become_method is 'sudo' (default). This feature will be removed in a
future release. Deprecation warnings can be disabled by setting
deprecation_warnings=False in ansible.cfg.
PLAY ***************************************************************************
TASK [setup] *******************************************************************
fatal: [192.168.219.133]: UNREACHABLE! => {"changed": false, "msg":
"SSH encountered an unknown error during the connection. We recommend
you re-run the command using -vvvv, which will enable SSH debugging
output to help diagnose the issue", "unreachable": true}
fatal: [192.168.219.134]: FAILED! => {"changed": false, "failed":
true, "module_stderr": "", "module_stdout": "sudo: a password is
required\r\n", "msg": "MODULE FAILURE", "parsed": false}
NO MORE HOSTS LEFT *************************************************************
to retry, use: --limit @ntp.retry
PLAY RECAP *********************************************************************
192.168.219.133 : ok=0 changed=0 unreachable=1 failed=0
192.168.219.134 : ok=0 changed=0 unreachable=0 failed=1
ansible@ansible-virtual-machine:~/ansible-repo$
前提
とりあえず、作って触って見たいがスタートで、特に業務で使おうという野心はありませんww chefみたいなツールを、自社メンバーに共有したいってのがスタートですね。
インストール
[環境]
[履歴] https://github.com/hatakeyama-takeshi/stady/issues/3
触ってみた。
まぁ、ネットに乗っているレベルと変わりませんが。。。。 :sweat: やってみたので、共有です。
触った感じ、zabbixやjenkinsのような運用ツールというか、ansibleコマンドをインストールした感触でした。 (ubuntuサーバ作る方が時間かかった。。。) 簡単にansibleをいうなれば、ansibleサーバから、各種ノードサーバに一斉にコマンド発行できるイメージです。
具体的には、~/ansible-repo配下に、hostsファイルを書いただけで以下が出来ます。
■hostsサンプル (wsがansibleサーバ、nodeがzabbix3.0サーバ)
■全部にpingしてみた。
上記は、対象サーバに一斉にpingしたコマンドです。 対象サーバはhosts管理しているので、ココは自由に書き換えられそうです。 例えばwebサーバだけにコマンド流すとかはできそうですね。
◆ノードサーバだけにping
◆全部のサーバにuname -a
構築導入も結構簡単で、ノード側サーバにはエージェントは本当に不要でした。 opensslで公開鍵を登録してあげるだけ。 結構、既存で動いているサーバにも適応可能ですね。
◆known_hostsに書いてないとコマンド通らない
◆ansibleサーバからコマンド一つでノードサーバ情報を引き抜く (絶対こんなに情報いらないw)
実際にplaybook書いてみたが、失敗w
上記は、pingだけですが、playbookを作れば、対象サーバへの一斉ユーザ追加やログ収集、 ssl証明書更新やntpインストール、たぶんapach再起動みたいなこともansibleで出来そうという事でした。 エージェントレスとかを考えると、古いウォーターフォール型のシステム運用でも、気軽に導入できる気がするので、試してみた。
◆ntpをインストールさせようとして失敗したログ (sudo使えるようにしないとダメだとさ)
実行した結果、サーバに届いてないとか、実行に失敗したというのが、ひとめで分かりますね。
◆うまくいくとこうなる。
ansibleのいいところは、ドライランができることでした。 -Cオプションをいれると、実際にはntpインストールするサーバでコマンドがうまくいくかを先にチェックしてくれます。 これは、心強い。(どこまで信用できるかは、疑心暗鬼w)
playブックですが、YAML形式で、Ansible独自の手続き言語らしいのですが、 まぁ、やっていることはコマンドと変わらないかなぁと。 それこそ、参考書に転がっているレベルはnetにいっぱいありました。 あんまり心配いらないですね
windowsをnodeにできる?そっちも簡単?
もうひとつ、調べてたのは、winodows相手に、ansibleコマンドを打てるかです。 加えて、簡単かどうかがpointです。
こちらは、chefと一緒でcygwinインストール必須でした。。。。 時間切れの為、いったん後回し。 win2008R2環境だけ作っておいたので、あとで試してみる。
触ってみての感触。
下馬評どおり、簡単です。linuxは。 windowsになるとcygwinインストールしないといけないとか、chefと変わんないので、 既存で、chef/puppetを使っている場合は、導入メリット薄めです。
さわってみてですが、 playbookとhostsの管理方法に課題があるとネットにありましたが、まさにそうだとおもいました。 コマンド実行のために書いたファイルが散乱します。 複数人で書いているとごちゃごちゃになりそうでした。 (一人で遊んでても、このバックアップファイルなんだ?と迷う始末。。。)
git intして、github上で管理するのが必須ですね。 (次作るときは、絶対git登録しよう。。。) ベストプラクティスはあるみたいですが、、、ここら辺は実際に使っている人の講演会とかで聞くのが一番よさそう。
プラス面として押したいのが、ドライラン機能。 chefで実行後確認とか、はらはらしながら実行するとかは、やっぱり運用者としては博打的な要素が強い。 もっと、高機能リリースするようにしないと、どれぐらいの精度か分からないけど、、、 実行前にプレ実行できるのは、YESな機能とおもいました。