Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Ansible を使用して Junos OS の設定を取得または比較する

概要 ジュニパーネットワークスのAnsibleモジュールを使用して、Junosデバイスの設定を取得または比較します。

ジュニパーネットワークスは、Junosデバイスの設定を管理できるAnsibleモジュールを提供しています。 表 1 は、Junos デバイスの設定を取得または比較するために使用できるモジュールの概要を示しています。

表 1:設定を取得または比較するモジュール

コンテンツ セット

モジュール名

juniper.device 徴収

config

juniper.device.config モジュールを使用して、ネイティブ Junos OS 設定と、デバイスに追加されたサードパーティの YANG データ モデルに対応する設定データの両方について、完全な設定または設定の一部を要求できます。Junos デバイスから設定を取得するには、retrieve パラメーターを指定して config モジュールを実行します。モジュールの応答には、return_output オプションが false に設定されていない限り、config キーと config_lines キーのテキスト形式の設定が含まれます。また、アクティブなコンフィギュレーションを以前にコミットされたコンフィギュレーションと比較することもできます。

以下のセクションでは、モジュールを使用して設定を取得または比較する方法について説明します。

構成データのソース データベースを指定する方法

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

  • retrieve: 'candidate'- 候補コンフィギュレーションからデータを取得します。

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

コミットされた構成データベース

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

受験者構成データベース

次のプレイブックは、インベントリ グループ内の各デバイスの完全な候補構成をテキスト形式で取得します。データベースがロックまたは変更されている場合、モジュールはエラーを返します。

返す構成データの有効範囲を指定する方法

完全な Junos OS 設定の取得に加えて、 config モジュールの filter パラメータを含めることで、設定の特定の部分を取得できます。 filter パラメータの値は、返す設定ステートメントを選択するサブツリーフィルタを含む文字列です。サブツリー フィルターは、選択条件に一致する構成データを返します。複数の階層を要求する場合、 filter の値は、ルート ( <configuration> 要素で表される) から表示する各要素までの設定階層のすべてのレベルを表す必要があります。

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

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

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

返す構成データの形式を指定する方法

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

設定データを返す形式を指定するには、 config モジュールの format パラメータを目的の形式に設定します。許容値は以下のとおりです。

  • 'json'—JavaScript Object Notation(JSON)

  • 'set'—Junos OS set コマンド

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

  • 'xml'—Junos XMLの要素

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

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

サードパーティの YANG データ モデルの設定データを取得する方法

Junosデバイスに標準化またはカスタムのYANGモジュールをロードして、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 引数に値 customietf、または openconfig を含み、さらに特定の XML サブツリーを返す filter 引数を含めると、Junos OS は非ネイティブ データ モデルから一致する階層のみを返します。Junos OSの設定に「interfaces」など、同じ名前の階層が含まれている場合、それは応答に含まれません。model: "True" を使用する場合、filter オプションはサポートされません。

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>を参照してください。

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

取得した設定が保存されるローカルAnsible制御ノード上のディレクトリを指定するには、 dest_dir 引数を含め、ターゲットディレクトリへのパスを定義します。各デバイスの設定は、 hostname.config という名前の個別のファイルに保存されます。

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

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

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

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

アクティブなコンフィグを以前のコンフィグと比較する方法

juniper.device.config モジュールを使用すると、アクティブな設定を以前にコミットされた設定と比較できる、またはロールバック設定を行うことができます。アクティブなコンフィギュレーションを以前のコンフィギュレーションと比較するには、以下のモジュール引数をインクルードします。

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

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

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

  • diff_lines- 差分を含む 1 行の文字列のリスト。

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

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