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?
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.
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.
A status dashboard runs on an isolated device in your home network, with no inbound route from the Internet. Use SSH remote port forwarding with your workstation as a jump host to publish it on a public-facing gateway VM.
Several self-hosted services run on isolated devices in your home network, with no inbound route from the Internet. Use SSH dynamic remote port forwarding to turn a public-facing gateway VM into a single SOCKS proxy that reaches all of them.
Several internal microservices live inside a private VPC and are reachable only from within it. Use SSH dynamic local port forwarding to turn your dev machine into a single SOCKS proxy that reaches all of them through one bastion host.
Prove your networking skills by setting up an improvised proxy server with netcat.