Talk:Docker

From ArchWiki

Arch Linux bootstrap-based Docker image build setup

I have recently come up with an Arch Linux Docker base image build setup (https://github.com/czka/archlinux-docker), based on bootstrap tarball. Compared to the shell script approach (https://wiki.archlinux.org/index.php/Docker#Build_Image), it has the benefit of enabling Arch Linux Docker image builds on non-Arch hosts, and does not require root.

What do you think of it? I tried getting some attention on Arch forum (https://bbs.archlinux.org/viewtopic.php?pid=1667108#p1667108) but no reply yet. Maybe I'm re-inveting the wheel? I was thinking not, as no similar solution is documented here on the Wiki. Please let me know.

In the forum topic I mentioned I'm asking abot 3 things I need to sort out in order to call the whole thing done. I'll appreciate some input.

docker0 Bridge gets no IP / no internet access in containers

I want to rewrite this section: based on my experience with systemd 232 and Docker 1.13, creating /etc/systemd/network/ipforward.network file as suggested by that section introduces problems where bridges created by Docker loose their IP addresses once all containers using those bridges are stopped, and don't regain the IP. Ektich (talk) 09:42, 2 March 2017 (UTC)

Storage driver section regarding overlay2

The wording of Arch Linux using overlay2 suggests that the default storage driver is overlay2. From what I can tell, the default storage driver is devicemapper. Perhaps the section should say that there is work being done to make overlay2 the default storage driver and reference a Github issue or something like that. --Dmp1ce (talk) 01:21, 2 April 2017 (UTC)

Storage driver devicemapper clarification

It is true that devicemapper in loopback mode should never be used outside of development but if a proper LVM volume is being used (no loopback), performance is not degraded in any way. Devicemapper non-loopback is the preferred local storage driver on CentOS and RHEL. The wording should probably be changed to say that devicemapper is acceptable to use but there should be a proper backing for it and not just a loopback LVM volume. --MrOwen (talk) 23:19, 31 October 2017 (UTC)

no connectivity between containers

I experienced that docker containers started with docker-compose can not connect to each other (even on published ports). For me it only helped to disable ip tables filtering for bridges (which is not a good solution as it omits docker security (icc flag useless)

# echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables

Aatdark (talk) 13:52, 22 December 2017 (UTC)

Docker service failed to start "Error initializing network controller: list bridge addresses failed: no available network"

Good to add solution for:

dockerd[13737]: Error starting daemon: Error initializing network controller: list bridge addresses failed: no available network

which is following that commands:

#!/bin/bash

#
# create docker0 bridge
# restart docker systemd service
# confirm new outgoing NAT masquerade is set up
#
# reference
#     https://docs.docker.com/engine/userguide/networking/default_network/build-bridges/
#


sudo brctl addbr docker0
sudo ip addr add 192.168.42.1/24 dev docker0
sudo ip link set dev docker0 up
ip addr show docker0
sudo systemctl restart docker
sudo iptables -t nat -L -n

exit(0)

tested and works for me solution found at [1]

—This unsigned comment is by Drathir (talk) 22:57, 9 January 2018‎. Please sign your posts with ~~~~!

Yes, this worked for me. Please go ahead and add this info to the page. axper (talk) 09:06, 16 August 2018 (UTC)

X11 Forwarding

I have had issues when a container required to forward X11, as it wasn't able to connect to display via unix socket...

The solution was to found here[2] and it was to allow docker to connect via

 $ xhost +local:docker


Maybe it would be worth to add a section in troubleshooting?

Karrq (talk) 16:48, 19 May 2021 (UTC) Karrq

Native overlay diff

https://wiki.archlinux.org/title/Docker#Enable_native_overlay_diff_engine seemed to be true Pickfire (talk) 10:50, 23 September 2022 (UTC)

On my system, if I load the overlay module with sudo modprobe overlay, and then check /sys/module/overlay/parameters/metacopy and /sys/module/overlay/parameters/redirect_dir, both are Y, suggesting that the default is still the suboptimal configuration.
Looking at the relevant Kconfig file, it does not specify a default, meaning that OVERLAY_FS_METACOPY defaults to N, when building a vanilla kernel. It is actually Arch's kernel configuration which re-enables this option by default.
That said, that still is a default, and there are circumstances in which metacopy is disabled at runtime; see "disabling metacopy" in this file. Maybe there is an info message explaining why metacopy and/or redirect_dir was disabled for you. -- CodingKoopa (talk) 18:01, 24 September 2022 (UTC)

Docker rootless

Steps 1 - 3 worked for me here: https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user Why are we recommending against that and telling user to install and "extras" package from AUR? -- Calvertdw (talk) 20:40, 26 September 2022 (UTC)!

These are different things. The article you linked discusses interfacing with the Docker Engine as a nonroot user. Docker#Docker rootless is for running the daemon itself as a nonroot user, a more exotic configuration. For the former configuration, we do mention it in Docker#Installation.
I have tried to clarify this with Special:Diff/748634. Thanks, CodingKoopa (talk) 03:11, 27 September 2022 (UTC)