This is an interesting take. I didn’t know the daemon binary can actually be used to run (as in create+start) or exec into containers. Didn’t it create a docker demon instance every time?
I would have done the last two commands differently:
export DOCKER_HOST=unix:///var/run/docker1.sock
docker run -d --network=host --privileged --hostname test --user root --name test 20:latest
docker exec --user root -it test /bin/bash
As an alternative approach, you could create a docker context and register unix:///var/run/docker1.sock as context. This would allow switching contexts between the started docker daemons.
This is not what actually happens. When you start a container without network namespace isolation (like you did with --network=host), then the container uses all host network interfaces directly. Your container doesn’t care or require the unix domain socket (unless the application inside the container actually requires a unix domain socket itself). Though, your docker demon instance will expose it’s rest api on it, and the docker cli needs to use it, to control the 2nd docker demon instance.
brctl addbr docker1
ip addr add 172.19.0.1/16 dev mn1
ip link set dev docker1 up
dockerd -H unix:///var/run/docker1.sock -p /var/run/docker1.pid --ip-masq=true --bridge=docker1 --data-root=/mnt/d1/docker-data --exec-root=/mnt/d1/docker-exec >/dev/null 2>&1 &
I just don’t understand why I haven’t got normal tcp port access both ways! something is blocking!? This driving me nuts! I just want to use ports in/out recieve/reply normally on what ever port is available but NONE work!
Running multiple daemons on a single host is considered as “experimental”. The user should be aware of unsolved problems. This solution may not work properly in some cases. Solutions are currently under development and will be delivered in the near future.
This section describes how to run multiple Docker daemons on a single host. To run multiple daemons, you must configure each daemon so that it does not conflict with other daemons on the same host. You can set these options either by providing them as flags, or by using a daemon configuration file.
The following daemon options must be configured for each daemon:
-b, --bridge= Attach containers to a network bridge
--exec-root=/var/run/docker Root of the Docker execdriver
--data-root=/var/lib/docker Root of persisted Docker data
-p, --pidfile=/var/run/docker.pid Path to use for daemon PID file
-H, --host=[] Daemon socket(s) to connect to
--iptables=true Enable addition of iptables rules
--config-file=/etc/docker/daemon.json Daemon configuration file
--tlscacert="~/.docker/ca.pem" Trust certs signed only by this CA
--tlscert="~/.docker/cert.pem" Path to TLS certificate file
--tlskey="~/.docker/key.pem" Path to TLS key file
When your daemons use different values for these flags, you can run them on the same host without any problems. It is very important to properly understand the meaning of those options and to use them correctly.
The -b, --bridge= flag is set to docker0 as default bridge network. It is created automatically when you install Docker. If you are not using the default, you must create and configure the bridge manually or just set it to ‘none’: --bridge=none
--exec-root is the path where the container state is stored. The default value is /var/run/docker. Specify the path for your running daemon here.
--data-root is the path where persisted data such as images, volumes, and cluster state are stored. The default value is /var/lib/docker. To avoid any conflict with other daemons, set this parameter separately for each daemon.
-p, --pidfile=/var/run/docker.pid is the path where the process ID of the daemon is stored. Specify the path for your pid file here.
--host=[] specifies where the Docker daemon will listen for client connections. If unspecified, it defaults to /var/run/docker.sock.
--iptables=false prevents the Docker daemon from adding iptables rules. If multiple daemons manage iptables rules, they may overwrite rules set by another daemon. Be aware that disabling this option requires you to manually add iptables rules to expose container ports. If you prevent Docker from adding iptables rules, Docker will also not add IP masquerading rules, even if you set --ip-masq to true. Without IP masquerading rules, Docker containers will not be able to connect to external hosts or the internet when using network other than default bridge.
--config-file=/etc/docker/daemon.json is the path where configuration file is stored. You can use it instead of daemon flags. Specify the path for each daemon.
--tls* Docker daemon supports --tlsverify mode that enforces encrypted and authenticated remote connections. The --tls* options enable use of specific certificates for individual daemons.
Example script for a separate “bootstrap” instance of the Docker daemon without network:
I was referring to the commands to create or exec the container, I was surprised to see dockerd (=the demon) being used instead of docker (=the client).
As I never felt the need to run more than a single docker demon on a host, I leave this for someone else to answer.
the guy who answers is doing it like that and it does work - I can confirm!
I don’t understand what is restricting me from using any ports properly though. Now today I can’t even use that 25177 unix DGRAM port that I was sort of hijacking. It’s litterally just stopped working so now I am stuck with no tcp ports to use
