I installed docker from binaries on SLES 15 x86_64 (https://docs.docker.com/engine/install/binaries/#install-static-binaries). And now I need to configure boot on start up and rootless launch. But I have no docker.service. And I don't understand how to configure it manually.
Thank you.
Normally I'd suggest to enable Container Module 12 x86_64 (aka sle-module-containers/12/x86_64) as described here but I think you have your reasons for not using it.
You need to create the docker.service and docker.socket files in the /etc/systemd/system folder as described in the documentation.
docker.service content can found here and it's currently:
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target docker.socket firewalld.service containerd.service
Wants=network-online.target containerd.service
Requires=docker.socket
[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutStartSec=0
RestartSec=2
Restart=always
# Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229.
# Both the old, and new location are accepted by systemd 229 and up, so using the old location
# to make them work for either version of systemd.
StartLimitBurst=3
# Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230.
# Both the old, and new name are accepted by systemd 230 and up, so using the old name to make
# this option work for either version of systemd.
StartLimitInterval=60s
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
# Comment TasksMax if your systemd version does not support it.
# Only systemd 226 and above support this option.
TasksMax=infinity
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process
OOMScoreAdjust=-500
[Install]
WantedBy=multi-user.target
docker.socket can be found here and it's currently:
[Unit]
Description=Docker Socket for the API
[Socket]
# If /var/run is not implemented as a symlink to /run, you may need to
# specify ListenStream=/var/run/docker.sock instead.
ListenStream=/run/docker.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker
[Install]
WantedBy=sockets.target
I've downloaded two docker containers and already configure them.
So, now all I want is to start them on system startup.
They are in a path like
/home/user/docker-mailserver
/home/user/docker-webserver
Hosted on a Ubuntu 18.04.01 (x64)
On boot those docker containers are not running.
On login, those docker containers are starting.
I already tried to do something like
docker run -it --restart unless-stopped fancydockercontainer:latest
docker run -dit --restart unless-stopped fancydockercontainer:latest
But then when I do docker ps there where new containers added to the pool.
Is there a way to "re-route" the start process of those container to system start without completely delete / remove them?
Addition:
I started them like docker-compose up -d mailserver
After #KamilCuk gave a hint to solve this with service, this was a possible solution.
Looks like this:
Create service file with command:
nano /etc/systemd/system/docker-mail.service
Done stuff like that in the file
[Unit]
Description=Docker Mailserver
Requires=docker.service
After=docker.service
[Service]
Restart=always
RemainAfterExit=yes
WorkingDirectory=/home/user/docker-mailserver
ExecStart=/usr/bin/docker-compose up -d mail
ExecStop=/usr/bin/docker-compose stop -d mail
[Install]
WantedBy=default.target
Adding the new service to systemctl with systemctl enable docker-mail.service
After rebooting the server, this mailserver is available.
At this point, I was able to see the startup log with journalctl -u docker-mail.service -b (-b is just "boot")
I'm having a problem building Docker images on my corporate network. I'm just getting started with Docker, so I have the following Dockerfile for a hello-world type app:
# DOCKER-VERSION 0.3.4
FROM centos:6.4
# Enable EPEL for Node.js
RUN rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
# Install Node.js and npm
RUN yum install -y npm
# Bundle app source
ADD . /src
# Install app dependencies
RUN cd /src; npm install
EXPOSE 8080
CMD ["node", "/src/index.js"]
This works fine when I build it on my laptop at home, on my own wireless network. It pulls down the requisite dependencies and builds the image correctly.
However, when I'm on my corporate network at work, this same docker build fails when trying to pull down the RPM from download.fedoraproject.org, with this error message:
Step 2 : RUN rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
---> Running in e0c26afe9ed5
curl: (5) Couldn't resolve proxy 'some.proxy.address'
error: skipping http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm - transfer failed
On my corporate network, I can access that URL just fine from my laptop. But once Docker is trying to build the container, all of a sudden it can't resolve at all. This behavior is the same for a variety of external resources (apt-get, etc.): They all can resolve just fine on my laptop on the corporate network, but Docker can't resolve them.
I don't have the network know-how to figure out what's going on here. Does anyone know why this strange behaviour would be occurring when building Docker containers?
I was able to figure out the issue. On Ubuntu, Docker sets the DNS servers for container to Google's servers at 8.8.8.x. As I understand it, this is a workaround on Ubuntu due to the fact that Ubuntu sets /etc/resolv.conf to be 127.0.0.1.
Those Google servers weren't accessible from behind our firewall, which is why we couldn't resolve any URLs.
The fix is to tell Docker which DNS servers to use. This fix depends on how you installed Docker:
Ubuntu Package
If you have the Ubuntu package installed, edit /etc/default/docker and add the following line:
DOCKER_OPTS="--dns <your_dns_server_1> --dns <your_dns_server_2>"
You can add as many DNS servers as you want to this config. Once you've edited this file you'll want to restart your Docker service:
sudo service docker restart
Binaries
If you've installed Docker via the binaries method (i.e. no package), then you set the DNS servers when you start the Docker daemon:
sudo docker -d -D --dns <your_dns_server_1> --dns <your_dns_server_2> &
I advise changing the DNS settings of the Docker daemon. You can set the default options for the docker daemon by creating a daemon configuration file at /etc/docker/daemon.json. Set DNS server according to your host machine, e.g. my DNS server is 10.0.0.2:
{"dns": ["10.0.0.2", "8.8.8.8"] }
Then you need just restart docker service:
sudo service docker restart
Step-by-step explanation is available here Fix Docker's networking DNS config
The following steps works for me ( for both docker build and docker run command). My linux version is Ubuntu 14.04.
Identify DNS using following command.
nm-tool | grep DNS
This result DNS:192.168.1.1 in my case
Create entry in /etc/default/docker.io. My current entry looks like this
DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4 --dns 192.168.1.1"
Restart docker service
sudo service docker.io restart
For any Linux distribution working with SystemD (Ubuntu 16, RHEL 7...), the path will be displayed with the following command:
$ systemctl status docker
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2016-06-29 08:10:33 PDT; 2min 34s ago
Docs: https://docs.docker.com
Main PID: 1169 (dockerd)
Tasks: 19
Memory: 85.0M
CPU: 1.779s
CGroup: /system.slice/docker.service
├─1169 /usr/bin/dockerd --dns 172.18.20.11 --dns 172.20.100.15 --dns 8.8.8.8 --dns 8.8.4.4 -H fd://
└─1232 docker-containerd -l unix:///var/run/docker/libcontainerd/docker-containerd.sock --shim docker-containerd-shim --met
The path would be /lib/systemd/system/docker.service. Add the DOCKER_OPTS values, which can have any of the --dns, in the line where the daemon is started.
cat /lib/systemd/system/docker.service | grep dns
ExecStart=/usr/bin/dockerd --dns 172.18.20.11 --dns 172.20.100.15 --dns 8.8.8.8 --dns 8.8.4.4 -H fd://
Docker (at least >=1.13, probably earlier) on Mac and Windows allow you configure the DNS in Preferences -> Daemon -> Advanced:
The following config sets two corporate DNS servers (use your own values here) with fallback to Google public DNS servers.
Specify your DNS to the Docker daemon.
First of all get your DNS address
$ nmcli dev show | grep 'IP4.DNS'
IP4.DNS[1]: 10.0.0.2
Test if the problem is really with the DNS by launching a docker container forcing this new DNS
$ docker run --dns 10.0.0.2 <image_name> <command_name>
If this solves the problem, you can apply this fix for all the docker daemons in the following way
Edit or create a file /etc/docker/daemon.json
Add the following line to this file
{
"dns": ["10.0.0.2", "8.8.8.8"]
}
Restart docker
$ sudo service docker restart
A very nice guide for doing ALL this process can be found here.
https://development.robinwinslow.uk/2016/06/23/fix-docker-networking-dns/
Solution without restarting Docker service
It is possible to modify the DNS settings for a single Docker image without affecting other docker build calls (and without restarting the Docker service) by overriding the resolv.conf at build time:
FROM ubuntu:18.04
RUN echo "nameserver 123.123.123.123" > /etc/resolv.conf && apt update
Replace the IP 123.123.123.123 with the one which is used within your corporate network (use nmcli dev show | grep 'IP4.DNS' to get the currently used DNS server).
Downsides:
This does not affect any other line from the Dockerfile. Hence, you have to prefix every line with the fix, if it depends on DNS resolution
On my Ubuntu 16.04 machine, sometimes, Google's DNS do not work for building Docker images.
cat /etc/docker/daemon.json
{"dns": [""8.8.8.8"] }
I have to manually find out my Service Providers DNS using the following command
nmcli device show <interfacename> | grep IP4.DNS
125.22.47.102
and add it to my daemon.json as show below
cat /etc/docker/daemon.json
{"dns": ["125.22.47.102","8.8.8.8"] }
restart docker
sudo service docker restart
(PS nm-tool is deprecated from Ubuntu 15.04)
Updated info September 2021
Inspired by Jason's answer; setting DNS server in the JSON didn't work for me in the current version, but there's now another place to set it:
When you turn on the toggle, the 8.8.8.8 is already there, so I just left it and it works well enough for me in my dev environment. I didn't research it but if wanted, there may be a way to add a list, perhaps separated by commas/semicolons/spaces etc.
I want to make a move to Docker, so I've just started to mess around with it. I've installed Docker on a VirtualBox Ubuntu 15.10 (Wily Werewolf) installation and as suggested here I then tried running a basic nginx Docker image:
$ docker run --name mynginx1 -P -d nginx
Cannot connect to the Docker daemon. Is the docker daemon running on this host?
So I checked out whether Docker was running:
$ sudo service docker status
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: active (running) since vr 2015-11-06 08:41:48 CET; 15min ago
Docs: https://docs.docker.com
Main PID: 7542 (docker)
CGroup: /system.slice/docker.service
└─7542 /usr/bin/docker daemon -H fd://
nov 06 08:41:47 kramer65-VirtualBox systemd[1]: Starting Docker Application Container Engine...
nov 06 08:41:47 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:47.900410966+01:00" level=info msg="API ...ock"
nov 06 08:41:48 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:48.033514149+01:00" level=info msg="Fire...lse"
nov 06 08:41:48 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:48.141594321+01:00" level=info msg="Defa...ess"
nov 06 08:41:48 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:48.416294436+01:00" level=warning msg="Y...it."
nov 06 08:41:48 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:48.565507576+01:00" level=info msg="Load...rt."
nov 06 08:41:48 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:48.567907022+01:00" level=info msg="Load...ne."
nov 06 08:41:48 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:48.567945214+01:00" level=info msg="Daem...ion"
nov 06 08:41:48 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:48.567969891+01:00" level=info msg="Dock....9.0
nov 06 08:41:48 kramer65-VirtualBox systemd[1]: Started Docker Application Container Engine.
Hint: Some lines were ellipsized, use -l to show in full.
This suggests that the Docker daemon is actually already running, but to be sure I just started the Docker daemon manually:
$ sudo docker daemon
INFO[0000] API listen on /var/run/docker.sock
INFO[0000] [graphdriver] using prior storage driver "aufs"
INFO[0000] Firewalld running: false
INFO[0000] Default bridge (docker0) is assigned with an IP address XXX.XX.X.X/XX. Daemon option --bip can be used to set a preferred IP address
WARN[0000] Your kernel does not support swap memory limit.
INFO[0000] Loading containers: start.
INFO[0000] Loading containers: done.
INFO[0000] Daemon has completed initialization
INFO[0000] Docker daemon commit=76d6bc9 execdriver=native-0.2 graphdriver=aufs version=1.9.0
I then tried running the image again, but with the same result:
$ docker run --name mynginx1 -P -d nginx
Cannot connect to the Docker daemon. Is the docker daemon running on this host?
I tried sudo'ing the command, but to no avail. What am I doing wrong here?
You need to add your current user to the docker group as follows:
sudo usermod -aG docker $(whoami)
then logout & login again into the system or restart the system.
test by docker version
for further info how to install docker-engine follow docker documentation
Add the user to the docker group
Add the docker group if it doesn't already exist:
sudo groupadd docker
Add the connected user "${USER}" to the docker group:
sudo gpasswd -a ${USER} docker
Restart the Docker daemon:
sudo service docker restart
Either do a newgrp docker or log out/in to activate the changes to
groups.
Usually, the following command does the trick:
sudo service docker restart
This, instead of docker start for the cases where Docker seems to already be running.
If that works then, as suggested and in another answer and on this GitHub issue, if you haven't added yourself in the docker group do it by running:
sudo usermod -aG docker <your-username>
And you're most likely good to go.
As for anybody else bumping into this, in some OS's docker doesn't start right after you install it and, as a result, the same can't connect to daemon message appears. In this case you can first verify that Docker is indeed not running by checking the status of your docker service by executing:
sudo service docker status
If the output looks something like: docker stop/waiting instead of docker start/running, process 15378 then it obviously means Docker is not active. In this case make sure you start it with:
sudo service docker start
And, as before, you'll most likely be good to go.
note to self: I get the error from the question's title when I forget to run docker command with sudo:
sudo docker run ...
[Ubuntu 15.10]
Had the same issue and what worked for me was:
Checking the ownership of /var/run/docker.sock
ls -l /var/run/docker.sock
If you're not the owner then change ownership with the command
sudo chown *your-username* /var/run/docker.sock
Then you can go ahead and try executing the docker commands hassle-free :D
After installing docker on Ubuntu, I ran the following command:
sudo service docker start
Have you tried it?
After install everything and start the service, try close your terminal and open it again, then try pull your image
Edit
I also had this issue again, if the solution above won't worked, try this solution that is the command bellow
sudo mv /var/lib/docker/network/files/ /tmp/dn-bak
Considerations
If command above works you probably are with network docker problems, anyway this resolves it, to confirm that, see the log with the command bellow
tail -5f /var/log/upstart/docker.log
If the output have something like that
FATA[0000] Error starting daemon: Error initializing network controller: could not delete the default bridge network: network bridge has active endpoints
/var/run/docker.sock is up
You really are with network problems, however I do not know yet if the next time you restart(update, 2 months no issue again) your OS will get this problem again and if it is a bug or installation problem
My docker version
Client:
Version: 1.9.1
API version: 1.21
Go version: go1.4.2
Git commit: a34a1d5
Built: Fri Nov 20 13:12:04 UTC 2015
OS/Arch: linux/amd64
Server:
Version: 1.9.1
API version: 1.21
Go version: go1.4.2
Git commit: a34a1d5
Built: Fri Nov 20 13:12:04 UTC 2015
OS/Arch: linux/amd64
I had the same problem. Been struggling for two days to solve it.
It only worked when I did:
According to Docker's Tutorial, you need to add the Docker key if not already added using:
$ sudo wget -qO- https://get.docker.com/gpg | sudo apt-key add -
Then make sure you grant docker privileges to yourself using:
$ sudo usermod -aG docker $USER
Hope this helps you too.
enter as root (sudo su) and try this:
unset DOCKER_HOST
docker run --name mynginx1 -P -d nginx
I've the same problem here, and the docker command only worked running as root, and also with this DOCKER_HOST empty
PS: also beware that the correct and official way to install on Ubuntu is to use their apt repositories (even on 15.10), not with that "wget" thing.
For OSX:
After opening docker and starting the 'default' machine via the Quickstart Terminal (https://docs.docker.com/engine/installation/mac/), you try docker commands and get this "can't connect to docker daemon" message, it turns out you need some env variables set:
eval "$(docker-machine env default)"
Then try it out with docker run hello-world to see if everything is peachy.
For the ones who already tried restarting your machine, unsetting the environment variable DOCKER_HOST as told in the docker env documentation and all the rest just try to go with the
sudo service docker restart
Only this did the trick for me even after restarting the machine.
Giving non-root access - from docker
Add the docker group if it doesn't already exist.
$ sudo groupadd docker
Add the connected user "${USER}" to the docker group.
Change the user name to match your preferred user.
You may have to logout and log back in again for
this to take effect.
$ sudo gpasswd -a ${USER} docker
Restart the Docker daemon.
$ sudo service docker restart
This question is currently number 3 on a Google search. After doing some research into solving this problem on my Linux system I thought I would write this answer. The original post states the problem is on Ubuntu but I also experienced the issue using Fedora. With that in mind, here is what I did to fix the problem.
On Fedora 22
Installing Docker:
$> curl -fsSL https://get.docker.com/ | sh
After installing Docker:
A user needs to be added to the docker group.
$> sudo usermod -aG docker
The docker daemon needs to be started
$> sudo service docker start
You can set the daemon to start at boot
$> sudo chkconfig docker on
You can verify the docker service is running
$> service docker status
And one last final check
$> docker run hello-world
Tested in Ubuntu 16.04
# Create the docker group and add your user to the docker group
groupadd docker
usermod -aG docker $USER
newgrp docker
# Configure docker service to be exposed
mkdir -p /etc/systemd/system/docker.service.d
echo -e '[Service]\nExecStart=\nExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2376' >> /etc/systemd/system/docker.service.d/override.conf
# restart service
systemctl daemon-reload
service docker restart
Try to use "sudo" with the command you are running.
I have same issue while running docker.
you can run commands as sudo user:
sudo docker ***your command here***
For Ubuntu:
Happened with me when I updated docker.
You need to unmask the service and socket and then restart the service.
Following worked for me:
systemctl unmask docker.service
systemctl unmask docker.socket
systemctl start docker.service
What happend behind the scenes
systemd also has the ability to mark a unit as completely unstartable, automatically or manually, by linking it to /dev/null. This is called masking the unit, and is possible with the mask command.
sudo systemctl mask docker.service
You can check the list of masked services using:
sudo systemctl list-unit-files
To enable auto/manual start of service you need to unmask it using:
sudo sytemctl unmask docker.service
Now the service will be enabled as shown below
As docker binds to a unix socket which is owned by root while starting up, using 'sudo' along with the docker commands will work.
I also had the same issue. The problem was in sockets allocated to docker-daemon and docker-client.
First, permission was not set for the docker-client on docker.sock You can set it using "sudo usermod -aG docker $USER"
Then check your bash file where the docker-client is running, For me it was on 0.0.0.0:2375, while docker-daemon was running on unix socket.(It was set in the configuration file of dockerd).
Just comment the bash-line and it'll work fine.
But if you want to make it work on TCP port instead of unix socket, change the configuration file of dockerd and set it on 0.0.0.0.2375 and keep the line in bash as it is if present or set it to 0.0.0.0:2375.
Perhaps this will help someone, as the error message is extremely unhelpful, and I had gone through all of the standard permission steps numerous times to no avail.
Docker occasionally leaves ghost environment variables in place that block access, despite your system otherwise being correctly set up. The following shell commands may make it accessible again, if you have had it running at one point and it just stopped cooperating after a reboot:
unset DOCKER_HOST
unset DOCKER_TLS_VERIFY
unset DOCKER_TLS_PATH
docker ps
I had a previously working docker install, and after rebooting my laptop it simply refused to work. Was correctly added to the docker user group, had the correct permissions on the socket, etc, but could still not run docker login, docker run ..., etc. This fixed it for me. Unfortunately I have to run this on each reboot. This is mentioned on a couple of github issues also as a workaround, although it seems like a bug that this is a persistent barrier to correct operation of Docker (note: I am on Arch Linux, not OSX, but this was the same issue for me).
I was able to fix that by running the following command:
sudo mv /var/lib/dpkg/info/docker-ce* /tmp
I have faced same error on Amazon EC2 instance. The issue got fixed after restarting the instance.
Add current user to docker group:
sudo usermod -aG docker $(whoami)
For Ubuntu 16.04
Inside file /lib/systemd/system/docker.service change:
ExecStart=/usr/bin/dockerd fd://
with:
ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2375
Inside file /etc/init.d/docker change:
DOCKER_OPTS=
with:
DOCKER_OPTS="-H tcp://0.0.0.0:2375"
and then restart your computer.