uri モジュール

Ansible には get_url というモジュールがあります。これは指定したURLを取得してターゲットホスト上に保存する機能をもち、ファイルのダウンロードなどに使われます。

似たようなモジュールでより汎用的なものとして uri があります。これはREST APIを叩いたり、WEBの動作確認など様々な使い方ができます。いわゆる curl コマンドのAnsibleモジュール版といっても良いでしょう。汎用HTTPリクエスト機能とも言いかえられるかもしれません。

このモジュールは shell などと同じく、冪等性を考慮していない汎用コマンド系なのでその点は注意が必要です。

公式のサンプルを少し見てみましょう。

Assertモジュールによる「テスト、確認の自動化」とTAP(Test Anything Protocol)

本記事は以下の12日目の記事です。ノウハウの塊です。
https://qiita.com/advent-calendar/2018/ansibleblogger

こっちもおすすめです。
https://qiita.com/advent-calendar/2018/ansible

Ansibleの「自動化の確かさ」ををテストするノウハウも最近ちらほらと出始めました。

このあたりの記事はとても参考になります。

- コードとしてITインフラを定義する――自動化を超えた継続的改善の実現とは
- Molecule入門
- Ansible Playbook の CI をまわす
- GitLab CIでAnsibleの自作モジュールのCIをやってみる

Moleculeはとても良いです。Roleのテストの方向性が固まって来た感があります。インフラCI実践ガイドで取り上げたかったですが、執筆の構想をしたときにはそれほどメジャーではなかったので見送りました（入れておけばよかった・・・

インフラにおけるAnsibleのテストはこんな感じで整理できます。

(1)Role単品のテスト
(2)Roleを組み合わせときのテスト
(3)出来上がった結果を確認するテスト
(4)上記が時間経過や周辺環境の変更があっても動くのかを確認するテスト

(1)はMoleculeでほぼ十分です。(4)に関しては(1, 2, 3)に対してマトリックスを組んでのテストになります。

(2)は現状では少々悩ましいです。問題が出やすいところでもあります。特にチームで開発した場合には、単品のロールとしては完璧でも、組み合わせると矛盾がでるケースがあるからです。Moleculeだけでできるのかもうちょっと研究が必要。

(3)はインテグレーションテストやシステムテストに相当するテストです。ここはテストのシナリオを書いて、独自で実装する必要があります。いわゆるブラックボックステストとして非機能要件やシステムの振る舞いを確認する必要があります。

前置きは長くなりましたが、Ansibleでなにかを確認したいとき、そこで活躍するのが assert モジュールです。
https://docs.ansible.com/ansible/latest/modules/assert_module.html