プログラマーの調べ物

プログラマーが調べ物をするときに役に立つサイトを作ります。

"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.


https://github.com/NancyFx/Nancy/wiki/Git-Workflow

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 ~]#

本当に入ってた!