Changes in d4c0538: Updated haproxy-letsencrypt-docker.md

				haproxy-letsencrypt-docker.md
			
          @@ -188,6 +188,7 @@ What's going on here then?

           * The global section logs everything to stdout, because that's what you do with docker. [rule 6](/rules#6-thou-shalt-respect-the-sanctity-of-stdout) does not apply in dockerland.

           * We're setting the Mozilla recommended ciphers and DH values. Check the [current recommendations](https://mozilla.github.io/server-side-tls/ssl-config-generator/) if you're foolish enough to go into production with this stuff.

           * We're using 'resolvers' and 'default-server init-addr none' to get around the problem of containers not being up at haproxy startup time. Docker with user-defined networks always puts a resolver at 127.0.0.11:53, and haproxy can use that to resolve container names at *runtime* instead of *startup* time.

          +* We're *not* running 'check' on the letsencrypt backend - it will be down most of the time, and we don't care.

           * We're binding to port 8080 and 8443, and setting the cert to the Let's Encrypt cert we dumped out in the previous section. The ports will be mapped back to 80 and 443 by docker later on.

           * Always redirect to https.

           * All traffic that matches the certbot [ACME](https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html) challenge protocol is directed to our letsencrypt container (to be created later).

...	...	@@ -188,6 +188,7 @@ What's going on here then?
188	188	* The global section logs everything to stdout, because that's what you do with docker. [rule 6](/rules#6-thou-shalt-respect-the-sanctity-of-stdout) does not apply in dockerland.
189	189	* We're setting the Mozilla recommended ciphers and DH values. Check the [current recommendations](https://mozilla.github.io/server-side-tls/ssl-config-generator/) if you're foolish enough to go into production with this stuff.
190	190	* We're using 'resolvers' and 'default-server init-addr none' to get around the problem of containers not being up at haproxy startup time. Docker with user-defined networks always puts a resolver at 127.0.0.11:53, and haproxy can use that to resolve container names at runtime instead of startup time.
	191	+* We're not running 'check' on the letsencrypt backend - it will be down most of the time, and we don't care.
191	192	* We're binding to port 8080 and 8443, and setting the cert to the Let's Encrypt cert we dumped out in the previous section. The ports will be mapped back to 80 and 443 by docker later on.
192	193	* Always redirect to https.
193	194	* All traffic that matches the certbot [ACME](https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html) challenge protocol is directed to our letsencrypt container (to be created later).