Hi,
So far I've been able to run it correctly
I'm wondering if it's possible to run some debian minimal or another distro.
I mean server with services like ssh, www, php, box86, qemu, dlna, etc.

Containers are not VMs.

That article doesn't tell you that you cannot do what you wish, merely why it isn't a good idea.

Instead of starting with the end solution, how about we start with what end goal you're trying to accomplish and let the solution fall out of that? I prefer to invert the XY Problem where possible.

If your end goal may be rephrased as "I stopped learning about virtualization technologies in 2005 when VMware came out and don't want to learn anything about containers, so give me a way to run full-fat OSes as VMs instead, please," this isn't the best place to get you past your blockage.

If instead you can bring some specific task that would work better this way on a RouterOS box, then we can at least entertain the idea. Be warned, however: most likely, we'll give you an alternative involving containers.

I'm trying https://hub.docker.com/r/ubuntu/bind9 right now.
It starts but I haven't solved all the networking issues.
The image could use more networking tools. *sigh*

You can build your own BIND9 container using an alpine base by building the following Dockerfile and importing the TAR file to the hAPax3's disk:

The Mikrotik container docs explain the very basic of building a TAR (https://help.mikrotik.com/docs/display/ ... ontainer-c)buildanimageonPC), so using docker on a PC, you'd run the following after creating a file called Dockerfile using the above code inside:

One of the benefits of building your own is you can include any desired zone files in COPY in the Dockerfile. But above example uses a default recursive resolver by default (e.g. it accepts DNS on port 53 on VETH, and then use root DNS servers to resolve

I'm trying https://hub.docker.com/r/ubuntu/bind9 right now.
It starts but I haven't solved all the networking issues.
The image could use more networking tools. *sigh*

OMG This image is a jewel! First things first:

• I'm using RouterOS example pattern: add bridge, add IPv4 subnet, add IPv6 subnet.
• Once hAP ax3 firewalls are updated the container networking just works!

Now for the really sweet part:

• The ubuntu/bind9 image has the apt package setup.
• No problems update then install subversion package.
• And subversion persists across container restarts.
• Didn't complete ssh package install but it worked.

@Amm0 thank you. That's really appreciated.
Before containers there were bare metal hypervisors; I boarded VMware ESXi free license train at version 3.5.
I agree containers are lighter weight and far more versatile but containers too have a steep learning curve.
Right now an ESXi host has failing HDD which downed a prior firewall / router VM playing that role.
hAP ax3 is now well along taking on that role and this BIND 9 container fills in another piece.

but containers too have a steep learning curve.

In the context of Mikrotik, try to think of them as a way to run an regular Linux "EXE" ... vs all the management ecosystem around Docker/etc. And DockerHub is still pretty focused on X64 so not all things play well on Mikrotik.

Before containers there were bare metal hypervisors; I boarded VMware ESXi free license train at version 3.5.

And before virtualization, there was UNIX "chroot". So I just think of the Dockerfile as a nouveau Makefile around "chroot". But then again, I recall learning BIND9 zone files from a Sparcstation2's man pages.

Right now an ESXi host has failing HDD which downed a prior firewall / router VM playing that role.

Well, that's nice part about container, especially if you build them yourself (or use GitHub to do that for you).. is that both the "code" (BIND9) and any zone files are already in a TAR file for both backup and deployment.

You can use mounts on Mikrotik to mount the config/zone files instead... but really do think for DNS, building the config(named.conf+zone files) into the container image likely be best. If DNS changes, just replace the whole TAR on Mikrotik. (Or use a 2nd container to do it and switch)

containers too have a steep learning curve.

"Steep"? No. "Broad?" Yes.

Amm0 gave you a four-line example above, which is simple enough you should be able to stare at it without once looking at the the Dockerfile reference and still puzzle out what it does. If that isn't a shallow learning curve, I don't know what is.

If you know shell scripting and Makefiles, the remaining elements legal in a Dockerfile amount to a set of directives to Docker's container build engine.

The only problem with containers in this regard is that the technology's now eight years old, leaving you a lot to catch up on if you're starting today.

As ever, the best way to learn a completely new technology is to set yourself a project and learn the minimal set of things you need in order to accomplish it. Automating the creation of fresh BIND containers is a fine example because BIND comes from the old design days of single independent services.

What I caution against above in my article is trying to make containers do too much. Bind + Subversion + SSH is definitely "too much."

both the "code" (BIND9) and any zone files are already in a TAR file for both backup and deployment.

Being able to "slaughter your cattle" and redeploy them at will means you don't need to back up the image tarball, either. You back up the Dockerfile and any input files, allowing you to rebuild the tarball at will.

Couple the Dockerfile with a Makefile and you can create the automation that lets you say things like "make redeploy" to build a fresh container, replace it on the target host, and restart it in a single command.

You can use mounts on Mikrotik to mount the config/zone files instead... but really do think for DNS, building the config(named.conf+zone files) into the container image likely be best.

I think it comes down to how often the zone files change. On a small LAN, where they might change quarterly at most, copying them directly into the container is fine, since by then, you may want to update BIND as well.

If this is the DNS at the center of a big WAN, I'd put them on a mount because they're likely changing daily, and the BIND project doesn't make new stable releases daily, so why rebuild and redeploy the container?

Granted, such a big, central DNS server isn't a good service to put on a RouterOS box…

Gentle souls, thank you so much for your experienced words and valuable time. Please don't mistake my direction as disagreement with good advice.

The only problem with containers in this regard is that the technology's now eight years old, leaving you a lot to catch up on if you're starting today.

The hard constraint I suffer with today is my personal time which is in high demand elsewhere.

Being able to "slaughter your cattle" and redeploy them at will means you don't need to back up the image tarball, either.

In a Virtual Machine (VM) world, Subversion based scripting provided critical capability to rapidly redeploy and configure VM. Aforesaid failed VM relied upon Subversion for updating configuration and zone files. hAP ax3 BIND 9 plan is as zone transfer intermediary between external BIND 9 VPS pair and internal Windows Active Directory Domain Controller pair. hAP ax3 BIND 9 as slave only zone transfer server doesn't really need to have long term zone file persistence but it seems to just be there.

I think it comes down to how often the zone files change. On a small LAN, where they might change quarterly at most, copying them directly into the container is fine,

The failed VM was master for a few zones but for hAP ax3 the plan is slave those zones so updating zone files becomes fully automated.

since by then, you may want to update BIND as well.

The image APT package manager will be useful keeping BIND 9 current.

What I caution against above in my article is trying to make containers do too much. Bind + Subversion + SSH is definitely "too much."

Yes, good container design should avoid such. While my network has 20-30 VM only a few run at any time and there is only a single operator. It seems to me I may not be much use Subversion or SSH after all.

TL;DR I choose good enough over the perfect solution which is time cost unattractive for now. Future optimization remains in play.

failed VM relied upon Subversion for updating configuration and zone files.

In the containerized world, you'd run Subversion on the container build host, which would do an "svn up" to pull fresh zone files, then build a container against them.

Each time you update the zone files, there are two major paths depending on where you stored those zone files on the container runner:

1. You baked the zone files into the container itself as Amm0 recommended above, requiring you to rebuild and redeploy that container.
2. You mounted a volume into the container as I recommended, so you merely need to scp the new zone files to that volume and restart the container to get it to see the new data.

In neither case do you need sshd inside the container. Under the first plan, the zone files get uploaded to the router along with a fresh copy of BIND when either one changes. In the second plan, it's RouterOS running the SSH server that receives the scp'd zone files when they change, since it is the host for the volume mounted into the container.

for hAP ax3 the plan is slave those zones so updating zone files becomes fully automated.

Yes. Ship the container with a minimal configuration that merely knows how to talk to the primary DNS servers to pull its data, then keep it up to date. It will store its cached copy inside the container, which is perfectly fine in this case. You don't need volumes for this. If you have to burn down the container and redeploy, it will simply pull the zone again and re-cache it.

No need at all for svn or sshd.

since by then, you may want to update BIND as well.

The image APT package manager will be useful keeping BIND 9 current.

That's VM thinking. The containerized way is to rebuild and redeploy the container to upgrade the software inside.

For something super-common like BIND, you shouldn't even be building your own containers. Simply find one that's well-maintained and compact, then inject your own local configuration on each redeployment.

I haven't gone looking, but I'd be surprised if you can't find one that fits on the internal flash. You should still put it on a USB stick since that's far easier to replace in case of chip failure, but you shouldn't need more than tens of megs here. If you're measuring a BIND container in gigs, you've done something highly suboptimal.

In neither case do you need sshd inside the container. Under the first plan, the zone files get uploaded to the router along with a fresh copy of BIND when either one changes. In the second plan, it's RouterOS running the SSH server that receives the scp'd zone files when they change, since it is the host for the volume mounted into the container.

Yes. Ship the container with a minimal configuration that merely knows how to talk to the primary DNS servers to pull its data, then keep it up to date. It will store its cached copy inside the container, which is perfectly fine in this case. You don't need volumes for this. If you have to burn down the container and redeploy, it will simply pull the zone again and re-cache it.

No need at all for svn or sshd.

Understood, in general agreement, and svn sshd are superfluous.

That's VM thinking. The containerized way is to rebuild and redeploy the container to upgrade the software inside.

For something super-common like BIND, you shouldn't even be building your own containers. Simply find one that's well-maintained and compact, then inject your own local configuration on each redeployment.

I haven't gone looking, but I'd be surprised if you can't find one that fits on the internal flash. You should still put it on a USB stick since that's far easier to replace in case of chip failure, but you shouldn't need more than tens of megs here. If you're measuring a BIND container in gigs, you've done something highly suboptimal.

Yes, VM thought it is. IMO my chosen image https://hub.docker.com/r/ubuntu/bind9 seems to fit proposed criteria.

IMO my chosen image https://hub.docker.com/r/ubuntu/bind9 seems to fit proposed criteria.

The 46 MiB for 64-bit ARM number quoted is the compressed image size, not the running size. You can expect it to roughly double in size when unpacked, so that on an ax³ with its 128 MiB of flash, it probably won't even unpack, since you temporarily need three times the storage space. (The image itself plus 2× that for the container generated from it.)

Not that I would recommend running BIND from internal flash, since it wants to cache data to disk, risking burning it out. You might be able to make use of RouterOS's new ramdisk capability for caching, but I'm mainly using this router's fixed flash size as a thread-relevant yardstick.

With a USB stick in the ax³, you can download to internal flash and unpack to USB, avoiding both problems, but I'm still not seeing why you'd tolerate this flabby container's size merely to get a stripped-down thing they call "Ubuntu" even though it's missing stuff even a minimal Ubuntu Server install will have.

Without making any personal endorsement, this one looks a lot more suitable, being a quarter the size yet well-documented and capable of doing the same job.

I'm confident mjkaye/bind9-alpine is sufficient despite it's 9.14 vs 9.18 version based on long BIND 9 experience. Canonical is updating frequently.
I am deployed on 16 GiB USB device:
The container shell df -hl is in general agreement with RouterOS as it should be.

We now know ubuntu/bind9 size as it's the only thing on that volume. 522 MiB is overstated due to added Subversion package and downloaded APT metadata.

A better way to get the unpacked image size is to ask Docker:


So there's me wrong; 46 megs became nearly 200 when unpacked. There must be a lot of highly-compressible text files in both images. My "2×" value assumed it was mostly executables.

@tangent Thank you!

My long standing beet with Canonical is any Ubuntu distribution is always far heavier than it's Debian progenitor. I prefer small attack surface.

In this case the heavier image is conserving my time. *sigh*
Are we hijacking @MWBSystems topic?

The smallest image is actually for unbound DNS, since someone publishes a "distroless" version – so no Alpine even. It actually a good example of a complex Dockerfile that build source code, then copies just the "EXE" and a few related files (see https://github.com/klutchell/unbound-do ... Dockerfile). The dockerhub version is here: https://hub.docker.com/r/klutchell/unbound

I'm more a BIND9 guy myself - although in reality I use AWS or the domain registrar's free DNS - but thought unbound be good to mention in our hijacking of the thread.

One additional note is BIND9 actually support Mikrotik /tool/update-dns (if enabled in zone file), which may be of use to update from RouterOS.

@* Thank you! I feel like I'm reading gold. ... As the hijack continues:
A casual Google Search suggests unbound doesn't zone transfer either way.

I’m guessing Amm0 meant NSD.

I’m guessing Amm0 meant NSD.

Specifically, https://nlnetlabs.nl/projects/unbound/about – while only a "recursive [DNS] resolver" if that what you're using BIND9 for, that smaller. Zone transfers, maybe, dunno?.

I was trying to kill two birds with one stone:

Unbound is popular in Pi-Hole community, so likely be trivial to bring up along with Pi-Hole (whether useful, dunno – I've never used either pi-hole or unbound)

As example of using NO Alpine, Ubuntu, or Debian in the final container image, outside of DNS specifically. A similar example using same "distroless" (e.g. no Linux disto in container) would be Cloudflared, which is ~30MB image (and be under "supported container/docker" title )

@tangent Wikipedia § NSD doesn't say much. I find NSD § Configuration § Setting up a secondary zone potentially useful.

Zone transfers, no.

I could be wrong on that part

I've never used either pi-hole or unbound

@Amm0 NLnet Labs unbound documentation is clear, caching resolver only.
IMO the good news is NLnet Labs NSD covers the authoritative side.
Similar to PowerDNS which is separate daemons.