Skip to content
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

Closed
bgrant0607 opened this issue Oct 1, 2014 · 3 comments
Closed

Support attach #1521

bgrant0607 opened this issue Oct 1, 2014 · 3 comments

Comments

@bgrant0607
Copy link
Member

@bgrant0607 bgrant0607 commented Oct 1, 2014

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

@bgrant0607
Copy link
Member Author

@bgrant0607 bgrant0607 commented Oct 8, 2014

This would actually require a number of features:

  • Configuration of stdin. The Docker remote API includes AttachStdin, OpenStdin, and StdinOnce. The latter would be useful for command execution, such as configuration generators. Currently, we don't open stdin on containers.
  • Possibly request for a tty. Currently, we don't allow one to be requested. Useful for interactive containers.
  • API for waiting for a pod to be scheduled. (Presumably based on the new Event API.)
  • API for tunneling stdin/stdout/stderr. Docker's attach API hijacks the HTTP connection for this.
  • Client integration of all of the above.

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.

@bgrant0607
Copy link
Member Author

@bgrant0607 bgrant0607 commented Jul 21, 2015

Port forwarding has been implemented.

@bgrant0607 bgrant0607 closed this Jul 21, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.