This looks good, maybe it needs to be a touch clearer that it's only for the docker driver in hcl files, as you can have different drivers and also json spec

Indeed good point

Just want to mention, docker is not the only driver for container related workloads, there is also a podman driver.
Also authentication against a private container registry would be awesome.

Just want to mention, docker is not the only driver for container related workloads, there is also a podman driver. Also authentication against a private container registry would be awesome.

@allroundtechie usually this is left to the caller of updatecli, typically in ci what i do is have a login step (for docker registries, npm, cargo, ...) then call updatecli

@loispostula Good point, thanks. I basically forgot how I was doing it with the docker-compose autodiscovery which I use at another project and a private registry and you are right, I also did this like you mentioned (within a CI pipeline step). This really says a lot about this tool, setup and forget, just works :-)

The way I see authentication today:

• Rely on the default docker configuration (usually my preferred approach)
• Specify credentials in the autodiscovery plugin, I must admit I never use this
• Not supported yet, but we could also load information from nomad configuration as explained here

The way I see authentication today:

• Rely on the default docker configuration (usually my preferred approach)
• Specify credentials in the autodiscovery plugin, I must admit I never use this
• Not supported yet, but we could also load information from nomad configuration as explained here

Just my two cents:
I do not know what the majority of updatecli users do or how they use updatecli, I personally use it within CI pipelines only. That said you do not want to have credentials or other security related stuff in clear text in config files or in this case hcl/nomad files for authentication.
I struggled with this myself when deploying nomad job via a CI pipeline and do a replacement of "dummy" credentials in the nomad/hcl file with the real credentials form the vault or secrets store e.g.

sed -i 's|REGISTRY_USERNAME|'${{ env.USERNAME }}'|g' service.hcl
sed -i 's|REGISTRY_PASSWORD|'${{ env.TOKEN_PACKAGE_READ }}'|g' service.hcl

So from a security point of view the last option @olblak mentioned is at least in context of CI pipelines actually a no go. But of course this could makes sense for other people who do not use CI pipelines.
Basically @loispostula mentioning the docker login setup in the CI pipeline is all which is needed.

@allroundtechie back when I was using nomad, but I do use it for my k3s clusters, I actually set up containerd with authenticated mirrors on the hosts and don't even bother with credentials in the job definitions

Thanks for the feedback, I agree with you.

Updatecli is mostly used from a CI environment and rely on environment variables.
Updatecli could also load credentials from SOPS files, but I never heard anyone using this approach and I stopped using SOPS a long time ago 🤷🏾

Basically @loispostula mentioning the docker login setup in the CI pipeline is all which is needed.
That's all I use as well

So I guess the PR is ready in the current state and we could always improve it after