Ansible Rolesとベストプラクティス
ロール(roles):handler、tasksなどのプレイブックを機能に応じて分類し、それぞれのサブディレクトリの下に置いて、集合を形成します.ロールです.Rolesディレクトリはansibleです.cfg中roles_Pathで定義されたパスは、エントリPlaybookファイルと同級ディレクトリに格納することもできます.rolesの使用を推奨path、統一管理が便利です.この例では、ポータルPlaybookファイルと同級ディレクトリに格納します.
Roles are ways of automatically loading certain vars_files, tasks, and handlers based on a known file structure. Grouping content by roles also allows easy sharing of roles with other users.
公式ドキュメントへの接続: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
Rolesディレクトリ構造
Rolesは、ディレクトリの命名規則とディレクトリの配置に依存します.次の例では、Rolesのディレクトリ構造を定義します. *.ymlファイル:エントリPlaybookファイル site.yml:この名前は、一般的に導入プロジェクトのPlaybookファイル名です.他にもPlaybookを作成しているタスクがある場合は、名前は自由です. rolesディレクトリ:Rolesを格納するディレクトリ.次の各サブディレクトリはロールです.ここにはcommonとwebservers があります.
各ロールの下で、機能に基づいてディレクトリを作成します.ディレクトリ名には仕様があります.各ディレクトリの下にmainが必要です.ymlファイル、ansibleはこのファイルを呼び出します.ディレクトリ名の意味は次のとおりです. tasks:このディレクトリにある他のtaskファイル をincludeで含むロールのタスクリストを定義します. handlers:キャラクタのトリガ条件を定義するときに実行される動作 defaults:デフォルト変数を設定し、優先度が極めて低く、基本的にこの変数に値がない場合に使用されます. vars:ロールで使用する変数を定義し、優先度が 高い files:copyモジュールまたはscriptモジュールによって呼び出されたファイルを格納します.いいえ.ymlファイル templates:jinjia 2テンプレートを格納するために使用され、templateモジュールは自動的にこのディレクトリでjinjia 2テンプレートファイルを探します.いいえ.ymlファイル meta:役割を定義するメタデータで、主に依存関係 として使用されます.
マルチプラットフォームのサポート
公式にはtasksで区別されるマルチプラットフォームサポートの例があります.また、本から見た異なるプラットフォームが異なるロール名を定義する例もあります.最後に、公式のベストプラクティスの例です.
tasksマルチプラットフォームサポート
tasksレベル、tasksディレクトリに対応します.ロールを定義し、ロールの下に複数のtaskファイルを定義します.メールでymlで条件判断を行い、対応するtaskファイルをインポートします.tasks/main.ymlは必須で、tasksのエントリファイルとして使われていますが、実際のコードはこのファイルに書かなくても、このファイルに他のyamlファイルを含めることができます.公式には、マルチプラットフォームサポートの例があります.
rolesマルチプラットフォームサポート
ロールレベルは、rolesの下のロールサブディレクトリ(commonやwebserversディレクトリなど)に対応します.複数のロールを直接定義し、すべてのロールを条件付きでインポートします.要求を満たすロールのみがインポートされて実行されます.rolesレベルでマルチプラットフォームをサポートします.異なるプラットフォームに不要な役割を定義しておきます.たとえば、2つのロール名はhttpd_です.dbとhttpd_rh.Playbookファイルは次のように書くことができます.
ここでの判断プラットフォームの方式は上のものと同じであるべきであり,いずれもAnsibleによって自動的に取得されたホスト情報によって自動的に判断される.ここの書き方は上の公式サイトの書き方よりlow.私は実際にテストしていないので、元の書き方を残しました.
group_byモジュール自動ホストグループ化
Playbookレベル、rolesに対応する同級ディレクトリ、例えばsite.ymlファイル.まずgroup_を実行しますbyモジュールのtaskは、ホストを動的にグループ化します.その後、グループごとにプレイブックの設定を行います.この部分はrolesとは関係なく、rolesを使っても使えますし、rolesを使っても使えません.公式のベストプラクティスのやり方です.group_byモジュールは、キーワードに基づいてホストをグループ化することができる.キーワードはホスト情報から抽出でき、抽出された後、前のカスタム接頭辞または接尾辞を先に接続できます.最終的に取得された文字列はホストグループのグループ名となり、Playbookのhostsはこのグループ名を直接記入することができます.
グループを通してbyモジュールはホストに動的にグループを追加し、事前にグループ変数ファイルを作成することもできます.これらのグループ変数も有効になります.
Using Roles
公式サイトにはいろいろな花のテクニックがあります.https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#using-roles
様々な花のテクニック: roleをtasksに書きます.これは新しい文法フォーマットです.別のtask は、roleの導入前後で実行することができる.絶対パスを使用してrole に導入する. roleを導入するとともに、変数 を定義する.条件付きでroleを導入し、上のrolesのマルチプラットフォームはこのように を使用しています.ロールにラベルを追加します.シーンを使うのはまだ分からない ロール依存関係
キャラクタ依存性により、キャラクタを使用するときに自動的に他のキャラクタを追加できます.ロール依存定義はmeta/main.ymlファイルのdependenciesの下には、現在のロールの依存ロールと依存ロールのパラメータリストが含まれています.プロファイルの例:
ロールの依存関係は、metaファイルのkey、すなわちdependenciesにすぎません.他のキーとallowduplicates、これは定義ロールがタスクを繰り返し実行できることです.他のキーは一時的にドキュメントに表示されません.
ロールにモジュールとプラグインを埋め込む
「≪ディレクトリ構造|Directory Structure|emdw≫」には、ロールが使用する基本ディレクトリ名がリストされます.ここのカスタムモジュールとプラグインもrolesディレクトリの下にあるロール名サブディレクトリに配置されています.新しいディレクトリ構造:
Webserversロールの下にカスタムモジュールが追加され、ディレクトリ名はlibraryを使用します.ansibleのプラグインにはいろいろありますが、ここではwebserverロールの下でfilterプラグインに2つのカスタム機能を追加したファイルです.
プロジェクトディレクトリ構造
ここでは、Ansibleの公式ベストプラクティスで推奨されている作業ディレクトリの構造です.
ここのカスタムモジュールとプラグインはプロジェクトディレクトリの下にあり、自動的に有効になりません.libraryのデフォルト:
修正できるcfgプロファイルは、デフォルトのホームディレクトリの場所を使用してソフト接続を作成することもできます.
Roles are ways of automatically loading certain vars_files, tasks, and handlers based on a known file structure. Grouping content by roles also allows easy sharing of roles with other users.
公式ドキュメントへの接続: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
Rolesディレクトリ構造
Rolesは、ディレクトリの命名規則とディレクトリの配置に依存します.次の例では、Rolesのディレクトリ構造を定義します.
site.yml
webservers.yml
fooservers.yml
roles/
common/
tasks/
handlers/
files/
templates/
vars/
defaults/
meta/
webservers/
tasks/
defaults/
meta/
各ロールの下で、機能に基づいてディレクトリを作成します.ディレクトリ名には仕様があります.各ディレクトリの下にmainが必要です.ymlファイル、ansibleはこのファイルを呼び出します.ディレクトリ名の意味は次のとおりです.
マルチプラットフォームのサポート
公式にはtasksで区別されるマルチプラットフォームサポートの例があります.また、本から見た異なるプラットフォームが異なるロール名を定義する例もあります.最後に、公式のベストプラクティスの例です.
tasksマルチプラットフォームサポート
tasksレベル、tasksディレクトリに対応します.ロールを定義し、ロールの下に複数のtaskファイルを定義します.メールでymlで条件判断を行い、対応するtaskファイルをインポートします.tasks/main.ymlは必須で、tasksのエントリファイルとして使われていますが、実際のコードはこのファイルに書かなくても、このファイルに他の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
rolesマルチプラットフォームサポート
ロールレベルは、rolesの下のロールサブディレクトリ(commonやwebserversディレクトリなど)に対応します.複数のロールを直接定義し、すべてのロールを条件付きでインポートします.要求を満たすロールのみがインポートされて実行されます.rolesレベルでマルチプラットフォームをサポートします.異なるプラットフォームに不要な役割を定義しておきます.たとえば、2つのロール名はhttpd_です.dbとhttpd_rh.Playbookファイルは次のように書くことができます.
# 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によって自動的に取得されたホスト情報によって自動的に判断される.ここの書き方は上の公式サイトの書き方よりlow.私は実際にテストしていないので、元の書き方を残しました.
group_byモジュール自動ホストグループ化
Playbookレベル、rolesに対応する同級ディレクトリ、例えばsite.ymlファイル.まずgroup_を実行しますbyモジュールのtaskは、ホストを動的にグループ化します.その後、グループごとにプレイブックの設定を行います.この部分はrolesとは関係なく、rolesを使っても使えますし、rolesを使っても使えません.公式のベストプラクティスのやり方です.group_byモジュールは、キーワードに基づいてホストをグループ化することができる.キーワードはホスト情報から抽出でき、抽出された後、前のカスタム接頭辞または接尾辞を先に接続できます.最終的に取得された文字列はホストグループのグループ名となり、Playbookのhostsはこのグループ名を直接記入することができます.
---
- 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
グループを通してbyモジュールはホストに動的にグループを追加し、事前にグループ変数ファイルを作成することもできます.これらのグループ変数も有効になります.
Using Roles
公式サイトにはいろいろな花のテクニックがあります.https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#using-roles
様々な花のテクニック:
キャラクタ依存性により、キャラクタを使用するときに自動的に他のキャラクタを追加できます.ロール依存定義はmeta/main.ymlファイルのdependenciesの下には、現在のロールの依存ロールと依存ロールのパラメータリストが含まれています.プロファイルの例:
---
dependencies:
- role: common
vars:
some_parameter: 3
- role: apache
vars:
apache_port: 80
- role: postgres
vars:
dbname: blarg
other_parameter: 12
ロールの依存関係は、metaファイルのkey、すなわちdependenciesにすぎません.他のキーとallowduplicates、これは定義ロールがタスクを繰り返し実行できることです.他のキーは一時的にドキュメントに表示されません.
ロールにモジュールとプラグインを埋め込む
「≪ディレクトリ構造|Directory Structure|emdw≫」には、ロールが使用する基本ディレクトリ名がリストされます.ここのカスタムモジュールとプラグインもrolesディレクトリの下にあるロール名サブディレクトリに配置されています.新しいディレクトリ構造:
roles/
webservers/
tasks/
defaults/
meta/
library/
module1
module2
filter_plugins
filter1
filter2
Webserversロールの下にカスタムモジュールが追加され、ディレクトリ名はlibraryを使用します.ansibleのプラグインにはいろいろありますが、ここではwebserverロールの下でfilterプラグインに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 ,
ここのカスタムモジュールとプラグインはプロジェクトディレクトリの下にあり、自動的に有効になりません.libraryのデフォルト:
~/.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 修正できるcfgプロファイルは、デフォルトのホームディレクトリの場所を使用してソフト接続を作成することもできます.