Galaxy ユーザーガイド

Ansible Galaxy は、コミュニティーが開発したロールの検索、ダウンロード、共有を行う無料サイトである Galaxy の Web サイトを指します。

Galaxy を使用して、Ansible コミュニティーの優れたコンテンツで自動化プロジェクトを活性化させます。Galaxy は ロール などの事前にパッケージ化された作業単位を提供し、Galaxy 3.2 では コレクション が新たに提供されました。 インフラストラクチャーのプロビジョニング、アプリケーションのデプロイ、および日々の作業を行うすべてのタスクにロールがあります。コレクション形式は、複数の Playbook、ロール、モジュール、およびプラグインが含まれる可能性のある自動化の包括的なパッケージを提供します。

Galaxy でコレクションの検索

Galaxy でコレクションを検索するには、以下を行います。

  1. 左側のナビゲーションにある 検索 アイコンをクリックします。
  2. コレクション にフィルターを設定します。
  3. その他のフィルターを設定し、Enter を押します。

Galaxy は、検索条件に一致するコレクションのリストを表示します。


Galaxy からコレクションのインストール

You can use the ansible-galaxy collection install command to install a collection on your system.


By default, ansible-galaxy uses as the Galaxy server (as listed in the ansible.cfg file under GALAXY_SERVER). You do not need any further configuration. See Configuring the ansible-galaxy client if you are using any other Galaxy server, such as Red Hat Automation Hub).

To install a collection hosted in Galaxy:

ansible-galaxy collection install my_namespace.my_collection

You can also directly use the tarball from your build:

ansible-galaxy collection install my_namespace-my_collection-1.0.0.tar.gz -p ./collections


The install command automatically appends the path ansible_collections to the one specified with the -p option unless the parent directory is already in a folder called ansible_collections.

When using the -p option to specify the install path, use one of the values configured in COLLECTIONS_PATHS, as this is where Ansible itself will expect to find collections. If you don’t specify a path, ansible-galaxy collection install installs the collection to the first path defined in COLLECTIONS_PATHS, which by default is ~/.ansible/collections

You can also keep a collection adjacent to the current playbook, under a collections/ansible_collections/ directory structure.

├── collections/
│   └── ansible_collections/
│               └── my_namespace/
│                   └── my_collection/<collection structure lives here>

See コレクション構造 for details on the collection directory structure.

Automation Hub からのコレクションのダウンロード

ansible-galaxy コマンドで Automation Hub からコレクションをダウンロードするには、以下を行います。

  1. Automation Hub API トークンを取得します。 にアクセスし、バージョンのドロップダウンから Get API token をクリックして、API トークンをコピーします。
  2. ansible.cfg ファイルの [galaxy] セクションの下にある server_list オプションで Red Hat Automation Hub サーバーを設定します。
server_list = automation_hub

  1. Automation Hub でホストされるコレクションをダウンロードします。
ansible-galaxy collection install my_namespace.my_collection

See also

Automation Hub の使用
Automation Hub の概要


By default ansible-galaxy installs the latest collection that is available but you can add a version range identifier to install a specific version.

To install the 1.0.0 version of the collection:

ansible-galaxy collection install my_namespace.my_collection:1.0.0

To install the 1.0.0-beta.1 version of the collection:

ansible-galaxy collection install my_namespace.my_collection:==1.0.0-beta.1

To install the collections that are greater than or equal to 1.0.0 or less than 2.0.0:

ansible-galaxy collection install my_namespace.my_collection:>=1.0.0,<2.0.0

You can specify multiple range identifiers which are split by ,. You can use the following range identifiers:

  • *: Any version, this is the default used when no range specified is set.
  • !=: Version is not equal to the one specified.
  • ==: Version must be the one specified.
  • >=: Version is greater than or equal to the one specified.
  • >: Version is greater than the one specified.
  • <=: Version is less than or equal to the one specified.
  • <: Version is less than the one specified.


The ansible-galaxy command ignores any pre-release versions unless the == range identifier is used to explicitly set to that pre-release version.


You can also setup a requirements.yml file to install multiple collections in one command. This file is a YAML file in the format:

# With just the collection name
- my_namespace.my_collection

# With the collection name, version, and source options
- name: my_namespace.my_other_collection
  version: 'version range identifiers (default: ``*``)'
  source: 'The Galaxy URL to pull the collection from (default: ``--api-server`` from cmdline)'

The version key can take in the same range identifier format documented above.

Roles can also be specified and placed under the roles key. The values follow the same format as a requirements file used in older Ansible releases.

  # Install a role from Ansible Galaxy.
  - name:
    version: 1.9.6

  # Install a collection from Ansible Galaxy.
  - name: geerlingguy.php_roles
    version: 0.9.3


While both roles and collections can be specified in one requirements file, they need to be installed separately. The ansible-galaxy role install -r requirements.yml will only install roles and ansible-galaxy collection install -r requirements.yml -p ./ will only install collections.

ansible-galaxy クライアントの設定

By default, ansible-galaxy uses as the Galaxy server (as listed in the ansible.cfg file under GALAXY_SERVER).

You can configure this to use other servers (such as Red Hat Automation Hub or a custom Galaxy server) as follows:

To configure a Galaxy server list in ansible.cfg:

  1. Add the server_list option under the [galaxy] section to one or more server names.
  2. Create a new section for each server name.
  3. Set the url option for each server name.

For Automation Hub, you additionally need to:

  1. Set the auth_url option for each server name.
  2. Set the API token for each server name. Go to and click :Get API token from the version dropdown to copy your API token.

The following example shows how to configure multiple servers:

server_list = automation_hub, my_org_hub, release_galaxy, test_galaxy







You can use the --server command line argument to select an explicit Galaxy server in the server_list and the value of this argument should match the name of the server. To use a server not in the server list, set the value to the URL to access that server (all servers in the server list will be ignored). Also the --api-key argument is not applied to any of the predefined servers. It is only applied if no server list is defined or a URL was specified by --server.

Galaxy server list configuration options

The GALAXY_SERVER_LIST option is a list of server identifiers in a prioritized order. When searching for a collection, the install process will search in that order, e.g. automation_hub first, then my_org_hub, release_galaxy, and finally test_galaxy until the collection is found. The actual Galaxy instance is then defined under the section [galaxy_server.{{ id }}] where {{ id }} is the server identifier defined in the list. This section can then define the following keys:

  • url: The URL of the galaxy instance to connect to, this is required.
  • token: A token key to use for authentication against the Galaxy instance, this is mutually exclusive with username
  • username: The username to use for basic authentication against the Galaxy instance, this is mutually exclusive with token
  • password: The password to use for basic authentication
  • auth_url: The URL of a Keycloak server ‘token_endpoint’ if using SSO auth (Automation Hub for ex). This is mutually exclusive with username. auth_url requires token.

As well as being defined in the ansible.cfg file, these server options can be defined as an environment variable. The environment variable is in the form ANSIBLE_GALAXY_SERVER_{{ id }}_{{ key }} where {{ id }} is the upper case form of the server identifier and {{ key }} is the key to define. For example I can define token for release_galaxy by setting ANSIBLE_GALAXY_SERVER_RELEASE_GALAXY_TOKEN=secret_token.

For operations where only one Galaxy server is used, i.e. publish, info, login then the first entry in the server_list is used unless an explicit server was passed in as a command line argument.


Once a collection is found, any of its requirements are only searched within the same Galaxy instance as the parent collection. The install process will not search for a collection requirement in a different Galaxy instance.

Galaxy でのロールの検索

Galaxy データベースは、タグ、プラットフォーム、作成者、および複数のキーワードで検索します。たとえば、以下のようになります。

$ ansible-galaxy search elasticsearch --author geerlingguy

search コマンドは、検索に一致する最初の 1000 個の結果を一覧で返します。

Found 2 roles matching your search:

Name                              Description
----                              -----------
geerlingguy.elasticsearch         Elasticsearch for Linux.
geerlingguy.elasticsearch-curator Elasticsearch curator for Linux.


info コマンドを使用して、特定のロールに関する詳細を表示します。

$ ansible-galaxy info username.role_name

これは、ロールの Galaxy にあるすべてのものを返します。

Role: username.role_name
    description: Installs and configures a thing, a distributed, highly available NoSQL thing.
    active: True
    commit: c01947b7bc89ebc0b8a2e298b87ab416aed9dd57
    commit_message: Adding travis
    company: My Company, Inc.
    created: 2015-12-08T14:17:52.773Z
    download_count: 1
    forks_count: 0
    github_repo: repo_name
    github_user: username
    id: 6381
    is_valid: True
    license: Apache
    min_ansible_version: 1.4
    modified: 2015-12-08T18:43:49.085Z
    namespace: username
    open_issues_count: 0
    path: /Users/username/projects/roles
    scm: None
    src: username.repo_name
    stargazers_count: 0
    watchers_count: 1

Galaxy からのロールのインストール

ansible-galaxy コマンドが Ansible にバンドルされており、これを使用して Galaxy からロールをインストールするか、または git ベースの SCM から直接ロールをインストールすることができます。また、 これを使用して、Galaxy の Web サイトで新しいロールの作成、ロールの削除、またはタスクの実行を行います。

デフォルトでは、コマンドラインツールはサーバーアドレス を使用して Galaxy Web サイト API と通信します。`Galaxy プロジェクト<>`_ はオープンソースプロジェクトであるため、 独自の内部 Galaxy サーバーを実行し、デフォルトのサーバーアドレスを上書きしたい場合があります。この場合は、–server オプションを使用できます。 または、ansible.cfg ファイルで Galaxy サーバー値を設定して行います。ansible.cfg の値を設定する方法は、「GALAXY_SERVER」を参照してください。


ansible-galaxy コマンドを使用して、`Galaxy の Web サイト<>`_ からロールをダウンロードします。

$ ansible-galaxy install namespace.role_name


デフォルトでは、Ansible はパスのデフォルトリスト ~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles にあるディレクトリーで、最初に書き込み可能なディレクトリーにロールをダウンロードします。これは、ansible-galaxy を実行しているユーザーのホームディレクトリーにロールをインストールします。


  • セッション内に環境変数 ANSIBLE_ROLES_PATH を設定します。
  • ansible.cfg ファイルに roles_path を定義します。
  • ansible-galaxy コマンドに --roles-path オプションを使用します。

以下は、--roles-path を使用して現在の作業ディレクトリーにロールをインストールする例を示しています。

$ ansible-galaxy install --roles-path . geerlingguy.apache

See also

Ansible の設定


Galaxy サーバーがロールをインポートする場合は、Sandmantic Version 形式に一致する git タグをバージョンとしてインポートします。その後、インポートされたタグのいずれかを指定して、特定バージョンのロールをダウンロードできます。


  1. Galaxy 検索ページでロールを検索します。
  2. 名前をクリックして、利用可能なバージョンなどの詳細を表示します。

/<namespace>/<role name> を使用してロールに直接移動することもできます。たとえば、geerlingguy.apache ロールを表示するには、 にアクセスします。

Galaxy から特定のバージョンのロールをインストールするには、コンマと GitHub リリースタグの値を追加します。たとえば、以下のようになります。

$ ansible-galaxy install geerlingguy.apache,v1.0.0

git リポジトリーを直接指定し、ブランチ名またはコミットハッシュをバージョンとして指定することもできます。たとえば、次のコマンドは、 特定のコミットをインストールします。

$ ansible-galaxy install git+,0b7cd353c0250e87a26e0499e59e7fd265cc2f25


requirements.yml ファイルにロールを追加して、複数のロールをインストールできます。ファイルのフォーマットは YAML で、 ファイル拡張子は .yml または .yaml のいずれかにする必要があります。

以下のコマンドを使用して、requirements.yml: に含まれるロールをインストールします。

$ ansible-galaxy install -r requirements.yml

ここでも、拡張機能は重要です。.yml 拡張を省略すると、ansible-galaxy CLI は、ファイルが古い (現在は非推奨な)、 基本的な形式であると見なします。

このファイルの各ロールには、以下の属性が 1 つ以上あります。

ロールのソース。Galaxy からダウンロードする場合は namespace.role_name 形式を使用します。 それ以外の場合は、git ベースの SCM 内のリポジトリーを指定する URL を指定します。以下の例を参照してください。これは必須の属性です。
SCM を指定します。本ガイドの執筆中は、git または hg のみが許可されています。以下の例を参照してください。デフォルトは git です。
ダウンロードするロールのバージョン。リリースタグの値、コミットハッシュ、またはブランチ名を指定します。デフォルトは、リポジトリーでデフォルトとして設定されたブランチに設定されます。それ以外の場合は master にデフォルト設定されます。
ロールを特定の名前にダウンロードします。Galaxy からダウンロードする場合にデフォルトは Galaxy 名に設定されます。 それ以外の場合は、リポジトリーの名前がデフォルトになります。

以下の例を、requirements.yml でロールを指定するためのガイドとして使用してください。

# from galaxy
- name: yatesr.timezone

# from GitHub
- src:

# from GitHub, overriding the name and specifying a specific tag
- name: nginx_role
  version: master

# from a webserver, where the role is packaged in a tar.gz
- name: http-role-gz

# from a webserver, where the role is packaged in a tar.bz2
- name: http-role-bz2

# from a webserver, where the role is packaged in a tar.xz (Python 3.x only)
- name: http-role-xz

# from Bitbucket
- src: git+
  version: v1.4

# from Bitbucket, alternative syntax and caveats
- src:
  scm: hg

# from GitLab or other git-based scm, using git+ssh
- src: [email protected]:mygroup/ansible-base.git
  scm: git
  version: "0.1"  # quoted, so YAML doesn't parse this as a floating-point value

同じ requirements.yml ファイルからのロールおよびコレクションのインストール


  # Install a role from Ansible Galaxy.
  - name:
    version: 1.9.6

  # Install a collection from Ansible Galaxy.
  - name: geerlingguy.php_roles
    version: 0.9.3


ロールとコレクションの両方を 1 つの要件ファイルで指定できますが、個別にインストールする必要があります。 ansible-galaxy role install -r requirements.yml はロールのみをインストールし、ansible-galaxy collection install -r requirements.yml -p ./ はコレクションのみをインストールします。


大規模なプロジェクトの場合、requirements.yml ファイルの include ディレクティブにより、大きなファイルを複数の小さなファイルに分割できます。

たとえば、プロジェクトに requirements.yml ファイルと webserver.yml ファイルが含まれるとします。

webserver.yml ファイルの内容は次のとおりです。

# from github
- src:

# from Bitbucket
- src: git+
  version: v1.4

以下は、webserver.yml ファイルが含まれる requirements.yml ファイルの内容を示しています。

# from galaxy
- name: yatesr.timezone
- include: <path_to_requirements>/webserver.yml

両方のファイルから全ロールをインストールするには、root ファイルを渡します (この場合、コマンドラインの requirements.yml は、 以下のようになります。

$ ansible-galaxy install -r requirements.yml



ロールの一覧を指定して、meta/main.yml ファイルにロール依存関係を指定します。ロールのソースが Galaxy の場合は、 namespace.role_name 形式のロールのみを指定できます。requirements.yml でより複雑な形式を使用し、srcscmversion、および name を指定することもできます。

以下は、依存するロールを持つ meta/main.yml ファイルの例になります。


  author: geerlingguy
  description: Elasticsearch for Linux.
  company: "Midwestern Mac, LLC"
  license: "license (BSD, MIT)"
  min_ansible_version: 2.4
  - name: EL
    - all
  - name: Debian
    - all
  - name: Ubuntu
    - all
    - web
    - system
    - monitoring
    - logging
    - lucene
    - elk
    - elasticsearch

タグは、依存関係チェーンを介して*継承* されます。タグをロールおよびそのすべての依存関係に適用するには、タグをロール内のすべてのタスクに適用せずに、ロールに適用する必要があります。

依存関係として一覧表示されるロールは、条件およびタグのフィルタリングの対象となり、 適用されているタグや条件によっては、完全には実行されない場合があります。

ロールのソースが Galaxy の場合は、ロールを namespace.role_name 形式で指定します。

  - geerlingguy.apache
  - geerlingguy.ansible

または、以下のように requirements.yml で使用される複雑な形式でロールの依存関係を指定することもできます。

  - name: geerlingguy.ansible
  - name: composer
    src: git+
    version: 775396299f2da1f519f0d8885022ca2d6ee80ee8

ansible-galaxy で依存関係が発生すると、各依存関係が roles_path に自動的にインストールされます。プレイの実行中に依存関係がどのように処理されるかを理解するには、「ロール」を参照してください。


Galaxy は、すべてのロールの依存関係が Galaxy に存在することを想定しているため、 依存関係は namespace.role_name 形式で指定されます。src の値が URL である依存関係でロールをインポートすると、インポートプロセスに失敗します。


list を使用して、roles_path にインストールされている各ロールの名前およびバージョンを表示します。

$ ansible-galaxy list
  -, v2.7.2
  - ansible-network.config_manager, v2.6.2
  - ansible-network.cisco_nxos, v2.7.1
  - ansible-network.vyos, v2.7.3
  - ansible-network.cisco_ios, v2.7.0


remove を使用してロールを roles_path から削除します。

$ ansible-galaxy remove namespace.role_name

See also