生涯未熟

生涯未熟

プログラミングをちょこちょこと。

Spring v4.0.0にアップグレードしたらbundle exec rails cが死んだ話

所属チームにRenovateを導入してウキウキ気分で依存ライブラリのアップグレードをやっていたのですが、Springをシュッとv4.0.0にアップグレードしたらbundle exec rails cなどが動かなくなりました・・・

どのように動かなくなったかというと bundle config set without test をやっているのに、何故かtest groupのGemが Could not find で怒られてしまい動かないという。

原因

最初、自分の設定類がおかしいのかと色々ガチャガチャと調査をしていたのですが、そんな折にこのStack Overflowを発見。

stackoverflow.com

で、回答にあったようにv3.1.1にダウングレードしてみると確かに動く🤔

問題となっているISSUEがこちらで

github.com

v4.0.0のアップグレードで今まで Bundler.with_original_env としていたところを Bundler.with_unbundled_env に変更した結果、 BUNDLE_ の環境変数が削除されてしまいました。
何が問題かというと BUNDLE_APP_CONFIG も削除されてしまうので、bundle config内のwithoutが参照できずに本来省かないといけないtest groupのGemもチェックされ、エラーとなってしまった感じですね。

数時間この問題にハマったので、みなさんもお気をつけください👀（ちなみにFix版のv4.0.1はまだ未リリース・・・

Linuxで動かしながら学ぶTCP/IPネットワーク入門を読んだ

bells17さんのメモ書きを読んで、そういえば積ん読になってたな〜と思い出したので引っ張り出して読みました。 zenn.dev

結論から言うと凄い良本でした。

感想

今までこの手のネットワーク本は「ネットワークはなぜつながるのか」くらいしか読んだことがなかったのですが（こちらもネットワークの入門書としては非常に良かったです）、概念は分かったけどももうちょっと具体的なところに手が届いていない感じがありました。そこを補うような内容が本書では書かれています。

最初困ったのは手を動かすための環境作りにvirtual box + vagrantを使うように書かれていたのですが、M1 Macを使っているとvirtual boxを使うことができません。
そのため、GCEでUbuntu 20.04のインスタンスを立ち上げ対応することに。。。

個人的に４章のイーサネットのブリッジの辺りや、NATのところは知識が薄かったので非常に学びがありました。スイッチングハブとリピータハブってそういうことなんだったんだなーとか。

あとは新しい学びというか改めてというところで、DHCPの説明への運びが上手いな〜と思っていて基本的には写経を中心に進めていく本書なのですが、章を進めていくごとに写経量がかなーり増えていきます。で、同じようなコマンドをタイプしまくるのに飽きたところで「DHCPを使えば君たちが今迄タイプしてたことは必要なくなるんだ！」って持っていき方は非常にわかりみが深くなって良い体験でした。

ということで、ネットワークの入門書としてはめちゃくちゃ良本でした。個人的には「ネットワークはなぜつながるのか」で大まかなイメージを掴んでおいて、副読本として本書を併せて読むのがベストなような気がしました。

cURLでIAP越えするためのトークンを吐き出す

zenn.dev

こちらの記事みたいに gcloud auth print-identity-token で取りたかったが上手く出来なかったので上手く出来るようにやってみた。

どう失敗した？

$ gcloud auth print-identity-token foo@bar.iam.gserviceaccount.com --audiences="hoge.apps.googleusercontent.com"

ERROR: (gcloud.auth.print-identity-token) Your current active account [XXX] does not have any valid credentials
Please run:

  $ gcloud auth login

to obtain new credentials.

For service account, please activate it first:

  $ gcloud auth activate-service-account ACCOUNT

なるほど〜🤔

どう対応した？

これをやった。

$ gcloud auth print-identity-token \
--impersonate-service-account=foo@bar.iam.gserviceaccount.com \
--audiences="hoge.apps.googleusercontent.com" \
--include-email

こんな感じでSAのなりすましでTokenを吐くことが出来る。 --include-email が付いているのはIAPの検証で使われるから（無かったらemailがないぞと叱られる）。
あと、未検証だけども前準備としてなりすますSAに gcloud auth login でログイン中のユーザーの サービス アカウント トークン作成者 権限を付与する必要があるかも。

Terminated, NodeShutdownのPodをCronJobで滅した

GKEを運用している中で何故かTerminatedやNodeShutdownなPodが残ったまんまになってるな〜〜〜と神経質な自分にとっては許しがたい事象が数ヶ月続いていました。
やっとこさ本腰入れて調査出来る時間が取れたので、この気持ち悪い状態で残ってるPodを滅するために調べました。

結論

結論これじゃーんって記事が見つかりました。

kamihikouki.hatenablog.com

Preemptible VMのせいか〜〜〜ありがてぇありがてぇと読んでたのですが、この一節見てほげ〜となりました。

ガベージコレクションされるまではずっと残ります。 この閾値は、GKEユーザーからは変更することができないようです。かつそのデフォルト値は12500と非常に大きいです。

ほげ〜〜〜そりゃ残ったまんまだわさ。
こりゃいかんと対策を探す旅へ。

対策

これも割とサクッと見つかりました。
先程の記事にもあった kubectl delete をCronJobで定期実行しましょうやという記事。

heschlie.blog

まぁそれくらいしかないですよね、という感じでまんまパクって動かしました。
で、ちゃんと全てのTerminated, NodeShutdown Podが滅されるようになりました。満足。

[追記: 2022/05/31 21:59]

記事中にあったkubectl deleteのコマンドより、こっちの方がいいかもしれない。

command:
  - /bin/sh
  - -c
  - kubectl get pods --all-namespaces | grep -i -e Terminated -e NodeShutdown | awk '{print $1, $2}' | xargs -r -n2 kubectl delete pod -n