Métodos de instalación

Todos los métodos crean los mismos objetos en el router: la veth, la dirección del router, las pertenencias a listas que conserves, la envlist, el contenedor y el manifiesto de la instalación, todos con la misma etiqueta. Así que mikroscope status y uninstall reconocen una instalación la haya hecho el método que sea. Se diferencian en dónde se ejecutan y en cómo llega la imagen del agente al router. Todos necesitan antes los Requisitos, device mode incluido.

Comparar métodos

Método	Necesita	Úsalo cuando
Descarga del registro con la CLI	ssh al router; que el router llegue a Docker Hub o a GHCR	por defecto: una orden, sin subir nada
Instalación sin conexión	ssh y `scp`; el tar de la imagen para la arquitectura del router	el router no llega a ningún registro
Desde el código fuente	Go 1.27 y una copia del repositorio; ssh y `scp`	estás cambiando el agente y lo quieres desde tu árbol
Script de RouterOS	la CLI en cualquier ordenador; un terminal en el router	llegas al router por Winbox o WebFig, no por ssh
Generador de scripts	un navegador; un terminal en el router	no tienes la CLI
Instalación manual: terminal	un terminal en el router	quieres escribir o adaptar cada orden
Instalación manual: WebFig y Winbox	WebFig o Winbox	prefieres los menús a las órdenes

Usa la descarga del registro salvo que algo te lo impida. Es una orden sin nada que elegir ni nada que ajustar en el router: el índice de la imagen publicada lleva todas las plataformas que puede ser un contenedor de MikroTik, así que el router elige la suya. No queda ningún tar en la flash.

El tar de la imagen es la única ruta en la que tú eliges la arquitectura, y una elección equivocada se instala, arranca y muere con exec format error en el registro del contenedor. Instalación sin conexión tiene la tabla.

Descarga del registro

mikroscope install --router admin@192.168.88.1 --remote-image jmrplens/mikroscope-agent:1.6.1

El paso del contenedor pasa a ser /container/add remote-image="registry-1.docker.io/jmrplens/mikroscope-agent:1.6.1" …, y el plan imprime the router pulls registry-1.docker.io/jmrplens/mikroscope-agent:1.6.1 (nothing is uploaded) donde iría una subida. Cada versión publica la imagen dos veces, como jmrplens/mikroscope-agent:1.6.1 en Docker Hub y como ghcr.io/jmrplens/mikroscope-agent:1.6.1 en GHCR. Las dos llevan linux/amd64, linux/arm64, linux/arm/v7 y linux/arm/v5, y RouterOS elige la que necesita su arquitectura.

Esta ruta necesita dos cosas que las demás no: que el router llegue al registro, y RAM libre para las capas mientras las extrae. doctor avisa cuando la memoria libre no llega a --memory-max más 16 MiB.

--remote-image toma su valor por defecto de MIKROSCOPE_REMOTE_IMAGE. upgrade también la acepta, y toma la imagen solo de sus propias opciones, así que vuelve a pasarla con la versión nueva. image la rechaza, porque no hay tar que escribir.

Ajustes del registro

mikroscope le pasa a RouterOS la referencia entera, con el equipo del registro incluido. Una referencia sin equipo, o que empieza por docker.io/, index.docker.io/ o registry.hub.docker.com/, sale como registry-1.docker.io/jmrplens/mikroscope-agent:1.6.1, el equipo en el que responde el registro de Docker Hub; cualquier otro equipo se deja como está. RouterOS 7.18 y posteriores aceptan ahí un equipo de registro (registro de cambios de la 7.18: «container - allow specifying registry using remote-image property»), y mikroscope necesita la 7.24.

Así que no ajustas nada en el router:

/container/config registry-url, un único valor para todo el equipo, no decide esta descarga. install, upgrade y el script de RouterOS nunca lo escriben (verificado).
No hace falta iniciar sesión en ningún registro: la imagen publicada es pública en los dos (probado).
doctor, y upgrade antes de retirar nada, leen registry-url y si hay un usuario fijado, para un único aviso.

Para descargar a través de un espejo o de una caché de descargas, nombra su equipo en la referencia: --remote-image <mirror-host>/jmrplens/mikroscope-agent:1.6.1. mikroscope la envía tal cual, y upgrade imprime una note cuando registry-url nombra un equipo distinto del de la descarga.

Docker Hub permite a un cliente anónimo 100 descargas cada 6 horas por dirección IPv4 o /64 de IPv6 (límites de descarga de Docker Hub). Docker cuenta una imagen multiarquitectura como una descarga por arquitectura descargada, y un router solo descarga la suya. El límite es por dirección pública, así que los routers detrás de un mismo NAT lo comparten, algo que importa cuando una flota se instala a la vez.

Un script de RouterOS con la misma instalación, para un router al que llegas sin ssh, está en Script de RouterOS.

Desde el código fuente

git clone https://github.com/jmrplens/mikroscope
cd mikroscope
make build
bin/mikroscope install --router admin@192.168.88.1

plan, install, upgrade e image compilan el agente por su cuenta cuando no reciben ni --remote-image ni --agent-tar: go build ./cmd/mikroscope-agent para linux/<arch> con CGO_ENABLED=0, empaquetado en un tar de imagen sin Docker. install y upgrade compilan para la arquitectura que leen del router; plan e image no se conectan a nada y compilan arm64 salvo que --arch diga otra cosa. La ruta de compilación es relativa, así que ejecuta la CLI desde la copia del repositorio. Es la única ruta que instala un agente compilado desde tu propio árbol.

make build deja la CLI en bin/mikroscope. Sin Go en el PATH, el verbo se detiene antes de escribir nada y nombra las otras dos rutas y la versión de Go que necesita.

El tar de imagen publicado, cuál usa cada placa y cómo verificar la descarga están en Instalación sin conexión.

Escrito y mantenido por José Manuel Requena Plens (jmrplens)jmrp.ioGitHub