在 Docker 上配置 cJunosEvolved
阅读本主题可了解 KVM 上 cJunosEvolved 实例部署的连接和配置
连接到 cJunosEvolved
您可以使用管理员凭据从 Ubuntu 主机通过 SSH 连接到 cJunosEvolved,如本节所示:
管理 IP 地址是在 Docker Compose YAML 文件中特定容器的“网络”部分下的“eth0_mgmt”中指定的地址。
每个 cJunosEvolved 都配置为使用管理员凭据进行 SSH 访问。管理员密码为“admin@123”。
如果您希望进行 root 访问,可以为 cJunosEvolved 设置 root 身份验证纯文本密码。完成此作的方式与处理任何 JunosEvolved 路由器相同。如果您希望以 root 身份登录,也请启用 SSH as root 用户:
set system root-authentication plain-text-password <enter the password twice>
set system services ssh root-login allow
# ssh admin@<management IP address> (admin@14.1.1.3) Password: Last login: Thu Mar 20 21:06:48 2025 from 14.1.1.1 --- JUNOS cJunosEvolved-25.2R1.1-EVO Linux (none) 5.15.164-10.22.33.18-yocto-standard-juniper-16971-g1c568856e6a0 #1 SMP PREEMPT Thu Feb 6 08:43:02 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux admin@re0>
ssh 的替代方法是使用主机服务器中的以下命令,进入 CLI 并配置容器。最好在运行 “docker logs -f cevo1 命令并看到容器(在本例中称为cevo1)已到达登录提示符后运行此命令。
# docker exec -ti cevo1 cli
root@cevo1>
配置 cJunosEvolved
配置 cJunosEvolved 的方法有多种:
手动配置
您可以通过 ssh 或“连接到 cJunosEvolved”部分中提到的 Docker 命令连接到 cJunosEvolved 容器中的 EVO VM,然后继续配置容器。
磁盘配置
通过 Docker Compose YAML 文件的 “volumes” 部分指定分层 Junos Evolved CLI 配置。在下面的示例中:
主机服务器上的特定容器目录中需要有一个名为 juniper.conf 的有效分层配置文件,例如: /root/cjunosevo/config/cevo1
cJunosEvolved 软件期望将 juniper.conf 文件放置在容器 Linux 端的目录 /home/evo/configdisk 中。见下文:
services:
cJunosEvo1:
#[snip]
privileged: true
volumes:
-'/root/cjunosevo/config/cevo1:/home/evo/configdisk'
自动配置
另一种选择是通过将 CPTX_AUTO_CONFIG 环境变量设置为 1 来自动配置 cJunosEvolved,如本手册前面所述。
自动配置选项是比磁盘配置更简约的配置工具。它与磁盘配置选项互斥,并优先于它。
自动配置基于从 Docker Compose YAML 文件中提取信息来执行 cJunosEvolved 的启动配置。自动配置可以配置以下内容:
-
- 管理员登录凭据:
- 用户 ID:admin
- 密码:admin@123
- 要启用 ssh,请运行命令
set system services ssh。 - 默认日志记录级别设置如下:
set system syslog file interactive-commands interactive-commands anyset system syslog file messages any noticeset system syslog file messages authorization info - 基于为“eth0_managment”指定的值的 cJunosEvolved 的管理 IP
- Compose YAML 文件中指定的从 eth4 开始的接口的数据接口“ipv4_address”值在 RE 的启动配置中配置。CLI 中使用的接口表示法是根据指示应使用 BX 还是 BT、通道化还是非通道化表示法的环境变量自动配置。有关更多详细信息,请参阅本手册中的 WAN 接口表。
- 管理员登录凭据:
例如,在自动配置 BX 通道化 cJunosEvolved 的情况下,如果 Docker Compose YAML 文件具有:
eth4:
ipv4_address: 100.1.1.2
# and this in the “networks” section:
networks:
eth4:
name: eth4
driver: bridge
ipam:
driver: default
config:
- subnet: 100.1.1.0/24
然后运行命令 set interfaces et-0/0/0:0 unit 0 family inet address 100.1.1.2/24 。此配置将在路由引擎 CLI 中设置。
此外,根据 BX 还是 BT,通道化还是非通道化,所有数据接口都会在路由引擎 CLI 中设置相应的通用接口相关配置。以下示例适用于通道化 BX 的第一个数据接口 (eth4):
set interfaces et-0/0/0 number-of-sub-ports 4
set interfaces et-0/0/0 speed 100g
如果在 Docker Compose YAML 文件中设置了“CPTX_AUTO_CONFIG:1”环境变量,并且未为同一文件中的数据接口指定 IPv4 地址,则 cJunosEvolved 将根据 Docker 提供的内容分配 IP 地址。例如,如果为相应的数据接口指定了子网 IP,则 Docker 将从该子网分配一个 IP 地址,并将在相应接口的 cJunosEvolved 路由引擎 CLI 中配置该地址。建议在使用 CPTX_AUTO_CONFIG 时,在 YAML 文件的服务部分提供每个接口的 IP 地址,并在 YAML 文件的“网络”部分提供该网络的匹配子网 IP 地址,以便您可以控制 IP 地址。
如何停止、启动和重新启动 cJunosEvolved
停止
Docker Compose 文件中的 cJunosEvolved 容器可以以平滑的方式同时停止,以便保留其磁盘以供下次重新启动。从主机服务器运行 stop 命令:
# docker compose -f <docker-compose-filename>.yaml stop -t <secs>
-t 选项要求 Docker Compose 等待指定的秒数,然后再向容器发送 SIGTERM。要指定的超时值取决于各种因素,包括存储在容器中的日志和配置的大小以及主机服务器的磁盘速度。在测试中,240 秒的 -t 值就足够了,通常小于 60 秒。请根据您的用例对此值进行基准测试,如下所示:
- 在主机服务器上,使用命令开始
docker logs -f <container-name>监视 EVO VM 日志。这将从 EVO VM 打印正在进行的日志。 -
stop发出具有较大 -t 值的命令,如下所示:# docker compose -f <docker-compose-filename>.yaml stop -t 240 - 当容器收到命令通知
stop并相应地进行时,您将看到容器日志。为了成功关闭,应该在日志末尾看到如下消息:2025 年 3 月 28 日星期五 22:40:14 UTC:EVO VM 在 [30 秒] 内成功关闭
一旦 cJunosEvolved 停止,“docker container ls”将不会显示它,但其网络将保留以供将来重新启动,如下例所示:
# docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 171a361a6f86 cjunosevolved:25.2R1.1-EVO "/entrypoint.sh" 3 days ago Up 3 days cevo2 740524cf95b3 cjunosevolved:25.2R1.1-EVO "/entrypoint.sh" 3 days ago Up 3 days cevo1 # docker compose -f dual-bx-bt-chan-autocompose.yaml stop -t 180 [+] Stopping 2/2 ✔ Container cevo1 Stopped 36.9s ✔ Container cevo2 Stopped 36.9s # docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES # docker network ls NETWORK ID NAME DRIVER SCOPE 785df5e996d5 bridge bridge local 6222dbea40c6 eth0_mgmt bridge local fb5a95cd7236 eth1_reserved bridge local cec52e294667 eth2_reserved bridge local 4f6d181ab5ec eth3_reserved bridge local 3a8ccd8d44dc eth4 bridge local 4e701a843d95 eth5 bridge local 6e3035f60692 eth6 bridge local bf4f5b2583aa eth7 bridge local 0f8822dda3ab eth8 bridge local 507f0ad3feaf eth9 bridge local 4af981ed503e eth10 bridge local 7d280f0f348a eth11 bridge local 2304e4ab7184 host host local da25cbdc438c none null local
使用以下命令验证两个容器是否已成功 docker logs 停止:
# docker logs cevo1 [snip] Tue Apr 1 00:00:24 UTC 2025: EVO VM shutdown successfully in [30secs] # docker logs cevo2 [snip] Tue Apr 1 00:00:24 UTC 2025: EVO VM shutdown successfully in [30secs]
开始
可以使用命令 docker compose start 再次启动已停止的容器。
对于全新安装,请使用本文档前面所示的 docker compose up -d 命令。
以下示例演示了 docker compose start.
# docker compose -f <docker-compose-file-name> [+] Running 2/2 ✔ Container cevo1 Started 6.2s ✔ Container cevo2 Started 6.2s # docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 171a361a6f86 cjunosevolved:25.2R1.1-EVO "/entrypoint.sh" 3 days ago Up 54 seconds cevo2 740524cf95b3 cjunosevolved:25.2R1.1-EVO "/entrypoint.sh" 3 days ago Up 54 seconds cevo1 You can monitor the console of EVOVM as it boots up via the following command. It should show cJunosEvolved reach login prompt and shows in this case it took 66 seconds to do so. #docker logs -f <container-name> Tue Apr 1 00:47:41 UTC 2025: EVO VM boot Done in [66secs] Tue Apr 1 00:47:41 UTC 2025: entrypoint.sh is done, enter wait loop.. re0 login:
重新启动
您可以使用命令 docker compose -f <docker-compose-file-name> restart -t 90 重新启动正在运行的容器。
提供您在停止部分中提到的基准测试的“-t”。一个 restart 命令是 a stop 然后 start 一个命令,因此需要告诉 Docker Compose 多长时间提供容器以正常停止以保护容器磁盘,如上面的停止部分所述。
例如:
# docker compose -f <docker-compose-file-name>dual-bx-bt-chan-autocompose.yaml restart -t 90 [+] Restarting 2/2 ✔ Container cevo1 Started 41.1s ✔ Container cevo2 Started In this case, the container was stopped gracefully in 30 secs as shown in the “docker logs” command. It was restarted as shown above. Tue Apr 1 00:58:18 UTC 2025: EVO VM shutdown successfully in [30secs]