That brings us to the related matter of…

[script]: https://help.mikrotik.com/docs/display/ROS/Scripting


# <a id="run"></a>There Is No “Run”

RouterOS offers no shorthand command akin to `docker run` for creating and starting a container in a single step. Moreover, the lack of Linux-like interactive terminal handling — covered [below](#terminal) — means a simple command like…
Although RouterOS 7.20 did add an [equivalent to Docker’s `exec` command](#exec), it still lacks a `run` equivalent, being shorthand for creating and starting a container in a single step. Moreover, the lack of Linux-like interactive terminal handling — covered [below](#terminal) — means a simple command like…

    $ docker run --rm -it alpine:latest

…followed by…

    sh-5.1# <do something inside the container>
    sh-5.1# exit

…may end up expressed under RouterOS as…

    > /container
    > add remote-image=alpine:latest veth=veth1 entrypoint=sleep cmd=3600
    > print
    … nope, still downloading, wait…
    > print
    … nope, still extracting, wait longer…
    > print
    … oh, good, got the container ID…
    …wait until container extracts…
    > start 0
    … wait for it to launch…
    > shell 0
    sh-5.1# <do something inside the container>
    sh-5.1# exit
    > stop 0
    > remove 0

Whew! 😅

Prior to the enhancements to `/container/print` in RouterOS 7.20, the sequence could be even longer because you needed to manually give the command repeatedly until the runtime entered a settled state, else the `shell` command would fail.

I resorted to that “sleep 3600” hack in order to work around the lack of interactive mode in `container.npk`, without which containers of this type will start, do a whole lot of _nothing_, and then stop. I had to give it some type of busy-work to keep it alive long enough to let me shell in and do my actual work. This sneaky scam is a common one for accomplishing that end, but it has the downside of requiring you to predict how long you want the container to run before stopping; this version only lasts an hour.
What has _not_ changed in RouterOS 7.20 is the need for that “sleep 3600” hack. We need it in order to work around the lack of interactive mode in `container.npk`, without which containers of this type will start, do a whole lot of _nothing_, and then stop. We must give it some type of busy-work to keep it alive long enough to let us shell in and do our actual work. This sneaky scam is a common one for accomplishing that end, but it has the downside of requiring the user to predict how long you want the container to run before stopping; this version only lasts an hour.

If you are imagining more complicated methods for keeping containers running in the background when they were designed to run interactively, you are next liable to fall into the trap that…


# <a id="cmd"></a>There Is No Host-Side Command Line Parser

The RouterOS CLI isn’t a Bourne shell, and the container feature treats the optional `entrypoint` and `cmd` values as simple strings, without any of the parsing you get for free when typing `docker` commands into a Linux command shell. The net effect of all this is that with many containers, you’re limited to two-word commands, one in `entrypoint` and the other in `cmd`, as in the above “`sleep 3600`” hack.

## <a id="events"></a>`events`

RouterOS doesn’t support container events.


## <a id="exec"></a>`exec`

As of RouterOS 7.20, the following commands are roughly equivalent:

    $ docker exec CONTAINER ls -lR /etc
    $ ssh myrouter '/container/shell cmd="ls -lR /etc" 0'

That is to say, they each pass a multi-argument command to the command shell inside the container, if any, which parses the command and executes it within its confines.

There is no way in RouterOS to execute a command inside a running container short of `/container/shell`, which of course only works if there is a `/bin/sh` inside the container.
Prior, the only method was via `/container/shell`, which of course only works if there is a `/bin/sh` inside the container.


## <a id="export"></a>`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.