juniper.device.software Ansibleモジュールを使用して、Junosデバイスにソフトウェアをインストールする

juniper.device.software Ansible モジュールを使用して、Junos OSを実行しているデバイスまたはJunos OS Evolvedを実行しているデバイスにソフトウェアをインストールできます。

Ansibleを使用してソフトウェアをインストールする

ジュニパーネットワークスは、JunosデバイスにソフトウェアイメージをインストールできるAnsibleモジュールを提供しています。 表1は 、モジュールの概要を示しています。 juniper.device コレクションの特定のモジュール セットを既に使用している場合は、そのセットの モジュール を使用します。

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

コレクション

モジュールセット

モジュール名

juniper.device

juniper.device

juniper.device.software

junipernetworks.junos

juniper.device.junos_package

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

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

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

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

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

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

no_copy パラメータ

local_package または pkg_set パラメータ

remote_package パラメータ

Ansible制御ノード

省略するか、次のように設定します。 false

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

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

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

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

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

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

–

リモートロケーション

–

–

ソフトウェア パッケージがインストールされているターゲット Junos デバイスの視点からの URL。

ターゲットデバイス

に設定 true

–

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

ソフトウェアパッケージがAnsible制御ノード上にある場合は、インストールに適した引数を含めます。

  • local_package—スタンドアロンのJunosデバイスまたは非混在バーチャルシャーシのメンバーにソフトウェアをインストールします。引数値は、ソフトウェアイメージへの絶対パスまたは相対パスを指定する単一の文字列です。

  • pkg_set—混在バーチャルシャーシ内のメンバーにソフトウェアをインストールします。引数値は、さまざまなバーチャルシャーシメンバーのソフトウェアイメージの絶対ファイルパスまたは相対ファイルパスを順不同で指定する文字列のリストです。

    次に例を示します。

デフォルトでは、 local_package または pkg_set 引数を含めると、モジュール はソフトウェア パッケージを Ansible 制御ノードからターゲット Junos デバイス(個々のデバイスまたはプライマリ デバイス)の /var/tmp ディレクトリバーチャルシャーシコピーします。 local_package イメージを別のディレクトリにコピーする場合は、 remote_package 引数を定義し、ターゲットディレクトリを指定します。 remote_package 引数にファイル名が含まれている場合、 local_package 引数と remote_package 引数のファイル名は同じでなければならず、そうでない場合はモジュールがエラーを生成します。

ソフトウェアパッケージがターゲットJunosデバイス(個々のデバイスバーチャルシャーシまたはプライマリデバイス)に既に存在する場合、モジュールにはremote_package引数だけでなくno_copy: true引数も含める必要があります。remote_package引数は、ターゲットデバイス上の既存のソフトウェアパッケージへのファイルパスを指定します。ディレクトリremote_package指定しない場合、デフォルトは/var/tmpです。

ソフトウェアパッケージがAnsible制御ノードまたはターゲットデバイス以外の場所にある場合、モジュールには remote_package 引数を含め、ソフトウェアパッケージの場所を指定する必要があります。 remote_package の値は、ターゲットJunosデバイスの視点からのURLです。使用できるURL形式については、 Junos OS CLIコマンドでファイル名とURLを指定するための形式を参照してください。

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

Ansibleを使用してJunosデバイスにソフトウェアパッケージをインストールするには、 juniper.device.software モジュールを実行し、必要な引数を指定します。次に例を示します。

juniper.device.softwareモジュールを実行すると、以下の操作が実行されます。

  1. version引数で指定されたJunos OSバージョン、またはversion引数が省略されている場合はソフトウェアパッケージのファイル名で指定されたバージョンを、管理対象デバイスにインストールされているバージョンと比較します。インストールされているバージョンと目的のバージョンが同一である場合、モジュールは残りのインストール手順を省略し、changedとfailedをfalseに設定します。
  2. ソフトウェアパッケージがAnsible制御ノード上にあり、 no_copy パラメーターが省略されているか falseに設定されている場合、モジュールは以下の操作を実行します。
    • checksum_algorithm引数で指定されたアルゴリズムを使用して、ローカルソフトウェアパッケージまたはパッケージのチェックサムを計算します。使用可能なchecksum_algorithm値は、md5、sha1、sha256です。デフォルトはmd5です。または、checksum引数にチェックサムを指定することもできます。

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

    • SCPまたはFTPは、同じ名前とチェックサムを持つファイルがデバイス上のターゲットの場所にまだ存在しない場合、ターゲットデバイスにパッケージをコピーします。

      local_packageを含めると、モジュールはパッケージをremote_packageディレクトリにコピーするか、remote_packageが指定されていない場合は/var/tmpディレクトリにコピーします。pkg_setを含めると、モジュールは常にバーチャルシャーシプライマリ デバイスの/var/tmpディレクトリにパッケージをコピーします。

      注:

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

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

ソフトウェアパッケージがターゲットデバイスにインストールされると、最初にそこでダウンロードされたか、モジュールによってコピーされたかにかかわらず、モジュールは次の操作を実行します。

  1. validate引数がfalseに設定されていない限り、新しいパッケージに対して設定を検証します。

    注:juniper.deviceリリース2.0.4以降、validateパラメーターのデフォルトはtrueです。それ以前のリリースでは、デフォルトはfalseです。
  2. all_reがfalseに設定されていない限り、個々のルーティングエンジンにパッケージをインストールします。

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

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

タイムアウト値を指定する方法

juniper.device.softwareモジュールは、NETCONFセッションを介して操作を実行します。NETCONF RPCのタイムアウトのデフォルト時間は30秒です。インストールプロセス中に、特定の操作により、RPCタイムアウト間隔が次のように増加します。

  • デバイスへのパッケージのコピーとインストール—1800秒(30分)

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

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

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

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

juniper.device.softwareモジュールを使用してデバイスにソフトウェアをインストールすると、モジュールは含まれているインストール引数に対して適切なRPCを呼び出します。例えば、モジュールは、標準Junos OSインストールに対して<request-package-add> RPC、VMホストアップグレードに対して<request-vmhost-package-add>RPC、統合ISSUシナリオに対して<request-package-in-service-upgrade>RPCを呼び出します。

このモジュールでは、 validate オプションなど、多くのインストールオプションに対して明示的な引数がサポートされています。このモジュールは、 kwargs の議論も支持しています。引数を使用すると、RPC がサポートする追加のオプションを含めることができます。 kwargs 引数は、追加でサポートされているオプションのキーと値のペアのディクショナリを取ります。

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

注:

ターゲット Junos デバイスが特定の RPC に対してサポートしているインストール オプションのみを含める必要があります。

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

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

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

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

以下のプレイブックは、指定されたデバイス上のJunos OSとホストOSをアップグレードして再起動します。

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

juniper.device.softwareモジュールは、機能をサポートし、必要な要件を満たすデバイス上での統合型ISSUまたはNSSUの実行をサポートします。ISSUおよびNSSUの統合機能の詳細については、ご使用の製品のソフトウェアマニュアルを参照してください。

統合型ISSU機能により、コントロールプレーンを中断することなく、トラフィックの中断を最小限に抑えることなく、2つの異なるJunos OSリリース間でアップグレードすることができます。統合型ISSUを実行するには、 software モジュールに issu: true 引数を含める必要があります。次に例を示します。

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

EXシリーズバーチャルシャーシメンバーにソフトウェアをインストールする方法

一般に、混在していないEXシリーズのバーチャルシャーシをアップグレードする場合、 インストールプロセスの概要 で説明されているインストールプロセスに従って、バーチャルシャーシ全体をアップグレードします。ただし、バーチャルシャーシ内の特定のメンバースイッチにソフトウェアをインストールする必要がある場合があります。 juniper.device.software モジュールでは、EXシリーズが混在していないバーチャルシャーシ内の個々のメンバースイッチにソフトウェアパッケージをインストールすることができます。

特定のメンバーにソフトウェアをインストールするには、 member_id 引数を含め、メンバーIDを指定する文字列のリストを定義します。システムが、バーチャルシャーシのプライマリデバイスから指定したメンバーにソフトウェアパッケージをインストールします。

以下のAnsibleプレイブックは、EXシリーズバーチャルシャーシのメンバー0とメンバー1のソフトウェアをアップグレードします。

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

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

要件

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

  • juniper.deviceコレクションがインストールされたAnsible 2.17以降を実行している構成管理サーバー

  • NETCONFを有効にし、適切な権限でユーザーアカウントが設定されたJunosデバイス

  • Ansible制御ノードとJunosデバイス上の適切なユーザーに設定されたSSHパブリック/プライベートキーペア

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

概要

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

このプレイブックには、ansible.builtin.wait_for モジュールを利用して、デフォルトの NETCONF ポート 830 を使用して Junos デバイスとの NETCONF セッションの確立を試みる Check NETCONF connectivity タスクが含まれています。プレイブックの実行中に制御ノードがデバイスとのNETCONFセッションの確立に失敗した場合、そのデバイスのプレイにある残りのタスクをスキップします。

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

local_package引数は、Ansible制御ノード上のJunos OSソフトウェアパッケージのパスを定義します。インストール中に、モジュールは以下を実行します。

  • ターゲット・デバイス上でストレージ・クリーンアップ操作を実行します

  • ソフトウェアイメージをデバイスの /var/tmp ディレクトリにコピーします

  • ファイルのチェックサムを検証します

  • アクティブな設定に対して新しいソフトウェアを検証します

  • ターゲットホストの各ルーティングエンジンにソフトウェアをインストールします

デフォルトでは、インストールが完了すると juniper.device.software モジュールが各ルーティングエンジン再起動しますが、このタスクではわかりやすくするために明示的に reboot: true を設定します。

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

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

設定

Ansibleプレイブックの作成

juniper.device.softwareモジュールを使用してJunosデバイスにソフトウェアイメージをインストールするプレイブックを作成するには:

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

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

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

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

  5. (オプション)モジュール応答を出力するタスクを作成します。

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

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

結果

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

プレイブックを実行する

プレイブックを実行するには:

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

検証

インストールを確認する

目的

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

アクション

プレイブックの出力には、失敗したタスクが含まれているはずです。ただし、インストールの詳細については、プレイブックで定義されているログファイルの内容を確認することもできます。ログファイル出力の例を次に示します。簡潔にするために、一部の出力は省略されています。

意味

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

変更履歴テーブル

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。

リリース
説明
2.0.4
juniper.deviceリリース2.0.4以降、validateパラメーターのデフォルトはtrueです。以前のリリースでは、デフォルトはfalseです。