search

PowerDNS / pdns

PowerDNS Authoritative, PowerDNS Recursor, dnsdist
https://www.powerdns.com/
GNU General Public License v2.0
3.7k stars 908 forks source link

Official pdns docker images #12068

Open snaeqe opened 2 years ago

snaeqe commented 2 years ago

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

Habbie commented 2 years ago

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.

Habbie commented 2 years ago

(Note that the Dockerfiles live in the root of our git tree)

aerique commented 2 years ago

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

snaeqe commented 2 years ago

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" 😄

Habbie commented 2 years ago

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.

MichaelSasser commented 11 months ago

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:

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.

aerique commented 11 months ago

Thanks for your suggestion @MichaelSasser. We've had an internal discussion about it and will take a closer look at it.