ロール（役割）：ハンドブック機能、例えばハンドラ、タスクおよび別のサブディレクトリに配置された他のカテゴリーとして、セットに従って形成は、役割です。
roles_path ansible.cfgディレクトリ内の役割は、パスを定義することができ、かつ入口は、同じディレクトリのファイル脚本に配置することができます。推奨roles_path、便利な一元管理。この例では、脚本とファイルが同じディレクトリに保存されている入り口を使用しています。
ロールは自動的に知られているファイル構造に基づいて、特定のvars_files、タスク、およびハンドラをロードする方法です。役割によってグループ化コンテンツは、他のユーザーと役割を簡単に共有することができます。
接続の公式文書：
https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html
公式のGitHubの上の簡単な例：
https://github.com/ansible/ansible-examples
ベストプラクティスの公式ドキュメント：
https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html
役割のディレクトリ構造
役割は、ディレクトリ・ネーミングおよびディレクトリ表示に依存しています。ここでは役割のディレクトリ構造の正式な定義の例です。
site.yml
webservers.yml
fooservers.yml
roles/
common/
tasks/
handlers/
files/
templates/
vars/
defaults/
meta/
webservers/
tasks/
defaults/
meta/- * .Ymlファイル：ファイルエントリのプレイブック
- site.yml：名前は一般的にプロジェクトの脚本ファイル名を展開しています。脚本、ランダムに名前の作成で他のタスクがある場合。
- ディレクトリの役割：ストレージディレクトリの役割。以下は、各文字のサブディレクトリで、一般的なWebサーバがあります
各役割には、需要に応じて、ディレクトリ機能を作成し、ディレクトリ名の指定があります。各ディレクトリの下にこのファイルが呼び出されるansible、main.ymlファイルを持っている必要があります。
次のようにディレクトリの名前の意味は次のとおりです。
- タスク：このディレクトリにある他のタスクのファイルが含まれて含まれ、使用することができ、タスクリストの役割を定義
- ハンドラ：トリガ条件の実行のアクション定義された役割を
- デフォルト：デフォルトの変数、低優先度を設定し、時間は変数の基本値がこの値を使用することはありませんです
- varsは：変数の使用の役割を定義し、優先度の高いです
- ファイル：スクリプトまたはモジュールによって呼び出されたファイルコピーモジュールを格納するために使用されます。ファイルはmain.ymlを必要としません
- テンプレート：jinjia2テンプレート、テンプレートモジュールを格納するために使用されるが、自動的にこのディレクトリにjinjia2テンプレートファイルを検索します。ファイルはmain.ymlを必要としません
- メタ：メタデータの役割の定義は、主に依存関係として使用されています
マルチプラットフォームのサポート
マルチプラットフォームサポートのタスクの公式例の区別があります。
あなたは、異なるプラットフォーム上で見ブックの名前から定義されたさまざまな役割の例もあります。
最後に、公式のベストプラクティスの例の一つ。
マルチプラットフォームのサポートタスク
レベルのタスク、対応する作業ディレクトリ。
複数のタスクファイルの役割を定義し、役割を定義しました。main.ymlでの条件判断は、タスクファイルを、対応する導入しました。
タスク/ main.ymlは、エントリー文書のタスクとして、起こる必要がありますが、このファイルの実際のコードを書いていない、このファイル内の他のYAMLファイルを含めることができます。公式には、マルチプラットフォームサポートの例があります。
# roles/example/tasks/main.yml
- import_tasks: redhat.yml
when: ansible_facts['os_family']|lower == 'redhat'
- import_tasks: debian.yml
when: ansible_facts['os_family']|lower == 'debian'
# roles/example/tasks/redhat.yml
- yum:
name: "httpd"
state: present
# roles/example/tasks/debian.yml
- apt:
name: "apache2"
state: presentマルチプラットフォームのサポートの役割
ロールレベル、例えば共通のディレクトリやWebサーバとしての役割、下の対応するサブディレクトリの役割。
役割のかなりの数の直接の定義、すべてのロールが条件付きでインポートします。役割の要件を満たすためにのみ実行インポートされます。
役割で複数のプラットフォームをサポートするレベル。異なるプラットフォームのための事前定義された役割ません。例えば、二つの役割はhttpd_db名前とhttpd_rhです。脚本ファイルは、書くことができます。
# site.yml
- name: install httpd
hosts: webservers
roles:
- { role: httpd_db, when: ansible_os_family == 'Deian' }
- { role: httpd_rh, when: ansible_os_family == 'RedHat' }裁判官が同じでなければなりませプラットフォーム上記の方法は、自動的にAnsibleを自動的に取得したホスト情報を決定するために使用されます。ここでの文言は、上記の公式サイトの文言よりも低いです。私は実際にそれが本来の文言を維持し、テストしていません。
自動的にホストモジュールにパケットGROUP_BY
脚本レベル、例えばsite.ymlファイルと同じディレクトリの役割に対応します。
最初のタスク実行モジュールGROUP_BY、ホストの動的グルーピング。グループの後、次に脚本を設定されています。
このセクションと役割を適用することができた役割とは何の関係もない、無用の役割も適用することができます。これは、公式練習でのベストプラクティスです。
GROUP_BYホストモジュールは、キーワードに基づいてグループ化することができます。キーワードは、ホスト情報から抽出して、抽出することができ、カスタムのプレフィックスまたはサフィックスの最初の部分にスプライスされることができます。グループ名を取得するには、最終的な文字列は、宿主中で、このような脚本は、グループ名を記入することができ、ホストグループになります。
---
- name: talk to all hosts just so we can learn about them
hosts: all
tasks:
- name: Classify hosts depending on their OS distribution
group_by:
key: os_{{ ansible_facts['distribution'] }}
# now just on the CentOS hosts...
- hosts: os_CentOS
gather_facts: False
tasks:
- # tasks that only happen on CentOS go here動的GROUP_BYのグループ化により、ホストモジュールを追加し、あなたが事前ファイル内の変数の良いセットを作成することができ、これらの変数はまたに反映するように設定されています。
ロールの使用
派手なトリック公式サイトのすべての種類があります。
https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#using-roles
派手なトリックのすべての種類：
- タスク書かれた役割は、これは新しい構文です。他のタスクは、役割の導入前と後に実行することができます
- 役割を紹介するために、絶対パスを使用します
- 役割の導入、変数の定義ながら
- マルチプラットフォームの役割上記の条件付き輸入の役割は、それほど使用されています
- 役割のためのタグを追加します。私は使用シナリオを理解したくありませんでした
役割の依存関係
役割を使用する際に依存ロールによって、他の文字は自動的に追加することができます。役割は、依存関係がメタ/ main.ymlファイルに依存して定義し、コンテンツが役割と役割に依存するパラメータに依存する役割の現在のリストが含まれています。
設定ファイルの例：
---
dependencies:
- role: common
vars:
some_parameter: 3
- role: apache
vars:
apache_port: 80
- role: postgres
vars:
dbname: blarg
other_parameter: 12依存関係の役割は、依存関係のある、ちょうどキーメタファイルです。他のキーallow_duplicatesがありますが、これは役割の定義は、タスクを繰り返すことができます。他のキーは一時的に、文書に表示されません。
ロール埋め込みモジュールとプラグイン
ディレクトリ構造では、ディレクトリは、ロールの名前の基本的な使用を示しています。ここではカスタムモジュールとプラグインサブディレクトリ名は、ディレクトリ内の役割の役割です。
新しいディレクトリ構造：
roles/
webservers/
tasks/
defaults/
meta/
library/
module1
module2
filter_plugins
filter1
filter2カスタムモジュールを追加するためのWebサーバーの役割、ディレクトリ名では、ライブラリを使用します。
多くのansibleプラグインのウェブサーバの役割はここにありますファイル用の2つのカスタムフィルタプラグイン機能を追加することです。
プロジェクトのディレクトリ構造
ここでは作業ディレクトリ構造に推奨公式Ansibleベストプラクティスです。
production # 生产环境的 inventory 文件
stage # 试运行环境的 inventory 文件
group_vars/ # 定义组变量
group1
group2
host_vars/ # 定义主机变量
hostname1
hostname2
library/ # 如果有自定义的模块，放在这里(可选)
module_utils/ # 如果有自定义的模块中要使用的工具，放在这里(可选)
filter_plugins/ # 如果有自定义的过滤插件，放在这里(可选)
site.yml # 主 playbook
webservers.yml # Web 服务器的 playbook
dbservers.yml # 数据库服务器的 playbook
roles/ # role 文件存放目录
common/ # common 角色目录
tasks/ #
main.yml # task 入口
handlers/ #
main.yml # handler 入口
templates/ # 存放模板文件
ntp.conf.j2 #
files/ # 存放文件资源
bar.txt #
foo.sh #
vars/ #
main.yml # 定义角色使用的变量
defaults/ #
main.yml # 定义角色默认变量
meta/ #
main.yml # 定义角色依赖
webservers/ # webservers 角色目录，不展开了ここではカスタムモジュールとプラグインが自動的にプロジェクトディレクトリに反映されていないのです。
ライブラリのデフォルト値：~/.ansible/plugins/modules:/usr/share/ansible/plugins/modules
filter_pluginsのデフォルト値：~/.ansible/plugins/filter:/usr/share/ansible/plugins/filter
この公式の文書は、構成ファイル内の各変数の名前は、環境変数の名前、および変数を含む関連情報Ansibleの設定については、多くのデフォルト値、で見つけることができます。
https://docs.ansible.com/ansible/latest/reference_appendices/config.html
Ansible.cfgは、設定ファイルを変更することができます。また、ホームディレクトリのデフォルトの場所を使用することができ、ソフトリンクを作成します。