Executando aplicativos de terceiros em contêineres
Para executar seus próprios aplicativos no Junos OS Evolved, você tem a opção de implantá-los dentro de um contêiner Docker. O contêiner é executado no Junos OS Evolved, e os agentes funcionam dentro do contêiner, mantendo-os isolados do OS. Os contêineres são instalados em uma partição separada montada em /var/extensões.
Os contêineres Docker não são integrados ao Junos OS Evolved, eles são criados e gerenciados inteiramente através do Linux usando comandos Docker. Para obter mais informações sobre contêineres e comandos Docker, veja a documentação oficial do Docker: https://docs.docker.com/get-started/
Os contêineres têm limites padrão para os recursos que podem usar do sistema:
Storage – O tamanho da partição /var/extensões é orientado por plataforma: 8GB ou 30% do tamanho total de /var, o que for menor.
Memory – Os contêineres têm um limite padrão de 2GB ou 10% da memória física total, o que for menor.
CPU – Os contêineres têm um limite padrão de uso máximo de CPU de 20% em todos os núcleos.
Você pode modificar os limites de recursos em contêineres, se necessário. Veja modificação dos limites de recursos para contêineres.
Implantação de um contêiner Docker
Para implantar um contêiner docker:
Gerenciamento de um contêiner Docker
Os contêineres Docker são gerenciados por meio do fluxo de trabalho do Linux. Use os ps comandos ou top Linux para mostrar quais contêineres Docker estão sendo executados e use comandos Docker para gerenciar os contêineres. Para obter mais informações sobre os comandos Docker, veja: https://docs.docker.com/engine/reference/commandline/cli/
Os recursos de alta disponibilidade do Junos OS Evolved não são suportados para aplicativos personalizados em contêineres Docker, se um aplicativo tem funcionalidade de alta disponibilidade, então você deve executar o aplicativo em cada RE para garantir que ele possa se sincronizar.
Habilitando o Netlink ou a IO de pacotes em um contêiner
Você precisa fornecer argumentos adicionais aos comandos Docker se o seu contêiner exigir recursos extras como Netlink ou Packet IO. O exemplo a seguir mostra como ativar recursos de Netlink ou Packet IO para um contêiner adicionando argumentos a um comando Docker:
Crie um volume persistente de nome somente para leitura ao iniciar serviços Docker:
--mount source=jnet,destination=/usr/evo
Compartilhe o namespace da rede do host com o processo de contêiner:
--network=host
Inicie automaticamente o contêiner após a reinicialização do sistema:
--restart=always
Habilite o recurso de administração líquida, que é exigido pelas bibliotecas Netlink e Packet IO:
--cap-add=NET_ADMIN
Habilite as variáveis ambientais necessárias para o Netlink e o Packet IO:
--env-file=/run/docker/jnet.env
Selecionando um VRF para um contêiner Docker
Os contêineres herdam o roteamento e o encaminhamento virtual (VRF) do daemon Docker. Para executar contêineres em um VRF distinto, uma instância daemon Docker precisa ser iniciada no VRF correspondente. A docker@vrf.service instância permite iniciar um daemon no VRF correspondente. Se o VRF não estiver especificado, o VRF fica inadimplente em vrf0.
A docker.service rede funciona vrf:none por padrão.
O daemon docker para um VRF específico ouve no socket correspondente localizado em /run/docker-vrf.sock.
O cliente Docker é associado ao daemon docker específico vrF usando os seguintes argumentos:
--env-file /run/docker-vrf/jnet.env --host unix:///run/docker-vrf.sock or export DOCKER_HOST=unix:///run/docker-vrf.sock
Por exemplo, para executar um contêiner vrf0 , insira os seguintes argumentos e comandos Docker:
[vrf:none] user@host:~#docker -H unix:///run/docker-vrf0.sock run --rm -it --network=host --cap-add=NET_ADMIN --mount source=jnet,destination=/usr/evo --env-file=/run/docker-vrf0/jnet.env 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
Um contêiner só pode ser associado a um único VRF.
Modificação dos limites de recursos para contêineres
Os limites padrão de recursos para contêineres são controlados por um arquivo localizado em /etc/extensões/platform_attributes. Você verá o texto a seguir ao abrir este arquivo:
## 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=
Para alterar os limites de recursos para contêineres, adicione valores às EXTENSIONS entradas na parte inferior do arquivo:
EXTENSIONS_FS_DEVICE_SIZE_MIB=controla o espaço máximo de armazenamento que os contêineres podem usar. Digite o valor em bytes. O valor padrão é de 8GB ou 30% do tamanho total de /var, o que for menor.EXTENSIONS_CPU_QUOTA_PERCENTAGE=controla o uso máximo de CPU que os contêineres podem usar. Digite um valor como porcentagem do uso da CPU. O valor padrão é o uso máximo de CPU de 20% em todos os núcleosEXTENSIONS_MEMORY_MAX_MIB=controla a quantidade máxima de memória física que os contêineres podem usar. Digite o valor em bytes. O valor padrão é de 2GB ou 10% da memória física total, o que for menor.
Antes de modificar os limites de recursos para contêineres, esteja ciente dos requisitos de CPU e memória para a escala que você tem a oferecer em sua configuração. Tenha cuidado ao aumentar os limites de recursos para contêineres para evitar que eles causem uma tensão em seu sistema.