コンテナ内でのサードパーティ製アプリケーションの実行
自社のアプリケーションを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コンテナをデプロイするには:
Dockerコンテナの管理
Dockerコンテナは、標準のDocker Linuxワークフローで管理されます。 docker ps
、 ps
、または top
Linuxコマンドを使用して、実行中のDockerコンテナを表示し、Dockerコマンドを使用してコンテナを管理します。Docker コマンドの詳細については、以下を参照してください。 https://docs.docker.com/engine/reference/commandline/cli/
Junos OS Evolvedの高可用性機能は、Dockerコンテナ内のカスタムアプリケーションではサポートされていません。アプリケーションに高可用性機能がある場合は、各REでアプリケーションを実行して、同期できるようにする必要があります。このようなアプリケーションには、自身を管理し、すべてのインスタンスと通信するために必要なビジネス ロジックが必要です。
コンテナでのNetlinkまたはPacketIOの有効化
コンテナーに Netlink や PacketIO などの追加機能が必要な場合は、Docker コマンドに追加の引数を指定する必要があります。また、特定のリリースでNetlink機能を有効にするには、 nlsd
サービスを有効にする必要があります。次の例は、Docker コマンドに引数を追加することで、コンテナの Netlink または PacketIO 機能をアクティブにする方法を示しています。
Dockerサービスの開始時に読み取り専用の名前の永続ボリュームを作成します。
jnet
ボリュームをマウントすると、WAN/データポートを介したPacketIOおよびNetlink機能に必要なライブラリがマウントされます。--mount source=jnet,destination=/usr/evo
ホストの Network 名前空間と IPC 名前空間をコンテナーと共有します。WAN/データポート経由のPacketIOおよびNetlink機能を必要とするコンテナは、ホストネットワークおよびIPC名前空間に存在する必要があります。
--network=host --ipc=host
システムの再起動時にコンテナを自動的に起動します。
--restart=always
NetlinkおよびPacketIOライブラリで必要なネット管理機能を有効にします。
--cap-add=NET_ADMIN
Netlink および PacketIO over WAN/データ ポートに必要な環境変数を有効にします。
--env-file=/run/docker/jnet.env
jtd0 デバイスをホストからコンテナにマウントして、PacketIO を使用します。
--device=/dev/jtd0
ホストの /dev/shm ディレクトリを、Netlink および PacketIO over WAN/data ポート用のコンテナにマウントします。
-v /dev/shm:/dev/shm
コンテナアプリケーションでマルチキャストグループ管理が必要な場合は、ホストからコンテナに /dev/mcgrp ディレクトリをマウントします。
-v /dev/mcgrp:/dev/mcgrp
Junos OS Evolvedリリース24.1R1以降、DNS解決を必要とするホストネットワーク名前空間内のコンテナは、
docker run
コマンドに--dns ::1
オプションを渡す必要があります。これは、Junos OS Evolvedリリース23.4以前では必要ありません。--dns ::1
コンテナにNetlink関連の処理が必要な場合は、次のCLI設定を使用して、Junos OS EvolvedでNetlink非同期API(
nlsd
)プロセスを有効にする必要もあります。[edit] user@host# set system processes nlsd enable
PacketIOおよびNetlink機能を必要とするネイティブLinuxまたはコンテナベースのアプリケーションは、動的にリンクする必要があります。UbuntuベースのDockerコンテナは、ジュニパーネットワークスによって公式に認定された唯一のコンテナであるため、使用することをお勧めします。Ubuntu ベースのコンテナーでは、ベース Junos Evolved OS glibc
と互換性のあるglibc
を使用する必要があります。
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
にバインドできます。
[vrf:none] user@host:~# docker -H unix:///run/docker-vrf0.sock run --rm -it –-privileged --network=host --ipc=host --cap-add=NET_ADMIN --mount source=jnet,destination=/usr/evo --device=/dev/jtd0 -v /dev/mcgrp:/dev/mcgrp -v /dev/shm:/dev/shm --env-file=/run/docker-vrf0/jnet.env --dns ::1 debian:stretch bash # explicitly preload libsi.so and avoid libnli.so. Bind ping’s socket to vrf0 (default) VRF [vrf:none] user@host: my-container/# LD_PRELOAD=libsi.so.0 ip vrf exec vrf0 ping 1.2.3.4
このアプローチでは、すべてのソケットを 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 プロセスに関連付けられます。
--env-file /run/docker-vrf/jnet.env --host unix:///run/docker-vrf.sock or export DOCKER_HOST=unix:///run/docker-vrf.sock
たとえば、 vrf0
でコンテナーを実行するには、次の Docker コマンドと引数を入力します。
[vrf:none] user@host:~# docker -H unix:///run/docker-vrf0.sock run --rm -it --network=host --ipc=host --cap-add=NET_ADMIN --mount source=jnet,destination=/usr/evo --device=/dev/jtd0 -v /dev/mcgrp:/dev/mcgrp -v /dev/shm:/dev/shm --env-file=/run/docker-vrf0/jnet.env --dns ::1 debian:stretch ip link 1002: et-01000000000: BROADCAST,MULTICAST,UP mtu 1514 state UP qlen 1 link/ether ac:a:a:18:01:ff brd ff:ff:ff:ff:ff:ff 1001: mgmt-0-00-0000: BROADCAST,MULTICAST,UP mtu 1500 state UP qlen 1 link/ether 50:60:a:e:08:bd brd ff:ff:ff:ff:ff:ff 1000: lo0_0: LOOPBACK,UP mtu 65536 state UP qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
コンテナは 1 つの VRF にのみ関連付けることができます。
コンテナのリソース制限の変更
コンテナのデフォルトのリソース制限は、 /etc/extensions/platform_attributesにあるファイルによって制御されます。このファイルを開くと、次のテキストが表示されます。
## Edit to change upper cap of total resource limits for all containers. ## applies only to containers and does not apply to container runtimes. ## memory.memsw.limit_in_bytes = EXTENSIONS_MEMORY_MAX_MIB + EXTENSIONS_MEMORY_SWAP_MAX_MIB:-0 ## please start extensions-cglimits.service to apply changes to CPU and Memory values here ## please restart var-extensions.mount to apply changes to partition resize here ## make sure the docker daemon is stopped before changing mount size ## For changing EXTENSIONS_FS_DEVICE_SIZE_MIB, please also remove file rm /var/extensions_fs ## make sure to create a backup before partition resize ## check current defaults, after starting extensions-cglimits.service ## $ /usr/libexec/extensions/extensions_cglimits get ## you can also set current values like this as an alternative to starting extensions-cglimits.service ## $ /usr/libexec/extensions/extensions_cglimits set ## if you set one of the memory values, set the other one as well – mandated by cgroup ## device size limit will be ignored once extensionsfs device is created #EXTENSIONS_FS_DEVICE_SIZE_MIB= #EXTENSIONS_CPU_QUOTA_PERCENTAGE= #EXTENSIONS_MEMORY_MAX_MIB= #EXTENSIONS_MEMORY_SWAP_MAX_MIB=
コンテナーのリソース制限を変更するには、ファイルの下部にある 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=
も指定する必要があります。Linuxcgroup
では、メモリと 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 とメモリの要件に注意してください。コンテナーのリソース制限を増やす場合は、コンテナーがシステムに負荷をかけないように注意してください。