MikroTik Solutions

Changes To Container Limitations
Login

Changes To Container Limitations

Changes to "Container Limitations" between 2024-07-25 05:49:51 and 2024-07-25 05:53:12

39
40
41
42
43
44
45
46

47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
39
40
41
42
43
44
45

46
47
48
49
50
51
52
53
54






























55
56
57
58
59
60
61







-
+








-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-







[sdcnt]: https://packages.fedoraproject.org/pkgs/systemd/systemd-container/
[sdnsp]: https://wiki.archlinux.org/title/Systemd-nspawn

A good many of these limitations stem from those of RouterOS itself. For instance, while RouterOS proper is built atop Linux, and it provides a feature-rich CLI, it is nothing like a Linux command shell. (More on this [below](#run).)

While I could also point out the lack of a background management daemon,(^`containerd` in modern setups, `dockerd` in old ones) a good bit of Docker’s competition also lacks this, on purpose, so I cannot ding RouterOS for this same lack.

With this grounding, let us dive into the details
With this grounding, let us dive into the details.


## <a id="create" name="load"></a>Container Creation

The single biggest area of difference between the likes of Docker and the RouterOS `container.npk` feature is how you create containers from OCI images.

RouterOS combines Docker’s `create` and `load` commands as `/container/add`, the distinction expressed by whether you give it the `remote-image` or `file` option, respectively.

<a id="run"></a>There is no shorthand command like `docker run` for creating and starting a container in a single step. Moreover, the lack of Linux-like interactive terminal handling means a simple command like…

    $ docker run --rm -it alpine:latest
    sh-5.1# <do something inside the container>
    sh-5.1# exit

…is most briefly expressed under RouterOS as…

    > /container
    > add remote-image=alpine:latest veth=veth1 entrypoint=sleep cmd=3600
    … wait for it to download and extract …
    … poll with "print" commands to get the container ID …
    > 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

The “sleep 3600” hack is necessary because `container.npk` lacks any notion of interactive mode. In order to keep a container of this type from starting, doing a whole lot of _nothing_, and then stopping,(^…but not cleaning up after itself as with `--rm`, mind!) you have to give it some type of busy-work to keep it alive. This is a common one, but it only lasts an hour. More complicated methods are difficult to pull off due to the lack of host-side Bourne shell command parsing in RouterOS; the `cmd` option gets passed into the container as a single string, but you only have two to play with, `entrypoint` and `cmd`, so how do you say something like the following?

    docker run alpine:latest 'while true ; do sleep 5 ; done' &

The answer is that if you want a RouterOS container to do anything tricky like that, you need to write your own `ENTRYPOINT` script.

Another bit of fallout from all this is that there can be no equivalent to commands like “`docker run --attach std…`” under RouterOS due to lack of a termios/pty subsystem visible at the RouterOS CLI level.

But let us move on from `run`.

Given the size of the output from `docker create --help`, it should not be surprising that the bulk of that is either not available in RouterOS or exists in a very different form. Most of these limitations stem from [the list above](#global). For instance, the lack of any CPU usage limit features means there is no equivalent under `/container` for the several `docker create --cpu*` options. Rather than go into these options one by one, I’ll cover the ones where the answers cannot be gleaned through a careful reading of the rest of this article:

*   **`--env`**: The equivalent is this RouterOS command pair:

        /container/envs/add name=NAME …
        /container/add envlist=NAME …

107
108
109
110
111
112
113
114

115
116
117

































118
119
120
121
122
123
124
77
78
79
80
81
82
83

84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127







-
+



+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+








*   **`--read-only`**: RouterOS offers precious little in terms of file system permission adjustment. As a rule, it is best to either shell into the container and adjust permissions there or rebuild the container with the permissions you want from go. Any expectations based on being able to adjust any of this between image download time and container creation time are likely to founder.

*   **`--restart`**: <a id="restart"></a>The closest RouterOS gets to this is its `start-on-boot` setting, meaning you’d have to reboot the router to get the container to restart. If you want automatic restarts, you will have to [script] it.

*   **`--rm`**: No direct equivalent. There is a manual `/container/remove` command, but nothing like this option, which causes the container runtime to automatically remove the instantiated container after it exits. It’s just as well since this option is most often used when running _ad hoc_ containers made from a previously downloaded image; RouterOS’s lack of an image cache means you have to go out of your way to export a tarball of the image and upload it to the router, then use “`/container/add file=…`” if you want to avoid re-downloading the image from the repository on each relaunch.

With all of that to ground us, the rest is far simpler to discussThat 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 means a simple command like…

    $ docker run --rm -it alpine:latest
    sh-5.1# <do something inside the container>
    sh-5.1# exit

…is most briefly expressed under RouterOS as…

    > /container
    > add remote-image=alpine:latest veth=veth1 entrypoint=sleep cmd=3600
    … wait for it to download and extract …
    … poll with "print" commands to get the container ID …
    > 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

The “sleep 3600” hack is necessary because `container.npk` lacks any notion of interactive mode. In order to keep a container of this type from starting, doing a whole lot of _nothing_, and then stopping,(^…but not cleaning up after itself as with `--rm`, mind!) you have to give it some type of busy-work to keep it alive. This is a common one, but it only lasts an hour. More complicated methods are difficult to pull off due to the lack of host-side Bourne shell command parsing in RouterOS; the `cmd` option gets passed into the container as a single string, but you only have two to play with, `entrypoint` and `cmd`, so how do you say something like the following?

    docker run alpine:latest 'while true ; do sleep 5 ; done' &

The answer is that if you want a RouterOS container to do anything tricky like that, you need to write your own `ENTRYPOINT` script.

Another bit of fallout from all this is that there can be no equivalent to commands like “`docker run --attach std…`” under RouterOS due to lack of a termios/pty subsystem visible at the RouterOS CLI level.

With all of that to ground us, the rest is far simpler to discuss.


# <a id="tlc"></a>Remaining Top-Level Commands

For lack of any better organization principle, I’ve chosen to cover these commands in alphabetical order. I skip over short aliases like `docker rmi` for `docker image rm` in order to cover things only once, and I don’t repeat any of the `create`/`load`/`run` discussion [above](#create). Because Podman cloned the Docker CLI, this matches fairly well with it, except that I do not currently go into any of its pure extensions, such as its eponymous `pod` command.


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