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

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

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

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

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

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

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

別のモードを指定するには、パラメーターをmode目的のモードと同じに設定します。サポートされているモードにはbatch、 dynamicephemeral、 、exclusiveprivateおよび が含まれます。さまざまなモードについては、 CLIユーザーガイドを参照してください。

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

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

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

メモ：

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

エフェメラル構成データベースのデフォルト・インスタンスを構成するには、引数を mode に設定します ephemeral。例えば：

一時的な構成データベースのユーザー定義インスタンスを構成するには、引数を に設定し、引数ephemeralをmodeephemeral_instanceインスタンスの名前に設定します。

および 関数を使用するとjunos.load、 、 、 、load overrideload replaceまたは load update の操作を使用してload merge設定変更を読み込むjunos.install_configことができます。目的のロード操作を指定するには、その関数の適切な引数を含めるか省略します。ロード操作を指定しない場合、デフォルトは 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 機能を使用すると、サポートされている標準の形式のいずれかを使用して、Junos OS を実行するデバイスを設定できます。部分的または完全な構成、または Jinja2 テンプレートを含むファイルから構成データを読み込むことができます。データは、テキスト、Junos XML要素、Junos OS set コマンド、またはJSONとして提供できます。

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

表 3: 構成データの形式の指定

構成データ形式	ファイル拡張子	フォーマットパラメータ
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.install_config 関数を使用するとjunos.load、部分的または完全な構成、または Jinja2 テンプレートを含むファイルから構成データを読み込むことができます。ファイルは、Saltマスターまたはプロキシミニオンサーバーに配置できます。関数は、salt:// 表記を使用してSaltマスター上のパスを指定し、絶対パスを使用してプロキシミニオンサーバー上のパスを指定する必要があります。ファイルが構成データの形式を示すために受け入れられたファイル拡張子のいずれかを使用しない場合、関数呼び出しには、データの形式を指定する引数も含め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 関数は、候補コンフィギュレーションと要求されたコンフィギュレーションの差分を自動的に実行します。この関数は、変更がある場合にのみ構成を適用します。同じ設定をもう一度適用しようとすると、次の例に示すように、関数は設定がすでに適用されているというメッセージを返し、 junos.install_config 再度ロードしてコミットしません。

および junos.install_config 実行および状態関数は、junos.loadJunos OS 設定データ用の Jinja2 テンプレートの使用をサポートしています。Jinja は、定義済みのテンプレートからドキュメントを生成できる Python 用のテンプレート エンジンです。テンプレートは、目的の言語のテキスト ファイルであり、式と変数を使用して柔軟性を提供します。Junos OSの設定データは、サポートされている設定フォーマット(ASCIIテキスト、Junos XML要素、Junos OSsetコマンド、JSONなど)でJinja2テンプレートを使用して作成できます。これらの関数は、Jinja2 テンプレートと提供される変数のディクショナリを使用して、構成データをレンダリングします。

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

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

• テンプレートパス— 設定データを読み込む方法の説明に従って、Salt マスターまたはプロキシミニオンサーバー上のテンプレートファイルへのパスを指定します。

• [テンプレート形式(Template format)]:テンプレート ファイルが形式の指定に受け入れられるファイル拡張子の 1 つを使用しない場合、設定データの形式を示す引数を設定します format 。形式の指定については、「 読み込む構成データの形式を指定する方法」を参照してください。

• テンプレート変数 - テンプレートは、ピラー データやグレイン データで定義されているような 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.set_hostname 関数はjunos.install_config、要求された設定変更を読み込み、junos.rollbackコミットチェックとコミット操作を自動的に実行します。また、個々の 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_check 関数をjunos.commit呼び出します。

コミットの詳細

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

コミット同期

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

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

コミット タイムアウト

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

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

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

例えば、以下のコマンドは、以前にコミットした設定にコンフィギュレーションをロールバックし、コミットします。

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

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