You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For several back-end stack/services, Java developers rely on launching local docker images. With WSL 2, accessing the open ports / running services on Windows host has become tedious.
Motivation
With WSL 1, when a running docker image exposes ports on Windows host, access via shell was seamless. With WSL 2, this requires explicit configurations. May be the need for tightening access controls took precedence here (probably due to WSL 2 architecture changes), but some simplification about accessing host ports from WSL 2 shells could be very useful in simplifying the development experience.
The text was updated successfully, but these errors were encountered:
@vishnuprasadc What build of Windows 10 are you running, and which distro? And which version of Docker?
Scenario?
Could I ask you to share a little more of what you're trying to achieve? What you're running, and where? For example, are you running a Java service hosted within a WSL instance, or within a Docker container running in WSL that you'd like to access from the Windows host?
Background
WSL1 exposes a POSIX compatible layer atop the NT kernel, upon which it runs distros and Linux binaries. because Linux and Windows share the same kernel, and thus networking stack, they were also able to access one anothers' ports etc.
WSL2 runs distros and Linux binaries in containers (one per distro) atop a real Linux kernel, all running in a lightweight VM. As such, WSL2 doesn't share/use any of NT's kernel infrastructure, and so WSL2 has to perform some non-trivial network traffic routing, etc. to marshal traffic between the Windows host and the WSL2 worker VM.
Summary
For several back-end stack/services, Java developers rely on launching local docker images. With WSL 2, accessing the open ports / running services on Windows host has become tedious.
Motivation
With WSL 1, when a running docker image exposes ports on Windows host, access via shell was seamless. With WSL 2, this requires explicit configurations. May be the need for tightening access controls took precedence here (probably due to WSL 2 architecture changes), but some simplification about accessing host ports from WSL 2 shells could be very useful in simplifying the development experience.
The text was updated successfully, but these errors were encountered: