Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
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).
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.