自宅環境をAnsibleで管理し始めると、環境構築は劇的に楽になります。しかし、長く運用を続けていると、ある一つの課題に直面することがあります。

それは、一度入れたデーモン類をどうやって消すかという問題です。

Ansibleは「あるべき状態」を定義するツールですが、「以前入れたデーモンを完全に消去した状態」を定義するのは、構築するよりも手間がかかります。

本稿では、私が自宅環境で実践しているデーモンの捨て方に関する運用ルールを共有します。

はじめに：Ansibleにおける削除の難しさ

Ansibleでデーモンをインストールする場合、Playbookを実行すれば一瞬で完了します。しかし、それを削除しようとすると、以下のような作業が必要になります。

これらを網羅した削除用Playbookを作るのは、構築以上の工数がかかります。かといって、手動でサーバーに入ってコマンドを叩いて消すのも完璧にやるのは困難です。

そこで、「きれいに消す」ことよりも「管理をシンプルに保つ」ことに主眼を置き、アプローチを考えてみました。

方針：管理対象を「アプリ」と「システム」に分ける

すべてのツールを一律にAnsibleのRoleで管理するのではなく、性質に応じて2つの層に分類しました。

分類	対象	管理手法	Ansibleの役割
1. アプリ層	Webサーバ、DB、Wiki等のアプリケーション	Docker Compose	定義ファイルの配置と起動のみ
2. システム層	Docker本体、監視Agent (Node Exporter等)	OS直下	コミュニティRole等で標準インストール

それぞれの層について、具体的な運用ルールを定めます。

Webサーバーやデータベースなど、コンテナ化が容易なものは Docker Compose で管理します。

ここでの最大のポイントは、Ansibleタスク内で docker_container モジュールを使って個別のコンテナ定義を書かないことです。 Ansibleは docker-compose.yml を運んで、起動コマンドを叩くだけの役割に徹します。

Ansibleの docker_container モジュールは便利ですが、これを使ってポート、ボリューム、環境変数などを細かくタスク内に定義してしまうと、Playbookが肥大化し、Ansibleへの依存度が高くなりすぎます。

そうではなく、定義はすべて docker-compose.yml として独立させ、Ansible側では community.docker.docker_compose_v2 モジュールを使って「ファイルパスを指定して起動するだけ」にします。

こうすることで、以下のメリットが生まれます。

アプリが不要になった場合は、無理にAnsibleで削除タスクを流さず、以下の手順で対応します。

コンテナイメージについては、定期的に docker system prune を実行するCronジョブなどを設定し、使われていないものを自動的に掃除させるのが効率的です。

「Docker Engine自体」や「システム監視エージェント」など、コンテナ基盤に関わるデーモン類はOS直下にインストールします。これらは、Ansible Galaxy等で公開されている品質の高いコミュニティRoleを利用する前提です。

システム層のデーモン類が不要になった場合は、以下の手順とします。

コミュニティRoleを使ってインストールした場合、設定ファイルがシステム内の様々な場所に配置されます。これを手動で完全に削除して回るのはコストが見合いません。
サービスさえ停止していればリソース消費はありませんので、設定ファイルの残骸については許容するという割り切りをしています。

もし、ゴミファイルが増えすぎて管理に支障が出るようであれば、OSごと再インストールします。手順がコード化（IaC）されているため、OSの再構築も比較的低コストで行えるのが強みです。

これまでの内容をフローにまとめると以下のようになります。

特に個人運用では、Ansibleですべての状態を厳密に制御するのは面倒すぎて非現実的だと思います。これくらいの温度感なら無理なく運用し続けられるのではないでしょうか。