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
|
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
|
-
+
+
+
|
Allow me to begin with a distilled version of the details below, both to satisfy the **tl;dr** crowd and to set broad expectations for the rest of my readers.
The major things lacking in RouterOS’s `container.npk` feature are:
* a local image cache(^One knock-on effect of this not covered above is that removing and reinstalling a container requires RouterOS to re-download the image, even when done back-to-back, even if you never start the container between and thereby cause it to make changes to the expanded image’s files.)
* a CoW/overlay file system(^This is not a verified fact, but an inference based on the observation that if RouterOS _did_ have this facility underlying its containers, I would expect to find equivalents to Docker’s `commit` and `diff` commands. This pairs with the lack of an image cache: no CoW means no need for a baseline source to compute deltas against.)
* image building
* image building(^RouterOS's container runtime is closer in nature to the `runc` command underlying `containerd` than to the broader Docker Engine product. 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.)
* orchestration
* JSON and REST APIs
* per-container limit controls:(^The only configurable resource limit is on maximum RAM usage, and it’s global, not settable on a per-container basis.)
* FD count
* PID limit
* CPU usage
* storage IOPS
* `/dev/shm` size limit
* terminal/logging bps
* syscall restrictions
* [capability][caps] restrictions
* [rlimit]
* hardware pass-thru:
* USB device entries under `/dev` are on the wish list, but not currently available.(^Not unless RouterOS itself sees the USB device, as with storage media, which you can bind-mount into the container with “`/container/add mounts=…`”.)
* There is no GPU support, not even for bare-metal x86 installs.
[caps]: https://www.man7.org/linux/man-pages/man7/capabilities.7.html
[rlimit]: https://www.man7.org/linux/man-pages/man2/getrlimit.2.html
[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. This means equivalent commands to the likes of “`docker run --attach std…`” would not make a lot of sense on RouterOS, there being nothing like the termios/pty subsystem visible at the RouterOS CLI level.
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…
|
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
-
+
-
-
-
|
There is no interactive terminal (stdin/stdout/stderr) in RouterOS to speak of, and you normally run these boxes headless, connecting to their virtual terminal via WinBox or SSH only long enough to reconfigure something before logging back out. The `container.npk` feature is designed to run its subordinate processes purely 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 carries the requirement that a `/bin/sh` program exist inside the container.(^You can’t count on that in every container. Indeed, all of [my public containers](https://hub.docker.com/repositories/tangentsoft) elide the shell to reduce the container’s attack surface.) Even then, you’re typing commands at the shell, not at the container’s `ENTRYPOINT` process.
All of this explains why RouterOS [lacks](#run) a direct equivalent of “`docker run`”, particularly the common `-it` option pair. The closest `container.npk` comes is its [`shell`](#shell) command implementation.
## <a id="build"></a>`build`/`buildx`
RouterOS provides a bare-bones container runtime only, not any of the image building toolchain. 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.
RouterOS provides a bare-bones container runtime only, not any of the image building toolchain.
[sdcnt]: https://packages.fedoraproject.org/pkgs/systemd/systemd-container/
[sdnsp]: https://wiki.archlinux.org/title/Systemd-nspawn
## <a id="commit"></a>`commit`
Given the [generalities above](#general), it should be no surprise that RouterOS has no way to commit changes made to the current image layer to a new layer.
|