Ansibleのクイックタスクに必須のアドホックコマンドを使いこなす

Ansibleのアドホックコマンドを使用すると、1つのホストまたはグループ全体に対して、1つのクイックタスクを実行できます。アクセステスト、ディスク容量の確認、ファイルのコピー、サービスの再起動、ファクトの調査など、プレイブックを作成せずに済む場合に便利です。

これらはプレイブックの代替ではありません。即時の作業に使用し、繰り返し行うタスクやリスクのあるタスクは、バージョン管理された自動化に移行してください。

基本的なコマンド構造

アドホックコマンドは次の形式に従います。

ansible <パターン> -m <モジュール名> -a "<モジュール引数>" [オプション]

ホストパターンはインベントリのターゲットを選択します。モジュールはAnsibleが何を行うかを決定します。引数はモジュール固有の値を渡します。

一般的なオプションは次のとおりです。

• -i <インベントリ> または --inventory <インベントリ>: 特定のインベントリファイルまたはインベントリソースを使用します。
• -u <ユーザー> または --user <ユーザー>: 特定のリモートユーザーとして接続します。
• -b または --become: 特権昇格（通常はsudo）を使用します。
• -k または --ask-pass: SSHパスワードを要求します。
• -K または --ask-become-pass: sudoパスワードを要求します。
• --limit <サブセット>: 選択したホストをさらに絞り込みます。

-i を指定しない場合、Ansibleは設定されたインベントリを使用します。多くのシステムでは /etc/ansible/hosts ですが、ansible.cfg で変更できます。

ping でアクセスをテストする

ping モジュールはICMPエコーパケットを送信しません。Ansibleの通常のトランスポートを介して接続し、ターゲット上で小さなモジュールを実行し、pong が返ってくることを期待します。

ansible all -m ping

グループに対して:

ansible webservers -m ping

成功した結果は次のようになります。

web01.example.com | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

これが失敗した場合は、高レベルのタスクのトラブルシューティングを行う前に、インベントリ、DNS、SSHキー、リモートユーザー、sudo設定、Pythonの可用性を修正してください。

command でシンプルなコマンドを実行する

command モジュールは、リモートホスト上でプログラムを直接実行します。シェルを起動しないため、パイプ、リダイレクト、グロブ展開、$VARIABLE 展開は、ターミナルでのようには機能しません。

稼働時間を確認:

ansible webservers -m command -a "uptime"

ディスク使用量を確認:

ansible all -m command -a "df -h"

sudoで保護されたディレクトリを一覧表示:

ansible dbservers -m command -a "ls -l /var/log" --become

シェル機能が必要ない場合は、最初に command を使用してください。推論が容易で、偶発的なシェル解釈を回避できます。

シェル機能が必要な場合のみ shell を使用する

shell モジュールは、リモートホスト上のシェルを介してコマンドを実行します。パイプ、リダイレクト、変数展開、シェルの条件分岐に使用します。

最大のログディレクトリを検索:

ansible databases -m shell -a "du -sh /var/log/* | sort -rh | head -n 5"

リモートの環境変数を確認:

ansible all -m shell -a "printf '%s\n' \"$PATH\""

動的な入力には注意してください。ユーザーが提供した値が引用符や検証なしでシェルコマンドに挿入されると、コマンドインジェクションのバグが発生する可能性があります。

ファイル編集には、シェルリダイレクトではなく、目的に特化したモジュールを使用することをお勧めします。たとえば、lineinfile で管理対象の行を追加します:

ansible webservers -m lineinfile -a "path=/etc/app/app.conf line='feature_enabled=true' create=yes" --become

これは echo ... >> file で追加するよりも安全で再現性があります。

copy でファイルをコピーする

copy モジュールは、コントロールノードから管理対象ホストにファイルを転送します。

ansible webservers -m copy -a "src=./myscript.sh dest=/tmp/myscript.sh mode=0755"

root所有権が必要な設定ファイルをコピー:

ansible all -m copy -a "src=./app.conf dest=/etc/app/app.conf owner=root group=root mode=0644" --become

宛先に同じ内容とメタデータが既に存在する場合、Ansibleは変更なしと報告します。

file でパスを管理する

file モジュールを使用して、ディレクトリの作成、パスの削除、所有権の設定、パーミッションの設定、シンボリックリンクの作成を行います。

ディレクトリを作成:

ansible appservers -m file -a "path=/opt/my_app state=directory mode=0755 owner=app group=app" --become

古いファイルを削除:

ansible host1 -m file -a "path=/tmp/old_file.txt state=absent"

シンボリックリンクを作成:

ansible appservers -m file -a "src=/opt/my_app/releases/current dest=/opt/my_app/current state=link"

setup でファクトを収集する

setup モジュールは、OS、ネットワーク、CPU、メモリ、デバイスの詳細など、ホストに関するファクトを収集します。

1つのホストからすべてのファクトを収集:

ansible webserver1 -m setup

小さな部分だけが必要な場合にファクトをフィルタリング:

ansible all -m setup -a "filter=ansible_distribution*"

出力は大きくなる可能性があるため、フィルタリングによりトラブルシューティングが読みやすくなります。

アドホックコマンドとプレイブックの使い分け

アドホックコマンドは、クイックチェックや1回限りのタスクに使用します。

• ping で接続性をテスト。
• command で状態を確認。
• copy で既知のファイルを1つコピー。
• file で1つのパスを作成または削除。
• トラブルシューティング中に setup でファクトを収集。

タスクが繰り返し行われる、複数のステップからなる、チームメイトによるレビューが必要、またはバージョン管理と予測可能な構造が必要なほどリスクが高い場合は、プレイブックを使用します。

実行前の安全確認

破壊的な操作を実行する前に、ホストパターンを確認します。

ansible webservers --list-hosts

影響範囲を小さくしたい場合は --limit を使用します。

ansible all --limit web01.example.com -m ping

command と shell は自動的に冪等性があるわけではないことに注意してください。useradd deploy のようなコマンドは、防御的に記述しない限り、2回目の実行で失敗する可能性があります。user、file、copy、lineinfile などのモジュールは、通常、より安全な繰り返し動作を提供します。

まとめ

Ansibleのアドホックコマンドは、迅速で的を絞った操作に最適です。ping から始め、シンプルなチェックには command を使用し、実際のシェル構文が必要な場合にのみ shell を予約し、copy、file、lineinfile、setup などのモジュールをジョブに適している場合は優先的に使用します。