-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added Windows variants for v2.6.0 #42
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Elton Stoneman <[email protected]>
What's up @sajayantony ? |
Signed-off-by: Elton Stoneman <[email protected]>
@friism do you know who can help review these? |
Bumped Windows versions, but this is still dependent on |
Sorry if this is the wrong place to raise these questions / concernes. Are there thoughts on how we can secure the .key file that we must mount into the container for SSL to work? If the registry service was compromised, we are worried that the private key could be stolen. On windows if you had to protect a certificate at rest (on disk) you would typically persist it as a passphrase protected pfx file. Otherwise it should be in the windows certificate store. However I am assuming that |
Status? I'd like to use an official image on Windows |
Any progress on this ? When will have offcial windows image ? |
This would close #26. |
I'm actively maintaining a Windows version at https://hub.docker.com/r/gesellix/registry/tags (based on https://github.com/docker-client/docker-registry/tree/main/registry-windows, which is based on #42), which should be useful for anyone. |
The major roadblock from the maintainers perspective is the lack of expertise in the space due to which we are not actively seeking to make this happen. |
Can you share details about the scope of the maintenance? We might try to reduce maintenance costs as much as possible. I understand if this won't have a chance to be supported right now, I'd like to see some minimal support, though. Naively speaking: what if the official image would only be enhanced with variants for the Windows-platform, but a note in the README could clearly state that the variant is provided for convenience only without further support? My use case is only for integration tests and not about running the Docker registry in production. Again, I totally understand if you currently cannot or don't want to support Windows variants, and maybe I don't know about some hidden maintenance costs. |
Well, our releases pack binaries https://github.com/distribution/distribution/releases which are then copied into the official image. So the release build would have to incorporate those there somehow and we dont have any way at the moment to do the win binary builds, though we havent revisited for a while. |
Would a Windows GitHub workflow runner suffice? I haven't checked if a cross-compile would work. I see two building blocks here:
Part 2. requires 1., but 1. could dynamically be built at Docker image creation time (this is my current approach). We would not provide any registry.exe, then. If you require a registry.exe beside the other release artifacts, I can have a look into the current release workflow and try to add a Windows build. Do you think that adding a binary release artifact and adding a Windows compatible Docker image to registry:3 is ok for maintenance? I'm willing to help. |
As I said, I havent had time to look into that properly. Try opening a PR in the main repo and we can maybe start a discussion |
Added Dockerfiles for building registry images running on Windows Nano Server and Windows Server Core. The binaries were built from v2.6.0 of
docker/distribution
using the local source for PR 2209.Sample images are on the Hub as sixeyed/registry. The Windows Dockerfiles are good to be built as official images with this PR.
The
update.sh
changes rebuild the Windows binary in the same way that the Linux binary is built. That depends on PR 2209 so it is for future releases.