ビッグデータプラットフォームの展開における自動化された運用および保守ツールであるAnsibleの適用（下記）

1.プレイブックとファイル形式の紹介
プレイブックは文字通りスクリプトを意味します。実際には、アクターはスクリプトに従って実行します。Ansibleでは、今回のパフォーマンスはコンピューターによって実行されます。コンピューターは、アプリケーションのインストールと展開、外部サービスの提供、および整理を行います。いろいろなものを扱うコンピュータ。
プレイブックファイルはYMAL言語で書かれています。YMAL形式はJSONファイル形式に似ており、理解、読み取り、書き込みが簡単です。まず、YMALの形式を理解することを学びます。これは、後でプレイブックを書くのに非常に役立ちます。以下は、プレイブックで一般的に使用されるYMAL形式のルールです。
ファイルの最初の行は「---」（3つのハイフン）で始まり、YMALファイルの始まりを示します。
同じ行の＃の後のコンテンツは、シェル、Python、Rubyと同様に、コメントを表します。
リストYMALの場合要素は「-」で始まり、スペース、要素の内容が続きます。
同じリスト内の要素は同じインデントを維持する必要があります。そうでない場合はエラーとして扱われます。
ホスト、変数、役割、タスクplayこのようなオブジェクトの表現方法は、キー値の中央で「：」で区切られ、「：」の後にスペースが追加されます。
最初に次の例を見てください。

- apple
- banana
- orange

JSONと同等の次の形式：

[
 “apple”,
 “banana”,
 “orange”
]

プレイブックファイルは、プレイブックファイルの内容を上から下に順番に実行するansible-playbookコマンドを介して解析されます。
2.
プレイブックの構成プレイブックは、1つ以上の「プレイ」で構成されるリストです。playの主な機能は、以前にマージされたホストをグループに結合して、Ansibleによって以前に定義された役割にすることです。プレイブックで複数のプレイを整理すると、それらをリンクして、事前に設定されたメカニズムに従って一連の複雑なタスクを完了することができます。
プレイブックは、主に次の4つの部分で構成されます。
ターゲット部分は、プレイブックを実行するリモートホストグループを
定義します。変数部分は、プレイブックの実行時に使用する必要のある変数を定義します。
タスク部分、リモートホストで実行されるタスクのリストを定義します。
ハンドラー部分は、タスクの実行が完了した後に呼び出す必要があるタスクを定義します。
以下に、プレイブックを構成する4つのコンポーネントについて説明します。
（1）Hosts and Users
プレイブックの各プレイの目的は、1つまたは複数のリモートホストが指定されたユーザーとしてタスクを実行できるようにすることです。
ホスト：タスクを実行するリモートホストを指定するために使用されます。各プレイブックはホストを指定する必要があり、ホストはワイルドカード形式を使用することもできます。ホストまたはホストグループはインベントリリスト（hostsファイル）で指定されます。システムのデフォルトの/ etc / ansible / hostsを使用することも、自分で編集することもできます。実行時に-iオプションを追加して、カスタムの場所を指定します。ホストリスト。
remote_user：リモートホストでタスクを実行するユーザーを指定するために使用します。任意のユーザーを指定することも、sudoを使用することもできますが、ユーザーは対応するタスクを実行する権限を持っている必要があります。
（2）
タスクリスト再生の主要部分はタスクリストであり、各タスクがホストで1つずつ指定され、すべてのリモートホストで実行されます。つまり、最初のタスクが完了した後に2番目のタスクが開始されます。すべてのリモートホスト。トップダウンプレイブックを実行しているときに、途中でエラーが発生した場合、実行されたすべてのタスクがロールバックされるため、プレイブックを修正した後、再度実行する必要があります。
タスクの目的は、指定されたパラメーターを使用してモジュールを実行することであり、変数はモジュールパラメーターで使用できます。モジュールはコマンドを実行しますが、1回以上実行しても結果は同じです。つまり、結果が一貫しているため、プレイブックは複数回実行しても安全です。タスクには、名前と実行するモジュールが含まれています。名前は、ユーザーが読みやすいようにオプションです。モジュールが必須であり、対応するパラメーターを同時にモジュールに指定する必要があることを追加することをお勧めします。 。
タスクを定義するには、module：options形式を使用することをお勧めします。例：

service: name=httpd state=running

（3）ハンドラーは
、関係するリソースが変更されたときに特定のアクションを実行するために使用されます。ハンドラーと「通知」は一緒に使用されます。「通知」アクションは、各再生実行の最後にトリガーするために使用できます。これにより、複数の変更が発生するたびに指定された操作を実行する必要がなくなります。「通知」を使用すると、すべての変更が発生した後に1回だけ指定された操作を実行します。性的に。
notifyにリストされている操作はハンドラーと呼ばれます。つまり、notifyは、ハンドラーで定義されている操作を呼び出すために使用されます。
注：通知で定義されたコンテンツは、トリガー効果を実現するために、ハンドラーで定義された「-name」コンテンツと同じである必要があります。そうでない場合、効果はありません。
（4）タグは
、ユーザーがプレイブックのコードの一部を実行するかスキップするかを選択できるようにするために使用されます。Ansibleはべき等であるため、変更されていない部分は自動的にスキップされますが、プレイブックに多くのタスクがある場合、各部分が1つずつ変更されているかどうかを判断するのに長い時間がかかります。したがって、一部の部分が変更されていないことが確実な場合は、タグを介してこれらのコードスニペットをスキップできます。
3.プレイブックの実行結果の分析
ansible-playbookを使用してプレイブックファイルを実行します。出力コンテンツはJSON形式であり、簡単に識別できるようにさまざまな色で構成されています。一般的に、出力内容において、各色の意味は次のとおりです。
緑は実行は成功したがシステムはそのままであることを
意味し、黄色はシステムステータスが変更されたこと、つまり実行された操作が有効であることを意味します。
赤は実行が失敗したことを意味し、エラーメッセージが表示されます。
簡単なプレイブックファイルは次のとおりです。

- name: create user
  hosts:192.168.1.31
  user: root
  gather_facts: false
  vars:
    user1: testuser
  tasks:
   - name: start createuser
     user: name="{
   
   {user1}}"

上記のプレイブックで実装されている機能は、新しいユーザーを追加することです。各パラメーターの意味は次のとおりです。

• nameパラメータは、プレイブックによって実装される関数の概要を示します。その後の実行中に、nameの値が出力されます。

• hostsパラメーターは、操作するホストを指定します。

• userパラメーターは、操作のためにリモートホストにログインするために使用されるユーザーを指定します。

• collect_factsパラメーターは、タスクタスクを実行する前にセットアップモジュールを実行してホスト関連情報を取得するかどうかを指定します。このパラメーターのデフォルト値はtrueであり、オンになっていることを意味します。ファクト情報がタスクで使用される場合、この関数はオンにする必要があります。それ以外の場合はfalseに設定されます。これにより、プレイブックの実行速度が向上する可能性があります。

• varsパラメーターは変数を指定します。これは値がtestuserであるuser1変数です。変数値は引用符で囲む必要があることに注意してください。

• タスクはタスクを指定します。以下の名前パラメーターはタスクの説明でもあり、実行中に出力されます。ユーザーはモジュールであり、次の名前はユーザーモジュールのパラメーターであり、追加されたユーザー名は上記を呼び出します。 user1変数の値。

4.
プレイブックのタスク構文は、プレイブックで使用されます。タスク部分は、タスク全体の中核です。コマンド、シェル、ファイル、cron、ユーザー、その他のモジュールなど、上記で紹介した一般的なansibleモジュールは引き続き使用できます。のパラメータと意味はコマンドラインモードとまったく同じですが、記述が異なります。
いくつかの例を通して、プレイブックの一般的な汎用モジュールの記述を見てみましょう。
（1）Playbookの例
以下はPlaybookの例です。test.ymlファイルの内容は次のとおりです。

- hosts: hadoophosts
  remote_user: root
  tasks:
   - name: create hadoop user
     user: name=hadoop state=present
   - name: create hadoop directory and chmod/chown
     file: path=/opt/hadoop state=directory mode=0755 owner=hadoop group=hadoop
   - name: synchronize hadoop program
     synchronize: src=/data/hadoop/ dest=/opt/hadoop
   - name: Setting environment variables
     shell: echo "export JAVA_HOME=/usr/jdk" >> /etc/profile

プレイブックファイルでは、ユーザー、ファイル、同期、シェルモジュールが使用されます。ファイルはホストグループhadoophostsの定義を開始し、リモートホストで操作を実行するようにルートユーザーを設定します。次はタスクタスクの開始です。、「-name」は説明情報であり、タスクの実行内容と進行状況を識別するために使用されます。最初のタスクは、ユーザーモジュールを使用してhadoopユーザーを作成するために使用されます。
このファイルから、プレイブックモードで記述されたファイルの方が簡潔でわかりやすいことがわかります。タスクの実行戦略と順序が設定されていれば、この操作を使用するたびに直接実行できます。実行方法は次のとおりです。
コピーの生成

ansible-playbook  test.yml

以前に紹介されたansibleモジュールに加えて、プレイブックでよく使用されるモジュールがいくつかあります。一般的に使用されるプレイブックモジュールをいくつか示します。

（2）unarchiveモジュール
このモジュールは、解凍、つまり圧縮ファイルを解凍してさまざまなリモートノードに配布するために使用されます。次のパラメータを覚えておいてください：
src、ソースファイルパス、このソースファイルは管理マシン上にあります;
dest、指定リモートホストのファイルパス;
モードで、リモートホストのファイル権限を設定します。
次の例を見てください。

- hosts: 192.168.1.31
  remote_user: root
  gather_facts: false
  tasks:
   - name: unarchive spark files
     unarchive: src=/src/spark.tar.gz dest=/opt

この操作では、管理マシン上の/src/spark.tar.gzファイルをリモートホストに転送して解凍し、解凍したファイルをリモートホストの/ optディレクトリに配置します。この例では、gather_factsオプションをfalseに設定していることに注意してください。これは、以下のタスクではファクト情報が使用されていないためです。
（3）lineinfile、replace module
自動化された操作と保守では、オペレーティングシステムの特定のパラメーターの変更、削除、追加など、ファイルのコンテンツを置き換えることは非常に一般的なシナリオです。Ansibleは、置換の効果を実現するためにsedコマンドと組み合わせたシェルモジュールを提供しますが、回避する必要のある問題が発生することが多く、読みやすさや保守性などの多くの要因を考慮すると、Ansibleに付属の置換モジュールが適しています。Ansibleで一般的に使用される置換モジュールはreplaceとlineinfileです。
replaceモジュールは、指定された正規表現に従って、リモートホストの下のファイル内のコンテンツを置き換えることができます。一般的に使用されるパラメーターを次の表に示します。

次の例を見てください。

- hosts: 192.168.1.31
  remote_user: root
  tasks:
   - name: modify selinux
     replace: path=/etc/selinux/config regexp="enforcing" replace=disabled backup=yes

この操作は、リモートホストの/ etc / selinux / configファイル内の強制文字列を置き換え、無効に置き換え、置き換え前にバックアップを作成することです。実際には、リモートホストのselinuxサービスを閉じます。 

 lineinfile、このモジュールはreplace関数も実装できますが、lineinfileはより強力で、より多くのパラメーターをサポートします。一般的なパラメーターの意味を次の表に示します。

lineinfileに基づくプレイブックタスクを見てみましょう。

- hosts: 192.168.1.31
  remote_user: root
  tasks:
   - lineinfile: dest=/etc/profile insertafter='ulimit(.*)' line="ulimit -c unlimited"
   - lineinfile: dest=/etc/profile line="export JAVA_HOME=/usr/jdk"
   - lineinfile: dest=/etc/selinux/config regexp='SELINUX=(.*)' line='SELINUX=disabled'
   - lineinfile: dest=/etc/resolv.conf regexp='search(.*)' state=absent

プレイブックタスクでは、lineinfile置換操作が4回呼び出されました。最初は、/ etc / profileファイルでulimitで始まる行を見つけ、最後に「ulimit-cunlimited」というコンテンツの行を追加しました。 2回目は/ etc / profileファイルの最後にJAVA_HOMEパスを追加します。3回目は、/ etc / selinux / configファイルの「SELINUX =」で始まる行を変更して「SELINUX = disabled」に置き換えます。 "、これは実際にはselinuxを閉じています。最後の操作は/etc/resolv.confファイルでsearchで始まる行を見つけて、それを削除することです。
（4）レジスタ、set_fact、およびデバッグモジュール
Ansibleで変数を定義する方法はたくさんあります。モジュールの実行結果を変数として登録したり、ロール内のファイルで変数を定義したり、を使用したりすることもできます。組み込み変数など、登録時に、両方のset_factを使用して変数を登録できます。
登録オプションを使用すると、現在のタスクの出力結果を変数に割り当てることができます。次の例を参照してください。

- hosts: 192.168.1.41
  remote_user: root
  tasks:
   - name: ps command
     shell: hostname
     register: host_result
   - debug: var=host_result

この例では、リモートホストで実行されたシェルコマンド「hostname」の出力結果が変数host_resultに割り当てられ、変数が参照され、デバッグモジュールを使用して出力されます。出力結果はjson形式です。この例では、最後にデバッグモジュールも使用していることに注意してください。このモジュールは、デバッグ中に情報を出力するために使用されます。
プレイブックのデバッグ出力は次のとおりです。

PLAY [192.168.1.41] *******************************************************************************************

TASK [Gathering Facts] ****************************************************************************************
ok: [192.168.1.41]

TASK [ps command] *********************************************************************************************
skipping: [192.168.1.41]

TASK [debug] **************************************************************************************************
ok: [192.168.1.41] => {
    "host_result": {
        "changed": false, 
        "failed": false, 
        "msg": "skipped, running in check mode", 
        "skipped": true
    }
}

PLAY RECAP ****************************************************************************************************
192.168.1.41               : ok=2    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0   

[root@namenodemaster ansible]# 

この出力はjson形式のデータであることがわかります。一番上のキーはhost_resultで、中括弧には複数の2次キーがあります。必要な結果は、リモートホストのホスト名を出力することです。他のものはありません。追加の二次キー情報を使用してこの要件を達成するにはどうすればよいですか？jsonデータの特定の2次キー項目を出力する場合は、「key.dict」または「key ['dict']」を使用して引用できます。
上記の出力からわかるように、必要な2次キーはstdoutアイテムであるため、このコンテンツのみを出力するには、host_result.stdoutへの変数参照を変更できます。つまり、上記のプレイブックタスクを次のコンテンツに変更します。

- hosts: 192.168.1.41
  remote_user: root
  tasks:
   - name: hostname command
     shell: hostname
     register: host_result
   - debug: var=host_result.stdout
   - debug: 'msg="output: {
   
   {host_result.stdout}}"'

プレイブックでは、デバッグパラメータが追加されています。デバッグモジュールで一般的に使用される2つのパラメータ、つまりmsgとvarがあり、どちらも変数を参照して情報を出力できますが、少し違いがあります。msgはカスタム情報を出力できます。変数はdoubleである必要があります。中括弧が含まれています。varパラメーターは変数のみを出力でき、double中括弧は必要ありません。

変更されたプレイブックのデバッグ出力は次のとおりです。

PLAY [192.168.1.41] ****************************************************************************************************************************************

TASK [Gathering Facts] *************************************************************************************************************************************
ok: [192.168.1.41]

TASK [hostname command] ************************************************************************************************************************************
changed: [192.168.1.41]

TASK [debug] ***********************************************************************************************************************************************
ok: [192.168.1.41] => {
    "host_result.stdout": "yarnserver"
}

TASK [debug] ***********************************************************************************************************************************************
ok: [192.168.1.41] => {
    "msg": "output: yarnserver"
}

PLAY RECAP *************************************************************************************************************************************************
192.168.1.41               : ok=4    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0  

出力から、これが私たちが望む結果であることがわかります。

set_factとregisterの関数は非常に似ており、タスク出力を変数に割り当てることもできます。set_factは、シェルで変数を割り当てる方法に似ています。変数の値を別の変数に割り当てることも、文字列を変数に割り当てることもできます。次の例を見てください。

- hosts: 192.168.1.41
  remote_user: root
  tasks:
   - name: hostname command
     shell: hostname
     register: host_result
   - set_fact: var1="{
   
   {host_result.stdout}}"
   - set_fact: var2="This is a string"
   - debug: msg="{
   
   {var1}}  {
   
   {var2}}"

この例では、hostnameの出力結果をhost_result変数に割り当て、次にhost_result変数をset_factを介してvar1変数に割り当て、次に文字列をvar2変数に割り当て、最後にデバッグモジュールを介して変数情報を出力します。これらのモジュールの使用法と書き込み形式に注意してください。

このプレイブックの出力は次のとおりです。

PLAY [192.168.1.41] ****************************************************************************************************************************************

TASK [Gathering Facts] *************************************************************************************************************************************
ok: [192.168.1.41]

TASK [hostname command] ************************************************************************************************************************************
changed: [192.168.1.41]

TASK [set_fact] ********************************************************************************************************************************************
ok: [192.168.1.41]

TASK [set_fact] ********************************************************************************************************************************************
ok: [192.168.1.41]

TASK [debug] ***********************************************************************************************************************************************
ok: [192.168.1.41] => {
    "msg": "yarnserver  This is a string"
}

PLAY RECAP *************************************************************************************************************************************************
192.168.1.41               : ok=5    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0  

（5）delegate_to、connection、local_actionモジュール
Ansibleは、デフォルトではリモートホストでのみ操作を実行しますが、管理マシンのローカルマシンでいくつかの操作を実行する必要がある場合は、それを実装する方法がたくさんあります。デリゲート_to（タスク委任）を介して達成できます。connection：localメソッドを介して、またlocal_actionキーワードを介して達成することもできます。

それらの使用法を説明するために例を見てみましょう

- hosts: 192.168.1.41
  remote_user: root
  gather_facts: true
  tasks:
   - name: connection
     shell: echo "connection . {
   
   {inventory_hostname}} $(hostname) ." >> /tmp/local.log
     connection: local
   - name: delegate_to
     shell: echo "delegate_to . {
   
   {inventory_hostname}} $(hostname) ." >> /tmp/local.log
     delegate_to: localhost
   - name: local_action
     local_action: shell echo "local_action. {
   
   {inventory_hostname}} $(hostname)" >> /tmp/local.log

この例では、connection、delegate_to、local_actionの3つのメソッドを順番に使用し、 Ansibleの組み込み変数である変数{ {inventory_hostname}}を使用して、リモートホストのホスト名を取得します。ホスト名に関しては、これは実用的なファクト情報であるため、gather_factsオプションをtrueに設定する必要があります。また、$（hostname）はシェル内の変数であり、ホスト名の取得にも使用されます。この例の機能は、リモートホストのホスト名をの/tmp/local.logファイルに出力することです。順番に管理マシン。

ビッグデータの運用および保守環境におけるAnsible-playbookアプリケーションの事例

1.ホスト名をバッチで変更し、ローカル解像度を生成します

ビッグデータの運用・保守環境では、ホスト名の要件が比較的厳しいため、ビッグデータノードのホスト名を一元的に計画し、一元的に設定する必要があります。DNS解決サーバーがローカルに確立されていない場合は、各ノードにローカル解決を追加する必要があります。つまり、各ノードのIPとホスト名の間の対応を/ etc / hostsファイルに追加します。これらの2つの問題を解決するには、2つのプレイブックスクリプトだけで自動的に完了します。

各ノードのホスト名をバッチで変更するには、最初にansibleの/ etc / ansible / hostsファイルの内容を変更し、次の構成を追加する必要があります。

[hostall]
192.168.1.31 hostname=namenodemaster
192.168.1.41 hostname=yarnserver
192.168.1.70 hostname=salve001
192.168.1.103 hostname=slave002
192.168.1.169 hostname=slave003

ここでは、hostallという名前のホストグループが定義されています。グループには3つのホストがあります。各ホストIPの後にホスト名変数が続きます。変数が定義されたホスト名になった後、この変数はプレイブックスクリプトで直接参照できます。

次に、プレイブックスクリプトを作成できます。内容は次のとおりです。

- hosts: hostall
  remote_user: root
  tasks:
    - name: change name
      shell: "echo {
   
   {hostname}} > /etc/hostname"
    - name:
      shell: hostname {
   
   {hostname}}

その中で、変数{ {hostname}}とその値は、/ etc / ansible / hostsファイルで定義されている「hostname = namenodemaster」の内容です。シェルモジュールを使用することにより、定義されたホスト名が各リモートホスト（RHEL / Centos7 / 8システムに限定）の/ etc / hostnameファイルに追加され、hostnameコマンドが実行されて有効になります。実行プロセスは次のとおりです。次のとおりです。

PLAY [hostall] ************************************************************************************************

TASK [Gathering Facts] ****************************************************************************************
ok: [192.168.1.41]
ok: [192.168.1.31]
ok: [192.168.1.169]
ok: [192.168.1.103]
ok: [192.168.1.70]

TASK [change name] ********************************************************************************************
changed: [192.168.1.41]
changed: [192.168.1.31]
changed: [192.168.1.103]
changed: [192.168.1.70]
changed: [192.168.1.169]

TASK [shell] **************************************************************************************************
changed: [192.168.1.41]
changed: [192.168.1.31]
changed: [192.168.1.169]
changed: [192.168.1.70]
changed: [192.168.1.103]

PLAY RECAP ****************************************************************************************************
192.168.1.103              : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
192.168.1.169              : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
192.168.1.31               : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
192.168.1.41               : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
192.168.1.70               : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0  

各ホスト名を変更した後、ローカル解決ファイル（IPとホスト名に対応するファイル）を作成し、各リモートホストに送信する必要があります。この機能を実現するには、次のプレイブックスクリプト、コンテンツを記述します。以下のとおりであります

- hosts: hostall
  remote_user: root
  roles:
  - roles
  tasks:
   - name: add localhost
     local_action: shell echo "127.0.0.1   localhost" > {
   
   {AnsibleDir}}/roles/templates/hosts.j2
     run_once: true
   - set_fact: ipaddress={
   
   {hostvars[inventory_hostname].ansible_default_ipv4.address}}
   - set_fact: hostname={
   
   {hostvars[inventory_hostname].ansible_facts.hostname}}
   - name: add host record
     local_action: shell echo {
   
   {ipaddress}} {
   
   {hostname}} >> {
   
   {AnsibleDir}}/roles/templates/hosts.j2
   - name: copy hosts.j2 to allhost
     template: src={
   
   {AnsibleDir}}/roles/templates/hosts.j2 dest=/etc/hosts

プレイブックでは、ロールの変数が使用されているため、次の図に示すように、ansibleのデフォルトのディレクトリ構造を理解してください。

[root@namenodemaster ansible]# tree
.
├── ansible.cfg
├── hosts
└── roles
    ├── files
    │   ├── conf.tar.gz
    │   ├── hadoop.tar.gz
    │   ├── jdk.tar.gz
    │   └── zookeeper.tar.gz
    ├── templates
    │   ├── authorized_keys.j2
    │   ├── hosts.j2
    │   └── zoo.cfg.j2
    └── vars
        └── main.yml

4 directories, 10 files

このプログラムは/ etc / ansibleコマンドの下にインストールされます。このディレクトリには、ファイル、テンプレート、ロールの3つのサブディレクトリがあります。ファイルディレクトリは、主にコピーするリモートホストのいくつかのプログラムファイルを格納し、テンプレートディレクトリストアに均一にリモートホストにコピーされますいくつかの構成されたテンプレートファイルを、; main.ymlファイルを使用するための役割ディレクトリに作成された定義しますロール変数、main.ymlで変数を定義する方法は次のとおりです。

server1_hostname: 192.168.1.70
server2_hostname: 192.168.1.103
server3_hostname: 192.168.1.169
AnsibleDir: /etc/ansible
BigdataDir: /opt/bigdata
hadoopconfigfile: /etc/hadoop

その中で、コンテンツの各行のコロンの前部は変数名であり、後部は変数の値です。変数が定義された後、それはプレイブックで参照できます。

最後に、ロール変数を使用するため、上記のプレイブックファイルに戻り、rolesキーワードを導入します。次に、タスクタスクでは、local_actionモジュールが最初に使用され、テンプレートファイルhosts.j2が管理マシンで生成されます。変数{ {AnsibleDir}}がmain.ymlで定義され、run_onceがローカルシェルを表すことに注意してください。 一度だけ実行されます。次に、set_factを介して2つの変数ipaddressとhostnameが定義されます。どちらも、ansible組み込み変数から特定の値を取得し、取得したipaddressとhostnameの値をhosts.j2ファイルに書き込みます。管理マシン上;最後の操作手順は、hosts.j2テンプレートファイルをテンプレートモジュールを介してリモートホストの/ etc /ディレクトリにコピーし、名前をhostsファイルに変更することです。

このスクリプトを/ etc / ansibleディレクトリに置き、hosts.ymlという名前を付けてから、次のコマンドを実行します。

ansible-playbook  hosts.yml

実行が成功した場合は、緑と薄黄色の出力プロンプトが表示されます。実行が失敗した場合は、赤の出力内容を確認して、検査の問題を判断できます。

2.ホストはSSHの信頼を自動的に確立します

ビッグデータ環境では、インストール、構成、メンテナンスの利便性のために、管理マシン（Ansibleがインストールされているマシン）と各クラスターノード間のパスワードなしのログイン（一方向の信頼）が一般的にセットアップされ、最も簡単な方法ですパスワードなしでログインするにはSSHの公開鍵と秘密鍵の認証メカニズムを設定します。

次のプレイブックスクリプトは、管理マシンからリモートホストグループhostallへのパスワードなしのログインを完了することができます。スクリプトの内容は次のとおりです。

- hosts: hostall
  gather_facts: no
  roles:
   - roles
  tasks:
   - name: close ssh yes/no check
     lineinfile: path=/etc/ssh/ssh_config regexp='(.*)StrictHostKeyChecking(.*)' line="StrictHostKeyChecking no"
   - name: delete /root/.ssh/
     file: path=/root/.ssh/ state=absent
   - name: create .ssh directory
     file: dest=/root/.ssh mode=0600 state=directory
   - name: generating local public/private rsa key pair
     local_action: shell ssh-keygen -t rsa -N ''  -f /root/.ssh/id_rsa
   - name: view id_rsa.pub
     local_action: shell cat /root/.ssh/id_rsa.pub
     register: sshinfo
   - set_fact: sshpub={
   
   {sshinfo.stdout}}
   - name: add sshkey
     local_action: shell echo {
   
   {sshpub}} > {
   
   {AnsibleDir}}/roles/templates/authorized_keys.j2
   - name: copy authorized_keys.j2 to all hosts
     template: src={
   
   {AnsibleDir}}/roles/templates/authorized_keys.j2 dest=/root/.ssh/authorized_keys mode=0600
     tags:
     - copy sshkey

このプレイブックはもう少し複雑ですが、ロール変数を使用しているため、このスクリプトは/ etc / ansibleディレクトリに配置する必要があります。スクリプトはlineinfileモジュールを使用して、リモートホスト上のsshd構成ファイルssh_configを置き換えます。この置き換えは閉じられます。 SSH経由で初めてログインするときに表示される「yes / no」プロンプト。

次に、リモートホストの/root/.sshディレクトリを削除し、このディレクトリを再作成します。この操作の目的は、リモートホストの/root/.sshディレクトリがクリーンで、正しい権限を持っていることを確認することです。

次に、local_actionモジュールを使用して、管理マシンで公開鍵と秘密鍵のペアを生成すると同時に、生成された公開鍵ファイルの内容を変数sshinfoの値として使用し、set_factモジュールを介して変数sshpubを再定義します。変数は、最終的な公開鍵値であるsshinfo変数のstdout出力を参照し、変数sshpubの内容を管理マシンのauthorized_keys.j2テンプレートファイルに書き込みます。

最後に、テンプレートモジュールを使用して、authorized_keys.j2テンプレートファイルを各リモートホストの/root/.sshディレクトリにコピーし、名前をauthorized_keysに変更して、所有者にファイルの読み取りおよび書き込み権限を付与します。

このスクリプトを/ etc / ansibleディレクトリに置き、ssh.ymlという名前を付けてから、次のコマンドを実行します。

 ansible-playbook  ssh.yml -k

3.JDKの自動インストール

JDKの自動インストールは、ビッグデータの運用と保守で最も一般的なシナリオです。通常、バイナリバージョンをダウンロードして解凍して使用できます。したがって、JDKをインストールするプロセスは、ダウンロードしたJDKプログラムをリモートホストにコピーするプロセスです。インストールが完了したら、JAVA_HOMEをシステム環境変数に追加して、インストールされたJDKをシステムに認識させます。

次のプレイブックファイルは、JDKのインストールを自動化するプロセス全体であり、内容は次のとおりです。

- hosts: hostall
  remote_user: root
  roles:
  - roles
  tasks:
   - name: mkdir jdk directory
     file: path={
   
   {BigdataDir}} state=directory mode=0755
   - name: copy and unzip jdk
     unarchive: src={
   
   {AnsibleDir}}/roles/files/jdk.tar.gz dest={
   
   {BigdataDir}}
   - name: set env
     lineinfile: dest=/etc/profile line="{
   
   {item.value}}" state=present
     with_items:
     - {value: "export JAVA_HOME={
   
   {BigdataDir}}/jdk"}
     - {value: "export PATH=$JAVA_HOME/bin:$PATH"}
   - name: chmod bin
     file: dest={
   
   {BigdataDir}}/jdk/bin mode=0755 recurse=yes
   - name: enforce env
     shell: source /etc/profile

このスクリプトのBigdataDirとAnsibleDirはすべてロール変数です。特定のパスは以前に定義されています。その中で、jdk.tar.gzは管理マシンにあります。スクリプトは最終的にJDK環境変数を/ etc / profileに書き込みます。 item.value変数。ファイルの最後で、この変数の定義と参照メソッドに注意が必要です。

このスクリプトを/ etc / ansibleディレクトリに置き、jdk.ymlという名前を付けてから、次のコマンドを実行します。

 ansible-playbook  jdk.yml

スクリプトが正常に実行されると、JDKと環境変数が構成されます