docker
Add Compose CLI ECS documentation for redirecting 443 HTTPS traffic to any container port
What does this extra example show? How to forward HTTPS 443 traffic to a container's port 8080.
At first glance, this may look like a redundant documentation entry. After all, we just showed SSL termination right above this example. We're cluttering the docs! Let me directly address this:
- This literally took me 3 straight days to figure out how to do. I arrived at a custom 120 line CloudFormation yaml file before I realized I could do it this way.
- There is not a single mention of the
x-aws-protocolflag on this entire documentation page. This adds a very helpful use case. - The jump to overriding a network load balancer and learning the
x-aws-protocolflag, plus learning the correctx-aws-cloudformationoverlay, plus understanding the difference between all the load balancer sub objects (TargetGroup, Listener, LoadBalancer) and knowing which fields to override is non-trivial. - Many web frameworks actively discourage running your server on port 80. It requires root user (sudo) permissions to bind to port 80. You could even argue the port 80 example above this one is encouraging bad practices (see this Digital Ocean explanation https://www.digitalocean.com/community/tutorials/how-to-use-pm2-to-setup-a-node-js-production-environment-on-an-ubuntu-vps#give-safe-user-permission-to-use-port-80 ) Users, like me, who understand this and aren't looking to forward to port 80, have no other choice but doing a 3 day deep dive into the abyss of custom CloudFormation overlays.
Further examples that this is non-trivial:
I think forwarding HTTPS traffic to a non-privileged container 443:8080 is a VERY common use case, and well worth the extra example here in the docs.
Proposed changes
Accept this example into the documentation.
Related issues (optional)
https://github.com/docker/compose-cli/issues/693 https://github.com/docker/compose-cli/issues/1472
Deploy Preview for docsdocker ready!
| Name | Link |
|---|---|
| Latest commit | c692ed5204b00f0b6ffdf884a5d519b1ae87d8cc |
| Latest deploy log | https://app.netlify.com/sites/docsdocker/deploys/627d920f772cea00081c92a9 |
| Deploy Preview | https://deploy-preview-14739--docsdocker.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
@ndeloof Do you have any feedback on this PR or things making you hesitant to merge it in?
This is amazingly helpful, and I hope it gets merged in soon.
Quick note, for me I had to change the MyServiceTCP9999Listener to MyService9999Listener for some reason, to avoid getting an Every Resources object must contain a Type member error. Not sure when that gets triggered as my example was almost identical to the example in your PR.
Thanks for the pull request. We'd like to make our product docs better, but haven’t been able to review all the suggestions. As our docs have also diverged, we do not have the bandwidth to review and rebase old pull requests.
If the updates are still relevant, review our contribution guidelines and rebase your pull request against the latest version of the docs, then mark it as fresh with a /remove-lifecycle stale comment.
If not, this pull request will be closed in 30 days. This helps our maintainers focus on the active pull requests.
Prevent pull requests from auto-closing with a /lifecycle frozen comment.
/lifecycle stale
@thaJeztah Do you have someone else you could assign this PR to? It's now been sitting for 1 year without anyone looking at it. I'm happy to rebase and reopen as the example is incredibly helpful and we're currently using it in production, but I'm just not sure what another year of it sitting would accomplish.
I finally had some time and rebased and recreated this pull request here: https://github.com/docker/docs/pull/17178