Cuatro formas de instalar
El agente es una imagen de contenedor, y las cuatro rutas de abajo se
diferencian en una sola cosa: cómo llega esa imagen al router. Todo lo demás
que escribe install —la veth, la dirección, las dos pertenencias a listas, la
envlist, el contenedor y su etiqueta— es igual tomes la ruta que tomes, y
también lo son los requisitos previos:
Lo que necesita el router va primero en
las cuatro, porque device-mode container=yes exige una mano en el equipo y
ninguna ruta lo esquiva.
Cuál elegir
Sección titulada «Cuál elegir»| Ruta | Necesita | Prefiérela cuando |
|---|---|---|
| Un pull del registro — empieza por aquí | que el router llegue a Docker Hub; nada más | casi siempre: una orden, nada que elegir, nada que subir |
| Un script de RouterOS | una terminal en el router; --remote-image |
llegas al router por WinBox o WebFig y no por ssh |
| Un checkout, con Go | Go 1.27 y el repositorio; ssh al router | trabajas en mikroscope y quieres el agente de tu propio árbol |
| El tar publicado | los artefactos de la release, el correcto para la placa; ssh al router | el router no llega a ningún registro |
Desliza en horizontal para ver todas las columnas
Toma la primera salvo que algo te lo impida. Un pull del registro es una
sola orden sin nada que elegir: el índice de imágenes publicado lleva todas las
plataformas que puede ser un contenedor de MikroTik, así que el router
reconoce la suya y nadie tiene que saber si la placa es ARM de 64 bits o una de
las dos clases de 32 bits. Nada aterriza en la flash, y uninstall no tiene
ningún fichero del que dar cuenta.
El tar va el último a propósito. Es la ruta correcta para un router sin salida
a un registro, y es la única en la que tú eliges la arquitectura —y la
forma en que eso sale mal es una imagen que se instala, arranca y muere con
exec format error en el registro del contenedor—. Si la tomas, lee
qué tar antes de descargar nada.
Un pull del registro
Sección titulada «Un pull del registro»La ruta recomendada, y la más corta. Una orden, nada que descargar, nada que subir:
mikroscope install --router usuario@192.168.88.1 \ --remote-image jmrplens/mikroscope-agent:1.0.4No se sube nada, ningún tar aterriza en el equipo, y uninstall no tiene
ningún fichero del que dar cuenta: el paso del contenedor pasa a ser
/container/add remote-image="jmrplens/ y el plan
imprime the router pulls … (nothing is uploaded) donde iría la línea de
subida. La release publica la imagen dos veces, como
jmrplens/ en Docker Hub y como
ghcr. en GHCR. Las dos llevan linux/amd64,
linux/arm64, linux/arm/v7 y linux/arm/v5, y RouterOS toma la que necesita
su arquitectura —que es la razón de que esta ruta no pregunte nada sobre la
placa: las dos clases de ARM de 32 bits que vende MikroTik están en el índice.
La referencia de arriba es la de Docker Hub, y no lleva host de registro: el
router se la descarga del que ya nombre /, y
RouterOS trae ese ajuste puesto en https:/. En un router
donde nadie lo haya tocado, la orden de arriba no necesita fijar nada antes —en
la RB5009 sobre la que se mide este proyecto, ese ajuste vale
https:/—. La referencia de GHCR es la alternativa, y
necesita antes / en el
equipo, que es un cambio para todos sus contenedores.
Necesita dos cosas que las otras rutas no: que el router llegue al registro, y que tenga sitio en RAM para las capas mientras las extrae.
Una referencia sin host —jmrplens/— deja el registro a
lo que el router ya tenga configurado, y entonces doctor no comprueba nada al
respecto. --remote-image toma su valor por defecto de
MIKROSCOPE_REMOTE_IMAGE, y upgrade también lo acepta; image lo rechaza,
porque no hay ningún tar que escribir.
Un script de RouterOS
Sección titulada «Un script de RouterOS»Para un router al que llegas por WinBox o WebFig, o donde no quieres ssh desde otra máquina en absoluto:
mikroscope plan --rsc \ --remote-image jmrplens/mikroscope-agent:1.0.4 \ --out install.rscEl fichero lleva las mismas órdenes que ejecuta install, en el mismo orden y
con cada objeto etiquetado igual, así que status y uninstall desde la CLI
los reconocen después. Léelo, y luego pégalo en la terminal del router, o súbelo
y hazle /import. Sin --out sale por la salida estándar. Lleva su propia
cabecera: la etiqueta que escribe, qué comprobar antes de ejecutarlo y, al
final, /container/print where name~"mikroscope" y la URL /healthz en la que
responde el agente.
Dos advertencias, ambas escritas en el propio script:
- No puede subir nada. Un script que se ejecuta en el router no tiene forma
de poner la imagen ahí, así que acompáñalo de
--remote-image. Sin él, la cabecera dice en su lugar qué nombre de fichero hay que dejar antes en el equipo —el nombre que espera el paso del contenedor— y cómo regenerar el script para un pull del registro. - Con
--token, el fichero es una credencial. La línea de la envlist lleva el token en claro, porque el router lo necesita en claro. La CLI escribe el fichero con permisos0600; lo que hagas con él después es la exposición.
Nada dentro del script comprueba nada. No hay doctor, ni pregunta sobre con
qué chocarían los objetos que crea, ni confirmación: escribe. Ejecuta
mikroscope doctor desde una máquina que pueda, o lee
Lo que necesita el router y comprueba
a mano los tres requisitos, antes de pegarlo.
Las cuatro rutas se ejecutaron de extremo a extremo contra el RB5009UG+S+ de
referencia (RouterOS 7.24.2, arm64) el 2026-09-17, una tras otra, cada una
instalando bajo su propio nombre, veth y /30 para no tocar nada de lo que ya
había en el equipo, y cada una retirada antes de la siguiente. En todas ellas
el agente respondió a /healthz desde el equipo del colector: la compilación
desde el checkout y el mikroscope-agent-arm64. publicado con 2 ms de ida y
vuelta, la descarga que el propio router hizo de
jmrplens/ desde Docker Hub con 2 ms, y el script de
plan --rsc — subido e importado con /import, sin CLI ninguna en la
instalación misma — con 15 ms en sus primeras muestras. uninstall verificó
después por recuento de propiedad en cada caso, y el /export del router tras
las cuatro era idéntico byte a byte al tomado antes de ellas.