Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

コンテナ内でのサードパーティ製アプリケーションの実行

自社のアプリケーションをJunos OS Evolvedで実行する場合、Dockerコンテナとして導入するオプションがあります。コンテナは Junos OS Evolved 上で実行され、アプリケーションはコンテナ内で実行されるため、ホスト OS から分離された状態に保たれます。 コンテナは、 /var/extensionsにマウントされた別のパーティションにインストールされます。コンテナは、再起動やソフトウェアのアップグレード後も維持されます。

手記:

DockerコンテナはJunos OS Evolvedには統合されておらず、Dockerコマンドを使用して、すべてLinuxで作成および管理されます。Dockerコンテナとコマンドの詳細については、Dockerの公式ドキュメントを参照してください。 https://docs.docker.com/get-started/

コンテナーには、システムから使用できるリソースに対する既定の制限があります。

  • Storage/var/extensions パーティションのサイズはプラットフォーム主導型で、8GB または /var の合計サイズの 30% のいずれか小さい方です。

  • Memory – コンテナには、デフォルトの物理メモリ制限はありません。これは変更できます。

  • CPU – コンテナにはデフォルトの CPU 制限はありません。これは変更できます。

手記:

必要に応じて、コンテナのリソース制限を変更できます。 コンテナのリソース制限の変更を参照してください。

Dockerコンテナのデプロイ

Dockerコンテナをデプロイするには:

  1. VRF(vrf0など)にバインドされたDockerサービスを開始します。Junos OS Evolvedリリース23.4R1以前では、このDockerサービスによって管理されるすべてのコンテナがこのLinux VRFにバインドされます。Junos OS Evolved リリース 24.1R1 以降では、コンテナ内の特定のタスクを VRF にバインドすることをお勧めします。詳細については、「Docker コンテナの VRF の選択」を参照してください。
  2. 次の環境変数を構成して、クライアントの Docker ソケットを設定します。
  3. 画像をインポートします。
    手記:

    import コマンドの URL は、コンテナーごとに変更する必要があります。

  4. イメージがダウンロードされていることを確認し、イメージ ID を取得します。
  5. イメージ ID を使用してコンテナーを作成し、そのコンテナーに bash セッションを入力します。
  6. イメージIDを使用してパケットIOとNetlink機能を備えたコンテナを作成し、そのコンテナにbashセッションを入力します。
    手記:

    Dockerコンテナは、 -it 引数を使用しない限り、デフォルトでデーモン化されます。

Dockerコンテナの管理

Dockerコンテナは、標準のDocker Linuxワークフローで管理されます。 docker psps 、または top Linuxコマンドを使用して、実行中のDockerコンテナを表示し、Dockerコマンドを使用してコンテナを管理します。Docker コマンドの詳細については、以下を参照してください。 https://docs.docker.com/engine/reference/commandline/cli/

手記:

Junos OS Evolvedの高可用性機能は、Dockerコンテナ内のカスタムアプリケーションではサポートされていません。アプリケーションに高可用性機能がある場合は、各REでアプリケーションを実行して、同期できるようにする必要があります。このようなアプリケーションには、自身を管理し、すべてのインスタンスと通信するために必要なビジネス ロジックが必要です。

DockerコンテナのVRFの選択

Junos OS Evolvedリリース23.4R1以前では、コンテナはDockerプロセスからVRF(仮想ルーティングと転送)を継承します。別の VRF でコンテナを実行するには、対応する VRF で Docker プロセス インスタンスを起動する必要があります。 docker@vrf.service インスタンスでは、対応する VRF でプロセスを開始できます。VRF が指定されていない場合、VRF はデフォルトで vrf0 になります。

docker.serviceはデフォルトでvrf:noneで実行されます。

Junos OS Evolved リリース 24.1R1 以降では、 ip vrf exec task コマンドを使用して、コンテナ内の特定のタスクを特定の Linux VRF にバインドすることをお勧めします。これには、コンテナーをオプション --privileged で起動する必要があり、コンテナーには互換性のあるバージョンの iproute2 がインストールされている必要があります。また、コンテナーは、ネットワーク名前空間をホストと共有する必要があります。また、ソケット オプション SO_BINDTODEVICE を使用して、コンテナー内の特定のタスクまたはアプリケーションのソケットを特定の Linux VRF デバイスにバインドすることもできますが、その場合は iproute2 は必要ありません。

ip vrf show コマンドは、使用可能なすべての Linux VRF を一覧表示します。iproute2 を使用してコンテナ内のタスクのソケットを VRF にバインドする場合は、--env-file=/run/docker-vrf0/jnet.env を使用して一部の環境変数を上書きし、iproute2に干渉しないようにプリロードされないようにlibnli.soことをお勧めします。

次のコマンドを使用して、コンテナを起動し、コンテナのタスクに関連付けられたソケットをデフォルトの vrf vrf0 にバインドできます。

このアプローチでは、すべてのソケットを 1 つの VRF にバインドするのではなく、コンテナ内のさまざまなタスクに関連付けられたさまざまなソケットを異なる VRF に関連付けることができます。

特定の VRF の Docker プロセスは、 /run/docker-vrf.sock にある対応するソケットをリッスンします。

これは、Linux で表示される VRF であり、Junos OS Evolved VRF ではありません。ユーティリティ evo_vrf_name (Junos OS Evolved リリース 24.1 以降で使用可能)を使用して、Junos OS Evolved VRF に対応する Linux VRF を検索できます。

Docker クライアントは、次の引数を使用して VRF 固有の Docker プロセスに関連付けられます。

たとえば、 vrf0 でコンテナーを実行するには、次の Docker コマンドと引数を入力します。

手記:

コンテナは 1 つの VRF にのみ関連付けることができます。

コンテナのリソース制限の変更

コンテナのデフォルトのリソース制限は、 /etc/extensions/platform_attributesにあるファイルによって制御されます。このファイルを開くと、次のテキストが表示されます。

コンテナーのリソース制限を変更するには、ファイルの下部にある EXTENSIONS エントリに値を追加します。Dockerプロセスを開始する前に、必ずこれを行ってください。

  • EXTENSIONS_FS_DEVICE_SIZE_MIB=コンテナが使用できる最大ストレージ容量を制御します。値をメガバイト単位で入力します。デフォルト値は、8000 または /var の合計サイズの 30% のいずれか小さい方です。Dockerプロセスを初めて開始する前に、必ずこのエントリを追加してください。後でこの値を変更する必要がある場合は、既存のパーティションを削除する必要があり、このパーティション上のデータが失われる可能性があります。Dockerサービスがすでに開始された後にこのストレージパーティションを変更する必要がある場合は、最初にsystemctl stop dockerコマンドでDockerプロセスを停止する必要があり、systemctl stop var-extensions.mountコマンドに続いてrm /var/extensions_fsコマンドを使用して既存のパーティションを削除できます。この属性を変更したら、Docker プロセスを再度開始すると、指定したサイズの新しいパーティションが作成されます。また、systemctl restart var-extensions.mountコマンドでvar-extensions.mount再起動して、同じ結果を得ることもできます。重要なデータが失われないように、パーティションのバックアップを取ることをお勧めします。この値を /var パーティションの 30% を超えて増やすと、Junos OS Evolved の通常の機能に影響を与える可能性があるため、その方法はお勧めしません。

  • EXTENSIONS_CPU_QUOTA_PERCENTAGE= コンテナが使用できる最大CPU使用率を制御します。CPU 使用率のパーセンテージとして値を入力します。デフォルト値は20%ですが、プラットフォームによって異なる場合があります。

  • EXTENSIONS_MEMORY_MAX_MIB= コンテナが使用できる物理メモリの最大量を制御します。値をメガバイト単位で入力します。デフォルト値は 2000 ですが、プラットフォームによって異なる場合があります。これを変更する必要がある場合は、スワップ値 EXTENSIONS_MEMORY_SWAP_MAX_MIB= も指定する必要があります。Linux cgroup では、メモリと CPU の制限に不合理な値を設定することは許可されていないことに注意してください。設定した値が cgroupに反映されない場合、最も可能性の高い理由は、値が間違っていることです(非常に高いまたは非常に低い可能性があります)。

  • EXTENSIONS_MEMORY_SWAP_MAX_MIB= コンテナが使用できるスワップメモリの最大量を制御します。値をメガバイト単位で入力します。デフォルト値は使用可能なスワップ領域の 15% ですが、プラットフォームによって異なる場合があります。どちらかを変更する場合は、 EXTENSION_MEMORY_MAX_MIB=EXTENSIONS_MEMORY_SWAP_MAX_MIB= の両方を設定する必要があります。スワップの推奨値は EXTENSION_MEMORY_MAX_MIB=の15%です。スワップの実際の cgroup 値は EXTENSION_MEMORY_MAX_MIB + EXTENSIONS_MEMORY_SWAP_MAX_MIBになります。

既定では、これらはプラットフォーム固有の値に設定されるため、コンテナーを起動する前に値を設定することをお勧めします。

注意:

コンテナーのリソース制限を変更する前に、構成でサポートする必要があるスケールの CPU とメモリの要件に注意してください。コンテナーのリソース制限を増やす場合は、コンテナーがシステムに負荷をかけないように注意してください。