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のディレクトリ構造を定義します.
site.yml
webservers.yml
fooservers.yml
roles/
    common/
        tasks/
        handlers/
        files/
        templates/
        vars/
        defaults/
        meta/
    webservers/
        tasks/
        defaults/
        meta/
  • *.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/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
    様々な花のテクニック:
  • roleをtasksに書きます.これは新しい文法フォーマットです.別のtask
  • は、roleの導入前後で実行することができる.
  • 絶対パスを使用してrole
  • に導入する.
  • roleを導入するとともに、変数
  • を定義する.
  • 条件付きでroleを導入し、上の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プロファイルは、デフォルトのホームディレクトリの場所を使用してソフト接続を作成することもできます.