pdns
pdns copied to clipboard
PowerDNS
Official pdns docker images
- Program: Authoritative, Recursor, dnsdist
- Issue type: Feature request
Short description
Provide official docker images
Usecase
I want to run powerdns (in this case a recursor) reliably on my home k8s pi-cluster without building my own images or trusting third parties
Description
Next to packages, it would be great to have official pdns docker images available On Docker Hub, there's https://hub.docker.com/r/powerdns - But I find no reference to this on powerdns.com, so I'm not sure this is the real thing and not a shmock. If it is official, a back-reference eg on powerdns downloads would be great. Also, if it is official, it would be great to have one image that is being upgraded with newer tags instead of the current inclusion of the version in the image name
Happy to help creating the dockerfile and/or serve as a canary/friendly user
Hello! Those images are official. I'll improve the references.
Are you sure you want to blindly upgrade between major versions? For the auth, there might be database schema changes. For all three products, there might be incompatible configuration changes.
Yes, https://hub.docker.com/u/powerdns is the real thing. Thanks pointing out the omission on our website.
We tag latest releases, is this not what you meant?
You can contribute to the Dockerfiles in this repository: https://github.com/PowerDNS/pdns (Dockerfile-auth, Dockerfile-dnsdist and Dockerfile-recursor).
edit: nevermind, I see Habbie has answered in the meantime
Are you sure you want to blindly upgrade between major versions? For the auth, there might be database schema changes. For all three products, there might be incompatible configuration changes.
That's where the beauty of tags comes in^^ You can have concurrent tags for major/minor/bugfix versions, and the user will get updated to the latest version of his chosen train; and if you don't generally provide a "latest" tag, nobody should fall into the pit of an update into disaster.
The benefit of this would be less confusion - you'd have eg only recursor, server and dnsdist as images, instead of bedazzling new users to find out which one is "the real thing", leaving them to guessing that the highest number might be the most current. Which version/tag is the most current could easily be placed in the image overview, with a note which versions/tags still receive security updates.
Also, your images will gain more weight/klout/.. as it's not 10k for -44, 10k for -45 and so on, but 100k for server 😄
Currently I'm only looking into the (rather slimly configured) recursor; so probably I could even go with "latest" 😄
That's where the beauty of tags comes in^^ You can have concurrent tags for major/minor/bugfix versions, and the user will get updated to the latest version of his chosen train; and if you don't generally provide a "latest" tag, nobody should fall into the pit of an update into disaster.
Right! That model would work too. I think we considered it and decided our current model would be clearer. If I look at, for example, openwrt/rootfs, there are so many tags it -also- becomes confusing. I'm not sure there's a perfect answer here.
I was about to look into PowerDNS when I saw the rather unpleasant image and tagging scheme the project(s) are using. I landed here to check first, since it didn't look too official.
Most of the big projects use a certain tagging scheme for docker images. Picking up this scheme would be a huge help, especially with dependency management tools (e.g. renovate). Those tools are widely used in IaC (Infrastructure as Code) projects, where the maintainers only have to merge a PR created by the to deploy the new version to their servers. Based on some rules, this could also happen automatically.
Having the major version in the image name just complicates things. If you want to make sure that users can't use the latest tag, even though it's helpful for trying things out, you can choose not to offer one. Instead, you could offer the tag 44-latest for version 44.x and 45-latest for version 45.x. Or even better 44-bookwork and 45-bookworm when it was built with Debian bookworm as base image. If you decide on adding an alpine-based image, you would tag it 44-alpine and 45-alpine so that they could live next to each other. For those like me, who really want to pin images, you could also offer 44.1.2-bookworm and for those who don't want to pin the patch version 44.1-bookworm.
Even though it might look weird, this is what the schema dependency management tools that handle Docker images understand. For example, they would create a PR that updates the image from 44.1.1-foo to 44.1.2-foo but never from 44.1.1-foo to 44.1.2-bar (if that isn't specially configured somehow).
In the end, I would still recommend having the latest tag, just for trying it out. In the README and documentation, I would strictly advise against using it, though. If I pull and use the latest tag of Postgres in production it would be my own fault if "suddenly" a new major version is released, and I blindly pull it and restart the container.
Here are some example images which use the described scheme:
- https://hub.docker.com/_/postgres
- https://hub.docker.com/_/nginx
- https://hub.docker.com/_/busybox
- https://hub.docker.com/_/python
- https://hub.docker.com/_/redis
- https://hub.docker.com/_/node
- https://hub.docker.com/_/mysql
Please don't understand this as a personal critic. I just wanted to provide feedback on how I think the containerization part of the project could be vastly improved. I have seen others using this kind of image scheme before, and I'm always in conflict, if I should really invest the time in checking and updating the images manually. I sometimes even build my own images if the process is just too complicated. It's usually not a big thing if someone only runs a couple of containers, but doing that for tens or hundreds of containers is just not feasible.
Thanks for your suggestion @MichaelSasser. We've had an internal discussion about it and will take a closer look at it.
@Habbie @aerique Could you also consider bumping up the version of Debian used across all PowerDNS docker images.
Currently you are either using EOL (i.e. Buster in the Lightingstream docker image which is now EOL ELTS, i.e. commercial payment for updates only) or EOL LTS (i.e. Bullseye in most other Docker images).
The current version of Debian (Bookworm) has been out since 2023-06-10. The previous version of Debian (Bullseye) becomes obsolete next year (2026-08-31 ) unless you pay for commercial support under Debian's EOL ELTS programme.
So really you should bump up to Bookworm "today" and then try to keep on top of it going forward ? The Debian release cadence is not exaclty rapid, so it should only require a Dockerfile update from you every couple of years. 😉
Could you also consider bumping up the version of Debian used across all PowerDNS docker images.
Yes, good idea. PRs help!