RouterOS Containers: Docker no MikroTik

Resumo O MikroTik RouterOS v7 pode rodar containers compatíveis com Docker diretamente no roteador, de modo que filtragem de DNS, agentes de monitoramento e pequenos serviços de rede ficam ao lado do plano de roteamento, em vez de em uma máquina separada. Este guia cobre os requisitos de hardware e arquitetura, como ativar o device-mode de container com segurança, montar a rede veth e bridge com NAT, implantar seu primeiro container e gerenciar containers em uma frota. O RouterOS 7.23 (maio de 2026) ampliou o catálogo de apps de container prontos para uso, tornando isso uma opção prática tanto para provedores quanto para quem monta laboratórios.

O Que São Containers no MikroTik RouterOS?

Containers no MikroTik RouterOS são a implementação de containers Linux da MikroTik, que permite que um dispositivo RouterOS v7 rode imagens de aplicação isoladas e compatíveis com Docker diretamente no roteador. Eles funcionam com imagens do Docker Hub, GCR, Quay e outros registries e, embora o RouterOS use sua própria sintaxe de CLI em vez do comando docker, o comportamento de fundo é o mesmo — baixar uma imagem, dar a ela uma rede, montar armazenamento e executá-la. (Documentação da MikroTik)

Para um provedor ou um laboratório, isso significa que pequenos serviços próximos à rede podem ser colocados junto ao plano de roteamento: um filtro de DNS Pi-hole ou AdGuard, um agente de monitoramento, um proxy reverso ou uma ponte de IoT. A versão estável RouterOS 7.23, de 25 de maio de 2026, adicionou uma longa lista de apps prontos para uso — incluindo paperless-ngx, nextcloud, lorawan-stack, birdnet-go e front-ends de gerenciamento Docker como portainer e dockge — junto com um novo switch network-outgoing-access para impedir que um container inicie tráfego de saída. (Changelog do RouterOS 7.23)

Requisitos e Hardware

O pacote container é compatível com as arquiteturas arm, arm64 e x86, e precisa ser instalado antes de qualquer outra coisa. Baixar uma imagem remota exige bastante espaço livre, por isso a MikroTik recomenda armazenamento externo em vez do flash interno do dispositivo. (Documentação da MikroTik)

Planeje mídia externa em USB, SATA ou NVMe, formatada com um sistema de arquivos suportado pelo RouterOS. A MikroTik sugere um disco capaz de pelo menos 100 MB/s de throughput sequencial e 10K IOPS aleatórios — discos mais lentos tornam a extração da imagem dolorosamente longa. Evite colocar volumes de container no armazenamento interno, que é pequeno e se desgasta sob os padrões de escrita dos containers. Dispositivos com flash muito limitada devem usar imagens pré-construídas no disco conectado, em vez de baixar remotamente.

Ative o Device-Mode de Container com Segurança

Os containers vêm desativados por padrão e, por bons motivos, exigem acesso físico para serem ligados. Ative o recurso com:

/system/device-mode/update container=yes

O RouterOS então espera que você confirme com um toque no botão de reset ou um reinício a frio. Esse portão de confirmação física é um controle de segurança deliberado: uma vez que o modo container está ligado, containers podem ser adicionados, iniciados e removidos remotamente, e uma imagem maliciosa pode se tornar um ponto de apoio no roteador. A MikroTik é direta sobre isso — se seu dispositivo RouterOS for comprometido, os containers tornam trivial instalar software malicioso, e não há garantia de segurança para imagens de terceiros.

Trate o roteador que hospeda containers como exatamente tão seguro quanto a imagem menos confiável que você roda nele. Implante apenas imagens em que você confia, mantenha o dispositivo protegido por firewall e revise nosso guia de operações de segurança do device-mode antes de ativar isso em produção.

Monte a Rede do Container

Os containers precisam de uma interface virtual, uma bridge e NAT para alcançar a internet. O padrão abaixo espelha a rede “bridge” do Docker. Primeiro, crie uma interface veth e uma bridge que compartilhe seu endereço de gateway:

/interface/veth/add name=veth1 address=172.17.0.2/24 gateway=172.17.0.1
/interface/bridge/add name=containers
/ip/address/add address=172.17.0.1/24 interface=containers
/interface/bridge/port add bridge=containers interface=veth1

Uma veth pode servir muitos containers, e criar pares veth/bridge adicionais permite isolar grupos de containers entre si. Se você é novo no bridging do RouterOS, nosso tutorial de configuração de bridge explica o modelo subjacente. Em seguida, adicione uma regra de masquerade para que o tráfego de saída do container seja traduzido — veja o guia de configuração de NAT para o quadro completo:

/ip/firewall/nat/add chain=srcnat action=masquerade src-address=172.17.0.0/24

Implante Seu Primeiro Container

Aponte o registry e o diretório temporário de extração ao seu disco externo e, então, adicione a imagem. O exemplo do Pi-hole abaixo é o canônico da documentação da MikroTik:

/container/config/set registry-url=https://registry-1.docker.io tmpdir=disk1/tmp
/container/add remote-image=pihole/pihole interface=veth1 root-dir=disk1/images/pihole name=pihole logging=yes

Adicionar o container inicia o download e a extração, mas não o executa. Verifique o progresso com /container/print e espere até status=stopped, depois inicie-o:

/container/start pihole

Por fim, publique o serviço encaminhando uma porta do roteador para o endereço veth:

/ip firewall nat add action=dst-nat chain=dstnat dst-address=192.168.88.1 dst-port=80 protocol=tcp to-addresses=172.17.0.2 to-ports=80

O Pi-hole agora responde no IP da LAN do roteador. Rodar a filtragem de DNS desta forma é uma alternativa às blocklists nativas do RouterOS — se você prefere o caminho sem container, veja nosso tutorial de adlist do RouterOS.

Gerencie Containers em uma Frota

Um único container em um roteador é fácil. A verdadeira questão operacional para um provedor é consistência: a mesma imagem, o mesmo esquema de veth e NAT, o mesmo layout de armazenamento e os mesmos limites de start-on-boot e de memória em todos os dispositivos. O RouterOS oferece as primitivas — start-on-boot=yes sobrevive a reinícios, e memory-high ou memory-max limitam a RAM por container, para que um serviço descontrolado não consuma todo o plano de roteamento:

/container/config/set memory-high=200M
/container/set pihole start-on-boot=yes

A parte difícil é fazer isso de forma idêntica em dezenas ou centenas de roteadores remotos e, depois, provar que cada um realmente voltou após um reinício — especialmente quando o dispositivo fica atrás de CGNAT e você não pode simplesmente alcançar seu IP público.

Dicas

• Mantenha todo volume de container no disco externo; nunca na NAND interna.
• Use um par veth/bridge separado para isolar containers não confiáveis dos confiáveis.
• Defina memory-max em tudo em que você não confia plenamente, para manter o roteador responsivo.
• Para um ambiente de teste limpo antes de mexer na produção, rode as mesmas imagens em uma instância CHR virtualizada antes de implantar em roteadores físicos.

Dê o Próximo Passo

Containers transformam um roteador MikroTik em um pequeno host de aplicações, mas uma frota desses hosts precisa de orquestração. O MKController modela a configuração do RouterOS de forma central, aplica-a a todos os dispositivos do seu inventário e rastreia desvios, para que você veja qual roteador divergiu — e, através do NATCloud, alcança dispositivos atrás de CGNAT para confirmar que um container reiniciou após a manutenção. Isso fecha a lacuna entre configurar um container à mão e operá-los de forma confiável em toda uma rede de provedor.

Comece seu teste gratuito do MKController