Docker for Windows

[grahamehorner]

Please consider creating an official docker RabbitMQ for Windows image using Windows Server Core;

As a group of developers we use docker to create a local development environment; sharing images with others so the 'works on my machine' is a thing of the past; at present we use a number of images including including asp.net, redis, ms-sql-server, documentdb etc

[tianon]

There are installers available for Windows (https://www.rabbitmq.com/install-windows.html), so I'm not opposed, but configuration is going to be tricky. On Linux, we use an entrypoint script which sets up the configuration and then execs rabbitmq-server (so the server itself is the only thing left resident). On Windows, that pattern is not possible (due to architectural limitations).

For images like MongoDB, we've "solved" that by making the Windows images strictly bring-your-own for configuration, initialization, etc. If an approach like that is acceptable here, then we should definitely play around with making this happen! (and possibly whether it can work in Nano Server too)

[grahamehorner]

I think having RabbitMQ running in docker on window server core and/or nanoserver would be a great for the inner developer loop; at present I've not been able to see how/if this could be installed given the packaged installer, this may have to be a manual install process of RabbitMQ as opposed to the provide package installers? IMHO bring you own configuration for would be an acceptable starting point.

[grahamehorner]

FYI, found this spring2/rabbitmq

[reecebradley]

it'd still be good if there was a rabbitmq that is under the official channel.

[michaelklishin]

@tianon IMO "bring your own configuration" is a valid approach for any OS.

There are binary releases for Windows distributed by our team as well, I'm not qualified to say which one is more suitable for the current state of provisioning and automation tooling on Windows.

[AceHack]

I created a docker nanoserver-insider image, it's very basic and need work to really be production ready. Not to mention it needs nanoserver-insider right now because erlang does not work on the current version of nanoserver. The same dockerfile would work as well for windowsservercore.

rabbitmq-nanoserver-insider.zip

[AceHack]

Also if the architectural limitations you speak of are not having bash then you could use windows server core insider and still run your bash script for windows because it can support bash now :)

https://msdn.microsoft.com/en-us/commandline/wsl/install-on-server

[KencyK]

Are there any plans of having rabbitMQ for windows? We were getting the below error:
rabbitmq_ppn_engine | {"Cookie file /var/lib/rabbitmq/.erlang.cookie must be accessible by owner only",[{auth,init_cookie,0,[{file,"auth.erl"},{line,286}]},{auth,init,1,[{file,"auth.erl"},{line,140}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]}

[tianon]

@KencyK my comment from above still applies... #168 (comment)

We're not opposed to the idea, since it does seem to be something upstream actively supports, but the nature of native Windows containers makes the usage of such a creation less intuitive.

[luigiberrettini]

Here is a working Dockerfile that can be a good start.

At the moment Nano Server images have to deal with Erlang issue 477.

I really prefer not to create an unofficial image: can I contribute/help in some way?

[Bhaal22]

Rmq Windows based on multi stage builds to startt from windowsservercore to get powershell feature and then switch to nanoservercore:1709

Need to update to 1803.

https://blog.drylm.org/posts/rabbitmq_windows_container.html

@luigiberrettini the issue you mention is not valid anymore since 1709.

[luigiberrettini]

The solution you published on your blog and referenced both on the Erlang issue and here is sort of a hack otherwise you could have used a single stage build based on microsoft/nanoserver:1709 (I tried it and it did not work)

That's the reason why the Erlang issue is still open

Anyway it is a better approach than using Windows Server core because it reduces image size

[Bhaal22]

Not so sure.
As far as I remember I had it working on my first tries with 1709 when I did make experiments with the zip in my git repo and adding the zip via the dockerfile.

I only use multi stage builds to have powershell to download and run msiexec stuff.

[luigiberrettini]

If you look at the Dockerfile I referenced above and try to do the same with 1709 and PowerShell Core as I did it won't work
This is not due to downloading or copying files, but to the Erlang installer that, even if called with the proper flags (not to use UI), executes without doing nothing

[Bhaal22]

The referenced issue is not related to run erlang installer. The attached docker file already use a multi stage build.
The referenced issue is related to erlang runtime failing.

Unable to load emulator DLL
(c:\erlang\erts-9.0\bin\beam.smp.dll)
Unable to load emulator DLL
(c:\erlang\erts-9.0\bin\beam.smp.dll)

Indeed the installer does not run as-is in the nanoserver:1709 container
Probably related to some c++ runtime missing.

[luigiberrettini]

Before installing Erlang, it could be helpful to install Microsoft Visual C++ Redistributable for Visual Studio 2017 with vc_redist.x64.exe /install /quiet /norestart or vc_redist.x64.exe /install /passive /norestart

Unfortunately MSI is not supported on Nano Server

[grahamehorner]

@luigiberrettini MSI isn't supported for good reasons; as the packages have calls to APIs that are part of the UI layer and given the large majority of security issues related to the UI layers, the aim for nano server was be as secure and small as possible, some but not all MSIs follow the /quiet /passive rules and still try to access UI api; thank fully vc_redist isn't one of them ;) and good spot btw as I've been battling with an issue where VC libraries where missing and was getting odd messages (unrelated) but your tip made the penny drop :D

[yosifkit]

Multistage builds are not supported for Official Images: docker-library/official-images#3383.

[Bhaal22]

Indeed. w/o multi stage, nanoserver:{1709,1803} cannot be really supported, no Powershell.
Official Erlang-OTP releases are only nullsoft exes for windows.

[luigiberrettini]

I do not understand why there is this focus on PowerShell:

• there are bigger problems than that, like being able to install common programs, since almost none support the new WSA installer format
• Nano Server has PowerShell Core and I was able to use it to create the RabbitMQ image if it wasn't for the Erlang installer unable to work

[Bhaal22]

Yes indeed. That's not totally correct.

the nanoservercore container instance has no tools other than batch-tools (cd, file, type, xcopy, ...) support.
Even the batch-tools distribution looks incomplete. I noticed the timeout command is missing for some reasons. And of course, all UI related libs are missing + msiexec.

So basically, with batch-tools only, you dont have such a tools like:

• curl / Invoke-WebRequest
• unzip / Extract-Archive
• and maybe other tools which could be handy during the build phase of an image.

That's why maybe I mentionned too much PowerShell.

[luigiberrettini]

You are right, now I remember that I used the PowerShell Core image:
microsoft/powershell:nanoserver

This is perfectly doable without having a multistage build, but the Erlang installation problem still exist

[Bhaal22]

yes indeed. i did not had a look at the powershell core image yet.
the solution would be that erlang team releases archive of erlang-otp instead of installers ...

[luigiberrettini]

Being a "Linux program" probably the installer does not do more than unpacking and setting something in the path... even if it sets registry keys, this could be done via shell

[Bhaal22]

Indeed. I am pretty sure this is definitely overkill to have such an installer.
Will have a look at the nullsoft installer definition. Should not be too hard to understand.

[luigiberrettini]

Here is it

It seems that it is strongly tied to having a UI experience, but luckily this mostly means writing a lot of values in the registry (install folder, shell extension and so on)

[Bhaal22]

yeah and indeed useless stuff.
I am not sure in erlang codebase they do care about registry keys.

[luigiberrettini]

Opened ERL-635 please vote it

[kavhad]

The following link to a Dockerfile can build an image running rabbitmq on nanoserver

https://github.com/sixeyed/dockerfiles-windows/blob/master/rabbitmq/nanoserver/sac2016-ignore/Dockerfile

It in itself depends on the following image which is using multistage build to install erlang on windows servercore but then copy resulting files into an nanoserver image

https://github.com/sixeyed/dockerfiles-windows/blob/master/erlang/nanoserver/sac2016/Dockerfile

[luigiberrettini]

I hope the Erlang team will start putting some effort also on Windows related issues instead of simply deprioritizing them and flagging as up-for-grabs or help wanted: it would be great to build and run RabbitMQ with a single stage build on microsoft/nanoserver

I just discovered that 7-Zip can unpack NSIS files
Tests should be performed to see if it is possible to install Erlang performing these steps:

• download 7-Zip
• extract it
• use the command line 7z.exe to unpack the Erlang installer
• copy the extracted content to the Erlang instalation folder
• install vcredist_x64.exe
• run Install.exe

[xied75]

As I have already commented there in the https://bugs.erlang.org/browse/ERL-477
Erlang should be simply offered as a zip, the-Installer-mental-state is really some legacy thinking...

[tianon]

I've done a little bit of testing with this, and was able to get something preliminary running with the following Dockerfile. A few issues:

• not sure how to get RABBITMQ_DATA_DIR to take properly
• doing docker run IMG rabbitmq-server doesn't work, but if I run powershell instead it starts up
• Ctrl+C gets captured by cmd (since rabbitmq-server is really a batch file, so it's capturing the signal and prompts for terminating the batch job instead of Erlang doing the right thing)
• the Erlang layer is almost 400MB, so there's obviously a lot of things in there that are going to be ripe for removal
• the Erlang installer is a standard NSIS installer, so it's possible we could "extract" it instead of installing it, but that's probably splitting hairs (IMO the installer is OK, we just need to clean a few things out when we're done installing to slim it down)

FROM mcr.microsoft.com/windows/servercore:1803

# $ProgressPreference: https://github.com/PowerShell/PowerShell/issues/2138#issuecomment-251261324
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]

ENV RABBITMQ_HOME C:\RabbitMQ

# PATH isn't actually set in the Docker image, so we have to set it from within the container
RUN $newPath = ('C:\erl\bin;{0}\sbin;{1}' -f $env:RABBITMQ_HOME, $env:PATH); \
	Write-Host ('Updating PATH: {0}' -f $newPath); \
	setx /M PATH $newPath
# doing this first to share cache across versions more aggressively

# no minor updates for Windows -- infeasible to rebuild from source
ENV OTP_VERSION 21.2

# pulling from erlang-solutions.com instead of erlang.org because it's a lot faster download and includes https
RUN $url = 'https://packages.erlang-solutions.com/erlang/esl-erlang/FLAVOUR_1_general/esl-erlang_{0}~windows_amd64.exe' -f $env:OTP_VERSION; \
	Write-Host ('Downloading {0} ...' -f $url); \
	Invoke-WebRequest -Uri $url -OutFile otp-setup.exe; \
	\
	Write-Host 'Installing ...'; \
	Start-Process otp-setup.exe -Wait \
		-ArgumentList @( \
# https://nsis.sourceforge.io/Which_command_line_parameters_can_be_used_to_configure_installers
			'/S', \
			'/D=C:\erl' \
		); \
	\
	Write-Host 'Removing ...'; \
	Remove-Item otp-setup.exe -Force; \
	\
	Write-Host 'Validating ...'; \
	Start-Process erl -NoNewWindow -Wait \
		-ArgumentList @( \
			'-version' \
		); \
	\
	Write-Host 'Complete.'

ENV RABBITMQ_VERSION 3.7.10

# https://www.rabbitmq.com/install-windows-manual.html
RUN $url = 'https://github.com/rabbitmq/rabbitmq-server/releases/download/v{0}/rabbitmq-server-windows-{0}.zip' -f $env:RABBITMQ_VERSION; \
	Write-Host ('Downloading {0} ...' -f $url); \
	[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; \
	Invoke-WebRequest -Uri $url -OutFile rabbit.zip; \
	\
	Write-Host 'Expanding ...'; \
	Expand-Archive -Path rabbit.zip -DestinationPath C:\; \
	\
	Write-Host 'Renaming ...'; \
	Move-Item -LiteralPath ('rabbitmq_server-{0}' -f $env:RABBITMQ_VERSION) -Destination $env:RABBITMQ_HOME; \
	\
	Write-Host 'Removing ...'; \
	Remove-Item rabbit.zip -Force; \
	\
# TODO verification
	\
	Write-Host 'Complete.'

# send all logs to TTY
ENV RABBITMQ_LOGS=- RABBITMQ_SASL_LOGS=-

# TODO RABBITMQ_DATA_DIR

# TODO CMD ["rabbitmq-server"]
CMD ["powershell"]

[ericjmooney]

Based on tianon's work above (which is great, btw, thank you so much) was able to get rabbit running with CMD directive like this:

CMD "cmd /k rabbitmq-server.bat"

[johnkwaters]

Wow - here I am a noob to Docker ... setting up some microservices - several dotnet 5 APIs, IdentityServer, a few mongodb... all on Windows containers. Then I spend 2 days trying to get rabbitmq to work in docker. Little did I realize that isn't supported! Didn't even know it wasn't until I stumble across this. Should I process or just try to get it all running on Linux/WSL instead?

[ericjmooney]

@johnkwaters If you are able, running on Linux-based containers is going to make your life a heck of a lot easier IMHO

[johnkwaters]

I hear you @ericjmooney ! I just switched - trying to iron out all the kinks, but seems way faster.

[tianon]

Coming back to this, I wonder how many of the limitations I noted in #168 (comment) are things we can actually reasonably overcome vs insurmountable. 🙈

To put that another way: I realize lots of folks want a Windows-based RabbitMQ container image, but I'm not sure it really makes sense as part of what's maintained in this repository given that it will not be a comfortable or more importantly a well-supported experience. 🤔 😞

For example, not having a clean way to docker stop the container gracefully sounds like a pretty big showstopper.

[lukebakken]

At some point I plan on migrating all of the scripts we use to manage RabbitMQ on Windows to Powershell, which will fix the docker stop issue.

But, I fail to see the benefit to a Windows-based RabbitMQ docker image. What would that provide to someone developing on Windows that the Linux-based one does not?

[TBBle]

But, I fail to see the benefit to a Windows-based RabbitMQ docker image. What would that provide to someone developing on Windows that the Linux-based one does not?

The ability to run it in combination with other Windows-only containers without messing about with multiple Docker (or other runtime) instances or exploiting oddities in Docker Desktop for Windows's implementation.

Outside development, running Linux-based containers on Windows Server in production is a non-supported setup, so you'd need to fire up a Linux VM to host the RabbitMQ container on a Linux container runtime.

And all of the above workarounds are non-starters if you're trying to include a RabbitMQ instance in the same k8s Pod (or similar shared sandbox setup) as some Windows-only container, as such shared container sandboxes share the same platform/kernel.

[lukebakken]

Thanks @TBBle, that is very informative.