【無料ツール】画像をPDFに変換するPhotoPDF Appを公開しました!

【Ansible講座 第6回】秘密情報の管理と通知。Ansible Vaultの暗号化とHandlers完全ガイド

そのパスワード、平文のままGitに上げていませんか?

こんにちは!「LINUX工房」管理人の「リナックス先生」です。
前回は、Playbookを「Role」に分割して整理整頓する方法を学びました。

しかし、本格的な構築(特にデータベースやAPI連携)を始めると、必ず直面する問題があります。
「パスワードやAPIキーなどの機密情報をどう扱うか?」です。
Playbookの中に password: "MySecretPass123" とそのまま書いてGitにプッシュしてしまうと、世界中にパスワードを公開することになりかねません。
これは絶対にやってはいけない「セキュリティ・インシデント」です。

コウ君

先生、ドキッとしました…。
実はテスト環境だからいいやと思って、DBのrootパスワードをそのまま書いてました。
あと、Roleを使ってたら「設定変更してないのにApacheが毎回再起動する」ようになっちゃって、なんか遅いんです。
これって直せますか?

リナックス先生

あらあら、コウ君。それは「Ansible Vault」と「Handlers」を理解していない証拠ね。
Ansibleには、パスワードを暗号化して安全に管理する機能と、必要な時だけ再起動を走らせるスマートな通知機能があるの。
今回は、セキュリティと効率性を両立させるための、プロ必須のテクニックを伝授するわよ!

本記事では、AlmaLinux 9 をベースに、機密情報を暗号化する Ansible Vault の操作方法と、Role設計において重要な Handlers (notify) の詳細な挙動について徹底解説します。

🚀 Ansible完全攻略講座(バックナンバー)

現在地:【第6回】秘密情報の管理と通知。Ansible Vaultの暗号化とHandlers


第1章:Ansible Vault(アンシブル・ボールト)とは?

Ansible Vaultは、Ansibleに標準搭載されている「ファイルの暗号化機能」です。
Playbook、変数ファイル、あるいは特定の変数だけをAES256で暗号化できます。

なぜ必要なのか?

Infrastructure as Code (IaC) の原則として、設定ファイルはGitなどでバージョン管理すべきです。
しかし、以下の情報は公開されてはいけません。

  • データベースのパスワード
  • クラウドサービスのAPIキー / シークレットキー
  • SSH秘密鍵
  • SSL証明書の秘密鍵

Ansible Vaultを使えば、これらのファイルを暗号化した状態でリポジトリにコミットできます。
復号するための「Vaultパスワード」を知っている人(またはCI/CDシステム)だけが、Ansibleを実行できるようになります。


第2章:Vaultの基本操作(作成・編集・復号)

まずは、基本的なコマンド操作を覚えましょう。
ansible-vault コマンドを使用します。

1. 暗号化ファイルの作成 (create)

新しく暗号化されたファイルを作成します。

ansible-vault create secret.yml

実行するとパスワードの入力を求められ、その後エディタ(viなど)が開きます。
ここで入力した内容は、保存すると即座に暗号化されます。

2. 暗号化ファイルの中身を見る (view)

暗号化されたファイルを復号して表示します(ファイル自体は暗号化されたまま)。

ansible-vault view secret.yml

パスワードを入力すれば、中身が見れます。
逆に cat secret.yml しても、$ANSIBLE_VAULT;1.1;AES256... という意味不明な文字列しか見えません。

3. 暗号化ファイルを編集する (edit)

ansible-vault edit secret.yml

一時的に復号してエディタを開き、保存時に再暗号化してくれます。
非常に便利です。

4. 既存ファイルを暗号化 / 復号する (encrypt / decrypt)

既に平文で作ってしまったファイルを後から暗号化したい場合。

# 暗号化する
ansible-vault encrypt plain.yml

# 元に戻す(平文にする)
ansible-vault decrypt plain.yml

第3章:【実践】PlaybookでのVault変数の利用

では、実際にWebサーバー構築のPlaybookで、Basic認証のパスワードなどを暗号化して管理してみましょう。

1. 変数ファイルの準備

group_vars/webservers/ ディレクトリに、平文の設定と暗号化の設定を分けて保存するのがベストプラクティスです。

mkdir -p group_vars/webservers/
nano group_vars/webservers/vars.yml

vars.yml (平文):

http_port: 80
server_admin: "admin@example.com"

次に、秘密情報を入れたファイルを作ります。

ansible-vault create group_vars/webservers/vault.yml

vault.yml (暗号化):

db_password: "SuperSecretPassword123!"
api_key: "abcdef123456"

2. Playbookからの参照

Ansibleは group_vars 配下のファイルを自動で読み込みます(暗号化されていても自動で復号を試みます)。
Playbook側では、普通に変数を参照するだけでOKです。

---
- name: Setup Web Server
  hosts: webservers
  tasks:
    - name: Print Secret (Debug)
      ansible.builtin.debug:
        msg: "The DB password is {{ db_password }}"

3. 実行時のパスワード入力

暗号化されたファイルを含むPlaybookを実行する際は、--ask-vault-pass オプションが必要です。

ansible-playbook site.yml --ask-vault-pass

実行時にパスワードを聞かれ、正しければ復号されて処理が進みます。

4. パスワード入力の自動化(パスワードファイル)

毎回パスワードを入力するのは面倒ですし、Cronなどで自動実行できません。
パスワードを記載したファイルを指定する方法があります。

# パスワードを書いたファイルを作成(権限600にする!)
echo "my_vault_password" > .vault_pass
chmod 600 .vault_pass

# ファイルを指定して実行
ansible-playbook site.yml --vault-password-file .vault_pass

💡 ansible.cfg での設定
ansible.cfg にパスワードファイルの場所を書いておけば、オプションも不要になります。

[defaults]
vault_password_file = ./.vault_pass

※ただし、.vault_pass ファイル自体は絶対にGitにコミットしないでください(.gitignore に追加必須)。


第4章:Handlers(ハンドラ)の深層

ここからは話題を変えて、Ansibleのもう一つの重要機能「Handlers(ハンドラ)」について解説します。

Handlersとは何か?

通常のタスク(Tasks)とは違い、「他のタスクから通知(notify)があった時だけ実行される、特別なタスク」のことです。
主に「設定ファイルが変更された時だけ、サービスの再起動を行う」という用途に使われます。

なぜTasksに書いてはいけないのか?

以下のダメな例を見てください。

  tasks:
    - name: Copy config file
      template: src=httpd.conf.j2 dest=/etc/httpd/conf/httpd.conf

    # ダメな例:毎回再起動してしまう
    - name: Restart Apache
      service: name=httpd state=restarted

これだと、設定ファイルが変わっていなくても、Playbookを実行するたびにApacheが再起動してしまいます。
再起動中はサービスが停止するため、無駄なダウンタイムが発生します。
これは「冪等性」の観点からも美しくありません。

正しい書き方 (notify と handlers)

  tasks:
    - name: Copy config file
      template: src=httpd.conf.j2 dest=/etc/httpd/conf/httpd.conf
      notify: Restart Apache  # 変更があった時だけ通知を送る

  handlers:
    - name: Restart Apache
      service: name=httpd state=restarted

notify で指定した名前と、handlers 内のタスク名が一致している必要があります。
これで、「設定ファイルが変更された(Changed)」時だけ通知が飛び、最後に1回だけ再起動が行われます。


第5章:Handlersの高度なテクニック

Handlersは単純に見えて、実は奥が深いです。
実務で役立つテクニックを紹介します。

1. 複数のタスクから1つのHandlerを呼ぶ

httpd.conf を変えた時も、SSL証明書を更新した時も、Apacheを再起動したい。
そんな時は、両方のタスクで同じ notify: Restart Apache を書けばOKです。
Ansibleは通知を記憶しておき、重複を排除して、最後に1回だけハンドラを実行します。

2. listen によるグルーピング

逆に、「1つの通知で複数のハンドラを動かしたい」場合や、「名前を疎結合にしたい」場合は listen を使います。

  tasks:
    - name: Update App Config
      template: ...
      notify: "Restart Web Services"  # 抽象的な名前で通知

  handlers:
    - name: Restart Apache
      service: name=httpd state=restarted
      listen: "Restart Web Services"  # これを聞く

    - name: Restart Nginx
      service: name=nginx state=restarted
      listen: "Restart Web Services"  # これも聞く

これで、1回の通知でApacheとNginxの両方を再起動できます。

3. flush_handlers で即時実行させる

ハンドラは通常、「全てのタスクが終わった一番最後」に実行されます。
しかし、「設定変更して再起動した後に、その新しい設定で疎通確認をしたい」という場合、最後まで待たれると困ります。

そんな時は meta: flush_handlers を使います。

  tasks:
    - name: Update Config
      template: ...
      notify: Restart Apache

    # ここで溜まっているハンドラを強制的に実行させる!
    - name: Flush handlers
      meta: flush_handlers

    - name: Check Health
      uri: url=http://localhost/ ...

第6章:RoleにおけるHandlersの配置

Roleを使っている場合、Handlersはどこに書くべきでしょうか?
答えは roles/role_name/handlers/main.yml です。

Role内での定義

# roles/apache/handlers/main.yml
- name: Restart Apache
  service:
    name: httpd
    state: restarted

Role内での呼び出し

# roles/apache/tasks/main.yml
- name: Configure httpd
  template: ...
  notify: Restart Apache

Role内に書かれたハンドラは、そのRoleが読み込まれた時に自動的に有効になります。
非常にスッキリと管理できます。


まとめ:守りと攻めの両立

お疲れ様でした!
今回は、Ansible運用における「守り(セキュリティ)」と「攻め(効率的な制御)」の両方を強化しました。

今回の重要ポイント:

  • 機密情報は ansible-vault で暗号化してGit管理する。
  • パスワードファイルを使えば、自動化(Cron/CI)も可能。
  • 再起動などの処理は tasks ではなく handlers に書き、notify で呼ぶ。
  • flush_handlers を使えば、ハンドラの実行タイミングを制御できる。

これで、Ansibleの主要な機能はほぼ網羅しました。
インベントリ、Playbook、変数、テンプレート、Role、そしてVaultとHandlers。
これらを組み合わせれば、どんな複雑なシステムでもコード化できます。

次回、第7回はいよいよ実践編です。
「実践演習。LAMP環境(Apache+MySQL+PHP)をボタン一つで構築する」
これまで学んだ知識を総動員して、WordPressが動く環境をゼロから全自動で構築するPlaybook(Role構成)を作成します。
集大成となる実践演習、ぜひ挑戦してください!

▼ セキュリティ意識の高い環境を作る ▼

Vaultを実験する
「VPS」で自分専用環境

おすすめVPSを見る

DevSecOpsスキルを年収に
「ITエンジニア転職」

転職エージェントを見る

コメント