MikroTik Solutions

Changes To Container Limitations
Login

Changes To Container Limitations

Next Previous

Changes to "Container Limitations" between 2024-07-23 19:08:14 and 2024-07-23 20:33:19

1
2
3

4
5
6
7
8
9
10

1
2

3
4
5
6
7
8
9
10



-
+








# 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.
The [RouterOS `container.npk` feature](https://help.mikrotik.com/docs/display/ROS/Container) is highly useful, but it is a custom development, not a copy of Docker Engine. Because of the stringent resource constraints on the bulk of MikroTik's devices, it is very thinly featured compared to the big-boy server container engines. The purpose of this document is not to denigrate the RouterOS or its developers; RouterOS serves a particular market, and its developers are working within those constraints. The intent here, rather, is 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 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.
︙
23
24
25
26
27
28
29
30

31
32

33
34
35
36
37

38
39
40
41
42
43
44

23
24
25
26
27
28
29

30
31

32
33
34
35
36

37
38
39
40
41
42
43
44








-
+

-
+




-
+









[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.
RouterOS doesn't maintain an image cache, thus has no way to commit changes made to the current 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.
It is for this same reason that removing and reinstalling the container re-downloads the image, even when done back-to-back, without starting the container and thereby making changes to the downloaded image.


## `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.
There is no direct equivalent of this command. The closest RouterOS comes is when you mount a volume, then use the regular `/file` facility to copy files in under that volume's mount point. There is no direct way to copy a file into the container proper, as you might when overwriting a stock config file.


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

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








-
+
















-
+

-
+

-
-
-
-
+
+
+
+









-
+








## `events`

RouterOS doesn't support container events.


## `exec`

<font color=red>**TODO**</font>
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.


## `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`
## <a id="image"></a>`image`/`images`

<font color=red>**TODO**</font>
RouterOS does not maintain a local image cache, thus has no need for any of the subcommands:


## `images`

<font color=red>**TODO**</font>
*   `docker image ls` (a.k.a. `docker images`)
*   `docker image prune`
*   `docker image rm`
*   `docker image tree`


## `import`

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


## `info`

<font color=red>**TODO**</font>
With the understanding that RouterOS has far fewer configurables than a big-boy container engine, the closest command to this in RouterOS is `/container/config/print`. The output is in typical RouterOS "print" format, not JSON.


## `inspect`

The closest approximation to this in RouterOS is 

    /container/print detail where …
︙
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151

133
134
135
136
137
138
139





140
141
142
143
144
145
146








-
-
-
-
-









    /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.
︙
194
195
196
197
198
199
200
201

202
203
204
205
206
207
208

189
190
191
192
193
194
195

196
197
198
199
200
201
202
203








-
+








## `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>
There is no equivalent to this in RouterOS. You will need to connect to your image registry of choice and use its search engine.


## `start`

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

<font color=red>**TODO**</font>
︙
223
224
225
226
227
228
229
230

231
232
233
234
235

218
219
220
221
222
223
224

225
226
227
228
229
230








-
+






    /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>
RouterOS's `container.npk` has no independent version number of its own. You use the version of the package matching the `routeros.npk` installed. RouterOS upgrades the container package automatically when it upgrades everything else.


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