☰

Update haproxy-letsencrypt-docker.md

David Stark committed 2020-05-23 20:01:55 +0100 commit 7560f5bbb5ccbc20abd2adbbfbd32c3498754129

				compute/haproxy-letsencrypt-docker.md
			
          @@ -183,7 +183,7 @@ backend domain2

           ```

           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.

          +* 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 mental 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.

...	...	@@ -183,7 +183,7 @@ backend domain2
183	183	```
184	184
185	185	What's going on here then?
186		-* 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.
	186	+* 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.
187	187	* 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 mental enough to go into production with this stuff.
188	188	* 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.
189	189	* We're not running 'check' on the letsencrypt backend - it will be down most of the time, and we don't care.