I have just installed docker on a fedora 18 system:
Linux draco 3.8.4-202.fc18.x86_64 #1 SMP Thu Mar 21 17:02:20 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[mike#draco docker-master]$ sudo ./docker run -i -t base /bin/bash
2013/04/02 08:24:59 net: no such interface
Can anyone tell me what is missing here? lxc is installed, as well as lxc-libs, and lxc-templates.
You need a network bridge configured with the name lxcbr0.
To do this, you can run (as root):
brctl addbr lxcbr0
ifconfig lxcbr0 10.65.41.1
That usually means you don't have aufs setup correctly.
See https://github.com/dotcloud/docker/issues/183 for more information.
Related
I'm building CI/CD on Github Actions, and I want to use a specific docker image.
I used this yaml file:
jobs:
build:
name: Test Image
runs-on: ubuntu-latest
container:
image: lambci/lambda:build-nodejs12.x
steps:
- name: What OS is running
run: uname -a
But I'm getting the wrong image:
Linux b25c9fe8c287 5.4.0-1031-azure #32~18.04.1-Ubuntu SMP Tue Oct 6 10:03:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
instead of
Linux 758d8f59b7b6 5.4.39-linuxkit #1 SMP Fri May 8 23:03:06 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux).
What am I doing wrong?
The output of uname -a shows you what kernel is running. There are no kernels shipped with docker images, instead you get the Linux kernel of the host. Docker is a method to run isolated processes, not a virtual machine environment, and therefore you should expect the output of uname -a to vary depending on where you run the image.
I'm trying to create a Docker image which will forward a port through a VPN. I've created a simple image which exposes port 5144, and tested that it works properly:
sudo docker run -t -d -p 5144:5144 \
--name le-bridge \
--cap-add=NET_ADMIN \
--device=/dev/net/tun \
bridge
sudo docker exec -it le-bridge /bin/bash
I check that the port is exposed correctly like this:
[CONTAINER] root#6116787b1c1e:~# nc -lvvp 5144
[HOST] user$ nc -vv 127.0.0.1 5144
Then, whatever I type is correctly echoed in the container's terminal. However, as soon as I start the openvpn daemon, this doesn't work anymore:
[CONTAINER] root#6116787b1c1e:~# openvpn logger.ovpn &
[1] 33
Sun Apr 5 22:52:54 2020 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019
Sun Apr 5 22:52:54 2020 library versions: OpenSSL 1.1.1 11 Sep 2018, LZO 2.08
Sun Apr 5 22:52:54 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]
Sun Apr 5 22:52:54 2020 UDPv4 link local (bound): [AF_INET][undef]:1194
Sun Apr 5 22:52:54 2020 UDPv4 link remote:
Sun Apr 5 22:52:54 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun Apr 5 22:52:55 2020 [] Peer Connection Initiated with [AF_INET]
Sun Apr 5 22:53:21 2020 TUN/TAP device tun0 opened
Sun Apr 5 22:53:21 2020 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Apr 5 22:53:21 2020 /sbin/ip link set dev tun0 up mtu 1500
Sun Apr 5 22:53:21 2020 /sbin/ip addr add dev tun0 10.X.0.2/24 broadcast 10.X.0.255
Sun Apr 5 22:53:21 2020 Initialization Sequence Completed
root#6116787b1c1e:~#
root#6116787b1c1e:~# nc -lvvp 5144
listening on [any] 5144 ...
From here, using the exact same netcat command, I cannot reach the exposed port anymore from the host.
What am I missing?
EDIT: It's maybe worth mentioning that after the VPN is started, the connexion still succeeds from the host ; it just never reaches the netcat process inside the container.
I'm not exactly sure why, but it turns out that routes need to be fixed inside the container. In my case, the following command solves the issue:
ip route add 192.168.0.0/24 via 172.17.42.1 dev eth0
...where 172.17.42.1 is the IP of the docker0 interface on my host.
Hopefully this is helpful to someone one day.
After updating the docker to version 18.09.0, I get the following error(Virtual server with Ubuntu 18.04):
Nov 09 20:53:52 localhost.localdomain modprobe[663]: modprobe: ERROR: ../libkmod/libkmod.c:514 lookup_builtin_file() could not open buitin file '/lib/modules/4.15.0/modules.builtin.bin
Nov 09 20:53:52 localhost.localdomain modprobe[663]: modprobe: FATAL: Module overlay not found in directory /lib/modules/4.15.0
uname -a
Linux localhost.localdomain 4.15.0 #1 SMP Wed May 23 10:04:13 MSK 2018 x86_64 x86_64 x86_64 GNU/Linux
Also on LXC container (with Ubuntu 18.04) in Majaro
Nov 09 21:06:38 Ubuntu modprobe[5393]: modprobe: ERROR:
../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.14.78-1-MANJARO/modules.dep.bin'
Nov 09 21:06:38 Ubuntu modprobe[5393]: modprobe: FATAL: Module overlay not found in directory /lib/modules/4.14.78-1-MANJARO
uname -a
Linux Ubuntu 4.14.78-1-MANJARO #1 SMP PREEMPT Sun Oct 21 07:57:51 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
docker -v
Docker version 18.09.0, build 4d60db4
How can i fix it?
You have to override a portion of the containerd service file:
systemctl edit containerd.service
Then insert the following and save it:
[Service]
ExecStartPre=
After that you'll be able to get docker to start.
For reference: https://github.com/docker/for-linux/issues/475#issuecomment-437373774
Essentially your systemd file needs to have the ExecStartPre value cleared, best to use an override file so an upgrade will properly update the main file.
I am new with the Fiware and docker technologies so I need some help.
I am following the instructions from this link http://simple-docker-hosting-on-fiware-cloud.readthedocs.io/en/v1.0/manuals/install in order to create a docker-host machine on Fiware cloud but when I run the following command:
docker-machine create -d openstack --openstack-flavor-id="2" --openstack-image-name="base_ubuntu_14.04" --openstack-net-name="node-int-net-01" --openstack-floatingip-pool="public-ext-net-01" --openstack-sec-groups="docker-sg" --openstack-ssh-user "ubuntu" docker-host
I receive the following error:
Error creating machine: Error running provisioning: Unable to verify the Docker daemon is listening: Maximum number of retries (10) exceeded
Although, I can see the instance of the docker-host machine on Fiware cloud, but when I run the following command:
eval "$(docker-machine env docker-host)"
the following error comes up:
Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host "147.27.60.136:2376": dial tcp 147.27.60.136:2376: connectex: No connection could be made because the target machine actively refused it.
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
Be advised that this will trigger a Docker daemon restart which might stop running containers.**
I also tried to regenerate the certificates:
docker-machine regenerate-certs docker-host
but I received the following error:
Error getting SSH command to check if the daemon is up: ssh command error:
command : sudo docker version
err : exit status 1
output : Client:
Version: 18.04.0-ce
API version: 1.37
Go version: go1.9.4
Git commit: 3d479c0
Built: Tue Apr 10 18:21:14 2018
OS/Arch: linux/amd64
Experimental: false
Orchestrator: swarm
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?**
Image with the result for the Command: docker-machine ls
What am I doing wrong?
I use docker community edition for windows 10.
The docker version is:
Client:
Version: 18.03.0-ce
API version: 1.37
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:06:28 2018
OS/Arch: windows/amd64
Experimental: false
Orchestrator: swarm
Server:
Version: 18.03.0-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:14:32 2018
OS/Arch: linux/amd64
Experimental: false
First make sure you've opened your docker port (tcp/2376) in your default security group
Let me suggest you using base_ubuntu_16.04 instead of base_ubuntu_14.04
Anyway, it won't run properly at first. There is a problem with the latests versions of docker and docker-machine. As a workaround, after running your docker-machine command, you can do this to fix the problem:
ssh docker-host 'sudo apt-get -y install linux-image-extra-$(uname -r) linux-image-extra-virtual ; sudo modprobe aufs ; sudo service docker start'
However, you might find furhter problems due to MTU configuration in your docker host. To solve them, you can lower your MTU with these commands:
docker-machine ssh docker-host "sudo sed -i 's/--label provider=openstack/--label provider=openstack\n--mtu=1400/g' /etc/default/docker"
docker-machine ssh docker-host "sudo service docker restart"
docker-machine ssh docker-host "sudo ip link set mtu 1400 dev docker0"
My starting point is:
How to use docker remote api to create container?,
so I edit /etc/init/docker.conf and update 2 occurrences of the DOCKER_OPTS variable to:
DOCKER_OPTS='-H tcp://0.0.0.0:4243 -H unix:///var/run/docker.sock'
Then, a simple test to list docker images fails:
$ service docker restart
$ curl -X GET http://10.143.0.218:4243/images/json
curl: (7) Failed to connect to 10.143.0.218 port 4243: Connection refused
Docker version is:
$ sudo docker version
Client:
Version: 1.12.3
API version: 1.24
Go version: go1.6.3
Git commit: 6b644ec
Built: Wed Oct 26 19:06:36 2016
OS/Arch: linux/arm
Server:
Version: 1.12.3
API version: 1.24
Go version: go1.6.3
Git commit: 6b644ec
Built: Wed Oct 26 19:06:36 2016
OS/Arch: linux/arm
The solution comes from the comments of this page: http://www.virtuallyghetto.com/2014/07/quick-tip-how-to-enable-docker-remote-api.html
[08/18/2016 at 6:00 am] Oliver Weise says:
Thanks, that put me in the right direction. However since Ubuntu 16.04
with its systemd docker daemon the /etc/default/docker is no longer
effective. Instead you need to create a systemd dropin file.
I placed such a file under: /etc/systemd/system/docker.service.d/remote-api.conf
With the contents:
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H tcp://127.0.0.1:2376 -H unix:///var/run/docker.sock
(Yes, the double ExecStart is necessary)
After that run:
sudo systemctl daemon-reload // reloading daemon definitions
sudo systemctl restart docker
Not tested this, but if it's Jessie, then it uses systemd by default as the init system iirc, and this has implications for how the daemon (dockerd) is configured and started.
So you're editing the /etc/init/docker.conf file but I don't think that's being read / used.
Take a read of this article on different startup procedures on each init system in Docker, and this for specific systemd configuration.