# Motivation

The [RouterOS `container.npk` feature](https://help.mikrotik.com/docs/display/ROS/Container) is highly useful, but compared to Docker Engine, it is very thinly featured. The purpose of this document isn't to denigrate the RouterOS or its developers but to provide a mapping between what people expect of a fully-featured container engine and what you get in RouterOS. Where it makes sense, I try to provide workarounds.

<font color=red>This document is a **Work in Progress**.</font>


# Top-Level Commands

For lack of any better organization principle, I've chosen to organize this document along the lines of the `docker` CLI structure, following the same command hierarchy, in alphabetical order at each level. I skip over short aliases like `docker rmi` for `docker image rm` to cover things only once.



## `attach`

There is no interactive terminal (stdin/stdout/stderr) in RouterOS to speak of. Containers normally run in the background, with logging suppressed by default. If you say `/container/set logging=yes`, the standard output streams go to the configured logging destination, but there is no way to interactively type commands at the container short of `/container/shell`, which requires that `/bin/sh` exist inside the container. Even then, you're typing commands at the shell, not at the container's `ENTRYPOINT` process.

In short, there is no equivalent in RouterOS to the common `docker run -it` invocation option.


## `commit`

RouterOS doesn't maintain an image cache, thus has no way to commit changes to an image layer to a new layer.

It is for this same reason that removing and reinstalling the container re-downloads the image, even when done back-to-back.


## `cp`

There is no direct equivalent of this command. The closest RouterOS comes is if you mount a volume, then use the regular `/file` facility to copy files in under that volume's mount point. You can't copy a file into the container proper, as you might when overwriting a stock config file.


## `create`/`load`

The RouterOS command `/container/add` provides a basic version of this, though with many limitations relative to a fully-featured container engine:

<font color=red>**TODO**</font>

RouterOS doesn't have separate top-level commands for creating a container from an OCI image registry versus loading it from a tarball. They're both `/container/add`, differing in whether you give the `remote-image` or `file` options, respectively.


## `diff`

With no local image cache, there can be no equivalent command.


## `events`

RouterOS doesn't support container events.


## `export`/`save`

There is no way to produce a tarball of a running container's filesystem or to save its state back to an OCI image tarball.

The [documented advice][imgtb] for getting such a tarball is to do this on the PC side via `docker` commands, then upload the tarball from the PC to the RouterOS device.

[imgtb]: https://help.mikrotik.com/docs/display/ROS/Container#Container-c)buildanimageonPC


## `history`

RouterOS doesn't keep this information.


## `import`

This is `/container/add file=oci-image.tar` in RouterOS.


## `inspect`

The closest approximation to this in RouterOS is 

    /container/print detail where …

You get only a few lines of information back from this, mainly what you gave it to create the container from the image. You will not get the pages of JSON data the Docker CLI gives.

A related limitation is that the configurable items are often global in RouterOS, set for all containers running on the box, not available to be set on a per-container basis. A good example of this is the memory limit, set via `/container/config/set ram-high=…`.

Atop this, there aren't even _global_ settings in RouterOS for:

*   FD limits
*   PID limits
*   maximum CPU usage
*   syscall restrictions
*   [capabilities][caps]
*   [rlimit]

…much less per-container settings as you get in Docker, Podman, LXC, etc.

[caps]:   https://www.man7.org/linux/man-pages/man7/capabilities.7.html
[rlimit]: https://www.man7.org/linux/man-pages/man2/getrlimit.2.html


## `kill`/`stop`

RouterOS doesn't make a distinction between "kill" and "stop". The `/container/stop` command behaves more like `docker kill` or `docker stop -t0` in that it doesn't try to bring the container down gracefully before giving up and killing it.


## `logs`

By default, RouterOS drops all logging output from a container. To see it, you must enable it on a per-container basis with the `/container/add logging=yes` option, then tell RouterOS where to send those logs via a `/system/logging add topics=container …` command.

Each message is handled in real time, not buffered as with Docker or Podman. Furthermore, RouterOS mixes logs from all sources for a given "topic" set, which in this context means that if you have multiple running containers on the device, their logs all go to the same place. Thus, if you were expecting to be able to set up memory logging for a container, log out of the router, then sometime later come back in and get a dump of everything that one particular container has logged since the last time you asked — as you can with the big-boy container engines — then you will be disappointed.


## `pause`/`unpause`

No such feature in RouterOS; a container is running or not.

If the container has a shell, you could try a command sequence like this to get the same effect:

    > /container/shell 0
    $ pkill -STOP 'name of process'


## `port`

RouterOS exposes all ports defined for a container in the `EXPOSE` directive in the `Dockerfile`. The only way to instantiate a container with fewer exposed ports is to rebuild it or override it with a different `EXPOSE` value.


## `rename`

RouterOS doesn't let you set the name on creation, much less rename it later. The closest you can come to this is to add a custom `comment`, which you can both set at "`add`" time and after creation.


## `restart`

RouterOS doesn't provide this shortcut. You must stop it and then start it again manually.


## `rm`

RouterOS spells this `/container/remove`, but do be aware, there is no equivalent for `docker rm -f` to force the removal of a running container. RouterOS makes you stop it first.


## `start`

RouterOS has `/container/start`, but with many limitations relative to `docker start`:

<font color=red>**TODO**</font>


## `stats`/`top`

The closest thing in RouterOS is the `/container/print follow*` commands.

A more direct alternative would be to shell into the container and run whatever it has for a `top` command, but of course that is contingent on what is available, if indeed there is a shell at all.


## `tag`

RouterOS does nothing more with tags than to select which image to download from a registry. Without a local image cache, you cannot re-tag an image.


## `update`

No equivalent short of this:

    /container/stop 0
    …wait for it to stop…
    /container/remove 0
    /container/add …

The last step is the tricky one since `/container/print` shows most but not all of the options you gave to create it. If you didn't write down how you did that, you're going to have to work that out to complete the command sequence.


## `wait`

The closest equivalent to this would be to call `/container/stop` in a RouterOS script and then poll on `/container/print where …` until it stopped.