"Using a SSH password instead of a key is not possible because Host Key checking is enabled and sshpass does not support this. Please add this host's fingerprint to your known_hosts file to manage this host."
Ansibleで以下のようなエラーが出たときは、一度sshでログインして、fingerprintを残しておけばOK。
TASK [Gathering Facts] ******************************************************************************************** fatal: [app1]: FAILED! => {"failed": true, "msg": "Using a SSH password instead of a key is not possible because Host Key checking is enabled and sshpass does not support this. Please add this host's fingerprint to your known_hosts file to manage this host."}
「Are you sure you want to continue connecting (yes/no)? yes」 にyesで答えればよい。
ssh 192.168.62.128 The authenticity of host '192.168.62.128 (192.168.62.128)' can't be established. ECDSA key fingerprint is a1:a8:f5:ac:5a:27:48:d1:38:fd:56:30:9e:3c:0a:f9. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.62.128' (ECDSA) to the list of known hosts. sysmgr@192.168.62.128's password: Last login: Mon Jul 17 17:01:42 2017 from 192.168.62.1 [sysmgr@localhost ~]$ ログアウト Connection to 192.168.62.128 closed.
fingerprintフィンガープリントとは、デジタルコンテンツの同一性を確認するために使用される値のこと。
Playbookに変数を埋め込む
以下のように、debug-var.ymlに変数を設定してみる。
$ cat debug-var.yml --- - name: check variable action hosts: localhost vars: my_name: test machine tasks: - name: output my_name value debug: msg: "variable my_name's value is {{ my_name }} ."
変数は{{}}で囲むことによって展開することができる。
コマンド実行して確認。
ansible-playbook debug-var.yml
結果は以下のようになる。
$ ansible-playbook debug-var.yml [WARNING]: Host file not found: /etc/ansible/hosts [WARNING]: provided hosts list is empty, only localhost is available PLAY [check variable action] *************************************************** TASK [Gathering Facts] ********************************************************* ok: [localhost] TASK [output my_name value] **************************************************** ok: [localhost] => { "msg": "variable my_name's value is test machine ." } PLAY RECAP ********************************************************************* localhost : ok=2 changed=0 unreachable=0 failed=0
Ansibleで複数ホストに疎通確認
Inventory
IngventoryとはAnsibleから操作する対象を定義するもの。 Inventoryファイルには、INI形式のファイルにホスト情報を記載できる。
[app], [db]のように、[…]で区切られた部分はセクションと呼ばれ、見出しの意味を持つ。
前回まで1行でhostsに書いていたものを、別の書き方で定義してみる。
vm-machine ansible_host=192.168.62.130 ansible_port=22 ansible_user=root ansible_ssh_pass=root_pass
以下のように書き換えて、疎通確認。
$ cat inventory [app] app1 ansible_host=192.168.62.130 app1 ansible_port=22 app1 ansible_user=root app1 ansible_ssh_pass=root_pass1 app2 ansible_host=192.168.62.129 app2 ansible_port=22 app2 ansible_user=root app2 ansible_ssh_pass=root_pass2
pingコマンド実行
$ ansible all -i inventory -m ping app1 | SUCCESS => { "changed": false, "ping": "pong" } app2 | SUCCESS => { "changed": false, "ping": "pong" } [sysmgr@localhost ansible]$
無事に二台とも疎通が取れた。
Git Workflowでspikeブランチやprototypingブランチを作るということ
複数人で開発を行っているときは、他の人に開発中のソースコードを見せるのが望ましい。 まだちゃんとテストしてないけど、とりあえずコミットしたソース、というのをコミットするブランチがspikeやprototyingと呼ばれるブランチだ。
このspikeに色々とコミットしまくって、最終的には綺麗なコミットになるようにrebaseする。 で、最終的にはspikeブランチは消す。
spikeブランチの命名規則はMyFeatureSpike
のようにするのが慣例のようだ。
https://github.com/NancyFx/Nancy/wiki/Git-Workflow
It’s quite normal, and encouraged, that during design/development of your feature you create several spikes/prototypes, which you share with the other developers for feedback. Due to the fact that rebasing public commits is pure evil, and that we require you to rebase any updates from upstream/master, it is recommended that you:
Create one or more “MyFeatureSpike” branch(es) (or words to that effect) - this makes it quite clear to other developers that this is a temporary spike branch, and if they decide to fork it for their own work they should do so in the knowledge that it will:
a) likely be rebased, and
b) get deleted at some point.
When you’re happy with the approach, create your real feature branch and start working on that. It is suggested that you effectively “throw away” your spike branch and start afresh with a test-first approach, but as long as you end up with good quality, well tested code this isn’t enforced.
ファイルやフォルダのアイコンはopenclipartで見つけるといいと思う。
以下のサイトのアイコンがすごくよかったのでメモ。
Ansibleでリモートサーバのコマンドやシェルスクリプトを実行
リモートのサーバ上にあるhoge.shを実行してみる。
# cat hoge.sh #!/bin/sh echo "hogeeee" exit 0 [root@localhost script]#
これをAnsibleホストから実行するには、以下のようなPlaybookを書く。
$ cat command.yml - name: execute shell script hosts: all tasks: - name: execute hoge.sh command: "/root/script/hoge.sh"
以下のコマンドで実行。
ansible-playbook -i hosts command.yml
結果はこんな感じになる。
$ ansible-playbook -i hosts command.yml PLAY [execute shell script] ****************************************************************** TASK [Gathering Facts] *********************************************************************** ok: [vm-machine] TASK [execute hoge.sh] *********************************************************************** changed: [vm-machine] PLAY RECAP *********************************************************************************** vm-machine : ok=2 changed=1 unreachable=0 failed=0
では、exit 1
で終了した場合はどうなるのか?
実行するスクリプトをexit 1
で終了するように変更。
cat hoge.sh #!/bin/sh echo "hogeeee" exit 1 [root@localhost script]#
すると…
$ ansible-playbook -i hosts command.yml PLAY [execute shell script] ****************************************************************** TASK [Gathering Facts] *********************************************************************** ok: [vm-machine] TASK [execute hoge.sh] *********************************************************************** fatal: [vm-machine]: FAILED! => {"changed": true, "cmd": ["/root/script/hoge.sh"], "delta": "0:00:00.003313", "end": "2017-07-15 22:40:10.164897", "failed": true, "rc": 1, "start": "2017-07-15 22:40:10.161584", "stderr": "", "stderr_lines": [], "stdout": "hogeeee", "stdout_lines": ["hogeeee"]} to retry, use: --limit @/home/sysmgr/ansible/command.retry PLAY RECAP *********************************************************************************** vm-machine : ok=1 changed=0 unreachable=0 failed=1
ちゃんとエラーで終了した旨を通知してくれる。
Ansibleで別のサーバにNginxをインストールしてみる
正直、感動した。 こんなに簡単にサーバが作れるなんて…。
site.ymlを以下のように書く。
$ cat site.yml --- - name: Ansible Example hosts: all become: true tasks: - name: Install libselinux-python yum: name: libselinux-python state: present - name: Install EPEL Repository yum: name: epel-release state: present - name: Install ngnix yum: name: nginx state: present - name: set run automation service: name: nginx state: started enabled: true
hostsは以下。
$ cat hosts vm-machine ansible_host=192.168.62.130 ansible_port=22 ansible_user=root ansible_ssh_pass=root_password
で、ansible-playbook -i hosts site.yml
を実行すると、勝手にサーバ上にNginxをインストールしてくれる。
$ ansible-playbook -i hosts site.yml PLAY [Ansible Example] *********************************************************************** TASK [Gathering Facts] *********************************************************************** ok: [vm-machine] TASK [Install libselinux-python] ************************************************************* ok: [vm-machine] TASK [Install EPEL Repository] *************************************************************** changed: [vm-machine] TASK [Install ngnix] ************************************************************************* changed: [vm-machine] TASK [set run automation] ******************************************************************** changed: [vm-machine] PLAY RECAP *********************************************************************************** vm-machine : ok=5 changed=3 unreachable=0 failed=0
別サーバにログインして
# nginx -v nginx version: nginx/1.10.2 [root@localhost ~]#
本当に入ってた!