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`.
|
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 discuss…
|