This question is regarding getting Xdebug to work with a CLI PHP script hosted inside a web-server Docker instance.
I have docker containers : web-server, varnish-cache, nginx-proxy.
I am able to successfully debug a Magento 2 web-page via browser with this VS Code Launch config:
This is with the new XDebug v3 which removed alot of v2 configuration settings
Client (Windows 10) IP (my laptop) : 192.168.1.150, Host (Ubuntu 20.04) IP: 192.168.1.105, hosting with Docker containers IP: 172.100.0.2-5
VS Code launch:
"name": "(Magento 2) Listen for XDebug on 192.168.1.5/105",
"type": "php",
"request": "launch",
"port": 9099,
"stopOnEntry": false, // Set to true to test any script on entry
"log": false,
// Remember to update remote_connect_back or remote_host
// inside xdebug PHP configuration.
// When using CLI debugging - rather use remote_host,
// because remote_connect_back = 1 does not work with CLI
// Server -> Local
"pathMappings": {
"/var/www/html/": "${workspaceRoot}",
},
"xdebugSettings": {
"max_children": 10000,
"max_data": 10000,
"show_hidden": 1
}
},
XDebug configuration (PHP 7.3)
zend_extension=xdebug.so
xdebug.log=/var/log/apache2/xdebug.log
xdebug.idekey=VSCODE
xdebug.client_port=9099
xdebug.client_discovery_header=HTTP_X_REAL_IP
xdebug.discover_client_host=On
; fallback for CLI - use client_host
xdebug.client_host=172.100.0.2
xdebug.start_with_request=yes
xdebug.mode=debug
Docker network:
docker inspect network magento2-network-frontend:
"Containers": {
"6538a93fbe811fbbd9646d4ce089e1b686b508862ed86f6afaac1b600043a1e5": {
"Name": "redis-cache-magento2.3.5",
"EndpointID": "d27bfbff61765cf2b840e98d43ec7a378e182baa7007dabde4bab5a41734fa2a",
"MacAddress": "02:42:ac:64:00:05",
"IPv4Address": "172.100.0.5/16",
"IPv6Address": ""
},
"7c7ba745db17d6d6a100901ed1e3fe38a3d26a97e086edc155254a7d41033bcf": {
"Name": "web-server-apache2-magento2-3-5",
"EndpointID": "9b81f6b7ff2292eba6fb68af209f1d5c958bea3ee0d505512862f225ed8e57be",
"MacAddress": "02:42:ac:64:00:02",
"IPv4Address": "172.100.0.2/16",
"IPv6Address": ""
},
"7f208ecce2aafdf182e4616ef2e8b043f3b8245018c299aae06c1acf4fc0d029": {
"Name": "varnish-cache-magento2-3-5",
"EndpointID": "e1c4e3f9e792b7dfd2cebfbb906bd237795820639a80ab8f530f0c8418257611",
"MacAddress": "02:42:ac:64:00:03",
"IPv4Address": "172.100.0.3/16",
"IPv6Address": ""
},
"dc599fa93b09650b70f8f95333caecc8f9db18cd19b17be57d84196e91f54c2a": {
"Name": "nginx-proxy-magento2-3-5",
"EndpointID": "7b8396af676d9af51b098d09f20d9e73ef83f4b085cb5f7195ea234aae7ed91d",
"MacAddress": "02:42:ac:64:00:04",
"IPv4Address": "172.100.0.4/16",
"IPv6Address": ""
}
The CLI command: _as can be seen it's a Magento 2 bin/magento migrate:data command from within the hosting Apache2 Web-server Docker container. (IP shown above is then : 172.100.0.2)
rm var/migration* && bin/magento migrate:data /var/www/html/app/code/ModuleOverrides/Magento_DataMigrationTool/etc/opensource-to-opensource/1.7.0.2/config.localboth.host_restoredb.xml
No debug breakpoints will work in my VS Code on Windows 10 Client (IP 192.168.1.150) because I am calling the script from within the container 172.100.0.2.
The log file /var/log/apache2/xdebug.log confirms something along this line:
Could not connect to debugging client. Tried: 172.100.0.2:9099 (fallback through xdebug.client_host/xdebug.client_port) :-(
So, since I have no idea how to run a CLI script from Windows 10 client and only from within Docker container, how/what can I do to get this CLI script to connect to Xdebug?
Additional information (if needed)
Magento 2 has CLI capability bin/magento [command] - and the command I am trying to debug is part of the data-migration-tool which is failing to import attributes correctly. No-one has a 100% working solution on the github repo for this particular issue - so I want to try and dig deeper to try and find a solution. Also, the tool is only a CLI tool, no web-ui option.
You need to set Xdebug's xdebug.client_host to the IP address of your IDE, which you indicated is 192.168.1.150.
You also need to turn off xdebug.discover_client_host, as that would try to use the internal Docker network IP (172.100.0.2), which is not where your IDE is listening on.
Remember: Xdebug makes a connection to the IDE, not the other way around.
Related
A problem with a Docker Container running NextJS application trying to access another Docker Container running a NestJS-API.
The environment looks like this:
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b04de77cb381 ui "docker-entrypoint.s…" 9 minutes ago Up 9 minutes 0.0.0.0:8004->3000/tcp ui
6af7c952afd6 redis:latest "docker-entrypoint.s…" 2 hours ago Up 2 hours 0.0.0.0:8003->6379/tcp redis
784b6f925817 api "docker-entrypoint.s…" 2 hours ago Up 2 hours 0.0.0.0:8001->3001/tcp api
c0fb02031834 postgres:latest "docker-entrypoint.s…" 21 hours ago Up 21 hours 0.0.0.0:8002->5432/tcp db
All containers are in the same bridged network.
A 'docker network inspect ' shows all Containers.
Containers are started in different docker-compose files (ui, redis+api, db)
API to DB
The api talks to the database db with postgresql://username:password#db:5432/myDb?schema=public
Notice the 'db' being the name on the Docker Network and port 5432 in the url.
Since they are on the same network you need to use the internal port 5432 instead of 8002.
Local UI
When I run the UI on the Host (on port 3000), it is able to access the API (in the Container).
Data is transferred from db-container to api-container to ui-on-the-host.
UI in the Container
Now I start also a browser on localhost:8004. This is the UI in the Container.
The UI is accessing the api on http://api:3001/*.
Sounds logical to use Docker Networkname and internal port. I also do that from API to DB.
But, this does not work: "net::ERR_NAME_NOT_RESOLVED".
Test: ncat test
Docker-Exec into the UI Container and doing a check (with ncat) shows the port is open:
/app $ nc -v api 3001
api (192.168.48.4:3001) open
Test: curl in the UI Container
(Added later)
When doing a Curl test out of the UI-Container to the API-Container I do get a result.
(See the simple/stupid Debug=endpoint called /dbg)
$ docker exec -u 0 -it ui /bin/bash
UI$ url http://api:3001/dbg
{"status":"I'm alive and kicking!!"}
About the Network
I did create my own Bridged Network.
So, the network is there and it looks like all Containers are connected to the network.
/Users/bert/_> docker network inspect my-net
[
{
"Name": "my-net",
"Id": "e786d630f252cf12856372b708c309f90f8bf177b6b1f742d6ae02f5094c7223",
"Created": "2021-03-11T14:10:50.417675Z",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "192.168.48.0/20",
"Gateway": "192.168.48.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"6af7c952afd60a3b4f36e244273db5f9f8a993a6f738785f624ffb59f381cf3d": {
"Name": "redis",
"EndpointID": "d9a6e6f6a4467bf38d3348889c86dcc53c5b0fa5ddc9fcf17c7e722fc6673a25",
"MacAddress": "02:42:c0:a8:30:05",
"IPv4Address": "192.168.48.5/20",
"IPv6Address": ""
},
"784b6f9258179e8ac03ee8bbc8584582dd9199ef5ec1af1404f7cf600ac707e1": {
"Name": "api",
"EndpointID": "d4b82f37559a4ee567cb304f033e1394af8c83e84916dc62f7e81f3b875a6e5f",
"MacAddress": "02:42:c0:a8:30:04",
"IPv4Address": "192.168.48.4/20",
"IPv6Address": ""
},
"c0fb02031834b414522f8630fcde31482e32d948de98d3e05678b34b26a1e783": {
"Name": "db",
"EndpointID": "dde944e1eda2c69dd733bcf761b170db2756aad6c2a25c8993ca626b48dc0e81",
"MacAddress": "02:42:c0:a8:30:03",
"IPv4Address": "192.168.48.3/20",
"IPv6Address": ""
},
"d678b3e96e0f0765ed62a70cc880b07836cf1ebf17590dc0e3351e8ee8b9b639": {
"Name": "ui",
"EndpointID": "c5a8d7e3d8b31d8dacb2f343bb77f4b364f0f3e3a5ed1025cc4ec5b65b44fd27",
"MacAddress": "02:42:c0:a8:30:02",
"IPv4Address": "192.168.48.2/20",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {}
}
]
Conclusion:
UI-Container with Curl in Container can talk to API-Container.
UI-on-Host with Browser on Host can talk to API-Container.
UI-Container with Browser on Host cannot talk to API-Containe. !!?? Why????
Question then is how to use a UI-container in the browser and talk to other Containers over the Docker Bridged Network?
Ok, problem solved.
It was a matter of confusion where the NextJS Application gets the API-location from.
Since the NextJS-Application (the UI) is in the end just running in a browser, you need to specify the API location as seen from the browser, not as seen as inter-Container communication.
For example on localhost we just refer to localhost:port to connect to a process running on the port port on the local machine. Is there a way to refer to the network the container is running on so we don't have to worry and hard-code what is the ip of a specific container/service. For instance if we want to connect to the postgresql database we would just write bridge1:5432.
EDIT : #fly2matrix suggested to use the named container solution but it didn't work, docker network inspect bridge returns
...
"Containers": {
"2375b29321dc4a5947f8b63b46fe1c955f43fb1fbca64bb2adce3503380dda37": {
"Name": "somepostgres",
"EndpointID": "398ec0e792b836ceb5dd5d2e448e813047f9157ad90283b448e40eaf3f4f5b66",
"MacAddress": "02:42:ac:11:00:03",
"IPv4Address": "172.17.0.3/16",
"IPv6Address": ""
},
"a72fbb333e2d8cd3b7b78205795456fadc44678348ccedc58a78510cd273505b": {
"Name": "pizz",
"EndpointID": "2e7aa30844a632f4d42e3d0cfa16003dfd1d86aef85e63d16c83b3a71601e134",
"MacAddress": "02:42:ac:11:00:02",
"IPv4Address": "172.17.0.2/16",
"IPv6Address": ""
}
},
My containers are on the same boat but if I try to connect to somepostgres:5432 from pizz container it just says 'unknown host'.
Try using named containers ,
#>docker run -d -it --name "container-name" {image-name}:{tag}
and other container can reach this container using name container-name of required containers.
Additionally you can also use --link option to link containers (internally it will create an entry in /etc/hosts to create alias dns name)
I have this:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e3252abd7587 cdt-tests "/bin/bash /home/new…" 5 seconds ago Exited (1) 22 seconds ago cdt-tests
f492760705e3 cdt-server "/bin/bash /usr/loca…" 52 seconds ago Up About a minute 0.0.0.0:3040->3040/tcp cdt-server
89c5a28855df mongo "docker-entrypoint.s…" 55 seconds ago Up About a minute 27017/tcp cdt-mongo
1eaa4aa684a9 selenium/standalone-firefox:3.4.0-chromium "/opt/bin/entry_poin…" 59 seconds ago Up About a minute 4444/tcp cdt-selenium
the cdt-tests container, is attempting to make connections to the other containers in the same network. the network looks like this:
$ docker network inspect cdt-net # this yields the below json
[
{
"Name": "cdt-net",
"Id": "8c2b486e950076130860e0c6c09f06eaf8cccf02127786b80bf7cc169f8eae0f",
"Created": "2018-01-23T21:52:34.5021152Z",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "172.18.0.0/16",
"Gateway": "172.18.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"1eaa4aa684a9d7c1ad7a1b7ac28418b100e6b8d7a22ceb2a97cf51e4487c5fb2": {
"Name": "cdt-selenium",
"EndpointID": "674ce85e14339e67e767ab9844cd2fd1356fc3e60ab050e1cd1457e4168ac9fc",
"MacAddress": "02:42:ac:12:00:02",
"IPv4Address": "172.18.0.2/16",
"IPv6Address": ""
},
"89c5a28855dfde05fe9db9a35bbe7bce232eb56d9024022785d2a65570c423b5": {
"Name": "cdt-mongo",
"EndpointID": "ed497939965363cd194b4fea8e6a26ee47ef7f24bef56c9726003a897be83dd1",
"MacAddress": "02:42:ac:12:00:03",
"IPv4Address": "172.18.0.3/16",
"IPv6Address": ""
},
"f492760705e30be4fe8469ae422e96548ee2192f41314e3815762a9e39a4cc82": {
"Name": "cdt-server",
"EndpointID": "17e8bd6f7735a52669f0fe92b2d5717c7a3ae6954c108af3f29c13233ef20ee6",
"MacAddress": "02:42:ac:12:00:04",
"IPv4Address": "172.18.0.4/16",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {}
}
]
in my cdt-tests container, I run these commands:
export CDT_SELENIUM_HOST="cdt-selenium.cdt-net";
export OPENSHIFT_NODEJS_IP="127.0.0.1";
export OPENSHIFT_NODEJS_PORT="3040";
export CDT_SERVER_HOST="127.0.0.1";
export CDT_SERVER_PORT=3040;
export OPENSHIFT_MONGODB_DB_HOST="127.0.0.1"
export OPENSHIFT_MONGODB_DB_PORT=27017
nc -zv "$CDT_SELENIUM_HOST" 4444 > /dev/null 2>&1
nc_exit=$?
if [ ${nc_exit} -eq 0 ]; then
echo "selenium server is live"
else
echo "selenium server is NOT live"
exit 1;
fi
nc -zv "$OPENSHIFT_MONGODB_DB_HOST" 27017 > /dev/null 2>&1
nc_exit=$?
if [ ${nc_exit} -eq 0 ]; then
echo "mongo server is live"
else
echo "mongo server is NOT live"
exit 1;
fi
nc -zv "$CDT_SERVER_HOST" 3040 > /dev/null 2>&1
nc_exit=$?
if [ ${nc_exit} -eq 0 ]; then
echo "cdt server is live"
else
echo "cdt server is NOT live"
exit 1;
fi
and all of those connection tests fail. Does anyone know how to connect between containers in the same Docker network? is there some surefire pattern to use?
It looks like you're trying to use 127.0.0.1 as the address for your other containers. Docker containers all have a unique ip address in an isolated network space. Much like your own physical host, 127.0.0.1 is a special address that means "this container". So since none of those services are running in the container in which you're running your tests, you can't connect to anything.
You need to use the ip address of the container running the service you want to test. Because ip addresses change with every deployment, it's not convenient to use the literal address. You need some way to get the information dynamically. For this reason, Docker maintains a DNS service on each network so that you can simply use the name of a container like any other hostname.
For example, in your environment, you could set:
export OPENSHIFT_MONGODB_DB_HOST="cdt-mongo"
And then your mongo test should succeed. And so forth for the other _HOST and _IP variables you're using.
I could assure you that the way #larsks mentioned would work well.
But there is still an easy way. I could see container cdt-tests is in the same network with other containers based on your description above. So you may attach all containers to a user-defined bridge network created by docker network create -d bridge mynet.
When starting containers, just add --net=mynet flag.
E.g.docker run -tid --name=cdt-server --net=mynet cdt-server .
Thus, there is no need to add any ENVs into your container(s). Since user-defined bridge networks provide automatic DNS resolution between containers. You may see introduction here.
first of all, I'm a totally n00b in docker, but I got into a project that are actually running in docker, so I've been reading about it.
My problem is, I have to inspect my development environment in a mobile device(iOS). I tried to access by my docker ip because this is what I basically do in my computer. After a few failed attempts I noticed that I've to access with the docker network bridge instead of docker host(the default).
I already have defined my docker bridge( I think its default), but i have no idea how to run my server with this network, can you guys help me?
A few important notes:
I'm using MAC OS X El capitan ( 10.11.1 )
The device and the mac are in the same wi-fi network and i can access using regularly localhost outside docker.
My following steps to run my server is:
cd gsat_grupo_5/docker && docker-compose -p gsat_grupo_5 up -d
docker exec -it gsatgrupo5_web_1 bash
python manage.py runserver 0.0.0.0:8000
When I run docker ps my output is:
My docker bridge output:
{
"Name": "bridge",
"Id": "1b3ddfda071096b16b92eb82590326fff211815e56344a5127cb0601ab4c1dc8",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1"
}
]
},
"Internal": false,
"Containers": {
"565caba7a4397a55471bc6025d38851b1e55ef1618ca7229fcb8f8dfcad68246": {
"Name": "gsatgrupo5_mongo_1",
"EndpointID": "471bcecbef0291d42dc2d7903f64cba6701f81e003165b6a7a17930a17164bd6",
"MacAddress": "02:42:ac:11:00:05",
"IPv4Address": "172.17.0.5/16",
"IPv6Address": ""
},
"5e4ce98bb19313272aabd6f56e8253592518d6d5c371d270d2c6331003f6c541": {
"Name": "gsatgrupo5_thumbor_1",
"EndpointID": "67f37d27e86f4a53b05da95225084bf5146261304016809c99c7965fc2414068",
"MacAddress": "02:42:ac:11:00:03",
"IPv4Address": "172.17.0.3/16",
"IPv6Address": ""
},
"a0b62a2da367e720d3a55deb7377e517015b06ebf09d153c6355b8ff30cc9977": {
"Name": "gsatgrupo5_web_1",
"EndpointID": "52687cc252ba36825d9e6d8316d878a9aa8b198ba2603b8f1f5d6ebcb1368dad",
"MacAddress": "02:42:ac:11:00:06",
"IPv4Address": "172.17.0.6/16",
"IPv6Address": ""
},
"b3286bbbe9259648f15e363c8968b64473ec0a9dfe1b1a450571639b8fa0ef6f": {
"Name": "gsatgrupo5_mysql_1",
"EndpointID": "53290cb44cf5ed8322801d2dd0c529518f7d414b3c5d71cb6cca527767dd21bd",
"MacAddress": "02:42:ac:11:00:04",
"IPv4Address": "172.17.0.4/16",
"IPv6Address": ""
}
},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
}
]
If there's some another smart approach to access my environment in my mobile device I'm listening.
I've to access with the docker network bridge instead of docker host(the default).
Unless you have a protocol that does something odd, like connecting back out to the device from the server, normally accessing <macip>:8000 from your device would be enough. Can you test the service from any other computers?
If you do require direct access the container network, that's a bit harder when using a Mac...
Docker for Mac doesn't support direct access to the Linux virtual machines bridge networks where your containers run.
Docker Toolbox runs a VirtualBox VM with the boot2docker vm image. It would be possible to use this but it's a little harder to apply custom network config to the VM that is setup and run via the docker-machine tools.
Plain Virtualbox is probably your best option, running your own VM with Docker installed.
Add two bridged network interfaces to the VM in Virtualbox. One for the VM and one for the the container, so they can both be available on your main network.
The first interface is for the host. It should pick up an address from DHCP like normal and Docker will then be available on your normal network.
The second bridged interface can be attached to your docker bridge and then the containers on that bridge will be on your home network.
On pre v1.10 versions of docker Pipework can be used to physically mapped an interface in to the container.
There is some specific VirtualBox interface setup required for both methods to make sure all this works.
Vagrant
Vagrant might make the VM setup a bit easier and repeatable.
$ mkdir dockervm
$ cd dockervm
$ vagrant init debian/jessie64
Vagrantfile network config:
config.vm.network "public_network", bridge: "en1: Wi-Fi (AirPort)"
config.vm.network "public_network", bridge: "en1: Wi-Fi (AirPort)"
config.vm.provider "virtualbox" do |v|
v.customize ['modifyvm', :id, '--nictype1', 'Am79C973']
v.customize ['modifyvm', :id, '--nicpromisc1', 'allow-all']
v.customize ['modifyvm', :id, '--nictype2', 'Am79C973']
v.customize ['modifyvm', :id, '--nicpromisc2', 'allow-all']
end
Note that this VM will have 3 interfaces. The first interface is for Vagrant to use as a management address and should be left as is.
Start up
$ vagrant up
$ vagrant ssh
I've been trying the latest RC's for docker and compose for a few days, and finally, today, the new stable versions (1.10 and 1.6 respectively).
The new networking stuff added in 1.9 has been great so far. But since I upgraded to 1.10rc1 (and so far for every RC and stable), containers in the same user defined network can no longer find each other. In fact, they can't even reach the outside world right now.
A quick example, file test_docker/docker-compose.yml:
version: '2'
services:
db1:
image: mysql
environment:
MYSQL_ALLOW_EMPTY_PASSWORD: yes
db2:
image: mysql
environment:
MYSQL_ALLOW_EMPTY_PASSWORD: yes
This creates two MySQL containers with the official image. According to the compose docs, a new testdocker_default should be created, with both containers automatically connected, which is the case:
docker network inspect testdocker_default
[
{
"Name": "testdocker_default",
"Id": "820f702e8e685567e4f1a8638cd9be305e96e37fcd741306eed6c1cf0d54ba02",
"Scope": "local",
"Driver": "bridge",
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1/16"
}
]
},
"Containers": {
"16d5594bdfd11f55d33a207612b8447f6b50ff4be8b42d2313707b06ca618556": {
"Name": "testdocker_db2_1",
"EndpointID": "b6d5ff10fba860c01ac7a6508e56c5e116296cd06ea2158c695897e18fcd50ce",
"MacAddress": "02:42:ac:11:00:03",
"IPv4Address": "172.17.0.3/16",
"IPv6Address": ""
},
"9b8b885dab3b5012c9663cb97a07af66fbe385f92c69a614a4d56bf85305ec3a": {
"Name": "testdocker_db1_1",
"EndpointID": "09e43aef8e14b0e876d47fabe67a3827dc4cea5d44b199113d9ab2678d8ce22a",
"MacAddress": "02:42:ac:11:00:02",
"IPv4Address": "172.17.0.2/16",
"IPv6Address": ""
}
},
"Options": {}
}
]
Now, the documentation also says that the containers should be able to reach each other through db1 and db2, but this is not the case:
root#9b8b885dab3b:/# mysql -h db2 -u root
ERROR 2005 (HY000): Unknown MySQL server host 'db2' (111)
root#9b8b885dab3b:/# mysql -h testdocker_db2_1 -u root
ERROR 2005 (HY000): Unknown MySQL server host 'testdocker_db2_1' (111)
Additionally, neither container is able to reach the internet, unless I explicitly add Google's DNS to the /etc/resolv.conf.
I'm pretty sure I'm doing something wrong here, because I can't find issues raised by other people, but I can't figure out what it is.
Thanks guys!
Edit:
To clarify, containers can ping each other through their IP address, but the hostnames are not resolved.
This issue was reported on GitHub. The suggested workaround for the moment is to disable firewalld altogether.
I will update this answer with a better solution to this issue as soon as one is found.
Edit #1:
Pull request solving this issue (tested for Fedora 23). This PR is already merged with master, for anyone wanting to compile Docker from source.
Couldn't find an expected release date, but I'm guessing it will be released as a patch version in the next couple weeks. Will update this answer again with further information when available.
Edit #2:
Docker's 1.10.1 RC solves this issue. I'll mark this answer as accepted just to close this topic.