Running the cdash container on a system where NGINX is already serving port 443

[bjornpiltz]

Is there a plan to support this use case? CDash isn't the only service running on my machine.

What I've tried

On the host system I have an /etc/nginx/conf.d/cdash.conf

server_name cdash.server.com;
ssl_certificate /etc/letsencrypt/live/cdash.server.com/fullchain.pem;
...
proxy_pass http://127.0.0.1:8080;

I set the following variables in .env

APP_URL=https://cdash.server.com
APP_KEY=...
SSL_CERTIFICATE_FILE=/etc/letsencrypt/live/cdash.server.com/fullchain.pem
SSL_CERTIFICATE_KEY_FILE=/etc/letsencrypt/live/cdash.server.com/privkey.pem

I adapted docker-compose.production.yml to map ports 8080:443 instead of 443:443

What I get

When I start the container with

docker compose --env-file .env \
           -f docker/docker-compose.yml \
           -f docker/docker-compose.production.yml \
           -f docker/docker-compose.postgres.yml \
            up -d

and try to access https://cdash.server.com I'm presented with an Apache error:

400 Bad Request

Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
Apache/2.4.57 (Debian) Server at localhost Port 80

[zackgalbreath]

I could be wrong, but I think this is because you're passing in docker-compose.dev.yml rather than docker-compose.production.yml. You could update the port mapping in that file to serve traffic over port 8443 rather than 443.

[bjornpiltz]

Sorry, that was a typo on my part. I've added the mapping 8080:443 to docker-compose.production.yml and started it with -f docker/docker-compose.production.yml.

[bjornpiltz]

I have now made numerous attempts at creating a production docker-compose.yml with persistent memory, but which does SSL/certification outside of the container, but failed. It would be nice if this mode was supported. Imho it even makes more sense (simpler and securer) for the host system to take care of certificates, but I guess there are reasons for the current design.

[zackgalbreath]

I agree. We ran into similar problems with TLS termination when we initially developed our production docker compose support, hence the "pass the SSL keys down into the container" approach we have now.

For what it's worth, we do have collaborators serving CDash behind an NGINX ingress in Kubernetes, so this approach does seem feasible (from a CDash standpoint, at least).

Perhaps we need to add a layer like haproxy to achieve TLS termination within our docker compose system.