コンテナでのサードパーティアプリケーションの実行
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 / extensionパーティションのサイズはプラットフォーム駆動型です: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でアプリケーションを実行して、それ自体を同期できるようにする必要があります。このようなアプリケーションには、それ自体を管理し、すべてのインスタンスと通信するために必要なビジネス ロジックが必要です。
コンテナでのネットリンクまたはパケットIOの有効化
コンテナーに Netlink や PacketIO などの追加機能が必要な場合は、Docker コマンドに追加の引数を指定する必要があります。また、特定のリリースでNetlink機能を有効にするために、サービスを有効にする nlsd
必要があります。次の例は、Docker コマンドに引数を追加することによって、コンテナーの Netlink 機能または PacketIO 機能をアクティブ化する方法を示しています。
Docker サービスの開始時に読み取り専用の名前の永続ボリュームを作成します。ボリュームを
jnet
マウントすると、WAN/データポート経由でPacketIOおよびNetlink機能に必要なライブラリがマウントされます。--mount source=jnet,destination=/usr/evo
ホストのネットワーク名前空間と IPC 名前空間をコンテナーと共有します。WAN/データ ポートを介した PacketIO および Netlink 機能を必要とするコンテナーは、ホスト ネットワークと IPC 名前空間に存在する必要があります。
--network=host --ipc=host
システムの再起動時にコンテナを自動的に起動します。
--restart=always
Netlink および PacketIO ライブラリに必要なネット管理機能を有効にします。
--cap-add=NET_ADMIN
WAN/データ ポート上の Netlink と PacketIO に必要な環境変数を有効にします。
--env-file=/run/docker/jnet.env
jtd0 デバイスをホストからコンテナにマウントして、PacketIO を支援します。
--device=/dev/jtd0
ホストの / dev/shm ディレクトリを、WAN/データ ポート経由で Netlink と PacketIO のコンテナーにマウントします。
-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
コンテナにネットリンク関連の処理が必要な場合は、次のCLI設定でJunos OS Evolvedでネットリンク非同期API(
nlsd
)プロセスを有効にする必要もあります。[edit] user@host# set system processes nlsd enable
PacketIOとNetlink機能を必要とするネイティブLinuxまたはコンテナベースのアプリケーションは、動的にリンクする必要があります。UbuntuベースのDockerコンテナは、ジュニパーネットワークスが公式に認定した唯一のコンテナであるため、使用することをお勧めします。Ubuntuベースのコンテナでは、ベースとなるJunos EvolvedOSglibc
と互換性のあるものglibc
を使用する必要があります。
Docker コンテナの VRF の選択
コンテナは、Docker デーモンから仮想ルーティングと転送 (VRF) を継承します。個別の VRF でコンテナを実行するには、対応する VRF で Docker デーモン インスタンスを起動する必要があります。インスタンスでは docker@vrf.service
、対応する VRF でデーモンを起動できます。VRF が指定されていない場合、VRF のデフォルトは vrf0
になります。
は docker.service
デフォルトで実行されます vrf:none
。
特定の VRF のドッカーデーモンは、/ 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 ## check current defaults, after starting extensions-cglimits.service ## $ /usr/libexec/extensions/extensions-cglimits get ## please start extensions-cglimits.service to apply changes here ## 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
値を追加します。
-
EXTENSIONS_FS_DEVICE_SIZE_MIB=
コンテナが使用できる最大ストレージ容量を制御します。値をバイト単位で入力します。デフォルト値は、8GB または /var の合計サイズの 30% のいずれか小さい方です。 -
EXTENSIONS_CPU_QUOTA_PERCENTAGE=
コンテナが使用できる最大 CPU 使用率を制御します。CPU 使用率の割合として値を入力します。 -
EXTENSIONS_MEMORY_MAX_MIB=
コンテナーが使用できる物理メモリの最大量を制御します。値をバイト単位で入力します。
コンテナーのリソース制限を変更する前に、構成でサポートする必要があるスケールの CPU とメモリの要件に注意してください。コンテナのリソース制限を増やす場合は、システムに負担がかからないように注意してください。