共通システム管理タスクのためのサービスモジュールの使用

Ansibleは、完全なプレイブックが必要ない場合でも便利です。いくつかのホストでサービスがダウンしている場合や、メンテナンスウィンドウの前にノイズの多いものを無効にする必要がある場合、アドホックコマンドが適切なツールになります。これにより、1回限りの操作のためにYAMLファイルを作成することなく、同じインベントリターゲティングと特権昇格モデルを提供します。

組み込みのserviceモジュールは、システム管理者のツールキットで最も頻繁に使用されるツールの1つです。これは、Systemd、SysVinit、Upstartなどのinitシステム間の違いを抽象化し、多様なLinuxディストリビューション全体でサービスを管理するための標準化された冪等なインターフェースを提供します。このガイドでは、アドホックコマンドのみを介してserviceモジュールを活用し、必須の一般的なシステム管理操作を実行する方法を詳しく説明します。

アドホックコマンドと`service`モジュールの理解

アドホックコマンドは、/usr/bin/ansibleコマンドを使用し、ターゲットグループ（-i）、モジュール（-m）、および引数（-a）を指定する1行の実行です。これらは非永続的であり、プレイブックYAMLファイルに依存しません。

serviceモジュールには、主に2つのパラメーターが必要です。

name: 管理するサービスの名前（例：httpd、nginx、sshd）。
state: 望ましい動作状態（started、stopped、restarted、reloaded）。
enabled（オプション）: サービスがシステム起動時に開始するかどうか（yesまたはno）。

基本的なアドホックコマンド構文

以下のすべての例では、ansibleコマンドを使用しています。サービスの管理には多くの場合root権限が必要なため、-b（become/sudo）フラグはほぼ常に必要です。

ansible <host_pattern> -m service -a "name=<service_name> state=<action> enabled=<yes/no>" -b

注: <host_pattern>をターゲットホストまたはグループ（例：webservers、all）に置き換えてください。

1. サービスが実行中であることを確認する（サービスの開始）

最も一般的なタスクの1つは、重要なサービスが現在アクティブであることを確認することです。state=startedパラメーターは、サービスが停止している場合にAnsibleがそれを開始することを保証します。すでに実行中の場合は、Ansibleは何もしません（冪等性）。

例：すべてのWebサーバーでNginx Webサーバーが実行中であることを確認する

ansible webservers -m service -a "name=nginx state=started" -b

Ansibleがchanged: trueメッセージを返した場合、サービスは停止しており、現在開始されています。changed: falseを返した場合、サービスはすでに実行中でした。

2. サービスの停止

アクティブなサービスを即座に停止するには、state=stoppedを使用します。これは、メンテナンス、依存関係のクリーンアップ、または即時のセキュリティパッチに役立ちます。

例：すべてのデータベースサーバーでPostgreSQLデータベースを停止する

ansible db_servers -m service -a "name=postgresql state=stopped" -b

ヒント: 重要なサービスを停止する場合は、必要に応じてcommandモジュールなどの別のモジュールを使用して確認コマンドを実行し、ステータスを確認してください（例：ansible db_servers -a 'systemctl status postgresql'）。

3. サービスの再起動とリロード

設定ファイルが変更された場合、サービスをグレースフルにリロードするか、強制的に再起動する必要があることがよくあります。serviceモジュールは両方のアクションを処理します。

再起動（`state=restarted`）

再起動には、サービスの完全な停止とその後の開始が含まれます。これは、基盤となるデーモンの動作に影響を与える変更に必要です。

例：すべてのホストでSSHデーモンを再起動する

ansible all -m service -a "name=sshd state=restarted" -b

リロード（`state=reloaded`）

リロードは、サービス（NginxやApacheなど）でサポートされている場合、実行中の接続を中断せずに設定変更を適用します。これは高可用性環境で推奨される方法です。

例：Nginx設定をグレースフルにリロードする

ansible webservers -m service -a "name=nginx state=reloaded" -b

重要: サービスがreloadをサポートしていない場合、結果はサービス管理者とユニット定義によって異なります。一部のユニットはリロード要求を失敗させ、一部はリロードを別のアクションにマッピングし、一部は有用なことを何もしません。本番環境の変更にリロードを依存する前に、サービスのドキュメントを確認してください。

4. サービスの永続性の管理（有効化と無効化）

stateパラメーターは現在のランタイムステータスを制御します。別のenabledパラメーターは、サービスがオペレーティングシステムの起動時に自動的に開始するかどうかを制御します。

サービスが起動時に開始することを確認する（`enabled=yes`）

これは、ホストの再起動後も存続する必要があるミッションクリティカルなサービスにとって重要です。

例：Dockerサービスが有効で実行中であることを確認する

ansible dockernodes -m service -a "name=docker state=started enabled=yes" -b

サービスが起動時に開始しないようにする（`enabled=no`）

これは、システムを保護したり、不要なデフォルトサービスを無効にしたりするためによく使用されます（例：クラウドベースのファイアウォールを使用する場合、組み込みのファイアウォールを無効にする）。

例：デフォルトのFirewalldサービスを無効にする

ansible all -m service -a "name=firewalld state=stopped enabled=no" -b

セキュリティのベストプラクティス: 未使用のサービスがシステムの更新や再起動中に予期せず起動しないように、常にstoppedとenabled=noの両方に設定してください。

5. 高度なサービスタイプとエラーの処理

汎用のserviceモジュールはすべての主要なinitシステムで動作するように設計されていますが、明示的な処理が役立つ、または必要となるシナリオがあります。

汎用モジュールが失敗する場合

まれに、特に古いシステムや高度にカスタマイズされた環境では、汎用のserviceモジュールが正しいinitシステムを検出できない場合があります。Ansibleはそのような場合にシステム固有のモジュールを提供します。

systemd: すべての最新ディストリビューション（CentOS 7+、Ubuntu 15+、Debian 8+）向け。
sysvinit: 古いシステムまたは特殊なディストリビューション向け。

ターゲットがSystemdを使用していることがわかっている場合は、明示的にsystemdモジュールを使用できます。ただし、基本的な操作の場合、その構文は汎用のserviceモジュールと同じです。

# 明示的にsystemdモジュールを使用（機能は'service'と同じ）
ansible servers -m systemd -a "name=chronyd state=started enabled=yes" -b

カスタムスクリプトを使用したサービスの管理

initシステムでネイティブにサポートされていないサービスコマンドを実行する必要がある場合（例：起動時のカスタム環境変数）、完全なプレイブックでserviceモジュールを他のタスクと組み合わせるか、アドホック介入にshellモジュールを使用する必要があるかもしれません。ただし、これにより冪等性が低下します。

# 複雑なサービス操作に'shell'を使用したアドホックコマンドの例（注意して使用）
ansible webservers -a "/usr/bin/my_custom_service_script restart" -b

サービスモジュールアドホックコマンドチートシート

タスク	引数	コマンド例
実行を確認	`state=started`	`ansible all -m service -a "name=apache2 state=started" -b`
サービスを停止	`state=stopped`	`ansible all -m service -a "name=fail2ban state=stopped" -b`
強制再起動	`state=restarted`	`ansible servers -m service -a "name=postfix state=restarted" -b`
グレースフルリロード	`state=reloaded`	`ansible webservers -m service -a "name=httpd state=reloaded" -b`
自動起動を設定	`enabled=yes`	`ansible all -m service -a "name=firewalld enabled=yes" -b`
自動起動を無効化	`enabled=no`	`ansible all -m service -a "name=cups enabled=no" -b`
実行と有効化を確認	`state=started enabled=yes`	`ansible control -m service -a "name=ansible_api state=started enabled=yes" -b`

実際のインシデントのための安全なワークフロー

インシデント中にAnsibleサービスモジュールを使用する場合、コマンド自体は通常簡単な部分です。より難しい部分は、正しいホストをターゲットにし、サービス管理者が何をするかを理解することです。

インベントリの検査から始めます。webserversでNginxを再起動しようとしている場合、そのグループに何が含まれているかを確認します。

ansible-inventory -i inventory.ini --graph webservers

インベントリが動的な場合は、動的ソースに対して同じチェックを実行します。クラウドタグには、移行や一時的なスケーリングイベントの後など、予期しないホストが含まれていることがよくあります。5つのアプリケーションノードで安全なサービス再起動は、リージョン内のすべてのノードでリスクがある場合があります。

次に、同じターゲットに対して読み取り専用コマンドを実行します。

ansible webservers -m command -a "systemctl is-active nginx" -b

これにより、変更を加える前に、接続ユーザー、特権昇格、ホストパターン、およびサービス名が確認されます。DebianとUbuntuでは、Webサービスは通常nginxまたはapache2です。多くのRed Hatファミリーシステムでは、Apacheは通常httpdです。Ansibleモジュールは、パッケージの命名規則を推測できません。

リスクの高いサービスの場合は、最初に--limitを使用します。

ansible webservers --limit web01.example.com -m service -a "name=nginx state=reloaded" -b

それが機能する場合は、小さなグループに拡張し、次に完全なグループに拡張します。アドホックコマンドには、serialを使用したプレイブックのような組み込みのロールアウト構造がないため、意図的に行う必要があります。大規模なフリートの場合、serialを設定し、ヘルスチェックを追加し、失敗時に停止できるため、1つの巨大なアドホックコマンドよりも短いプレイブックの方が安全な場合があります。

state=restartedには注意してください。これは常に再起動を要求するため、changedを報告し、他に何も変更がなくてもサービスを中断します。本当に再起動したい場合には問題ありません。「問題がないことを確認する」ための怠惰な方法として使用するのは無駄です。ルーチンチェックには、state=startedを優先してください。停止したサービスを開始しますが、実行中のサービスはそのままにします。

enabled=yesとenabled=noも同様に注意が必要です。これらは現在のランタイム動作だけでなく、ブート動作も変更します。トラブルシューティング中にこれを実行すると、

ansible all -m service -a "name=firewalld state=stopped enabled=no" -b

ファイアウォールを今停止しただけでなく、システムに再起動後に開始しないように指示したことになります。これは、ホストファイアウォールが意図的に無効にされているクラウド環境では正しいかもしれませんが、セキュリティベースラインに違反する可能性があります。共有運用チームでは、チケットにメモを残すか、プレイブックの変更をコミットして、永続的な決定が表示されるようにします。

systemdで管理されるサービスの場合、ansible.builtin.systemd_serviceモジュールは、daemon_reload、masked、ユーザースコープのサービスなどのsystemd固有のオプションを提供します。汎用のserviceモジュールはポータブルな基本操作には依然として便利ですが、systemd固有の動作が必要になったら、systemdモジュールを直接使用します。

ansible appservers -m ansible.builtin.systemd_service -a "name=myapp state=restarted daemon_reload=true" -b

最後に、常に結果を読み取ります。changed=trueは、Ansibleがモジュールに何かを変更するように要求したことを意味し、アプリケーションがその後正常であることを意味するわけではありません。サービスは正常に再起動し、2秒後に独自のヘルスチェックに失敗する可能性があります。サービスの変更後は、アプリケーションに一致するチェックを実行します。

ansible webservers -m uri -a "url=http://127.0.0.1/health status_code=200"

または、HTTPが利用できない場合：

ansible webservers -m command -a "systemctl is-active nginx" -b

最高のアドホックサービスコマンドは退屈です。つまり、ターゲットが狭く、状態が明確で、特権昇格が含まれ、その直後に確認コマンドが続きます。この習慣により、サービスを迅速に管理する際に発生するほとんどの間違いを防ぐことができます。

アドホックコマンドがプレイブックになるべき時

アドホックコマンドは、高速でコンテキストの少ない作業に最適です。これらは反復可能な操作の代わりにはなりません。同じサービスコマンドをチャットに貼り付け、手動の確認手順を追加し、「最初の2つのホストでこれを実行し、待ってから残りで実行してください」と誰かに伝えていることに気付いた場合、それはすでに存在しようとしているプレイブックです。

プレイブックは、レビュー可能な意図を提供します。

- name: nginxを安全にリロード
  hosts: webservers
  become: true
  serial: 5
  tasks:
    - name: nginx設定を検証
      ansible.builtin.command: nginx -t
      changed_when: false

    - name: nginxをリロード
      ansible.builtin.service:
        name: nginx
        state: reloaded

    - name: ローカルヘルスエンドポイントを確認
      ansible.builtin.uri:
        url: http://127.0.0.1/health
        status_code: 200

同じ操作でもまだシンプルですが、バッチ処理、検証、ヘルスチェックが含まれています。Gitに保存できます。次のメンテナンスウィンドウの前に誰かがレビューできます。また、any_errors_fatal: trueを追加したり、端末を見てプレッシャーの中で判断を下す代わりに、失敗動作を調整したりすることもできます。

クイックスタート、ストップ、チェックにはアドホックserviceコマンドを使い続けてください。操作が顧客向けの可用性を変更する場合、ロールアウト順序が必要な場合、または別の担当者によって繰り返される必要がある場合は、プレイブックに手を伸ばしてください。その線は儀式に関するものではありません。リスクのある部分を可視化することに関するものです。