RouterOS Containers : Docker sur MikroTik

Résumé MikroTik RouterOS v7 peut exécuter des container compatibles Docker directement sur le routeur, de sorte que le filtrage DNS, les agents de surveillance et les petits services réseau vivent à côté du plan de routage plutôt que sur une machine séparée. Ce guide couvre les exigences matérielles et d’architecture, l’activation sécurisée du device-mode container, la construction du réseau veth et bridge avec NAT, le déploiement de votre premier container et la gestion de container sur toute une flotte. RouterOS 7.23 (mai 2026) a élargi le catalogue d’applications container prêtes à l’emploi, en faisant une option pratique aussi bien pour les FAI que pour les bricoleurs de labo.

Que Sont les Containers sur MikroTik RouterOS ?

Les containers sur MikroTik RouterOS sont l’implémentation par MikroTik des conteneurs Linux, qui permet à un appareil RouterOS v7 d’exécuter des images d’application isolées et compatibles Docker directement sur le routeur. Ils fonctionnent avec des images de Docker Hub, GCR, Quay et d’autres registres et, bien que RouterOS utilise sa propre syntaxe CLI au lieu de la commande docker, le comportement sous-jacent est le même : tirer une image, lui donner un réseau, monter du stockage et l’exécuter. (Documentation MikroTik)

Pour un FAI ou un labo, cela signifie que de petits services proches du réseau peuvent être co-localisés avec le plan de routage : un filtre DNS Pi-hole ou AdGuard, un agent de surveillance, un reverse proxy ou un pont IoT. La version stable RouterOS 7.23 du 25 mai 2026 a ajouté une longue liste d’applications prêtes à l’emploi — dont paperless-ngx, nextcloud, lorawan-stack, birdnet-go et des front-ends de gestion Docker comme portainer et dockge — ainsi qu’un nouveau commutateur network-outgoing-access pour empêcher un container d’initier du trafic sortant. (Changelog RouterOS 7.23)

Prérequis et Matériel

Le paquet container est compatible avec les architectures arm, arm64 et x86, et il doit être installé avant toute autre chose. Tirer une image distante nécessite beaucoup d’espace libre, c’est pourquoi MikroTik recommande un stockage externe plutôt que le flash interne de l’appareil. (Documentation MikroTik)

Prévoyez un support externe sur USB, SATA ou NVMe, formaté avec un système de fichiers pris en charge par RouterOS. MikroTik suggère un disque capable d’au moins 100 Mo/s de débit séquentiel et 10K IOPS aléatoires — des disques plus lents rendent l’extraction de l’image péniblement longue. Évitez de placer les volumes container sur le stockage interne, qui est petit et s’use sous les schémas d’écriture des container. Les appareils au flash très limité devraient utiliser des images préconstruites sur le disque connecté plutôt que de les tirer à distance.

Activez le Device-Mode Container en Toute Sécurité

Les container sont désactivés par défaut et, pour de bonnes raisons, exigent un accès physique pour être activés. Activez la fonction avec :

/system/device-mode/update container=yes

RouterOS attend alors que vous confirmiez par un appui sur le bouton reset ou un redémarrage à froid. Cette barrière de confirmation physique est un contrôle de sécurité délibéré : une fois le mode container activé, des container peuvent être ajoutés, démarrés et supprimés à distance, et une image malveillante peut devenir un point d’ancrage sur le routeur. MikroTik est clair à ce sujet : si votre appareil RouterOS est compromis, les container rendent l’installation de logiciels malveillants triviale, et il n’y a aucune garantie de sécurité pour les images tierces.

Considérez le routeur qui héberge des container comme exactement aussi sécurisé que l’image la moins fiable que vous y exécutez. Ne déployez que des images de confiance, gardez l’appareil derrière un pare-feu et consultez notre guide des opérations de sécurité du device-mode avant d’activer ceci en production.

Construisez le Réseau du Container

Les container ont besoin d’une interface virtuelle, d’un bridge et de NAT pour atteindre internet. Le schéma ci-dessous reflète le réseau « bridge » de Docker. Créez d’abord une interface veth et un bridge qui partage son adresse de passerelle :

/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

Un veth peut servir de nombreux container, et créer des paires veth/bridge supplémentaires permet d’isoler des groupes de container les uns des autres. Si vous débutez avec le bridging RouterOS, notre tutoriel de configuration de bridge explique le modèle sous-jacent. Ajoutez ensuite une règle masquerade pour que le trafic sortant du container soit traduit — voir le guide de configuration NAT pour le tableau complet :

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

Déployez Votre Premier Container

Pointez le registry et le répertoire temporaire d’extraction vers votre disque externe, puis ajoutez l’image. L’exemple Pi-hole ci-dessous est celui de référence de la documentation 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

Ajouter le container lance le téléchargement et l’extraction, mais ne l’exécute pas. Vérifiez la progression avec /container/print et attendez status=stopped, puis démarrez-le :

/container/start pihole

Enfin, publiez le service en transférant un port du routeur vers l’adresse 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

Pi-hole répond désormais sur l’IP LAN du routeur. Exécuter le filtrage DNS de cette façon est une alternative aux blocklists natives de RouterOS — si vous préférez la voie sans container, consultez notre tutoriel adlist RouterOS.

Gérez des Container sur Toute une Flotte

Un seul container sur un routeur, c’est facile. La vraie question opérationnelle pour un FAI est la cohérence : la même image, le même schéma veth et NAT, la même disposition de stockage et les mêmes limites start-on-boot et de mémoire sur chaque appareil. RouterOS vous donne les primitives — start-on-boot=yes survit aux redémarrages, et memory-high ou memory-max plafonnent la RAM par container pour qu’un service emballé n’affame pas le plan de routage :

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

Le plus difficile est de faire cela à l’identique sur des dizaines ou des centaines de routeurs distants, puis de prouver que chacun est bel et bien revenu après un redémarrage — surtout quand l’appareil se trouve derrière le CGNAT et que vous ne pouvez pas simplement atteindre son IP publique.

Conseils

• Gardez chaque volume container sur le disque externe ; jamais sur la NAND interne.
• Utilisez une paire veth/bridge séparée pour isoler les container non fiables des fiables.
• Définissez memory-max sur tout ce dont vous ne vous fiez pas pleinement afin de garder le routeur réactif.
• Pour un banc d’essai propre avant de toucher à la production, exécutez les mêmes images sur une instance CHR virtualisée avant de les déployer sur des routeurs physiques.

Passez à l’Étape Suivante

Les container transforment un routeur MikroTik en un minuscule hôte d’applications, mais une flotte de ces hôtes a besoin d’orchestration. MKController modélise la configuration RouterOS de manière centralisée, l’applique à chaque appareil de votre inventaire et suit la dérive pour que vous voyiez quel routeur a divergé — et via NATCloud, il atteint les appareils derrière le CGNAT pour confirmer qu’un container a redémarré après la maintenance. Cela comble l’écart entre configurer un container à la main et les exploiter de façon fiable sur tout un réseau de FAI.

Démarrez votre essai gratuit MKController