Docker Community Forums

Share and learn in the Docker community.

Docker + Cockpit + SSL Cert Automation


Use case:

  • Fedora with Cockpit
  • Docker with Nextcloud (1 domain) and a LEMP-stack (1 domain), reverse proxy (Nginx Proxy Manager).

I started learning Docker from scratch a couple of days ago. Setting this up with LEMP in separate containers, as a kind of good practice, has been a real challenge.

The thing is:
I run Cockpit and Nextcloud on the same domain and would like to utilize the same cert that the Nginx Proxy Manager generates for the nextcloud container.

  1. I have dismantled the cert-volume and made it a mount.
  2. I moved the necessary files to the Cockpit cert folders.
  3. Everything works great.

However, the certs are bound to expire, and I want to automate the process like so:

I know I can trigger a cp and chmod, but that would start from the container, and this is where the problem begins.

The renewal-hook will be executed in the container, but how do I cp the files to the general OS? Do I mount the Cockpit cert folders? Where in the container? Bad practice if possible?

Another solution would be to run a separate lets encrypt/certbot instance in the OS, but since 80/443 needs to be accessible and they are on the same domain, I guess it’s no option. Alternatively I could get a separate domain for cockpit and run let’s encrypt separately there, but I prefer not to if I can make the container trigger to write into the Cockpit cert folder on renewal somehow. But ultimately I guess the container won’t be able to restart the cockpit service anyway.

Another general question I have is if I can map same_domain:ports to different containers with the reverse proxy. I know I can use subdomains, but ports? Maybe naive question, but I imagine I could do it with open ports otherwise.

Typicaly you will want to have a reverse proxy that takes care of the creation/update of the letsencrypt certificates and termination of TLS-Traffic. The reverse proxy container must share at least one network with the target containers to foward traffic to them via http.

You might want to take a look at Traefik. It allows to definde the reverse proxy rules as labels on the target container regardless wgether you aim for subdomain or context path based proxy rules. It can also take care of creating and updating the letsencrypt certificate.

It’s just that cockpit is for the general OS and not containerized . Maybe traefik has an option to route to the real localhost and what not, but I went for a solution with VPN. I think it’s good because it disables public access to management , even if Ive had such a solution before. The only issue is that it wants certs when browsing locally then , but that I can accept without proper sign I think.

From inside a container, you can communicate with host ports via host-ip or the ip of the docker0 interface or the ip of the docker_gwbridge interface.

Traefik allows to set static configuration for “external” services as well.

Its up to you, if you use NPM directly on the host and forward traffic to Cockpit and/or the published ports of your containers, or complety do the oposite, run Traefik/NPM in a container and forward traffic to other containers using service names, and the ip’s I mentioned above to forward traffic to Cockpit.