Ansible 2.10以降を使い始めると、こういった疑問を抱く方が多くいます。
この変化は一時的な仕様変更ではありません。Ansible CollectionsとFQCN(Fully Qualified Collection Name)は、Ansible全体のモジュール体系を整理した根本的なアーキテクチャ改革です。ansible-lintでの警告への対応だけでなく、外部Collectionの導入や自動化コードの保守性にも直結する重要な概念です。
この記事では、CollectionsとFQCNの基本的な概念から、
ansible.builtin名前空間の使い方、community.generalなどの外部Collection導入手順、そしてPlaybookへの実装パターンまでを解説します。単なるコマンドリファレンスではなく、ansible-lintの警告を解消しながらモダンな記法に移行するための実践的な設計視点を重点的に扱います。実行環境はRHEL 10 / Rocky Linux 9です。この記事のポイント
・FQCNは「名前空間.コレクション名.モジュール名」の3パート形式でAnsible 2.10から標準化された
・ansible.builtinは追加インストール不要の組み込みコレクションでcopy/file/serviceなどが含まれる
・外部CollectionはCollection単位でインストールしrequirements.ymlで宣言管理できる
・ansible-lintのfqcn警告はモジュール名をFQCN形式に書き直すことで解消できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
CollectionsとFQCNが生まれた背景|Ansible 2.10のモジュール体系再編
Ansible 2.9以前は、数千のモジュールがすべてansible/modules/ というフラットな単一名前空間に詰め込まれていました。copyやuser、ec2_instanceが同じ場所に並ぶ構造で、モジュール数の増加に伴ってメンテナンスが困難になっていました。特定クラウドサービスのモジュールをアップデートするためにAnsible全体のリリースを待つ必要があり、開発サイクルの柔軟性が欠けていたのです。2020年にリリースされたAnsible 2.10でこの構造が根本から見直されました。モジュールが機能・用途別の「Collection」という単位にまとめられ、Ansibleコア(ansible-core)と分離してリリースされるようになりました。
・ansible-core:Playbook実行エンジン+ansible.builtinコレクションのみを含む最小パッケージ
・ansible(パッケージ):ansible-coreに多数のコミュニティCollectionを同梱した配布パッケージ
この再編によって、各CollectionがAnsibleコアとは独立したリリースサイクルを持てるようになりました。AWS・GCP・Azure向けのCollectionが新しいクラウドサービスへの対応を素早く反映できるようになったのは大きなメリットです。
FQCNが必要になった理由
モジュールがCollection単位に分散した結果、「どのCollectionのモジュールを呼び出すのか」を明示的に指定する記法が必要になりました。これがFQCN(Fully Qualified Collection Name)です。
copyと書くだけでは「ansible.builtinのcopyなのか、それとも別CollectionにあるcopyなのかJが曖昧になるため、ansible.builtin.copyのように完全修飾名で書くことが推奨されています。FQCNの読み方と構造|ansible.builtin.copyを解剖する
FQCNは3つのパートを「.(ドット)」でつなげた形式です。1. FQCNの3パート構造
# FQCNの基本形式 名前空間.コレクション名.モジュール名(またはプラグイン名) # 具体例その1: 組み込みモジュール ansible.builtin.copy ^^^^^^^ ^^^^^^^ ^^^^ 名前空間 コレクション名 モジュール名 # 具体例その2: コミュニティコレクション community.general.java_cert ^^^^^^^^^ ^^^^^^^ ^^^^^^^^^ 名前空間 コレクション名 モジュール名
・名前空間(Namespace):組織・プロジェクトを表す識別子。
ansibleはRed Hat公式、communityはコミュニティ管理を意味する・コレクション名(Collection name):機能カテゴリを表す名前。
builtinは組み込みモジュール群、generalは汎用モジュール群・モジュール名(Module name):実際に呼び出すモジュール。
copyはファイルコピー、userはユーザー管理など2. ansible.builtinの代表モジュール
ansible.builtinはansible-coreに同梱された組み込みCollectionです。追加インストールなしでいつでも使えます。現場でよく使うモジュールを以下に示します。| モジュール(FQCN) | 主な用途 |
|---|---|
ansible.builtin.copy |
ファイルをリモートホストにコピーする |
ansible.builtin.file |
ファイル・ディレクトリの属性・パーミッション変更 |
ansible.builtin.template |
Jinja2テンプレートを展開してコピーする |
ansible.builtin.user |
Linuxユーザーアカウントの作成・変更・削除 |
ansible.builtin.service |
systemdサービスの起動・停止・有効化 |
ansible.builtin.package |
OSを問わず汎用パッケージ管理(dnf/apt両対応) |
ansible.builtin.dnf |
RHEL/Rocky Linux向けのdnfパッケージ管理 |
ansible.builtin.apt |
Debian/Ubuntu向けのaptパッケージ管理 |
ansible.builtin.command |
リモートホストで任意のコマンドを実行する |
ansible.builtin.shell |
シェル(/bin/sh)経由でコマンドを実行する |
ansible.builtin.lineinfile |
ファイルの特定行を追加・変更・削除する |
ansible.builtin.debug |
変数の値やメッセージをコンソールに出力する |
ansible.builtin.commandとansible.builtin.shellの違いはよく混同されます。commandはシェルを経由しないため|や&&などのシェル記法は使えませんが、予期しないシェルインジェクションのリスクがありません。パイプや変数展開が必要な場合のみshellを使い、それ以外はcommandを選ぶのが現場での定石です。外部Collectionを導入する実践手順|community.generalとansible.posixの例
ansible.builtinにないモジュールを使いたい場合は、外部Collectionを追加でインストールします。ここでは最も利用頻度が高いcommunity.generalとansible.posixを例に手順を示します。1. ansible-galaxy collection installで個別インストールする
# community.generalをインストール(最新版) ansible-galaxy collection install community.general # バージョンを指定してインストール ansible-galaxy collection install community.general:9.5.0 # ansible.posixをインストール ansible-galaxy collection install ansible.posix # 実行結果の例(RHEL 10 環境) Starting galaxy collection install process Process install dependency map Starting collection install process Downloading https://galaxy.ansible.com/download/community-general-9.5.0.tar.gz Installing 'community.general:9.5.0' to '/root/.ansible/collections/ansible_collections/community/general' community.general:9.5.0 was installed successfully
~/.ansible/collections/ 配下になります。チーム開発ではプロジェクトのルートディレクトリ内にインストールすることも多いです。2. requirements.ymlで複数のCollectionを宣言管理する
チーム開発では、必要なCollectionをすべてrequirements.ymlに宣言しておく方法が標準的です。これにより、チームメンバー全員が同じCollectionバージョンの環境を1コマンドで再現できます。# requirements.yml(Collectionセクション) --- collections: - name: ansible.posix version: ">=1.5.0" - name: community.general version: "9.5.0" - name: community.mysql version: ">=3.8.0"
# Collectionのみインストール(--type collection は省略可) ansible-galaxy collection install -r requirements.yml # Roleのみインストール ansible-galaxy role install -r requirements.yml # CollectionとRoleを両方インストールする場合は2コマンドを順に実行する ansible-galaxy collection install -r requirements.yml ansible-galaxy role install -r requirements.yml
3. ansible.cfgでCollection検索パスを設定する
プロジェクトにローカルインストールしたCollectionを認識させるには、ansible.cfgのcollections_pathを設定します。# ansible.cfg の設定例(プロジェクトルートに配置) [defaults] collections_path = ./collections:/usr/share/ansible/collections # 設定後、パスが正しく読まれているか確認 ansible-config dump | grep COLLECTIONS_PATHS # 出力例(RHEL 10 / rocky9-admin ユーザーの場合) COLLECTIONS_PATHS(/home/rocky9-admin/project/ansible.cfg) = ['/home/rocky9-admin/project/collections', '/usr/share/ansible/collections']
# インストール済みCollectionの一覧を確認 ansible-galaxy collection list # 出力例(RHEL 10 環境) # /root/.ansible/collections/ansible_collections Collection Version ----------------- ------- ansible.posix 1.5.4 community.general 9.5.0 # /usr/lib/python3.12/site-packages/ansible_collections Collection Version ----------------- ------- amazon.aws 8.2.1 ansible.netcommon 6.1.2
Ansible実践ハンズオンの詳細を見る >>
PlaybookでFQCNを正しく書く|直接記述とcollections:ディレクティブの使い分け
Playbook内でFQCNを使う方法は2つあります。1. FQCNをモジュール名に直接書く(推奨)
最もシンプルで推奨される方法は、タスクのモジュール名としてFQCNをそのまま書くことです。# FQCN直接記述(推奨) --- - name: Webサーバーセットアップ hosts: webservers tasks: - name: Nginxをインストールする ansible.builtin.dnf: name: nginx state: present - name: Nginx設定ファイルをコピーする ansible.builtin.copy: src: nginx.conf dest: /etc/nginx/nginx.conf owner: root group: root mode: '0644' - name: Nginxサービスを起動して自動起動を有効にする ansible.builtin.service: name: nginx state: started enabled: yes - name: sudoersにdeployユーザーを追加する(community.generalのモジュール) community.general.sudoers: name: deploy-user user: deploy commands: ALL nopassword: yes
2. collections:ディレクティブで短縮記法を使う
同じCollectionのモジュールを多数使う場合、collections:ディレクティブでデフォルトの検索順を指定することで、モジュール名を短縮して書けます。ただしansible-lintでFQCN警告が出る原因にもなるため、採用する場合は注意が必要です。# collections:ディレクティブによる短縮記法(参考) --- - name: コミュニティモジュールをまとめて使うPlay hosts: dbservers collections: - community.general - community.mysql tasks: - name: MySQLデータベースを作成する(FQCN省略形) mysql_db: # community.general.mysql_db を指す name: appdb state: present
ansible-lintを使う現場ではFQCN直接記述を選んでください。
collections:ディレクティブを使った短縮記法は、どのCollectionのモジュールを実際に呼んでいるか一見して分かりにくくなります。また、同名モジュールが複数のCollectionに存在する場合に、意図しないモジュールが呼ばれる曖昧さが生じます。FQCNを直接書く習慣をチームに定着させることが、Playbookの保守性を長期的に高める近道です。トラブルシュート|ansible-lintのFQCN警告とCollection not foundエラーへの対処法
ansible-lintはデフォルト設定でFQCN未使用を警告します。既存のPlaybookをlintにかけると大量の警告が出ることがあります。1. 「fqcn[action-core]」警告への対応
# ansible-lint実行時の警告例 ansible-lint playbook.yml # 出力例(FQCN未使用の警告) WARNING Listing 3 violation(s) that are fatal playbook.yml:8: fqcn[action-core]: Use FQCN for builtin module actions: copy playbook.yml:15: fqcn[action-core]: Use FQCN for builtin module actions: service playbook.yml:22: fqcn[action-core]: Use FQCN for builtin module actions: dnf
# 変更前(短縮名) - name: 設定ファイルをコピーする copy: src: app.conf dest: /etc/app/app.conf # 変更後(FQCN) - name: 設定ファイルをコピーする ansible.builtin.copy: src: app.conf dest: /etc/app/app.conf
--fixオプション(バージョン6.8以降)を使うか、慎重に一件ずつ確認するのが確実です。2. Collection not foundエラーの診断
# よくあるエラー ERROR! couldn't resolve module/action 'community.general.sudoers'. This often indicates a misspelling, missing collection, or incorrect module path. # 診断手順 # 1. Collection名にタイポがないか確認 ansible-galaxy collection list | grep community.general # 2. インストールされていない場合はインストール ansible-galaxy collection install community.general # 3. ansible.cfgのcollections_pathが正しいか確認 ansible-config dump | grep COLLECTIONS_PATHS # 4. モジュール名の正式名称をドキュメントで確認 ansible-doc -t module community.general.sudoers
ansible-doc -t module コレクション名.モジュール名を実行すると、そのモジュールのドキュメントとFQCNが確認できます。モジュール名が正しいのにエラーが出る場合は、インストール先のパスがansible.cfgのcollections_pathに含まれていないことが多いです。3. プロキシ環境でインストールが失敗する
企業のプロキシ環境下ではansible-galaxy collection installがSSL証明書の検証エラーで失敗することがあります。# プロキシを環境変数で指定してインストール export HTTPS_PROXY=http://proxy.example.com:8080 ansible-galaxy collection install community.general # または ansible.cfg にGalaxyサーバーの設定を追記 # [galaxy] # server_list = release_galaxy # # [galaxy_server.release_galaxy] # url=https://galaxy.ansible.com/ # # proxy=http://proxy.example.com:8080
本記事のまとめ
| やりたいこと | コマンド/設定 |
|---|---|
| インストール済みCollectionを確認する | ansible-galaxy collection list |
| 外部Collectionをインストールする | ansible-galaxy collection install collection名 |
| requirements.ymlからCollectionを一括インストールする | ansible-galaxy collection install -r requirements.yml |
| モジュールのFQCNとドキュメントを確認する | ansible-doc -t module ansible.builtin.copy |
| ansible.cfgのCollection検索パスを確認する | ansible-config dump | grep COLLECTIONS_PATHS |
| Playbookのfqcn警告を一括修正する | ansible-lint --fix playbook.yml |
ansible.builtin.copyのようなFQCN形式で書くことがベストプラクティスになっています。最初は冗長に感じるかもしれませんが、どのCollectionのモジュールを呼んでいるのかが一目瞭然になり、複数のCollectionが混在する大規模プロジェクトほどその恩恵を実感できます。外部Collectionはrequirements.ymlで宣言して管理することで、チームメンバー全員が
ansible-galaxy collection install -r requirements.ymlの1コマンドで同じ環境を再現できます。CollectionとFQCNの関係を正しく理解することが、モダンなAnsible設計の第一歩です。
Ansible実践ハンズオンの詳細を見る >>
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら
- 前のページへ:ansible-pullで構成管理をGitOps化する方法|プル型運用の仕組みとcron連携の設計
- この記事の属するカテゴリ:Ansibleへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます