Docker 101: Publish All Exposed Ports on Random Host Ports to Avoid Port Conflicts
Can you get several builds of an app running side by side without port conflicts, so you can test them simultaneously?
Focused, hands-on DevOps and server-side problems with hints, feedback, and automated solution checks.
Can you get several builds of an app running side by side without port conflicts, so you can test them simultaneously?
A common setup for small deployments: two servers (VM or bare-metal), each with a public and a private IP. The app listens on the public port but wants to talk to Redis over the private network. Can you set it up?
Learn how to keep a database available to an app running on your workstation without exposing its port to other machines on the network.
A web app is listening inside a container, but the browser can't reach its IP address. Recreate the container so the app is available on port 80 of the Docker host.
A Deployment running a distroless Chainguard nginx image (cgr.dev/chainguard/nginx) is deployed in the namespace webapps, fronted by a ClusterIP Service. Port-forward that Service to localhost port 3333 on cplane-01, use curl to save the response body to /home/laborant/index.html, and verify the file is accessible and contains the expected content.
An inventory service lives inside a private VPC and keeps its debugging port bound to 127.0.0.1. Use SSH local port forwarding with a jump-only bastion to query the debugging port from your workstation.
Harden a bastion host so only admins can get a shell on it, operators can open tunnels to arbitrary destinations, and developers can reach only the one internal service they actually need.
A remote VM serves an app on port 80 and keeps an internal debugging port bound to 127.0.0.1. Reach the debugging port from your workstation using an SSH tunnel, without exposing it on the VM's external interface.
A production search cluster lives inside a private VPC and is reachable only from within it. Use SSH local port forwarding through a public-facing bastion host to query the cluster's API from your dev machine.
A payment webhook receiver runs as a local build on your dev machine, bound to 127.0.0.1 and invisible from the Internet. Use SSH remote port forwarding to publish it on a public-facing gateway VM so a test payment provider can reach it.