Updating from 7.18.2 - is 7.20.x or 7.21.x better for containers on ARM32?

Greetings all. I have a RB3011 that I basically demoted to a container router. Right now I run pihole v6 and an Alpine container for the NextDNS client. Everything works fine, but I’d like to automate a couple things so I’m looking for a way to run commands from outside the container. The changelog for 7.20.x looks like I can do this…

*) container - added option to execute commands inside a container using "/container/shell cmd= user=";

But in 7.21 I see: *) container - added run command to allow interactive mode (CLI only), which I thought we’ve already had for quite some time with /container/shell. Am I confusing these two things somehow?

Also - I see there’s a huge amount of container changes since the oldish version I’m on. Does anyone have an opinion on whether 7.20 or 7.21 is a better choice in general for containers, or any gotchas in the newer versions that would help me decide? RB3011 is ARM32. Tia

I cannot speak directly to 7.18.2 to 7.20.x/7.21.x.... But I do a lot of container testing, include upgrade/downgrades, mainly on ARM32-based RB1100AHx4 (and some CHR). And, in general, things upgrade fine (and mostly downgrade). Once in while in past, something like a VETH may be need be remove and re-added in some upgrades in past.

The more important thing is the disk. Since I have had issues with btrfs formatted disks acting odd in upgrade, but never with ext4. So using ROSE disks, is often where you may upgrade/downgrade risk IMO. But since ext4 is builtin, less problems, at least from what I've seen.

Since NextDNS client should not really have a configuration, need mounts, etc... It should be easy to re-create if needed. But doubt that be the case.

But... as with any RouterOS upgrade... save the :export show-sensitive file=config-7.18.2.rsc locally (and perhaps also save :export file=safe-config-7.18.2.rsc too in case you need to post it here)... and also in Files, save a "Backup" file to PC too.

1 Like
  • /container shell requires the container to be already running, and after the command finishes the container continues to run.

  • /container run requires the container to be in the stopped, not running state. The container will be started with the command being the entry point, and stops when the command exits.

For example the Alpine container on my home router is normally not running, and I can abuse /container run to execute individual commands, even stuff like ls /abc or temporarily run speedtest or iperf3 -s and can be sure no further resources are consumed once the command finishes. If I want a temporary Alpine shell session I use cmd=ash.

True that nextdns doesn’t need envs or mounts. It’s super simple. I have both the containers and their underlying configs all scripted out, so not too tough for me to get fresh ones. Thanks for your thoughts.

Ah, I get it now. Thank you.