Publish a Docker Image using Docker Hub

[Linuturk]

Based on my prior work in #1153, I'd like to close the loop on getting an official Docker Hub build setup for the project. I'm currently maintaining a separate image here, but we aren't automatically tracking versions as development continues in the main project. https://cloud.docker.com/repository/docker/linuturk/mono-choco/general

Based on a reported issue against my repo, it seems there is value for end users here. Linuturk/mono-choco#14

I'd be happy to setup some time with the project maintainers to help setup Docker Hub builds. Happy to have a phone or video call to assist.

[sbaerlocher]

I think it would be cool if there is an official Docker container image for chocolatey based on Linux that is actively maintained.

Maybe Chocolatey Community would be the right place for it. I could help keep it up to date, with version tags.

[TheCakeIsNaOH]

I also think this would be of value.

The image should probably have a signed version of choco. Therefore the image needs to either come from chocolatey themselves or a signed mono choco build needs to be made(#1002) which then can be used by the community to make docker images.

[TheCakeIsNaOH]

Todo list:

• Fix choco pack failing (#2076) Pack always truncate stream #2276
• Switch install location to /opt/chocolatey? Docker switch install location to /opt/chocolatey #2360
• Create mono build scripts for official and debug targets Add scripts for debug and official build targets #2358
• Make any changes required to the Linux dockerfile and wrapper script for official builds. Perhaps this will require two separate sets of files. (#2364) Rework Linux Dockerfile #2365
• Create a windows dockerfile Add a Windows Dockerfile #2366
• Fix chocolatey finding install location issues when on Mono (#2369 #2370) Do not trim forward slashs prefixes on Linux #2371
• Add a wrapper script for choco.exe? (#2364) Rework Linux Dockerfile #2365
• Metadata Dockerfile add metadata with LABEL #2361
• Fix uppercut so the official build configuration uses the official strongname key and has codesigning available.
  • Lets not require code signing at the minute, this would require several changes to the .uppercut build, and likely finding an alternative tool to do this on a Linux machine. Strong name signing is enough for now.
• Figure out what tag structure to use.
• Update documentation Document limitations when running on mono docs#260
• Private item

[gep13]

@TheCakeIsNaOH said...
Figure out what tag structure to use.

What were you thinking here? @JPRuskin did you have any input here?

[TheCakeIsNaOH]

What were you thinking here?

Some of these may have simple answers. I haven't uploaded any images to docker hub before, so I am not knowledgeable in this area.

• Is there a latest tag? Does it point to the latest stable release (e.g. 0.11.1)?
• Is there a beta tag, where does it point?
• Is there a nightly/ci/git/unstable/develop tag, if there are going to be development type builds made available?
• Is there going to be a 0.11 tag, pointing to the lastest 0.11.x release?
• How do the different architectures work for tagging? $version-win-amd64 and $version-linux-amd64? Use docker manifest to create a combined $version tag where it will download the correct image depending on what architecture you are running on?

https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/

https://mauridb.medium.com/docker-multi-architecture-images-365a44c26be6

[rfay]

It's not really best practice to use a latest tag, as they often aren't maintained and can often lead to unpredictable results. I recommend stable tags.

I would recommend "just get it to work and publish it with a specific tag". In the future, when the time comes for a bugfix or feature, publish a new tag.

[StefanScherer]

If you can provide the always newest as latest then it's fine, the quality of latest depends on each image provider. The latest tag is just the one that end users can omit that is implicitly used. I agree with @rfay that using latest on the end user side is not best practise, but very often the easiest to start with (eg. in docs / tutorial where you otherwise have to update the tag everytime). Of course it shouldn't point to nightly builds or other beta images.

If you provide stable tag instead then it's also fine.

A tag with the exact version of chocolatey would be useful, but don't know what you want to do when you rebuild the image again with a newer base image (mono) underneath. Overwrite the same tag? Or combine the two choco + mono version. It's hard for me to make suggestions here.

The mono:6.12 image is for Linux only, if you really want a multi-arch image then it's for eg. Apple M1 users :-) Use docker buildx instead of the docker manifest commands to have proper multi-arch manifest lists.
Building multi-arch/multi-os with a combo of Linux and Windows image is still a challenge, even with buildx. Put that out of the discussion right now. 😅

[TheCakeIsNaOH]

It's not really best practice to use a latest tag, as they often aren't maintained and can often lead to unpredictable results. I recommend stable tags.

As in a stable tag? Or as in stable, versioned tags? Or both?

A tag with the exact version of chocolatey would be useful, but don't know what you want to do when you rebuild the image again with a newer base image (mono) underneath. Overwrite the same tag? Or combine the two choco + mono version. It's hard for me to make suggestions here.

IMHO, the underlying mono version should only be updated with new versions of Chocolatey itself.

Building multi-arch/multi-os with a combo of Linux and Windows image is still a challenge, even with buildx. Put that out of the discussion right now. 😅

Both a a Windows image and a Linux image are wanted. Are you saying that the tooling is not currently up to the task of creating both Linux and Windows os images with a single image name? So there instead would need to be chocolatey/choco-win:tag and chocolatey/choco-linux:tag uploaded?

[rfay]

Windows images are unusual for things like this. But Linux image that run on Windows are fine. You say "A Windows image is wanted"... what does that mean?

[TheCakeIsNaOH]

You say "A Windows image is wanted"... what does that mean?

An image that launches a Windows container, not an image that launches a Linux container on Windows. That way, choco is (almost) fully functional.

Something like this:
https://github.com/chocolatey/choco/pull/2367/files#diff-1b3545ff53d9b36abe4874e69f40fa8eb19ed3a557781007d9b66adf92b2b503

[rfay]

OK. My use-case has always been building choco packages and pushing them using macOS or Linux. I'm not sure why somebody on Windows (the only place a Windows container can run) would necessarily need this.

[TheCakeIsNaOH]

OK. My use-case has always been building choco packages and pushing them using macOS or Linux

Same here.

I'm not sure why somebody on Windows (the only place a Windows container can run) would necessarily need this.

Validating that packages install without needing to spin up a full VM. Or running the package internalizer in a CI pipeline?

[StefanScherer]

Well, I did a demo at the Chocolatey fest 2018 how to use a choco base image to easily install eg. nodejs in a Windows container instead of all the manual steps 😄 Or to fully test a new choco package in a ephemeral environment. But I agree this only works for some non-gui tools.

But I just learned that choco pack and push could be run on Linux which is a good thing for CI, so yeah let's put that into a Linux image. 👍

[TheCakeIsNaOH]

After some discussion with @gep13, here is the plan:

• Have latest-windows and latest-linux tags pointing to the most recent images of the respective architectures.
• Have $version-windows and $version-linux tags pointing to the image with $version of choco.
• The version of mono used on the Linux images is not expected to change frequently, and if it does change, it would generally be changed between versions of choco, instead of rebuilding the previous choco version.
• Use docker manifest create to create a latest tag that points to latest-windows and latest-linux tags, so docker pull chocolatey/choco will just work on both linux and windows. And similarly create a $version manifest,

[gep13]

Doh! This one should have been the one in the release notes. Will close this as a duplicate of #2534