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 OS。

Ansibleを使用したソフトウェアのインストール

ジュニパーネットワークス Ansible を使用して Junos OS を実行しているデバイスを管理するサポートと、デバイスにソフトウェア イメージをインストールまたはアップグレードできるモジュールが提供されています。 表 1 に 、モジュールの概要を示します。

表 1:ソフトウェアモジュール

コンテンツ セット

モジュール名

juniper.device コレクション

software

Juniper.junos 役割

juniper_junos_software
注:

リリース Juniper.junos 2.0.0 より、モジュールの機能はモジュール juniper_junos_software に置き換 junos_install_os え可能です。

次のセクションでは、ソフトウェア イメージの場所と一般的なソフトウェア インストール プロセスを指定する方法と、モジュールを使用してソフトウェア パッケージをインストールする際のオプションについて説明Junos OS。また、これらの機能をサポートするデバイスで、VM ホストのアップグレード、統合型 ISSU(統合型インサービス ソフトウェア アップグレード)、NSSU(ノンストップ ソフトウェア アップグレード)など、より特化したアップグレード シナリオの実行方法も説明しています。

ソフトウェア イメージの場所の指定方法

またはモジュールを使用してJunos OSを実行しているデバイスにソフトウェアをインストールする場合、ソフトウェア パッケージを software juniper_junos_software Ansible Control Node にダウンロードし、デフォルトでモジュールは、インストールを実行する前にターゲット デバイスにパッケージをコピーします。混在するバーチャル シャーシでは、パッケージは Ansible コントロール ノードに存在する必要があります。スタンドアロン デバイスまたは非混合 バーチャル シャーシ 環境の場合、Junos OS を実行しているターゲット デバイスにすでに存在するソフトウェア イメージ、またはターゲット デバイスから到達可能な URL に存在するソフトウェア イメージをインストールするようモジュールに指示することもできます。

表 2 は 、ソフトウェア パッケージの場所に応じて設定する必要があるモジュールの引数の概要を示しています。モジュールは常に、 、または local_package pkg_set の引数のいずれかを含める必要 remote_package があります。引数のデフォルトは 、 の で、制御ノード上の指定された場所からターゲット デバイスにソフトウェア パッケージをコピーするようモジュール no_copy false に指示します。

表 2:ソフトウェアパッケージの場所に関するモジュールの引数

ソフトウェア パッケージの場所

no_copy パラメーター

local_package または pkg_set パラメータ

remote_package パラメーター

Ansible制御ノード

除外または次に設定する false

スタンドアロン デバイスまたは非混在のバーチャル シャーシ:

ローカル local_package 制御ノード上のソフトウェア パッケージのファイル パス(ファイル名を含む)に設定します。ファイル パスは、プレイブック ディレクトリを基準にしています。

(オプション)ソフトウェア パッケージがコピーされるターゲット デバイス上のファイル パス。デフォルト のディレクトリは /var/tmp です。

ファイル remote_package 名を含む場合は、 で指定されたファイル名と一致する必要 local_package があります。

混合混合バーチャル シャーシ環境:

ローカル制御ノード上の1つ以上のソフトウェア パッケージのファイル パスのリスト(ファイル名を含む pkg_set )に設定します。ファイル パスは、プレイブック ディレクトリを基準にしています。

–

遠隔地

–

–

実行しているターゲット デバイスのJUNOS OS パッケージがインストールされている場所からの URL。

ターゲット デバイス

に設定します。 true

–

ソフトウェア パッケージがすでに存在する必要があるターゲット デバイス上のファイル パス。デフォルト のディレクトリは /var/tmp です。

ソフトウェア パッケージが Ansible コントロール ノードに存在する場合は、Junos OS を実行しているスタンドアロン デバイス、または非混合 バーチャル シャーシ のメンバーにソフトウェアをインストールする引数を含める、または混合 バーチャル シャーシ のメンバーにソフトウェアをインストールする引数を含める。 local_package pkg_set module の引数は、ローカル制御ノード上のソフトウェア パッケージまたはパッケージへの絶対または相対ファイル パスを指定します。

引数 local_package は、ソフトウェア イメージ パスを指定する 1 つの文字列です。引数には、さまざまなアプリケーション メンバーに必要なソフトウェア イメージ パスを指定する文字列の pkg_set リストバーチャル シャーシまれます。例えば：

デフォルトでは、 または の引数を含める場合、モジュールは、Junos OS バーチャル シャーシ(個々のデバイスまたはプライマリ デバイス)を実行しているターゲット デバイスの local_package pkg_set /var/tmp ディレクトリに任意のソフトウェア パッケージをコピーします。イメージを別のディレクトリに local_package コピーする場合は、引数を定義 remote_package してターゲット ディレクトリを指定します。引数にファイル名が含まれる場合は、引数のファイル名を同一にする必要があります。またはモジュールが remote_package local_package remote_package エラーを生成します。

ソフトウェア パッケージが Junos OS を実行しているターゲット デバイスにすでに存在する場合、モジュールには、引数だけでなく、ターゲット デバイスの既存のソフトウェア パッケージへのファイル パスを指定する引数も含める必要があります。 no_copy: True remote_package ディレクトリ remote_package を指定しない場合、デフォルトは /var/tmp です。

ソフトウェア パッケージが Ansible コントロール ノードまたはターゲット デバイス以外の場所に存在する場合、モジュールは引数を含め、ソフトウェア パッケージの場所を指定する remote_package 必要があります。値は remote_package 、デバイスで実行されているターゲット デバイスから見た URL Junos OS。許容可能な URL 形式の詳細については、「 Junos OS CLI コマンドでのファイル名と URL の指定の形式 」 を参照してください。

インストール プロセスの概要

Ansible を使用して Junos OS を実行しているデバイスにソフトウェア パッケージをインストールするには、またはモジュールを実行し、任意の必要な引数 software juniper_junos_software を指定します。例えば：

またはモジュールを実行 software juniper_junos_software すると、以下の操作が実行されます。

  1. 引数でJunos OS指定されたバージョン、または引数が除外された場合はソフトウェア パッケージのファイル名で、パスにインストールされたバージョンを比較 version version 管理対象デバイス。設置済みバージョンと必要なバージョンが同一の場合、モジュールは残りの設置手順とセット changed を failed スキップして false 、
  2. ソフトウェア パッケージが Ansible コントロール ノード上に位置し、パラメーターを除外するか、False に設定されている場合、モジュールは次の no_copy 操作を実行します。

    • チェックサムが引数にまだ提供されていない場合は、引数に指定されたアルゴリズムを使用して、ローカル ソフトウェア パッケージまたはパッケージのチェックサム checksum_algorithm を計算 checksum します。許容値 checksum_algorithm は 、 md5 sha1 sha256 です。デフォルトは md5 .

    • 引数が に設定されていない限り、ターゲット デバイスでストレージのクリーンアップを実行し、ソフトウェア パッケージのスペースを cleanfs 作成します false 。

    • SCP または FTP は、任意のパッケージをターゲット デバイスにコピーします。

      モジュールが含まれる場合、同じ名前とチェックサムを持つファイルがデバイス上のターゲットの場所に存在しない場合、パッケージはディレクトリにコピーされます。またはが指定されていない場合は local_package remote_package remote_package 、/var/tmp ディレクトリにコピーされます。モジュールが含まれる pkg_set 場合、パッケージは常にプライマリ デバイスの /var/tmp ディレクトリバーチャル シャーシされます。

      注:

      引数を除外またはに設定した場合、ストレージのクリーンアップ操作によって既存のファイルが削除されるため、モジュールは、ターゲットの場所に存在している場合でも、ソフトウェア パッケージをデバイスにコピーします cleanfs true 。存在 cleanfs: false し、ファイルがターゲットの場所にすでに存在している場合、モジュールはファイル コピー操作をスキップします。

    • 各リモート ファイルのチェックサムを計算し、それをローカル ファイルの値と比較します。

最初にダウンロードしたデバイスか、モジュールがコピーするかは別の方法で、ソフトウェア パッケージがターゲット デバイスに追加されると、モジュールは次の操作を実行します。

  1. パラメーターが に設定されている場合は、新しいパッケージに対 validate する設定を検証します true 。

    注:

    デフォルトでは、 および モジュール はソフトウェア パッケージを検証しません。また、ソフトウェア パッケージを追加する前提条件として、既存の設定に対 software juniper_junos_software してバンドル化する必要があります。アクティブな設定が新しいソフトウェア イメージで動作確認するには、引数を . に validate 設定します true 。

  2. に設定されていない限り、パッケージを各ルーティング エンジンデバイス all_re にインストールします false 。

  3. 引数が に設定されていない限ルーティング エンジン アップグレードされたデバイス reboot を再起動します false 。

および software モジュール juniper_junos_software を使用すると、モジュールの引数を含めてインストールの進行状況 logfile をログに記録できます。デフォルトでは、重大度レベルの警告以上のメッセージだけがログに記録されます。一般的なインストール プロセスでメッセージをログに記録するために必要な重大度レベルの INFO 以上のメッセージをログに記録するには、 または コマンドライン オプションを使用してプレイブック -v --verbose を実行します。

タイムアウト値の指定方法

ソフトウェア モジュールジュニパーネットワークス NETCONF セッションを使用して操作を実行します。NETCONF RPC のデフォルトタイムは 30 秒です。インストール プロセスで、特定の操作で RPC のタイムアウト間隔が次のように増えます。

  • デバイスにパッケージをコピーしてインストールする - 1800 秒(30 分)

  • チェックサムの計算 - 300 秒(5 分)

  • ストレージのクリーンアップの実行 - 300 秒(5 分)

インストール プロセス、チェックサム計算、ストレージのクリーンアップが、これらの間隔を超える場合があります。これらの操作のタイムアウト値は、 、および をモジュールの引数リストで必須の秒 install_timeout checksum_timeout cleanfs_timeout に設定することで変更できます。例えば：

同等のモジュールの引数を持たしていないインストール オプションを指定する方法

またはモジュールを使用してデバイスにソフトウェアをインストールする場合、モジュールが、指定されたインストールの引数(標準の Junos OS インストールの RPC、VM ホスト アップグレード用の software juniper_junos_software <request-package-add> <request-vmhost-package-add> RPC、統合型 <request-package-in-service-upgrade> ISSU シナリオ用の RPC など)を呼び出します。これらのモジュールは、多くのインストール オプション(オプションなど)で明示的な引数をサポート validate しています。モジュールは引数もサポートします。RPC によってサポートされる追加オプションを含め、同等のモジュールの引数を持 kwargs つオプションを含めすることもできます。引数 kwargs は、追加でサポートされるオプションのキー/値ペアの辞書を取ります。

モジュールでサポートされる現在のオプションのリストについては、そのモジュールの API リファレンス マニュアルを参照してください。特定の RPC で使用可能なすべてのオプションのリストについては、同等のコマンドのマニュアル、または Junos XML API Explorerで RPC のリクエスト タグを検索してください。

注:

モジュールには、デバイスで稼働しているターゲット デバイスでサポートされているインストール オプションのみをJunos OS。

以下のプレイブックでは、モジュール software がターゲット ホストに新しいソフトウェア イメージをインストールします。モジュールには、 kwargs を使用する引数が含まれています unlink: True 。アップグレードが成功した後にディレクトリからソフトウェア パッケージを削除するこの引数は、RPC にオプションを含 <unlink/> むのに相当 <request-package-add> します。

VM ホスト アップグレードの実行方法

VMホストをサポートするルーティングエンジンを搭載したデバイスでは、Junos OS Vマシン(VMホスト)上で仮想マシン(VM)として動作します。ホスト OS と互換性のある Junos OS をアップグレードする VM ホストのアップグレードでは、VM ホスト インストール パッケージ(junos-vmhost-install- x .tgz)が必要で request vmhost software add 、RPC に対応する動作モード コマンドを使用して実行されます。 <request-vmhost-package-add>

と software モジュール juniper_junos_software は vmhost: True 、VM ホスト アップグレードの実行の引数をサポートしています。引数が存在すると、モジュールは RPC を使用してインストールを実行 <request-vmhost-package-add> します。

次のプレイブックは、デバイス上でJunos OS OSをアップグレードおよび再起動します。

統合型 ISSU または NSSU の実行方法

この機能をサポートし、必要な要件を満たすデバイス上で、統合型インサービス ソフトウェア アップグレード(統合型 ISSU)またはノンストップ ソフトウェア アップグレード software (NSSU)を実行するモジュールをサポートします。 juniper_junos_software 統合型 ISSU と NSSU 機能の詳細については、ご使用の製品のソフトウェア マニュアルを参照してください。

統合型 ISSU 機能を使用すると、2 つの異なる Junos OS リリース間でアップグレードが可能で、コントロール プレーン を中断してトラフィックの中断を最小限に抑えることができます。統合型インサービス ソフトウェア アップグレードを実行するには、 または モジュールに引数 software juniper_junos_software を含める必要 issu: True があります。例えば：

NSSU 機能を使用すると、ネットワーク トラフィックの中断を最小限に抑Junos OSまたは冗長ルーティング エンジンを使用して、スイッチまたは バーチャル シャーシ 上で実行されているソフトウェアをアップグレードできます。ノンストップ ソフトウェア アップグレードを実行するには、またはモジュール software juniper_junos_software に引数を含める必要 nssu: True があります。例えば：

例: Ansibleの使用によるソフトウェアのインストール

この例では、 software 収集内のモジュールを使用して、デバイスで動作しているデバイスにソフトウェア イメージ juniper.device をインストールJunos OS。

要件

この例では、次のハードウェアとソフトウェアのコンポーネントを使用しています。

  • Ansible 2.10 以降が動作し、収集がインストールされた構成 juniper.device 管理サーバー

  • NETCONF Junos OSを有効にした状態でデバイスを実行し、適切な権限を持って設定されたユーザー アカウント

  • Ansibleコントロールノードおよび実行中のデバイスで、適切なユーザーに対して設定されたSSHパブリック/プライベートキーのペアJunos OS

  • 必要なホストが定義された既存の Ansible インベントリ ファイル

概要

この例では、指定されたインベントリ グループ内のホスト上のJunos OSアップグレードにモジュールを使用する Ansible software プレイブックを示しています。この例では、ソフトウェア イメージが Ansible コントロール ノードに存在し、モジュールがイメージをターゲット デバイスにコピーしてからインストールします。モジュールは引数を明示的に定義していないので、モジュールはデフォルトのホストで host 動作します {{ inventory_hostname }} 。

このプレイブックには、モジュールを利用して、デフォルトの Checking NETCONF connectivity NETCONF ポート 830 を使用して Junos OS を実行しているデバイスとの NETCONF セッションを確立しようとするタスクが含まれています wait_for 。プレイブックの実行中にコントロール ノードがデバイスとの NETCONF セッションを確立できない場合、そのデバイスのプレイ中の残りのタスクはスキップします。

Install Junos OS package software NETCONF のチェックが正常に完了すると、このタスクはモジュールを実行します。この version 引数は、指定するJunos OSで実行されているデバイス上のコマンドによって報告されるバージョンを定義 show version Junos OS。プレイブックの実行中、モジュールはまず要求されたバージョンがデバイスにインストールされていないか確認します。要求されたバージョンが現在インストールされているバージョンと異なる場合、モジュールは要求されたバージョンをインストールします。

引数 local_package は、Ansible コントロール ノード上Junos OSパスを定義します。インストール中、モジュールは、ターゲット デバイスでストレージのクリーンアップ操作を実行し、デバイスの /var/tmp ディレクトリにソフトウェア イメージをコピーし、ファイルのチェックサムを検証し、アクティブな設定に対して新しいソフトウェアを検証してから、ターゲット ホストの各 ルーティング エンジン にソフトウェアをインストールします。デフォルトでは、モジュールはインストールがルーティング エンジン後に各インターフェイスを再起動しますが、このタスクは明確 software に reboot: True 設定されています。

タスクはモジュールの結果を変数に格納 response し、1 つのハンドラーに通知します。ユーザーがチェック モードを使用してプレイブックを実行しない場合、ハンドラーはデバイスとのセッションを確立して、デバイスがオンラインに戻ってくる wait_reboot か確認します。この変数は、コントロール ノードがデバイスとの再接続を試みる時間 wait_time の長さを定義します。

この例では、インストール logfile の進行状況をログに記録するパラメーターを含まれています。この機能は、インストールが失敗した場合のデバッグや、デバイスへのインストールの日時のロギングに重要です。プレイブックを実行するユーザーには、指定されたログ ファイルに書き込む権限が必要です。デフォルトでは、重大度レベルの警告以上のメッセージだけがログに記録されます。この例では、重大度レベル INFO 以上のメッセージをログに記録してインストールを監視するオプションを使用してプレイブック -v を実行します。

構成

Ansibleプレイブックの作成

モジュールを使用して仮想ネットワークを実行しているデバイスにソフトウェア イメージをインストールするプレイブックを作成するには、 software 次の手順にJunos OS。

  1. プレイブックのプレートと、モジュールをローカルで実行するこのプレイを含めます。

  2. この例では、必要な変数を定義またはインポートします。この例では、必要なバージョンJunos OS、新しいイメージへのパスなどが含まれます。

  3. (オプション)NETCONF 接続を検証するタスクを作成します。

  4. デバイスに Junos OS パッケージをインストールし、ハンドラーに通知するタスクを作成します。

  5. (オプション)モジュールレスポンスを印刷するタスクを作成します。

  6. 再起動後にデバイスがオンラインに戻ってくるのを確認するハンドラーを作成します。

    ハンドラー名は、インストール タスクで参照されているのと同じ名前にする必要があります。

結果

Ansible Control Node で、完了したプレイブックを確認します。プレイブックに意図したコードが表示されない場合は、この例の手順を繰り返してプレイブックを修正します。

プレイブックの実行

プレイブックを実行するには、以下の通りを実行します。

  • 制御ノード ansible-playbook で コマンドを発行し、プレイブックパスと必要なオプションを提供します。

検証

インストールの検証

目的

ソフトウェアのインストールが正常に完了されたことを検証します。

アクション

プレイブックの出力は、タスクの失敗を示す必要があります。ただし、インストールの詳細については、プレイブックで定義されたログ ファイルの内容も確認できます。ログ ファイル出力の例をここに示します。一部の出力は、複雑さのために除外されています。

意味

ログ ファイルの内容は、イメージが正常にコピーされ、ターゲット デバイス上の両方のルーティング エンジンにインストールされたことを示しています。

関連ドキュメント

リリース履歴テーブル
リリース
説明
2.0.0
ジュニパー.junos リリース 2.0.0 より、juniper_junos_software モジュールは、この junos_install_os モジュールの機能を置きjunos_install_osします。