juniper.device.config Ansibleモジュールを使用して、Junos OS構成を管理します
juniper.device.config Ansibleモジュールを使用して、Junos OSを実行しているデバイスとJunos OS Evolvedを実行しているデバイスの設定を管理できます。
ジュニパーネットワークスは、Junosデバイスを設定できるAnsibleモジュールを提供しています。 表1は 、利用可能なモジュールの概要を示しています。 juniper.device コレクションの特定のモジュール セットを既に使用している場合は、そのセットの モジュール を使用します。
|
コレクション |
モジュールセット |
モジュール名 |
|---|---|---|
|
|
||
|
|
juniper.device.junos_config |
次のセクションでは、 juniper.device.config モジュールを使用して、Junosデバイスの設定を変更およびコミットする方法について説明します。 juniper.device.junos_config モジュールについては、 juniper.device.junos_config Ansibleモジュールを使用したJunosデバイスの設定を参照してください。
モジュールの概要
juniper.device.configモジュールでは、Junosデバイス上で以下の操作を実行できます。
-
設定データの読み込み
-
設定をコミットします
-
設定をロールバックする
-
レスキュー設定を読み込みます
設定変更を行う基本的なプロセスは、設定をロックし、設定変更を読み込み、設定をコミットしてアクティブにしてから、設定のロックを解除することです。設定の変更に使用されるユーザーアカウントには、各デバイスで設定の関連部分を変更するための権限が必要です。設定を変更するには、モジュールの引数リストに次のいずれかのパラメーターが含まれている必要があります。
-
load—新しい設定データを読み込みます。 -
rollback—レスキュー設定または以前にコミットされた設定に戻します。
デフォルトでは、 juniper.device.config モジュール configure exclusive モードを使用して候補の構成データベースを変更し、候補のグローバル構成を自動的にロックおよびロック解除します。別の設定モードを指定することもできます。例えば、候補設定のプライベートコピーや一時設定データベースに変更を加えることができます。設定モードの指定についての詳細は、 設定モードの指定方法を参照してください。
新しい設定データを読み込む際、設定モードを指定するだけでなく、読み込み操作や変更のソースや形式を指定することもできます。
-
ロード操作—ロード操作は、選択した設定データベースに設定データをロードする方法を決定します。Junos OS CLI で利用可能なものと同じ読み込み操作の多くから選択できます。詳細については、「 ロードアクションを指定する方法」を参照してください。
-
フォーマット—サポートされている標準フォーマットのいずれかを使用して、Junosデバイスを設定できます。設定データまたはJinja2テンプレートは、テキスト、Junos XML要素、Junos OS
setコマンド、またはJSONとして提供できます。設定データの形式を指定する方法については、 ロードする設定データの形式を指定する方法を参照してください。 -
設定データソース—文字列のリスト、ローカルAnsible制御ノード上のファイル、Jinja2テンプレート、またはクライアントデバイスから到達可能なURLから設定データを読み込むことができます。設定データのソースを指定する方法については、次のセクションを参照してください。
juniper.device.configモジュールでは、レスキュー設定を読み込んでコミットしたり、以前にコミットした設定にロールバックしたりすることもできます。レスキュー設定または以前にコミットされた設定を読み込むには、rollback モジュール引数を含める必要があります。詳細については、次のセクションを参照してください。
設定を変更した後、デバイス上でアクティブな設定にするには、設定をコミットする必要があります。デフォルトでは、 juniper.device.config モジュールは設定への変更をコミットします。この動作を変更したり、追加のコミットオプションを提供するには、 設定のコミット方法を参照してください。
デフォルトでは、 juniper.device.config モジュールに load または rollback 引数が含まれている場合、モジュールの応答は設定変更を 差分 またはパッチ形式で自動的に返します。このモジュールは、 diff フィールドと diff_lines フィールドの違いを返します。モジュールが差異を計算して返さないようにするには、 diff モジュール引数を false に設定します。
設定モードを指定する方法
デバイス設定を変更する際に使用する設定モードを指定できます。タスクで設定モードを指定するには、モジュールの config_mode パラメーターを含めます。サポートされている設定モードは次のとおりです。
-
batch -
dynamic -
ephemeral -
exclusive -
private
デフォルトでは、 juniper.device.config モジュールは configure exclusive モードを使用して候補の構成データベースを変更します。排他設定モードは、モジュールが要求された設定変更を行う必要がある限り、候補となるグローバル設定( 共有設定データベースとも呼ばれます)をロックします。データベースをロックすると、他のユーザーが同時にデータベースを変更したり、データベースへの変更をコミットしたりできなくなります。
次の例は、候補設定のプライベートコピーを設定する方法と、一時データベースを設定する方法を示しています。
例:config_mode: "private"
次のプレイブックでは private 設定モードを使用して、候補の設定のプライベートコピーを変更します。
---
- name: Configure Device
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Configure op script
juniper.device.config:
config_mode: private
load: set
lines:
- "set system scripts op file bgp.slax"
register: response
- name: Print the config changes
ansible.builtin.debug:
var: response.diff_lines
user@ansible-cn:~/ansible$ ansible-playbook configure-script.yaml
PLAY [Configure Device] *******************************************************
TASK [Configure op script] ****************************************************
changed: [dc1a.example.net]
TASK [Print the config changes] ***********************************************
ok: [dc1a.example.net] => {
"response.diff_lines": [
"",
"[edit system scripts op]",
"+ file bgp.slax;"
]
}
PLAY RECAP ********************************************************************
dc1a.example.net : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
一時データベースを設定する
juniper.device.configモジュールを使用して、このデータベースをサポートするデバイス上のエフェメラル設定データベースを更新できます。エフェメラルデータベースは、Junosデバイスで設定更新を実行するための高速なプログラムインターフェイスを提供する代替設定データベースです。
エフェメラル設定データベースのデフォルトインスタンスを開いて設定するには、 config_mode: ephemeral 引数を含めます。次に例を示します。
---
- name: Configure ephemeral database
hosts: dc1a
connection: local
gather_facts: no
tasks:
- name: Configure the default ephemeral database
juniper.device.config:
config_mode: ephemeral
load: set
lines:
- "set protocols mpls label-switched-path to-hastings to 192.0.2.1"
エフェメラル設定データベースの既存のユーザー定義インスタンスを開いて設定するには、 config_mode: ephemeral 引数をインクルードし、 ephemeral_instance 引数をインスタンスの名前に設定します。
tasks:
- name: Configure a user-defined ephemeral instance
juniper.device.config:
config_mode: ephemeral
ephemeral_instance: eph1
load: set
lines:
- "set protocols mpls label-switched-path to-hastings to 192.0.2.2"
ロードアクションを指定する方法
juniper.device.configモジュールは、Junos OS CLIでサポートされているのと同じ読み込み操作の多くを使用して、設定変更の読み込みをサポートしています。読み込み操作を指定するには、モジュールのload引数を対応する読み込み操作の値に設定します。表 2 は、さまざまな荷重操作の引数値を要約したものです。
|
ロード操作 |
|
説明 |
|---|---|---|
|
|
|
読み込んだコンフィギュレーションを既存のコンフィギュレーションにマージします。 |
|
|
|
設定全体を読み込んだ設定に置き換えます。すべてのシステム プロセスが設定を解析します。 |
|
|
|
パッチ ファイルから設定データを読み込みます。 |
|
|
|
読み込んだコンフィギュレーションを既存のコンフィギュレーションとマージしますが、既存のコンフィギュレーションのステートメントを、 |
|
|
|
|
|
|
|
完全な設定を読み込み、既存の設定と比較します。候補となるコンフィギュレーションのうち変更された部分のみを置き換えます。コミット操作中は、影響を受けたシステム プロセスのみが新しい設定を解析します。 |
読み込むコンフィギュレーション・データのフォーマットを指定する方法
juniper.device.configモジュールでは、サポートされている標準フォーマットのいずれかを使用してJunosデバイスを設定できます。設定データを文字列またはファイルとして提供できます。ファイルには、設定データまたはJinja2テンプレートのいずれかを含めることができます。文字列、ファイル、またはJinja2テンプレート内で設定データを提供する場合、データのサポートされている形式には、テキスト、Junos XML要素、Junos OSsetコマンド、JSONが含まれます。
juniper.device.configモジュールは、lines引数内で文字列として提供した設定データの形式を自動検出しようとします。ただし、format引数を含めることで、文字列の書式を明示的に指定できます。ファイルまたはJinja2テンプレートで設定データを提供する場合は、データのフォーマットを指定する必要があります。ファイルに適切な拡張子を追加するか、format引数を含めます。
表3 は、設定データでサポートされている形式と、ファイル拡張子と format パラメーターに対応する値をまとめたものです。 format 引数を含めると、文字列の自動検出形式とファイル拡張子で示される形式の両方が上書きされます。
|
設定データ形式 |
ファイル拡張子 |
|
|---|---|---|
|
CLI設定ステートメント(テキスト) |
.conf |
|
|
JavaScript Object Notation(JSON) |
.json |
|
|
Junos OS |
.set |
|
|
Junos XML 要素 |
.xml |
|
モジュールの load 引数を override または updateに設定した場合、Junos OS set コマンド形式を使用することはできません。
設定データを文字列として読み込む方法
juniper.device.configモジュールでは、文字列のリストから設定データを読み込むことができます。設定データを文字列として読み込むには、適切なload引数とlines引数を含めます。lines引数は、読み込む設定データを含む文字列のリストを取ります。
モジュールは、 lines 設定データの形式を自動検出しようとします。ただし、 format 引数を含めることで、形式を明示的に指定できます。フォーマットの指定については、 ロードするコンフィギュレーション・データのフォーマットを指定する方法を参照してください。 format 引数を含めると、自動検出された形式が上書きされます。
次のプレイブックでは、2つのopスクリプトを設定してコミットします。この場合、linesの設定データがsetステートメント形式を使用しているため、load引数の値は'set'になりますJunos OS。
---
- name: Load and commit configuration
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Load configuration data using strings and commit
juniper.device.config:
load: set
lines:
- "set system scripts op file bgp.slax"
- "set system scripts op file bgp-neighbor.slax"
register: response
- name: Print the response
ansible.builtin.debug:
var: response
次のプレイブックでは、テキスト形式の設定データとともに lines を使用して同じステートメントを設定します。この場合、この例では load: "merge"を使用しています。
---
- name: Load and commit configuration
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Load configuration data using strings and commit
juniper.device.config:
load: merge
lines:
- |
system {
scripts {
op {
file bgp.slax;
file bgp-neighbor.slax;
}
}
}
register: response
- name: "Print the response"
ansible.builtin.debug:
var: response
ローカルファイルまたはリモートファイルから設定データを読み込む方法
juniper.device.configモジュールでは、ファイルから設定データを読み込むことができます。ファイルは、次のいずれかの場所に配置できます。
-
Ansible制御ノード
-
クライアントデバイス
-
クライアントデバイスから到達可能なFTPまたはHTTP URL
ファイルから設定データを読み込むときは、ファイルの場所とファイル内の設定データのフォーマットを指定する必要があります。サポートされている設定データ形式には、テキスト、Junos XML 要素、Junos OS set コマンド、JSON が含まれます。Jinja2テンプレートを含むファイルの読み込みについては、 Jinja2テンプレートを使用した設定データの読み込み方法を参照してください。
フォーマットを指定するには、モジュールの format パラメータを含めるか、設定データファイルに適切な拡張子を追加します。 format パラメーターを指定すると、ファイル拡張子によって示される形式が上書きされます。フォーマットの指定については、 ロードするコンフィギュレーション・データのフォーマットを指定する方法を参照してください。設定データJunos XML形式を使用する場合は、トップレベルの <configuration> タグでデータを囲む必要があります。
テキスト、Junos OS set コマンド、またはJSONとしてフォーマットされた設定データを、NETCONFセッション内で直接デバイスを設定する場合に必要なように、 <configuration-text>、 <configuration-set>、または <configuration-json> タグで囲む必要はありません。
表4 は、ファイルの場所を指定するために含めることができるモジュールパラメーターの概要を示しています。
|
モジュールパラメータ |
説明 |
|---|---|
|
|
|
|
|
|
Ansible制御ノード上のローカルファイルから設定データを読み込むには、 src 引数を設定データを含むファイルの絶対パスまたは相対パスに設定します。次に例を示します。
---
- name: Load and commit configuration
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Load configuration from a local file and commit
juniper.device.config:
load: merge
src: "build_conf/{{ inventory_hostname }}/junos.conf"
register: response
- name: Print the response
ansible.builtin.debug:
var: response
Junosデバイス上のファイル、またはFTPまたはHTTP URLから設定データを読み込むには、 url パラメーターを使用します。読み込むファイルのパスまたはURLを指定します。次に例を示します。
---
- name: Load and commit configuration
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Load configuration from a remote file and commit
juniper.device.config:
load: merge
url: "/var/tmp/junos.conf"
register: response
- name: Print the response
ansible.builtin.debug:
var: response
urlの値は、絶対または相対的なローカルファイルパス、FTPの場所、またはHTTP URLです。
-
ターゲットデバイス上のローカルファイルのファイルパスは、以下のいずれかの形式になります。
-
/path/filename—ローカルフラッシュディスクまたはハードディスクのいずれかにマウントされたファイルシステム上のファイル。
-
A:filename または a:path/filename—ローカルドライブ上のファイル。デフォルトのパスは /(ルートレベルディレクトリ)です。リムーバブル メディアは、MS-DOS または UNIX(UFS)形式にすることができます。
-
-
FTP サーバー上のファイルのファイル パスは、以下の形式になります。
ftp://username:password@hostname/path/filename -
HTTPサーバー上のファイルのファイルパスは、以下の形式になります。
http://username:password@hostname/path/filename
いずれの場合も、 path 変数のデフォルト値はユーザーのホームディレクトリです。絶対パスを指定するには、アプリケーションはパスを文字 %2Fで開始します。例: ftp://username:password@hostname/%2Fpath/filename。
Jinja2テンプレートを使用して設定データを読み込む方法
juniper.device.configモジュールにより、Ansibleコントロールノード上のJinja2テンプレートファイルから設定データをレンダリングし、Junosデバイス上で設定をロードしてコミットできます。Jinjaは、定義済みのテンプレートからドキュメントを生成できるPython用のテンプレートエンジンです。テンプレートは目的の言語のテキストファイルであり、式と変数を使用することで柔軟性を提供します。Jinja2テンプレートを使用して、ASCIIテキスト、Junos XML要素、Junos OSsetコマンド、JSONを含むサポートされている設定形式の1つで、Junos OS設定データを作成できます。Ansibleモジュールは、Jinja2テンプレートと提供の変数ディクショナリを使用して、設定データをレンダリングします。
Jinja2テンプレートを使用して設定データを読み込んでコミットするには、モジュールの引数リストに template パラメーターと vars パラメーターを含めます。
-
template—Jinja2テンプレートファイルのパス -
vars- Jinja2 テンプレートのレンダリングに必要なキーと値のディクショナリ
また、テンプレートのファイル拡張子がデータの形式を示していない場合は、 format パラメーターを含める必要があります。フォーマットの指定については、 ロードするコンフィギュレーション・データのフォーマットを指定する方法を参照してください。
例えば、 interfaces-mpls.j2 ファイルには、以下のJinja2テンプレートが含まれています。
interfaces {
{% for item in interfaces %}
{{ item }} {
description "{{ description }}";
unit 0 {
family {{ family }};
}
} {% endfor %}
}
protocols {
mpls {
{% for item in interfaces %}
interface {{ item }};
{% endfor %}
}
rsvp {
{% for item in interfaces %}
interface {{ item }};
{% endfor %}
}
}
juniper.device.configモジュールを使用してJinja2テンプレートを読み込むには、template引数をテンプレートファイルのパスに設定します。vars辞書のテンプレートで必要な変数を定義します。
次のプレイブックでは、Jinja2テンプレートと vars ディクショナリを使用して設定データをレンダリングします。 format パラメーターは、テンプレートファイル内の設定データの形式を示します。プレイブックは、ターゲットホストで設定をロードしてコミットします。
---
- name: Load and commit configuration
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Load a configuration from a Jinja2 template and commit
juniper.device.config:
load: merge
template: "build_conf/templates/interfaces-mpls.j2"
format: text
vars:
interfaces: ["ge-1/0/1", "ge-1/0/2", "ge-1/0/3"]
description: "MPLS interface"
family: "mpls"
register: response
- name: Print the response
ansible.builtin.debug:
var: response
このモジュールは、以下の設定データを生成します。このモジュールは、デバイス上の候補コンフィギュレーションにデータを読み込み、コミットします。
interfaces {
ge-1/0/1 {
description "MPLS interface";
unit 0 {
family mpls;
}
}
ge-1/0/2 {
description "MPLS interface";
unit 0 {
family mpls;
}
}
ge-1/0/3 {
description "MPLS interface";
unit 0 {
family mpls;
}
}
}
protocols {
mpls {
interface ge-1/0/1;
interface ge-1/0/2;
interface ge-1/0/3;
}
rsvp {
interface ge-1/0/1;
interface ge-1/0/2;
interface ge-1/0/3;
}
}
レスキュー設定の読み込み方法
レスキュー設定では、既知の動作設定や、いつでも復元できる既知の状態の設定を定義することができます。レスキュー設定は、既知の設定に戻す必要がある場合や、デバイス設定とバックアップ設定ファイルが修復できないほど損傷した場合の最後の手段として使用します。レスキュー設定を作成すると、デバイスは最後にコミットされた設定をレスキュー設定として保存します。
juniper.device.configモジュールにより、Junosデバイス上の既存のレスキュー設定に戻すことができます。デバイス上でレスキュー設定を読み込んでコミットするには、モジュールのrollback: rescue引数を含めます。次に例を示します。
---
- name: Revert to rescue configuration
hosts: dc1a
connection: local
gather_facts: no
tasks:
- name: Load and commit rescue configuration
juniper.device.config:
rollback: rescue
register: response
- name: Print response
ansible.builtin.debug:
var: response
設定をロールバックする方法
Junosデバイスには、プラットフォームに応じて、最後にコミットされた設定と最大49の以前の設定のコピーが保存されます。保存されている設定のいずれかにロールバックできます。この機能は、設定変更によって望ましくない結果が生じ、既知の動作する設定に戻したい場合に有効です。設定のロールバックは、デバイス上で設定を変更するプロセスと似ています。ただし、設定データを読み込む代わりにロールバックを実行します。つまり、候補の設定全体が以前にコミットされた設定に置き換えられます。
juniper.device.configモジュールにより、Junosデバイスで以前にコミットされた設定にロールバックできます。設定をロールバックしてコミットするには、モジュールのrollback引数を含め、ロールバック設定のIDを指定します。有効なID値は、0(最後にコミットされた設定の場合はゼロ)から、保存された以前の設定の数より少ない1(最大49)です。
次のプレイブックでは、最初に復元する設定のロールバックIDの入力を求めます。最初のタスクは、設定を要求されたバージョンにロールバックし、コミットします。2 番目のタスクでは、設定の違いを標準出力に出力します。
---
- name: Roll back the configuration
hosts: dc1a
connection: local
gather_facts: no
vars_prompt:
- name: "ROLLBACK"
prompt: "Rollback ID of the configuration to restore"
private: no
tasks:
- name: Roll back the configuration and commit
juniper.device.config:
rollback: "{{ ROLLBACK }}"
register: response
- name: Print the configuration changes
ansible.builtin.debug:
var: response.diff_lines
user@ansible-cn:~/ansible$ ansible-playbook configuration-rollback.yaml
Rollback ID of the configuration to restore: 1
PLAY [Roll back the configuration] ********************************************
TASK [Roll back the configuration and commit] *********************************
changed: [dc1a.example.net]
TASK [Print the configuration changes] ***************************************
ok: [dc1a.example.net] => {
"response.diff_lines": [
"",
"[edit interfaces]",
"- ge-0/0/0 {",
"- unit 0 {",
"- family mpls;",
"- }",
"- }"
]
}
PLAY RECAP ********************************************************************
dc1a.example.net : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
設定のコミット方法
デフォルトでは、 juniper.device.config モジュールを使用して設定を変更すると、モジュールは自動的にコミットチェックを実行し、変更をコミットします。モジュールがコミットチェックを実行したり、変更をコミットしたりしないようにするには、 check または commit 引数をそれぞれ falseに設定します。
また、Junos OS CLI で利用可能なものと同じオプションの多くを使用して、コミット操作をカスタマイズすることもできます。 表5 は、さまざまなコミットオプションを指定するために使用できるモジュール引数の概要を示しています。
|
モジュール引数 |
説明 |
|
|---|---|---|
|
|
コミットチェックを実行するか、以前確認されたコミット操作を確認します。 |
|
|
|
コミットチェックからコミット操作まで指定された秒数待ちます。 |
– |
|
|
そのコミット操作に対するコメントをシステムログファイルとデバイスのコミット履歴に記録します。 |
– |
|
|
設定変更をコミットするか、以前に確認されたコミット操作を確認します。 |
|
|
|
候補の設定に変更がない場合でも、設定をコミットします。 |
|
|
|
他のルーティングエンジンにオープンな設定セッションやコミットされていない設定変更がある場合でも、すべてのルーティングエンジンで設定を同期してコミットします。 |
|
|
|
すべてのルーティングエンジンの設定を同期し、コミットします。 |
|
|
|
最初のコミット後、指定された時間内にコミット操作を確認する必要があります。指定した時間内にコミットを確認しない場合は、以前にコミットした設定にロールバックします。
|
– |
|
|
指定された値をタイムアウトとして使用して、操作の完了を待ちます。 |
30秒 |
コミットコメント
設定をコミットするときに、コミットされた変更の目的を説明する簡単なコメントを含めることができます。変更を説明するコメントをログに記録するには、メッセージ文字列に comment: "comment string" 引数を含めます。
コミットチェック
デフォルトでは、 juniper.device.config モジュールはコミットチェックとコミット操作の両方を実行します。 check_commit_wait 引数は、コミットチェックとコミット操作の間の待機時間(秒)を定義します。デバイスがコミット チェック操作を完了し、コミット操作を開始する前に設定ロックを解除するのに十分な時間を確保する必要がある場合、この引数を含めます。コミットチェック操作が設定のロックを解除する前にデバイスがコミット操作を開始すると、コミット操作は失敗し、モジュールは CommitErrorを発行します。
空の変更をコミット
デフォルトでは、候補コンフィギュレーションとコミットされたコンフィギュレーションに違いがない場合、モジュールは変更をコミットしません。違いがない場合でもコミット操作を強制するには、引数 commit_empty_changes: true を含めます。
コミット同期
デバイスにデュアルルーティングエンジンがある場合、引数を含めることで、両方のルーティングエンジンの設定を同期してコミット commit_sync: true できます。他のルーティングエンジンにオープンな設定セッションやコミットされていない設定変更がある場合でも、 commit synchronize 操作を強制的に成功させるには、 commit_force_sync: true 引数を使用します。 commit_force_sync: true オプションを含めると、デバイスは設定を同期してコミットする前に、他のルーティングエンジン上のすべての設定セッションを終了します。
コミットの確認
最初のコミット後、指定された時間内にコミット操作を確認するように要求するには、confirmed: minutes引数を含めます。指定された制限時間内にコミットを確認しない場合、設定は自動的に以前にコミットされた設定にロールバックされます。許容範囲は 1 分から 65,535 分です。確認済みのコミット操作は、設定変更が正しく機能し、デバイスへの管理アクセスが妨げられないことを検証するのに役立ちます。変更によってアクセスができなくなったり、その他のエラーが発生した場合は、以前の設定への自動ロールバックにより、ロールバック期限が過ぎた後にデバイスへのアクセスが可能になります。コミット操作を確認するには、check: true または commit: true 引数を付けて juniper.device.config モジュールを呼び出します。
次のプレイブックでは、最初のタスクは設定を変更し、コミット チェックとコミット操作の間に 10 秒待ち、コミット操作が 5 分以内に確認されるように要求します。また、コミットに対するコメントもログに記録します。2つ目のタスクは、コミットを確認するための commit check 操作を発行します。実際のシナリオでは、最初のコミット後に検証タスクを実行し、タスクが特定の検証基準に合格した場合にのみコミット確認を実行する場合があります。
---
- name: Load configuration and confirm within 5 minutes
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Load configuration. Wait 10 seconds between check and commit. Confirm within 5 min.
juniper.device.config:
load: merge
format: text
src: "build_conf/{{ inventory_hostname }}/junos.conf"
check_commit_wait: 10
confirmed: 5
comment: "updated using Ansible"
register: response
- name: Print the response
ansible.builtin.debug:
var: response
- name: Confirm the commit with a commit check
juniper.device.config:
check: true
diff: false
commit: false
register: response
- name: Print the response
ansible.builtin.debug:
var: response
デバイスの設定時に警告を無視する方法
juniper.device.configモジュールにより、Junosデバイスの設定を変更およびコミットできます。場合によっては、RPC 応答に、モジュールが RpcError 例外を発生させる重大度レベルが警告以上の <rpc-error> 要素が含まれていることがあります。RpcError例外が発生すると、ロード操作またはコミット操作が失敗する可能性があります。
特定のケースでは、ロードおよびコミット操作の警告に応答して発生するRpcError例外を抑制する必要があるか、望ましい場合があります。モジュールの引数リストに ignore_warning パラメーターを含めることで、警告に対して発生したRpcError例外を抑制するようにjuniper.device.configモジュールに指示できます。ignore_warning引数は、ブール値、文字列、または文字列のリストを取ります。
モジュールによって実行されたロードおよびコミット操作に関するすべての警告を無視するようにモジュールに指示するには、 ignore_warning: true 引数を含めます。次の例では、ロード操作とコミット操作に関する警告をすべて無視します。
---
- name: Configure Device
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Configure op script
juniper.device.config:
config_mode: private
load: set
lines:
- "set system scripts op file bgp.slax"
ignore_warning: true
register: response
- name: Print the response
ansible.builtin.debug:
var: response
ignore_warning: trueを含め、すべての<rpc-error>要素の重大度レベルが警告である場合、アプリケーションはすべての警告を無視し、RpcError例外を発生させません。ただし、重大度レベルが高い<rpc-error>要素では例外が発生します。
特定の警告を無視するようにモジュールに指示するには、 ignore_warning 引数を無視する警告を含む文字列または文字列のリストに設定します。次の例では、2 つの特定の警告を無視しています。
---
- name: Configure Device
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Configure Junos device and ignore warnings
juniper.device.config:
config_mode: private
load: merge
src: "build_conf/{{ inventory_hostname }}/junos.conf"
ignore_warning:
- "Advertisement-interval is less than four times"
- "Chassis configuration for network services has been changed."
register: response
- name: Print the response
ansible.builtin.debug:
var: response
モジュールは、すべての<rpc-error>要素の重大度レベルが警告であり、応答内の各警告が指定された文字列の 1 つ以上に一致する場合、RpcError例外を抑制します。
例:Ansible を使用して Junos デバイスの設定
juniper.device.configモジュールにより、Junosデバイスの設定を管理できます。この例では、config モジュールを使用して、SSH 経由の NETCONF を介して Junos デバイスの設定を変更します。
要件
この例では、以下のハードウェアおよびソフトウェアコンポーネントを使用しています。
-
juniper.deviceコレクションがインストールされたAnsible 2.17以降を実行している構成管理サーバー -
NETCONFを有効にし、適切な権限でユーザーアカウントが設定されたJunosデバイス
-
AnsibleコントローラとJunosデバイス上の適切なユーザーに設定されたSSHパブリック/プライベートキーペア
-
必要なホストが定義された既存のAnsibleインベントリファイル
概要
この例では、 juniper.device.config モジュールを使用して、ターゲットJunosデバイスの設定で新しい op スクリプトを有効にする Ansible プレイブックを紹介します。設定データ ファイル junos-config.conf には、テキスト形式の関連設定データが含まれています。
プレイブックには、ansible.builtin.wait_for Ansibleモジュールを利用して、NETCONFデフォルトポート(830)を使用してターゲットデバイスとのNETCONFセッションを確立しようとするCheck NETCONF connectivityタスクが含まれています。プレイブックの実行中に制御ノードがターゲットデバイスとのNETCONFセッションの確立に失敗した場合、そのデバイスのプレイにある残りのタスクをスキップします。
プレイブックでは、 juniper.device.file_copy モジュールを使用して、新しい op スクリプトを Ansible 制御ノードから Junos デバイスにコピーします。モジュール引数は、ローカルデバイス上のスクリプトのディレクトリとファイル名、およびリモートデバイス上の宛先ディレクトリを指定します。
デバイスを設定するタスクは、NETCONFチェックが成功した場合モジュール juniper.device.config を実行します。 load: "merge" 引数は、 load merge 操作を使用して、新しい設定データを候補設定に読み込みます。デフォルトでは、 config モジュールは、 load および rollback 操作のためにデバイス上の設定データをコミットします。モジュール引数には comment 引数が含まれ、デバイスのシステムログファイルとコミット履歴にコミットコメントを記録します。
設定
設定データファイルを作成する
ステップバイステップの手順
モジュールで使用されるコンフィギュレーション・データ・ファイルを作成するには:
-
設定データの形式(この例ではテキスト)に基づいて、適切な拡張子を持つ新しいファイルを作成します。
-
必要な設定変更をファイルに含めます。
user@ansible-cn:~/ansible$ cat build_conf/dc1a.example.net/junos-config.conf system { scripts { op { file bgp.slax; } } }
Ansibleプレイブックの作成
ステップバイステップの手順
configモジュールを使用してJunosデバイスの設定を変更するプレイブックを作成するには:
-
モジュールをローカルで実行するプレイブックの定型文を含めます。
--- - name: Load and commit configuration data on a Junos device hosts: dc1 connection: local gather_facts: no
-
(オプション)NETCONF接続を検証するタスクを作成します。
tasks: - name: Check NETCONF connectivity ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: 830 timeout: 5 -
新しいopスクリプトをデバイスにコピーするタスクを作成します。
- name: Copy the op script to the device juniper.device.file_copy: action: put file: bgp.slax local_dir: scripts remote_dir: /var/db/scripts/op -
設定をデバイスにロードし、コミットするタスクを作成します。
- name: Merge configuration data from a file and commit juniper.device.config: load: "merge" src: "build_conf/{{ inventory_hostname }}/junos-config.conf" comment: "Configuring op script with Ansible" register: response -
(オプション)構成変更を 差分 形式で出力するタスクを作成します。
- name: Print the response ansible.builtin.debug: var: response
結果
Ansibleコントロールノードで、完成したプレイブックを確認します。プレイブックに意図したコードが表示されない場合は、この例の手順を繰り返してプレイブックを修正します。
---
- name: Load and commit configuration data on a Junos device
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Check NETCONF connectivity
ansible.builtin.wait_for:
host: "{{ inventory_hostname }}"
port: 830
timeout: 5
- name: Copy the op script to the device
juniper.device.file_copy:
action: put
file: bgp.slax
local_dir: scripts
remote_dir: /var/db/scripts/op
- name: Merge configuration data from a file and commit
juniper.device.config:
load: "merge"
src: "build_conf/{{ inventory_hostname }}/junos-config.conf"
comment: "Configuring op script with Ansible"
register: response
- name: Print the response
ansible.builtin.debug:
var: response
プレイブックを実行する
プレイブックを実行するには:
-
制御ノードで
ansible-playbookコマンドを発行し、プレイブックパスと任意のオプションを指定します。user@ansible-cn:~/ansible$ ansible-playbook ansible-pb-junos-config.yaml PLAY [Load and commit configuration data on a Junos device] *************** TASK [Check NETCONF connectivity] ***************************************** ok: [dc1a.example.net] TASK [Copy the op script to the device] *********************************** changed: [dc1a.example.net] TASK [Merge configuration data from a file and commit] ******************** changed: [dc1a.example.net] TASK [Print the response] ************************************************* ok: [dc1a.example.net] => { "response": { "changed": true, "diff": { "prepared": "\n[edit system scripts op]\n+ file bgp.slax;\n" }, "diff_lines": [ "", "[edit system scripts op]", "+ file bgp.slax;" ], "failed": false, "file": "build_conf/dc1a.example.net/junos-config.conf", "msg": "Configuration has been: opened, loaded, checked, diffed, committed, closed." } } PLAY RECAP **************************************************************** dc1a.example.net : ok=4 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
検証
設定の確認
目的
Junosデバイスで設定が正しく更新されたことを確認します。
アクション
Ansibleプレイブックの出力を確認して、設定タスクが成功したか失敗したかを確認します。また、Junosデバイスにログインし、設定、コミット履歴、ログファイルを表示して、設定とコミットを確認することもできます。例を示します。
user@dc1a> show configuration system scripts
op {
file bgp.slax;
}
user@dc1a> show system commit
0 2020-12-17 15:33:50 PST by user via netconf
Configuring op script with Ansible
user@dc1a> show log messages Dec 17 15:33:39 dc1a mgd[33444]: UI_COMMIT: User 'user' requested 'commit' operation (comment: Configuring op script with Ansible) Dec 17 15:33:57 dc1a mgd[33444]: UI_COMMIT_COMPLETED: commit complete
Playbook エラーのトラブルシューティング
タイムアウトエラーのトラブルシューティング
問題点
プレイブックは TimeoutExpiredError エラーメッセージを生成し、デバイス設定の更新に失敗します。
ncclient.operations.errors.TimeoutExpiredError: ncclient timed out while waiting for an rpc reply
NETCONF RPCのタイムアウトのデフォルト時間は30秒です。大規模な設定変更はこの値を超える場合があり、設定をアップロードしてコミットする前に操作がタイムアウトします。
ソリューション
デフォルトのRPCタイムアウト間隔よりも長いコミット時間を必要とする可能性のある設定変更に対応するには、モジュールの timeout 引数を適切な値に設定し、プレイブックを再実行します。
設定ロックエラーのトラブルシューティング
問題点
プレイブックは、設定をロックできないことを示す LockError エラーメッセージを生成します。次に例を示します。
FAILED! => {"changed": false, "msg": "Unable to open the configuration in exclusive mode: LockError(severity: error, bad_element: None, message: configuration database modified)"}
または
FAILED! => {"changed": false, "msg": "Unable to open the configuration in exclusive mode: LockError(severity: error, bad_element: lock-configuration, message: permission denied)"}
設定ロックエラーは、以下の理由で発生する可能性があります。
-
別のユーザーが設定に対する排他的ロックを持っています。
-
別のユーザーが設定データベースに変更を加えましたが、まだ変更をコミットしていません。
-
Ansibleモジュールを実行するユーザーには、デバイスを設定する権限がありません。
ソリューション
通常、 LockError メッセージ文字列は、問題の根本原因を示します。別のユーザーが設定に対して排他的ロックを持っている場合、または設定を変更した場合は、ロックが解除されるか変更がコミットされるまで待ってから、プレイブックを再度実行します。問題の原因が、デバイスを設定する権限をユーザーに持っていないことである場合、必要な権限を持つユーザーを使用してプレイブックを実行するか、必要に応じて、現在のユーザーに変更を行うために必要な権限を与えるようにJunosデバイスを設定します。
設定変更エラーのトラブルシューティング
問題点
プレイブックは、権限が拒否されたため設定を変更できないことを示す ConfigLoadError エラーメッセージを生成します。
FAILED! => {"changed": false, "msg": "Failure loading the configuraton: ConfigLoadError(severity: error, bad_element: scripts, message: error: permission denied)"}
このエラーメッセージは、Ansibleモジュールを実行するユーザーが設定を変更する権限を持っているが、設定の要求されたセクションを変更する権限を持っていない場合に生成されます。
ソリューション
必要なパーミッションを持つユーザーを使用してプレイブックを実行するか、必要に応じて、変更を行うために必要なパーミッションを現在のユーザーに付与するようにJunosデバイスを設定します。