自宅環境をAnsibleで管理し始めると、環境構築は劇的に楽になります。しかし、長く運用を続けていると、ある一つの課題に直面することがあります。
それは、一度入れたデーモン類をどうやって消すかという問題です。
Ansibleは「あるべき状態」を定義するツールですが、「以前入れたデーモンを完全に消去した状態」を定義するのは、構築するよりも手間がかかります。
本稿では、私が自宅環境で実践しているデーモンの捨て方に関する運用ルールを共有します。
はじめに：Ansibleにおける削除の難しさ
Ansibleでデーモンをインストールする場合、Playbookを実行すれば一瞬で完了します。しかし、それを削除しようとすると、以下のような作業が必要になります。
- 配布された設定ファイルのパスを特定して削除タスクを書く
- 作成されたユーザーやグループを削除する
- 依存関係で入ったライブラリを特定する
これらを網羅した削除用Playbookを作るのは、構築以上の工数がかかります。かといって、手動でサーバーに入ってコマンドを叩いて消すのも完璧にやるのは困難です。
そこで、「きれいに消す」ことよりも「管理をシンプルに保つ」ことに主眼を置き、アプローチを考えてみました。
方針：管理対象を「アプリ」と「システム」に分ける
すべてのツールを一律にAnsibleのRoleで管理するのではなく、性質に応じて2つの層に分類しました。
| 分類 | 対象 | 管理手法 | Ansibleの役割 |
|---|---|---|---|
| 1. アプリ層 | Webサーバ、DB、Wiki等のアプリケーション | Docker Compose | 定義ファイルの配置と起動のみ |
| 2. システム層 | Docker本体、監視Agent (Node Exporter等) | OS直下 | コミュニティRole等で標準インストール |
それぞれの層について、具体的な運用ルールを定めます。
1. アプリケーション層：Docker Composeへ管理を委譲する
Webサーバーやデータベースなど、コンテナ化が容易なものは Docker Compose で管理します。
ここでの最大のポイントは、Ansibleタスク内で docker_container モジュールを使って個別のコンテナ定義を書かないことです。 Ansibleは docker-compose.yml を運んで、起動コマンドを叩くだけの役割に徹します。
なぜdocker_containerモジュールを使わず、Composeファイルにするのか
Ansibleの docker_container モジュールは便利ですが、これを使ってポート、ボリューム、環境変数などを細かくタスク内に定義してしまうと、Playbookが肥大化し、Ansibleへの依存度が高くなりすぎます。
そうではなく、定義はすべて docker-compose.yml として独立させ、Ansible側では community.docker.docker_compose_v2 モジュールを使って「ファイルパスを指定して起動するだけ」にします。
こうすることで、以下のメリットが生まれます。
- Ansibleがない環境でも、ファイルさえあれば
docker compose upで再現できる（ポータビリティが高い） - コンテナの構成変更は
docker-compose.ymlの書き換えだけで済み、Ansibleのタスク変更が最小限になる - 削除時の影響範囲が明確になる
コンテナ削除の運用
アプリが不要になった場合は、無理にAnsibleで削除タスクを流さず、以下の手順で対応します。
- サーバー上で
docker compose downを手動実行する（もしくはDockgeで非アクティブ化する） - Ansibleの定義を削除する
コンテナイメージについては、定期的に docker system prune を実行するCronジョブなどを設定し、使われていないものを自動的に掃除させるのが効率的です。
2. システム層：OS直下の設定は深追いしない
「Docker Engine自体」や「システム監視エージェント」など、コンテナ基盤に関わるデーモン類はOS直下にインストールします。これらは、Ansible Galaxy等で公開されている品質の高いコミュニティRoleを利用する前提です。
OS直下のデーモンのアンインストール運用
システム層のデーモン類が不要になった場合は、以下の手順とします。
- サーバー上で
systemctl stopおよびdisableを実行する - Ansibleの定義を削除する
残存ファイルは許容する
コミュニティRoleを使ってインストールした場合、設定ファイルがシステム内の様々な場所に配置されます。これを手動で完全に削除して回るのはコストが見合いません。
サービスさえ停止していればリソース消費はありませんので、設定ファイルの残骸については許容するという割り切りをしています。
もし、ゴミファイルが増えすぎて管理に支障が出るようであれば、OSごと再インストールします。手順がコード化（IaC）されているため、OSの再構築も比較的低コストで行えるのが強みです。
まとめ：完璧さを求めない現実的な運用
これまでの内容をフローにまとめると以下のようになります。
特に個人運用では、Ansibleですべての状態を厳密に制御するのは面倒すぎて非現実的だと思います。これくらいの温度感なら無理なく運用し続けられるのではないでしょうか。