Related
I have a Rails application that I want to deploy using Docker on an Ubuntu server. I have the Dockerfile for the application already set up, right now I want to view the nginx conf in its container.
I ran the command below to start an nginx container in an interactive mode:
docker run -i -t nginx:latest /bin/bash
Right now I am trying to install nano editor in order to view the configuration for nginx configuration (nginx.conf) using the commands below:
apt-get update
apt-get install nano
export TERM=xterm
However, when I run the first command apt-get update, I get the error below:
Err:1 http://security.debian.org/debian-security buster/updates InRelease
Temporary failure resolving 'security.debian.org'
Err:2 http://deb.debian.org/debian buster InRelease
Temporary failure resolving 'deb.debian.org'
Err:3 http://deb.debian.org/debian buster-updates InRelease
Temporary failure resolving 'deb.debian.org'
Reading package lists... Done
W: Failed to fetch http://deb.debian.org/debian/dists/buster/InRelease Temporary failure resolving 'deb.debian.org'
W: Failed to fetch http://security.debian.org/debian-security/dists/buster/updates/InRelease Temporary failure resolving 'security.debian.org'
W: Failed to fetch http://deb.debian.org/debian/dists/buster-updates/InRelease Temporary failure resolving 'deb.debian.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.
I have checked very well it has nothing to do with network connectivity. I would need some help. Thank you.
Try restarting docker. Worked for me.
sudo service docker restart or sudo /etc/init.d/docker restart
Prior to bumping into this issue, docker was working fine. If you never had docker working in the first place, you probably have a different issue.
Specifying a DNS server for docker containers helped me.
Create a /etc/docker/daemon.json file with this content:
{
"dns": ["8.8.8.8", "8.8.4.4"]
}
and restart the docker service:
sudo service docker restart
src: https://docs.docker.com/engine/install/linux-postinstall/#specify-dns-servers-for-docker
Perhaps the network on the VM is not communicating with the default network created by docker during the build (bridge), so try "host" network :
docker build --network host -t [image_name]
for docker-compose:
service_name:
container_name: name
build:
context: .
network: host
If you have VPN running, stop it and try again. It solved for me!
Here's how I solved it:
Start the docker container for the application in an interactive mode, in my case it an nginx container :
docker run -i -t nginx:latest /bin/bash
Run the command below to grant read permission to the others role for the resolv.conf file:
chmod o+r /etc/resolv.conf
Note: If you are having this issue on your host machine (Ubuntu Linux OS) and not for the Docker containers, then run the same command adding sudo to it in the host machine terminal:
sudo chmod o+r /etc/resolv.conf
Endeavour to exit your bash interactive terminal once you run this:
exit
And then open a new bash interactive terminal and run the commands again:
apt-get update
apt-get install nano
export TERM=xterm
Everything should work fine now.
Reference to this on Digital Ocean: Apt error: Temporary failure resolving 'deb.debian.org'
That's all.
sudo vi /etc/docker/daemon.json
and check flag of iptables, aslo add DNS if not added
{...., "iptables":true,"dns": ["8.8.8.8", "8.8.4.4"]}
then
sudo service docker restart
solved me
I had the same problem and in my case it was file access control.
I uses extended acls on the docker root folder and did not realize it, because they where inherited from the folder above (stupid idea to test docker in a "scratch" directory where permissions are set via extended acls).
This lead to the situation that "/etc/resolv.conf" had setting "640" inside the running docker container with a "+" marking the extended acls. But the image did not have extended acls installed and could not handle it.
The weird thing was that, as far as I can see, all other network tools worked (e.g. ping) but only apt could no access the DNS resolver.
After removing the extended acls from the docker root and setting the usual acls, everything worked inside the running container.
Similar to the answer of "Promise Prestion", but solved permanently for new containers, too.
Run this command:
echo -e "nameserver 8.8.8.8\nnameserver 8.8.4.4" |sudo tee -a /etc/resolv.conf
After that run-
sudo apt-get update
This worked for me.
I easily resolved it via:
- docker exec -it nginx bash (Go inside container)
- ping google.com (if not working)
- exit (Exit from container)
- sudo service docker restart
Please also confirms /etc/sysctl.conf
- net.ipv4.ip_forward = 1
sudo sysctl -p /etc/sysctl.conf
Under Debian, as root, I've ran:
/etc/init.d/docker restart
This solved the issue for me.
Then build and run the container again.
I had a similar issue, I tried many suggested solutions, but my issue was gone after I rebooted my VM.
I was having the wrong DNS IP address in my /etc/docker/daemon.json. In my case, it was my home router DNS IP address and I was trying from the office network.
I found out my office DNS and updated with that.
{
"dns": ["192.168.1.1"]
}
Similar issue, under debian.
Root cause was a bad DOCKER-USER rule in iptables chain
Those rules have been haded
iptables -I DOCKER-USER -i eno1 -j DROP
iptables -I DOCKER-USER -s 90.62.xxx.xx/32 -i eno1 -j ACCEPT
so removing temporarily following rule fix the point
iptables -D DOCKER-USER -i eno1 -j DROP
Coming here from some docker cross compiling headache:
While forking some repo I manually downloaded its root folder containing confd stuff and added it just like the original maintainer did.
ADD root /
after this I was not able to apt update anymore.
I found that the permission of my root named folder was wrong. stat -f "%OLp" root revealed it is 700, but must be 755 to work.
I'm using Arch version 6.0.11 and docker version 20.10.21, and having this issues inside docker containers.
Thanks to #Marco, that was the initial hint to solve this. The problem is related to the use of extended ACLs in the host system.
The docker root folder has ACLs, you can see this as it has a plus sign at the end of permissions "+":
$ sudo ls -lh /var/lib/docker
drw-rw-r--+ 3 root root 4.0K Nov 24 2021 network
And what is the problem? Some docker images does not have ACLs installed, so as it was pointed this causes an issue.
Other network tools like curl resolved DNS properly, but apt or git have problems with DNS resolution.
TLDR; Where is the fix? Modify ACL to set default rx to others.
setfacl -R -d -m o::rx /var/lib/docker
After that, all network tools will be able to perform DNS resolution.
Credits:
Marco comment
Closed git issue in docker
According to Docker documentation, using Docker under WSL v2 should be fairly simple:
Install WSL 2 (make sure all the preconditions are met);
Install Docker Desktop 2.2.0 or newer;
In Docker Settings > General enable 'Expose daemon on tcp://localhost:2375 without TLS' and 'Enable the experimental WSL 2 based engine';
Make sure no Docker-related packages are installed in your Linux file system.
Once all this is done, I should be able to run docker or docker-compose commands from my Linux Terminal. But I'm not. I keep getting Command 'docker' not found, but can be installed with sudo apt install docker.io'.
What am I doing wrong?
Did you check if the integration is enabled in Resources > WSL Integration as below?
Have you made sure that wsl2 is enabled for your distro? Run this in Powershell
wsl -l -v
If your distro is not on WSL 2 then enable it like this.
wsl --set-version <Distro> 2
Install docker and docker-compose.
Type in the terminal:
sudo service docker start
sudo service --status-all | grep '+'
I recently upgraded Docker Desktop for Mac to version 2.2.0.0, and now when try to run a docker-machine command I am getting an error:
$ docker-machine --version
docker-machine: command not found
Docker Machine used to be installed with Docker, but it appears in the latest docs that this is no longer the case. What is the replacement or do I need to install Docker Machine from somewhere else?
Docker machine has been removed from later versions of Docker Desktop. Your going to need the docker-toolbox package.
Read here for install and co existence of the packages.
https://docs.docker.com/docker-for-mac/docker-toolbox/#docker-toolbox-and-docker-desktop-coexistence
For Windows, if you have chocolatey installed, you follow the steps:
open a command shell with "Run as Administrator" selected (I tested this on my work laptop).
run "choco install docker-machine"
Docker machine is now merged into the docker command, So instead of using
docker-machine init
Use
docker swarm init
And instead of
docker-machine join
Use
docker swarm join
for more command just use this:
docker swarm --help
If you already have docker-desktop & want the docker-machine command, then brew install docker-machine does the trick.
My versions of the binaries in usr/local/bin/docker and usr/local/bin/docker-compose did not change, & the version of the docker client & server, but I got the docker-machine binary extra.
run unset ${!DOCKER_*} if you want to use docker-desktop.
The docker docs are a bit confusing because they seem to address the case where you have docker-machine first, not the case where you have desktop first.
You basically need to install Docker Machine first on your local machine. Reference :- https://github.com/docker/machine/releases
$ curl -L https://github.com/docker/machine/releases/download/v0.16.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine &&
chmod +x /tmp/docker-machine &&
sudo cp /tmp/docker-machine /usr/local/bin/docker-machine
Try and run this command on bash:
curl -L https://github.com/docker/machine/releases/download/v0.16.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine && chmod +x /tmp/docker-machine && sudo cp /tmp/docker-machine /usr/local/bin/docker-machine
Click here to know more about docker-machine installation
It worked for me.
Did you try brew to install it as they removed docker-machine from v2.2.0?
brew install docker-machine
Try this (both inside, and outside of container):
ss -nputl
After creating a new machine with Docker Machine, I'm getting the following error:
$ docker ps
Error response from daemon: client is newer than server(client API version 1.21, server API version: 1.19)
How can I fix this?
docker-machine upgrade <your-machine>
will do the trick. This can happen - as it did for me - even if you're not using RCs and your machine was newly created. It would be due to an ISO cache issue. The error is commented in this thread.
If the docker client is 1.9.x and the server is running docker 1.8.x,
the error message is observed.
If someone happens to get this error, but is not using docker-machine, there is another way to resolve the issue by specifying an older API version in an environment variable on the client side:
export DOCKER_API_VERSION=<version>
for example:
export DOCKER_API_VERSION=1.19
and retrying the docker command.
Reference.
On ubuntu distrib it happens after an apt update, if docker run as a service.
The client is updated but the old version of the server is still running.
In this case just do a:
sudo service docker restart
If you upgrade your docker client you will not be able to use old docker-machine VMs. Actually you can force an upgrade with docker-machine upgrade vm-name, but if you are working with other distros (except boot2docker) as docker host like coreos, atomic, rancheros it may fail.
I am using Carina to manage more than one docker client version.
just install with $ curl -sL https://download.getcarina.com/dvm/latest/install.sh | sh
(linux and mac installation) and run dvm ls to list installed versions, dvm install 1.9.0 to install versions and dvm use 1.8.1 to change your client version.
Very easy and powerfull. =)
Atention, for your safety always take a look inside scripts downloaded from internet before running them.
Hope it helps
Apparently this error is due to docker-machine "falling asleep". Here is the magic command solving it for me:
$ docker-machine restart default
Or replace default by the name of your machine.
The result is:
$ docker-machine restart default
Restarting "default"...
Restarted machines may have new IP addresses. You may need to re-run the `docker-machine env` command.
As suggested, you may need to:
$ docker-machine env default
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://....."
export DOCKER_CERT_PATH=".../.docker/machine/machines/default"
export DOCKER_MACHINE_NAME="default"
# Run this command to configure your shell:
# eval $(docker-machine env default)
And so you finally run that command:
$ eval $(docker-machine env default)
From now it should work.
I had the same issue with 1.10.0-rc4, and it turned out that boot2docker wasn't updated properly when installing a newer Docker Toolbox. I had to remove boot2docker manually:
sudo rm -rf /usr/local/share/boot2docker
You can also delete the rest of the toolbox:
sudo rm -rf /usr/local/bin/docker*
sudo rm -rf /Applications/Docker
And finally install Docker Toolbox of the desired version.
Please see official uninstall script for on GitHub for OS X here.
I have successfully installed docker-machine on my Windows computer, and I'm able to use the Docker CLI on my windows box to run docker commands on a boot2docker VM.
I have docker-machine version 0.2.0, and docker 1.6.2, and the VM yields "4.0.3-boot2docker" when I run "uname -r" on it.
Now I want to install docker-compose to manage that boot2docker VM. Does docker-compose run on my Windows machine and manage the VM "remotely", as docker does, or do I have to install it on the VM itself?
On a related note, I tried installing docker-compose on my VM by doing the following:
C:\ docker-machine ssh dev
$ whoami
docker
$ sudo -i
# curl -L https://github.com/docker/compose/releases/download/1.2.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
# chmod +x /usr/local/bin/docker-compose
# exit
$ which docker
/usr/local/bin/docker
$ which docker-compose
/usr/local/bin/docker-compose
This is fine, but when I try to run docker-compose it doesn't work.
$ docker-compose up
-sh: docker-compose: not found
The file is in /usr/local/bin, and it has exactly the same privileges as docker.
docker#dev:/usr/local/bin$ ls -al do*
-rwxr-xr-x 1 root root 15443675 May 13 21:24 docker
-rwxr-xr-x 1 root root 5263681 May 19 00:09 docker-compose
docker#dev:/usr/local/bin$
Is there something I'm missing?
Have a good look at the curl output. It seems that the download url is not valid anymore. I found that
curl -L https://github.com/docker/compose/releases/download/1.2.0/docker-compose-Linux-x86_x64
gave
{"error":"Not Found"}
For me, the current release 1.3.2 worked well, i.e.:
curl -L https://github.com/docker/compose/releases/download/1.3.2/docker-compose-Linux-x86_x64
NOTE: When using on current CoreOS don't try to output in /usr/local/bin/docker-compose as noted here. Instead use /opt/bin/docker-compose (dir may need to be created first), i.e.
mkdir -p /opt/bin
curl -L https://github.com/docker/compose/releases/download/1.3.2/docker-compose-Linux-x86_x64 > /opt/bin/docker-compose
I found that the download links don't work for older versions and the "install" fails silently resulting in the problem you describe. Have a look to find a download link to a current version here:
https://github.com/docker/compose/releases
Like mkoertgen said, you can always view the output from the curl command in the terminal to see that you don't get "not found" or something similar or run cat /usr/local/bin/docker-compose to verify that it's not a textfile containing "not found".
You can install docker-compose on your Windows host too.
It will manage your docker remotely. You can think of docker-compose as a more abstract interface to docker.
After running boot2docker init, run boot2docker shellinit | Invoke-Expression. This will tell docker and docker-compose where the docker server is running.
More info on installing it on Windows can be found here: http://docs.docker.com/installation/windows/