Add versioned tags to dockerimage

[JanoschDeurer]

It would be great to have tags on the docker image so one can automatically detect and upgrade to a new version when one is available. This would be especially interesting when #32 is realized.

[joao-p-marques]

It seems like a good idea. WDYT @yajo?
Could it be done with GH Actions like in https://github.com/Tecnativa/doodba/blob/e1699a12dad34e87b3c7ed63d9b683ead1172bd8/.github/workflows/ci.yaml#L29?

[JanoschDeurer]

It is a feature that is directly supported by Dockerhub, if you don't want to build a CI/CD. On Dockerhub you can directly build the git tags as docker tags. If you want any input or help I'll gladly provide it :)

[kaysond]

Agreed. It would be nice to have tagged versions, especially for something that's so security critical

[yajo]

We don't use tags at the moment because there's no intention to maintain more than just 1 version of this image, and I wouldn't want to give the contrary sensation.

This is not meant to be a inheritable haproxy solution with specific stuff for the docker proxy. Instead, it's intended to be just a no-brainer lock you put in front of the socket.

I mean, the underlying proxy technology or version used should be irrelevant for our target users. We might even consider switching to a different proxy in the future if it is useful for something, as long as the behavior of the image remains the same.

That said, if you care about pinning, you can use the image sha256 (which all images have, automatically).

The most similar thing I'd approve as tags would be a date-based tag, but do you think it'd be really necessary given you can use sha256 for pinning? 🤔

[JanoschDeurer]

@yajo I think maintaining only one version of the image is in no conflict with version tags for the image. This image is already updated when new versions of haproxy arrive. If one of these changes breaks something in my deployment it would be great to have a way back to the old version. Right now I have to build my own Dockerimage and then update haproxy myself.

Also I think that using the sha256 hash is not a solution as automation solutions can not update between these as they can not know which one is the newer version.

[kaysond]

+1. It's not about maintaining multiple versions. It's about being able to pin to a specific version and be aware of a new release. Yes, you can use the hash, and you could even update by comparing to the hash of the :latest tag (which actually has problems of its own). But it's just inconvenient.

It's the same reason we have Github releases. Sure, you could just reference commit hashes of a master/release branch, but versions are just convenient.

There's also the matter of what happens if there's a bug? Maybe unlikely given the small size of the project, but if you're building every commit, and there's only one branch, I could easily get a bugged change, or exploitable HAProxy verison on an random pull :latest .

[yajo]

Yes, I'm just curious about how recently the crowd is so worried about having updated, or versioned versions of this image. 🤔

My POV is that it shouldn't be that important what's the version, or even the proxy implementation behind this image. It's just a dumb thing you put in front of your socket and that does mostly "nothing" all the time (except if some unauthorized request lands, of course).

According to that, I don't see a reason to maintain "versions". I mean, what's a "version" for this project? I'd see it more sensible to version it according to the docker API version than on the proxy itself, whose version should be meaningless for this project.

Otherwise I think I'd just use a completely separate versioning system, unrelated to the haproxy version beneath. @joao-p-marques WDYT?

[joao-p-marques]

Well, I agree that the concept of version from the point of view of the "product" is a bit unnecessary here or doesn't really apply.

However, I think we wouldn't loose anything by having different versions pinned in docker images.
I imagine someone might be interested in reverting to a specific old version, whether that is a different version of HA Proxy, a different interface with respect to environment variables and such, or even a different proxy, as @yajo said.
It would also make it easier to introduce more complex changes in the future, even if they break something, because it would be easier to our users to pin a version and ensure it doesn't change, instead of always using the latest image and risking pulling a new image with "dangerous" changes.

Overall, I think it would be a nice improvement.

With respect to the process of doing it, and to what @JanoschDeurer said:

It is a feature that is directly supported by Dockerhub, if you don't want to build a CI/CD. On Dockerhub you can directly build the git tags as docker tags. If you want any input or help I'll gladly provide it :)

We plan to migrate to GHCR in parallel with Docker Hub (see #34) so I think it would be better to integrate it directly in the CI in this project.

[yajo]

OK, but then we should have some strategy regarding versions in code and images. Something like this:

• tecnativa/docker-socket-proxy:master deploying always latest commit.
• Other versions just following semver or PEP 440 versioning schemes. Both as git and as docker tags.
• Only produce packages when tagging.
• tecnativa/docker-socket-proxy:latest pointing to latest tag.
• Our versioning scheme will not be coupled with that of haproxy, alpine or whatever stuff we use beneath. However a major upgrade in some of those components can be considered a change big enough to bump a major version. It will depend on each release.

[kaysond]

it would be easier to our users to pin a version and ensure it doesn't change, instead of always using the latest image and risking pulling a new image with "dangerous" changes.

This is exactly it. It's really just about having easily readable Docker image tags, rather than versioning the underlying "software".

@yajo strategy goes above and beyond what I think is being requested, but if its practical, I think it is an even better way to go.

* Our versioning scheme will not be coupled with that of haproxy, alpine or whatever stuff we use beneath. However a major upgrade in some of those components can be considered a change big enough to bump a major version. It will depend on each release.

FWIW that is definitely what I would expect as far as versioning for the image.

[georglauterbach]

I'm using this container as a proxy for Traefik 2 too, and was surprised to not see versioned tags. Since I'm running a production workload, pinning a version is absolutely necessary. This is therefore missing critical for me. Thank you all for working on this:)

[joao-p-marques]

Thank you @aendeavor 😃
We ended up not implementing it yet in #34 but it is on the roadmap.
In the meantime, you can consider using the image hash to pin a specific version. For the ghcr image, you can check them here: https://github.com/orgs/Tecnativa/packages/container/package/docker-socket-proxy
It is not ideal, but should help you until we implement this 😃

[joao-p-marques]

Tagged images are added with #40

The structure will now be:

1. Each individual git released version will result in an image being tagged with the correspondent :{{version}}
2. :latest will refer to the latest released version in git.
3. :edge will be the version that is in the repo's master branch

[jwillmer]

@joao-p-marques would you mind adding this information in the readme so that i can see it in docker hub? Also is v0.1 the latest version of all v0.1.n tags?

[joao-p-marques]

@joao-p-marques would you mind adding this information in the readme so that i can see it in docker hub?

Thanks for the warning, here it is: #53

Also is v0.1 the latest version of all v0.1.n tags?

Yes, by SEMVER standards, that is the case 👍