Docker Community Forums

Share and learn in the Docker community.

"docker service create" background mode


(Scalincoln) #1

Is there a way to run “docker service create” with a detach option, similar to “docker run -d” ?

I’m trying to launch a ubuntu container with the latest docker rc release (1.12rc3); however, the container appears to exit upon launch. Here is the command I’m using to launch the container:

docker service create --name myubuntu ubuntu:14.04 /bin/bash

When I check on the service, this is what I see:

root@Endpoint01:~# docker service ls
ID            NAME      REPLICAS  IMAGE         COMMAND
ewx32l4xg1zx  myubuntu  0/1       ubuntu:14.04  /bin/bash

Is there a reason why the service is not running?


(John Harris) #2

docker service create runs detached by default. It is not running anything per se, just setting the desired state. You currently see 0/1 because to begin with the node has to pull the image. If you do docker service ls a couple mins later you should see 1/1 :slight_smile:


(Scalincoln) #3

Thanks for the feedback. I pulled the image prior to creating the service, so the image is local to the host. But just for grins, I relaunched it again and checked it an hour after. The REPLICAS status is still 0/1 and nothing shows up in docker ps. I’m still puzzled as to why docker service won’t run the service.


(John Harris) #4

Sorry, brain not working when I replied before. Your container is running them immediately exiting. /bin/bash isn’t doing anything and just returns, then your container dies. Then starts a new one, then immediately dies, etc…

Make sense?


(Scalincoln) #5

Yeah, that’s what I suspected. Is there a way to tell “docker service” to run /bin/bash in the background and not exit? I’m looking for something similar to this:

docker run -i -t -d ubuntu:14.04 /bin/bash

But for docker service.

My end goal is to use the 1.12 swarm orchestration feature to spin up a lot of ubuntu containers and run /bin/bash in the background. I suppose I can program my ubuntu container to run a continuous ping to keep the container from dying, but I’d like to avoid that if possible.

I know this is a bit odd. My container is not providing a service. Instead, I’m using it to simulate clients on a network.

Does this make sense?


(John Harris) #6

-it is basically attaching your terminal to the container input and giving you a TTY. You’re either doing that or not I guess (in this case, you’re not). You need to run something to keep the containers alive, otherwise they’re going to die.


(Scalincoln) #7

Is this case, I am trying to run something. That something is /bin/bash.
But I have no idea how to tell "docker service" to put that in the background.
I’m looking for a -d option for docker service. Is this possible?


(John Harris) #8

No that’s not possible. I’d suggest to run tail -f /dev/null as your command or something, to keep it alive.

Just running $ docker run -d ubuntu:14.04 /bin/bash doesn’t result in a running container. You’re essentially looking for the service equivalent of $ docker run -dit ubuntu:14.04 /bin/bash which doesn’t exist I don’t believe.


(Scalincoln) #9

Yeah, you’re right. I am looking for the service equivalent of $ docker run -dit ubuntu:14.04 /bin/bash


(Nathan Le Claire) #10

I don’t think services are meant to be run with TTY or interactive at all. You have to run some kind of persistent process. If you want interactive mode just use docker run.


(Scalincoln) #11

Yeah, I originally started with docker run, but I needed orchestration. This is why I looked into swarm. What is the easiest way to spin up a lot of containers in TTY and interactive mode?


(Nathan Le Claire) #12

Usually you don’t. What is your use case?


(Scalincoln) #13

I’m trying to use containers to simulate an end user client. This is mainly for testing purposes. For example, I want to load test my VPN server. I’ve pre installed a VPN client in my container and also configured it to automatically connect to my VPN server on startup. I’ve done this by updating the base ubuntu:14.04 container. Everything works great when I use the "docker run -itd" command. And I can manually launch multiple containers with no issues. I suppose I can write a script that just runs "docker run itd" multiple times, but I was hoping to avoid that with docker service. Ultimately, I need to run 1000s of these containers to do connectivity and load testing.


(Nathan Le Claire) #14

Why do you need it in interactive mode and with a TTY though (-it)?


(Scalincoln) #15

From time to time, I may need to login to the container and run additional tools. This is a nice to have. The main requirement is the background option (-d). My container doesn’t have an active process. The main process is the VPN client, which runs in the background.


(Nathan Le Claire) #16

If you want to attach to the container after the fact why not use docker exec -ti?


(Scalincoln) #17

Yes, I can connect to the container after the fact with exec -ti.
But I first need to run the container with the -itd option; otherwise, the container just runs and exits.

docker run -itd ubuntu:14.04 /bin/bash


(Nathan Le Claire) #18

You say this is your desired effect, but you’re invoking the bash process to start these containers? Why not invoke the client in the foreground directly, or through a script wrapper? e.g., nginx which traditionally would fork a daemon and run it in the background is usually configured to run in the foreground when invoked inside of a docker container. If the containers are not meant to be interactive there’s no need to run them in interactive mode.


(Ktwalrus) #19

Sounds like you don’t need the -it option on the docker run. You can always use docker exec -it container_name /bin/bash on any running container to execute interactive shell commands.

Seems like all you need is to have you container execute a CMD that doesn’t exit like

docker run -d --name test1 ubuntu:14.04 sleep infinity

and later

docker exec -it test1 bash

Note I gave the container the name test1 so I don’t have to do a docker ps to find the id/name of the container for the exec.

Or as @nathanleclaire just replied… make sure the commands you are running in your containers run one process in the foreground (like nginx) or the init script you are using runs the process in the background and then does sleep infinity to not exit the container until it is stopped.