docker-openwrt VS Moby

You can run openwrt in docker. It is not the easiest setup, but described on this github

You can install OpenWrt in Docker, if that tickles your fancy: https://github.com/oofnikj/docker-openwrt

Docker networking defaults have been tightened up but per https://github.com/moby/moby/issues/22054#issuecomment-28714...:

the default binding address is still 0.0.0.0.

There are now rules in raw-PREROUTING to drop packets sent from outside the host to container addresses, and to ports mapped to the loopback address. Rules in the filter-FORWARD chain no longer depend on its default policy.

Yeah, while I’ve seen some great libraries that follow the practice of minimizing their dependencies, I’m a bit annoyed with the amount of dependencies that docker will bring along [1]. I’ve been on the lookout for alternatives for my docker needs, but the state of podman, buildah and some others that I checked is similar. They all bring in roughly the same number of dependencies… if anyone knows of a stripped down Go lib that can be used to build from a Dockerfile, pull, and run a container, I would be grateful for any suggestions. Heck docker / moby isn’t even using go.mod proper.

[1] https://github.com/moby/moby/blob/master/vendor.mod

As far as I can tell from https://github.com/moby/moby/issues/4032, as of Debian 12 "bookworm" and Ubuntu 23.04 "Lunar", explicitly setting DEBIAN_FRONTEND is no longer necessary.

It's not an alpine layer, it's a Dockerfile construct representing basically an empty tar file layer: <https://docs.docker.com/build/building/base-images/#create-a...> and <https://github.com/moby/moby/pull/8827>

Manifests are tacked on afterwards, and have a lot of complexity that I'm not sure most folks have actually thought through.

Ex - lots of refs are to "multi-arch" images, Except... there's no such thing as a multi-arch image, the entire identifier is just a reference to a manifest that then points to a list of images (or other manifests) by arch, and the actual resolved artifact is a single entry in that list.

But it means the manifest needs to be able to reference and resolve other names, and that means including... names.

For a more concrete example, just check https://github.com/moby/moby/issues/44144#issuecomment-12578...

Basically - the digests weren't intended to support image verification across repos, and the tool doesn't treat them that way. The digest was intended to allow tighter specification than a tag (precisely because a publisher might push a different container to the same tag later).

If we run the command without -i option (i.e. with only -t option), a pseudo-TTY will be allocated and the shell will start, but no commands can be accepted and we cannot continue the operation because STDIN is disabled. To forcefully exit from a container in this state, we need to send three consecutive SIGINT signals by pressing cmd + . same times. And this exiting does not trigger the automatic container removal provided by --rm option, so we need to trigger it by stopping the container or remove the container directly.

Docker has a known security issue with port exposure in that it punches holes through the firewall without asking your permission, see https://github.com/moby/moby/issues/4737

I usually expose ports like `127.0.0.1:1234:1234` instead of `1234:1234`. As far as I understand, it still punches holes this way but to access the container, the attacker would need to get a packet routed to the host with a spoofed IP SRC set to `127.0.0.1`. All other solutions that are better seem to be much more involved.

When using the Docker Engine on Linux directly, based on the Moby project, you can run