juniper.device.config Ansibleモジュールを使用して、Junos OS設定を取得または比較する

juniper.device.config モジュールを使用して設定を取得する場合、モジュールの引数リストに retrieve パラメーターを含める必要があります。retrieve パラメーターは、データの取得元となる構成データベースを指定します。以下の値にretrieveを設定して、それぞれのデータベースから設定データを返すことができます。

• candidate—候補の設定からデータを取得します。

• committed—コミットされた設定からデータを取得します。

注:選択したデータベースに関係なく、候補の構成データベースがロックまたは変更されている場合、モジュールは構成を取得できず、エラーを返します。

コミットされた設定データベース

以下のプレイブックは、インベントリグループ内の各デバイスのコミットされた設定全体をテキスト形式で取得します。

候補者構成データベース

次のプレイブックは、インベントリグループ内の各デバイスの完全な候補設定をテキスト形式で取得します。

完全なJunos OS設定を取得するだけでなく、 filter パラメーターを使用して設定の特定の部分を取得することもできます。 filter パラメーターの値は、返す設定ステートメントを選択するサブツリーフィルターを含む文字列です。サブツリーフィルターは、選択基準に一致する設定データを返します。複数の階層をリクエストする場合、 filter の値は、ルート( <configuration> 要素で表される)から各要素に至る設定階層のすべてのレベルを表す必要があります。

次のプレイブックは、各デバイスのコミットされた設定データベースの [edit interfaces] 階層レベルと [edit protocols] 階層レベルで設定を取得して出力します。

次のプレイブックは、ge-1/0/1インターフェイスの設定を取得して出力します。

以下のプレイブックは、 [edit system services] 階層レベルでコミットされた設定を取得して出力します。

juniper.device.config モジュールを使用して設定を取得すると、モジュール は Junos XML プロトコル<get-configuration>操作を呼び出し、さまざまな形式の設定データを返すことができます。デフォルトでは、モジュールは設定データをフォーマットされたテキストとして返します。テキスト形式では、改行、タブ、その他の空白、中括弧、角括弧を使用して、ステートメント間の階層関係を示します。

設定データを返す形式を指定するには、モジュールの format パラメーターを必要な形式と等しく設定します。許容される値は以下の通りです。

• json—JavaScript Object Notation(JSON)

• set—Junos OS set コマンド

• text—書式設定されたテキスト(デフォルト)

• xml—Junos XML 要素

プレイブック出力では、 config キーと config_lines キーに、要求された形式の設定が含まれています。XMLまたはJSON形式Junos要求する場合、 config_parsed キーには同等の設定がJSON形式で含まれます。

次のプレイブックは、インベントリグループ内の各デバイスのコミットされた設定全体をXML形式で取得します。

Junosデバイスは、RPC応答をXML形式で返します。JSON、セット、またはテキスト形式でデータをリクエストした場合でも、NETCONFサーバーの応答はデータをXMLタグでラップします。したがって、Ansibleモジュールは、RPC応答を処理するためにXMLパーサーを使用する必要があります。XML パーサーは、多くの場合、ドキュメントの深さと単一のテキスト ノードのサイズに安全上の制限を課します。これらの制限は、悪意のある攻撃、メモリの枯渇、および一般的なパフォーマンスの問題を防ぐための組み込みのセキュリティ対策です。

ネットワークデバイスは、大規模で複雑な設定や、広範なコマンドおよびRPC出力を持つことがあります。デフォルトでは、XMLパーサーはテキストノードにサイズ制限を課します。通常は約10MBです。1 つのテキストノードがサイズ制限を超えると、パーサーはエラーを生成します。次に例を示します。

一般に、構成、コマンド、または RPC データを XML 形式で要求する場合、ドキュメントには多くの小さな XML ノードが含まれ、パーサーはまれなケースを除いてこの制限に遭遇しません。ただし、JSON、セット、またはテキスト形式で同じデータをリクエストすると、デバイスは1つ以上のXMLタグでラップされたデータを返します。たとえば、デバイスは、 <rpc-reply> タグに加えて、必要に応じてセットとテキストの設定データを <configuration-set> タグまたは <configuration-text> タグでラップします。同様に、デバイスはコマンド出力をテキスト形式で <output> 要素で囲みます。大量のデータの場合、応答によって、パーサーのデフォルトの制限を超える単一のXMLテキストノードが生じる可能性があります。

大規模な設定や広範なコマンドまたはRPC出力を任意の形式で要求すると、XMLパーサーがRPC応答を処理します。したがって、XML データではまれですが、すべての形式でノード サイズ制限エラーが発生する可能性があります。このような場合は、応答を XML として返すことをお勧めします。

他の形式のいずれかが必要な場合は、 huge_tree: true モジュール引数を含めることで、パーサーの制限をオーバーライドできます。 huge_tree: true を使用すると、テキストノードの最大サイズ、属性の最大サイズ、深度の最大制限を無視する XML_PARSE_HUGE オプションが有効になります。その結果、パーサーは大きな XML ドキュメント、ディープ XML ツリー、および大きなテキストノードを処理できます。

次のプレイブックは、インベントリグループ内のデバイスに対してコミットされた設定を set 形式で取得します。引数モジュール juniper.device.config には、 huge_tree: trueが含まれます。このオプションを使用すると、特定の応答がパーサーのデフォルトのノードサイズ制限を超えても、タスクは成功します。

標準化された YANG モジュールまたはカスタム YANG モジュールを Junos デバイスにロードして、Junos OS ではネイティブ サポートされていないが変換ではサポート可能なデータ モデルを追加できます。候補構成では、それらのモデルに定義された構文を使用して、非ネイティブデータモデルを設定します。設定をコミットすると、データモデルの変換スクリプトによってそのデータが変換され、対応するJunos OS設定がチェックアウト設定の一時的な変更としてコミットされます。

候補コンフィギュレーションとアクティブなコンフィギュレーションには、それらのモデルで定義された構文の非ネイティブYANGデータモデルの設定データが含まれています。 juniper.device.config モジュールを使用して、ネイティブJunos OS設定を取得するだけでなく、標準(IETF、OpenConfig)およびカスタムYANGデータモデルの設定データを取得できます。デフォルトでは、モジュールの応答にはサードパーティ YANG データ モデルの設定データは含まれません。

Junos OS設定の取得に加えて、非ネイティブYANGデータモデルで定義された設定データを取得するには、 model パラメータを使用してモジュールを実行し、必要に応じて namespace パラメータを含めます。 model 引数は、次のいずれかの値を取ります。

• custom—カスタムYANGデータモデルで定義された設定データを取得します。カスタム YANG データ モデルのデータを取得する場合は、引数 namespace を含める必要があります。

• ietf—IETF YANGデータモデルで定義された設定データを取得します。

• openconfig—OpenConfig YANGデータモデルで定義された設定データを取得します。

• True—完全なJunos OS設定と任意のYANGデータモデルからのデータを含む、すべての設定データを取得します。

model引数でietfまたはopenconfigが指定されている場合、モジュールは自動的に適切な名前空間を使用します。カスタム YANG データ モデルのデータを取得するmodel: customを指定する場合は、対応する名前空間に namespace 引数も含める必要があります。

model引数に値custom、ietf、またはopenconfigを含め、特定のXMLサブツリーを返すfilter引数も含めると、非ネイティブデータモデルから一致する階層のみJunos OS返されます。Junos OS設定に「interfaces」などの同じ名前の階層が含まれている場合、それは応答に含まれません。model: Trueを使用する場合、filterオプションはサポートされていません。

juniper.device.config モジュール を使用して非ネイティブ設定データを取得する場合、filter パラメーターも含めた場合にのみ、返されるデータの形式を指定できます。filterパラメーターを省略する場合は、format: xmlを指定する必要があります。

次のプレイブックは、コミットされた設定からOpenConfig interfaces 設定階層を取得します。 filter 引数を省略すると、RPCは完全なJunos OSとOpenConfigの設定を返します。

次のタスクは、指定された名前空間を持つカスタムYANGデータモデルのコミットされた設定から l2vpn 設定階層を取得します。

次のタスクは、Junos OSがコミットした完全な設定と、デバイスに追加された他のYANGデータモデルの設定データを取得します。

juniper.device.config モジュールを使用して設定を取得すると、モジュール は Junos XML プロトコル<get-configuration>操作を呼び出します。このモジュールでは、format属性など、多くの<get-configuration>属性に対して明示的な引数がサポートされています。モジュール は options 引数もサポートしているため、同等の モジュール 引数を持たない追加の <get-configuration> 属性を含めることができます。options引数は、<get-configuration>操作でサポートされている属性のキーと値のペアの辞書を取ります。

Junos XMLプロトコル <get-configuration> 操作でサポートされている属性の完全なリストについては、 <get-configuration>を参照してください。

例えば、juniper.device.configモジュールは、継承前のコンフィギュレーションからデータを取得します。このコンフィギュレーションでは、<groups>、<apply-groups>、<apply-groups-except>、<interface-range>タグは、コンフィギュレーション出力の個別の要素です。継承後のコンフィギュレーションからデータを取得するには、inherit: inheritにoptions引数を含めることができます。継承後のコンフィギュレーションでは、ユーザー定義のグループおよび範囲から継承されたステートメントを継承ステートメントの子として表示します。

次のプレイブックでは、継承後にコミットされた設定から [edit system services] 階層レベルの設定データを取得します。継承後のコンフィギュレーションでは、 [edit groups global system services] などのグループ階層レベルで設定されたステートメントは、 [edit system services] の下に継承され、取得したコンフィギュレーションデータに返されます。

juniper.device.config モジュールを使用して設定を取得すると、返された設定データをローカルの Ansible 制御ノード上のファイルに保存できます。データをファイルに保存するには、モジュールのdest_dirまたはdestパラメーターを含めます。dest_dirオプションは、ディレクトリパスを指定します。destオプションでは、パスとファイル名の両方を指定できます。ターゲット名を持つ出力ファイルが既に存在する場合、モジュールはファイルを上書きします。

取得した設定を保存するディレクトリを指定するには、 dest_dir 引数をターゲットディレクトリのパスに設定します。各デバイスの設定は、 hostname.configという名前の個別のファイルに保存されます。

次のプレイブックは、インベントリグループ内のすべてのデバイスからコミットされた設定を取得します。プレイブックは、各デバイスの設定を、Ansible制御ノードのplaybookディレクトリの下にある configs ディレクトリ内の個別のファイルに保存します。

出力ファイルのパスとファイル名を指定するには、 dest 引数をファイルの絶対パスまたは相対パスに設定します。 dest 引数を含めてディレクトリを省略すると、ファイルはプレイブックディレクトリに保存されます。複数のデバイスの設定を取得する場合、 dest 引数には、各デバイスのファイル名を区別するために、 {{ inventory_hostname }} などの変数を含める必要があります。ファイル名を区別しない場合、各デバイスのコンフィギュレーション・ファイルが他のデバイスのコンフィギュレーション・ファイルを上書きします。

次のプレイブックは、コミットされた設定データベースから、インベントリグループ内の各デバイスの [edit system services] 階層を取得します。プレイブックは、各デバイスの設定を Ansible コントロールノードのプレイブックディレクトリ内の個別のファイルに保存します。各ファイルは、そのホスト名によって一意に識別されます。

設定データをファイルに保存していて、モジュールの応答で設定データを複製したくない場合は、オプションでモジュールの引数リストに return_output: false を含めることができます。 return_output を false に設定すると、モジュール は応答で config、 config_lines、 config_parsed キーを省略します。デバイスが大量の設定データを返す場合、この操作が必要になることがあります。

juniper.device.configモジュールにより、アクティブな設定を以前にコミットした設定やロールバック設定と比較することができます。アクティブな設定を以前の設定と比較するには、以下のモジュール引数を含めます。

デフォルトでは、 rollback: id 引数を含めると、モジュール設定がロールバックされ、コミットチェックが実行され、変更がコミットされます。設定のみを比較し、モジュールによるロールバック設定の読み込みとコミットを防ぐには、 commit: false 引数を含める必要があります。 check: false 引数を含めることで、不要なコミットチェック操作を防ぐことができます。

モジュールは、 diff キーと diff_lines キーを返します。キーには、アクティブな設定と以前の設定の設定の違いが 差分 またはパッチ形式で含まれています。

• diff— prepared という名前の 1 つのキーとその値 (差分を含む 1 つの複数行の文字列) を含む辞書。

• diff_lines—差異を含む単行文字列のリスト。

ローカルAnsible制御ノード上のファイルに差分を保存するには、 diffs_file 引数を含め、出力ファイルの絶対パスまたは相対パスを定義します。 diffs_file 引数を含めてディレクトリを省略した場合、ファイルはプレイブックディレクトリに保存されます。複数のデバイスの設定を比較する場合、 diffs_file 引数には、各デバイスのファイル名を区別するために、 {{ inventory_hostname }} などの変数を含める必要があります。ファイル名を区別しない場合、各デバイスの出力ファイルが他のデバイスの出力ファイルを上書きします。

次のプレイブックでは、以前にコミットされた設定のロールバックIDを入力するよう求めます。次に、プレイブックはコミットされた設定を指定されたロールバック設定と比較し、その比較を一意の名前のファイルに保存して、標準出力に対する応答を出力します。