てくなべ (tekunabe)

ansible / network automation / 学習メモ

[Ansible] service モジュールの基本的な使い方(サービスの起動・停止・自動起動の有効化など)

■ はじめに

Ansible には、sytemctlservice コマンドなどによるサービスの管理(起動、停止、再起動削除など)をする service モジュール があります。

この記事では、 service モジュールの公式ドキュメントに記載されている使用例をベースにして、使い方を説明します。

なお、公式ドキュメントの使用例は、Playbook 単位ではなくtask 単位で記載されています。この記事では Playbook 単位で例示します。

動作確認環境

  • Ansible 2.3.0, 2.7.8
  • CentOS 7.6 (Ansible 側、管理対象ホスト側とも)

目次


■ サービスが起動された状態にする

Playbook

apache httpd が起動された状態にする Playbook です。

- hosts: linux
  gather_facts: no
  become: yes

  tasks:
    - name: Start service httpd, if not started
      service:
        name: httpd
        state: started
  • name オプション
    • 対象のサービス名を指定します。(必須)
  • state オプション
    • name で指定したサービスどのような状態としたいかを指定します。
    • state: started を指定するとサービスが起動された状態になります。
      • 起動していない状態だった場合は、起動します。
        • systemctl start httpd のイメージ
      • 起動している状態だった場合は、何もしません。
      • start (起動そのものを指示)ではなく、started (起動された状態なっていることを指示)であることが、他のモジュール、オプションにも通じる特徴です。
      • 他に指定できる値(stopped など)については後述の使用例で説明します。

実行ログ

ここでは、サービスが起動していない状態で Playbook を実行します。

$ ansible-playbook -i inventory service_started.yml 

PLAY [linux] ***********************************************************************************

TASK [Start service httpd, if not started] *****************************************************
changed: [linux1]

PLAY RECAP *************************************************************************************
linux1                     : ok=1    changed=1    unreachable=0    failed=0   

$ sudo systemctl status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: active (running) since Sun 2019-02-24 08:04:47 UTC; 2s ago
   (...略...)

Feb 24 08:04:47 centos7 systemd[1]: Starting The Apache HTTP Server...
Feb 24 08:04:47 centos7 httpd[14442]: AH00558: httpd: Could not reliably determine the ser...age
Feb 24 08:04:47 centos7 systemd[1]: Started The Apache HTTP Server.
Hint: Some lines were ellipsized, use -l to show in full.

無事にサービスが起動された状態になりました。


■ サービスが停止された状態にする

Playbook

apache httpd が停止された状態にする Playbook です。

- hosts: linux
  gather_facts: no
  become: yes

  tasks:
    - name: Stop service httpd, if started
      service:
        name: httpd
        state: stopped
  • name オプション
    • 対象のサービス名を指定します。(必須)
  • state オプション
    • name で指定したサービスどのような状態としたいかを指定します。
    • state: stopped を指定するとサービスが起動された状態になります。
      • 起動している状態だった場合は、起動します。
        • systemctl stop httpd のイメージ
      • 起動していない状態だった場合は、何もしません。
  • enabled オプション(後述)
    • もし、自動起動を有効にしたい場合は、 enabled: yes も併用して指定します。本オプションの詳細は後述します。

実行ログ

ここでは、サービスが起動している状態で Playbook を実行します。

$ ansible-playbook -i inventory service_stopped.yml 

PLAY [linux] ***********************************************************************************

TASK [Stop service httpd, if started] **********************************************************
changed: [linux1]

PLAY RECAP *************************************************************************************
linux1                     : ok=1    changed=1    unreachable=0    failed=0   
(ansible2780) [vagrant@centos7 service]$ sudo systemctl status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:httpd(8)
           man:apachectl(8)

Feb 24 07:55:54 centos7 systemd[1]: Starting The Apache HTTP Server...
Feb 24 07:55:54 centos7 httpd[14291]: AH00558: httpd: Could not reliably determine the ser...age
Feb 24 07:55:54 centos7 systemd[1]: Started The Apache HTTP Server.
Feb 24 08:04:16 centos7 systemd[1]: Stopping The Apache HTTP Server...
Feb 24 08:04:17 centos7 systemd[1]: Stopped The Apache HTTP Server.
Feb 24 08:04:47 centos7 systemd[1]: Starting The Apache HTTP Server...
Feb 24 08:04:47 centos7 httpd[14442]: AH00558: httpd: Could not reliably determine the ser...age
Feb 24 08:04:47 centos7 systemd[1]: Started The Apache HTTP Server.
Feb 24 08:06:34 centos7 systemd[1]: Stopping The Apache HTTP Server...
Feb 24 08:06:35 centos7 systemd[1]: Stopped The Apache HTTP Server.
Hint: Some lines were ellipsized, use -l to show in full.

無事にサービスが停止された状態になりました。


■ サービスが再起動された状態にする

Playbook

apache httpd が再起動された状態にする Playbook です。

- hosts: linux
  gather_facts: no
  become: yes

  tasks:
    - name: Restart service httpd, in all cases
      service:
        name: httpd
        state: restarted
  • name オプション
    • 対象のサービス名を指定します。
  • state オプション
    • state: restarted を指定すると、再起動された状態になります。
      • 起動している状態だった場合は、再起動(停止、起動)します。
        • systemctl restart httpd のイメージ
      • 起動していない状態だった場合は、起動します。
        • systemctl restart httpd のイメージ

実行ログ

ここでは、サービスが起動している状態で Playbook を実行します。

$ ansible-playbook -i inventory service_restarted.yml 

PLAY [linux] ***********************************************************************************

TASK [Restart service httpd, in all cases] *****************************************************
changed: [linux1]

PLAY RECAP *************************************************************************************
linux1                     : ok=1    changed=1    unreachable=0    failed=0   

(ansible2780) [vagrant@centos7 service]$ sudo systemctl status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: active (running) since Sun 2019-02-24 08:13:09 UTC; 4s ago
   (...略...)

Feb 24 08:13:09 centos7 systemd[1]: Stopped The Apache HTTP Server.
Feb 24 08:13:09 centos7 systemd[1]: Starting The Apache HTTP Server...
Feb 24 08:13:09 centos7 httpd[14645]: AH00558: httpd: Could not reliably determine the ser...age
Feb 24 08:13:09 centos7 systemd[1]: Started The Apache HTTP Server.
Hint: Some lines were ellipsized, use -l to show in full.

無事にサービスが再起動された状態になりました。(ログに StoppedStarting がある)

応用編: 再起動が必要な場合のみ再起動する

設定ファイルを変更した場合にのみ、サービスを再起動する、ということも指定できます。

以下の Playbook では、httpd.conf を管理対象ホスト側にコピーします。もし、そのコピーによって、httpd.conf が変更された場合(changed)だけ、handers 配下に定義された httpd_restarted というハンドラー(タスク)が呼び出され、サービスの再起動が実行されます。

- hosts: linux
  gather_facts: no
  become: yes

  tasks:
    - name: deploy httpd.conf
      copy:
        src: httpd.conf
        dest: /etc/httpd/conf/httpd.conf 
      notify: httpd_restarted   # handlers の httpd_restarted に対応

  handlers:
    - name: httpd_restarted  # notify の httpd_restarted に対応
      service:
        name: httpd
        state: restarted

以下に、2回分の実行ログを載せます。1回目は httpd.conf が変更されたため、ハンドラー経由でサービスが再起動しています。 続く2回目は、httpd.conf が前回実行分から変更されていないため、特に何もしていません。

$ ansible-playbook -i inventory service_restarted2.yml   # 1回目 (httpd.conf 変更あり)

PLAY [linux] ***********************************************************************************

TASK [deploy httpd.conf] ***********************************************************************
changed: [linux1]

RUNNING HANDLER [httpd_restarted] **************************************************************
changed: [linux1]

PLAY RECAP *************************************************************************************
linux1                     : ok=2    changed=2    unreachable=0    failed=0   

$ ansible-playbook -i inventory service_restarted2.yml  # 2回目 (httpd.conf 変更なし)

PLAY [linux] ***********************************************************************************

TASK [deploy httpd.conf] ***********************************************************************
ok: [linux1]

PLAY RECAP *************************************************************************************
linux1                     : ok=1    changed=0    unreachable=0    failed=0


■ サービスのコンフィグが再読み込みされた状態にする

Playbook

apache httpd のコンフィグが再読み込みされた状態にする Playbook です。

- hosts: linux
  gather_facts: no
  become: yes

  tasks:
    - name: Reload service httpd, in all cases
      service:
        name: httpd
        state: reloaded
  • name オプション
    • 対象のサービス名を指定します。
  • state オプション
    • state: reloaded を指定すると、コンフィグが再読み込みされた状態になります。
      • 起動している状態だった場合は、realod します。
        • systemctl reload httpd のイメージ
      • 起動していない状態だった場合は、起動します。
        • systemctl start httpd のイメージ

実行ログ

ここでは、サービスが起動している状態で Playbook を実行します。

$ ansible-playbook -i inventory service_reloaded.yml 

PLAY [linux] ***********************************************************************************

TASK [Reload service httpd, in all cases] ******************************************************
changed: [linux1]

PLAY RECAP *************************************************************************************
linux1                     : ok=1    changed=1    unreachable=0    failed=0   

$ sudo systemctl status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: active (running) since Sun 2019-02-24 08:24:17 UTC; 7s ago
   (...略...)

Feb 24 08:24:17 centos7 systemd[1]: Stopped The Apache HTTP Server.
Feb 24 08:24:17 centos7 systemd[1]: Starting The Apache HTTP Server...
Feb 24 08:24:17 centos7 httpd[14978]: AH00558: httpd: Could not reliably determine the ser...age
Feb 24 08:24:17 centos7 systemd[1]: Started The Apache HTTP Server.
Feb 24 08:24:22 centos7 systemd[1]: Reloading The Apache HTTP Server.
Feb 24 08:24:22 centos7 httpd[15029]: AH00558: httpd: Could not reliably determine the ser...age
Feb 24 08:24:22 centos7 systemd[1]: Reloaded The Apache HTTP Server.
Hint: Some lines were ellipsized, use -l to show in full.

無事にサービスが reload された状態になりました。(ログに Reloaded がある)


■ サービスの自動起動が有効化された状態にする

Playbook

apache httpd自動起動が有効化された状態にする Playbook です。

- hosts: linux
  gather_facts: no
  become: yes

  tasks:
    - name: Enable service httpd, and not touch the state
      service:
        name: httpd
        enabled: yes
  • name オプション
    • 対象のサービス名を指定します。
  • enabled オプション
    • state: restarted を指定すると、自動起動が有効化された状態になります。
      • 無効化されている状態だった場合は、有効化します。
        • systemctl enable httpd のイメージ
      • 有効化されている状態だった場合は、何もしません。
    • もし、enabled: no と指定した場合は、無効化された状態にします。(逆の動作)

実行ログ

ここでは、サービスの自動起動が無効化されている状態で Playbook を実行します。

$ ansible-playbook -i inventory service_enabled.yml  

PLAY [linux] ***********************************************************************************

TASK [Enable service httpd, and not touch the state] *******************************************
changed: [linux1]

PLAY RECAP *************************************************************************************
linux1                     : ok=1    changed=1    unreachable=0    failed=0   

(ansible2780) [vagrant@centos7 service]$ sudo systemctl status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2019-02-24 08:26:41 UTC; 8min ago
   (...略...)

Feb 24 08:26:41 centos7 systemd[1]: Starting The Apache HTTP Server...
Feb 24 08:26:41 centos7 httpd[15161]: AH00558: httpd: Could not reliably determine the ser...age
Feb 24 08:26:41 centos7 systemd[1]: Started The Apache HTTP Server.
Feb 24 08:26:45 centos7 systemd[1]: Reloading The Apache HTTP Server.
Feb 24 08:26:45 centos7 httpd[15175]: AH00558: httpd: Could not reliably determine the ser...age
Feb 24 08:26:45 centos7 systemd[1]: Reloaded The Apache HTTP Server.
Hint: Some lines were ellipsized, use -l to show in full.

無事にサービスの自動起動が有効化された状態になりました。(ログに httpd.service; enabled がある)


■ まとめ

公式ドキュメントの使用例をベースにして、service モジュール の使い方を説明しました。

他に「こんなことできるかな?」と気になる事がありましたら、公式ドキュメントで詳細をご確認ください。

docs.ansible.com

また、service モジュールは System modulesに分類されています。System modules には、他にもusertimezonehostnamefirewalld などのモジュールがあります。詳細は System modules の一覧からご確認ください。

[Ansible] yum モジュールの基本的な使い方(パッケージのインストールなど)

■ はじめに

Ansible には、yum によるパッケージの管理(インストール、更新、削除など)をする yum モジュール があります。

この記事では、 yum モジュールの公式ドキュメントに記載されている使用例をベースにして、使い方を説明します。

なお、公式ドキュメントの使用例は、Playbook 単位ではなくtask 単位で記載されています。この記事では Playbook 単位で例示します。

動作確認環境

  • Ansible 2.3.0, 2.7.8
  • CentOS 7.6 (Ansible 側、管理対象ホスト側とも)

目次


■ 最新バージョンのパッケージをインストールされた状態にする

Playbook

apache httpd の最新版をインストールされた状態にする Playbook です。

- hosts: linux
  gather_facts: no
  become: yes

  tasks:
    - name: install the latest version of Apache
      yum:
        name: httpd
        state: latest
  • name オプション
    • 対象のパッケージ名を指定します。
  • state オプション
    • name で指定したパッケージをどのような状態としたいかを指定します。
    • state: latest を指定すると最新バージョンがインストールされた状態になります。
      • インストールされていない状態だった場合は、最新バージョンをインストールします。
        • yum install httpd のイメージ
      • 古いバージョンがインストールされている場合は、最新にアップデートします。
        • yum update httpd のイメージ
    • もし、state: present を指定した場合は、任意のバージョンがインストールされた状態という指定になります。

実行ログ

ここでは、インストールされていない状態で Playbook を実行します。

$ ansible-playbook -i inventory yum_latest.yml 

PLAY [linux] ***********************************************************************

TASK [install the latest version of Apache] ****************************************
changed: [linux1]

PLAY RECAP *************************************************************************
linux1                     : ok=1    changed=1    unreachable=0    failed=0   

$ yum list installed | grep httpd
httpd.x86_64                         2.4.6-88.el7.centos        @base           
httpd-tools.x86_64                   2.4.6-88.el7.centos        @base 

無事に最新版がインストールされました。


■ 複数のパッケージをインストールされた状態にする

Playbook

gitwget をインストールされた状態にする Playbook です。

- hosts: linux
  gather_facts: no
  become: yes

  tasks:
    - name: ensure a list of packages installed
      yum:
        name: "{{ packages }}"
      vars:
        packages:
          - git
          - wget
  • name オプション
    • 対象のパッケージ名を指定します。
    • 別途定義する変数 packages を指定しています。
    • 本タスクのようにリストを指定した場合は、1回の yum コマンドに対するオプションの指定になります。
      • 例えば yum install gityum install wget をそれぞれ実行するのではなく、yum install git wget を 1回実行。
    • 本タスクでは state オプションを省略しているので、実質 state: present 扱いになり、任意のバージョンがインストールされた状態という指定になります。
  • packages 変数
    • インストールされた状態としたいパッケージ名をリストで指定しています。
    • 変数名は任意で、name オプションの指定と整合性があれば問題ありません。

実行ログ

ここでは、いずれもインストールされていない状態で Playbook を実行します。

$ ansible-playbook -i inventory yum_multi.yml 

PLAY [linux] ***********************************************************************

TASK [install the latest version of Apache] ****************************************
changed: [linux1]

PLAY RECAP *************************************************************************
linux1                     : ok=1    changed=1    unreachable=0    failed=0   

$ yum list installed | grep git 
git.x86_64                           1.8.3.1-20.el7             @updates   
$ yum list installed | grep wget
wget.x86_64                          1.14-18.el7                @base           

無事に gitwget がインストールされました。


■ パッケージがインストールされていない状態にする

Playbook

apache httpd がインストールされていない状態にする Playbook です。

- hosts: linux
  gather_facts: no
  become: yes

  tasks:
    - name: remove the Apache package
      yum:
        name: httpd
        state: absent
  • name オプション
    • 対象のパッケージ名を指定します。
  • state オプション
    • state: absent を指定すると、インストールされていない状態になります。
      • インストールされている状態だった場合は、アンインストールします。
        • yum remove httpd のイメージ
      • インンストールされていない状態だった場合は何もしません

実行ログ

ここでは、httpd がインストールされている状態で Playbook を実行します。

$ ansible-playbook -i inventory yum_absent.yml 

PLAY [linux] *******************************************************************

TASK [remove the Apache package] ***********************************************
changed: [linux1]

PLAY RECAP *********************************************************************
linux1                     : ok=1    changed=1    unreachable=0    failed=0   

$ yum list installed | grep httpd
httpd-tools.x86_64                   2.4.6-88.el7.centos        @base  
$ 

無事に http がアンインストールされました。(httpd をインストールしたときに一緒にインストールした httpd-tools は残ります)


■ まとめ

公式ドキュメントの使用例をベースにして、yum モジュール モジュールの使い方を説明しました。

他に「こんなことできるかな?」と気になる事がありましたら、公式ドキュメントで詳細をご確認ください。

docs.ansible.com

また、yum モジュールは Packaging modulesに分類されています。Packaging modules には、他にも yum_repositorydnfapt などのモジュールがあります。詳細は Packaging modules の一覧からご確認ください。

[Ansible] 認証情報の変数名は ansible_user、ansible_password に統一したほうがよさそう

■ はじめに

Ansible で管理対象ホストのユーザー名やパスワードを定義する変数名はいくつかあります。

  • ユーザ名
    • ansible_ssh_user
    • ansible_user
  • パスワード
    • ansible_ssh_pass
    • ansible_pasword

みなさんはどのよいうに使い分けていますでしょうか。

先日たまたま、現在開発中の Ansible 2.8 の Porting Guide を眺めていたら、

  • ユーザー名とパスワードは ansible_useransible_pasword という変数名に統一しましょう
  • ansible_ssh_user のようなコネクションタイプ名が含まれる変数名は将来的に非推奨になるだろう

という旨の記述を見かけました。

Connection plugins have been standardized to allow use of ansible<conn-type>user and ansible<conn-type>password variables. Variables such as ansible<conn-type>pass and ansible<conn-type>username are treated with lower priority than the standardized names and may be deprecated in the future. In general, the ansible_user and ansible_password vars should be used unless there is a reason to use the connection-specific variables.

この記事では本件の経緯などをまとめます。

(以下ツイートの続きです)


■ 経緯

下記の issue で、 _pass_password などの複数の変数名が許容されているものは、ドキュメント上は標準化していったほうが良いのではという提案がありました。

github.com

対するプルリクは以下のものです。

github.com

ドキュメントやログメッセージに含まれる変数名が以下のように変更されていることが、変更の差分で確認できます。

  • ansible_ssh_user から ansible_user
  • ansible_ssh_pass から ansible_password
  • ansible_become_pass から ansible_become_password


■ そもそもどのような変数名が使えるの?

もし既存の Playbook や 変数名の中から認証情報に関する変数名を洗い出して統一するために修正する場合、そもそもどのような変数名が使えるのかを知る必要があります。その場合は、各コネクションプラグイン最新版Doc開発中Doc)の説明ページで確認できます。

例えばネットワークモジュール向けのひとつ、 network_cli コネクションプラグイン (最新版Doc開発中Doc) であれば、パスワードとして ansible_ssh_passansible_password を利用できることが確認できます。


■ まとめ

Ansible で管理対象ホストのユーザー名やパスワードを定義する変数名は、標準化、将来性のため ansible_useransible_password に統一したほうが良さそうです。

[Ansible] -i オプションでディレクトリを指定すると複数のインベントリファイルをマージできる

■ はじめに

Ansible の管理対象ホストを定義するインベントリは、ansible-playbook コマンドの -i オプションで指定します。スタティックなインベントリでも、ダイナミックインベントリでも同じです。

  • コマンド例
$ ansible-playbook -i inventory site.yml

この -i オプションでは、ファイルの指定だけでなく、ディレクトリも指定できます。ディレクトリを指定した場合は、そのディレクトリ配下の複数のインベントリファイルをマージして扱うことができます。

この記事では、簡単な例で試してご説明します。

  • 動作確認環境: Ansible 2.7.5


■ おためし

準備

inventories ディレクトリのインベントリファイルは以下のとおりです。

inventories/
|-- hosts1
`-- hosts2

それぞれのインベントリファイルの中身は以下のとおりです。

  • hosts1
[vsrx]
vsrx1 ansible_host=172.16.0.1

[vsrx:vars]
ansible_network_os=junos
ansible_connection=netconf
  • hosts2
[vsrx]
vsrx2 ansible_host=172.16.0.2

上記の 2ファイルをマージするとどの様になるかご想像つきましたでしょうか。

実行

それでは -iディレクトリを指定して、インベントリファイルがマージでできているかを確認します。

ansible-inventory コマンド編

インベントリの情報を確認するための ansible-inventory コマンドを利用して確認します。

まず --graph オプションで、グループの所属状態を確認します。

$ ansible-inventory -i inventories --graph
@all:
  |--@ungrouped:
  |--@vsrx:
  |  |--vsrx1
  |  |--vsrx2

上記の通り、host1host2 に分かれて定義されていた vsrx グループがマージされ、vsx1vsrx2 の 2ホストが所属する状態になりました。

次に --list オプションででインベントリ情報のリストを表示してみます。

$ ansible-inventory -i inventories --list
{
    "_meta": {
        "hostvars": {
            "vsrx1": {
                "ansible_connection": "netconf", 
                "ansible_host": "172.16.0.1", 
                "ansible_network_os": "junos"
            }, 
            "vsrx2": {
                "ansible_connection": "netconf", 
                "ansible_host": "172.16.0.2", 
                "ansible_network_os": "junos"
            }
        }
    }, 
    "all": {
        "children": [
            "ungrouped", 
            "vsrx"
        ]
    }, 
    "ungrouped": {}, 
    "vsrx": {
        "hosts": [
            "vsrx1", 
            "vsrx2"
        ]
    }
}

上記の通り、vsrx グループがマージさました。 また、host1 にのみ定義していた vsrx グループに対する変数 ansible_connection などもうまくマージされた後に適用されています。

ansible-playbook コマンド編

今度は、簡単な playbook を実行して試します。

  • playbook (test.yml)
- hosts: all
  gather_facts: no

  tasks:
    - name: inventory merge test
      debug:
        msg: "I am {{ inventory_hostname }}"                                   

対象は all にしていますので、vsrx1vsrx2 が対象になるはずです。

(認証情報を定義した変数ファイルは省略)

  • playbook 実行
$ ansible-playbook -i inventories test.yml

PLAY [all] *******************************************************************

TASK [inventory merge test] **************************************************
ok: [vsrx1] => {
    "msg": "I am vsrx1"
}
ok: [vsrx2] => {
    "msg": "I am vsrx2"
}

PLAY RECAP *******************************************************************
vsrx1                      : ok=1    changed=0    unreachable=0    failed=0   
vsrx2                      : ok=1    changed=0    unreachable=0    failed=0  

無事にvsrx1vsrx2 が対象になっていることを確認できました。

補足

■ まとめ

ansible-playbook コマンドなどの -i オプションに、ファイルではなく、ディレクトリを指定するとマージして扱えることを確認できました。

このような指定が必要になるケースは多くはないかもしれませんが、何かのときに思い出していただければ幸いです。

フィードバックがないというフィードバック

フィードバックがほしい

ブログや登壇などのアウトプットをする理由のひとつが、フィードバックが得られることです。

  • わかりやすかった
  • 自分も始めてめてみようと思った
  • 内容が薄い
  • もっと別のことを聞きたかった

こられはすべてフィードバックですので、次のアウトプットにつなげるための参考にさせてもらっています。いつもありがとうございます。

フィードバックがない?

上記で挙げたようなフィードバックがないことももちろんあります。この状態は、何も得るものがなかったということなのでしょうか。

私は、フィードバックがないこと自身が暗黙のフィードバックだと考えています。

直敵的なフィードバック(感想など)が得られなかった原因は、例えば以下のようなものだと思います。

  • フィードバックを得る仕組みを用意していなかった
  • フィードバックを掴みにいく行動をしていなかった
  • 良くも悪くもなかった
  • 何も残らない内容だった
  • ターゲットに届いていなかった

などなど。ふりかえる材料には十分なりえます。

ですので、直接的なフィードバックがないこと自身は、私はアウトプットしない理由にはしていません。そもそも自分向けメモのような、フィードバックを想定していない場合もあります。

Ansible Night in Nagoya 2019.02 に参加と登壇してきました

■ はじめに

【祝】初名古屋開催!

2019/02/15 に名古屋で「Ansible Night in Nagoya 2019.02」が開催されました。

Ansible ユーザー会によるこのイベントは、これまで東京、大阪福岡で開催されてきましたが、今回ははじめての名古屋開催となりました。

ansible-users.connpass.com


■ 会場

Misoca さんのセミナールーム

f:id:akira6592:20190217120917p:plain:w400
会場入り口
f:id:akira6592:20190217120949p:plain:w400
準備中

このようなイベントが開催できるのは、開場提供をしてくださる方々のおかげです。ありがとうございます。 今回は、クラウド見積・納品・請求書サービスを提供する株式会社 Misoca さんのセミナールームを提供していただきました。オフィスへの行き方を説明するページがとてもていねいに書かれているのが、方向音痴な私にとっては助かりました。

ライブビューイングも

東京のレッドハットさんのオフィスでは、ライブビューイングも設定されていました。


■ 各発表

● Ansibleではじめるサーバー・ネットワークの自動化

私の発表分です。

www.slideshare.net

内容は基本的なものに

初の名古屋開催の最初の発表ということで、Ansible とはなにかからはじめる内容にしました。

「8a1」APC勉強会や、ssmjp 2018/10で発表させてただいた内容をベースにして、少し最新情報(Ansible 2.8)の加えました。

その場で Playbook を書いてみる

f:id:akira6592:20190217120406j:plain:w400
デモでPlaybook実行中「ちょっと時間がかかってるようですね・・」

途中「apache httpd をインストールして、index.html をデプロイして、httpd サービスを起動する」という処理の Playbook をゼロから書いて実行するデモを行いました。

yum モジュールのところで、少し時間がかかって、ヒヤヒヤしました。途中で、準備していたデモ動画に切り替えて説明を進めました。そうこうしているうちに、裏では Playbook の処理が終わっていたようで、最後の少し余った時間で、動作確認をすることができました。

  • 実際に書いた Playbook (web.yml)
- hosts: web
  become: yes

  tasks:
    - yum:
        name: httpd
        state: latest
    
    - template:
        src: index.html.j2
        dest: /var/www/html/index.html

    - service:
        name: httpd
        state: started
  
  vars:
    v_name: Nagoya

(時間短縮のため、タスクに name をつけていません・・)

  • 準備していたインベントリファイル (inventory.ini)
[web]
172.16.0.10

[web:vars]
ansible_user=vagrant
  • 準備していたコンテンツファイル(index.html.j2)
<html>
<head>
  <title>Test Page</title>
</head>
<body style="background-color:#339cff">
<h1 style="color:#ffffff">Hello, {{ v_name }}!</h1>
</body>
</html>
  • デモで実行したコマンド
$ ansible-playbook -i inventory.ini web.yml

slack で頂いたご質問

Ansible ユーザー会の slack である ansiblejp (参加リンク http://bit.ly/slack-ansiblejp )で、発表中に以下のご質問をいただきました。

ansibleを書くにあたって便利なエディタとかツールってありますか?

最後の時間で口頭でご紹介しましたが。Visual Studio Code に Ansible という拡張があります。デモ環境もこちらを使っていました。

● Ansible AWXを導入してみた

アビームシステムズ株式会社 後藤卓さん・DaichiYamaguchiさん

www.slideshare.net

  • 作ったものは、AWX、Jenkins、GitLab、Redmineなどで、AWS上のサーバ構築自動化システム。
  • いままでは、紙による構築申請だったところを、redmine に置き換えた。
  • Ansible 単品ではなくAWX を採用した理由は GUIWindows Server を扱う人が多かったため CLI より GUI
  • AWX のいいところは、ジョブテンプレート、実行ログの管理。決め手はロールベースのアクセス制御
  • プロキシに引っかかる場合は突破するための対応が必要
  • 運用で苦労しそうなことは、Playbook 自体の管理やメンテナンスのCI、コンテナが死んだ時の対応をどうするか(オートヒーリングか)

● ネットワークエンジニアがAnsibleと出会った話

株式会社リクルートテクノロジーズ 遠藤惇平さん

speakerdeck.com

  • Ansible でネットワーク機器の自動化も行けそうと思て上司に相談したら通った
  • 自動化対象の作業は自動化難易度の低さを優先、成功体験を積むため
  • Ansibleで、ios/ nxos / panos / junos / bigip のパスワード変更作業の検証が成功

● Ansibleと変更管理とシステム運用と

藤原尚由さん

  • Playbook のメンテナンスは辛い
  • 人の入れ替わりや時間の経過で、なんの処理だかかわからなくなってしまう
  • Playbookの変更理由をgitなりsubversionなりに残しておこう。

● 名古屋コミュニティ盛り上げていきましょう!

DaichiYamaguchiさん

www.slideshare.net

  • 名古屋は人口に対して勉強会の回数が少ない
  • コミュニティ参加すると、最新技術動向を知れる、人脈を築ける
  • 登壇、運営、手伝い、参加、飲み会などでコミュニティに関わってみましょう


■ togetter まとめ

togetter.com


■ Ansible 飯(懇親会)

会場近くの、ぴち天というお店で懇親会を行いました。地元の方に、三河尾張の関係やコミュニティのお話などを楽しく伺いました。


■ 感想など

いろいろな方のお話を聞けて楽しかったです。他の方の諸資料は、アップされ次第リンクを貼らせていだたきます。また、ブログましたなどと声をかけていただけることがあって嬉しかったです。インターネットってすごいですね。

名古屋でもコミュニティが盛り上がるとよいですね。ありがとうございました!

[Ansible] INI形式の変数定義では yes や true は 文字列、True は boolean

■ はじめに

いままで INI 形式のインベントリファイル内での変数は ansible_host くらいしか定義してなかったので気が付かったのですが、boolean の値を定義する場合は YAML とは異なる事情があるようです。

ansibleで変数に入れたyes/noの扱いに苦しんだ - Qiita

自分なりにしらべたことや、試したことをまとめます。

ポイントは、 INI 形式では boolean 値になりそうな値の中では、大文字から始まる True / False が boolean になる点です。

INI 形式では True / False のみが boolean

以下の回答によると、大文字から始まる TrueFalse のみを boolean として扱って、それ以外は文字列扱いになるようです。

How Exactly Does Ansible Parse Boolean Variables? - Stack Overflow

また、以下の公式サイトのページによると、INI 形式で定義した変数は pythonast.literal_eval で処理されるようです。 ini – Uses an Ansible INI file as inventory source. — Ansible Documentation


■ おためし

以下の Playbook で動作を確認します。環境は Ansible 2.7.5 です。

- hosts: localhost
  connection: local
  gather_facts: no

  tasks:
    - name: print value
      debug:
        msg: "{{ test_bool }}"

    - name: print type
      debug:
        msg: "{{ test_bool | type_debug }}"

type_debug フィルターで、Python としての型を確認できます。

INI 形式のインベントリファイルの場合

yes は文字列

インベントリファイル (INI)

localhost test_bool=yes

実行結果

文字列になりました。"yes" のようにダブルコーテーションがついています。

TASK [print value] *************************************************************
ok: [localhost] => {
    "msg": "yes"
}

TASK [print type] **************************************************************
ok: [localhost] => {
    "msg": "unicode"
}

true も文字列

インベントリファイル (INI)

localhost test_bool=true

実行結果

文字列になりました。

TASK [print value] *************************************************************
ok: [localhost] => {
    "msg": "true"
}

TASK [print type] **************************************************************
ok: [localhost] => {
    "msg": "unicode"
}

TRUE は文字列

インベントリファイル (INI)

localhost test_bool=TRUE

実行結果

文字列になりました。

TASK [print value] *************************************************************
ok: [localhost] => {
    "msg": "TRUE"
}

TASK [print type] **************************************************************
ok: [localhost] => {
    "msg": "unicode"
}

True は boolean

インベントリファイル (INI)

localhost test_bool=True

実行結果

booleanになりました。

TASK [print value] *************************************************************
ok: [localhost] => {
    "msg": true
}

TASK [print type] **************************************************************
ok: [localhost] => {
    "msg": "bool"
}

以降、比較のために YAML 形式でも試します。

YAML 形式のインベントリファイルの場合

yes は boolean

イベントリファイル (YAML)

all:
  hosts:
    localhost:
      test_bool: yes

実行結果

INI 形式のインベトリファイルで test_bool=yes と指定したときとは異なり、boolean になりました。

TASK [print value] *************************************************************
ok: [localhost] => {
    "msg": true
}

TASK [print type] **************************************************************
ok: [localhost] => {
    "msg": "bool"
}

vars で定義した場合

yes は boolean

イベントリファイル (INI)

ここでは変数は定義しません。

localhost

./host_vars/localhost.yml

ここに変数定義します。

test_bool: yes
実行結果
TASK [print value] *************************************************************
ok: [localhost] => {
    "msg": true
}

TASK [print type] **************************************************************
ok: [localhost] => {
    "msg": "bool"
}


■ まとめ

INI 形式と YAML 形式で boolean として扱う値の違いについて確認しました。

YAML 形式については、公式ドキュメントの YAML Syntax に記載されている通りyes / no / True / False などでも boolean になります。

一方、INI 形式については、boolean になりそうな値の中では、大文字から始まる True / False が boolean になります。

公式ドキュメントの Working with Inventory には、以下の注意書きがありました。

Values passed in the INI format using the key=value syntax are not interpreted as Python literal structure (strings, numbers, tuples, lists, dicts, booleans, None), but as a string. For example var=FALSE would create a string equal to ‘FALSE’. Do not rely on types set during definition, always make sure you specify type with a filter when needed when consuming the variable.

以下に結果をまとめます。

フォーマット 定義 結果 備考
INI test_bool=yes 文字列
INI test_bool=no 文字列
INI test_bool=true 文字列
INI test_bool=false 文字列
INI test_bool=TRUE 文字列
INI test_bool=FALSE 文字列
INI test_bool=True boolean
INI test_bool=False boolean
YAML test_bool: yes boolean YAML Syntax 通り
YAML test_bool: no boolean YAML Syntax 通り
YAML test_bool: true boolean YAML Syntax 通り
YAML test_bool: false boolean YAML Syntax 通り
YAML test_bool: True boolean YAML Syntax 通り
YAML test_bool: False boolean YAML Syntax 通り
YAML test_bool: yes boolean YAML Syntax 通り