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
Labels
area/api Indicates an issue on api area. area/app-lifecycle area/usability kind/design Categorizes issue or PR as related to design. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery.

Comments

@bgrant0607
Copy link
Member

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 bgrant0607 added kind/design Categorizes issue or PR as related to design. area/api Indicates an issue on api area. labels Oct 1, 2014
@bgrant0607 bgrant0607 added this to the v0.9 milestone Oct 4, 2014
@bgrant0607
Copy link
Member Author

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 bgrant0607 modified the milestones: v1.0, v0.9 Oct 10, 2014
@bgrant0607 bgrant0607 added the priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. label Dec 3, 2014
@bgrant0607 bgrant0607 removed this from the v1.0 milestone Dec 3, 2014
@bgrant0607 bgrant0607 changed the title Question: Decide whether to support attach Support attach Dec 10, 2014
@bgrant0607 bgrant0607 added the sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. label Feb 28, 2015
@bgrant0607
Copy link
Member Author

Port forwarding has been implemented.

@davidopp
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Indicates an issue on api area. area/app-lifecycle area/usability kind/design Categorizes issue or PR as related to design. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery.
Projects
None yet
Development

No branches or pull requests

2 participants