kubernetesにelasticsearchを導入するのでドハマリ

helmの標準リポジトリからインストールしたら成功したけど、elasticsearchが6.7までしか導入できないので、metrics-beatが動作しない。


helm install elastic/elasticsearch \
–name elasticsearch \
–set client.replicas=3 \
–set master.replicas=3 \
–set master.persistence.storageClass=local-storage \
–set master.persistence.size=8Gi \
–set data.replicas=3 \
–set data.persistence.storageClass=local-storage \
–set master.podDisruptionBudget.minAvailable=2 \
–set cluster.env.MINIMUM_MASTER_NODES=2 \
–set cluster.env.RECOVER_AFTER_MASTER_NODES=2 \
–set cluster.env.EXPECTED_MASTER_NODES=2 \
–set client.serviceType=LoadBalancer \
–namespace elasticsearch

で、色々ググったらelastic社の公式リポジトリを使えば7.2も導入できるっぽい。

helm repo add elastic https://helm.elastic.co

で、StorageClassの指定方法が判らず2時間ほど悪戦苦闘して、以下のようにすればいけることが判明。

helm install elastic/elasticsearch –name=elasticsearch –namespace=elasticsearch –set volumeClaimTemplate.storageClassName=local-storage

kibanaは特に問題なし

helm install elastic/kibana –name kibana –namespace kibana –set service.type=LoadBalancer –set elasticsearchHosts=http://elasticsearch-master.elasticsearch:9200/

これで、コンテナは簡単とか言わないでほしいな。

マンゴー



とあるどどんとふ公式鯖利用者のフォロワーさんからお中元で宮古島産の高級マンゴーをいただきました。ドドンと大玉で4個です。



マンゴー捌きは下手くそなので、フォトジェニックにインスタ映えするようなカットには失敗しましたが、ものごっつう美味しいです。しかも巨大。4個。最高です。


剥いた瞬間から始まる夫婦姉妹での血で血を争うバトルロワイヤル。あっという間でした。食べ終わった後の圧倒的な満足感と感動と喪失感。やはり国産マンゴーが家にあると、仕事でむかつく人に会っても「そんな口きいていいのか?(ry


というわけで、完食した後にググってみたら、国産マンゴーって実生でもちゃんと美味しく結実するらしい(ただし7-8年後)のは以前ふるさと納税の返礼品でマンゴーを入手したときに調べていたのですが、氷点下になるような気温だとアウトなので九州や沖縄じゃないと育てるのは厳しいらしいと諦めていました。


。。。育てるのは厳しいらしいのです。。。




やっぱり諦めきれなかったので、嫁からの「無駄な悪あがきはやめろ」との冷ややかな意見を華麗にスルーし、種を取り出して水に浸してみました。1週間ぐらいで発芽するらしいです。無事発芽したら鉢植えしてみよう。。。鉢植えでも1.5mぐらいになるらしいので、成功しても買った方が安いだろと嫁に怒られかねません。


あと、よく考えたら我が家の玄関って日当たり良いし、どどんとふ公式鯖があるから冬でも暖かくね??と思ったのはここだけの話。うまくいけば、データセンターの排熱でマンゴー栽培という新たなビジネスチャンス!

fluentdにハマり中

haproxyのアクセスログをfluentdに食わせるところでドハマリ中。haproxyのログが変な形式だしrsyslog経由だしIPv6だしrubyの正規表現あんまり詳しく知らないので何度やってもparseに失敗してエラー吐く。ちゃんとfluentdを調べないと。。。

ipv6ではまる

少し前から自宅のPCでYouTubeが再生できなくなってしまい、色々調べてみたら「xxxx.googlevideo.com 」からのストリーミングがIPv6のみ不正パケットとしてルーターが破棄してしまっていたことが判明。FirewallでInvalidでもforwardをacceptするようにしてもダメだったので、本当にパケットが壊れているのではなくRouterOSの不具合かなにかでQUICかStream系のパケットを正しくルーティングできていなさげ。
解決策はすっげー乱暴だけど「xxxx.googlevideo.com 」である「2001:ce8:b2::/48」をルーターでrejectすることによって「xxxx.googlevideo.com 」へのアクセスのみを無理矢理IPv4にFailBackさせたら解決した。原因と対策を思いつくまで1週間近くかかったよ。。。ってこんなんわかるか!!

メモ(systemdでハイバネートとサスペンドを無効化)

正直いって、こんなんデフォルトで無効化しておいてほしい。罠スギ。

# systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
# systemctl restart systemd-logind.service

話は変わるけど、busterにしたら色々依存関係ぶっ壊れてopennebulaは起動しなくなった。ソースからビルドしようにも色々面倒なので、管理用のsunstoneだけ動かす仮想マシンをstretchで作った方が良いかもしれない。