I have a testenvironment for code in a docker image which I use by running bash in the container:
me#host$ docker run -ti myimage bash
Inside the container, I launch a program normally by saying
root#docker# ./myprogram
However, I want the process of myprogram to have a negative niceness (there are valid reasons for this). However:
root#docker# nice -n -7 ./myprogram
nice: cannot set niceness: Permission denied
Given that docker is run by the docker daemon which runs as root and I am root inside the container, why doesn't this work and how can force a negative niceness?
Note: The docker image is running debian/sid and the host is ubuntu/12.04.
Try adding
--privileged=true
to your run command.
[edit] privileged=true is the old method. Looks like
--cap-add=SYS_NICE
Should work as well.
You could also set the CPU priority of the whole container with -c for CPU shares.
Docker docs: http://docs.docker.com/reference/run/#runtime-constraints-on-cpu-and-memory
CGroups/cpu.shares docs: https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt
Related
I have a docker service/image I'm using which restarts as soon as starts.
I'm unable to fix the issue by getting into the container using
docker exec -it CONTAIER_NAME
since it restarts/terminates as soon as it boots.
Is there anyway I can pause it directly? I can't rebuild the image as I don't have access to the internet on the server. (Yes I'm sure the rebuild or build--no-cache will fix the issue)
The issue should be easily fixable if I modify permissions for a certain folder, but I'm not sure how to do this inside the container when I can't access it. The image doesn't have a docker file and is used directly from the docker hub.
If we do not get any information from the container's logs, we have the option to start the process "manually". For this, we start the container with an interactive terminal (-it, -i to keep STDIN open, -t to open a pseudo-TTY) and override the entrypoint to be a shell, e.g. bash. For good measure, we want the container to be removed when it terminates (i.e. when we exit the termainal, --rm):
docker run ... -it --rm --entrypoint /bin/bash
Once inside the container, we can start the process that would have normally started through the entrypoint from the container's terminal and extract error information from here.
I'm running openshift and it does not allow docker containers to run commands as root.
Is there a easy way to check if a custom docker image has commands run by root?
Are you sure this is correct, docker doesn't care what's going on within a VM, and root command would only be able to damage it's own VM.
That said you can open a shell on the image and do some checks
docker run -it gregclinker/boot-docker:1.0.3 /bin/sh
Then you could do:
ps -ef
to check any background processes running and so on.
I'm using Docker for Windows (Education Edition with Hyper-V) and am fairly new to Docker. My workflow feels a little bit complicated and I think there are better ways. Here's what I do:
When I develop with Docker containers, I add a Dockerfile to my project first.
Then I am going to build the container by running a command like docker build -t containername .
When Docker is done building, I am going to run the container with a command like docker run -p 8080:8080 containername (sometimes I add a volume at this point)
This runs the container and leaves my Powershell in a state where I can read debug messages and so on from the container.
Then I'm testing and developing the application.
Once I'm done developing and testing, I need to CTRL + C in order to exit the running container.
Now comes the tricky part: Say, I forgot something and want to test what I forgot to test right away. I would again run docker build -t containername . BUT docker would now tell me, that the port is already taken. So I continue like this:
I search for my container with this command: docker ps
Once I found the name (i.e. silly_walrusbeard) I type docker stop silly_walrusbeard. Now I can run docker build -t containername . again and the port is now free.
How could I simplify this workflow? Is there an alternative to CTRL+C that also stops the container? Thanks for your suggestions!
list all current containers with docker ps -a. Kill them with docker kill <ID> and maybe docker rm <ID>.
And when you run new containers use the --rm to free ports (among other things) automatically when the container stops:
docker run --rm -it containername
(I usually need the -it when running shells, but I'm not sure about powershell. Maybe you don't need it)
In practice to start a container I do:
docker run a8asd8f9asdf0
If thats the case, what does:
docker start
do?
In the manual it says
Start one or more stopped containers
This is a very important question and the answer is very simple, but fundamental:
Run: create a new container of an image, and execute the container. You can create N clones of the same image. The command is:
docker run IMAGE_ID and not docker run CONTAINER_ID
Start: Launch a container previously stopped. For example, if you had stopped a database with the command docker stop CONTAINER_ID, you can relaunch the same container with the command docker start CONTAINER_ID, and the data and settings will be the same.
run runs an image
start starts a container.
The docker run doc does mention:
The docker run command first creates a writeable container layer over the specified image, and then starts it using the specified command.
That is, docker run is equivalent to the API /containers/create then /containers/(id)/start.
You do not run an existing container, you docker exec to it (since docker 1.3).
You can restart an exited container.
Explanation with an example:
Consider you have a game (iso) image in your computer.
When you run (mount your image as a virtual drive), a virtual drive is created with all the game contents in the virtual drive and the game installation file is automatically launched. [Running your docker image - creating a container and then starting it.]
But when you stop (similar to docker stop) it, the virtual drive still exists but stopping all the processes. [As the container exists till it is not deleted]
And when you do start (similar to docker start), from the virtual drive the games files start its execution. [starting the existing container]
In this example - The game image is your Docker image and virtual drive is your container.
run command creates a container from the image and then starts the root process on this container. Running it with run --rm flag would save you the trouble of removing the useless dead container afterward and would allow you to ignore the existence of docker start and docker remove altogether.
run command does a few different things:
docker run --name dname image_name bash -c "whoami"
Creates a Container from the image. At this point container would have an id, might have a name if one is given, will show up in docker ps
Starts/executes the root process of the container. In the code above that would execute bash -c "whoami". If one runs docker run --name dname image_name without a command to execute container would go into stopped state immediately.
Once the root process is finished, the container is stopped. At this point, it is pretty much useless. One can not execute anything anymore or resurrect the container. There are basically 2 ways out of stopped state: remove the container or create a checkpoint (i.e. an image) out of stopped container to run something else. One has to run docker remove before launching container under the same name.
How to remove container once it is stopped automatically? Add an --rm flag to run command:
docker run --rm --name dname image_name bash -c "whoami"
How to execute multiple commands in a single container? By preventing that root process from dying. This can be done by running some useless command at start with --detached flag and then using "execute" to run actual commands:
docker run --rm -d --name dname image_name tail -f /dev/null
docker exec dname bash -c "whoami"
docker exec dname bash -c "echo 'Nnice'"
Why do we need docker stop then? To stop this lingering container that we launched in the previous snippet with the endless command tail -f /dev/null.
daniele3004's answer is already pretty good.
Just a quick and dirty formula for people like me who mixes up run and start from time to time:
docker run [...] = docker pull [...] + docker start [...]
It would have been wiser to name the command "new" instead of "run".
Run creates a container instance of an existing (or downloadable) image and starts it.
I have a docker image with all the necessary tools and environment properly set up. However, I am having a hard time running it in the background.
Seems like there are two approaches:
(1) can run the box as daemon and I can attach to it whenever I want to use the box. However, the container exit with code zero right after I run it as daemon.
$:~/docker/docker_scrapy$ sudo docker run -ti -v ~/docker/docker_scrapy/myvolume:/var/myvolume 3fb9894af1d9 /bin/bash
root#3fc39116a586:/# python -c 'from bs4 import BeautifulSoup'
root#3fc39116a586:/# cd /var/myvolume/
root#3fc39116a586:/var/myvolume#
$:~/docker/docker_scrapy$ sudo docker run -d -v ~/docker/docker_scrapy/myvolume:/var/myvolume 3fb9894af1d9
c5fab6e6ac02a579e3371aa641b18ca67feb93a9f4f4934b6d083157182fe4e1
$:~/docker/docker_scrapy$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Clearly, I can start the box in the interactive mode, but when I try to run it as a daemon, it will exit with code 0 right after I started. And I can not attach to it because I need to start it. Does that mean you can not run a image in the daemon mode if it is idle?
(2 )Or setting it up as a SSH server, and I can ssh in and do the work whenever I want. Like Vagrant up/ssh..
In summary:
(1) What did I do wrong with the detach/attach?
(2) Which is the proper way to have a run docker in the background? daemon/ssh
If you give it another command to run after starting the service that waits for input then the container will keep running until you attach and exit that command. I usually leave a shell running after the service starts so I can debug things. here's a simple example:
First let's create a service that runs in the background
arthur#a:~$ docker run -ti ubuntu bash
root#5dc7f330b947:/# cat <<'EOF' >start-service.sh
> while true
> do
> echo service is running >> service.log
> sleep 10
> done
> EOF
root#5dc7f330b947:/# chmod +x start-service.sh
root#5dc7f330b947:/# exit
arthur#a:~$ docker ps -l
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5dc7f330b947 ubuntu:12.04 bash 50 seconds ago Exited (0) 3 seconds ago jolly_nobel
arthur#a:~$ docker commit 5dc7f330b947 service/example
4c37b69b129287d79a6fe3916e4293f935194966b1de49d125f1cf8d6ab14f6f
then we can start it (i background it with a & here. in your example the & would not be required). Note it's fine to use both the interactive and detach options.
arthur#a:~$ docker run -ti -d service/example bash -c "./start-service.sh & bash"
b35a5397ea2d29b4085d93ef32270379b09e49118380b0376309bca74fd719d0
arthur#a:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b35a5397ea2d service/example:latest bash -c './start-ser 7 seconds ago Up 7 seconds cranky_wright
later we can attach and check on the service by looking in it's log file:
arthur#a:~$ docker attach b35a5397ea2d
root#b35a5397ea2d:/# cat service.log
service is running
service is running
service is running
root#b35a5397ea2d:/#
I don't recommend running sshd inside the container because it leaves an option for attackers that isn't strictly useful for me.
A lots of questions in there. I would firstly suggest you go through the docker tutorial to grasp some of the underlying concepts. That said...
That Dockerfile will never run in the background, that's not how docker works. There is no cmd, no entrypoint, nothing to run.
Docker by default runs one task, when that returns the container stops. So if all you wanted was a sshd you would run that as your CMD in non daemon mode. (sshd -D)
There are ways to run daemonized apps though:
Using supervisord, as documented on the docker site.
Another alternative is phusion/baseimage.
Phusion/baseimage provides ssh access, but honestly to do what I need in containers I find nsenter easier to use. Especially when paired with the phusion docker-bash tool.
Notice: this answer promotes a tool I've written.
First of all, conceptually running multiple processes in one container is not the right approach (https://docs.docker.com/articles/dockerfile_best-practices/). A more favorable solution is one that involves multiple containers each running their own process/service. Linking them together would result in a coherent application.
I've created a containerized SSH server that you can 'stick' to any running container. This way you can create compositions with every container, without that container even knowing about ssh. The only requirement is that the container has bash.
The following example would start an SSH server attached to a container with name 'sshd-web-server1'.
docker run -ti --name sshd-web-server1 -e CONTAINER=web-server1 -p 2222:22 \
-v /var/run/docker.sock:/var/run/docker.sock -v $(which docker):/usr/bin/docker \
jeroenpeeters/docker-ssh
You connect to the SSH server with your ssh client of choice, just as you normally would.
Be adviced: Docker-SSH is currently still under development, but it does work! Please let me know what you think
For more pointers and documentation see: https://github.com/jeroenpeeters/docker-ssh