MikroTik Solutions

Changes To Container Limitations
Login

Changes To Container Limitations

Changes to "Container Limitations" between 2025-05-02 11:24:32 and 2025-05-23 19:57:44

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.