MikroTik Solutions

Changes To Container Limitations
Login

Changes To Container Limitations

Next Previous

Changes to "Container Limitations" between 2024-07-23 18:45:59 and 2024-07-23 19:08:14

1
2
3
4
5
6
7
8
9
10
11

12
13
14
15
16
17
18
19








20
21
22
23
24
25
26
27
28
29
30
31
32
33

34
35
36
37
38
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

1
2
3
4
5
6
7
8
9


10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
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
92
93
94
95
96
97
98
99
100
101
102
103
104
105










-
-
+








+
+
+
+
+
+
+
+













-
+






+
+











+
+
+
+
+














+
+
+
+
+
+
+
+
+
+





+
+
+
+
+








# 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.

For lack of any better organization principle, I've chosen to structure this document along the lines of the `docker` CLI, using their command hierarchy, in alphabetical order at each level. I skip over short aliases like `docker rmi` for `docker image rm` in order 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.


## `build`/`buildx`

RouterOS provides a bare-bones container runtime only, not any of the image build tooling. It is closer in nature to the `runc` command underlying `containerd` than to Docker Engine proper. An even closer match is the lightweight `crun` command at the heart of Podman, and even more so the elementary runner that ships with systemd, variously called either [`systemd-nspawn`][sdnsp] or [`systemd-container`][sdcnt], depending on the tastes of whoever is packaging it.

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


## `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`
## `create`/`load`/`run`

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.

RouterOS has no shorthand command like `docker run` for creating and starting a container in a single step. You must `add` it, then `start` it.


## `diff`

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


## `events`

RouterOS doesn't support container events.


## `exec`

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


## `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.


## `image`

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


## `images`

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


## `import`

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


## `info`

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


## `inspect`

The closest approximation to this in RouterOS is 

    /container/print detail where …
︙
93
94
95
96
97
98
99
















100
101
102
103
104
105
106

122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151








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








[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.


## `login`/`logout`

RouterOS only allows you to configure a single image registry, including the login parameters:

    /container/config/set registry-url=… username=… password=…

The only way to "log out" is to overwrite the username and password via:

    /container/config/set username="" password=""


## `logout`

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


## `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.
︙
115
116
117
118
119
120
121
















122
123
124
125
126
127
128
129
130
131
132
133
134
135
136





137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167





168
169
170
171

160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209







210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235








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















+
+
+
+
+







-
-
-
-
-
-
-

















+
+
+
+
+





    $ 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.


## `ps`/`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.


## `push`/`pull`

RouterOS maintains no local image cache, thus cannot push or pull images.

While it _can_ pull from an OCI image repo, it does so as part of `/container/add`, which is closer to a `docker create` command than to `docker pull`.

There is no equivalent at all to `docker push`.


## `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.


## `search`

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


## `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.


## `version`

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


## `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.