Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページで
 

コミット スクリプトの仕組み

コミットスクリプトには、カスタム設定ルールを適用する手順が含まれており、標準的なJunos OSの有効性チェックが実行される前に、コミットプロセス中に呼び出されます。階層レベルで 1 つ以上のコミット スクリプト ファイルの名前を一覧表示して、コミット スクリプトを [edit system scripts commit] 有効にします。これらのファイルは、デバイス上の適切なコミット スクリプト ディレクトリに追加する必要があります。

コミット操作を実行すると、Junos OS は各スクリプトを順番に実行し、継承後 の候補構成 の情報をスクリプトに渡します。このスクリプトは、設定を検査し、必要なテストと検証を実行し、特定のアクションを実行するための一連の手順を生成します。すべてのコミットスクリプトが実行されると、Junos OSはすべてのスクリプトの指示を処理します。コミット プロセスがコミット スクリプトによって停止しない場合、Junos OS はすべてのコミット スクリプトの変更を適用し、チェックアウト設定の最終検査を実行します。

メモ：

1 つ以上のコミット スクリプトによって検査される構成をコミットする場合、大規模な構成の処理に対応するために、コミット スクリプトに割り当てられたメモリの量を増やす必要がある場合があります。既定では、実行されたスクリプトのデータ セグメント部分に割り当てられるメモリの最大量は、システムの利用可能なメモリの合計の半分で、最大 128 MB です。実行されたコミット スクリプトごとに割り当てられる最大メモリを増やすには、設定を max-datasize size コミットする前に、 階層レベルで [edit system scripts commit] バイト単位で適切なメモリ制限を使用して ステートメントを設定します。

コミット スクリプト アクションには、エラー、警告、システム ログ メッセージの生成が含まれます。エラーが発生した場合、コミット操作は失敗し、候補の設定は変更されません。これは、標準的なコミット エラーで発生するのと同じ動作です。コミット スクリプトは、システム設定の変更を生成することもできます。標準の検証チェックが実行される前に変更が読み込まれるため、スクリプトが適用される前に設定に既に存在しているステートメントと同様に、変更は正しい構文で検証されます。構文が正しい場合、設定はアクティブになり、アクティブな動作デバイスの設定になります。

コミット スクリプトは、保護されたステートメントや保護された階層に設定変更を加えることはできません。コミットスクリプトが保護されたステートメントや階層の変更または削除を試みると、Junos OSは変更できないという警告を発行します。保護された構成要素の変更に失敗しても、コミット スクリプトやコミット プロセスは停止しません。

次のセクションでは、コミット スクリプトの入力と出力に関連するいくつかの重要な概念について説明します。

コミット スクリプト入力

コミット スクリプトの入力は、Junos XML API 形式の継承後の候補設定です。 継承後 という用語は、すべての設定グループ値が候補コンフィギュレーションのターゲットによって継承され、設定の非アクティブ部分が削除されたことを意味します。設定グループの詳細については、 CLIユーザーガイドを参照してください。

コマンドを commit 発行すると、Junos OS は候補の設定を XML 形式で自動的に生成し、管理(mgd)プロセスに読み込みます。このプロセスでは、入力がコミット スクリプトによって評価されます。

CLI で、継承後の候補コンフィギュレーションの XML 形式を表示するには、 コマンドを show | display commit-scripts view 発行します。

グループに対するスクリプト生成された変更を含むすべての設定グループ データを表示するには、 コマンドを show groups | display commit-scripts 発行します。

コミット スクリプト出力

コミットプロセス中は、有効なコミットスクリプトが順次実行され、コミットスクリプト出力(命令セット)がJunos OSに提供されます。すべてのコミットスクリプトが実行されると、Junos OSはすべてのスクリプトの指示を処理します。

コミットスクリプトアクションには、警告、エラー、システムログメッセージの生成、設定の永続的および一時的な変更が含まれます。 表 1 では、コミット スクリプトがコミット プロセス中にさまざまなアクションを実行するよう Junos OS に指示する際に使用できるさまざまな要素、テンプレート、機能について簡単に概説しています。場合によっては、同じアクションを実行する複数の方法があります。SLAX スクリプトと XSLT スクリプトは結果ツリーを返すので、SLAX <syslog><message> に存在するような出力要素や XSLT スクリプトが結果ツリーに直接追加されます。

表 1:コミット スクリプトのアクションと出力

コミット スクリプト出力

SLAX / XSLT

Python

コミットしているユーザーに警告メッセージを生成します。

<xnm:warning>

jcs.emit_warning()

エラー メッセージを生成し、コミット操作を失敗させます。

<xnm:error>

jcs.emit_error()

システム ログ メッセージを生成します。

jcs:syslog()

<syslog><message>

jcs.syslog()

設定に対する永続的な変更を生成します。

<change>

emit_change(content、「変更」、 format

設定に対する一時的な変更を生成します。

<transient-change>

emit_change(content「一時変更」) format

XPath 式で定義された現在のコンテキスト ノードに対して永続的な変更を生成します。

Xslt

<xsl:call-template name="jcs:emit-change">
    <xsl:with-param name="content">

Slax

call jcs:emit-change() {
    with $content = {   }
}

–

XPath 式で定義された現在のコンテキスト ノードに対して一時変更を生成します。

Xslt

<xsl:call-template name="jcs:emit-change">
    <xsl:with-param name="tag" select="'transient-change'"/>
    <xsl:with-param name="content">

Slax

call jcs:emit-change() {
    with $tag = "transient-change";
    with $content = {   }
}

–

構成変更と併せて警告メッセージを生成します。このタグのセットを使用して、構成が変更されたことを示す通知を生成できます。

Xslt

<xsl:call-template name="jcs:emit-change">
    <xsl:with-param name="message">
          <xsl:text>

Slax

call jcs:emit-change() {
    with $message = {
        expr "message";
    }
}

jcs.emit_warning()

Junos OS はこの出力を処理し、適切なアクションを実行します。エラーと警告は、Junos OS CLI または Junos XML プロトコル クライアント アプリケーションに戻されます。エラーが発生すると、コミット操作は自動的に失敗します。永続的および一時的な変更は、適切な設定データベースに読み込まれます。

コミット スクリプトからのエラー、警告、システム ログ メッセージの出力をテストするには、 コマンドを commit check | display xml 発行します。

コミット スクリプト処理の詳細なトレースを表示するには、 コマンドを commit check | display detail 発行します。

メモ：

システム ログ メッセージはトレース出力に表示されないため、コミット チェック操作を使用してスクリプトが生成したシステム ログ メッセージをテストすることはできません。さらに、システムログメッセージは、コミット操作中はシステムログに書き込まれますが、コミットチェック操作中には書き込まれません。

コミット スクリプトと Junos OS コミット モデル

Junos OSは、コミットモデルを使用してデバイスの設定を更新します。このモデルでは、デバイスの動作に影響を与えることなく、候補構成に対して一連の変更を行うことができます。変更が完了したら、設定をコミットできます。コミット操作により、候補の設定変更が現在の設定に保存されます。

候補コンフィギュレーションで一連の変更をコミットすると、これらの変更を現在のコンフィギュレーションに転送する 2 つの方法が使用されます。

  • 標準コミット モデル — デバイスでコミット スクリプトがアクティブでない場合に使用されます。

  • コミット スクリプト モデル — コミット スクリプトをコミット モデルに組み込みます。

標準コミット モデル

標準コミットモデルでは、管理(mgd)プロセスが標準のJunos OS検証ルールに基づいて候補の設定を検証します。設定ファイルが有効であれば、現在のアクティブなコンフィギュレーションになります。 図 1 とそれに伴うディスカッションでは、標準コミット モデルの仕組みを説明します。

図 1:標準コミット モデル Standard Commit Model

標準のコミット モデルでは、ソフトウェアは次の手順を実行します。

  1. 候補のコンフィギュレーションがコミットされると、そのコンフィギュレーションがコピーされてチェックアウト・コンフィギュレーションとなります。

  2. mgdプロセスは、チェックアウト設定を検証します。

  3. エラーが発生しない場合、チェックアウト設定は現在のアクティブなコンフィギュレーションとしてコピーされます。

コミット スクリプトを使用したコミット モデル

標準のコミット モデルにコミット スクリプトを追加すると、プロセスがより複雑になります。mgd プロセスは、最初に XML 形式のチェックアウト構成をスクリプト ドライバーに渡し、コミット スクリプトによるチェックアウト構成の検証を処理します。検証が完了すると、スクリプト ドライバーは mgd プロセスに アクション ファイル を返します。mgd プロセスは、アクション・ファイルの指示に従って、候補とチェックアウトの構成を更新し、CLI またはクライアント・アプリケーションにメッセージを発行し、必要に応じてシステム・ログに情報を書き込みます。アクション ファイルを処理した後、mgd プロセスは標準的な Junos OS 検証を実行します。 図 2 とそれに伴うディスカッションで、このプロセスについて説明します。

図 2:コミット スクリプトを追加 Commit Model with Commit Scripts Addedしたコミット モデル

コミット スクリプト モデルでは、Junos OS は次の手順を実行します。

  1. 候補構成がコミットされると、mgd プロセスは XML 形式の候補構成をスクリプト ドライバーに送信します。

  2. 有効になっている各コミット スクリプトは候補構成に対して呼び出され、各スクリプトは mgd プロセスが実行する一連のアクションを生成できます。アクションは、アクション・ファイルに収集されます。

  3. mgd プロセスは、コミット スクリプトのエラー、警告、システム ログ メッセージに対して、アクション ファイルで次のアクションを実行します。

    • エラー— mgd プロセスはコミット プロセスを停止します(つまり、コミット操作は失敗します)、CLI または Junos XML プロトコル クライアントにエラー メッセージを返し、それ以上のアクションは実行しません。

    • 警告—mgd プロセスはメッセージを CLI または Junos XML プロトコル クライアントに転送します。

    • システム ログ メッセージ—mgd プロセスはメッセージをシステム ログ プロセスに転送します。

  4. アクション・ファイルに永続的な変更が含まれている場合、mgd プロセスは要求された変更を候補構成に読み込みます。

  5. 候補のコンフィギュレーションは、チェックアウト・コンフィギュレーションとしてコピーされます。

  6. アクションファイルに一時的な変更が含まれている場合、mgdプロセスは要求された変更をチェックアウト構成に読み込みます。

  7. mgdプロセスは、チェックアウト設定を検証します。

  8. 検証エラーがない場合、チェックアウト設定は現在のアクティブなコンフィギュレーションにコピーされます。

メモ：

コミット スクリプトは、保護されたステートメントや保護された階層に設定変更を加えることはできません。コミットスクリプトが保護されたステートメントや階層の変更または削除を試みると、Junos OSは変更できないという警告を発行します。保護された構成要素の変更に失敗しても、コミット スクリプトやコミット プロセスは停止しません。

コミット操作中に候補構成に対して行われた変更は、そのコミット操作中にカスタム・ルールによって評価されません。ただし、永続的な変更は候補の設定で維持され、後続のコミット操作時にカスタム ルールによって評価されます。コミット スクリプトが候補の設定を変更する方法の詳細については、「 複数のコミット スクリプトを使用する場合の潜在的な競合の回避」を参照してください。

一時変更は、コミットスクリプトのカスタムルールによって評価されることはありません。コミットスクリプトが候補設定を評価し、候補がチェックアウト設定にコピーされてチェックアウト設定になった後にのみ、一時的な変更がチェックアウト設定に行われるからです。一時的な変更を設定から削除するには、コミットスクリプトを削除、 無効化、または 無効化 するか(コミット 操作中のコミットスクリプトの実行の制御で説明されているとおり)、一時変更を生成するコードをコメントアウトします。

永続的な変更と一時的な変更の違いの詳細については、 コミットスクリプトを使用した永続的または一時的な設定変更の生成の概要を参照してください。

関連ドキュメント