use a static domain name to avoid cert errors when the VM IP changes

[robbles]

When I switch networks and end up with a different IP address, I get an error like this:

An error occurred trying to connect: Get https://192.168.99.100:2376/v1.21/containers/json: x509: certificate is valid for 192.168.99.102, not 192.168.99.100

Restarting dinghy doesn't help, but recreating the VM with dinghy destroy && dinghy create --provider virtualbox seems to fix it.

Is it possible to make this more resilient? Or is there just a configuration setting I'm missing? I think that recreating the dinghy instance every time I switch desks is not really reasonable, and neither is passing --tlsverify=false with every docker command.

[codekitchen]

I've been meaning to add this to the FAQ, thanks for the reminder: https://github.com/codekitchen/dinghy/blob/master/FAQ.md#the-docker-client-reports-errors-like-x509-certificate-is-valid-for-192168xy-not-192168xz

I haven't seen it happen as often as whenever you switch networks though. It seems to happen to most people once every few months or so. So there may be something more going on in your situation.

It'd be nice if docker-machine detected the situation and handled it automatically, I haven't checked open issues to see if they're planning to do that.

[robbles]

@codekitchen ah, that makes sense. I thought it might be a docker-machine issue.

I think it might be happening because I'm switching between a work and home network where there's a different DHCP reservation set up for my host machine, but I'm not sure.

Do you know if it's possible to force docker-machine to generate a certificate for a local domain name instead? Perhaps dinghy could solve this issue by setting DOCKER_HOST to something like tcp:https://docker.docker:2376 instead of an IP address, so that the certificate is always valid. Does that idea make sense?

[codekitchen]

Yeah interesting idea, it seems like that'd work.

[MrLoh]

yeah, this is really problematic. Recreating is no option for me, since pulling or building my docker container takes about 30 minutes (cotains over 2GB of NLP libraries). What's the best workarround for now. Can I just not set DOCKER_TLS_VERIFY=1?

@robbles what do you mean with “passing --tlsverify=false”, if I try to add this flag to docker run, it just crashes.

[codekitchen]

As stated in the FAQ answer I linked to, the fix is to run docker-machine regenerate-certs dinghy

[robbles]

@MrLoh do you have an older version of docker, or an out of date version of the VM created by docker-machine?
I tested the --tlsverify=false flag on mine and it just disables the verification, allowing me to run docker commands. I have run into trouble in the past with new versions of docker-machine not having backwards compatibility with pre-existing VMs. Sometimes docker-machine regenerate-certs fails if the VM is old enough. Maybe the issue you're seeing is similar?

[robbles]

@MrLoh in other words, I think it's likely that either solution will work for you if you recreate your VM this one time, in order to bring it up to date.

[MrLoh]

thanks the docker-machine regenerate-certs dinghy solved the issue.