Until today, I had not had any trouble accessing Deis with a Deis client that didn't match the server. of course features that didn't exist in the server might not work (or it might; take deisctl ssh from 1.10.0 to a 1.7.3 cluster as an example).
But, beware the jabberwok. I was missing the client on my mac. So, I just downloaded the latest client, 1.11.2 to work against a 1.10.1 cluster.
I just needed to certs:add; what could it hurt, I thought. Certs:add from 1.11.2 client to 1.10.1 server blew away all of the certs as it added the new one. Yikes!
I was able to ssh into one of the hosts and find them in etcd /deis/certs. After ensuring that I had all of the certs/keys, I deleted those keys and their parent directory keys. Why? Because even with the keys, I couldn't add them, presumably because they were really in etcd, just not show up with deis certs:list.
Attempting to push the old keys, I get a 500 error. I can push new keys --just not keys to replace the ones in a bad state.
Now, I'm looking for someplace else that may contain old references to to the keys, which may be preventing me from uploading this "duplicate" cert name.
Oh, and because of my sorted history with Deis and Docker, I have multiple DEIS clusters. I am able to add that cert/key pair to another cluster.
Consider heeding the warning to avoid mismatching client and server versions.
Friday, October 23, 2015
DEIS Nuggets: scale up then back down to apply SSL cert
I found that simply uploading a cert with deis cert:add will not affect the running processes. The cert is applied to the DEIS router. Scaling the application down, then back up will work. But, why not scale up then back down? Works for me. HTH
Subscribe to:
Posts (Atom)