Ansibleを使用したJunosデバイスの設定

juniper.device.config モジュールを使用すると、Junos デバイスで次の操作を実行できます。

• 構成データの読み込み

• 設定をコミットします

• 設定をロールバックする

• レスキュー設定を読み込む

設定を変更するには、モジュールの引数リストに、新しい設定データを読み込むための load パラメータ、またはレスキュー設定または以前にコミットした設定に戻すための rollback パラメータを含める必要があります。設定変更を行う基本的なプロセスは、設定をロックし、設定変更をロードし、設定をコミットしてアクティブにし、設定のロックを解除することです。

デフォルトでは、 config モジュールは configure exclusive モードで候補コンフィギュレーション データベースに変更を加えます。これにより、候補のグローバル コンフィギュレーションが自動的にロックおよびロック解除されます。別の設定モードを指定することもできます。例えば、候補コンフィギュレーションのプライベート・コピーや、一時的なコンフィギュレーション・データベースに変更を加えることができます。構成モードの指定の詳細については、 How to Specify the Configuration Modeを参照してください。

新しいコンフィギュレーション・データを読み込む場合、コンフィギュレーション・モードの指定に加えて、ロード操作や変更のソースとフォーマットを指定することもできます。

• ロード操作:ロード操作によって、選択した設定データベースに設定データを読み込む方法が決まります。この機能は、Junos OS CLI で使用できるものと同じ読み込み操作の多くをサポートしています。詳細については、「 読み込みアクションを指定する方法」を参照してください。

• フォーマット—サポートされている標準フォーマットの1つを使用してJunosデバイスを設定できます。設定データやJinja2テンプレートは、テキスト、Junos XML要素、Junos OS set コマンド、またはJSONとして提供できます。構成データの形式の指定については、 How to Specify the Format of the Configuration Data to Loadを参照してください。

• 構成データソース— lines、 src、 template、または url パラメーターをそれぞれ含めることで、文字列のリスト、ローカル Ansible 制御ノード上のファイル、Jinja2 テンプレート、またはクライアントデバイスから到達可能な URL から構成データを読み込むことができます。設定データのソースの指定の詳細については、次のセクションを参照してください。

  • 設定データを文字列として読み込む方法

  • ローカルファイルまたはリモートファイルから設定データを読み込む方法

  • Jinja2 テンプレートを使用してコンフィギュレーション・データを読み込む方法

config モジュールでは、レスキュー設定を読み込んでコミットしたり、以前にコミットした設定に設定をロールバックすることもできます。レスキュー設定または以前にコミットした設定を読み込むには、rollback モジュール引数を含める必要があります。詳細については、次のセクションを参照してください。

• レスキュー用設定を読み込む方法

• 設定をロールバックする方法

設定を変更した後、設定をコミットして、デバイス上でアクティブな設定にする必要があります。デフォルトでは、 config モジュールが設定の変更をコミットします。この動作を変更したり、追加のコミットオプションを指定したりするには、 How to Commit the Configurationを参照してください。

デフォルトでは、 config モジュールが設定を変更するための load または rollback 引数を含む場合、モジュールはモジュールの応答で設定変更を diff または patch 形式で自動的に返します。差は、 diff 変数と diff_lines 変数で返されます。モジュールが差を計算して返さないようにするには、 diff モジュール引数を false に設定します。

機器設定を変更する際に使用する設定モードを指定できます。タスクで設定モードを指定するには、 config モジュールの config_mode パラメータを含めます。サポートされている設定モードは次のとおりです。

• batch

• dynamic

• ephemeral

• exclusive

• private

デフォルトでは、 juniper.device.config モジュールは configure exclusive モードを使用して候補構成データベースに変更を加えます。コンフィギュレーション排他モードは、モジュールがコンフィギュレーションに対して要求された変更を行う必要がある限り、候補のグローバル コンフィギュレーション( 共有コンフィギュレーション データベースとも呼ばれる)をロックします。データベースをロックすると、ロックが解除されるまで、他のユーザーがデータベースを変更したり、データベースの変更をコミットしたりできなくなります。

次の例は、候補構成のプライベートコピーを構成する方法と、一時データベースを構成する方法を示しています。

• 例: config_mode: "private"
• 一時データベースを構成する

juniper.device.configモジュールは、Junos OS CLI でサポートされているのと同じロード操作の多くを使用して、設定変更のロードをサポートします。ロード操作を指定するには、モジュールの引数リストに load パラメーターを含め、それを対応するロード操作の値に設定します。表 2 は、各タイプのロード操作に必要なパラメーター設定をまとめたものです。

表 2: 読み込み操作を指定するためのパラメーター

ロード操作	load 引数	形容
load merge	load: "merge"	読み込んだコンフィギュレーションを既存のコンフィギュレーションにマージします。
load override	load: "override"	コンフィギュレーション全体をロードされたコンフィギュレーションに置き換えます。
load patch	load: "patch"	パッチ ファイルから構成データを読み込みます。
load replace	load "replace"	読み込んだコンフィギュレーションを既存のコンフィギュレーションにマージしますが、既存のコンフィギュレーションのステートメントを、ロードされたコンフィギュレーションの replace: タグを指定するステートメントに置き換えます。既存のコンフィギュレーションにステートメントがない場合、読み込まれたコンフィギュレーションのステートメントが追加されます。
load set	load: "set"	set形式のコンフィギュレーション・データをロードします。設定データは行ごとに読み込まれ、set、delete、deactivateなどの設定モードコマンドを含めることができます。
load update	load: "update"	読み込まれた完全な設定を既存の設定と比較します。読み込まれたコンフィギュレーションで異なる各構成要素は、既存のコンフィギュレーション内の対応するエレメントを置き換えます。コミット操作中は、変更された構成要素の影響を受けるシステム プロセスのみが新しい設定を解析します。

juniper.device.config モジュールでは、サポートされている標準フォーマットのいずれかを使用して Junos デバイスを設定できます。構成データは、文字列またはファイルとして指定できます。ファイルには、設定データまたは Jinja2 テンプレートのいずれかを含めることができます。文字列、ファイル、または Jinja2 テンプレート内で設定データを提供する場合、サポートされているデータ形式には、テキスト、Junos XML 要素、Junos OS set コマンド、JSON が含まれます。

config モジュールは、lines 引数内の文字列として指定された設定データの形式を自動検出しようとします。ただし、format 引数を含めることで、文字列の形式を明示的に指定できます。ファイルまたは Jinja2 テンプレートで設定データを指定する場合は、ファイルに適切な拡張子を追加するか、format 引数を含めて、データの形式を指定する必要があります。

表 3 は、構成データでサポートされる形式と、ファイル拡張子と format パラメーターに対応する値を要約したものです。 format 引数を含めると、文字列の自動検出形式とファイル拡張子で示される形式の両方がオーバーライドされます。

表 3: 設定データの形式の指定

設定データのフォーマット	ファイル拡張子	format パラメーター
CLI コンフィギュレーション ステートメント(テキスト)	.conf	「text」
JavaScript Object Notation(JSON)	.json	「json」
Junos OS set コマンド	。セット	「set」
Junos XML の要素	.xml	「xml」

手記：

モジュールの load 引数を 'override' または 'update' に設定した場合、Junos OS set コマンド形式を使用することはできません。

juniper.device.configモジュールを使用すると、文字列のリストから設定データを読み込むことができます。設定データを文字列として読み込むには、適切な load 引数と lines 引数を含めます。lines 引数は、ロードする設定データを含む文字列のリストを取ります。

モジュールは、 lines 設定データのフォーマットの自動検出を試みます。ただし、 format 引数を含めることで、形式を明示的に指定できます。形式の指定については、 How to Specify the Format of the Configuration Data to Loadを参照してください。 format 引数を含めると、自動検出された形式が上書きされます。

次の Playbook は、2 つの op スクリプトを設定してコミットします。この場合、lines の設定データはsetステートメント形式を使用するため、この場合、load 引数の値は 'set' Junos OSなります。

次のプレイブックは、テキスト形式の設定データで lines を使用して同じステートメントを設定します。この場合、 load: "merge" が使用されます。

juniper.device.configモジュールを使用すると、ファイルから設定データを読み込むことができます。ファイルは、次のいずれかの場所に配置できます。

• Ansible制御ノード

• クライアントデバイス

• クライアント デバイスから到達可能な URL

ファイルから設定データを読み込む場合、ファイルの場所とファイル内の設定データの形式を指定する必要があります。サポートされている設定データ形式には、テキスト、Junos XML 要素、Junos OS set コマンド、JSON などがあります。Jinja2 テンプレートを含むファイルの読み込みについては、「 Jinja2 テンプレートを使用して構成データを読み込む方法」を参照してください。

構成データの形式を指定するには、モジュールの引数リストに format パラメーターを明示的に含めるか、構成データ ファイルに適切な拡張子を追加します。 format パラメーターを指定すると、ファイル拡張子で示される形式がオーバーライドされます。形式の指定については、 How to Specify the Format of the Configuration Data to Loadを参照してください。設定データでJunos XML形式を使用する場合は、最上位の <configuration> タグで囲む必要があります。

手記：

NETCONF セッション内でデバイスを直接設定する場合、ASCII テキスト、Junos OS set コマンド、または JSON としてフォーマットされた設定データを、 <configuration-text>、 <configuration-set>、または <configuration-json> タグで囲む必要はありません。

表 4 は、ファイルの場所を指定するために含めることができるモジュール・パラメーターの概要を示しています。

表 4: 構成ファイルの場所の指定

モジュール パラメーター	形容
src	Ansible制御ノード上のファイルへの絶対パスまたは相対パス。デフォルトのディレクトリは playbook ディレクトリです。
url	クライアントデバイス上のファイルへの絶対パスまたは相対パス、FTPの場所またはHTTP URL。 クライアントデバイス上のデフォルトのディレクトリは現在の作業ディレクトリで、デフォルトでユーザーのホームディレクトリになります。

Ansible制御ノード上のローカルファイルから設定データを読み込むには、 src 引数を設定データを含むファイルの絶対パスまたは相対パスに設定します。例えば：

Junos デバイス上のファイル、または FTP または HTTP URL から設定データを読み込むには、 url パラメーターを使用して、読み込む設定データが含まれるファイルのパスを指定します。例えば：

url の値は、絶対または相対ローカル ファイル パス、FTP の場所、または HTTP URL です。

• ターゲット・デバイス上のローカル・ファイルのファイル・パスは、以下のいずれかの形式になります。

  • /path/filename:ローカル フラッシュ ディスクまたはハード ディスクのいずれかにマウントされたファイル システム上のファイル。

  • A:filename または a:path/filename - ローカル ドライブ上のファイル。デフォルトのパスは / (ルートレベルのディレクトリ) です。リムーバブルメディアは、MS-DOS または UNIX (UFS) 形式にすることができます。

• FTPサーバー上のファイルのファイルパスは、次の形式です。

• HTTPサーバー上のファイルのファイルパスは、次の形式になります。

いずれの場合も、 path 変数のデフォルト値はユーザーのホームディレクトリです。絶対パスを指定するには、アプリケーションはパスを文字 %2F で開始します。 たとえば、ftp://username:password@hostname/%2Fpath/filename です。

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 パラメーターを含める必要があります。形式の指定については、 How to Specify the Format of the Configuration Data to Loadを参照してください。

たとえば、 interfaces-mpls.j2 ファイルには、以下の Jinja2 テンプレートが含まれています。

juniper.device.config モジュールを使用して Jinja2 テンプレートを読み込むには、template 引数をテンプレート ファイルのパスに設定し、テンプレートに必要な変数を vars ディクショナリで定義します。次のプレイブックでは、Jinja2 テンプレートと vars で定義された変数を使用して構成データをレンダリングし、ターゲット ホストにロードしてコミットします。formatパラメータは、テンプレートファイル内の設定データの形式を示します。

モジュールは、以下の設定データを生成し、デバイス上の候補コンフィギュレーションにロードしてコミットします。

レスキュー設定では、作業中の既知の設定や、いつでも復元できる既知の状態の設定を定義することができます。レスキュー設定は、既知の設定に戻す必要がある場合や、デバイス設定とバックアップ設定ファイルが修復できないほど破損した場合の最後の手段として使用します。レスキュー設定を作成すると、デバイスは最後にコミットされた設定をレスキュー設定として保存します。

juniper.device.config モジュールを使用すると、Junos デバイスの既存のレスキュー設定に戻すことができます。デバイスにレスキュー設定を読み込んでコミットするには、モジュールの rollback: "rescue" 引数を含めます。例えば：

Junos デバイスには、プラットフォームに応じて、最後にコミットされた設定と、最大 49 個の以前の設定のコピーが保存されます。保存されている設定のいずれかにロールバックできます。これは、設定の変更によって望ましくない結果が発生し、既知の動作設定に戻したい場合に便利です。設定のロールバックは、デバイスの設定を変更するプロセスと似ていますが、設定データを読み込む代わりにロールバックを行い、候補の設定全体を以前にコミットされた設定に置き換えます。

juniper.device.config モジュールを使用すると、Junos デバイスで以前にコミットした設定にロール バックできます。設定をロールバックしてコミットするには、モジュールの rollback 引数を含め、ロールバック設定の ID を指定します。有効な ID 値は、0(直近にコミットされた設定の場合はゼロ)から、保存された以前の設定の数より1を引いた値(最大は49)です。

以下のプレイブックは、復元する設定のロールバックIDの入力を求め、設定をロールバックしてコミットし、設定変更を標準出力に出力します。

デフォルトでは、 juniper.device.config モジュールを使用して、 load または rollback 引数のいずれかを使用して設定を変更すると、モジュールは自動的にコミット チェックを実行し、変更をコミットします。モジュールがコミットチェックを実行したり、変更をコミットしたりしないようにするには、 check または commit 引数をそれぞれ false に設定します。

また、Junos OS の CLI で利用できるものと同じオプションの多くを使用して、コミット操作をカスタマイズすることもできます。 表 5 は、さまざまなコミット オプションを指定するために使用できるモジュール引数の概要を示しています。

表 5: コミット オプション

モジュール引数	形容	loadおよびrollback操作のデフォルト値
check: boolean	コミットチェックを実行するか、以前に確認されたコミット操作を確認します。	true
check_commit_wait: seconds	コミット・チェックとコミット操作の間に指定された秒数待機します。	–
comment: "string"	そのコミット操作のコメントを、システムログファイルとデバイスのコミット履歴に記録します。	–
commit: boolean	設定変更をコミットするか、以前に確認されたコミット動作を確認します。	true
commit_empty_changes: boolean	候補コンフィギュレーションとコミットされたコンフィギュレーションに違いがない場合でも、コンフィギュレーションの変更をコミットします。	false
commit_force_sync: boolean	他のルーティングエンジンで開いている設定セッションまたはコミットされていない設定変更がある場合でも、すべてのルーティング エンジンで設定を同期してコミットします。	false
commit_sync: boolean	すべてのルーティング エンジンの設定を同期し、コミットします。	false
confirmed: minutes	最初のコミット後、指定された時間内にコミット操作を確認することを要求します。指定された時間内にコミットが確認されない場合は、以前にコミットされた設定にロールバックします。 commit: true オプションまたは check: true オプションのいずれかを使用してコミットを確認する必要があります。	–
timeout: seconds	指定された値をタイムアウトとして使用して、操作の完了を待ちます。	30秒

コミットコメント

設定をコミットする際に、コミットされた変更の目的を説明する簡単なコメントを含めることができます。変更を説明するコメントをログに記録するには、メッセージ文字列に comment: "comment string" 引数を含めます。

コミットチェック

デフォルトでは、 config モジュールはコミットチェックとコミット操作の両方を実行します。 check_commit_wait 引数は、コミット チェックとコミット操作の間で待機する秒数を定義します。デバイスがコミットチェック操作を完了し、コミット操作を開始する前に設定ロックを解除するための十分な時間を提供する必要がある場合に、この引数を使用します。 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 引数を指定して config モジュールを呼び出します。

次のプレイブックでは、最初のタスクが設定を変更し、コミットチェックとコミット操作の間に 10 秒間待機し、5 分以内にコミット操作を確認する必要があります。また、コミットのコメントも記録されます。2 番目のタスクは、コミットを確認するために commit check 操作を発行します。実際のシナリオでは、最初のコミット後に検証タスクを実行し、タスクが特定の検証基準に合格した場合にのみコミット確認を実行できます。

juniper.device.config モジュールを使用すると、Junos デバイスの設定を変更し、コミットできます。場合によっては、RPC 応答に、モジュールがRpcError例外を発生させる原因となる重大度レベルが警告以上の<rpc-error>要素が含まれることがあります。RpcError例外が発生すると、ロードまたはコミット操作が失敗する可能性があります。

場合によっては、ロード操作とコミット操作の警告に応答して発生するRpcError例外を抑制することが必要または望ましい場合があります。モジュールの引数リストに ignore_warning パラメーターを含めることで、警告に対して発生するRpcError例外を抑制するように config モジュールに指示できます。ignore_warning 引数は、ブール値、文字列、または文字列のリストを取ります。

モジュールによって実行されるロード操作とコミット操作に関するすべての警告を無視するようにモジュールに指示するには、 ignore_warning: true 引数を含めます。次の例では、ロード操作とコミット操作に関する警告をすべて無視します。

ignore_warning: true を含み、すべての<rpc-error>要素の重大度レベルが警告である場合、アプリケーションはすべての警告を無視し、RpcError例外を発生させません。ただし、重大度レベルが高い<rpc-error>要素では、例外が発生します。

特定の警告を無視するようにモジュールに指示するには、 ignore_warning 引数に、無視する警告を含む文字列または文字列のリストを設定します。次の例では、2 つの特定の警告を無視します。

モジュールは、すべての<rpc-error>要素の重大度レベルが警告であり、応答内の各警告が指定された文字列の 1 つ以上と一致する場合、RpcError例外を抑制します。