Skip to content

Add documentation for redirecting 443 SSL traffic to any container port #17178

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

joshuakcockrell
Copy link
Contributor

This is a reopening of a 1 year old pull request: #14739 It was assigned to a maintainer but never got reviewed. I am reopening it because 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.

If you're questioning whether or not this is valuable, Here's a ~5000 word blog post someone wrote trying to accomplish the same thing in a VERY hacky way

Original PR

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-protocol flag on this entire page. This adds a very helpful use case.
  • The jump to overriding a network load balancer and learning the x-aws-protocol flag, plus learning the correct x-aws-cloudformation overlay, 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 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.

Proposed changes

Accept this example into the documentation.

Related issues (optional)

#14739

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-protocol` flag on this entire page. This adds a very helpful use case.
- The jump to overriding a network load balancer and learning the `x-aws-protocol` flag, plus learning the correct `x-aws-cloudformation` overlay, 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 )

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.
@netlify
Copy link

netlify bot commented Apr 25, 2023

Deploy Preview for docsdocker ready!

Name Link
🔨 Latest commit ab4da75
🔍 Latest deploy log https://app.netlify.com/sites/docsdocker/deploys/64474cf18322e20008985f08
😎 Deploy Preview https://deploy-preview-17178--docsdocker.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

@docker-robot
Copy link

docker-robot bot commented Jul 31, 2023

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

@joshuakcockrell
Copy link
Contributor Author

joshuakcockrell commented Aug 30, 2023

@ndeloof @thaJeztah @craig-osterhout
This got auto closed again. At this point I've been maintaining this issue through 15 months of rebases and still haven't received any feedback. It also hasn't been assigned to anyone.

Is there any feedback on what it would take to get this merged in? I'm happy to keep rebasing because we're currently using this SSL termination method in production (it's VERY helpful).

@ndeloof
Copy link
Contributor

ndeloof commented Aug 30, 2023

@joshuakcockrell ECS integration is deprecated, I don't expect we make any further improvement to the documentation

@joshuakcockrell
Copy link
Contributor Author

Sounds good thanks for letting me know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants