Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

ジュニパーネットワークスのAnsibleモジュールを使用して、Junosデバイスにソフトウェアをインストールします。

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

ジュニパーネットワークスは、Junosデバイスへのソフトウェアイメージのインストールまたはアップグレードを可能にするAnsibleモジュールを提供します。 表 1 にモジュールの概要を示します。

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

コンテンツ セット

モジュール名

juniper.device 徴収

software

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

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

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

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

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

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

no_copy パラメーター

local_package または pkg_set パラメーター

remote_package パラメーター

Ansible制御ノード

省略するか、に設定 false

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

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

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

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

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

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

リモートロケーション

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

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

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

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

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

  1. version 引数に指定されたJunos OSバージョン、または version 引数が省略された場合はソフトウェア パッケージ ファイル名に指定されたバージョンを、管理対象デバイスにインストールされているバージョンと比較します。インストールされているバージョンと必要なバージョンが同じ場合、モジュールは残りのインストール手順をスキップし、changedfailedfalseに設定します。
  2. ソフトウェア パッケージが Ansible 制御ノードにあり、no_copy パラメータが省略されているか、falseに設定されている場合、モジュールは次の操作を実行します。
    • checksum_algorithm 引数で指定されたアルゴリズムを使用して、ローカル ソフトウェア パッケージのチェックサムを計算します。指定できるchecksum_algorithm値は、md5sha1、および 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 引数が true に設定されている場合に、新しいパッケージに対して設定を検証します。

    手記:

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

  2. all_refalse に設定されていない限り、個々のルーティングエンジンにパッケージをインストールします。

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

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

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

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

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

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

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

場合によっては、インストール・プロセス、チェックサム計算、またはストレージ・クリーンアップが、これらの時間間隔を超えることがあります。これらの操作のタイムアウト値を変更するには、 install_timeoutchecksum_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 ExplorerでRPCのリクエストタグを検索してください。

手記:

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

次のプレイブックでは、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リリース間のアップグレードが可能になります。統合インサービス ソフトウェア アップグレードを実行するには、 software モジュールに issu: true 引数を含める必要があります。例えば:

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

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

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

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

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

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

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

必要条件

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

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

  • NETCONF が有効な Junos デバイスと、適切なパーミッションが設定されたユーザー アカウント

  • Ansible制御ノードとJunosデバイス上の適切なユーザー向けに設定されたSSH公開/秘密キーペア

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

概要

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

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

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

local_package引数は、Ansible制御ノード上のJunos OSソフトウェアパッケージのパスを定義します。インストール中に、モジュールはターゲットデバイス上でストレージクリーンアップ操作を実行し、ソフトウェアイメージをデバイスの/var/tmpディレクトリにコピーし、ファイルのチェックサムを検証し、新しいソフトウェアをアクティブな構成に対して検証してから、ターゲットホスト上の各ルーティングエンジンにソフトウェアをインストールします。デフォルトでは、software モジュールはインストールの完了後にルーティングエンジンごとにリブートしますが、このタスクではわかりやすくするためにreboot: trueを明示的に設定します。

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

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

構成

Ansible Playbook の作成

juniper.device.softwareモジュールを使用してJunosデバイスにソフトウェアイメージをインストールするプレイブックを作成するには、次の手順に従います。

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

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

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

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

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

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

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

業績

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

プレイブックを実行する

Playbook を実行するには、次のようにします。

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

検証

インストールの確認

目的

ソフトウェアのインストールが成功したことを確認します。

アクション

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

意味

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