ソルトを使用したJunos OS搭載デバイスの設定

変更する前に候補の構成をロックして、ロックが解除されるまで他のユーザーやアプリケーションが更新できないようにすることができます。これは、CLI の configure exclusive コマンドに相当します。コミット操作は、コミットを要求したユーザーやアプリケーションによる変更だけでなく、候補の設定にあるすべての変更に適用されるため、特に複数のユーザーが設定の変更を許可されているデバイスでは、変更を行う前に設定をロックすることを推奨します。

junos.install_config機能は、configure exclusiveモードを使用して候補の設定データベースに変更を加えます。このモードでは、設定データベースが自動的にロックされ、変更がロードされてコミットされ、データベースのロックが解除されます。ただし、junos.load 関数と junos.commit 関数を使用するなどして、読み込み操作とコミット操作を別々に実行する必要がある場合は、junos.lock 関数と junos.unlock 実行関数または状態関数を使用して、データベースを明示的にロックおよびロック解除できます。

設定データベースを変更する前に明示的にロックするには、 junos.lock 関数を使用します。例えば：

データベースをアンロックし、コミットされていない変更を破棄するには、 junos.unlock 関数を使用します。例えば：

構成データベースが変更されている場合、または別のユーザーが既に構成データベースに排他ロックをかけている場合、次の例に示すように、 junos.lock 関数は LockError メッセージを返します。

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

別のモードを指定するには、 mode パラメーターを目的のモードと同じに設定します。サポートされているモードは、 batch、 dynamic、 ephemeral、 exclusive、および privateです。各モードの詳細については、 CLIユーザーガイドを参照してください。

例えば、以下のコマンドは、 configure private モードでコンフィギュレーションを変更し、候補コンフィギュレーションのプライベートコピーを開きます。

同様に、この引数を Salt 状態ファイルに含めることもできます。

junos.install_config機能を使って、このデータベースをサポートするデバイス上の一時設定データベースを更新することもできます。一時データベースは、Junos OS を実行しているデバイスで設定更新を実行するための高速なプログラムインターフェイスを提供する代替設定データベースです。この機能を使用するには、Salt バージョン 3001 および Junos PyEZ リリース 2.1.3 以降が必要です

手記：

一時的な設定データベースは高度な機能であり、誤って使用すると、デバイスの動作に深刻な悪影響を与える可能性があります。詳細については、「 エフェメラル構成データベースについて」を参照してください。

一時設定データベースのデフォルトインスタンスを設定するには、 mode 引数を ephemeral に設定します。例えば：

エフェメラル構成データベースのユーザー定義インスタンスを設定するには、 mode 引数を ephemeral に設定し、 ephemeral_instance 引数をインスタンスの名前に設定します。

junos.loadおよびjunos.install_config機能を使用して、load merge、load replace、load override、またはload update操作を使用して設定変更を読み込むことができます。目的の読み込み操作を指定するには、その関数に適切な引数を含めたり省略したりします。ロード操作を指定しない場合、デフォルトは load replace です。表 2 は、各タイプのロード操作に必要な引数をまとめたものです。

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

ロード操作	関数の引数	形容
load merge	merge=True	読み込んだコンフィギュレーションを既存のコンフィギュレーションにマージします。
load override	overwrite=True	コンフィギュレーション全体をロードされたコンフィギュレーションに置き換えます。
load replace (デフォルト)	–	読み込んだコンフィギュレーションを既存のコンフィギュレーションにマージしますが、既存のコンフィギュレーションのステートメントを、ロードされたコンフィギュレーションの replace: タグを指定するステートメントに置き換えます。既存のコンフィギュレーションにステートメントがない場合、読み込まれたコンフィギュレーションのステートメントが追加されます。
load update	update=True	読み込まれた完全な設定を既存の設定と比較します。読み込まれたコンフィギュレーションで異なる各構成要素は、既存のコンフィギュレーション内の対応するエレメントを置き換えます。コミット操作中は、変更された構成要素の影響を受けるシステム プロセスのみが新しい設定を解析します。

次のコマンドは、ターゲット・デバイス上のコンフィギュレーション全体を指定されたコンフィギュレーションに置き換えてコミットします。RPC タイムアウトは、完全な設定を読み込んでコミットするのに十分な時間を確保するために増加します。

同等の状態ファイルは次のとおりです。

junos.load および junos.install_config 機能を使用すると、サポートされている標準フォーマットの 1 つを使用して Junos OS を実行しているデバイスを設定できます。設定データは、部分的または完全な設定または Jinja2 テンプレートを含むファイルから読み込むことができます。データは、テキスト、Junos XML要素、Junos OSsetコマンド、またはJSONとして提供できます。

構成データの形式を指定するには、適切な拡張機能を構成ファイルに追加するか、関数呼び出しに format 引数を明示的に含めます。 表 3 は、構成データでサポートされている形式と、ファイル拡張子と format パラメーターに対応する値をまとめたものです。 format 引数を含めると、ファイル拡張子で示される形式が上書きされます。

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

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

手記：

Junos OSを実行するデバイスは、Junos OS リリース16.1R1以降、JSON形式での設定データの読み込みをサポートしています。

junos.load および junos.install_config 機能を使用すると、部分的または完全な設定または Jinja2 テンプレートを含むファイルから設定データを読み込むことができます。このファイルは、Salt マスターまたはプロキシ ミニオン サーバに配置できます。関数は、salt:// 表記を使用して Salt マスター上のパスを指定し、絶対パスを使用してプロキシ ミニオン サーバー上のパスを指定する必要があります。ファイルが、構成データの形式を示すために受け入れられるファイル拡張子の 1 つを使用しない場合は、関数呼び出しに format 引数も含めて、データの形式を指定する必要があります。

表 4 は、使用できる構成データ・ソースについて説明し、ファイルの場所を指定するために必要な実行および状態関数の引数をリストしています。実行関数では、位置引数として、または path キーワードを使用してパスを指定できます。

表4:構成データソース

構成データソース	形容	場所	実行関数の引数	状態関数の引数
構成データ・ファイル	ASCIIテキスト、Junos XML要素、Junos OS set コマンド、またはJSONとしてフォーマットされた設定データを含むファイル。	ソルトマスター - salt:// 表記を使用 プロキシ ミニオン サーバ - 絶対パスを使用	path	name
Jinja2 テンプレート ファイル	ASCIIテキスト、Junos XML要素、Junos OS set コマンド、またはJSONとしてフォーマットされたJinja2テンプレートを含むファイル。 関数呼び出しに template_vars パラメーターを含めて、Salt システムでまだ定義されていない必要な Jinja2 テンプレート変数 (ピラー データやグレイン データなど) のディクショナリを提供します。	ソルトマスター - salt:// 表記を使用 プロキシ ミニオン サーバ - 絶対パスを使用	path	name

たとえば、次のファイルには、2 つの op スクリプトを構成する Junos OS set コマンドが含まれています。ファイルの拡張子は、構成データの形式を示します。

次のSaltコマンドは、 junos.install_config 実行機能を使用して、ターゲット・デバイスに設定をロードしてコミットします。パスは位置引数として提供されます。

同等の状態ファイルは次のとおりです。

junos.install_config機能は、候補コンフィギュレーションと要求されたコンフィギュレーションの差分を自動的に実行します。この関数は、変更があった場合にのみ設定を適用します。同じ設定を 2 回目に適用しようとすると、次の例に示すように、junos.install_config 関数は設定がすでに適用されていることを示すメッセージを返し、再度ロードしてコミットすることはありません。

junos.load 関数と junos.install_config 実行関数と状態関数では、設定データJunos OSための Jinja2 テンプレートの使用がサポートされています。Jinja は Python 用のテンプレートエンジンで、事前定義されたテンプレートからドキュメントを生成できます。目的の言語のテキスト ファイルであるテンプレートは、式と変数を使用して柔軟性を提供します。JINJA2 テンプレートを使用すると、ASCII テキスト、Junos XML 要素、Junos OS set コマンド、JSON など、サポートされている構成形式の 1 つでJunos OS構成データを作成できます。関数は、Jinja2 テンプレートと提供された変数のディクショナリを使用して、構成データをレンダリングします。

Jinja2 テンプレートは、特に類似した設定スタンザに対して、設定データを生成するための強力な方法を提供します。例えば、デバイス上の各インターフェイスに同じ設定ステートメントを手動で追加する代わりに、インターフェイスのリストを反復処理し、それぞれに必要な設定ステートメントを作成するテンプレートを作成できます。Jinjaでは、ブロックは「{%」と「%}」で区切られ、変数は「{{」と「}}」で囲まれます。

Jinja2 テンプレートを読み込むには、 junos.load または junos.install_config 関数呼び出しに次のパラメーターを含める必要があります。

• [テンプレート パス(Template path)]: 構成データのロード方法の説明に従って、Salt マスター サーバまたはプロキシ ミニオン サーバ上のテンプレート ファイルへのパスを指定します。

• [テンプレート形式(Template format)]:テンプレート ファイルが、受け入れ可能なファイル拡張子の 1 つを使用して形式を指定していない場合、設定データの形式を示すために format 引数を設定します。形式の指定については、 How to Specify the Format of the Configuration Data to Loadを参照してください。

• テンプレート変数 - テンプレートは、ピラーや粒度データで定義されているものなどの Salt 内部変数を参照できます。Salt システム内でまだ定義されていない変数は、 template_vars 引数で指定する必要があります。 template_vars 値は、Jinja2 テンプレートをレンダリングするために必要なキーと値のディクショナリです。

  手記：

  テンプレートにピラー データ、グレイン データ、関数などの Salt 内部変数のみが含まれている場合は、テンプレートをレンダリングするために junos.install_config 関数で template_vars: True を定義する必要がある場合があります。

次のサンプル Jinja2 テンプレートは、特定のリストの各インターフェイスに対して論理ユニット 0 で MPLS を有効にする設定データを生成し、MPLS および RSVP プロトコルの下でインターフェイスも設定します。

次のコマンドは、Jinja2テンプレートと template_vars で定義された変数を使用して設定データをレンダリングし、ターゲットホストにロードしてコミットします。

次の状態ファイルは、同じ構成を読み込みます。構成の違いは、プロキシ ミニオン サーバ上の diffs_file ファイルに保存されます。

状態を適用すると、Salt は設定をレンダリングし、デバイス上に設定を読み込んでコミットします。

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

設定を変更した後、設定をコミットして、デバイス上でアクティブな設定にする必要があります。 junos.install_config、 junos.rollback、および junos.set_hostname 機能は、要求された設定変更をロードし、コミットチェックとコミット操作を自動的に実行します。また、個別の junos.commit_check 機能と junos.commit 機能を使用して、コミットチェックやコミット操作を実行できます。たとえば、 junos.load 機能を使用して設定を更新した後などです。

Junos OS CLIには、コミットコメントの追加や複数のルーティングエンジン上の設定の同期など、コミット操作のオプションが用意されています。これらのオプションの一部は、Junos の実行および状態モジュール機能でサポートされています。 表 5 は、使用可能なコミット オプションと、それらをサポートする機能の概要を示しています。サポートされている引数は、実行関数と状態関数の両方で有効です。

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

関数の引数	形容	引数をサポートする関数	CLIコマンドに相当するもの
comment=comment	そのコミット操作のコメントを、システムログファイルとデバイスのコミット履歴に記録します。	junos.commit junos.install_config junos.rollback junos.set_hostname	commit comment "comment"
confirm=(True | minutes)	最初のコミット後、指定された時間内にコミット操作を確認することを要求します。それ以外の場合は、以前にコミットされた設定にロールバックします。 引数を True に設定して、デフォルトの時間の 10 分を使用します。	junos.commit junos.install_config junos.rollback junos.set_hostname	commit confirmed <minutes>
detail=True	コミット プロセスに関する詳細情報を返します。	junos.commit	commit | display detail
dev_timeout=seconds	指定された値をタイムアウトとして使用して、操作の完了を待ちます。	junos.commit junos.install_config junos.rollback junos.set_hostname	–
force_sync=True	もう一方のルーティング エンジンで開いている設定セッションまたはコミットされていない設定変更がある場合でも、両方のルーティング エンジンで設定を同期してコミットルーティングエンジン。	junos.commit	commit synchronize force
sync=True	両方のルーティングエンジンの設定を同期し、コミットします。	junos.commit	commit synchronize

コミットコメント

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

同様に、状態ファイルでは、次のようになります。

コミットコメントは、コミットのシステムログメッセージに含まれ、コミット履歴にも記録されます。

コミット確認済み

候補の構成をコミットする場合、コミットを恒久的なものにするための明示的な確認を要求することができます。指定された時間内にコミットが確認されない場合、デバイスは自動的にロードされ、以前にコミットされた設定をコミットします(ロールバックします)。確認されたコミット操作は、設定変更が正しく機能し、デバイスへの管理アクセスが妨げられないことを確認するのに便利です。変更によってアクセスができなくなったり、その他のエラーが発生した場合は、ロールバック期限が過ぎた後、以前の設定への自動ロールバックによってデバイスへのアクセスが復元されます。

最初のコミット後、指定された時間内にコミット操作を確認するように要求するには、 confirm=minutes 引数を含めます。許容範囲は 1 から 65,535 分です。また、デフォルトの時間である 10 分を使用するように confirm=True を指定することもできます。

以下のコマンドでは、15 分以内にコミットを確認する必要があります。

コミット操作を確認するには、 junos.commit または junos.commit_check 関数を呼び出します。

コミットの詳細

junos.commit 機能を使用して設定をコミットする場合、detail=True 引数を含めることで、コミット操作全体の詳細を確認できます。この引数を含めると、関数はコミット プロセスに関する詳細情報を返します。

コミット同期

junos.commit 機能を使用して設定をコミットする場合、sync=True 引数を含めることで、デュアル ルーティングエンジン システムの両方のルーティング エンジンで設定を同期およびコミットできます。例えば：

sync=True 引数を含めると、デバイスはローカルルーティングエンジンに保存された候補コンフィギュレーションを他のルーティングエンジンにコピーし、候補の構文の正しさを検証し、両方のルーティングエンジンにコミットします。もう一方のルーティングエンジンで開いている設定セッションやコミットされていない設定変更がある場合でも、commit synchronize操作を強制的に成功させるには、force_sync=True 引数を使用します。この引数を含めると、デバイスは、設定を同期してコミットする前に、もう一方のルーティングエンジン上の設定セッションを終了します。

コミットタイムアウトの

RPC がタイムアウトする既定の時間は 30 秒です。大規模な設定変更は、この値を超える可能性があり、設定をアップロードしてコミットする前に操作がタイムアウトする可能性があります。デフォルトのタイムアウト間隔よりも長いコミット時間を必要とする可能性のある設定変更に対応するには、 dev_timeout=seconds 引数を含め、タイムアウト間隔を適切な値に設定します。例えば：

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

salt.modules.junos.rollback実行機能とsalt.states.junos.rollbackステート機能を使うことで、Junos OSを実行しているデバイス上で、以前にコミットした設定に設定をロールバックさせることができます。設定をロールバックしてコミットするには、関数を実行し、id 引数を目的のロールバック設定の ID に設定します。有効な ID 値は、最後にコミットされた設定の 0(ゼロ)から、保存された以前の設定の数より 1 少ない数(最大は 49)です。id キーワードを省略すると、デフォルトは 0 になります。

例えば、以下のコマンドは、以前にコミットされた設定に設定をロールバックしてコミットします。

設定をロールバックし、後で参照できるように設定の違いをファイルに記録するには、 diffs_file 引数を含め、相違点が書き込まれるプロキシ ミニオン サーバ上のファイルのパスに設定します。

差分は、プロキシ ミニオン サーバ上の指定されたファイルに保存されます。