Comments (11)
I finished my prototype and when configured it works well for me. I published it in my autoForward
repo. Currently, I have the problem, that I can't start a detached process on the host running, which just using initializeCommand
, but maybe someone can give me a hind there. Furthermore, I have never packaged a feature, but I will hopefully figure that out.
It is pretty lightweight, especially compared to using VS Code for just auto-forwarding. Feedback is highly appreciated. Cheers
from cli.
@MunsMan Thank you for your efforts to actually implement this feature. This is the single feature that is preventing me from moving to devcontainers as a standard. Without this, using devcontainers without any specific tooling is simply impossible.
If I have some free time, I will try out your code.
from cli.
👍On this one. While you can use appPort
, this is currently only wired into the single container setup and is port publishing rather than full forwarding (e.g., if something only listens to localhost it won't work). While implementors can communicate with a server via text stream for devcontainer exec
, it's pretty common to need to communicate on a port instead. There's then user scenarios as well where this is very important.
from cli.
Any progress on this? It would help us a lot! 🤩
from cli.
I was thinking of dynamic port forwarding where we could start something along the lines of devcontainer port-forward --workspace-folder my_project
and that would forward the ports configured in the devcontainer.json (plus any that we might list in command line arguments).
E.g., we have implemented that in the Dev Containers extension for VS Code by locally listening on ports and forward any connections using docker exec
to run a little JavaScript snippet inside the container to connect to the target port there. The problem (and the reason we haven't included it in the dev container CLI) with this implementation is that it requires NodeJS inside the container. You could use socat
inside the container to achieve the same, but that would then require socat
to be available.
from cli.
@chrmarti your example was a helpful confirmation, I had to reverse engineer VS Code to get that inside.
I added 'static' forwarding via devontainer.json in this branch (https://github.com/MunsMan/devcontainercli/tree/port_forwarding), there it implemented via the Docker CLI and the publish option. Currently, socat
is not part of the default image to my knowledge, right? VS Code mounts it own node runtimes and server extensions, right?
For automatic forwarding, should it be a feature then? When we demand code in the container, it should be a feature. I was thinking if forwarding is possible by mounting sockets via volumes into the container, but I will build a prototype for myself first.
from cli.
I would love this feature and I would try to make an implementation draft, but I have a couple of questions.
-
To my knowledge, Docker only supports port forwarding configurations by startup. I couldn't find any command/interface to publish ports after initial start up. I found some ways to automatically publish all ports via host (unsafe) or via bridge (I guess VS Code implementation). Likewise, I propose we need a way to disable all forwarding, for untrusted environments. So, I'm thinking about these options:
- 'Static forwarding' via the published port from docker
- 'Automatic forwarding' via a network bridge
- 'Static and automatic forwarding' by combining both options
- 'No forwarding' for security or personal preference.
-
GitHub Codespaces. If there is support for Codespaces planned, is forwarding to the actual host enough? Further forwarding should be done by external software, right?
from cli.
I built a prototype for automatic forwarding ports via a UNIX Socket (I had the assumption that WSL should support that), but even macOS didn't support sharing UNIX Sockets via a volume. The macOS support will not come in the near future (docker/for-mac#483).
I build the Prototype in Rust and build images for the corresponding container, which then can directly be mounted. For Linux to Container or Container to Container, I had a Response Time which was 50 Times faster than the one of VS Code.
Due to the missing support for Unix Sockets on the other platforms, I'm considering using one static Port and Multiplexing all the other ports through it. A small program needs to run in the Container, scan for new ports and forward all traffic though the port. I would build the program in Rust, and then the CLI would need to pull the container corresponding binary and mount it into the container. The execution can be started via the postCreateCommand
. On the Host, an Application would Demultiplex the Traffic and manage the listening ports.
Any Feedback on that approach?
from cli.
For anyone interested in this topic, I have implemented the desired functionality using a Python script called devcontainer-cli-port-forwarder. This solution is based on @chrmarti's suggestion to utilize socat
for port forwarding. To make it work, simply add the following two lines to your devcontainer.json
file, and you should be all set.
"onCreateCommand": "sudo apt update && sudo apt install -y socat",
"initializeCommand": "python3 .devcontainer/devcontainer-cli-port-forwarder/forwarder.py &"
I was thinking of dynamic port forwarding where we could start something along the lines of
devcontainer port-forward --workspace-folder my_project
and that would forward the ports configured in the devcontainer.json (plus any that we might list in command line arguments).E.g., we have implemented that in the Dev Containers extension for VS Code by locally listening on ports and forward any connections using
docker exec
to run a little JavaScript snippet inside the container to connect to the target port there. The problem (and the reason we haven't included it in the dev container CLI) with this implementation is that it requires NodeJS inside the container. You could usesocat
inside the container to achieve the same, but that would then requiresocat
to be available.
from cli.
Until forwardPorts support is complete, how about treating forwardPorts as an alias for addPort?
It would require some workaround (e.g., add server process option --host 0.0.0.0
), but I think we can achieve the connection to the container.
I think this behavior is effective when using an already existing devcontainer.json
.
from cli.
@chrmarti Can you please share ETA for this issue?
from cli.
Related Issues (20)
- project-name changed after updating 0.56 -> 0.60 HOT 10
- obtuse and confusing error with local feature under WSL HOT 4
- Feature Request: Allow devcontainer up to Start Only the Specified Service and Its Dependencies HOT 4
- Adding labels to containers build by devcontainer cli HOT 5
- `compose.yaml` `name` breaks when using vars `${VAR}` HOT 3
- Forward docker credentials from docker cred helper HOT 1
- Add option to get the info on running containers HOT 2
- Apply --remove-existing-container before initializeCommand
- Error when devcontainer up HOT 2
- Push in quay.io/buildah/stable HOT 3
- 2244 HOT 2
- Consistently getting: command failed: {0} Exit code 1 Start: Run in container: test -f '/var/devcontainer/.patchEtcProfileMarker' HOT 1
- `runArgs` in Dev Containers image isn't shared to `.devcontainers.json` workspace HOT 3
- Option --omit-config-remote-env-from-metadata is not documented HOT 2
- Devcontainer over ssh hanging forever when wsl2 vm has freezed. HOT 2
- OpenTelemetry tracing HOT 2
- Issues executing binary inside container with devcontainer exec HOT 5
- devcontainer up not working with podman and docker-compose file HOT 5
- when using dockerComposeFile prebuilds are ignored
- X11 works with container launched via VSCode but not launched via devcontainers/cli
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cli.