Initial commit of Windows containers

[stellirin]

This patch allows us to build a PostgreSQL Windows container that matches the functionality of the Linux container image.

The Dockerfile uses the BigSQL distribution of PostgeSQL. I saw previous efforts that build a minimal 'proof of concept' image based on the EnterpriseDB distribution, but I was unable to launch this distribution on version 1803 of the windows/nanoserver base image, even with the VC Redistributable installed.

The docker-entrypoint.md maintains the functionality of its Linux counterpart, including the file_env function for selecting Environment variables, and the ability to automatically execute SQL and 'shell' scripts on first run.

Integration with Travis is not yet included, as I am unfamiliar with this tool (help will be required) but I understand it is possible to automate the build of the Windows images too.

Closes #324

[tianon]

The included docker-entrypoint.cmd is an absolute work of art -- it's both terrifying and amazing that you've managed to get all that to work.

The main issue we'll have with it (and truly the reason we don't have any entrypoint wrapper scripts on any Windows official images yet) is that Windows doesn't have the Unix concept of exec. With a Linux shell script entrypoint, we can end with exec, and once it invokes the intended command (postgres, mysqld, mongo, etc), the shell is gone completely, replaced by the target process. One very direct effect of this is that signals sent to the container are passed directly to the application, as intended, and it's very difficult to replicate that behavior with cmd or even PowerShell (if it's even possible to really replicate that properly at all).

Another issue we'll have is docker-library/official-images#3383 -- namely, no support for multi-stage builds in the official images. IMO, striving for Nano Server is an interesting goal, but not necessary to achieve a functional and useful image.

I'm also not entirely sold on BigSQL -- the official Windows download page (https://www.postgresql.org/download/windows/) relegates it to second-class, and describes it as including much more than a standard PostgreSQL install ("a graphical component manager" among other things), which doesn't make sense in the context of a Docker image, and especially doesn't make sense in the context of a minimal-size Nano Server-based image.

The combination of these factors are why #324 is still open and why the PoC there uses EnterpriseDB based on Windows Server Core.

[stellirin]

The included docker-entrypoint.cmd is an absolute work of art -- it's both terrifying and amazing that you've managed to get all that to work.

Thanks!

The main issue we'll have with it (and truly the reason we don't have any entrypoint wrapper scripts on any Windows official images yet) is that Windows doesn't have the Unix concept of exec. With a Linux shell script entrypoint, we can end with exec, and once it invokes the intended command (postgres, mysqld, mongo, etc), the shell is gone completely, replaced by the target process. One very direct effect of this is that signals sent to the container are passed directly to the application, as intended, and it's very difficult to replicate that behavior with cmd or even PowerShell (if it's even possible to really replicate that properly at all).

Hmm, I overlooked this since I was focusing on the main functionality of the script. I assume you refer to when Docker needs sends a SIGTERM or similar to the container. At my company we use entrypoint scripts but instead of using exec we catch the signals to run a shutdown script. Perhaps I can find some similar functionality for Batch scripts. Are there other uses for sending signals directly to the postgres executable?

Another issue we'll have is docker-library/official-images#3383 -- namely, no support for multi-stage builds in the official images. IMO, striving for Nano Server is an interesting goal, but not necessary to achieve a functional and useful image.

I was not aware of this, which is a pity since 500mb images are way better than 5gb images... but I can rework into a single flow. Probably I'd keep the cmd for now in case Docker Hub enables multistage builds, unless it proves impossible to catch signals in Batch scripts.

I'm also not entirely sold on BigSQL -- the official Windows download page (https://www.postgresql.org/download/windows/) relegates it to second-class, and describes it as including much more than a standard PostgreSQL install ("a graphical component manager" among other things), which doesn't make sense in the context of a Docker image, and especially doesn't make sense in the context of a minimal-size Nano Server-based image.

As far as I am aware (from what I learnt when building this image), the GUI referred to is little more than the batch script that is used to download the releases. It is used in this image because it is used to automate the download of the PostgreSQL files as well as the dependencies (Python etc). I did consider removing it from the final nanoserver image but in the end chose to keep the copy process simple.

However if the EnterpriseDB distribution is considered the 'canonical' Windows distribution, I will take another look. The main reason I abandoned it is because I could not get its VC Redistributable to work correctly on the latest nanoserver 1803. The BigSQL is self contained in that respect.

[stellirin]

Three points as motivation for this update:

• I saw some time ago that the BigSQL distribution disappeared, so I refactored to use the EnterpriseDB distribution.
• I saw your comment on Add multi-stage build support official-images#3383 that multi-stage builds are finally under development.
• I was pleasantly surprised to notice recently that I have over 2k pulls on Docker Hub, so there appears to be some demand for these!

I'm not so deep into the Docker for Windows community as you may be, but are you aware of any progress since last year regarding the 'exec' problem?

[ta32]

https://hub.docker.com/r/kiazhi/nanoserver.postgresql
this repo uses window server nano as the base image, is it possible to use this as a base image over server-core which is very large image? @stellirin

[tianon]

That image appears to be quite dated (based on the older Nano Server images that still contained powershell).

[ta32]

ok i see, I would have to use https://hub.docker.com/_/microsoft-powershell lts-nanoserver-1809
I guess nano-server is for simple containers where you just copy some binary in there an run it?

[stellirin]

@ta32 My image was a perfect development tool, but as was mentioned in the initial review there's no easy way to exec or catch SIGTERM in a Windows batch script so it is not suitable for production. At least that was the case 2 years ago when I recreated the entrypoint script.

What could work is a simple init binary that could handle the container lifecycle, but I have no idea if such a thing exists already for Windows, and I've since changed jobs where I don't even use Windows anymore.

To have parity with the latest version of the entrypoint script, you'd most likely want to use PowerShell. I exhausted my creativity replicating the original entrypoint script in batch, I couldn't find the motivation to try and replicate the new script that uses functions!