dockerArchived
3 messages
All things docker
Archive: https://archive.sweetops.com/docker/
sheldonhover 4 years ago
Why would docker-compose work but not docker compose when I'm running one on Ubuntu 18.04 and one on Mac with docker desktop and docker version on both is 20.9+
Tried experimental flag on Ubuntu for kicks and still no go.
Tried experimental flag on Ubuntu for kicks and still no go.
Saichovskyover 4 years ago
I am using an Amazom AMI image to build spot instances whenever there is a build job. One of the packages that is created is docker using the commands below:
Sometimes, my internal routing table for the instance looks like this:
And sometimes I have a smaller routing table (some of the subnets listed above are excluded). I am not sure what the reason is for the inconsistent routing tables and bridged network interfaces, but it’s causing me some trouble, because every once in a while, a job needs to access an IP in one of the listed subnets in the routing table, which gets created by docker. In other words, docker sometimes creates a routing table that overrides the default route, causing builds to fail for a particular service, where the build script needs to access an IP address in one of the listed subnets. The traffic gets routed to one of those docker interfaces and times out.
Now my question is, what can be done about this? I just tried to have a look at
# Install Docker CE
curl -fsSL <https://download.docker.com/linux/ubuntu/gpg> | apt-key add -
add-apt-repository \
"deb [arch=amd64] <https://download.docker.com/linux/ubuntu> \
$(lsb_release -cs) \
stable"
apt-get update -yq && apt-get -yq install docker-ce docker-ce-cli <http://containerd.io|containerd.io>Sometimes, my internal routing table for the instance looks like this:
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.206.96.1 0.0.0.0 UG 100 0 0 ens5
10.206.96.0 0.0.0.0 255.255.224.0 U 0 0 0 ens5
10.206.96.1 0.0.0.0 255.255.255.255 UH 100 0 0 ens5
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.30.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-77455fcf0cbe
172.31.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-41e09bcc0b9c
192.168.32.0 0.0.0.0 255.255.240.0 U 0 0 0 br-c80695bea2be
192.168.96.0 0.0.0.0 255.255.240.0 U 0 0 0 br-5d6cf359313a
192.168.112.0 0.0.0.0 255.255.240.0 U 0 0 0 br-f38334a832ee
192.168.160.0 0.0.0.0 255.255.240.0 U 0 0 0 br-41a02bc22363
192.168.208.0 0.0.0.0 255.255.240.0 U 0 0 0 br-1f45ae76c3fe
192.168.224.0 0.0.0.0 255.255.240.0 U 0 0 0 br-8a8bb9ab22a0
192.168.240.0 0.0.0.0 255.255.240.0 U 0 0 0 br-c7f72974b999And sometimes I have a smaller routing table (some of the subnets listed above are excluded). I am not sure what the reason is for the inconsistent routing tables and bridged network interfaces, but it’s causing me some trouble, because every once in a while, a job needs to access an IP in one of the listed subnets in the routing table, which gets created by docker. In other words, docker sometimes creates a routing table that overrides the default route, causing builds to fail for a particular service, where the build script needs to access an IP address in one of the listed subnets. The traffic gets routed to one of those docker interfaces and times out.
Now my question is, what can be done about this? I just tried to have a look at
/etc/docker/daemon.json to see what’s in there and the file is actually missing. How do I deal with this erratic behaviour by dockerd?
Oscarover 4 years ago
Has someone here tried to access a service running in a container from another container, both running in the same host? In my case, I have a DB running on a compose with the port published to the host. Then I am running a gitlab-runner container, which needs to access this database to keep the test local. It works if I point to the DB in AWS RDS. I have tried to point to the local using its IP, container name, 127.0.0.1. I also tried running the second container with --net <compose network> and tried the same as mentioned before. Any ideas?