【Ansible講座 第5回】コードを整理整頓。Rolesディレクトリ構成と再利用性の最大化完全ガイド

そのPlaybook、半年後の自分が見て理解できますか？

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、変数とテンプレートを使って、環境ごとに設定ファイルを自動生成する高度なPlaybookを作成しました。

しかし、高機能になればなるほど、site.yml の行数は増えていきます。
「Apacheのインストール」「ユーザー作成」「ファイアウォール設定」「DB構築」…これら全てを1つのファイルに書き続けると、あっという間に1000行を超え、「どこに何が書いてあるか分からない」「怖くて触れない」スパゲッティコードが出来上がります。

先生、図星です…。
前回のPlaybookにMySQLの設定も追加したら、もうスクロールするのが大変で。
それに、別のプロジェクトでもApacheの設定を使いたいんですけど、またコピペするの面倒だなって思ってました。
もっとスマートに管理する方法はないんですか？

それこそが、今回のテーマ「Role（ロール）」よ。
Roleを使えば、Playbookを「Webサーバー機能」「DBサーバー機能」といった部品（パーツ）に分解して整理できるの。
一度作った部品は、他のプロジェクトでも使い回せるし、誰か（世界中のエンジニア）が作った部品を取り込むこともできるわ。
今回は、Ansibleにおける「整理整頓の最終形態」をマスターしましょう！

本記事では、AlmaLinux 9 をベースに、Roleのディレクトリ構造の規格、既存のPlaybookをRole化するリファクタリング手順、そして世界中のRole共有サービス「Ansible Galaxy」の活用法までを徹底解説します。

第1章：Role（ロール）とは何か？

Role（ロール）とは、一言で言えば「Playbookを機能単位で分割・構造化したディレクトリ群」のことです。
「役割（Role）」という名前の通り、サーバーが担う役割ごとにタスクや変数をパッケージ化します。

Role化のメリット

• 可読性向上: 1つのファイルが短くなり、どこに何が書いてあるか明白になります。
• 再利用性: 「Webサーバー構築セット」としてRoleを作っておけば、別のプロジェクトでも import_role 一発で使い回せます。
• 分業が容易: 「AさんはWeb担当、BさんはDB担当」のように、並行して開発しやすくなります。

ディレクトリ構造の「規格」

Roleは、ディレクトリ名やファイル名が厳格に決められています。
Ansibleは、この規格に従って配置されたファイルを自動的に読み込みます。

roles/
  common/               # 全サーバー共通設定用のRole
    tasks/main.yml      # 処理内容（必須）
    handlers/main.yml   # ハンドラ
    templates/          # テンプレートファイル
    files/              # 静的ファイル
    vars/main.yml       # 変数定義
  web/                  # Webサーバー用のRole
    tasks/main.yml
    ...

第2章：Roleの雛形作成（ansible-galaxy init）

このディレクトリ構造を手動で作るのは大変です。
ansible-galaxy コマンドを使うと、ベストプラクティスに基づいた雛形を一瞬で作成できます。

1. rolesディレクトリの作成

まず、プロジェクトのルートに roles ディレクトリを作ります。

mkdir roles
cd roles

2. Roleの初期化

apache という名前のRoleを作ってみましょう。

ansible-galaxy init apache

これで roles/apache/ 配下に多数のディレクトリが生成されます。

各ディレクトリの役割

※不要なディレクトリ（tests, README.mdなど）は削除しても構いません。

第3章：【実践】既存Playbookのリファクタリング

それでは、前回（第4回）作成した「Webサーバー構築Playbook」を、Roleを使った構成に書き換えてみましょう。

移行前の Playbook (site.yml)

これが「スパゲッティの元」です。

---
- name: Setup Web Server
  hosts: webservers
  vars:
    http_port: 80
  tasks:
    - name: Install Apache
      ansible.builtin.dnf:
        name: httpd
        state: present
    - name: Deploy config
      ansible.builtin.template:
        src: templates/httpd.conf.j2
        dest: /etc/httpd/conf/httpd.conf
      notify: Restart Apache
  handlers:
    - name: Restart Apache
      ansible.builtin.systemd:
        name: httpd
        state: restarted

Step 1: タスクの移動 (roles/apache/tasks/main.yml)

tasks: の中身を、Role側の tasks/main.yml に移動します。
※インデントの深さに注意してください（リストの - が行頭に来ます）。

---
# roles/apache/tasks/main.yml
- name: Install Apache
  ansible.builtin.dnf:
    name: httpd
    state: present

- name: Deploy config
  ansible.builtin.template:
    src: httpd.conf.j2   # パスが変わる！ templates/ は不要
    dest: /etc/httpd/conf/httpd.conf
  notify: Restart Apache

ポイント： template モジュールの src は、自動的に roles/apache/templates/ を探しに行くため、単にファイル名を書くだけでOKです。

Step 2: ハンドラの移動 (roles/apache/handlers/main.yml)

handlers: の中身を移動します。

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

Step 3: テンプレートの移動

httpd.conf.j2 ファイルを、roles/apache/templates/ ディレクトリの中に移動します。

Step 4: 親Playbook (site.yml) の書き換え

中身を全部吸い出したので、親ファイルはこんなにスッキリします。

---
# site.yml
- name: Setup Web Server
  hosts: webservers
  become: true
  
  roles:
    - apache

たったこれだけです！
「webserversグループに対して、apacheロールを適用する」という意図が明確になりました。

PR

［改訂第4版］Linuxコマンドポケットリファレンス (Pocket reference) 新品価格 ￥3,080から (2026/5/30 09:52時点)

第4章：Roleの変数管理（defaults vs vars）

Role内で使う変数をどこに定義するかは、重要な設計ポイントです。
Roleには defaults/main.yml と vars/main.yml の2つの場所があります。

defaults/main.yml （推奨）

ここに定義した変数は「優先順位が最も低い」です。
つまり、「デフォルト値」として機能し、インベントリ変数（group_vars）やPlaybook変数で簡単に上書きできます。

# roles/apache/defaults/main.yml
http_port: 80

こうしておけば、使う側が「開発環境だから8080にしたい」と思った時に、group_vars/dev.yml で http_port: 8080 と書くだけで上書きできます。
汎用的なRoleを作るなら、変数は defaults に書きましょう。

vars/main.yml

ここに定義した変数は「優先順位が高い」です（インベントリ変数より強い）。
「Roleの内部ロジックに関わる定数」など、外部から変更されたくない値に使います。

第5章：Ansible Galaxyで「巨人の肩」に乗る

Roleの仕組みが素晴らしいのは、世界中のエンジニアが作った高品質なRoleを共有できるエコシステムがあるからです。
それが Ansible Galaxy です。

Ansible Galaxyとは？

https://galaxy.ansible.com/
Docker HubのAnsible版のようなものです。
例えば「MySQLのチューニング済み設定を入れたい」と思ったら、自分で書く前にここを探します。

Roleのインストール

最も有名なRole作者の一人、Jeff Geerling氏のMySQL Roleを入れてみましょう。

ansible-galaxy install geerlingguy.mysql

これだけで ~/.ansible/roles/ (または設定したパス) にダウンロードされます。

ダウンロードしたRoleの使い方

自分のPlaybookから呼び出すだけです。

roles:
  - role: geerlingguy.mysql
    vars:
      mysql_root_password: "super_secure_password"

変数を上書きするだけで、プロが書いた何千行もの処理を利用できます。
「車輪の再発明」をしないのが、優秀なエンジニアの鉄則です。

# requirements.yml
- src: geerlingguy.mysql
- src: geerlingguy.apache

第6章：ディレクトリ構成のベストプラクティス

Roleを使った場合の、プロジェクト全体のディレクトリ構成例です。
この形を目指して整理していきましょう。

project_root/
├── ansible.cfg
├── inventory/
│   ├── production.yml
│   └── staging.yml
├── group_vars/
│   ├── all.yml
│   └── webservers.yml
├── roles/
│   ├── common/       # 全サーバー共通（ユーザー作成、時刻設定など）
│   ├── apache/       # Webサーバー用
│   └── mysql/        # DBサーバー用
├── site.yml          # 全体のエントリーポイント
└── requirements.yml  # Galaxy Role一覧

site.yml の書き方例

---
# 1. 全サーバー共通設定
- name: Apply Common Config
  hosts: all
  become: true
  roles:
    - common

# 2. Webサーバー設定
- name: Setup Web Servers
  hosts: webservers
  become: true
  roles:
    - apache

# 3. DBサーバー設定
- name: Setup DB Servers
  hosts: dbservers
  become: true
  roles:
    - mysql

このように、役割ごとにPlayを分けて記述することで、サーバー構成全体がひと目で分かるようになります。

まとめ：Roleは資産である

お疲れ様でした！
PlaybookをRole化することで、コードの見通しが良くなり、再利用性が飛躍的に向上しました。

今回の重要ポイント：

• RoleはPlaybookを機能単位で部品化したもの。
• tasks, handlers, templates などのディレクトリ名には決まりがある。
• 変数は defaults/main.yml に書くと、利用者が上書きしやすい。
• Ansible Galaxyを使えば、他人の作った高品質なRoleを利用できる。

これで、大規模なシステム構築にも耐えうる土台ができました。
しかし、実運用に入ると新たな問題が発生します。
「DBのパスワード」や「APIキー」といった機密情報を、Playbook（テキストファイル）にそのまま書いてGithub等に上げてしまうと、セキュリティ事故になります。

次回、第6回は「秘密情報の管理と通知。Ansible Vaultの暗号化とHandlers」です。
パスワードなどの機密情報を暗号化して管理する Ansible Vault の使い方と、Role化の際に見落としがちな Handlers の高度な制御について解説します。
セキュリティも万全にしてこその自動化です。お楽しみに！