Make start and restart accept commands, along with -i and -t options

[ndarilek]

I would like to create an image that installs a database, with its CMD set to the command that runs said database.

Next, I'd like to restart the container based on said image, only this time I'd like to run a shell, or the database administrative tool, and manipulate the data in the database.

While "run" lets me specify a command, along with the -i and -t options needed to start the command in the foreground and make it accept input, I cannot start or restart a container with the same constraints. Additionally, I can't specify a different command when restarting a container.

This could be a partial solution for #1351. If I can create a container, then spin up a shell in that same container, I can run administrative tools associated with an app. Ideally #1351 wouldn't be fully discounted, but I wouldn't feel its lack nearly as acutely as I do because I can't spin up a container with a different command to modify its contents.

[creack]

At the moment, containers or single-process units. You can't do this with docker in its current state.
This feature will be available in Docker 1.0 as we will support multi-process by container.

In the meantime, If you really must, you can use lxc-attach to inject a shell within the running container.

[ndarilek]

Thanks for the workaround, but I'm confused. Assuming a stopped
container, why can't I start it and simply replace the CMD/ENTRYPOINT on
just that run?

docker run -i -t base /bin/bash
$ exit
docker start -i -t /usr/bin/tcsh

[creack]

Because right now, a container is defined by its process. If you change the process, you change container. If you want to start a new process, you have to use 'run'.
Run is a wrapper around 'create', 'start' and 'attach'. When 'create' is called, the container is created with all its metadata which are used by 'start'. 'start' does the AUFS mount and simply execute what the container is supposed to do.

[cpb]

Is it necessary to do the administration of the database inside the container? Would it make sense to connect to the database in the container as though it were a remote database

[ndarilek]

If you're talking about a database with a remote administration tool,
sure, but that's a very limited set of things. If you're talking about
something like http://prosody.im whose default datastore uses files, or
a container with a static website which you just want to launch a shell
in and tweak, or half a dozen other use cases I can think up off the top
of my head, then that model falls down.

And one of the things I like about containers is that, if my container
server doesn't need a database, then I don't need to install one. It
sounds like what's being suggested is that I have to keep every app I
may want to administer installed on the server so I can run their
administrative tools against the containers that contain them and the
data...and again, that's just the limited use case of interfacing with
apps which export their data for remote modification.

[cpb]

default datastore uses files

Try the Dockerfile instruction ADD

or a container with a static website which you just want to launch a shell
in and tweak

I think this is missing some of the opportunities Docker is providing. Doesn't the incremental snapshots of AUFS reduce how long it takes to make tweaks to a Dockerfile? I'd rather update a git reference and rebuild and relaunch.

that model falls down.

You're right, it doesn't always "make sense to connect to the database in the container" with a remote administration tool.

It sounds like what's being suggested is that I have to keep every app I may want to administer installed on the server

I do not represent dotcloud or docker, and I hope you do not take my questions as advice. I am learning about docker and am wanting to learn more about its use cases.

[ndarilek]

default datastore uses files

Try the Dockerfile instruction ADD
http://docs.docker.io/en/latest/use/builder/#add

I'd rather not keep my usernames/passwords/account details outside of
the container for a variety of reasons, so ADD isn't applicable.
Additionally, this wouldn't support changes made by the app itself,
running in the container.

or a container with a static website which you just want to launch
a shell
in and tweak

I think this is missing some of the opportunities Docker is providing.
Doesn't the incremental snapshots of AUFS reduce how long it takes to
make tweaks to a Dockerfile? I'd rather update a git reference and
rebuild and relaunch.

That's one possibility. I think there are a variety of workflows
that could reasonably be supported. Maybe I feel that keeping a
version of my site in HG *and* in Docker is overkill, and I'd
rather treat Docker as a place to toss in HTML and be sure it'll
be served up in a manner independent of what is installed on the host.

I do not represent dotcloud or docker, and I hope you do not take my
questions as advice. I am learning about docker and am wanting to
learn more about its use cases.

They're valid points, and I appreciate their being raised. I just feel
that defining a container in terms of its process, and making that an
immutable property of containers, is a limiting design choice. Just
today I went into /var/lib/docker/containers//rw/var/log/mysql/error.log, not to mention a variety of additional
log files. Could this have been piped to STDOUT? Sure, but I'm
manipulating a whole bunch of daemons on a lower level than I'm used to,
and it isn't immediately easy or obvious how to get some logging on
STDOUT...and that's just the log use case. If I can't restart a stopped
container with a new command, even if only temporarily, to investigate
or administer its data, I'm going to run up against some fairly
substantial limitations every day--that, or I'll have to just suck it up
and spin up an SSHD in every container, which seems a bit wasteful.

[shykes]

In a future version of docker we will introduce a docker exec command, which will allow injecting arbitrary processes into existing containers. docker start will rely on docker exec under the hood. That should solve the problem described here.

I'm going to close this issue since it suggests a slightly different solution (changing the behavior of docker start).

[tianon]

Sorry, on my phone right now or I'd check myself; do we already have a FIXME in the code for adding this separate exec primitive?

[tobegit3hub]

@shykes Is the docker exec available now? Really looking forward to it.

[crosbymichael]

Not yet, we are still finishing up the final changes for docker exec

[thewilli]

I'm not sure why this was closed. Even though docker exec is already available, it would be really great to temporarily change the command of a stopped container instead of having to commit it into a new image. While exec allows to work on running containers, it won't help if the init process of the container need to be bypassed (e.g. while it crashes). Or is there another way to start a stopped container with another command?

[alethenorio]

I am not sure why this was closed as "docker exec" does not solve the main issue here.

There can be a host of different reasons an existing container may not come up with the default entrypoint/CMD command, therefore no running container exists to run "docker exec".
There are also situations where even though the container may stay up after started, the default entrypoint/CMD may prevent subsequent commands commands using "docker exec", to fix whatever might be wrong with it, to work.

This means that right now the only way to fix a broken container in these situations is simply to delete the container and start a new one with "docker run", not the ideal sittuation.

Personally it would be nice to be able to override the entrypoint/CMD of an existing docker container with "docker start" (or at least CMD if anything).

[duglin]

@ByteFlinger one option is to make the main process (as denoted by the CMD/ENTRYPOINT) be a, sort of, dummy process (e.g. just sleep forever) and then use "docker exec" to start up any additional process you want. Granted you're not specifying the process on the "docker start" but I think you'll end up with the same net result.

[alethenorio]

But after you have created the container and it won't come up for whatever reason so that as soon as it comes up it goes down again, how will you change main process?
If I underatand what you mean, it implies adding the possibility of being able to trigger such a sleep in every single docker image just to be able to do that in the case of such an issue. Sounds totally counter productive and unnecessary.

[duglin]

you're right that its a totally different flow and way to work. And you need to make that kind of choice up-front, its not the kind of thing you can change once you've create an image/container with a CMD that runs something real. I was just looking for options given today's design.

[ghost]

If you want to start a new process, you have to use 'run'.

No, "run" starts a new container, with a new filesystem and different data to the existing container. If you want to start a command to do something with data in an existing container, you are plain out of luck, if for some reason you cant start it.

And dont say "oooh containers should be ephemeral and not contain any meaningful data above the base image" - if that was the case then --rm would be the default, and there would be no concept of "stopped" containers, they would just be blown away when they stop, because after all, the cannot contain anything useful. If they do contain something useful, then we should be able to interact with them in whatever way we want.

This is a ridiculous and pointless limitation to Docker, than has no justification whatsoever.

[clayg]

Brand new to the Docker toolset today, having lots of experience with virtualization and some with process isolation via cgroups, chroot and other systems - finally had a side project where I thought the dockerdockerdocker hype would make sense and I end up here after a matter of hours.

At this stage it's quite possible for me (if ridiculously annoying) to either rm the container, and run a new one with a different --entrypoint - or to just start it and exec a different process into it - but my brain keeps desperately reaching for a way to to change the COMMAND and start -ia.

The workflow gap makes no sense from the the outside - I think I'd really have to know something about how the initial command is injected into the container fs/metadata during build for this to be a defensible behavior at all. Totally awkward to use.

[ashw7n]

This would be a good addition to have, useful for running containerized CLI tools, without having to create different docker instances for every run.

[cjbottaro]

+1

In the same boat as @clayg.

[laktak]

This is a ridiculous and pointless limitation to Docker, than has no justification whatsoever.

+1

[2rs2ts]

This is a ridiculous and pointless limitation to Docker, than has no justification whatsoever.

+1

[duglin]

FYI: #19746

[tetherit]

+1

[pimterry]

Useful workaround, for the case where you want to shell into a container and examine the contents, but it's running a command that crashes immediately (or you don't want to rerun for some reason):

docker commit CONTAINERID my-broken-container
docker run -it my-broken-container /bin/bash

Saves the current state, starts it up interactively and doesn't run its normal start command, so you can happily take a look around. You can --entrypoint too if it's your entrypoint that's crashing.

[codepushr]

+1

[sigboe]

+1

Useful workaround

That's only useful for a broken container where you want to permanently change the command. Not useful for the dozens of other reasons to temporarily or run once with another command. 😢

[hihell]

@pimterry this is very helpful, but does it means if there is a bug preventing a container from start, the only solution is commit a new version and ditch the old one?

[pimterry]

@hihell I'm not sure exactly what you mean, but I think the answer is generally yes: if you have a broken unstartable container, you're going to have to build a new one. Doing so on top as here though means that you don't lose any of the existing state when you 'ditch' it - there's no downside to this.

This is really just for debugging runtime issues though - containers are disposable, and you shouldn't be depending on their state persisting long-term. If you have anything important in the container, it should live in a volume, so its lifetime can be separated from the container. Once you've worked out the actual bug, the 'right' thing to do generally is to ditch the container completely, create a brand new image that includs your bugfix, and start up a new container from scratch.

[hihell]

@pimterry great, thank you!