-
Notifications
You must be signed in to change notification settings - Fork 39.6k
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
Support attach #1521
Comments
This would actually require a number of features:
Interactive containers make it very easy to explore the container environment (e.g., explore the filesystem, print env vars, start the application manually), which is one of the features that makes Docker so accessible to users. As Kubernetes adds more functionality over raw Docker, it will become more important to provide a means for this exploration within the Kubernetes container environment (perhaps running a local cluster), rather than just expecting users to use raw Docker. This could also perhaps be done using ssh or exec, but achieving a similar experience might still require most of the above features. I think the main use case for non-interactive attachment (StdinOnce, no tty) is execution of containers on multiple inputs, where the user doesn't want to couple the container images to a particular storage system and/or where the data volume is small and using a distributed storage system (e.g., GCS, S3) or data repo (e.g., github, Docker registry) would be overkill (and likely slow). However, as with volumes, I could imagine eventually supporting multiple input sources, in addition to streaming via the API. Attach is not something we support internally, but is worthy of consideration for making the system more user-friendly and facilitating workflow/orchestration clients. |
Port forwarding has been implemented. |
Forked from #1503.
We should decide whether we will support Docker attach to stdin and stdout. It would be convenient for interactive containers and, more importantly, short-running, run-once data-in/data-out containers, such as for configuration generators, workflow steps, cron jobs, etc.
Support would likely be similar to that required to support run in container (aka docker exec) and/or ssh (#1513).
/cc @vishh
The text was updated successfully, but these errors were encountered: