# Métodos de instalación

Las formas de poner el agente de mikroscope en un router MikroTik — la CLI con una descarga del registro, el tar de la imagen o una copia del código, un script de RouterOS, el generador o a mano — y lo que necesita cada una.

Source: https://docs.jmrp.io/mikroscope/es/install/routes/

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](https://docs.jmrp.io/mikroscope/es/install/prerequisites/), device mode incluido.

## Comparar métodos

| Método                                                                         | Necesita                                                             | Úsalo cuando                                                   |
| ------------------------------------------------------------------------------ | -------------------------------------------------------------------- | -------------------------------------------------------------- |
| **[Descarga del registro](https://docs.jmrp.io/mikroscope/es/install/routes/#un-pull-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](https://docs.jmrp.io/mikroscope/es/install/offline/)                    | 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](https://docs.jmrp.io/mikroscope/es/install/routes/#un-checkout-con-go)                                  | 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](https://docs.jmrp.io/mikroscope/es/install/script/)                           | la CLI en cualquier ordenador; un terminal en el router              | llegas al router por Winbox o WebFig, no por ssh               |
| [Generador de scripts](https://docs.jmrp.io/mikroscope/es/install/generator/)                      | un navegador; un terminal en el router                               | no tienes la CLI                                               |
| [Instalación manual: terminal](https://docs.jmrp.io/mikroscope/es/install/manual-cli/)             | un terminal en el router                                             | quieres escribir o adaptar cada orden                          |
| [Instalación manual: WebFig y Winbox](https://docs.jmrp.io/mikroscope/es/install/manual-gui/)      | 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](https://docs.jmrp.io/mikroscope/es/install/offline/) tiene la tabla.

## Descarga del registro

```sh
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](https://download.mikrotik.com/routeros/7.18/CHANGELOG):
«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](https://docs.jmrp.io/mikroscope/es/about/status/#verified-remote-image-host)).
- No hace falta iniciar sesión en ningún registro: la imagen publicada es pública en los dos
  ([probado](https://docs.jmrp.io/mikroscope/es/about/status/#install-routes-tested)).
- `doctor`, y `upgrade` antes de retirar nada, leen `registry-url` y si hay un usuario fijado, para
  un único aviso.

> **Un único usuario de registro para todo el equipo**
>
> `/container/config` guarda un único usuario y contraseña de registro para todos los contenedores
> del router, y un inicio de sesión pensado para un registro y enviado a otro puede terminar la
> descarga de una imagen pública en `auth error`. `doctor` avisa, como
> `WARN no registry credential meant for another registry`, cuando hay un usuario fijado y el equipo
> que nombra `registry-url` no es del que se descarga la imagen.
> [Solución de problemas](https://docs.jmrp.io/mikroscope/es/reference/troubleshooting/#una-credencial-para-todos-los-registros)
> tiene las tres salidas.

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](https://docs.docker.com/docker-hub/usage/pulls/)). 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](https://docs.jmrp.io/mikroscope/es/install/script/).

## Desde el código fuente

```sh
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](https://docs.jmrp.io/mikroscope/es/install/offline/).

## Véase también

- [Requisitos](https://docs.jmrp.io/mikroscope/es/install/prerequisites/): lo que necesita en el router cada método.
- [Instalar con la CLI](https://docs.jmrp.io/mikroscope/es/install/): lo que hace `install` una vez decidido de dónde
  sale la imagen.
- [Actualizar y desinstalar](https://docs.jmrp.io/mikroscope/es/install/upgrade/): actualizar y retirar una instalación,
  hecha con cualquier método.
- [Almacenamiento y ajustes del contenedor](https://docs.jmrp.io/mikroscope/es/install/layout/): el disco que usan el tar y la raíz.