Hoping someone can confirm my current understanding:
When an https request hits aptible’s nginx proxy… ssl will be terminated there and then proxy_pass’ed to our container using HTTP (not HTTPS), but still on port 443, right? So, does our container need to listen on 443, but for raw HTTP traffic not for SSL traffic?
I think the HTTP request on port 80 is being sent to our container as HTTP on port 80, which is redirecting the request to the same server, but as HTTPS on port 443… then aptible’s nginx server is getting the request, terminating it and then passing it on as http to our container on port 443. Seems like we need to listen for HTTP (not HTTPS) on port 443, which is a little goofy, but can be done. Seem correct?
Correct: HTTPS is terminated at our nginx proxy, but the request is then passed to the app container on whatever port is exposed from the app container’s Docker image. So it may be that your Docker image is exposing 443.
If more than one port is exposed by your docker image, we choose the first port (sorted lexicographically, not numerically, which is just an artifact of how Docker lists the ports).
So if your image has 80 and 443 exposed, “443” < “80” so we’ll try to send traffic to 443.
@colby, is it possible to have more than one port opened for a single container? For example we have an application that has both a web presence and a web-socket service endpoint that requires a separate non-standard port be available (for chat). Any recommendations?
We’ve gotten around the restriction by applying a reverse proxy to redirect traffic to different ports internally. That said, if we had gone with a different solution, let’s say standing up the web-socket server on a different container we would have failed the “HTTP Health Check” (discovered this in debugging), because it processes WS requests, not HTTP requests. What if we want a docker container that doesn’t handle HTTP requests? Seems like an artificial constraint…