16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
|
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
-
|
* orchestration
* rootless mode
* image building
* [local image cache](#cache)
* [Docker Engine API][DEAPI]
* volume storage manager
* [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, several other limitations covered here would not exist.)
* 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
|
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
41
42
43
44
45
46
47
48
49
50
51
52
53
54
|
-
|
* **crun**: 0.5 MiB(^This is Podman’s alternative to `runc`, written in C to make it smaller. Early versions of Podman once relied on `runc`, and it can still be configured to use it, but the new default is to use the slimmer but feature-equivalent `crun`.)
One reason `container.npk` is far smaller than even the smallest of these runners is that the engines delegate much of what RouterOS lacks to the runner, so that even then it’s an unbalanced comparison. The [`kill`](#kill), [`ps`](#ps), and [`pause`](#pause) commands missing from `container.npk` are provided in Docker Engine way down at the `runc` level, not up at the top-level CLI.
With this grounding, let us dive into the details.
[caps]: https://www.man7.org/linux/man-pages/man7/capabilities.7.html
[CoW]: https://en.wikipedia.org/wiki/Copy-on-write
[DEAPI]: https://docs.docker.com/reference/api/engine/
[OCI]: https://opencontainers.org/
[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
|
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
|
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
|
-
+
-
+
-
+
|
## <a id="build"></a>`build`/`buildx`
RouterOS provides a bare-bones container runtime only, not any of the image building toolchain.
## <a id="commit"></a>`commit`
Given the [global limitations](#global), it should be no surprise that RouterOS has no way to commit changes made to the current image layer to a new layer.
Other OCI engines provide this by combining use of the [`diff`](#diff) facility and the local image cache, both of which RouterOS currently lacks.
## <a id="compose"></a>`compose`
RouterOS completely lacks multi-container orchestration features, including lightweight single-box ones like [Compose](https://docs.docker.com/compose/) or [Kind](https://kind.sigs.k8s.io) virtual clusters.
## `create`/`load`
[Covered above](#create).
## <a id="cp"></a>`cp`
RouterOS does let you mount a volume inside a container, then use the regular `/file` facility to copy files in under that volume’s mount point, but this is not at all the same thing as the “`docker cp`” command. There is no way to overwrite in-container files with external data short of rebuilding the container or using in-container mechanisms like `/bin/sh` to do the copying for you.
If you come from a Docker or Podman background, their local overlay image stores might lead you into thinking you could drill down into the GUID-named “container store” directories visible under `/file` and perform _ad hoc_ administration operations like overwriting existing config files inside the container, but alas, the RouterOS CLI will not let you do that.
If you come from a Docker or Podman background, their open (if abstruse) local image store file structures might lead you into thinking you could drill down into the GUID-named “container store” directories visible under `/file` and perform _ad hoc_ administration operations like overwriting existing config files inside the container, but alas, the RouterOS CLI will not let you do that.
## <a id="diff"></a>`diff`
With neither a local image cache nor a CoW file system to provide the baseline, there can be no equivalent command.
Because the `container.npk` package includes the Linux kernel’s `overlayfs` module, subsequent layers do not delete overwritten files, providing the base mechanism this future facility will require. One can only speculate on why that work has yet to be done.
## <a id="events"></a>`events`
RouterOS doesn’t support container events.
|