Open trnubo opened 9 years ago
I've been having instances go unreachable. I'm giving this a try.
I've managed to avoid the issue by not mounting systemd or resolv.conf. Instead, I'm running resolvable with the early-docker service and running the regular docker with "DOCKER_OPTS=--dns $private_ipv4". I think this is a nice also because it ensures that containers started with the primary docker daemon don't risk getting a bad resolv.conf from before resolvable started.
@trnubo what do you think a solution could be? Maybe just documentation?
I'm trying to run resolvable on CoreOS and AWS but my instances are losing their network connectivity periodically. I have narrowed it down to resolvable and that the machines with resolvable running don't have systemd-networkd running and when resolvable is not run systemd-networkd remains working.
I'm starting resolvable in a docker container with
-e DNS_RESOLVES="8.8.8.8,8.8.4.4" -v /var/run/docker.sock:/tmp/docker.sock -v /run/systemd:/tmp/systemd -v /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket gliderlabs/resolvable:master
Obviously AWS is running with a DHCP network not static IPs. It seems that unless I explicit add a network unit (like the one below, coreos doesn't have any by default) resolvable will effectively shutdown systemd-networkd which could be causing my issues (I'm still testing with the extra network unit).