Architecture:
* Router routes 80 and 443 to docker host
* Docker host has LetsEncrypt + nginx running with 80 + 443 exposed to the container
* Nginx config is routing everything from 80 to 443
* LetsEncrypt obtains certs that nginx uses to encapsulate the traffic that it proxies
* The apps (dockers) that are serving content on 80 (rerouted through docker ports)
So, in this config, the apps are hosting unencrypted content. But, that doesnt matter as nginx is handling the encryption. And while many dockers that support you providing them an ssl cert so they can do the encryption, it's not necessary as nginx is handling it.
Yes? No? Maybe?
This is called terminating SSL at the proxy and it’s a very common and perfectly acceptable practice as long as your network is secured against untrusted hosts joining. That would be open wifi access points, physical network ports accessible by untrusted parties, unsecured VPN/VNC/etc access on the WAN. Anything that would let a machine you don’t explicitly control join the LAN. As long as your internal network is secure, your proxied traffic is secure. And if you have a malicious host inside your LAN, your proxy traffic being sniffed is likely the least of your worries.
The setup you are talking about is actually quite common, and it’s generally called SSL termination – the SSL connection is established between the client and the reverse proxy/nginx, where it terminates, and the connection from nginx to the upstream servers (in your case services running in the containers) then can use plain old unencrypted HTTP. The advantage is you don’t have to configure SSL/TLS and obtain certificates on each service, but only once for nginx.