Insecure な clustering にさえハマる

host1 で cockroach が無事に起動する事を確認して、host2 でも確認、問題なさそう
で、host2 の node2 を host1 の node1 のクラスタに join させようとするのだけど、無視してしれっと別のクラスタをつくって stand alone で起動してくださる

全然、理由がわからない、Trouble Shootingを漁っても、ググってもわからない、なんで他のみんなはこんな目にあってないんだろ？
半泣きで SOに助けを求めたら、速攻で「node2のcockroach-data消しとかないとダメだよ」と教えてもらう、Marc さんありがとう、私は人の世の優しさで生かされている！

Secure な clustering には当然ハマりそう

Insecure な clustering でさえハマってググりまくるという希有な経験をさせていただいておりました私は、その過程で皆様が Secure な cluster を作ろうとしてハマりまくってるのをすでに知っていたので、ビビリながら try

Deploy の Manual Deployment の On-Premisesを何度も（普通なら１度で十分なんでしょうけど^^;;;）読んで、だんだんと分かってくる

1. deploy する対象は certs folder であって、my-safe-directory は deploy しないでどこかにかくしておく、ここには ca.key ができる
2. 前述の ca.key を使って certs 配下に証明書をいくつかつくるのだけど
   • クラスタ全体で同じものを使う: ca.crt, client.root.crt
   • node ごとに別のものを使う: node.crt

ということをドキュメントの行間から読み取るのが物凄く難しかったですが、これがわかればハマりポイントはなさそう...

なのにハマる

node1 は起動するのに node2 が join しないどころかリトライを繰り返して起動さえもしない
log (cockroach-data/logs/cockroach.log) をみると（クラスタ作り直した時に消しちゃったので記憶で書いてますが）host 1 の IP アドレスと host2 のIPアドレスが「対象が違う」というようなエラーメッセージ

実は、host1 に node2 用の証明書を間違えておいてたというおマヌなのが原因だったんですが、それにしても node1 はシレっと起動して、node2 の起動がエラーになるあたり、cockroachdb 恐るべし

番外編：admin UI にログインできない

admin UI にログインするためのカウントを作る SQL がドキュメントとか、admin UI のページにでてるんですが、これをコピーして sql client にペーストするとパスワードの前後のシングルクオートが化けてアカウントつくってくれるのでログインできません ^^;;;
これも原因に気づくまでずいぶん時間かかったんですけど全く知育玩具かと思うぐらい昨日今日で頭がよくなってきた気がする o(´∀｀)o

感想

名前からゴキブリなみのしぶとさを期待してたんですけど絶滅危惧種育ててるのかと思うほど大変だったですが...

てか、立ち上がっちゃえば核戦争後まで生き延びるほどしぶといクラスタだと期待しつつ次号につづく