I'm trying to use docker command inside container.
i use this command to mount /var/run/docker.sock and run container
docker run -d --name gitlab-runner --restart always \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /srv/gitlab-runner/config:/etc/gitlab-runner \
gitlab/gitlab-runner:latest
but when i try to use docker inside container(gitlab-runner) i get an error
docker: not found
host:
srw-rw---- 1 root docker 0 Mar 23 15:13 docker.sock
container:
0 srw-rw---- 1 root gitlab-runner 0 Mar 23 15:13 docker.sock
this worked fine, before i removed old container and created new one, and now i'm unable to run docker inside container. Please help.
You should differentiate between docker daemon and docker CLI. First one is a service, which actually performs all work - builds and runs containers. The second one is an executable, used to send commands to daemon.
Executable (docker CLI) is lightweight and uses /var/run/docker.sock to access daemon (by default, there are different transports actually).
When you start your container with -v /var/run/docker.sock:/var/run/docker.sock you actually share your host's docker daemon to docker CLI in container. Thus, you still need to install docker CLI inside container to make use of Docker, but you dont need to setup daemon inside (which is pretty complicated and requires priviledged mode).
Conclusion
Install docker CLI inside container, share socket and enjoy. But upon using host's docker daemon, you will probably be confused with bind mounting volumes because daemon doesn't see the container's internal file system.
Related
We want to do some testing on envoy, and we have a Docker container pulled from DockerHub envoyproxy/envoy running under Docker. However if one opens a CLI into the container there is no file called envoy, and if we look at a browser for http://localhost:443 nothing happens. Is envoy actually running in the container? ps shows the only running processes are bash and the ps command. So how do you test an envoy config file in the container, for example html.yaml?
We can run envoy standalone with a config file, but that is not the environment we will be using.
The Envoy Documentation is very long and very thorough, but to us at least this isn't clear.
You can easily test Envoy inside a Docker container by running:
docker run --name envoy \
-p 443:443 \
-v $PWD/html.yaml:/etc/envoy/envoy.yaml \
envoyproxy/envoy:v1.21.1
You must bind mount your config into /etc/envoy/envoy.yaml in the container.
Note that in order to access your services, you may want to run envoy in host network (--net=host), or at least in the same network as your services.
Also, the entrypoint command can be seen by executing ps -ef:
$ docker exec envoy ps -ef
UID PID PPID C STIME TTY TIME CMD
envoy 1 0 1 16:47 pts/0 00:00:01 envoy -c /etc/envoy/envoy.yaml
I have implemented docker native health check by adding HEALTHCHECK command in Docker file as shown below,
HEALTHCHECK --interval=60s --timeout=15s --retries=3 CMD ["/svc/app/healthcheck/healthCheck.sh"]
set the entry point for the container
CMD [".././run.sh"]
executing the docker run command as shown below,
docker run -d --net=host --pid=host --publish-all=true -p 7000:7000/udp applicationname:temp
healthCheck.sh is exiting with 1, when my application is not up and I can see the container status as unhealthy, but it is not getting restarted.
STATUS
Up 45 minutes (unhealthy)
Below are the docker and OS details:
[root#localhost log]# docker -v
Docker version 18.09.7, build 2d0083d
OS version
NAME="CentOS Linux"
VERSION="7 (Core)"
How to restart my container automatically when it becomes unhealthy?
Docker only reports the status of the healthcheck. Acting on the healthcheck result requires an extra layer running on top of docker. Swarm mode provides this functionality and is shipped with the docker engine. To enable:
docker swarm init
Then instead of managing individual containers with docker run, you would declare your target state with docker service or docker stack commands and swarm mode will manage the containers to achieve the target state.
docker service create -d --net=host applicationname:temp
Note that host networking and publishing ports are incompatible (they make no logical sense together), net requires two dashes to be a valid flag, and changing the pid namespace is not supported in swarm mode. Many other features should work similar to docker run.
https://docs.docker.com/engine/reference/commandline/service_create/
There is no auto restart mechanism for unhealth container currently, see this, but you can make a workaround as mentioned here:
docker run -d \
--name autoheal \
--restart=always \
-e AUTOHEAL_CONTAINER_LABEL=all \
-v /var/run/docker.sock:/var/run/docker.sock \
willfarrell/autoheal
It add docker unix domain socket to the monitor container, then it could monitor all unhealthy container and restart it for you if other container is not healthy.
I have some docker containers running on my docker environment (on a CentOS VM) which need docker inside. So I mount /var/run/docker.sock inside the containers.
Now I'm creating /etc/default/docker in which I put
DOCKER_OPTS="-H tcp://xx.xx.xx.xx:2376"
But now my question is: which IP is xx.xx.xx.xx? Is it the IP of the host or the IP of a container? + Is this the savest way to let a docker container use the socket? (=use docker in docker)
Running docker within docker is not so trivial an you might have a good reason for doing that.
The last time I was doing that, I was using dind (docker in docker) and had to mount the socket (/var/run/docker.sock) and used it in a combination with the --privileged flag. However things might have changed now (see https://github.com/docker/docker/pull/15596) and it should be able to run it without the socket mount:
docker run --privileged -d docker:dind
So be sure to check out this comprehensive guide at https://hub.docker.com/_/docker/
Working with Docker in Docker can be tricky. I would recommend using the official Docker image with the dind tag. You shouldn't need to specify the DOCKER_HOST in options as it will be correctly configured. For example running:
docker run -ti --name docker -v /var/run/docker.sock:/var/run/docker.sock --privileged docker:dind sh
Will drop you to a shell inside the container. Then if your run docker ps you should see a list of containers running on the host machine. Note the --privileged flag is required in this case as we are accessing the Docker daemon outside the container.
Hope this helps!
Dylan
Edit
Drop the --privileged flag from the above command due to security issues highlighted by Alexander in the comments. You also can drop the dind tag as its not required.
Is it possible to control (list/start/stop/delete) docker containers from docker container running on the same machine?
The idea/intent is to have docker container which monitors/controls neighbours.
Both low/high level details would be useful.
Thanks!
Yes, the easiest way is to mount the docker socket from the host inside the docker container e.g:
$ docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v $(which docker):/usr/bin/docker debian /bin/bash
root#dcd3b64945ed:/# docker ps -q
dcd3b64945ed
3178d5269041
e59d5e37e0f6
Mounting the docker socket is the easiest however its unsecure as gives the root access to everyone who has access to the docker.sock
Id suggest using the Docker Remote API to do the list/start/stop/etc with a program which hides the docker remote ( in your case local ) daemon .
Ref: https://docs.docker.com/articles/basics/
As the title indicates, is it possible to restart the host from a container? I have a docker container running with systemd as described here and started as:
$ docker run -privileged --net host -ti -d -v /sys/fs/cgroup:/sys/fs/cgroup:ro <image_name>
Once I issue the systemctl reboot command, I see:
# systemctl reboot
[root#dhcp-40-115 /]#
[3]+ Stopped
The host doesn't reboot. However, I see [1915595.016950] systemd-journald[17]: Received SIGTERM from PID 1 (systemd-shutdow). on host's kernel buffer.
Use case:
I am experimenting with running the restraint test harness in a container and some of the tests reboot the host and hence if this is possible to do from a container, the tests can run unchanged.
Update
As I mention in my answer:
There is a detail I missed in my question above which is once I have
systemd running in the container itself, the systemctl reboot is
(roughly saying) connecting to systemd on the container itself which
is not what I want.
The accepted answer has the advantage that it is not dependent on the host and the container distro be have compatible systemd. However, on a setup where they are, my answer is what I think is a more acceptable one, since you can just use the usual reboot command.
Other init systems such as upstart is untested.
I was able to send sysrq commands to the host mounting /proc/sysrq-trigger as a volume.
This booted the host.
docker-server# docker run -i -t -v /proc/sysrq-trigger:/sysrq centos bash
docker-container# echo b > /sysrq
You can set a bit-mask permission on /proc/sys/kernel/sysrq on the host to only allow eg, sync the disks and boot. More information about this at http://en.wikipedia.org/wiki/Magic_SysRq_key but something like this (untested) should set those permissions:
echo 144 > /proc/sys/kernel/sysrq
Also remember to add kernel.sysrq = 144 to /etc/sysctl.conf to have it saved over reboots.
There is a detail I missed in my question above which is once I have systemd running in the container itself, the systemctl reboot is (roughly saying) connecting to systemd on the container itself which is not what I want.
On the hint of a colleague, here is what I did on a "stock" fedora image (nothing special in it):
$ docker run -ti -v /run/systemd:/run/systemd fedora /bin/bash
Then in the container:
bash-4.2# systemctl status docker
docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled)
Active: active (running) since Tue 2014-07-01 04:57:22 UTC; 2 weeks 0 days ago
Docs: http://docs.docker.io
Main PID: 2589
CGroup: /system.slice/docker.service
Here, the container is able to access systemd on the host. Then, issuing a reboot command actually reboots the host:
bash-4.2# reboot
Thus, it is possible to reboot the host from the container.
The point to note here is that the host is running Fedora 20 and so is the container. If the host was a different distro not running systemd, this would not be possible. Generally speaking, if the host and the container are running distros which are not running systemd or incompatible versions of systemd, this will not work.
Adding to user59634's answer:
-v /run/systemd:/run/systemd works on fedora 27 and ubuntu 16
But the only socket you need is
docker run -it --rm -v /run/systemd/private:/run/systemd/private fedora reboot
You can also use /run/dbus, but I like this systemd method more. I do not fully understand how much power you are giving the container, I suspect it is a enough to take over your host. So I would only suggest using this in a container that you wrote, and then communicate with any another container see here.
Unrelated similar information
Sleeping/suspending/hibernating can be done with only the -v /sys/power/state:/sys/power/state, and using /lib/systemd/systemd-sleep suspend for example. If you know how to, you can echo a string directly to /sys/power/state, for example echo mem > /sys/power/state here for more explanation of the different options you get from cat /sys/power/state
docker run -d --name network_monitor --net host --restart always --privileged --security-opt apparmor=unconfined --cap-add=SYS_ADMIN \
-v /proc:/proc \
$IMAGE_URI
docker container must be granted enough permission to mount /proc