ITエンジニアに対するスカウトに思うところ

WantedlyやLinkedInにユーザとして登録していると，スカウトをもらうことがある．最近はこれに近いサービスが多くあり，LAPRASやOffersなんかもある．findyは，スカウトというほどはっきりしたものではないが，一応興味通知が来る． サービスを通さなくても，直接メールが来たり，TwitterのDMでスカウトが来たり，いろいろな方法でスカウトが届く．

スカウトと言っても，いきなり「あなたを1000万で雇うからすぐに来てくれ！」みたいなことはなくて，だいたいは「一度お話しましょう」というのが多い． この形のスカウトで一番多いのが「カジュアル面談」を誘うパターンだ．

前職がLAPRASだったこともあり，私も自分でスカウトメールを書いて送ったことはあるし，カジュアル面談をセッティングしたことも何度もある． そういう経験もあり，カジュアル面談の誘いが来たら，全部ではないがそれなりに受けてみることにしていた．

が，最近立て続けに不届きなスカウトメールを受け取ることが増えたので一言言っておきたい．

「転職意思がなくても構わないので」と書くのであれば転職意思がなくてもちゃんとカジュアル面談しろよ

Kubernetes 1.20ではownerReferenceのnamespaceに気を使え

qiita.com

ここの話です．

github.com

Issueの内容を熟知している方には余計なお世話です．

いやーこんなの自分には関係ないだろうと思ってたら見事に当たりました．

問題になるケース

問題になるケースはおそらく以下の2パターン．

1. OwnerとChildが別のnamespaceに所属するパターン
2. namespaceに所属するOwnerがcluster scopeなChildからOwnerReferenceを張られているパターン

ちなみにこれは作成時にエラーになるわけではない．あくまでGCコントローラの挙動の変更なので，リソースが削除される挙動が変更になっている．

私の場合2に該当していた．

CRDを定義して，カスタムリソースをapplyするとAdmissionWebhookのConfigurationと，それに合わせたWebhookのPodとServiceを作るようなコントローラを作っていた． このとき，CRDのscopeをNamespacedにしていたんだけど，NamespacedなカスタムリソースがCluster scopeのValidating/MutatingWebhookConfigurationをChildに持つ場合，がっつり上記に該当してGCされなくなる． 結果として，カスタムリソースを削除してもWebhookConfigurationが削除されないという状態になった．

対応

私の場合の話なので，2に該当する場合なのだけれど，OwnerがNamespacedである必要がないのであれば，OwnerをCluster scopeにしてしまえば良い．Cluster scopeなOwnerがCluster scopeなChildを持つことは特に問題ない．また，Cluster scopeなOwnerがNamespace scopeのChildを持つことも，特に問題はない．GCコントローラはちゃんとOwnerが消えたときにChildも消してくれる．

今回で言うなら，Validating/MutatingWebhookConfigurationのOwnerなので，別にCluster scopeで良くて，Cluster scopeに変更することで対応できた．合わせて作るPodとServiceのnamespaceをどこにするかは悩みどころではあったが．Cluster scopeなカスタムリソースもそれらのPodやServiceのOwnerになれるので，特に問題はなかった．

1についても同様なのだけれど，OwnerがCluster scopeで良いのであれば，Cluster scopeにすることで正しいOwnerReferenceになる．

問題はOwnerがNamespace scopeである必要がある場合なのだが，それってどんなケースなのか想像できないのでちょっと対応策も思いつかない……．

気づいた経緯

そもそもこの話は知っていたんだけど，完全に無関係だろうと思っていた．ので完全に油断していたんだけど，先日書いたkind local registryによりE2Eがそれなりの頻度でCIで走るようになったおかげで気づいた．

h3poteto.hatenablog.com

Kubernetes 1.20に上げたところでテストが落ちて，AdmissionWebhookが消えなくなっていたので，そこで問題が発覚した．

E2Eテスト便利や．

ちなみに記事でも紹介されてたけど kubectl-check-ownerrefefrences を使えば一発でわかるんで，これも便利だったよ．

github.com

kind local registryでCI内でテストを回す

Kubernetes関連のツールを作ったときなどに，E2Eテストをしたいことがある．実際にKubernetesクラスタに入れてみて，動かしてみてどうか，というのは開発環境でやるにしても結構手間だ． そういうときにkindはすごく便利なんだけど，これのlocal registryは更に便利だった．

Fediverse用のclient libraryを探す旅

この記事はFediverse (2) Advent Calendar 2020 の9日目です．大遅刻です． ちょうどこの週に引っ越しをすることになってしまって，「書く時間くらいあるやろー」と思ってたら，全然時間がなかったです．片付けて引っ越しして荷解きして，仕事できる状態までPC周りを復元して……とやっていたら全然書く時間が取れずにここまで遅刻しました．

それはともかくとして……．

Fediverseというとサーバの話をすることがどうしても多くなってしまうけど，クライアントアプリケーション開発者として日々APIに触れていると，クライアントライブラリを調べることが多い．

というわけで，FediverseのAPIを叩くクライアントライブラリを調査したときのメモを残しておく．

ちなみに，Fediverseが対象なので，Mastodon以外のクライアントライブラリも調べた．調べたのだが，正直Mastodon，Misskey以外は非常に数が少ない．クライアントアプリケーションもそこまで多くはないので，仕方ないのだろうが．

なお，俺がクライアントアプリケーションを作るときはJavaScript(TypeScript)で書いているので，普段はJSのライブラリ調査しかしていない．というわけで若干JS成分が多めである．

fluentd-sidecar-injectorをhelmでインストールできるようにした

以前fluentd-sidecar-injectorというものを作った．

h3poteto.hatenablog.com

AdmissionWebhookを使って，任意のPodにログ転送用のfluentdをサイドカーとして差し込むものだ．これの目的は，

標準出力以外の，例えばファイルに吐き出すようなログはどうなるだろう？ こういったログを集めるためには，アプリケーションのコンテナのサイドカーとしてfluentdを動かし，ログファイルをVolumeMountすることでサイドカー側のfluentdにログファイルを読ませる，というようなことをする必要がある． でもこれ， アプリケーションが増えてきたときに，毎回すべてのDeploymentにSidecarの定義書くのめんどくさくない？

というのを解決することだった．

これは変わってないのだが，いかんせんKubernetesのWebhookはインストールするのがめんどくさい．というわけでWebhookをセットアップするためのCustomResourceDefinitionとコントローラを作って，適切なリソース定義を書けばインストールできるようにした．これによりfluentd-sidecar-injectorはhelmでインストールすることができるようになった．

インストール方法を変えただけで，使い方は特に変わってない．