はじめに
2020/07/28 に A10ネットワークス株式会社さん主催の「【リモート勉強会】第2回:AnsibleでA10 Thunder のADC機能を設定しよう!(基礎編)」に参加させていただきました。
第1回が好評だっため、同じ内容で再度開催されたとのことです。実際私も第1回に参加した人からのススメもあって今回参加しました。
資料や、環境、Q&Aの体制が整っていて、実際にハンズオンができてとても有意義な勉強会でした。
この記事では、この勉強会通して学んだことのうち、特に知れてかったポイントなどをまとめます。
使用テキスト
使用されたテキストはこちらです。
LB としての基本的な設定を少しずつ Playbook を使って設定していく流れです。
Playbook のサンプルや解説はもちろん、実行ログや Thnder 側での確認手順なども詳細に書かれて、操作に迷うところはありませんでした。
基本は Collection モジュールを使用する
Ansible 本体にも、a10_*
モジュールがありますが、これらは基本的に利用されないようです。
これまでもいくつかサンプルを見て察しがついていたのですが、代わりに以下の collection を利用するのが良いようです。
環境
README.md
にもあるように、各種 PATH
が設定されていました。
[root@ansible playbook]# ansible-config dump --only-changed DEFAULT_ACTION_PLUGIN_PATH(env: ANSIBLE_ACTION_PLUGINS) = [u'/root/.ansible/collections/ansible_collections/a10/acos_axapi/plugins/action'] DEFAULT_CLICONF_PLUGIN_PATH(env: ANSIBLE_CLICONF_PLUGINS) = [u'/root/.ansible/collections/ansible_collections/a10/acos_cli/plugins/cliconf'] DEFAULT_TERMINAL_PLUGIN_PATH(env: ANSIBLE_TERMINAL_PLUGINS) = [u'/root/.ansible/collections/ansible_collections/a10/acos_cli/plugins/terminal']
a10.acos_axapi
のモジュールの ansible_host
オプションなどは省略可能
テキストでは、以下のように ansible_host
や ansible_username
といった接続に関わるオプションが各タスクごとに指定されていました、(引用元)
- name: Configure virtual server a10_slb_virtual_server: ansible_host: "{{ ansible_host }}" ansible_port: "{{ ansible_port }}" ansible_username: "{{ ansible_username }}" ansible_password: "{{ ansible_password }}" name: "vip1" ip_address: "10.0.1.100" port_list: - port_number: "80" protocol: "http" service_group: "sg1" pool: "p1" state: present
タスクごとに指定するのは、冗長だと思って楽にできる方法ががあるか質問したところ、実はインベントリファイルの変数設定さえあれば、タスク側は指定不要とご回答いただきました。 テキストではわかりやすさのため指定しているとのこと。
つまり上記の例では、以下のように書けます。
- name: Configure virtual server a10_slb_virtual_server: name: "vip1" ip_address: "10.0.1.100" port_list: - port_number: "80" protocol: "http" service_group: "sg1" pool: "p1" state: present
あとで、この README.md
を確認したらちゃんと書いてありました。
If you want to use an Inventory file to perform respective configurations through a playbook, you don't need to specify ansible_host, ansible_username, ansible_password and ansible_port in the playbook.
a10_write_memory
は毎回 changed
になる
running-config
を startup-config
に保存する a10_write_memory
というモジュールがあります。
このモジュールは実行のたびに毎回 changed
になります。設定の「定義」ではなく、write memory
という「操作」なので、そうなのだろうなと思います。
一方で、他の設定定義系のモジュールの多くは冪等性があるようです。そのため、もし、設定変更時のみ write memory
したい場合は、handlers
を組みわせることになると思います。
部分宣言的な定義
Virtual-Serverを構成するPlaybookの作成
のところで、以下のような説明がありました。
既存のport_list設定(port 80 http)を残す場合は、必ずPlaybookに記述する必要があります。 記述がない場合は、既存のport設定が消えて新規の(Playbook内に記述された)port設定のみが設定される形になります。
つまりもともと port 80 http
がある状態で、以下のように port 443 https
のみの port_list
にした場合、 port 80 http
が消えて port 443 https
のみになるということです。
port_list: - port_number: "443" protocol: "https" service_group: "sg1" pool: "p1" template_client_ssl: "ssl1"
このような挙動を取るものを、私は勝手に部分宣言的な定義と呼んでいます。
Network Resource Module でいう state: overridden
や state: replace
のような動きですね。
注意が必要な一方で、あるべき姿を宣言する形(引き算を考えなくていい)便利だと思います。
構造化データの取得には state: noop
各モジュールの state
オプションは present
や absent
の他にも noop
という値も指定できます。
get_type
オプションを併せて使うと、構造化データで結果を取得できるそう。
参考
a10.acos_cli.acos_command
モジュールは設定変更もできる
(これはテキストには出てこず、Q&Aのやりとりをきっかけに調べました)
私がこれまで見てきた *_command
モジュールは、主に show
コマンド用です。例えば、 ios_command
モジュールで、configure terminal
してなにか設定変更系コマンドを指定しても正常に実行できません。
一方で、a10.acos_cli.acos_command
モジュールでは、設定変更もできるようです。
例えば、以下のような例がモジュール内のドキュメントに記載されています。
- name: Run multiple sequential commands on ACOS device a10.acos_cli.acos_command: commands: - command: configure - command: slb template http test1 - command: write memory - command: end
ただ、実際は、a10.acos_cli.acos_config
モジュールのほうが、設定変更に特化した機能が多いため、a10.acos_cli.acos_config
のほうが設定変更に適していると思います。
a10.acos_cli.acos_command
モジュールは内部で show running-config
を実行する
(こちらもテキストには出てこず、Q&Aのやりとりをきっかけに調べました)
前述のように、設定変更もできることに起因するようですが、a10.acos_cli.acos_command
モジュールは内部で show running-config
を実行するようです。
事前事後のコンフィグの差分を確認し、差分があれば chenged
にする、という処理がありました、
これだけ聞くと、あぁそうなのか、という感じですが、気にしないといけないのは権限です。
show running-config
を実行するには、enable
する必要があります。ということは、相応の設定が必要になります。 enable
パスワードが空なのであれば、空であるという指定 ansible_become_password=""
が必要です。場合によっては。ansible_become_method=enable
も併せて必要になるケースもあるようです。
試せていませんが、使用しているユーザーが特権ユーザーであれば become 系は不要なのかなと予想しています。
おわりに
親切なテキストと、十分な環境、的確な回答をいただける Q&A が揃っていて、とても安心して作業できました。 もしまた開催されたらおすすめできる内容でした。
ありがとうございました。
おまけ
おかげさまで時間内にすべて終わりました。最後は HTTPSのVirtual-Serverの構成 です。
記念の動作確認 GIF です。LB で SSL を終端しつつラウンドロビンしています。(Firefox の Ctrl+F5 (スーパーリロード) しています)