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
Related
New to docker, please correct my statement
I'm trying to access docker container ex:nginx web server using port 80 in docker engine machine but am unable to access it.
Here my docker Engine network 10.20.20.0/24.
Docker Engine IP : 10.20.20.3
> Telnet 10.20.20.3 80 Connection failed
tcp 0 0 10.20.20.3:80 0.0.0.0:* LISTEN 28953/docker-proxy
Docker Container IP : 172.18.0.4
> Telnet 172.18.0.4 80 Connection success
Docker network detail
[root#xxxxxxxxx]# docker network inspect 1984f08c739d [
{
"Name": "xxxxxxxxxxxxx",
"Id": "1984f08c739d6d6fc6b4769e877714844b9e57ca680f61edf3a528bd12ca5ad1",
"Created": "2021-11-13T21:01:27.53591809+05:30",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.18.0.0/16",
"Gateway": "172.18.0.1"
}
]
},
"Internal": false,
"Attachable": true,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"126d5128621fa6cde0389f4c6e0b53be36670bce5f62e981da6e17722b88c4a9": {
"Name": "xxxxxxxxxxxxxxx",
"EndpointID": "b011052062ae137e3d190032311e0fbc5850f0459c9b24d8cc1d315a9dc18773",
"MacAddress": "02:42:ac:13:00:02",
"IPv4Address": "172.18.0.4/16",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {
"com.docker.compose.network": "default",
"com.docker.compose.project": "xxxxxxxx",
"com.docker.compose.version": "1.29.2"
}
} ]
I can access these nginx in other networks like 10.20.21.0/24 so on. But not on the same network 10.20.20.0/24 or same docker engine running on it.
My Environment Docker Engine VM having 2 Interfaces i.e. eth0 and eth1 with different subnet. In Previously it'll not work because both interfaces having separate routing table in /etc/sysconfig/network-scripts (route-eth0,route-eth1 and rule-eth0,eth1) Base hyper-v AHV. These route written to persistent interface. I tried to removing route for eth0. Since eth0 doesnt required routing table to persistent, it'll come by default route table in Linux. Then restarted the network..Hola there we go the docker listening on eth0 interfaces and something did for eth1. it's worked. Both eth0 and eth1 interfaces I can map to the dockers network. It's work like charm. I believe in AHV doesnt not required routing table for AHV VMs for different and same network subnets. So here the concluded its routing issues. Issues was resolved, I can access docker container with eth0,eth1 interfaces across different subnets and same subnet.
Both interfaces worked after restarting without any routes in AHV VMs and power off.
I'm trying to make a connection from one service to another, to achieve it I created an overlay network and two services attached to it like so.
$ docker network create -d overlay net1
$ docker service create --name busybox --network net1 busybox sleep 3000
$ docker service create --name busybox2 --network net1 busybox sleep 3000
Now I make sure my services are running and both connected to overlay.
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ecc8dd465cb1 busybox:latest "sleep 3000" About a minute ago Up About a minute busybox2.1.uw597s90tkvbcaisgaq7los2q
f8cfe793e3d9 busybox:latest "sleep 3000" About a minute ago Up About a minute busybox.1.l5lxp4v0mcbujqh79dne2ds42
$ docker network inspect net1
[
{
"Name": "net1",
"Id": "5dksx8hlxh1rbj42pva21obyz",
"Created": "2021-06-22T14:23:43.739770415Z",
"Scope": "swarm",
"Driver": "overlay",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "10.0.4.0/24",
"Gateway": "10.0.4.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"ecc8dd465cb12c622f48b109529534279dddd4fe015a66c848395157fb73bc69": {
"Name": "busybox2.1.uw597s90tkvbcaisgaq7los2q",
"EndpointID": "b666f6374a815341cb8af7642a7523c9bb153f153b688218ad006605edd6e196",
"MacAddress": "02:42:0a:00:04:06",
"IPv4Address": "10.0.4.6/24",
"IPv6Address": ""
},
"f8cfe793e3d97f72393f556c2ae555217e32e35b00306e765489ac33455782aa": {
"Name": "busybox.1.l5lxp4v0mcbujqh79dne2ds42",
"EndpointID": "fff680bd13a235c4bb050ecd8318971612b66954f7bd79ac3ee0799ee18f16bf",
"MacAddress": "02:42:0a:00:04:03",
"IPv4Address": "10.0.4.3/24",
"IPv6Address": ""
},
"lb-net1": {
"Name": "net1-endpoint",
"EndpointID": "2a3b02f66f395e613c6bc88f16d0723762d28488b429a9e50f7df24c04e9f1f0",
"MacAddress": "02:42:0a:00:04:04",
"IPv4Address": "10.0.4.4/24",
"IPv6Address": ""
}
},
"Options": {
"com.docker.network.driver.overlay.vxlanid_list": "4101"
},
"Labels": {},
"Peers": [
{
"Name": "e1c2ac76b95b",
"IP": "10.18.0.6"
}
]
}
]
So far so good! Next I ssh into one of containers and try to nslookup the second one, but have no luck.
$ docker exec -it busybox.1.l5lxp4v0mcbujqh79dne2ds42 sh
/ # nslookup busybox2
Server: 127.0.0.11
Address: 127.0.0.11:53
Non-authoritative answer:
*** Can't find busybox2: No answer
*** Can't find busybox2: No answer
/ # nslookup busybox2.1.uw597s90tkvbcaisgaq7los2q
Server: 127.0.0.11
Address: 127.0.0.11:53
Non-authoritative answer:
*** Can't find busybox2.1.uw597s90tkvbcaisgaq7los2q: No answer
*** Can't find busybox2.1.uw597s90tkvbcaisgaq7los2q: No answer
I know that overlay questions are quite common here, but they are mostly about node to node connections, not single node swarm. Another think to keep in mind is there is no local firewall on that node at all.
Am I trying to connect in the wrong way or is it a configuration issue?
The solution was simply adding a --attachable flag to network create command. After that I could ping my services by name.
Turns out you need that flag no matter if you are adding stack (in my case I have multiple stacks in the same swarm) or single services.
docker service create ... --network net1 does not create network aliases by default. To get that behaviour you need to use the long form syntax of --network
docker service create --network name=net1,alias=busybox1 busybox tail -f /dev/null
Its interesting that making the network attachable has a similar effect. Usually a network is made attachable so that containers can be attached to it via docker run --network net1 ... so while this approach works, it has potentially undesirable side effects for whatever network attachability is supposed to protect against.
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.
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.
I run docker containers on a Synology NAS. All container using the host driver have network connection but none of the containers using the bridge driver have. In the past it worked but some months ago one of my experimental containers experienced network problems
Environment:
Synology DS218+
DSM 6.2.3-25426 Update 2
10 GB internal memory
To simplify the description of the problem I have followed the tutorial from docker:
docker run –dit --name alpine1 alpine ash
docker run –dit --name alpine2 alpine ash
The containers have 172.17.0.2 and172.17.0.3 as IP addresses. When I attached to alpine1 I wasn’t able to ping to alpine2 using its IP-address (since the default bridge doesn’t do name resolution)
I also tried to use a user defined bridge:
docker network create –driver bridge test
and connected the containers to this network (and disconnected them from the default bridge network)
bash-4.3# docker network inspect test
[
{
"Name": "test",
"Id": "e0e203000f5cfae8103ed9b80dce113633e0e198c542f943ac2e7026cb684784",
"Created": "2020-12-22T22:47:08.331525073+01:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.22.0.0/16",
"Gateway": "172.22.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"3da4fda1508743b36540d6848c5334c84c3c9c02df88170e617d08f15e85999b": {
"Name": "alpine1",
"EndpointID": "ccf4be3f89c45dc73183210fafcfdafee9bbe30309ef15cf27e37bbb3783ea58",
"MacAddress": "02:42:ac:16:00:03",
"IPv4Address": "172.22.0.3/16",
"IPv6Address": ""
},
"c024024eb5a0e57720f7c2abe76ea5f5396a29eb02addd1f60d23075fcfcad78": {
"Name": "alpine2",
"EndpointID": "d4a8cf285d6dae7e8b7f96426a390b73ea800a72bf1739b0ea88c122de975650",
"MacAddress": "02:42:ac:16:00:02",
"IPv4Address": "172.22.0.2/16",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {}
}
Also in this case I wasn’t able to ping one container from the other.
Apart from updates of DSM I also upgraded the internal memory. Don’t think this has anything to do with the problem but you never know
I had a similar issue, have you tried disabling the firewall rules on the NAS?