* dtr-rethinkdb now houses the rethinkcli which means we no longer need
to pull the rethinkcli container from hub.
Signed-off-by: Kyle Squizzato <kyle.squizzato@docker.com>
I have a custom build hook to pass in build arguments on a repository from which I build two Docker images (tags), from two Dockerfiles.
My second build, however, with the custom Dockerfile, was not being built correctly. It was being built with the default `Dockerfile`, instead of my specified custom one.
I quickly figured out the custom build hook was to blame because it doesn't specify which Dockerfile it should build from, but there was no mention in the documentation of an environmental variable I can consume to get the custom "Dockerfile location" value. By dumping the env vars during the build process, I can there is an environmental variable with that value: `DOCKERFILE_PATH`.
This PR updates the documentation accordingly, to:
1) Expose the fact this environmental variable exists, and explains its purpose
2) Make sure its consumed in the example custom build hook, so any copy-pasters find themselves already supporting custom Dockerfiles, rather than struggling with the same problem
Restore Docker install docs for Windows Server to their original form using DockerMsftProvider for consistency with Microsoft docs. DockerProvider will be used for Insider/Preview builds only.
* HRM and Window Servers
Note:- Windows Server doesn't support Swarm Mode Routing Mesh yet (not considering Windows Server version 1709 which will be out soon). This means the hrm service is exposed only through the manager node's ip (since Windows Server cannot be a manager node). Therefore the DNS entry for the host name ('wordpress.example.org' in this example) should be mapped to the manager node and not to any of the Windows worker nodes.
* HRM with Windows Server
HRM with Windows Server