Start detached container

[cloudlena]

I would like to create a whalebrew package for mongod which starts MongoDB as a daemon. I think it would be awesome if I could just run mongodb and whalebrew would start my MongoDB in a detached Docker container. As far as I can tell, all we need for that is a Docker image called whalebrew/mongod from the following Dockerfile:

FROM mongo

EXPOSE 27017

CMD mongod

And a new config label for whalebrew called io.whalebrew.config.detach which would set the -d flag when running the container. What do you guys think?

[bfirsh]

Thanks for the suggestion! What's the advantage of this method over using existing tools like nohup?

[cloudlena]

That I wouldn't have to install MongoDB and could have it run in a container instead of on my local machine. I would develop my apps locally against this MongoDB and as soon as I'm done, just stop and remove the container.

I'm already doing this already but currently I start the container with docker run -d -p "27017:27017" mongo. For this command, I would like to use whalebrew instead. Then I could just run mongod and that would spin up a container with MongoDB running inside.

[themalkolm]

Inception! Maybe simply run it in bg then?

$ mongo &

[cloudlena]

My goal is not to be able to run something in the background... mongod already does that by default. My goal is to run something in a docker container...

[themalkolm]

No, I meant the idea of whalebrew is to treat docker containers as native commands. The naive way to run native commands in bg is & :)

Maybe whalebrew should have --docker-args somewhere (in package definition?) so such things could be easily hacked on package level without requiring to fix the binary right away.

[cloudlena]

Thanks for your feedback, @themalkolm! Since we already have some docker args covered through the labels that you can give your image (e.g. io.whalebrew.config.environment for the -e flag or io.whalebrew.config.ports for the -p flag), wouldn't it be more consequent to provide a io.whalebrew.config.detach label for the -d flag as described above? In that way, the developer of the specific whalebrew image could easily set whether their image should run as detached or not.

[nithin-bose]

So if we do make whalebrew to run a detached command, how do you then kill/stop that container?

[themalkolm]

Yep, this is the problem with detached containers I see. Now you suddenly break out of this abstraction and need to know that it is actually a docker container.

[cloudlena]

good point... you would really need to run docker stop...

[themalkolm]

This is why I suggested to simply run this cmd in bg so whenever it is killed it will stop the container automatically. But I think this is so error prone to random containers floating around.

[bfirsh]

Yup, it's a leaky abstraction, but I think commands by default always running in the background is even worse, because you have no idea it is running in the background, as @themalkolm says.

To solve that I suppose if it starts something in detached mode, it could say something like "Starting mongo in the background. Use Docker commands to manage it."

If you run mongo &, it is explicit that you're running something in the background. Both ps and docker ps will work to see it is running, which is pretty neat.

[LongLiveCHIEF]

I can image there would also be advantages to being able to use the docker DNS'ing to connect to whalebrew'd containers using container names.

[billinghamj]

Effectively isn't the ideal to be able to have your brew services running inside docker containers? So e.g. my local redis, postgres, mongo, elasticsearch etc can all be running off cleanly separated docker containers?