컨테이너에서 타사 애플리케이션 실행
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 – 컨테이너의 기본 결합 물리적 메모리 제한은 2GB입니다. 이것은 변경할 수 있습니다.
-
CPU – 컨테이너의 기본 결합 CPU 제한은 CPU 코어 1개의 20%입니다. 이것은 변경할 수 있습니다.
필요한 경우 컨테이너에 대한 리소스 제한을 수정할 수 있습니다. 컨테이너에 대한 리소스 제한 수정을 참조하십시오.
Docker 컨테이너 배포
Docker 컨테이너를 배포하려면 다음을 수행합니다.
Docker 컨테이너 관리
Docker 컨테이너는 표준 Docker Linux 워크플로를 통해 관리됩니다. docker ps또는 Linux 명령을 사용하여 실행 중인 Docker 컨테이너를 표시하고, ps top Docker 명령을 사용하여 컨테이너를 관리합니다. Docker 명령에 대한 자세한 내용은 다음을 참조하세요. https://docs.docker.com/reference/cli/docker/
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
호스트의 네트워크 및 IPC 네임스페이스를 컨테이너와 공유합니다. WAN/데이터 포트를 통해 PacketIO 및 Netlink 기능이 필요한 컨테이너는 호스트 네트워크 및 IPC 네임스페이스에 있어야 합니다.
--network=host --ipc=host
시스템 재부팅 시 컨테이너를 자동으로 시작합니다.
--restart=always
Netlink 및 PacketIO 라이브러리에 필요한 net admin 기능을 활성화합니다.
--cap-add=NET_ADMIN
WAN/데이터 포트를 통한 Netlink 및 PacketIO에 필요한 환경 변수를 활성화합니다.
--env-file=/run/docker/jnet.env
PacketIO를 지원하기 위해 호스트에서 컨테이너로 jtd0 디바이스를 마운트합니다.
--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 릴리스 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 OSglibc와 호환되는 을 glibc 사용해야 합니다.
Docker 컨테이너용 VRF 선택
Junos OS 진화한 릴리스 23.4R1 및 이전 버전의 경우, 컨테이너는 Docker 프로세스에서 가상 라우팅 및 포워딩(VRF)을 상속합니다. 개별 VRF에서 컨테이너를 실행하려면 해당 VRF에서 Docker 프로세스 인스턴스를 시작해야 합니다. docker@vrf.service 인스턴스를 통해 해당 VRF에서 프로세스를 시작할 수 있습니다. VRF가 지정되지 않은 경우 VRF의 기본값은 입니다 vrf0.
기본적으로 docker.service 실행됩니다 vrf:none .
Junos OS 진화한 릴리스 24.1R1 이상에서는 명령을 사용하여 ip vrf exec task 컨테이너 내의 특정 작업을 특정 Linux VRF에 바인딩하는 것이 좋습니다. 이렇게 하려면 컨테이너를 옵션 --privileged으로 시작해야 하며, 컨테이너에는 호환되는 버전의 이 iproute2 설치되어 있어야 합니다. 또한 컨테이너는 호스트와 네트워크 네임스페이스를 공유해야 합니다. 또한 socket 옵션을 SO_BINDTODEVICE 사용하여 컨테이너 내의 특정 작업 또는 애플리케이션에 대한 소켓을 특정 Linux VRF 디바이스에 바인딩할 수 있습니다. 이 경우 iproute2 필요하지 않습니다.
명령은 ip vrf show 사용 가능한 모든 Linux VRF를 나열합니다. 를 사용하여 iproute2컨테이너 내의 작업에 대한 소켓을 VRF에 바인딩하도록 선택한 경우 을 사용하여 --env-file=/run/docker-vrf0/jnet.env일부 env 변수를 덮어쓰는 것이 좋으므로 libnli.so 를 방해 iproute2하지 않도록 미리 로드되지 않습니다.
다음 명령을 사용하여 컨테이너를 시작하고 컨테이너의 작업과 연결된 소켓을 기본 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
이 접근 방식을 사용하면 컨테이너 내의 다른 작업과 연결된 다른 소켓을 하나의 VRF에 바인딩된 모든 소켓 대신 다른 VRF와 연결할 수 있습니다.
특정 VRF에 대한 Docker 프로세스는 /run/docker-vrf.sock에 있는 해당 소켓에서 수신 대기합니다.
이는 Junos OS Evolved VRF가 아닌 Linux에서 볼 수 있는 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
컨테이너는 단일 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 dockerDocker 프로세스를 중지해야 하며 명령 다음에 명령을 사용하여 기존 파티션을systemctl stop var-extensions.mountrm /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=중 하나를 수정하는 경우 및 둘 다 설정해야 합니다. 스왑에 권장되는 값은 의 15%입니다EXTENSION_MEMORY_MAX_MIB=. swapEXTENSION_MEMORY_MAX_MIB의 실제cgroup값은 +EXTENSIONS_MEMORY_SWAP_MAX_MIB입니다.
기본적으로 이러한 값은 플랫폼별 값으로 설정되므로 컨테이너를 시작하기 전에 값을 설정하는 것이 좋습니다.
컨테이너에 대한 리소스 제한을 수정하기 전에 구성에서 지원해야 하는 규모에 대한 CPU 및 메모리 요구 사항을 알고 있어야 합니다. 컨테이너에 대한 리소스 제한을 늘릴 때는 시스템에 부담을 주지 않도록 주의해야 합니다.