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

				haproxy-letsencrypt-docker.md
			
          @@ -176,3 +176,47 @@ What's going on here?

           5. Always redirect to https.

           6. 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).

           7. Other traffic is matched by request hostname to their respective containers. Your routing will probably be more complicated than this, but it's a start.

          +

          +Let's wrap this up in docker-compose...

          +

          +## docker-compose.yml

          +In your current directory (so next to the 'haproxy' dir you created above), put this is `docker-compose.yml`:

          +

          +```yaml

          +version: '3'

          +

          +services:

          +  haproxy:

          +    container_name: haproxy

          +    image: haproxy:latest

          +    restart: always

          +    volumes:

          +      - ./haproxy/bind:/usr/local/etc/haproxy:ro,Z

          +      - letsencrypt_etc:/etc/letsencrypt

          +    networks:

          +      - haproxy

          +    ports:

          +      - 80:8080

          +      - 443:8443

          +    user: '1001'

          +    

          +volumes:

          +  letsencrypt_etc:

          +    

          +networks:

          +  haproxy:

          +```

          +Here we have:

          +1. The container_name is 'haproxy'. We'll be referring to this container name later on for sending signals when certs are renewed.

          +2. The 'haproxy/bind' dir is mounted at /usr/local/etc/haproxy, so the haproxy.cfg file we created is in the right place for haproxy to read it. Mounted read-only, and with the 'Z' selinux flag (I'm running RedHat-ish host OSes here, so it's required - leave off the ',Z' if docker complains).

          +3. The letsencrypt volume is mounted at /etc/letsencrypt so haproxy can read the cert file

          +4. We're creating a user-defined network called 'haproxy' so we an talk to other containers

          +5. The high port numbers are mapped down to the usual 80/443

          +6. We're setting a non-priv UID to run as. Because [containers don't need to run as root](https://medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b)

          +

          +## Go!

          +Run that bad boy with `docker-compose up`. You should see some startup messages and hopefully no errors. haproxy might complain about the backends being down, but that's OK for now.

          +

          +Test port 443 from the docker host with:

          +`openssl s_client -connect localhost:443 | openssl x509 -text`

          +and you should see your cert if all has gone well.

...	...	@@ -176,3 +176,47 @@ What's going on here?
176	176	5. Always redirect to https.
177	177	6. 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).
178	178	7. Other traffic is matched by request hostname to their respective containers. Your routing will probably be more complicated than this, but it's a start.
	179	+
	180	+Let's wrap this up in docker-compose...
	181	+
	182	+## docker-compose.yml
	183	+In your current directory (so next to the 'haproxy' dir you created above), put this is `docker-compose.yml`:
	184	+
	185	+```yaml
	186	+version: '3'
	187	+
	188	+services:
	189	+ haproxy:
	190	+ container_name: haproxy
	191	+ image: haproxy:latest
	192	+ restart: always
	193	+ volumes:
	194	+ - ./haproxy/bind:/usr/local/etc/haproxy:ro,Z
	195	+ - letsencrypt_etc:/etc/letsencrypt
	196	+ networks:
	197	+ - haproxy
	198	+ ports:
	199	+ - 80:8080
	200	+ - 443:8443
	201	+ user: '1001'
	202	+
	203	+volumes:
	204	+ letsencrypt_etc:
	205	+
	206	+networks:
	207	+ haproxy:
	208	+```
	209	+Here we have:
	210	+1. The container_name is 'haproxy'. We'll be referring to this container name later on for sending signals when certs are renewed.
	211	+2. The 'haproxy/bind' dir is mounted at /usr/local/etc/haproxy, so the haproxy.cfg file we created is in the right place for haproxy to read it. Mounted read-only, and with the 'Z' selinux flag (I'm running RedHat-ish host OSes here, so it's required - leave off the ',Z' if docker complains).
	212	+3. The letsencrypt volume is mounted at /etc/letsencrypt so haproxy can read the cert file
	213	+4. We're creating a user-defined network called 'haproxy' so we an talk to other containers
	214	+5. The high port numbers are mapped down to the usual 80/443
	215	+6. We're setting a non-priv UID to run as. Because [containers don't need to run as root](https://medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b)
	216	+
	217	+## Go!
	218	+Run that bad boy with `docker-compose up`. You should see some startup messages and hopefully no errors. haproxy might complain about the backends being down, but that's OK for now.
	219	+
	220	+Test port 443 from the docker host with:
	221	+`openssl s_client -connect localhost:443 \| openssl x509 -text`
	222	+and you should see your cert if all has gone well.