Posts on meow.md

そとちゃん

Fri, 01 May 2026 00:00:00 +0000

そとちゃん

2025年11月14日

闘病生活が続く日のお昼。

突然そとちゃんが荒い口呼吸をはじめた。

少しショッキングな映像なので折りたたみ

その時が来たか、と思った。
(病院の先生からこういった症状が出ると危険だと聞いていた)

ある程度覚悟はしていたが、
1人だとおかしくなりそうだったのですぐに病院へ。

病院に着く頃には呼吸が少し落ち着いており、
検査してもらったが酸素飽和度に問題がないので苦しんではいないようだった。

呼吸が乱れた原因が腫瘍によるものか分子標的薬の副作用かはもうわからないので、
ひとまず投薬や給餌は中止、点滴のみやろうということになった。

入院の選択肢もあったがこの日は一旦帰宅。

帰宅すると急に動き出すそとちゃん。

さっきまでぐったりしていたのが嘘みたいに、
家の中を動き回る。

今思えば、これがエンジェルタイムというものだったのだろう。

そとちゃんは夜までこちらが心配になるくらい活発に動き回った。

ふらつきながら、でも力強く、
自分のナワバリをしっかりと調べていた。

夜になるとすこし落ち着いたが、
また少し呼吸が荒くなってしまった。

少しショッキングな映像なので折りたたみ

たくさん撫でると少し呼吸も楽になって、
お気に入りのベッドで安心した様子。

「また明日元気になってたくさん遊ぼうね、おやすみ」
日付がまわった朝2時半、そとちゃんに語りかけて俺は眠りについた。

2025年11月15日

次の日の早朝5時。

休日で普段ならまだ寝ているのに、
この日はやけに早く目が覚めた。

二度寝前に台所で水を一杯飲み、
そとちゃんの様子を確認する。

寝ているところに近づくとすぐ起きてしまうそとちゃんだが、
この日は目覚めることがなかった。

涙がとまらなかった。

たくさん感謝の言葉をかけた。

謝罪の気持ちもあったけど、それよりも感謝を伝えたかった。

少し落ち着いてから、
正式な診断とその後の処置をしてもらうためにいつもの病院へ。

早朝だったのでいつもと違う先生、看護師さんだったが、
とても優しい言葉をかけていただいた。

「最後まで本当に素敵なねこちゃんでしたね、がんばりましたね」
そういった言葉でそとちゃんと自分をたくさん褒めてもらった。
その度に涙が出た。

自分を責めることがないように言葉を選んでくれたのだとは思うが、
ただただ嬉しかった。

亡くなる瞬間に立ち会えなかったのでこれは本当なのか先生の優しい嘘かはわからないが、
状況から窒息ではなく体の機能がすーっと止まったような形で、
最後も苦しまずに逝けたのではないか、とのことだった。

それなら安心だし、そうであってほしい。

2025年11月15日朝5時推定9歳6ヶ月
そとちゃんは短い一生を生き切った。

お別れ

その後、
たくさんの友人が手を合わせに来てくれた。

たくさんの優しい言葉をいただいた。

そとちゃんは本当に愛されていたんだな。
そう実感するたびに涙が出た。

本当はそとちゃんの身体もずっとこのまま残しておきたかったが、
腐ってしまうのはかわいそうなので火葬することにした。

小さな、本当に小さなお葬式をした。

最後は体重2.3kgしかなかったが、元気な時でも最大4kgだったそとちゃん。
棺も最小サイズだった。

そとちゃんを炉に入れる直前はもう、
涙どころか鼻水もよだれも止まらなかった。

あんなに人前で取り乱したことはないんじゃないかというくらい、
どうしようもなくなってしまった。

たくさん喚いて少し落ち着いたころ、
そとちゃんのお骨が返ってきた。

頭以外は健康そのものだったので状態は良く、
立派な骨になって返ってきた。

骨になってもかわいいなんて、
やっぱりそとちゃんはすごいねこだ。

あまり大っぴらに見せるものでもないので折りたたみ

式場の方にも優しい言葉をかけていただき再び号泣。

本当に泣いてばかりだった。

お骨は埋葬せず、
しばらくは家で一緒にいることにした。

ふるさと

お葬式を終えてしばらく経ち、年も明けたころ。
そとちゃんを保護してくださった群馬の保護主さんのところを尋ねた。

https://www.larcenchat.com/

保護主さんとお会いするのはそとちゃんがうちに来た日以来で、
たくさんお話をさせていただいた。

信じてそとちゃんを託してくれたのに長生きさせてあげられなかった、
謝罪の気持ちを伝えたかったが、
それよりも先にたくさんの優しい言葉をいただいた。

言葉の一つ一つが本当に嬉しかった。

そとちゃんの後輩となる保護猫ちゃんたちとも遊ばせてもらった。

ねこちゃんに触れるのも数ヶ月ぶりだったので、
久しぶりに暖かい気持ちになれた。

カフェで素敵な時間を過ごした後、
そとちゃんが保護された場所を訪問した。

本当に静かで、のんびりとした場所だった。

こういうところで生まれ育ったからあんなに優しいねこになったのかな、
なんて考えたりした。

そとちゃんはこの場所で、産気づいた状態で保護された。
そとちゃんの子かはよくわかっていないが、保護される前は別の複数の子猫と一緒にいたところも目撃されていたらしい。
(その後保護主さんのところで2匹出産している)

そとちゃんはもういないけど、
そとちゃんの生きた証はこの世界に残っている。
そう考えると嬉しいし、少し寂しさが薄れた気がした。

ありがとう

そとちゃんがうちに来てくれてからの6年半、
本当に幸せな毎日だった。

結局一度も「シャーッ」「フーッ」と怒ることのなかった、心のやさしいねこだった。

おもちゃ遊びは好きだけど、
それよりもごろごろするのが好きだった。

イタズラなんてほとんどしないおりこうさんで、
人間よりも家をきれいに使ってくれた。

一緒にいるとたのしくてあたたかくて、
とにかく笑顔にさせてくれた。

今もスマホのカメラロールを辿ればそとちゃんの姿がたくさん残っていて、
一緒に過ごした日々を思い出して幸せな気持ちになれる。

うちに来てくれてありがとう。

ごはんの好き嫌いはあったけど、
おいしそうにおやつを食べてくれてありがとう。

ひざに乗ってくれてありがとう。
一度乗ると全然動かないから脚がしびれたけど、幸せだった。

撫でさせてくれてありがとう。
ブラシが嫌いなのに毛並みはいつもきれいだった。

たくさんおしゃべりしてくれてありがとう。
俺はねこの言葉がわからないしそとちゃんも人間の言葉がわからないけど、
毎朝2人でおしゃべりするのがたのしかった。

自慢の長いしっぽを揺らしてくれてありがとう。
ピンクの肉球を触らせてくれてありがとう。
最後まで喉を鳴らしてくれてありがとう。

初めて一緒に暮らしたねこがそとちゃんで本当によかった。　

世界一の最高のねこでした。

10月と11月のそとちゃん

Sun, 08 Feb 2026 00:00:00 +0000

そとちゃん

食欲不振

9月末ごろから食欲不振でごはんをあまり食べなくなったそとちゃん。

10月に入ってからは好きだったおやつもほとんど食べなくなってしまった。

お水は自分から飲んでくれるけど、
食べ物には全然反応しない…

何日か水しか飲まない状態が続き、
お腹が空きすぎて吐く?ようなことがあったので再び病院へ。

当日の体重は2.9kg。

1週前に病院で計ったときが3.22kgだったので、
わずか7日で300g近く落ちてしまったことになる。

超音波検査の結果、胃腸炎の疑いが出た。

9月後半に追加したビクタスが少し強い薬なのでそれが影響した可能性が高いとのこと。

さらに前回追加で行った細菌検査の結果が返ってきていて、
弱い方の薬リレキシペットがそとちゃんの耳漏から採取した菌に効果があることがわかった。

胃が荒れる原因になっている可能性があり、
弱い薬でも十分効く見込みがあるとのことで、
吐き気止めのお薬を追加しビクタスは休薬することに。

胃腸炎の他に腎臓の悪化も影響しているかも?とのことなので、
さらに点滴も入れてもらった。

ひとまずこれで様子を見て、
それでも改善しないようなら点滴の頻度を増やすことになった。

強制給餌

病院から戻って数日経っても症状は改善せず…

吐くことはなかったが、
相変わらずお水を飲むだけでごはんを全く食べない状態が続いた。

なにもお腹に入らない状況は流石にまずいので、
この頃から強制給餌を始めた。

ドライフードを小さく割り、
お薬の錠剤と同じ要領で上を向かせた状態で口を開けて飲み込ませる。

9月末からお薬はこの方法で飲ませていて、
そとちゃんも俺も割と慣れていたのでスムーズに飲ませることができた。

が、問題はその量。
ドライフードを飲ませられる量は一回で高々1,2粒なので、
必要なエネルギー(カロリー)は全然足りない。

そとちゃんの負荷もしんどそうで、
どうしよう…となり、点滴も兼ねて再び病院へ。

点滴

この日は血液検査とエコー検査をしてもらった。

血液検査の結果、
腎臓の数値は9月に行った猫ドック時とあまり変わらず少し高めの数値で、
悪くなってはいないが良くもなっていないという状況。

エコー検査では強制給餌したドライフードがお腹の中でうまく消化できず残っていることが確認された。

胃腸炎は治っていそうだが、
何日間かごはんを食べていなかったのもあり、
消化器自体の働きがあまりよくない様子。

この日の体重は2.8kgで、
たった数日で100gも落ちてしまっていた。

先生に強制給餌の件を相談し、
より高カロリーで消化器への負担も少ないロイヤルカナンの流動食を与えることになった。

流動食を入れたシリンジを口の横から差し込み、
吐かないように少しずつ入れていく。

嫌がるなのは変わらないが、
ドライフードよりはあげやすそうになってよかった。

とはいえ自力で食べてくれることが一番なので、
この日は耳に塗る食欲増進剤を追加してもらい、
さらに腎疾患の疑いを見て毎日点滴に通うことになった。

食欲復活

…が。

その日の夜にいつも通りダメ元でおやつを出したところ、
急にガツガツ食べ始めた!

自分から食べるなんて本当に久しぶり。

その後は朝のおやつも完食。

超えらい。

点滴の効果が出るには早すぎるということで、
おそらく食欲増進剤が効いたのか…?

とはいえ腎臓の数値は心配なので、
先生とも相談して念の為毎日の点滴は継続。

いいかんじ

この頃のそとちゃんは絶好調。

おやつメインではあるものの自分から食べてくれるようになり、
強制給餌の割合も減っていった。

たくさん食べたおかげで、体重も2.95kgまで復活。

毎日の点滴通いもがんばってくれて、
4日目には脱水症状もだいぶ改善していたので頻度を週1に減らせることになった。

前庭疾患

食事の問題は改善したものの、
一番の問題である前庭疾患がなかなか良くならない。

首の傾きはだんだん角度がきつくなっているように見えるし、
やっぱり左耳が痛いのかな…?

この頃から鳴き声も少し変になってきた。

前は高い声でかわいくおしゃべりしてくれていたのだが、
若干低めでダミ声のような鳴き方をするようになった。

(近づくと爆音ゴロゴロするのは変わらず。かわいい)

また、先生が診察中に気付いたのだが、
顔面の左側(正面から見て右側)が麻痺しているようだった。

瞬膜がちゃんとひっこんでいることもあるのだが、
出っ放しのときは見た目がかわいそうで、
これが個人的にはかなりつらかった。

流石に左目が見えづらいとそとちゃんも気になるのか、
今まで目ヤニが出やすかったりで閉じがちだった右目が逆にぱっちり開くようになった。
(諦めずに目薬を頑張ってきてよかったね…)

こんな感じで、
前庭疾患の症状は良くなるどころか少しずつ悪くなっているようだった。

二次診療

そんなこんなで投薬と通院が続く中、
先生から脳神経科での二次診療(CT/MRI)の打診をいただいた。

食欲不振と脱水症状はかなり改善した。
抗生剤も細菌検査を実施した上で1ヶ月以上続けている。
なのに症状が改善しない。

これは本当に細菌性の中耳炎なのだろうか？
何か別の原因があって、耳漏や菌はその影響ではないだろうか？とのことだった。

9月に最初の発作が出た時に実は「腫瘍性の問題も一応考えられる」というお話を受けていたが、
症状から最も当てはまるのが中耳炎ということで先生も俺も治療を続けてきた。

でもこの状況では抗生剤を続けても改善が見込めない。
一度腫瘍性の問題を考え直すべきではないか。

正直、考えたくなかった。

抗生剤を続けていれば中耳炎は治り、
元のそとちゃんに戻ると信じてお互い嫌な思いをしながら頑張ってきたのに。

でも、このまま症状が治らずそとちゃんが居なくなる、なんてのはもっと嫌だった。
今の治療で治る見込みが薄いなら、他にできることを見つけたい。

そんな思いで、日本動物高度医療センター(JARMeC)での検査を受けることにした。

当日病院に着いて、まずはレントゲン検査と血液検査。

レントゲン検査の結果はあまり良くなく、
9月の猫ドックでも確認したように耳の奥の骨が溶けているのに加え、
耳の穴から内耳までの経路が何か(膿?腫瘍?)で塞がれてしまっているようだった。

血液検査の結果は腎臓の数値が基準値を超えていて、
そとちゃんの体力が落ちていることを考慮すると全身麻酔をかけての検査にはかなりリスクがある状態。

とはいえ、これは事前にかかりつけの先生とも相談した上で決めていたし、
何よりもそとちゃんの生きる力を信じてサインすることにした。

そとちゃんを預けて半日待機。
あまり生きた心地はしなかった。
「やっぱり中耳炎でした」となることだけを祈って待っていた。

受け取りの時間が来て、
そとちゃんは無事に麻酔から目が覚めていた。

まずは無事に意識が戻ってよかった。
ほんとうにがんばってくれて、すごいねこだ。

CT検査の結果は、
悪性腫瘍(がん)の疑いが強いとのことだった。

耳から第一頚椎にかけて病変が広がっており、頭蓋骨も溶かして脳に到達しているような状態。
中耳~前庭にかけて組織が広範囲に壊れていて、神経疾患の原因はこれで間違いない。

実際の病変を採取して細胞診検査に回したが、
この段階で確定はできないものの炎症や白血球の増大が見られないため、
膿ではなく腫瘍の可能性が非常に高い。

大きなくくりでの症状としては中耳炎+前庭疾患に違いないが、
その原因が細菌性である可能性はほぼゼロ、ほぼ確実に腫瘍に由来するものだろう。

細胞診検査の結果待ちではあるものの、
悪性腫瘍であった場合はすでに脳の広範囲に広がっていることから、
物理的な切除は難しい。

余命は残り数ヶ月との宣告を受けた。

無理やりメモから書き起こしてはいるが、
このとき自分が何を考えていたか、あまり覚えていない。

病院からの帰り道、十数年ぶりに声を上げて泣いたことだけは覚えている。

緩和ケア

二次診療の結果を受けて、かかりつけの先生と相談。

痛みと炎症緩和のため、ステロイド系のお薬を追加し、
抗生剤の量は減らすことになった。

リレキシペットは飲む回数が多く負担がかかるので、休薬していた一日一回のビクタスを再開。
通院も負担がかかるので、これまで通いで行っていた点滴を家で実施。

とにかくそとちゃんが残りの時間を穏やかに過ごせるためにやっていこうということになった。

もう総合栄養食と一般食とかを気にする段階でもないので、
食べられるうちは大好きなおやつをたくさん食べさせてOK。

ニンゲンは悲しいけど、ねこは嬉しいね…

歩行の衰えにも備えて、
トイレを変えたり、ペット用ステップを追加したり。

念の為つけていたペットサークルもそとちゃんが寂しい思いをしないように撤去。

そとちゃんと一緒に過ごす時間を最優先にした。

強制給餌再び

そとちゃんの緩和ケアを始めて、11月になった頃。

だんだんとおやつも残すことが増えてきて、
ついにちゅーるすら食べなくなってしまった。

これまで効果があった食欲増進剤を試しても効果が出ず、
強制給餌を再開することになった。

神経症状で口をあけるのも辛くなってきたのか、
以前よりも嫌がるように。

頑張って飲んでくれるけど、その後は毎回ふきげん。

これまではごほうびのおやつでごまかせたけど、
それができないのでどうやって機嫌を直したらいいかもわからない。

とにかく給餌の後はたくさん褒めて、
逃げたときも無理に追わずに放置するようにした。

そとちゃんが嫌がっているのは明らかだったが、
命を少しでも繋ぐために食べさせるしかなかった。

細胞診検査の結果

強制給餌を再開して少したった頃、二次診療で行った細胞診検査の結果が届いた。

確定診断の結果は悪性上皮性腫瘍。

そとちゃんががんを患っていることが確定した。

あまりにも広範囲に広がっているため、
由来(耳垢腺がん/唾液腺がん/扁平上皮がん)の特定はできなかったそう。

再度かかりつけの先生と相談。

がんに対する治療をするのか、
それはせずにこのままステロイドの投与を続けるのか。

リスクを説明してもらった上で、
自分は抗がん剤(分子標的薬)での治療を選択した。

外科手術は不可能、放射線治療もそとちゃんの体力を考慮すると非現実的。
そんな状態でも腫瘍による神経の圧迫や耳漏を少しでも和らげられれば…と思っての判断だった。

この時点でもう完治を目指すつもりはなく、
あくまで楽にしてあげるための抗がん剤。

分子標的薬は一般的な抗がん剤に比べると効果もリスクも抑えめとのこと。
1,2回試してなにか苦しそうであればすぐやめてステロイドのみに切り替える。
そう決めて投与することにした。

抗がん剤

1回目の投与。

思ったよりも錠剤が大きく、
飲ませるのが大変だった。

初回なので投与後は2日程度様子を見る。

副作用が出た場合は下痢や嘔吐が出るはずだが、
そのような兆候は見られなかった。

残りの時間

そとちゃんは何を考えていただろうか。

自分に残された時間を理解していたかはわからないが、

強制給餌や抗がん剤治療が始まってからも毎日これまでと同じく、

たくさん寝て、

たまに起きて風呂場の水を飲み、

暖かいところを探してもうひと眠り。

また起きては爪を研ぎ、

お気に入りの紙袋にもぐって過ごした。

毎日楽しく、好きなことをたくさんして1日1日を大切に過ごしていた。

(つづく)

おまけ

Dify Console APIをcURLで呼び出してみた(v1.9.2 CSRF Token対応)

Sat, 25 Oct 2025 00:00:00 +0000

まとめ

セルフホスト版Dify(Community)で、非公開?のコンソールAPIがある
v1.9.2から、ログイン時に取得できるトークンの扱いが変わった
- トークンをこれまでのレスポンスボディでなくcookieに入れて返してくるのでそのまま使うのが良い

# login API: https://github.com/langgenius/dify/blob/1.9.2/api/controllers/console/auth/login.py#L44
email="hogehoge@uzimihsr.com" # Difyアカウントのメールアドレス
password="xxxxxxxx" # Difyアカウントのパスワード
base_url="http://localhost" # localhost以外で立ててる場合はそれに合わせて変更
curl -c cookie -X POST "${base_url}/console/api/login" -H 'Content-Type: application/json' -d "{\"email\":\"${email}\",\"password\":\"${password}\"}"
csrf_token=$(grep csrf_token cookie | cut -f7)

#　profile API: https://github.com/langgenius/dify/blob/1.9.2/api/controllers/console/workspace/account.py#L97
curl -sSf -X GET -b cookie -H "X-CSRF-Token: ${csrf_token}" "${base_url}/console/api/account/profile"

環境

Dify v1.9.2
- docker composeで起動

経緯

Difyの管理用APIであるConsole APIは公式ドキュメントで公開されていないもののなかなかに便利で、
ユーザー、ワークスペース、モデルプロバイダー、ツール、アプリなどの管理をUIでなくAPIで実行できるのでDify運用の自動化に使えそう。

一応GitHubのリポジトリを確認すると、このあたりで各種APIの中身が確認できる。
https://github.com/langgenius/dify/tree/main/api/controllers/console

実際に使われている偉大な先駆者様達の例↓

ところが、
最近セルフホスト版Difyのバージョンを最新の1.9.2に上げたところlogin API(POST /console/api/login)でAPIを呼ぶためのトークンが取れなくなってしまった。
(偉大な先駆者様達のコードも1.9.2ではおそらく動かなくなっている)

$ # login API: https://github.com/langgenius/dify/blob/1.9.2/api/controllers/console/auth/login.py#L44
$ # アカウントのメールアドレス(email)とパスワード(password)をJSONでPOSTするとログインできる
$ email="hogehoge@uzimihsr.com" # Difyアカウントのメールアドレス
$ password="xxxxxxxx" # Difyアカウントのパスワード
$ base_url="http://localhost" # localhost以外で立ててる場合はそれに合わせて変更
$ curl -X POST "${base_url}/console/api/login" -H 'Content-Type: application/json' -d "{\"email\":\"${email}\",\"password\":\"${password}\"}"
{"result":"success"}
$ # レスポンスボディにアクセストークンが入ってない!

困ったのでちょっと調べてみた。

ソースコード調査

結論から言うとこれ。

v1.9.1まではlogin APIがアクセストークンをレスポンスボディ(.data.access_token)で返していたのが、
セキュリティ向上を目的にHttpOnly Cookieに埋め込んで返すようになったらしい。

curlの-vオプションで実際にCookieの中身を確認してみる。

$ curl -v -X POST "${base_url}/console/api/login" -H 'Content-Type: application/json' -d "{\"email\":\"${email}\",\"password\":\"${password}\"}"
Note: Unnecessary use of -X or --request, POST is already inferred.
* Host localhost:80 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
* Trying [::1]:80...
* Connected to localhost (::1) port 80
> POST /console/api/login HTTP/1.1
> Host: localhost
> User-Agent: curl/8.7.1
> Accept: */*
> Content-Type: application/json
> Content-Length: 52
>
* upload completely sent off: 52 bytes
< HTTP/1.1 200 OK
< Server: nginx/1.23.1
< Date: Sat, 25 Oct 2025 07:30:12 GMT
< Content-Type: application/json
< Content-Length: 20
< Connection: keep-alive
< Set-Cookie: access_token=eyJhxxxxxxxxxxxx.eyJ1c2xxxxxxxxx.VzvJKdUxxxxxxxx; Expires=Sat, 25 Oct 2025 08:30:12 GMT; Max-Age=3600; HttpOnly; Path=/; SameSite=Lax
< Set-Cookie: refresh_token=a4ac94922exxxxxxxxxx; Expires=Mon, 24 Nov 2025 07:30:12 GMT; Max-Age=2592000; HttpOnly; Path=/; SameSite=Lax
< Set-Cookie: csrf_token=eyJhbxxxxxxxx.eyJleHAixxxxxxx.uSNFW3Fxxxxxxxx; Expires=Sat, 25 Oct 2025 08:30:12 GMT; Max-Age=3600; Path=/; SameSite=Lax
< X-Version: 1.9.2
< X-Env: PRODUCTION
<
* Connection #0 to host localhost left intact
{"result":"success"}

たしかにHttpOnlyなCookie(access_token, refresh_token)にトークンが埋め込まれている。

うまくいかない

じゃあCookieを使えばいいじゃん、ということで-cオプションでそのままCookieを保存して投げてみる。

$ # cookieをファイルに保存
$ curl -c cookie -X POST "${base_url}/console/api/login" -H 'Content-Type: application/json' -d "{\"email\":\"${email}\",\"password\":\"${password}\"}"
{"result":"success"}

$ # profile API: https://github.com/langgenius/dify/blob/1.9.2/api/controllers/console/workspace/account.py#L97
$ # 自分のアカウント情報を確認できる
$ curl -X GET -b cookie "${base_url}/console/api/account/profile"
{"code":"unauthorized","message":"CSRF token is missing or invalid.","status":401}
$ # が、失敗...

だめ。

再挑戦

トークン周辺のコードをもう少し調べる。

https://github.com/langgenius/dify/blob/1.9.2/api/libs/login.py#L79
https://github.com/langgenius/dify/blob/1.9.2/api/libs/token.py#L171
どうやらX-CSRF-Tokenヘッダにcsrf_token Cookieを与えないとだめっぽい。
(login APIが返すCookieのうち、これだけHttpOnlyじゃないのでJavaScriptでも触れる)
CSRFトークンってこうなってんだね…

ということでもう一度試してみる。
Cookieを直接触ってしまっているが、
上記の通りcsrf_tokenに限りHttpOnlyじゃないのでこれは実際のUIの挙動と同じはず。

$ # cookieをファイルに保存
$ curl -c cookie -X POST "${base_url}/console/api/login" -H 'Content-Type: application/json' -d "{\"email\":\"${email}\",\"password\":\"${password}\"}"
{"result":"success"}

# cookieファイルの中のcsrf_token(not HttpOnly)の値を取得
$ csrf_token=$(grep csrf_token cookie | cut -f7)

$ #　profile API: https://github.com/langgenius/dify/blob/1.9.2/api/controllers/console/workspace/account.py#L97
$ # 今度はX-CSRF-Tokenを添えて...
$ curl -sSf -X GET -b cookie -H "X-CSRF-Token: ${csrf_token}" "${base_url}/console/api/account/profile" | jq
{
 "id": "932a9004-b67c-422d-b7aa-89b11d8e04b5",
 "name": "hogehoge",
 "avatar": null,
 "avatar_url": null,
 "email": "hogehoge@uzimihsr.com",
 "is_password_set": true,
 "interface_language": "en-US",
 "interface_theme": "light",
 "timezone": "America/New_York",
 "last_login_at": 1761380052,
 "last_login_ip": "172.30.0.1",
 "created_at": 1758760919
}
$ # できた!

やったぜ。
DifyのConsole APIを呼び出して、ユーザー情報を取得することができた。

おわり

うまいこと使って、
Difyで作ったアプリだけじゃなくてDify自体の管理も自動化できたらいいな〜。
(というか公式でConsole API SDK出ないかな…)

おまけ

PyPIで古いバージョンのwheelが削除されてないちゃった

Wed, 15 Oct 2025 00:00:00 +0000

まとめ

ある日PyPIからPyAV 10.0.0のwheelが消えてpip installがうまくいかないことがあった
PyAVに限らず、PyPIで公開されているパッケージのwheelは削除されることがある
どのパッケージも最新版はだいたいwheelが公開されているのでなるべく新しいバージョンを使おう!

昨日まで動いてたのに…

PyAV 10.*系に依存しているプロジェクトを開発していて、
ある日何気なく再インストール(pip uninstall & pip install)したらこれまでインストールできていたものが急に失敗してしまった。

(DockerのPythonコンテナで実施: docker container run --rm -it python:3.10.12 /bin/bash)

(tutorial-env) root@e199492ba090:/# pip install av==10.*
Collecting av==10.*
 Downloading av-10.0.0.tar.gz (2.4 MB)
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.4/2.4 MB 17.7 MB/s 0:00:00
 Installing build dependencies ... done
 Getting requirements to build wheel ... error
 error: subprocess-exited-with-error

 × Getting requirements to build wheel did not run successfully.
 │ exit code: 1
 ╰─> [11 lines of output]
 Package libavformat was not found in the pkg-config search path.
 Perhaps you should add the directory containing `libavformat.pc'
 to the PKG_CONFIG_PATH environment variable
 Package 'libavformat', required by 'virtual:world', not found
 Package 'libavcodec', required by 'virtual:world', not found
 Package 'libavdevice', required by 'virtual:world', not found
 Package 'libavutil', required by 'virtual:world', not found
 Package 'libavfilter', required by 'virtual:world', not found
 Package 'libswscale', required by 'virtual:world', not found
 Package 'libswresample', required by 'virtual:world', not found
 pkg-config could not find libraries ['avformat', 'avcodec', 'avdevice', 'avutil', 'avfilter', 'swscale', 'swresample']
 [end of output]

 note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

なんでやねん…と思いながらもログを見てみると、
なぜかsdist(av-10.0.0.tar.gz)をダウンロードしてwheelをローカルでビルドしようとしている。
(そしてビルドに必要なFFmpegのパッケージが実行環境にないため失敗している)

wheelはどこへ消えた?

Python Packaging User Guideにも説明がある通り、
そもそもローカルでwheelをビルドしようとしているのはpipが対象のwheelを見つけられなかったからである。

When pip, the standard Python package installer, cannot find a wheel to install, it will fall back on downloading a source distribution, compiling a wheel from it, and installing the wheel. https://packaging.python.org/en/latest/discussions/package-formats/#what-is-a-source-distribution

ということは、これまではwheelが見つかる状態だったのにある日から対象のwheelが取得できなくなった？

実際にPyPIでPyAV 10.0.0のFilesを確認すると、たしかにsdistだけ残っていてwheelが消えている。
https://pypi.org/project/av/10.0.0/#files

(ちなみにWayback Machineで過去のページをみるとwheelが公開されていた痕跡が…)

いきなりwheelが消えるなんて、そんなことある…？

…

ありました。

「PyAV 9.2.0のwheelがPyPIから消えたんだけど！(意訳)」というissueでのコメント。

Old binary wheels were removed to have space for the 14.4.0 release.
https://github.com/PyAV-Org/PyAV/issues/1906#issuecomment-2899577746

「古いwheelは新しいバージョン(14.4.0)リリースの領域を確保するために削除した(意訳)」

はえ〜…
そんなことあるんすね…

自分がPyPIに詳しくないので初めて知ったのだが、
どうやらプロジェクトあたり最大10GBまでのサイズ上限があるらしい。

PyPI imposes storage limits on the size of individually uploaded files, as well as the total size of all files in a project.
The current default limits are 100.0 MB for individual files and 10.0 GB for the entire project. https://docs.pypi.org/project-management/storage-limits/

まあサイズ上限があるなら古いやつから消すよな…
ソース(sdist)さえあればビルドできないわけじゃないし… ~~(自分の環境はダメだったが)~~

ちなみに「重要なパッケージはたとえOwnerであってもPyPI上からの削除を制限した方が良いのでは?」的な議論もあるっぽい。
自分も使う側の人間なので気持ちはわかるが、開発者に責任を押し付けすぎでは？とも思う。
OSSむずかしい…。
https://discuss.python.org/t/stop-allowing-deleting-things-from-pypi/

あとはPyPIから削除されたwheelをアーカイブしているサイトもいくつかあるようだが、
非公式でメンテナンスは期待できないだろうし、
なにかあった時に自己責任なのであんまり触りたくないな〜という気持ち。
https://dashboard.stablebuild.com/pypi-deleted-packages/

素直にバージョンを上げよう

じゃあどうすんねんという話だが、
古いバージョンへの依存をやめれば良い。

バージョン縛りをなくしたところ、あっさり成功。
https://pypi.org/project/av/16.0.1/#files で公開されている最新版のwheelをダウンロード&インストールできた。

(tutorial-env) root@6673fc741395:/# pip install av
Collecting av
 Downloading av-16.0.1-cp310-cp310-manylinux_2_28_aarch64.whl.metadata (4.6 kB)
Downloading av-16.0.1-cp310-cp310-manylinux_2_28_aarch64.whl (38.2 MB)
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 38.2/38.2 MB 21.9 MB/s 0:00:01
Installing collected packages: av
Successfully installed av-16.0.1
(tutorial-env) root@6673fc741395:/# python
Python 3.10.12 (main, Aug 16 2023, 08:07:04) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import av
>>>

やったぜ。

…というより、そもそも3年前のバージョンに依存して使ってる方が悪いな、これ。
完全に自業自得。
これだけ古いと脆弱性も見つかってるだろうし、そこらへん自分で運用管理できてないのがバレバレ。
自力でビルドもできないOSSフリーライダーはなにをやってもダメ。

よいこのみんなはおとなしく提供元の意向にしたがって最新のバージョンを使いましょう。

おわり

Python弱者すぎてこんなので1日消耗してしまったので、備忘録として書いてみた。

PyPIやpipについてあまり理解せずに使ってしまっていたので勉強になったが、
そもそも古いバージョンに固定して放置している怠惰な自分が悪いわけで、
おそらく大多数の人はひっかからない気がする。

~~他のパッケージでもpip install時のログで急にtar.gzをダウンロードしてるときはPyPIでwheelが配布されているか確認するとよさそう。~~
弱者はおとなしく新しいバージョンを使おう!

おまけ

9月のそとちゃん

Sat, 11 Oct 2025 00:00:00 +0000

そとちゃん

発作?

9月2日のお昼。

いつも通り家で仕事をしていると、
そとちゃんが居る居間から「ガタン」と大きな音とそとちゃんの鳴き声がした。

様子を見に行くとバリバリベッドの横でそとちゃんが転がっていた。

最初は寝ぼけて落ちたのかと思ったが、
なにか様子がおかしい。

よくみると黒目が左右に揺れている。

歩き方もふらついていて、
至る所にぶつかってしまう。

おそらく発作のようなものが起きていて、
明らかにいい状態ではないのですぐに病院へ。

この時点では発作の原因は不明。

血液検査では腎臓の数値が少し高めなこと以外は何も見つからず、
身体検査も脚の神経反射は正常で、骨折などの怪我もなさそうだった。

突発性の発作は高齢猫に起こりうるものなので、
まずは様子を見て発作(のようなもの)が1日に何回も起きたり、
5分以上の長い発作が出るようなら専門的な治療を検討するということになった。

若干脱水気味だったので、
この日は点滴だけ打って帰宅。

ふらふら生活

病院から戻った後はケロッとしていて、
おやつを食べていつも通りゴロゴロ。

基本的には今まで通り元気なのだが歩くときはふらふらしていて、
ジャンプや着地に失敗することが多かった。

だんだん自分でも嫌になってきたようで、
1週間くらい経った頃には自分から高いところに登らなくなり、
ずっとベッドでゴロゴロしていて元気もなくなってしまった。😭

懸念の発作は突然体がビクッと動いて眼振が出るようなものがたまにあったが、
そんなに長続きするものでもなく週に1,2回あるかないか、という感じだった。

あまりひどい発作はなさそうだが見ていないところで危ない転び方をされると怖いので、
このタイミングでニトリのペットサークルを購入。

本人は嫌そうだが、安全のためには仕方ない…

猫ドック

最初の受診から約2週後。

あれからもひどい発作はないもののそとちゃんの調子があまり戻らないことと、
前回(2月に実施)からの頻度がちょうどよかったのもあり、
半年ぶりの猫ドックを受けることにした。

朝に病院に預けて、夕方お迎え。

詳細な結果は後日受領したのだが、
お迎えのタイミングで当日わかった所見として 左耳中耳炎からの前庭疾患 という診断が出た。

左耳がかなり汚れていたのと、
レントゲンでも左側の耳の骨が溶けているような見え方をしていることから外耳炎または中耳炎はほぼ確定、
さらに発作(眼振)やふらつきといった症状が継続しており前庭疾患の疑いが強いということだった。

前庭疾患の特徴としては平衡感覚が狂って気持ち悪い状態が続くもの。
実際に出ている症状もまさにそれに起因する感じなのでほぼ決まり。

また、眼振というのは異常がある方向に引っ張られることが多いらしく、
眼振の動画をよくみると黒目が左耳方向に引っ張られてからゆっくり中央に戻るような感じで、
まさに左耳が原因と思われる。

まずは原因がわかって一安心。
(実は初診の際、発作の原因が不明の場合は手の打ちようがない=発作を緩和する治療しかないと言われていた)

他に腎機能の低下などもあったのだが、
ひとまず中耳炎の治療を最優先で進めることに。

完治までは3ヶ月から半年くらいはかかるとのことで、
そとちゃんの長い闘病生活が始まった。

おくすり

中耳炎の治療では抗生剤を飲むことになり、
今回はリレキシペットA錠75が処方された。

まずは体の内側から炎症の原因となる菌を抑えるのが目的で、
これが効いてきたら今度は体の外側から与える薬に移行していくとのこと。

お薬を飲むのは得意なそとちゃん。

いつも通り砕いてちゅーるに混ぜたらちゃんと食べてくれた。

これが効くとよかったのだが…

通院①

当分の間は毎週通院することになったので、1週間後に再診。

結果はなかなか厳しいものだった。

1週前からの症状が改善していなかったのに加え、
さらに耳が痛いのか首が傾くようになるなど悪化している様子だった。

元々長期間の治療を想定していたが、
抗生剤が菌に合ってない可能性を考えて薬を追加することになった。

新しく追加したのはビクタスSS錠20mgで、
これまで与えていたお薬よりも対象となる菌の種類が多いため効果が期待できるとのこと。

ただしこれは耐性菌ができやすいということでもあるので、
今後を考えると先生もあまり使いたくなかったらしい。

そのため、この日は菌を特定するために耳垢、膿を採取して試験(培養)に回し、
対象が特定できたらそれに効く薬に変えることになった。

さらに脱水気味の状態だったので、点滴を打ってもらってこの日は帰宅。

食欲不振

お薬を増やしてから最初の数日はちゃんと食べてくれていたのだが、
だんだんと薬入りちゅーるへの反応が悪くなってきた。

薬が増えて味が悪くなったのか前庭疾患による食欲不振なのかはわからないが、
あんなに大好きだったちゅーるに反応を示さないというのはかなりショックだった。

試しに薬を薄めたり薬なしのちゅーるも出してみたがそれすら無反応なので、
おそらく後者(食欲不振)が原因だとは思うが…

他のおやつなら気分が向けば(?)たまに食べることもあるので、
それを祈るしかないという状況…

通院②

さらに1週後、9月4度目の通院。

状況はあまり良くなっていなかった。

初期のような眼振は発生しなくなったが、
依然ふらつき等の症状はそのまま。

さらに前回の診察で試験に回した耳の菌はサンプルが弱く特定まで至らなかったため、
再度試験を行いその結果が出るまでは今のお薬2種を継続することになった。

特に心配だったのは体重がさらに減っていたこと。

猫ドックの時でも3.34kgしかなかったのに、
この1週間で3.22kgまで落ちてしまっていた。

この週はご飯とおやつをほぼ残していたのでおそらくそれが原因。

特に薬入りちゅーるを食べないと状況もよくなるはずがないので、
今後はそとちゃんの口を開けて強制的に錠剤を飲ませることになった…

おわり

そとちゃんの病気に気づけなかったのがただただ悲しい。

先生からは適切な頻度で健康診断(猫ドック)を受けていたのが良かったとは言われたものの、
普段から耳を掻いているところを見ていたのになんで気づけなかったのか？と自分を責める気持ちも出てきてしまう。

9月は最初から最後までこんな感じでそとちゃんの状態が悪く、
それに引きずられる形で自分自身の精神も正直あまり良い状態ではなかった。

もちろん一番辛いのはそとちゃんなので早く治してあげたいが、
先は長そう…

おまけ

8月のそとちゃん

Sat, 13 Sep 2025 00:00:00 +0000

そとちゃん

バリバリベッド

そとちゃんは窓際にあるバリバリベッドがすき。

使いすぎてボロボロになってきたので、新しいものを購入。

新品ってこんなに綺麗だったのか…

並べてみると一目瞭然。

新しい方も気に入ってくれるか心配だったけど、
割とすんなり使ってくれた。

気に入ってくれたところで古いものは処分しようと思うのですが…

ダメでした。

意図せず増築という形になり部屋が狭くなってしまったが、
ねこは喜んでるのでOKです。😭

よかったね〜😊

鼻水ずるずる

ある日ちょっと元気がないなと思っていたら、
4月以来の鼻水が出てしまった。

前回ほどひどいくしゃみや鼻くそはないんだけど、心配なので病院へ。

診断結果は鼻炎。

前回と同じ(?)点鼻薬を処方してもらった。

診察のついでにワクチンも打ってもらった。

去年の9月以来で、
ちょっと早めだけどそれくらいならOKらしい。

すこし怪しいのは体重が結構落ちてたこと。

4月の時点では3.8kgだったのが、
この日は3.46kgまで落ちてしまっていた。

ごはんを残しがちだったので多少は落ちていると思ったが、
ここまで急激に下がっているのはびっくりだった。

先生とも相談して、
食べないよりはマシということでおやつ(≠総合栄養食)でもいいからたくさん食べさせる方針になった。

しょうがないね…😭

ごはん

点鼻薬を使って数日で、
鼻水がかなりおさまった。

そのおかげかわからないが、
あんまり食べなかったごはんをちょっと多めに食べてくれるようになった。

総合栄養食はおやつに比べて匂いが弱めなので、
鼻が詰まってる間はわかんなかったのかな…？

この調子で体重も戻るといいな〜🙏

おわり

体重がガタ落ちしているのは心配。

鼻も治ったしおやつも増やしたので、
たくさん食べて少しは戻るといいが…

これを書いている9月はさらに不穏な兆候が出ており、
あまりいい状態ではない、というのが正直なところ。

はやく健康な状態に戻るといいな…😭

おまけ

7月のそとちゃん

Fri, 15 Aug 2025 00:00:00 +0000

そとちゃん

ごはん問題

最近またそとちゃんがごはんを残すようになってしまった😭

去年のごはんイヤイヤ期はウェットフードを変えることでなんとか改善したが、
今回は同じごはんでも日によって食べたり食べなかったり…という感じで手強い。

特定の味が嫌いになったとか飽きたならわかるんだけど、
食べるときは食べるというのが厄介。

おやつならいつでも食べるので、
(毎度のことだが)やっぱり食欲不振ではなさそう。

おやつトッピング作戦を試すが、
それも効果は薄めというか今度はトッピングだけ食べる悪質行為が発生してしまう😭

それでも食べないよりはマシだが…

困っちゃうねえ…

ねこが落ちてる

常に冷房ガンガンの部屋なのに、
夏になるとねこが落ちているのは何故だろう…

夏バテ？

気がつくといろんなところで落ちていてかわいい。

落ち方にもいろいろあって、見ていて飽きない。

いいね〜〜👍

スツール

だいぶ前に買ったニトリのペットが入れるスツールが何故か今になってお気に入り。

すごいときはトイレ以外丸一日ここで過ごしたりする。

何がそんなにいいのかは謎だけど、
たくさん使ってくれるのはうれしい。

買ってよかった〜👍

おわり

ごはんは残すけど、ねこは元気。
暑さに負けず(?)毎日自由に暮らしている。

健康のためにもごはん、残さないでほしいが…😭

おまけ

6月のそとちゃん

Mon, 21 Jul 2025 00:00:00 +0000

そとちゃん

袋

そとちゃんは袋が好き。

ニンゲンの遠出でお留守番してもらったときはお土産を色々買ってみるけど、
一番喜ぶのはやっぱり紙袋。

その中でも最近はスタジオツアー東京でもらった紙袋が結構いい感じ。

紙が結構丈夫で、あんまりへたらない。
激しく遊んでもまだまだ入れちゃうのが良い。

硬ければ良いわけではなく、
ブランド物とかの加工された紙袋だと硬すぎてお気に召さないことが多いのだが、
これは程よい硬さがいい感じっぽい。

気に入ってくれてよかった〜👍

ごっちゃし座布団

おいしいもつ煮が食べられると聞いてグルメ目的で幕張の野球場に行ってみたら、
入場特典でごっちゃし座布団がもらえたのでそとちゃんに贈呈してみた。
(野球の試合をやっていた気もするけどもつ煮が美味しすぎてあまり覚えていない)

座布団はかなり小さめで、ねこにはちょうどいい大きさ。

しかもかなり軽くて、
あんまり強くないそとちゃんの力でも爪を引っ掛ければ動かせるのでいい相撲相手になっている。

ボロボロになるまで遊ぼうね…

お風呂

ブラッシングが嫌いでサボりまくりのそとちゃん、
ある日毛玉をちょっと多めに吐いてしまった。

普段は上手に吐くのだが、
今回はそこそこ汚れてしまったので久しぶりのお風呂が決定。

最後に入ったのは2~3年前?
だいぶ久しぶりだった。

例に漏れずそとちゃんも水が苦手なので、なるべく手短に済ませる。

まずは湯船に張ったぬるま湯で身体を濡らす。

地肌まで濡れたらねこ用シャンプーで全身を洗い、
やさしめのシャワーともう一度湯船ですすいで終わり。

そとちゃんは協力的ではないが抵抗が弱めだったので、
お風呂自体は30分かからないくらいで終了。

後はタオルドライと、
暴れるのでちゅーるで釣りながらぬるめのドライヤーで仕上げ。

おつかれさまでした…🛁

おわり

やはり夏はいろいろめんどくさくて更新が遅れてしまう。

7月中旬にこれを書いているのだが今年の夏も暑いので、
冷房をうまく使ってねこも人間も体調を崩さないように気をつけたい。

おまけ

5月のそとちゃん

Fri, 06 Jun 2025 00:00:00 +0000

そとちゃん

誕生日

5月1日はそとちゃんの誕生日。🎂

元野良なので推定だけど、
うちに来たのが5月1日なのでそういうことにしている。

今年で推定9さい。

3さいのときにうちに来てもう6年…
推定年齢が間違っていなければ野良だった期間の倍以上はうちで一緒に過ごしていることになる。

すこしは家猫っぽくなっただろうか？

とりあえず元気に誕生日を迎えられてよかった。
(実はこのときまだちょっと鼻水出てたけど…)

今年の誕生日プレゼントは色々考えたがこれというものが決まらず、
くったくたになってしまった寝床のしろたんを修理してあげることにした。

うちにきたときからずっと寝床にしているしろたん。

同じポジションでしか使わないもんだから、
もう底に触れるくらい綿が抜けてしまって寝心地が悪そう。

中身の綿袋を外し、
ユザワヤで綿とテープを買ってきて補修…

素人作業だけどなんとか復活できたのでこちらをプレゼントとして献上。

…が。

どうやら綿をパンパンに詰めすぎてしまったようで、
クッション性がなくなってしまった。

そとちゃんが乗っても全然沈まなくて、寝返りを打つと転げ落ちてしまう。

やってしまった…

結局そとちゃんもお気に召さず、
今はモチモチクッションを寝床にしている。

プレゼントはコケてしまったので、
ごちそうで挽回。

これでなんとかゆるしてほしい。

しろたんはいっぱいこねてまた自分好みにできるといいですね…

記念写真

5月中旬には鼻水もだいぶ治ったので、
毎年恒例の記念写真を撮りに行った。

相変わらずスタジオではやりたい放題。

スタッフさんも慣れっこなので、
一通り遊ばせてもらいそとちゃんが落ち着いてから撮影開始。

たくさん遊んで満足したのか、
今年はおとなしくねこ単体でかなりの枚数を撮影することができた。

がんばりました…

おわり

無事にそとちゃんが9さいの誕生日を迎えられた。🎉
歯は数本抜けちゃったし、ちょこちょこ病院に行く回数も増えてきたけどそとちゃん本人(猫)はまだまだ元気いっぱい。

ねこの9さいは人間でいうと50~60歳くらいのレディなのでそれなりに敬って接したほうが良いのかもしれないが、
そとちゃんは小さくてかわいいし自分からすると今も赤ちゃんみたいでベロベロに甘やかしている。

10歳の誕生日も元気に迎えられるよう頑張りましょうね…(主に人間が)

おまけ

4月のそとちゃん

Mon, 05 May 2025 00:00:00 +0000

そとちゃん

こたつ

4月になり暖かい日も増えてきたが、
そとちゃんは相変わらずこたつを堪能している。

最近はあまり電源を点けないので中に入ることは少なくなってきたが、
代わりにこたつに入った人の膝に乗るのがお気に入りになっている。

このポジションはかなり好きみたいで、
こたつに入るとすぐに乗ってくるし誰もこたつに入っていないと鳴いて呼びにくる。

かわいいね…
(片付けられない)

箱

最近また荷物が届いたので箱を献上。

元々袋派のそとちゃんも、
今ではすっかり箱を堪能するようになっている。
(単に袋が最近溜まらないだけなのだが)

今回の箱はフィット感が良く(?)、
よく入って遊んでいる。

楽しそうでなにより。

鼻水

月の後半からそとちゃんの鼻水が目立つようになってしまった。

慢性的にくしゃみが出ていて、
ずっと鼻をふがふがさせている。

それ以外は食欲もあり元気なのだが、
1週間くらい経って透明だった鼻水が若干白くなり、
鼻くそも目立つようになったので念のため病院へ。

当日の体重は3.8kgで痩せ気味だがあまり問題なし、
体温も37.9℃でおおむね平熱だった。

鼻水を採取してそのまま検査へ。

結果は細菌感染による鼻炎という診断だった。

ワクチンを打っていたので風邪系はあまり無いと勝手に思っていたが、
鼻水の成分的を見る限りは細菌に反応しているとのこと。

なんの菌に感染しているのか特定するには時間がかかって大変なので、
ひとまずの対応として菌の繁殖を抑えるために抗菌性の点鼻薬(ベストロン)を処方してもらった。
(これでも改善しないならより精密な検査、場合によっては菌の特定をするとのこと)

猫の点鼻薬は初めてなのだが、
目薬と同じ要領で上を向かせて後ろから垂らせばいいらしい。
(目薬は昔何回か使ったことがある)

家に帰って早速試したところ、
なんとか鼻に入れることができた。
(かなり嫌がるが…)

はやく治るといいな…

おわり

今年に入ってからちょこちょこ病院に行くことが増えてきたが、
本人(猫)は割と元気なのが救い。

5月はそとちゃんの誕生日(推定)もあるので、
健康な9歳を迎えたいね…

おまけ

3月のそとちゃん

Sat, 12 Apr 2025 00:00:00 +0000

そとちゃん

スケーリング

歯肉炎がひどくて歯が抜けてしまったそとちゃん。

残った歯を守るためにも2年ぶりのスケーリングを受けることに。

当日の朝は珍しくキャリーに入るのを渋ったが無事病院へ…

スケーリングは全身麻酔が必要だったりでほぼ半日かかるので、
朝病院に預けて夕方お迎えに行く形。

あとは先生に任せてしばしの別れ。

昼すぎには無事に終わった旨の電話をもらい、
予定通り夕方再び病院へ。

病院に着くと麻酔から目が覚めたそとちゃんがわんわん鳴いていた。

今回も麻酔後にちょっと漏れたおしっこがお尻について機嫌が悪かった様子。

肝心のスケーリングだが、
先生が術前術後の写真を撮っており、見せてもらうことができた。

なんか光の当て方じゃね？と思ったけどちゃんと歯石は取れているらしい。

あと気持ちの問題な気もするが口臭もちょっとマシになった気がする。

麻酔のために前日の夜から約20時間近くごはんをあげてなかったので、
帰宅後はごほうびごはんをドカ食い。

がんばりました…

お水

ねこの水飲み場は多いほうがいいらしい。

知らなかったわけではないのだが、
そもそも1箇所にしかなくてもそとちゃんはかなり水を飲んでくれるのであまり気にしていなかった。

ある日なんとなく、
本当になんとなく余っていた水飲み皿に水を入れて部屋に置いてみたのだが、
そとちゃんがいきなり食いついた。

それはそれでいいんだけど、
逆にこれまで使っていたピュアクリスタルの水を全然飲まなくなってしまった…

今までのはポンプと猫用のフィルタで濾過、
しかもヒーターでねこ好みに温めてるめちゃんこお金のかかった水なのに、
それよりも皿に汲んだだけの水道水を好むとは…?🤔

水はここ、と決めたら変えたくない的なこだわりがあるのかな？
よくわからないがたくさん飲んでくれるならヨシ！😭💸

洗濯機

家で使ってた洗濯機がもう10年以上で耐用年数を超えていたので、
いい機会だと思いニトリの激安ドラム式洗濯機を買ってみた。
(めっちゃ異音がする初期不良を引いて色々あったのだがそれは割愛、安いけどちゃんとサポートしてくれたから不満なし)

洗濯機といえば、うちには洗濯機大好きねこちゃんが一匹。

設置早々に洗濯機を調べるそとちゃん。

今までは縦ドラムだったから頑張ってジャンプしないと入れなかったのだが、
横ドラムになったので簡単に入れてしまう。
(⚠️そもそもねこは洗濯機に入っちゃダメです)

好きすぎて中に洗濯物があっても無理やり突破しようとする。

ドラムの中だけでなく、
洗濯中も気を抜くとたまに上にのぼってしまう。

今回買った洗濯機は安いのでヒーター式乾燥なのだが、
乾燥中は機械がかなり暖かくなるのでそれが気に入ってしまった様子。

ドラムの回転でガンガン揺れててもお構いなし。
洗濯機の上でねこがぷるぷる震えているのはちょっと面白いがやっぱり危険なのでダメです。

おわり

2月はそとちゃんがちょっと大変だったけど、
3月はほとんど元気に楽しく過ごせてよかった。

お水の件も洗濯機の件もそうだけど、
そとちゃんはなんでもすぐ好きになってくれるので一緒にいて楽しい。
怖がるという賢さはあんまりないんだろうな…😂

あと歯磨きを頑張ってこの状態をキープしましょう😤

おまけ

Azure SDK for PythonでCERTIFICATE_VERIFY_FAILEDを雑に回避する

Sat, 29 Mar 2025 00:00:00 +0000

まとめ

Azure SDK for Pythonを使っていてサービスへの接続時に証明書検証エラーSSL: CERTIFICATE_VERIFY_FAILEDが出た時、
雑に回避したかったら各クライアントのコンストラクタにconnection_verify=Falseを渡せば良い。
(本番運用するような場合はちゃんとルート証明書を端末のRootCAに追加しよう！怒られても知らないぞ！)

# こんな感じ
blob_service_client = BlobServiceClient.from_connection_string(connect_str, connection_verify=False)

経緯

~~会社のうんこPC~~ ちょっと特殊な環境で開発しているときにAzure SDK for PythonからAzureのサービスを呼び出したところ証明書エラーが出てしまった。

azure.core.exceptions.ServiceRequestError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1028)

このエラーは実行環境が信頼しているCA証明書でサーバー(Azure)側の証明書検証がしてしまうというもので、
正攻法としては信頼するCA証明書のリストにAzureのルート証明書を追加すれば解決するのだが、
~~PCがうんこすぎてそこらへん全然自由にいじれない~~
割と急いでたり動作検証で一回だけ通ればよかったりするときにわざわざ証明書をいじるのはけっこうめんどくさい。
全然汚い方法でいいからサクッと解決したくなった(=証明書検証自体をスキップしたい)。

環境

Python 3.13.2
azure-storage-blob 12.25.1
Azure Blob Storageは作成済みとする

手順

キーワード引数を指定

とりあえず使うコードはこんな感じ。
対象とするAzureサービスはなんでもいいが今回はBlob Storageのクライアントを使う。

これを特定の環境で実行したとき、次のようなエラーが出るものとする。
(接続文字列はportalから取得できる)

# 依存関係入れる
$ pip install -r requirements.txt
# ...

# 接続文字列を環境変数に設定
$ export AZURE_STORAGE_CONNECTION_STRING=DefaultEndpointsProtocol=https;AccountName=...;AccountKey=...;EndpointSuffix=core.windows.net

# スクリプト実行、証明書検証エラー発生
$ python main.py
Traceback (most recent call last):
 File "/test/main.py", line 14, in <module>
 for container in container_list:
 ^^^^^^^^^^^^^^
 File "/usr/local/lib/python3.13/site-packages/azure/core/paging.py", line 123, in __next__
 return next(self._page_iterator)
 File "/usr/local/lib/python3.13/site-packages/azure/core/paging.py", line 75, in __next__
 self._response = self._get_next(self.continuation_token)
 ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/usr/local/lib/python3.13/site-packages/azure/storage/blob/_models.py", line 538, in _get_next_cb
 return self._command(
 ~~~~~~~~~~~~~^
 marker=continuation_token or None,
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 maxresults=self.results_per_page,
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 cls=return_context_and_deserialized,
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 use_location=self.location_mode)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/usr/local/lib/python3.13/site-packages/azure/core/tracing/decorator.py", line 105, in wrapper_use_tracer
 return func(*args, **kwargs)
 File "/usr/local/lib/python3.13/site-packages/azure/storage/blob/_generated/operations/_service_operations.py", line 685, in list_containers_segment
 pipeline_response: PipelineResponse = self._client._pipeline.run( # pylint: disable=protected-access
 ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 _request, stream=_stream, **kwargs
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 )
 ^
 File "/usr/local/lib/python3.13/site-packages/azure/core/pipeline/_base.py", line 240, in run
 return first_node.send(pipeline_request)
 ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
 File "/usr/local/lib/python3.13/site-packages/azure/core/pipeline/_base.py", line 96, in send
 response = self.next.send(request)
 File "/usr/local/lib/python3.13/site-packages/azure/core/pipeline/_base.py", line 96, in send
 response = self.next.send(request)
 File "/usr/local/lib/python3.13/site-packages/azure/core/pipeline/_base.py", line 96, in send
 response = self.next.send(request)
 [Previous line repeated 2 more times]
 File "/usr/local/lib/python3.13/site-packages/azure/core/pipeline/policies/_redirect.py", line 204, in send
 response = self.next.send(request)
 File "/usr/local/lib/python3.13/site-packages/azure/core/pipeline/_base.py", line 96, in send
 response = self.next.send(request)
 File "/usr/local/lib/python3.13/site-packages/azure/storage/blob/_shared/policies.py", line 555, in send
 raise err
 File "/usr/local/lib/python3.13/site-packages/azure/storage/blob/_shared/policies.py", line 527, in send
 response = self.next.send(request)
 File "/usr/local/lib/python3.13/site-packages/azure/core/pipeline/_base.py", line 96, in send
 response = self.next.send(request)
 File "/usr/local/lib/python3.13/site-packages/azure/core/pipeline/_base.py", line 96, in send
 response = self.next.send(request)
 File "/usr/local/lib/python3.13/site-packages/azure/core/pipeline/_base.py", line 96, in send
 response = self.next.send(request)
 [Previous line repeated 1 more time]
 File "/usr/local/lib/python3.13/site-packages/azure/storage/blob/_shared/policies.py", line 301, in send
 response = self.next.send(request)
 File "/usr/local/lib/python3.13/site-packages/azure/core/pipeline/_base.py", line 96, in send
 response = self.next.send(request)
 File "/usr/local/lib/python3.13/site-packages/azure/core/pipeline/_base.py", line 96, in send
 response = self.next.send(request)
 File "/usr/local/lib/python3.13/site-packages/azure/core/pipeline/_base.py", line 128, in send
 self._sender.send(request.http_request, **request.context.options),
 ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/usr/local/lib/python3.13/site-packages/azure/core/pipeline/transport/_requests_basic.py", line 409, in send
 raise error
azure.core.exceptions.ServiceRequestError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1028)

ここで証明書検証をスキップするようにしたいが、
使ってるクライアントにそれっぽいオプションがなさそう…詰んだ…
と思ったが、ちょっとエラーを調べるとこのクライアントが内部で呼び出してるクラスとそのパラメータみたいなのが出てきた。

(BlobServiceClientがHTTPリクエストを送るメソッドの内部でConnectionConfigurationを呼び出していて、このclassにはconnection_verifyといういかにも証明書検証の有無を司ってそうなパラメータがある)

試しにキーワード引数(kwargs)をクライアントのコンストラクタに渡してみよう…

コードを書き換えて再度実行したところ、
「ちゃんと証明書検証したほうがいいぞ」的な警告は出るものの今度はエラーにならずちゃんと呼び出しが成功した(コンテナ名の一覧が表示できた)。

$ python main.py
/usr/local/lib/python3.13/site-packages/urllib3/connectionpool.py:1097: InsecureRequestWarning: Unverified HTTPS request is being made to host 'stuzimihsrexample.blob.core.windows.net'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#tls-warnings
 warnings.warn(
example-container-1
example-container-2

azure.core.configuration.ConnectionConfigurationは他のAzureサービスのクライアントでも通信時に使われているようなので、
同様に各クライアントのコンストラクタ引数にconnection_verify=Falseを渡せば証明書検証を回避できるはず。

やったぜ。

(証明書エラーの再現手順)

普通の環境で実行しても証明書エラーに遭うことはなかなかないので、
今回は問題を再現するため以下の手順で信頼するCA証明書が欠けているような状態を作った。

雑にDockerでPythonコンテナを立ち上げ、RootCAのリストを取得する。

$ # 作業ディレクトリ
$ pwd
/path/to/tempdir
$ ls -1 test
main.py
requirements.txt

$ # testディレクトリをマウントしてPythonコンテナを立て、そのままbashで入る
$ docker container run --rm -it -v /path/to/tempdir/test:/test python:3 /bin/bash
root@f8a544bd9c26:/#

root@f8a544bd9c26:/# # 依存関係入れる
root@f8a544bd9c26:/# cd test
root@f8a544bd9c26:/test# pip install -r requirements.txt
# ...

root@f8a544bd9c26:/test# # RootCAの場所を確認
root@f8a544bd9c26:/test# python
Python 3.13.2 (main, Mar 18 2025, 22:43:33) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import certifi
>>> certifi.where()
'/usr/local/lib/python3.13/site-packages/certifi/cacert.pem'
>>> exit

root@f8a544bd9c26:/test# # RootCAをコピーしてホストOS側で編集する
root@f8a544bd9c26:/test# cp /usr/local/lib/python3.13/site-packages/certifi/cacert.pem ./cacert.pem

拾ってきたRootCAをホストOS側から任意のエディタで開き、
# Issuer: CN=DigiCert Global Root G2の部分のpem(画像では1740~1768行目)をごっそり削除する。

(Blob StorageのRootCAがDigiCert Global Root G2であることはブラウザで確認した。)

これで信頼されたRootCAのリストからBlob StorageのRootCAが消えたので、
これをPythonが参照するように上書きする。

root@f8a544bd9c26:/test# # 編集後のcacert.pemで上書き
root@f8a544bd9c26:/test# cp ./cacert.pem /usr/local/lib/python3.13/site-packages/certifi/cacert.pem

あとはAzure portalから接続文字列をコピーしてきて環境変数に張り付けて、

root@f8a544bd9c26:/test# # 接続文字列を環境変数に設定
root@f8a544bd9c26:/test# export AZURE_STORAGE_CONNECTION_STRING=DefaultEndpointsProtocol=https;AccountName=...;AccountKey=...;EndpointSuffix=core.windows.net

コードを実行したらちゃんとエラーになった。

root@f8a544bd9c26:/test# python main.py
Traceback (most recent call last):
 File "/test/main.py", line 14, in <module>
 for container in container_list:
 ^^^^^^^^^^^^^^
 #...
azure.core.exceptions.ServiceRequestError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1028)

おわり

~~うんこPCで開発すんのマジしんどい、営業マンと同じ構成のポンコツ制限PCをエンジニアに使わせるんじゃないよ~~ 　

超久しぶりにPython触ったら色々わかんなすぎて泣いてしまった。
やっぱりGoがいいなあ…

おまけ

2月のそとちゃん

Sun, 16 Mar 2025 00:00:00 +0000

そとちゃん

歯が抜けた

ある日の夜。

寝る前に日課の歯みがきシートをしていたら、
そとちゃんが嫌がって動いたときに歯が引っかかってそのままポロッと抜けてしまった。😱

血が出たものの、ねこ自身は全く気にしてない様子。

念の為病院に電話したところ、
血が止まって本人(ねこ)が痛がるそぶりもなければ急診の必要はないとのことだった。

抜けたのは右上の奥歯。

元々右側の歯は歯肉炎がひどくて、
2年前にスケーリング(歯石除去)したときに一番奥の歯を抜歯していたのだが、
今回は手前の歯が抜けてしまった…

翌朝さっそく病院へ。

診察の結果、
とくに異常はなし。

気になるなら抗生剤を出してもよいが、
血が止まっているなら必須ではないとのことなので一旦なしにしてもらった。

あとは残った右下の歯も歯肉炎がひどかったので、
後日再びスケーリングをすることに。

歯磨きは毎晩やっていたが、
左側に比べて右側は痛がるのであまりうまくできていなかった。

反省…

猫ドック

スケーリングは全身麻酔が伴うため、
安全のために血液検査が必要。

どうせ血液検査をやるならということで、
そとちゃんは初めての猫ドックを受けることになった。

朝に病院に預けて、夕方までみっちり検査。

病院大好きそとちゃんも流石に疲れたのか、
家に帰ってきたころにはすっかりしょんぼりしていた。

加えて前日夜からご飯を抜いていたので、
めちゃめちゃお腹が空いていた様子。

一応検査後に病院でもおやつをもらったはずだが、
帰宅後すぐにごはんをドカ食い。

がんばりました…

気になる結果は…？

身体検査

体重は3.9kgでちょっと痩せ気味。
体格的に4.0kgは欲しいがごはんを好き嫌いしていたのもあって減ってしまった。

体温は平熱(38.2℃)で問題なし。

右眼は相変わらず目ヤニが多め。
タンパク質多めの食事にすると改善するかも？
目薬を処方することもできるが、
ほぼ生まれつきのようなもの(猫風邪の後遺症)なのでこまめに拭くのが一番らしい。

口は主に右側の歯肉炎が引っかかった。
歯列異常の診断は歯が抜けてしまっているからとのこと。

皮膚はフケが目立ち、
左耳の付け根に脱毛があった様子。
フケは一時的なストレス、
脱毛は脚で掻く癖があるのでそれ由来っぽい。
掻きすぎて出血などがあれば治療しなきゃだけど、今の所問題なし。
夏になったら久しぶりにお風呂入ろうか…

触診は背中を押した時に嫌がるそぶりを見せたので気をつけたほうがいいらしい。
とはいえレントゲン(後述)では異常はなかった。

その他は異常なし。

いろいろ引っかかってしまったが、
緊急で対応が必要というよりは「今後も注意して見てね」くらいのものだったので一安心。

便検査尿検査

うんちは異常なし。
形も成分もいい感じ。

おしっこは尿比重が低いのが問題とのこと。
薄すぎるので腎機能が低下している可能性がある。

そとちゃんは元々水を良く飲むのでそれが関係しているかもしれないが、
腎機能が落ちた猫は水をたくさん飲む傾向にあるのでやはり注意が必要。

1回のおしっこの量が異常に増えたりしたら再検査も視野に入れたほうが良いらしい。

レントゲン検査

おおむね問題なしだが、
気管支パターンが見つかったので咳が増えたら注意が必要とのこと。
よく水を飲んだ後にくしゃみか咳のような動きをよくやるので気をつけてあげたい。

エコー検査

こちらもおおむね問題なし。

膵臓がわずかに肥大していたとのことだが、
異常があれば食欲低下や嘔吐の症状が出るはずなので元々ちょっと大きいだけかもしれない。
(そとちゃんは好き嫌いするだけで食欲が落ちたことはほぼない)

血液検査

大きな異常はなし。

腎機能の値であるクレアチニンがわずかに基準値を上回っているが、
元々ブレが大きい値であること、
腎臓に本当に異常があるときすぐ上がる値(SDMA)が低いのでそこまで深刻な状態ではないらしい。

MCHCと血小板数も少なかったが、
こちらも基準値をギリギリ下回る程度なので大丈夫。

こんな感じで大きな異常はなし、
全身麻酔も打てるでしょうとのことで3月にスケーリングを行うことになった。

おしっこ

そとちゃんの病院通いはこれで終わらず…😭

猫ドックから帰ってから数日後、
こんどはそとちゃんがほぼ初めての粗相をしてしまった。

これまでにそとちゃんが粗相をしたのはたったの一回、
それもうちにお迎えした初日でトイレの場所がわからなかったときだけだったので、
とても心配になった。

様子を見ていると何度もトイレに行ってはいるのだが、
なかなかうまくおしっこが出ない様子。
(うんちは問題なくできていた)

トイレだとうまくおしっこできないから、
他におしりの居心地がいい場所を探してそこでおしっこを試みる、
といった動きをしているように見えた。

移動した先でもなかなかおしっこが上手に出せず、
血尿と思われるものがポタポタ出ている状態。

辛そうなのですぐに病院へ。

やはりおしっこがうまく出せず溜まっていたようで、
すぐにカテーテルで全て排出してもらった。

腎臓に問題があると排尿を我慢することもあるらしいが、
直近の検査で問題ないことと、
上記の症状や排出した尿から細菌の値が少し出たので細菌性膀胱炎との診断。

原因としてはトイレでうんちや汚れた砂が尿道に触れたのかも？とのこと。

素人的には猫ドックで採尿(膀胱穿刺)してもらったときに膀胱に傷がついたのでは？とも思ったが、
実際は針ではなくカテーテルで採尿していたので考えづらいということだった。

治療のため、
1週間ほど抗生物質のアモキクリアを飲むことになった。

帰宅後は何事もなかったかのようにケロッと復活。

溜まってたおしっこがなくなってスッキリしたのかな？

そして翌朝。

なんとまだ2回しか薬を飲んでないのに普通にトイレでおしっこできるようになった。

薬が効くにしてはちょっと早いと思うけどまあいいのかな？

薬もしっかり飲みきり、
以降は血尿も粗相もなくなった。

トイレはこまめに砂を入れ替えてるけど、再発しないといいな…

おわり

2月はなんと3回も(1回は検査だけど)病院のお世話になってしまった。

お財布に大ダメージなのはもちろんだが、
やはりシニアねこ(次の5月で推定9さい)なので心配が大きい。

歯が抜けたのも、毎日の歯磨きをもっと頑張っていれば防げたと思うと悔しい。

これで右上の歯は犬歯以外の臼歯が全部抜けてしまった。
綺麗な左側の歯は全部守っていきたいな…

おまけ

1月のそとちゃん

Fri, 28 Feb 2025 00:00:00 +0000

そとちゃん

ホットカーペット

新年早々そとちゃんにうれしいお年玉。

我が家にホットカーペットが導入された。🎉

友人から譲り受けたもので(物々交換なのに対価をまだ渡せておらず申し訳ない)、
うちの部屋にぴったりサイズ。

すぐにそとちゃんのお気に入りになった。

電源を入れるとすぐ乗ってきて溶けちゃう。

かわいいね。

たまに電源を落とすと明らかに機嫌が悪くなる。

上手につかってくれるといいな…

もちもちクッション

良い子にしているそとちゃんに俺からもお年玉を…

ニトリでもちもちクッションを購入。　　

直径60cmで、そとちゃんにちょうど良いサイズ。

こちらも早速気に入ってくれて、
気づけば上で丸くなっている。

丸くないときもある。

他のねこちゃんはこういったクッションでふみふみする子が多いみたいだけど、
そとちゃんはやっぱりふみふみしなかった😂
(自分がお母さん猫だから子猫しぐさはあまりしないのかな…?)

ホットカーペットと合わせて楽しくすごしてくれたらうれしい。

おわり

1月はそとちゃんに嬉しいプレゼントが多くてよかった。

なんでも喜んでくれるからあげた方もうれしい。

これで冬を乗り切りたいな…
(2月現在、ホットカーペットで電気代が爆発中💸)

おまけ

12月のそとちゃん(2024)

Sun, 12 Jan 2025 00:00:00 +0000

そとちゃん

来客

12月はちょこちょこ来客があり、
人間大好きなそとちゃんは大喜びだった。

そとちゃんはマジでお客さんが大好きなので、
自分からひざに乗りたがる。

普段から全然面識のない配送員さんや業者さんにも絡んでしまうし、
載せてもらえないと不機嫌になるくらいにはお客さんが好き。

猫カフェでアルバイトできるんじゃないかしら…😂

麻雀

たびたび来客がある中で、
なんとそとちゃんが麻雀好きなことが判明。🀄️

マットの上に登って大胆に観戦。

さらに牌もおててで上手に転がす。
すごいなあ…(ゲームにならない)

クリスマス

そとちゃんは今年もサンタさんになった。

べらぼうにかわいいね…

今年も1年良い子にしていたそとちゃんにはプレゼントをご用意。

楽しいクリスマスになってよかった。

おわり

2024年もそとちゃんはよく食べて寝て遊んで元気だった。

大きな環境の変化もあったが、
そとちゃんはすぐに慣れてごきげんになってくれるので本当に助かる。

しもべとしてはあまり良いことがない1年だったので、
2025年はねこを見習って明るく楽しい年にしたい。

おまけ

11月のそとちゃん(2024)

Sat, 11 Jan 2025 00:00:00 +0000

そとちゃん

こたつ

だいぶ寒くなってきたのでこたつを導入。

例年通りそとちゃんはこたつ大好きねこちゃんなので楽しそう。

でもやっぱり人間が入ると嫌みたいで出ていってしまう。

ちなみにこたつを出た後は人間のひざに収まる。

人間の脚が入っててもひざ上よりはこたつのほうが広くて快適だと思うのだが、
ねこ基準だとそうではない様子。

仲良く共存できたらいいな…

ふとん

こたつも出したし、
人間のふとんも暖かいやつに変更…

したら今回もそとちゃんに気に入られてしまった。

ねこにはこたつがあるのに…

人間が寝ててもおかまいなし。

躊躇なく上に乗って寝てしまう。
(ちなみに布団をかぶるのは苦手なので中には入らない)

まあ幸せそうなのでOKです。

おわり

ブログを更新しないままついに年を越してしまった。

今冬はまだまだ寒さが続くがそとちゃんは元気いっぱい。
こたつとふとんをうまく使って寒さを乗り切って欲しい。

おまけ

10月のそとちゃん(2024)

Mon, 09 Dec 2024 00:00:00 +0000

そとちゃん

ごはん食べくらべ

いつものごはんを食べなくなってしまったそとちゃん。

何日も食べてくれないと流石に困るので、
他のごはんを試してみることにした。

(久しぶりに動画作るのが結構大変で時間かかってしまった…)

試したごはんと結果はこんな感じ。

ごはん	結果
MiawMiaw	🙂 黒缶に比べればまあ食べたな、という程度
CIAO	🙂 MiawMiawと同じくらい食べたけど少し食べづらそうだった
WILD RECIPE	🤩 飲むように食べた
MonPetit	🤩 よく食べた
NaturaHa	😕 あんまり食べなかった
黒缶	😭 笑っちゃうくらい食べない
ROYAL CANIN	😊 そこそこ食べた
ROYAL CANIN(7+)	😊 シニア向けだけど、普通のと同じくらい食べた
kalkan	🥰 めちゃめちゃ食べた

食べた順だとワイルドレシピとモンプチがかなりよかったんだけど、
この2つは1袋あたりの量が他のフードの半分くらいなので若干使いづらいかな…?と思った。
毎回2袋開けるのは手間もゴミも増えるし、
なにより値段も高いし…💸

その次くらいによく食べたのがカルカン。
お手頃価格なのに食いつきがよかった。
庶民派ねこちゃんですね…

あとは自分のエゴでロイヤルカナンを選出。
そろそろシニア向けフードにも挑戦しないとな…と前から思っていたが、
今回試した感じだと結構食べてくれそうなので。

そんな感じで、
当分の間はカルカンとロイヤルカナンを併用することにした。

いっぱい食べてくれ〜🙏

ハロウィン

毎年のやつ。

今年もあまり嫌がらず写真を撮らせてくれた。

かわいいねえ…

おわり

とりあえずご飯をちゃんと食べてくれるようになってよかった。

これを書いている時点ですでに12月なのだが、今年の残りも健康に暮らせるようにしたい。

おまけ

Azure DatabricksワークスペースAPIをAPI Management経由で利用する

Wed, 13 Nov 2024 00:00:00 +0000

まとめ

どうしてもDatabricksのワークスペースAPIをAPI Management経由で叩きたかったのだが、
設定が結構大変な上になぞりやすい公式のドキュメントが見つからなかったので
自分が設定できたときの手順を残しておく。

DatabricksワークスペースAPIをAPI Managementのバックエンドとして利用する際はカスタムURLが使える
API Managementに持たせる資格情報はDatabricksワークスペースのPATも利用可能だが、
よりセキュアにやるならAPI Managementのauthentication-managed-identityポリシーでresource="2ff814a6-3304-4ab8-85cb-cd0e6f879c1d"を指定する

前提条件

Databricks, API Managementは以下の設定で作成済みとする。

Databricks
- ~~マネージドVNetではなくカスタムVNetで作成されていること~~
  - 参考: https://learn.microsoft.com/ja-jp/azure/databricks/scenarios/quickstart-create-databricks-workspace-vnet-injection
  - 必須ではないが、カスタムVNetで立てた方がネットワーク関連の設定がしやすい
API Management
- システム割り当てマネージドIDが有効になっていること
  - 参考: https://learn.microsoft.com/ja-jp/azure/api-management/api-management-howto-use-managed-service-identity
- Databricksとの通信をプライベートにする場合は、Developer, Standard v2またはPremiumプラン(送信VNet統合または内部/外部VNetインジェクションをサポートしているプラン)で作成すること
  - 参考: https://learn.microsoft.com/ja-jp/azure/api-management/virtual-network-concepts

手順

バックエンドAPIを作成

まずはAPI ManagementからDatabricksへ接続するためのバックエンドAPI情報を設定する。

API Managementの管理画面から「APIs」→「Backends」→「+追加」と進み、
バックエンド(例: dbw-01)を作成する。
ランタイムURLにDatabricksワークスペースURLをぺたっと貼るだけでOK。
(資格情報は後ほど設定する)

次にAPI定義を作成する。
API Managementの管理画面から「APIs」→「API」→「+Add API」と進み、
API定義(例: dbw-01)を作成する。
名前とAPI URL suffix(例: dbw-01)を設定するだけでよい。
(Web service URLは設定せず、後ほどポリシー式で先ほど作成したバックエンドを指定する)

API定義が作成できたら、「Design」→「All operations」→「Design」から全操作(メソッド)共通のポリシー編集画面を開き、
先ほど作成したバックエンドを指定するset-backend-serviceポリシーを追加する。

また、リクエストを受信しバックエンドに流せるようにoperationを追加する。
Azure Databricks REST API reference等を参考に必要なAPI操作を定義するのがよさげ。
(OpenAPIで定義されたものがあればインポートできるんだけど、自分が探した限りだと見つけられなかった)

今回は簡単に確認したいだけなので、全てのGETリクエストをそのままのパスで流すワイルドカードを設定する。
(ドキュメントの注意事項にもあるように、本来は必要な操作だけをホワイトリスト的に定義した方が安全)

これでAPIを利用する準備ができたように見えるが(実際ほぼ終わり)、
資格情報を設定していないので試しにAPI Management越しにリクエストを送っても失敗する。

# 変数の設定
$ apimUrl="<API Managementの管理画面「概要」→「基本」→「ゲートウェイのURL」>" # 例: https://apim-name.azure-api.net
$ subscriptionKey="<API Managementの管理画面「APIs」→「サブスクリプション」から取得した主キー>"

# API Management越しにクラスター一覧APIを呼び出す(Databricks用のキーは付与せず、API Management用のキーのみ設定)
$ curl -H "Ocp-Apim-Subscription-Key: ${subscriptionKey}" ${apimUrl}/dbw-01/api/2.1/clusters/list

{"error_code":"401","message":"Unauthorized"}

API ManagementのマネージドIDに権限を付与

次はこの資格情報を設定していく。

参考: https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/azure-mi-auth

Databricks側でPAT発行してそれをAPI ManagementバックエンドのAuthorizationヘッダーに設定、でもいいんだけど、
PATってあんまり推奨されるものでもない(個人の権限ですべての操作が行われてしまう)のでできればマネージドIDでやりたい。

このため、まずはAPI Managementのシステム割り当てマネージドIDをDatabricksにサービスプリンシパルとして登録(ワークスペースへのアクセス権限を付与)する。
(ドキュメントだとユーザー割り当てマネージドIDが推奨されてるけど、やってみたらシステム割り当てでもできちゃった)

Databricksワークスペースで「設定」→「IDとアクセス」→「サービスプリンシパル」→「Service Principalを追加」からシステム割り当てマネージドIDを新規追加する。
記載するIDはMicrosoft Entra IDの管理画面から「管理」→「すべてのアプリケーション」から対象のマネージドIDの情報を開き、「アプリケーションID」の値を利用する。
(マネージドIDが見つけづらい場合はAPI Management管理画面(portal)の「セキュリティ」→「マネージドID」→「オブジェクト(プリンシパル)ID」の値を取得し、アプリケーション一覧画面で検索する。)

必要であれば特定の権限を持つグループに対象のサービスプリンシパルを追加しておくこと。
(今回は雑にadminに追加してしまっているが、本番運用の際はちゃんと専用のグループと権限を設定した方が良い)

これでAPI ManagementのマネージドIDでDatabricksワークスペースを操作する権限が設定できた。

API Managementのポリシー設定

マネージドIDに権限を付与できたので、
次はAPI Managementがアクセストークンを取得するためのauthentication-managed-identityポリシーを定義する。

resourceに何を指定すればよいのか迷うところだが、
curlでアクセストークンを取得する例を見る感じ2ff814a6-3304-4ab8-85cb-cd0e6f879c1d(DatabricksのプログラムID)でよさそう。
(正直ここに気付けなくて1日くらい溶かした)

ここまでできたら接続設定は完了。
バックエンドAPIの作成後に試した手順で再度リクエストを送ると、
今度は権限が付与されているので成功するようになっている。

$ curl -H "Ocp-Apim-Subscription-Key: ${subscriptionKey}" ${apimUrl}/dbw-01/api/2.1/clusters/list

{"next_page_token":"","prev_page_token":""} 
# クラスターを作成していないのでほぼ空っぽだが、APIリファレンス通りのレスポンスが返っているので動作確認は成功
# https://docs.databricks.com/api/azure/workspace/clusters/list

やったぜ。
これでAPI Managementにさえ疎通できればDatabricksワークスペースAPIが使えるようになった。

後は必要に応じてネットワークを閉域化したり、お好みで…

bicep

今回ブラウザでポチポチした操作をコード(bicep)化するとこんな感じ。↓↓↓

ネットワークまわりの設定で追加したところがあり、
API Managementは外部モードでデプロイして、
Databricksにはプライベートエンドポイント経由で接続するようにした。

また、Databricksワークスペースの細かい設定(IPアクセスリストだったりサービスプリンシパル)はbicepでは書けないっぽいので(Terraformだといけるかも?)、
手動で実施する必要がある。

おわり

Azure Databricksが難しすぎて日々泣いている。😭
ファーストパーティサービスと言いつつRBACはAzureロールと別物だし、サービスエンドポイントはないし…
同じように泣いている人の助けになれば幸い。

おまけ

9月のそとちゃん(2024)

Wed, 30 Oct 2024 00:00:00 +0000

そとちゃん

病院

新居の近くに動物病院があるので、
ご挨拶ついでにワクチンを打ちにいった。
(毎年この時期に3種混合ワクチンを打っている)

そとちゃんは初めての病院でもおとなしく診察を受けててえらかった。👏
診察室を勝手に探検するやんちゃは卒業したっぽい。

体温はいつも通り38℃で正常。

体重は環境が変わっても変わらず4.0kgをキープ。
(ごはんちゃんと食べないのに…🤔)

毛並みと地肌もとても綺麗とのこと。
(全然ブラシさせてくれないのに…🤔)

とりあえず触診は問題なしだった。

ちょっと問題だったのは歯肉炎。
去年抜歯した右側の歯肉炎がひどいとのこと。
(写真撮り忘れた)

一応毎日歯みがきシートで拭いてはいたが、
右側はかなり嫌がるのもあってなかなかうまく掃除できていなかったっぽい。😭

普段からおとなしく掃除させてくれる左側の歯肉は綺麗だったので、
もうちょっと歯みがきをがんばろう…

ワクチンはいつも通り数秒で打てたので、
ついでに血液検査もしてもらった。

引っ越し後初めての病院は約2時間で終了。
家からかなり近くて助かっちゃった。

ごはん問題

~~めっちゃ好き嫌いする~~食のこだわりが強いそとちゃん。

ある日突然ウェットフード(黒缶)を食べなくなってしまった。😭

ここ数年のそとちゃんのごはんはずっとこんな感じだった。

タイミング	ごはん	食べ方
朝	ロイヤルカナン消化器サポート(ドライ) 10g	すぐ完食
昼	朝と同じカリカリ 10g	ちょっとだけ食べて残すめんどくさいと全然食べない
夕	黒缶パウチ 1袋 +トッピング(かつお節 or ちゅーる)	半分くらい食べて残りを朝までだらだら食べる
寝る前	にぼし 1,2本かにかま少々	爆速で食べる

現在はこんな感じ。

タイミング	ごはん	食べ方
朝	ロイヤルカナン消化器サポート(ドライ)	すぐ完食
昼	朝と同じカリカリ 10g	すぐ完食
夕	黒缶パウチ 1袋 +トッピング(かつお節 or ちゅーる)	トッピングだけ食べて全残し
寝る前	にぼし 1,2本かにかま少々	爆速で食べる +足りないと文句を言う

どうして…😭

おやつやトッピングは喜んで食べるので、
食欲がないわけではなさそう。
(なんならおやつはもっとよこせと鳴く😭)

病院に行ったときにも相談したが、
「他のごはんやおやつをちゃんと食べるなら単純にウェットだけ飽きたんじゃね？」とのことだった。

確かに今まで残しがちだったお昼のカリカリを完食するようになっているので、
(今まではカリカリ食べなくて悩んでたくらいなのでこれにはかなり驚いた)
本当に黒缶に飽きてしまったのだろうか…?

一応飽きがこないように同じ黒缶でも毎日違う味を4~5種類ローテしていたのだが…😭

あまりにも黒缶を残すので、
夜食用に追加でカリカリを出したらそれはちゃんと食べてしまった。
どうしよう…

血液検査

病院に行ってから1週間ほどで血液検査の結果が返ってきた。

果たして結果は…?

すこぶる健康だった。

昔ちょっと高い数値が出たことのある腎臓系(クレアチニン)も正常範囲内で、健康優良児とのこと。

この調子ならシニアねこでも半年に1回くらいの診察で問題ないらしい。

よかった〜
(ごはんちゃんと食べないのに…🤔)

おわり

新しい動物病院も雰囲気がよくていい感じだった。
健康とはいえ、年齢的に精密検査(猫ドック)もおすすめされたのでまた半年後に受けてみようかな…?

ごはん問題は結構深刻。
おやつだけお腹いっぱい食べたいそとちゃん
vs
黒缶を食べて欲しい俺
の家庭内戦争が毎晩発生しているので(俺が全敗)どうにか解決せねば…

おまけ

8月のそとちゃん(2024)

Fri, 04 Oct 2024 00:00:00 +0000

そとちゃん

新居を満喫

引っ越ししてそこそこ日数か経った。

そとちゃんは新居に慣れて満喫中。
(初日から我が物顔で振る舞っていたような気もするが)

前の物件よりも部屋数が多いので、
いろんな部屋でごろごろしているそとちゃんが見られて楽しい。

こうして見ると右頬を下にして寝てることが多い？

そうでもなかった。

デカいダンボール

作業用のディスプレイを新しく買ったのだが、
その空き箱がそとちゃんのものになってしまった(定期イベント)。

ディスプレイが約32インチだったのでこの箱が結構でかい。

そとちゃんと比べても十分な(?)大きさ。

これくらい大きいものが置いておけるのも部屋が広くなった恩恵か…?

家が広くなったのに

繰り返しになってしまうが、
引っ越しして家がめちゃめちゃ広く、部屋数も多くなった。

そとちゃんも部屋をうろうろ移動したりして楽しんでいた。

はずだった…

現在。

そとちゃんはほとんど俺の仕事部屋(せまい)で過ごしている。

なんで?

俺が日中ほとんど仕事部屋にいるので、一緒に居たいのかしら🤔
(そうだったらうれしいし健気でかわいい)

前の家でも滅多にやらなかった、
作業の邪魔もしてくる。

かわいいね。

右目

じめじめしてたせいもあるが、
あんまり右目の調子が良くなかった。

目ヤニが出てたらこまめに拭いてはいるものの、
どうしても粘度が強くて地肌に張り付いてしまうので結構痛そうに見える…😭

毎年涼しくなると症状が軽くなるので、はやく治ってほしい。

おわり

ついに1ヶ月遅れですら更新できなくなってしまった😭

9月分こそは…

おまけ

7月のそとちゃん(2024)

Sat, 31 Aug 2024 00:00:00 +0000

そとちゃん

ひっこし

実は(?) 引っ越しをしていた。

これまで住んでいた物件は日当たりもよく、
立地や設備も文句なしだったのだが…

諸事情(※)により住めなくなってしまったので、
仕方なくお引っ越し。😭
(※何がきっかけで叩かれるかわからないので私個人の名誉のために強調しておくが、決して近隣トラブルや契約の不備などではなく別の要因によるものである)

そとちゃんと暮らし始めてからこれで3回目の引っ越し。

環境が変わることでストレスにならないだろうかと(一応)心配だったが、
やはり流石のそとちゃん、ノリノリである。

まずは荷造りで大興奮。

荷物を作るたびにできる部屋の隙間と、
段ボールが楽しくてしょうがない。

引っ越し当日はやっぱり大騒ぎ。

車移動が苦手なそとちゃんはわんわん鳴いていた。
(今回はこれまでで最も移動距離が長いのでかわいそうだった…😭)

新居についたら早速探検。

知らない場所でも全然ビビらない性格なのは本当に助かる。
ストレスで吐いたり粗相もなかった。

引っ越し業者さんに絡んだり、
部屋を一通りチェックして大満足。

部屋。
そう、新居は部屋がめちゃめちゃ広い。

どれくらいかというと、今まで住んでた部屋の倍くらいの面積となっている。

これまでは縦長1Kの部屋だったので直線でしか走れなかったのが、
新居は正方形に近く、部屋数も増えたので、いろんな方向に曲がれたりと走り甲斐があるようだ。

日当たりもよくてねこ大満足。

そんなわけで、今回の引っ越しは大きなトラブルもなく無事に終わった。

おつかれさまでした。

おわり

そんなこんなで最近はドチャクソ忙しかったのだが、なんとか落ちついてきた。
(おかげで書くのがめちゃめちゃ遅くなったが😭)

新居は広くなったぶん家賃も💸倍増💸してしまったが、
ねこが広い部屋で楽しそうなのでまあヨシ！ 😭

(リアルフレンドの皆様は是非泊まり/遊びに来ていただきたい。ねこも喜ぶので…)

おまけ

Azure Databricksワークスペースへアクセス可能なIPアドレスを制限する(curlで設定)

Wed, 28 Aug 2024 00:00:00 +0000

まとめ

Databricks CLIをインストールしてなくても、直接APIを叩いてワークスペースのIPアクセスリストを設定できる

経緯

Azure Databricksのワークスペースについて、
インターネットからアクセスしたいが接続元のIPアドレスは制限したい、ということがあった。
(VPN引いてプライベート接続はお金かかるからあんまりやりたくなかった)

IPアクセスリストの設定は公式の設定手順はあるが、
Databricks CLI前提の手順になっている+自分の都合によりどうしてもCLIのインストールができないという状況なので、
APIをcurlで叩いて設定してみた。

手順

ワークスペースURLを取得

APIをたたくのに必要なのでワークスペースURLを取得する。
方法はなんでもいいけど、自分はAzure portalからコピーした。

# ワークスペースURL
$ url="https://adb-00000000000000.00.azuredatabricks.net"

アクセストークンの取得

APIを叩くためのアクセストークンを取得する。
https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/auth/pat#--azure-databricks-personal-access-tokens-for-workspace-users

# アクセストークン
$ token="dapixxxxxxxxxxxxxxxxx-3"

IPアクセスリストの作成

IPアクセスリストを作成する。
https://docs.databricks.com/api/azure/workspace/ipaccesslists/create

# リクエストボディJSON (ip_addressesにアクセスを許可したいIP(v4)のリストをCIDR表記で記載する)
$ cat << EOF > ip-access-list.json
{
 "label": "My Office",
 "list_type": "ALLOW",
 "ip_addresses": [
 "133.xxx.xxx.xxx/32"
 ]
}
EOF

# Create access list APIをコール
$ curl -X POST -H "Content-Type: application/json" -H "Authorization: Bearer $token" "$url/api/2.0/ip-access-lists" -d '@ip-access-list.json'

{"ip_access_list":{"list_id":"ec88d280-02f6-4945-84b8-76a7bcdeb05f", "label":"My Office", "ip_addresses":["133.xxx.xxx.xxx/32"],"address_count":1,"list_type":"ALLOW","created_at":1724834759440,"created_by":1878671197505866,"updated_at":1724834759440,"updated_by":1878671197505866,"enabled":true}}

ちなみに、
一番最初に作るIPアクセスリストの範囲に現在の自分のIPアドレスが含まれていない場合は怒られてしまうので注意。
(おそらく現在の端末から操作できなくなるのを防ぐため。
自分のIPアドレスからの通信を許可するリストが既に存在すれば、
2つめ以降のリスト作成時には自身のIPが含まれていなくても問題なし。)

自分のIPアドレスは https://checkip.amazonaws.com/ とか、なんか適当に調べれば出てくるはず。

# ip-access-list.jsonのip_addressesに現在の自分のIPアドレスがない場合
$ curl -X POST -H "Content-Type: application/json" -H "Authorization: Bearer $token" "$url/api/2.0/ip-access-lists" -d '@ip-access-list.json'

{"error_code":"INVALID_STATE","message":"Your current IP 133.xxx.xxx.yyy will not be allowed to access the workspace under current configuration"}

IPアクセスリストを有効化

IPアクセスリストでのアクセス制限を有効化する。
https://docs.databricks.com/api/azure/workspace/workspaceconf/setstatus

# Enable features
$ curl -X PATCH -H "Content-Type: application/json" -H "Authorization: Bearer $token" "$url/api/2.0/workspace-conf" -d '{"enableIpAccessLists": "true"}'

以上の手順が正しく実施できていれば、
IPアクセスリストにないIPアドレスからワークスペースを開こうとするとちゃんと拒否されるようになる。
やったぜ。

一応、IPアクセスリストの状態を確認する方法も貼っておく。
https://docs.databricks.com/api/azure/workspace/ipaccesslists/list
https://docs.databricks.com/api/azure/workspace/workspaceconf/getstatus

# Check configuration status
$ curl -s -H "Authorization: Bearer $token" "$url/api/2.0/workspace-conf?keys=enableIpAccessLists" | jq

{
 "enableIpAccessLists": "true"
}

# Get access lists
$ curl -s -H "Authorization: Bearer $token" "$url/api/2.0/ip-access-lists" | jq

{
 "ip_access_lists": [
 {
 "list_id": "ec88d280-02f6-4945-84b8-76a7bcdeb05f",
 "label": "My Office",
 "ip_addresses": [
 "133.xxx.xxx.xxx/32"
 ],
 "address_count": 1,
 "list_type": "ALLOW",
 "created_at": 1724834759440,
 "created_by": 1878671197505866,
 "updated_at": 1724834759440,
 "updated_by": 1878671197505866,
 "enabled": true
 }
 ]
}

(設定が終わったらアクセストークンの無効化を忘れずに…)

おわり

最近生成AIに頼りすぎで、なんか久しぶりにこういうの書いた気がする。
たまにはいいな〜

おまけ

6月のそとちゃん(2024)

Thu, 25 Jul 2024 00:00:00 +0000

そとちゃん

カリカリ

5月末に買った新しいカリカリマシーンがいい感じ。

6月は結構じめじめしていたけど、
湿気対策のおかげでカリカリがちゃんと乾いた状態をキープできていた。

そとちゃんも結構食べてくれていて、完食することも多くなってきた。

一緒に暮らして6年目にしてようやく、カリカリがしけて全然食べない問題がついに解決したっぽい。

やった〜🎉
(なお、俺が居るとあまり食べないのは変わらず…)

あつい

夏が始まった。

暑くてたまらない。

でもそとちゃんは毎日ひなたぼっこ…
もちろんエアコンはガンガンに回してるけど、それでも窓際は暑いだろうに…

流石に1日中窓際という感じでもなく、
たまに廊下に落ちてることもある。

だらけきっているねこはとてもかわいい。

溶けてる顔がたくさん見られてかわいいけど、
それでもやっぱり早く涼しくなってほしい…

おわり

ちょっといろいろありすぎて、意味わかんないくらい遅筆になってしまった。
来月こそは…

おまけ

5月のそとちゃん(2024)

Thu, 06 Jun 2024 00:00:00 +0000

そとちゃん

8さい

5月生まれ(推定)のそとちゃん。
ついに8さいになった。

当然本人(にゃん)にその意識はないが、
おめでたいので勝手にお祝いさせてもらった。

去年はキャットタワーだったが、今年はおもちゃをプレゼント。

まずはでるでる自飯器。

これはびっくりするくらい食いつかなかった…😭

お次は電池で動く虫のおもちゃ。

残念なことに、おもちゃの仕組み上カーペットの上だと全然動かなかった。
これもハズレ…😭

と思ったらそとちゃんは気に入った様子。

動けないけどじたばたしている虫にちょっかいを出すのが楽しいらしい。

あとはいつものまたたびスプレーと、

いつものカサカサする猫じゃらしをプレゼント。

最後はいつもよりちょっとおやつ多めのごはんでお祝い。

よかったね〜〜🎉

記念写真

もう毎年恒例となった誕生日の記念写真。

今年もいつもの写真屋さんで撮ってもらった。

スタジオに放たれたそとちゃんはやっぱり大冒険…

小道具や機材を思う存分存分探検してから撮影開始。

今年のそとちゃんはあんまり集中力がなくて、
カメラマンさんも大変そうだった😹

目線を釣るためのおもちゃを持っていったのだが、
そとちゃんがあまりにも熱中してしまい逆効果だった😭

こんなこともあろうかと、
ここで秘密兵器のまたたびを投入！

…今度はまたたびを持つ俺を追いかけてしまい、
そとちゃん単体でうまく撮れない😭
(画角に俺の手が入ってしまった)

結局今回はほとんどカメラ目線を貰えずに時間(集中力)切れ…
つくづくねこ様は人間の思い通りにならないことを再認識した。

でも懲りずにまた来年も撮りに行こう…

風呂場

最近暑いから？そとちゃんがよく風呂場で遊んでいた。

そとちゃんが入れないように普段湯船に載せている風呂フタを立てて乾かしていたら、
いつのまにか侵入されていた。

一度入った湯船の中が気に入ってしまったようで、
何回引っ張り出してもまた入るようになった😹

自分が濡れないのを良いことに、
完全に調子に乗っている。

今の家に来てからあまりお風呂に入れてないので、
水が出る場所ということもわかってないのかもしれない😂

夏も近いし、久しぶりにシャンプーしちゃおうかしら…

カリカリマシーン

今まで4年くらい使っていたカリカリマシーンSPがついにお亡くなりになってしまったので、
久しぶりに自動給餌器を買い換えることにした。

最近はいろんなメーカーのものが出ているが、
結局今まで使っていたメーカーの最新機種を購入。
カリカリマシーンV2C

これが数年でかなり進化していて、
タンクの密閉度が上がり、乾燥剤用のポケットが内側についたのがめちゃめちゃ嬉しい。

今まではタンクの内側にテープで無理やり乾燥剤を取り付けたり、
タンクをラップで塞いで蓋に本を乗せたりと苦しい湿気対策をしていたが、
これで梅雨の時期にそとちゃんがカリカリ食べない問題が解決するかも…?

あとはいきなり機械が変わってそとちゃんがびっくりするかとも思ったが、
特に気にせず普通に食べてくれたのでよかった。
こういう図太いところは本当に手がかからなくて助かる…

これでカリカリいっぱい食べてくれ〜🙏🙏🙏

おわり

そとちゃんが8さい(推定)になった。

たぶん3さいでうちにお迎えしたので、
これでもう5年一緒に暮らしていることになる。

そとちゃんはどう思ってるかわからないが、
俺は毎日一緒にいられて楽しく幸せに過ごしているので、あっという間の5年間だった。

ここまで大きな病気もなく、まだまだうるさいくらいに元気だけど、
シニアねこであることには違いないのでこれまでよりも一層健康には気をつけていきたい。

そとちゃんの猫生なのであまり無理強いするつもりはないんだけど、
個人的には30さいのおばあにゃんになるまで元気でいてほしい…👵🐈

まずは元気な9さいを目指してがんばろう。

おまけ

4月のそとちゃん(2024)

Thu, 02 May 2024 00:00:00 +0000

まとめ

右目

冬の間調子が良かったそとちゃんの右目。

最近少し暖かくなってきて、
また目ヤニがひどくなってしまった。

こまめに専用のウェットシートで拭いているのだが、
これがそとちゃんは気に入らない。
(昔は嫌がらず拭かせてくれたのに…)

とはいえ目ヤニを放置するわけにもいかないのでなんとか耐えてもらう。

毛の根元にこびりついた目ヤニがなかなか取れないのだが、
強く拭くと肌がすぐ赤くなってしまうので、これがとても難しい…

月末ごろから少し目ヤニが収まってきてまたいい感じなので、
どうにかこの調子が続くとそとちゃんも俺も助かる。

毎年梅雨の時期が一番ひどいので、そうならないことを祈りたい。

箱

3月に通販でいろいろ買う機会があり、
久しぶりにそれなりの大きさの段ボールが手に入った。

袋派なはずのそとちゃん、意外にもこれに食いついた。

このごろ部屋に箱を置いてなかったので珍しいのかもしれない。

よく入ってガサゴソしている。

だいぶ箱が好きになったのか、
ねこ用ではない(ねこ用段ボールとは?)箱をたまたま放置していたらそれにも入ってくれた。

かわいい。

…
放置していた袋(これもねこ用ではない)にも入ってくれた。

かわいいね。

ユニフォーム

我が千葉ロッテマリーンズにソト選手が入団した。

それだけ。

こたつ

4月は新生活の時期ということで、
出しっぱなしだったこたつ布団を撤去することにした。

正直この冬はエアコンを多用していてあまり電源を入れなかったので、
そとちゃんもあっさり受け入れてくれるかと思ったが…

そこはねこが相手なので、思い通りにはいかない。
湯たんぽを入れた時以外入ってなかったくせに…

十数分の説得(※物理含む)の末、
布団の撤去に成功。

部屋はだいぶスッキリしたが、
そとちゃんはちょっといじけてしまった。

外した布団に恨めしそうに乗る姿がなんとも言えない。

湯たんぽは残すので、どうにか機嫌を治してほしいところ…

おわり

ねこにとってかなしい出来事はちょこちょこあったが、4月もそとちゃんは楽しそうだった。
多少嫌なことがあっても自分ですぐ機嫌を治せてえらいな〜〜！

5月には誕生日(元野良なので推測)が来るが、変わらず元気で楽しく過ごしてほしい。
(これを書いてる時点ではもう8歳になりました)

おまけ

3月のそとちゃん(2024)

Fri, 19 Apr 2024 00:00:00 +0000

まとめ

いたずら

そとちゃんがまた仕事机に登るようになってしまった。

ここ数年はパソコンの邪魔をすることもあまりなかったのに、
何がきっかけかわからないけど最近になってまたいたずら三昧。

マウスやイヤホン、紙類をちょいちょいいじるのが楽しくてしょうがない。
かわいいおててでしっかり床に落とす。

仕事中にも乗ってくるのですごい迷惑。
降ろしてもめげずにまた登ってくる。

こまった…

爆鳴き

最近のそとちゃんは机の上に登るだけじゃなくて、めちゃめちゃ鳴く。
とてもうるさい。

特徴的なのが、わざわざ俺から離れたところで爆鳴きすること。
仕方ないので席を立って撫でにいくとすごい満足そうにして、
また離れた場所に移動して再度爆鳴きする。
すごいかまってちゃん。

疲れれば大人しくなると思っておもちゃを投げてもあんまり遊んでくれない。
本当にこっちの気を引きたいだけらしい…

あとは仕事で通話してるときにすごく積極的に発言する。
たまに研修用の動画にも反応するので、たぶん人間の声に反応するのが好きなんだと思う。

元気なのは良いことだけど、
仕事中はもうすこしちゃんとお昼寝してくれると助かるなあ…

おわり

そとちゃんは相変わらず元気いっぱい。

というか年々わんぱくになってるような気がする。

今年で推定8歳になるはずなんですが、シニアねことは…?

おまけ

2月のそとちゃん(2024)

Tue, 19 Mar 2024 00:00:00 +0000

まとめ

見張り

2月は窓につけてあるねこ用ハンモックがそとちゃんのお気に入りだった。

ここにはそとちゃんが好きなブランケットを敷いているので、
寒い日でも全然平気らしい。

ブランケットだけでなく、
もちろん外の景色を見るのも大好き。

毎朝欠かさず、日が登るのを監視している。

毎朝欠かさず。

それはすなわち、寝ている俺を毎朝踏み台にしているということ。
ベッドとハンモックの間は別に自力で跳べる高さのはずなのに、
わざわざ寝ている俺の腹の上に乗ってからジャンプして登っている。

体重4kgしかないそとちゃんとはいえ、
たった数cm程度の足で全体重をかけて踏み切られると結構重いし痛い。

踏み台にするだけならまだしも、
降りるときも最近は躊躇なく俺の腹に着地してくる。
昔はそんなひどいことしなかったのにどうして…

もう一個低いハンモック買おうかな…

しろたん

そとちゃんが一番すきな寝床は、本棚の上のしろたん。
夜中に寝床を移動することはあるが、だいたい最初はここで眠りについて朝もここで眼を覚ます。

が、このしろたんもだいぶ汚れてきていて、
色もグレーになり、なによりも毛だらけ…

というわけで久しぶりにしろたんを洗うことにした。

決死の説得も虚しく武力衝突が起こってしまったが、
なんとか汚れたしろたんを回収。

抱きぐるみを洗うといっても着脱式なので、
カバーを外して洗濯機で回すだけで綺麗になった。

ここで(予想通り？)問題が発生。

そとちゃん7歳(ねこ)、多感なお年頃、洗われたしろたんが気に食わない…

勝手に洗われたことに怒っているのか、自分の匂いが消えて不安なのか、
全然使ってくれなくなってしまった。

これまで引っ越しや病院でもすぐに新しい環境に適応し、
ねこらしからぬ度胸を見せていたそとちゃんがここまで露骨に落ち込むのを見るとかわいそうになってくる。

それでもいつまでも乗らないと匂いもつかないので、
何回か抱っこして無理やり乗せてみた。
が、ダメ…

と思ったらあれ？
ある日気づくとあっさり寝ていた。

いったいなにがきっかけで気に入ったのか…?
よくわからないけど使ってくれてよかった。

とはいえ今回あまりにもかわいそうだったので、今後はもう洗わないかな…

おわり

ちょっと身の回りでいろいろあってクッソ遅筆になってしまった。

次回こそは…

おまけ

SSWAを受験した

Fri, 23 Feb 2024 00:00:00 +0000

まとめ

最強の資格SSWAを受験した。その体験記。

SSWAとは

IT系のエンジニアとして働く上で資格いるいらない論争はたまによくある。

「資格なんて要らん！実務での経験が重要だ！」という方は多いだろうし、
履歴書盛るために資格だけやたらと持ってる未経験者、みたいなのは自分も「？」と思うことはあるが、
「最低限の学習意欲の証明にはなるので無いよりはマシ、ただし持ってるから偉いということはない。」
くらいに考えている。

実際自分もいくつか資格は持っているし、
雰囲気で触っていたものについて体系的に学び直せることはメリットが多いと思うので、
年に数回ほど新しいものを取得している。

そこで重要になってくるのが「どの資格を選ぶのか」だと思う。
I○A, ○isco, Ora○le, AW○, CN○F, etc…
世の中にはたくさんの資格がある。でも人生の時間は限られている。
学ぶなら自分にとって本当に価値のある資格を選ぶべきだ。

そんな中で今回私が選んだのが、SSWA(Sauna Spa Wellness Advisor) だ。

SSWA¹とはJSSA(Japan Sauna Spa Association)²が認定している、
サウナやスパに関する正しい知識の活用を目的とした温浴施設の従業員や利用者向けの資格である。
つまり俺みたいなサウナ好きのおっさんのための最強の資格だ。
なんとあの厚生労働省が支援しているらしい。
~~(支援って具体的に何？？)~~

今回はその受験記である。

~~金さえ払えば取れるガバ資格~~とか~~怪しい利権団体~~とか言うやつは俺がぶっとばす。

(技術要素は)ないです

受験申し込み

どんな資格も受験の申し込みをしないと始まらない。

まずは公式サイトにアクセスする。

なんと安心感のあるWebページだろうか。
スクリプトは必要最小限、適度なイラストと必要な説明だけが記載されておりとても美しい。
テキストの内容をチラ見することもできる。
俺こういうの大好き。

ちなみにこのページ、なんと英語対応もされている。
画面右上のEnglishをクリックすると英語版ページが表示される。

英語版はHTMLほぼ直書きの漢らしいページだ。
こういうのでいいんだよ。

余談はこれくらいにして、
受験の申し込みは公式サイト下部のお申込みフォームから行える。
リンク先のフォームで下記の項目を入力して送信するだけで手続きは完了だ。

名前(ふりがな)
住所
電話番号
メールアドレス

そう。
クレジットカードを登録する必要がないのである。

ではどうやって受験料を支払うのだろうか？

代引きである。
この令和の時代に代引き。
万が一のサイバー攻撃にも備えてクレカ情報を自社側で持たないようにするセキュリティ意識の高さが伺える。

ちなみに代引きの支払いにはクレジットカードが使える。便利。
そういえば受験料は代引き手数料込みで5330円だった。
受験料がアホみたいに高いベンダー系の試験に比べてなんとお手頃だろう。

ただ、この代引きというのは厄介でもある。
宅配ボックスは使えず、支払いのために直接受け取らないといけないのだから不便だ。

俺の場合は幸運なことに在宅勤務なので無事に一発で受け取れたが、
特に1人暮らしで毎日出勤する社会人の場合はこの受け取りこそが本資格で最も難しい問題だと言えよう。

今回は申し込みから5日くらいで封筒が届いた。

中身はこんな感じ。

公式テキスト
試験問題
返信封筒

ここで気になるのが返信封筒。
宛先の物件情報をみると築39年のオフィスビル、約10坪ほどの事務所で運営されているらしい。
それほど人数の多い団体ではなさそうだ。
~~怪しい利権団体~~とか言うやつは俺がぶっとばす。

試験対策

SSWA試験の流れとしては

テキストを読む
試験問題を解く(制限時間60分)
回答用紙を記入して郵送

というかんじ。

驚いたのは試験官など監視の仕組みがないこと。
これではカンニングし放題、制限時間破り放題(?)ではないか。

否。
サウナを愛する人間は皆善人である。
サウナを愛する人間がカンニングなどするはずがない。
カンニングして合格するような人間にサウナを愛する資格はない。
JSSAはそう言うことが言いたいんだと思う。
~~金さえ払えば取れるガバ資格~~とか言うやつは俺がぶっとばす。

というわけでテキストを真面目に読んでいく。

テキストはB5サイズ、63ページほどの冊子だ。
内容はサンプルの通りで、
三章構成となっている。

第一章　サウナ・スパ健康法
- お風呂、サウナの効果や健康に良い入り方、サウナの歴史など
第二章　サウナ・スパ後のボディケア
- 入浴後に効果的なマッサージなど
第三章　サウナ・スパ施設内での応急手当
- サウナやお風呂で人が倒れた際の救急隊員に引き渡すまでの処置手順

第一章はとても勉強になる。この試験のメインテーマと言って良いだろう。
入浴法の具体的な手順まで紹介されていてタメになる。

第三章の心肺蘇生法などは自動車教習所で教わるものとほぼ同じなのであまり深く読む必要はなさそうだが、
やけどや脳貧血など、サウナならではの症状に応じた手当の方法は勉強になる。

一番難しいのは第二章、特にPart.2の「温まった体に効果的なツボ指圧 20選」である。
東洋医学のツボの名前と効能が列挙されており、これを一発で全て覚えるのはとても大変だ。
他の章の内容と比較してもおそらく試験で難しい問題があるとしたらこのパートの内容だろうと考え、
自分の場合はここを3周した。

試験

1,2時間程度でテキストを読み終わったら早速試験問題に取り掛かる。

公平性のために試験問題の内容全ては公開できないが、
テキストの内容に関連する3択問題の合計25問で構成されている。

テキストの指示に従い、60分タイマーをセット。
バリバリ問題を解いていく。

長らく味わってこなかった、エンピツで筆記問題を解く感覚。
学生時代にはあまり好きではなかった暖かみのある作業が今はとても楽しい。

問題の内容としてはテキストを読んでいれば正解がわかるものばかり。
ただし意地悪というほどでもないが、漢字や数値が違うだけの選択肢などがあり、
ケアレスミスには注意が必要である。

ちなみに自分がしっかり対策したツボの名前に関する問題は1つも出なかった。
試験問題を使い回しているとは到底考えづらいが、
ある回の試験で1問も出なかった、というのは今後の受験生の判断材料の1つになると思い書いておく。

回答にかかった時間は5分。
制限時間60分とはなんだったのか。

あとは回答用紙を封筒に入れて投函して試験は終了。
あらかじめ切手が貼ってあるのがありがたい。

結果

テストセンター等で受けるIT系の試験とは異なり、
合否がわかるまでにはかなりの時間がかかる。
きっと厳正な審査、採点がされていることだろう。

自分の場合は回答を投函してから10日ほどで何やら緑色の大きい封筒が届いた。

結果は…?

合格だった。

合格のご褒美として以下のものを受領した。

認定証
資格カード
ピンバッジ

認定証は卒業証書みたいな良さげな紙でできている。
あんまりこういうのもらったことないからうれしい。

資格カードは免許証サイズ。
こいつには後で重要な役割が待っている。

ピンバッジ…
~~これいる？~~

ちなみに得点が何点だったかはわからないようになっていた。
~~金さえ払えば取れるテキトー採点のガバ資格~~とか言うやつは俺がぶっとばす。

SSWAのメリット

このSSWA、合格して認定証をもらって終わりの資格ではない。
なんと合格者は資格カードを見せると全国各地の協賛店で割引サービスが受けられるのだ。

それも名店とされるスパ、スーパー銭湯、カプセルホテルばかりである。
正直なところこの特典目当てで受験した。
約5000円の受験料も、そのうち元が取れるだろう…

と思いきや、
よく行く店舗は既に会員になってしまっていたり(割引の併用ができない)、
俺がよく使う短時間コースは対象外だったりで、
取得してから今日までまだ割引の恩恵を受けられていない。😭
どうして…

おわり

SSWAに合格した。やったぜ。

特典の恩恵は受けられていないが、
これまで雰囲気で入っていたサウナに対して学ぶ良い機会となった。
1人のサウナ好きとして大いに自慢したい。
俺は一般の人よりサウナに詳しいんだ。資格を取った俺は偉いんだ。

また、SSWAより上位の資格としてSSPM(Sauna Spa Professional Manager)というものがあるらしい。
SSWA資格者しか受験できないということなので、機会があればぜひ受験したい。
(なお受験料は3倍の15000円💸)

おまけ

サウナ・スパ健康アドバイザー
アルファベットの方がなんかかっこいいので本記事ではSSWAと呼称する。 ↩︎
公益社団法人日本サウナ・スパ協会
同じく。 ↩︎

1月のそとちゃん(2024)

Fri, 02 Feb 2024 00:00:00 +0000

まとめ

湯たんぽ

クリスマスプレゼントで献上したねこ型湯たんぽが結構いい感じ。
期待していた通り、くっついて(乗っかって)仲良くしてくれている。

横に並べてみると本当にねこが2匹いるみたいでめちゃめちゃかわいい。
本当に買ってよかった…

ただ、そとちゃんが自分から横に並ぶのは稀で、
どちらかというと上に乗っかることが多い。

寒いときに湯たんぽをひざに載せていると普通にそとちゃんが上から乗っかりにくる。

たまに猫の上に乗る猫の動画とか見かけるけど、
ねこは下の子が重くてかわいそう的なことは考えないんだろうか…？

もしくは、そとちゃんはかしこいのでこれがねこじゃないことに気づいていて、
クッション感覚で乗っているのかもしれない。
毛繕いとかもしないし…

まあかわいければなんでもOKです。

あまえんぼ

理由は謎だけど、
最近そとちゃんの甘えがはげしい。

いわゆる要求鳴きが多い。
ドアを開けて欲しいときとかにわんわん鳴く。

ドアはそとちゃんが開けられないからしょうがないんだけど、
なんだか要求がエスカレートしてしまってついにはこたつの布団の前でも鳴くようになった。

ふとんを持ち上げろということらしい。
元々自力で潜ってたのに…

こたつに入るときだけならいいものの、
出たい時にも鳴くことがある。
俺はドアマンか…？

あとはひなたぼっこしたいのに太陽が出てないときにもよく鳴く。
俺が悪いみたいな雰囲気だしてくるけどこればっかりはどうしようもない。

仕方がないのでおもちゃで遊んでごまかす。
簡単にごまかされちゃうのもかわいい。

一番のあまえんぼポイントはやっぱりひざに乗ってくるところ。

ソファでだらだらしてるとすかさず乗ってくる。

一度ひざに乗ると長くて、
だいたい10分くらい、長い時は30分以上乗っている。
(不思議と脚はしびれない)

長く居て欲しいときはなでたりおしりを叩いたりするといい感じになる。
問題は早めに降りて欲しくなったときの手段がないこと…

おわり

年は明けたけど、そとちゃんは相変わらずのんびりだらだら過ごしている。
毎日がお正月みたいなものでとてもうらやましい。

そろそろ寒さもピークを過ぎるはずなので、
また近所で抱っこ散歩とかできるといいな…

おまけ

12月のそとちゃん(2023)

Sun, 31 Dec 2023 00:00:00 +0000

まとめ

カーテン

そとちゃんはカーテンが好き。

カーテンの薄い生地がきもちいいみたいで普段から裾をベッドの上に広げてあるのだが、
よくここでゴロゴロしている。

でもそとちゃんが自力でカーテンを持ち上げることはできないので、
俺が裾をベッドに広げ忘れているとお昼頃にすごく文句を言ってきてうるさい。

カーテン越しにちょっと光を浴びるのが好きなのかな？
ちょっと変なクセだと思うけどかわいい。

毛布

今月はちょこちょこ人を泊めることがあったので、
(ちなみにそとちゃんはお客さんが大好き!誰でもすぐに膝に乗る)
普段使っていなかったもう1枚の毛布を引っ張り出した。

すぐにそとちゃんに気に入られてしまった。

あまりにもお気に入りなので、
その後もそとちゃんが乗れるように畳んでソファに置いている。　　

当分の間片付けるつもりはないのに、
そとちゃんが必死に場所を守ろうとしているのが健気でかわいい。

やっぱりこたつ

カーテン、布団、毛布とお気に入りスポットがたくさんあるそとちゃん。

それでもやっぱり寒い日はこたつが好き。

あれ？ねこいないな？と思ったらだいたいこたつの中で寝ている。

丸まってるおしりとこたつ布団の境目が個人的にめちゃめちゃかわいい。

いいね〜

クリスマス

今年もそとちゃんにサンタマントを着てもらった。
めちゃめちゃかわいいねえ…

ハロウィンの時のマントもそうだけど、
やっぱり軽めの素材だとあまり気にならない様子。
嫌がらずに協力してくれた。

しっかりカメラ目線くれてたすかる。
(おもちゃで釣ったけど…)

そんな今年のそとちゃんへのクリスマスプレゼントは…?

ねこ湯たんぽでした。

そとちゃんがおるすばんのときは事故が怖くてこたつの電源を入れられないんだけど、
湯たんぽならこたつよりも安全に暖が取れると思い購入。

開けてみるとこんな感じ。
お店で見たときはそとちゃんくらいの大きさかな？と思ってたんだけど、
実際はかなり大きかった…

気に入ってくれるかわからないけど、
とりあえず温めてこたつに入れてみた。

楽勝でした。

この湯たんぽが結構暖かくて、
こたつの中がほかほかになるのでそとちゃん的にもいい感じらしい。

なによりもねこが2匹くっついてるみたいでかわいい。

よかったね〜

おわり

今年もそとちゃんは元気でいい子だった。

大きなアクシデントもなく、
毎日遊んで食べて寝て楽しそうだったので本当によかった。

シニアねこになって流石にちょっと落ち着いてくるかと思ったけど、
全然そんなことはなく元気に騒いで遊んで何よりだった。
ちょっとお昼寝の時間が長くなったかな？というくらい。

来年もそとちゃんが変わらず楽しく過ごせるよう、俺も頑張りたい。

おまけ

Azureのリソースグループ名に日本語を使うのはやめよう

Tue, 12 Dec 2023 00:00:00 +0000

まとめ

Azureのリソースグループ名に日本語(英数字以外の文字)を使用するとAzure内部での一部API呼び出し時にエラーが発生する
ASCIIで表記できる文字(英数字と簡単な記号だけ)を使おう

経緯

Azure Data Factoryを試したくてリソースを作成していたときのこと。

Azure Data Factory 用の Azure Private Linkを参考に、
同時にプライベートエンドポイントを作成しようとした。

各項目の設定はほぼデフォルトで、問題なくデプロイが開始した…と思ったら、
Data Factory自体のデプロイはできたもののプライベートエンドポイントの作成がコケてしまった。

なにいってだこいつ…

俺は愚かなお猿さんなので、
これを一時的なエラーと決めつけて脳死で再試行を10回程度繰り返したが、
一度も成功することはなかった…

~~〜fin〜~~

原因調査

俺は人類の誇りを取り戻し、
おとなしくエラーの内容を読むことにした。

表示されたエラーはこんな感じ。

{
 "code":"DeploymentFailed",
 "target":"/subscriptions/xxxxxxxxxxxxxxxxxxxxx/resourceGroups/ふがふが/providers/Microsoft.Resources/deployments/Microsoft.DataFactory-20231212010148",
 "message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.",
 "details":[
 {
 "code":"ResourceDeploymentFailure",
 "target":"/subscriptions/xxxxxxxxxxxxxxxxxxxxx/resourceGroups/ふがふが/providers/Microsoft.Resources/deployments/deployPrivateEndpoint-fugafuga-df-01-private-endpoint",
 "message":"The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'."
 }
 ]
}

Call to Microsoft.DataFactory/factories failed. Error message: The request URI ‘https://management.azure.com:443/subscriptions/xxxxxxxxxxxxxxxxxxxxx/resourcegroups/%25E3%2581%25B5%25E3%2581%258C%25E3%2581%25B5%25E3%2581%258C/providers/Microsoft.DataFactory/factories/fugafuga-df-01/privateEndpointConnectionProxies/fugafuga-df-01-private-endpoint.f596276c-4285-425c-9019-b5553ce6006e/operationstatuses/da7d1374-a224-428c-a13e-81c969ac4fa6?api-version=2018-06-01' is not valid, because it contains double encoding sequence ‘%25’. (コード: InvalidDoubleEncodedRequestUri)

重要そうなのは2つ目のエラー文のInvalidDoubleEncodedRequestUriの部分。
なんかデプロイ時に内部で叩かれてそうなAPIのURLに%25が含まれているのが問題と言われている(気がする)。

ここで怒られているURLをJSONのエラーメッセージに含まれるURLと比較すると、
%25E3%2581%25B5%25E3%2581%258C%25E3%2581%25B5%25E3%2581%258Cとふがふがの部分が対応してそうというか、
ふがふががURLエンコードされたものがそれっぽい。

実際に試してみると、ふがふがを2回エンコードしたものがまさに一致した。

# jqでURLエンコード
$ echo 'ふがふが' | jq -Rr @uri
%E3%81%B5%E3%81%8C%E3%81%B5%E3%81%8C

# 2回エンコードしたら'%25'を含むエラーメッセージのURLと同じものが出てきた
$ echo '%E3%81%B5%E3%81%8C%E3%81%B5%E3%81%8C' | jq -Rr @uri
%25E3%2581%25B5%25E3%2581%258C%25E3%2581%25B5%25E3%2581%258C

エラーの名前的にもこいつが原因と見て間違いなさそう。
(エラー名もInvalidDoubleEncodedRequestUri:リクエストURIの不正な二重エンコード(意訳)だし)

じゃあこのふがふがはどこからきているのかというと、
リソース作成時に指定するリソースグループの名前だった。

つまり…
リソースグループ名にマルチバイト文字を使用していると、
それがAPIのURLにエンコードされた時にエラーが発生する
…ってコト!?

修正

ならリソースグループ名がURLエンコードが発生しない文字、
すなわち半角英数ならいいんじゃね？

できちゃったねぇ…

というわけで、
Azureのリソースグループ名に全角文字を使うのはやめようと心に誓った。

他のケース

上記の例はかなりわかりやすかったが、
他のところでも全角文字が原因でData Factoryがうまく動かないことがあった。
(というか、本当のところはプライベートエンドポイントではなくこっちでめちゃめちゃ時間消費してこの問題に気づいた)

問題が起きたのはAzure Data Factory または Azure Synapse Analytics を使用して Azure Blob Storage のデータをコピーし変換するなどを参考にAzure Blob Storage上のExcelデータをData Factoryで整形するフローを作っていた時のこと。

Azure Blob Storage上のExcelをデータセットとして参照できる状態で、
それをデータフローのソースとして参照すると接続時にエラーが発生してしまった。

Request headers must contain only ASCII characters. - RunId: 69672633-6312-4832-95fc-90a3d2b54678

なにいってだこいつ…
他にエラーログが出ていないのでこのメッセージしかヒントにならないが、
どうやら文字コードで怒られている様子。

一瞬Excelのデータに全角文字列があるから…? と思ったが、
.xlsx形式で保存するときは文字コード選べないし、
そもそもデータセットとして.xlsxが参照できるようになっている時点でデータ中身の文字コードが原因とは考えづらい。
(実際.xlsx内の文字列を英数のみに替えたり、UTF-8で.csvとして出力したファイルに変えても変わらなかった)

リクエストヘッダがどうとか言ってるし、
これも内部で叩こうとしてるアクセス先(Azure Blob Storage)のURLにASCIIで表現できない全角文字のリソースグループ名(ふがふが)が入ってるからでは…?

もしこの読みが正しいなら、
リソースグループ名を英数字に変えたらうまくいくんじゃね…?

できちゃったねえ…

お気持ち

実際のところリソースグループ名に使える文字に制限はあるのだろうか。
公式ドキュメントを漁って調べてみた。

Azure リソースの名前付け規則と制限事項によると、
一応リソースグループ名に使用できる文字は

アンダースコア、ハイフン、ピリオド、括弧と、Char.IsLetterOrDigit関数で定義されている文字または数字。

となっているので、おそらくちゃんと読まずに日本語でふざけたリソースグループ名をつけた俺が100%悪い。

…が、ちょっともやもやするのはリソースグループ作成時に普通にマルチバイト文字が指定できちゃうこと。

リソースグループ名の入力時と作成前の検証ステップで何も怒ってくれないのはどうなんだろう…?
バリデーションは機能しているのだろうか…?

おわり

Azure初心者すぎてこんなところでコケてそこそこの時間を無駄にしてしまったので、
戒めとして書いてみた。

もちろんちゃんとルールを把握せず雰囲気で触った俺が100%悪いんだけど、
システムを壊すような操作はそもそもバリデーション等でユーザーがいじれないようにするべきだと思っているのでやっぱりもやもやする。
Azureとは仲良くなれなさそうだな…

おまけ

11月のそとちゃん(2023)

Sun, 03 Dec 2023 00:00:00 +0000

まとめ

こたつ

我が家もついにこたつを解禁！

10月中から寒さ(?)を訴えてきたそとちゃん。

11月中旬から急に冷え込んできたこともあり、
念願かなって今年のこたつを手に入れた。

解禁直後のそとちゃんの様子↓

よほど嬉しかったのか、
ぷーぷー言いながら潜っていくのがかわいい。

ふとんを内側に寄せて、その上に座るのがやっぱり好きらしい。

人間が先に入っていると、
こたつ布団の上から膝に乗ってくるのがかわいい。

よかったね〜

ふとん

そとちゃんがこたつを手に入れた裏で、
人間用のふとんも冬用のものに変えていた。

ニトリの毛布にもなる掛け布団カバーを買ってみたのだが、
なんとこれが一瞬でそとちゃんのものになってしまった。

肌触りが気に入ったのかな？
昼間はよくこの上でひなたぼっこしている。

こたつを手に入れて満足したはずのそとちゃんだったが、
気づけばこたつよりもこの布団の上にいる方が多くなってしまった。

やけど防止で最近はこたつの電源を入れずにエアコンで部屋を温めるようにしているので、
下はNウォームの発熱、上はエアコンの温風で十分暖かいのかもしれない。

とりあえずねこが幸せならそれでOKです。

いもむし

冬用ふとんに替えてからというもの、
たまに謎のいもむしが部屋に出現するようになった。

体の表面に手脚のようなものは見当たらず、
特に動く様子はない。

近づいてよくみてみると体表は毛皮で覆われており、
撫でてみるとゴロゴロ、プープーといった音を出す。

いもむしが発生するタイミングは完全にランダムだが、
俺が朝起きると腹の上にくっついていることがある。
結構暖かくてきもちいい。

まれにいもむしの別個体のような丸い毛玉が出現することもある。

この毛玉はいもむしよりもさらに動きが少ないが、
お腹のような部分が一定のリズムで膨らんだりしぼんだりしていて、
肺呼吸に近い動きをしていることがよくわかる。

特に害があるわけでもないので今のところ駆除はせずに撫でているが、
一体何者なんだ…?

おわり

10月は暖かすぎてついに日本も熱帯地域になったのか…と思っていたが、
11月中旬からしっかり寒気がやってきた。

そとちゃんは暖かい部屋でぬくぬく過ごしている。

野良猫時代は冬の時期も屋外で生活していたことを考えると、
その生活の過酷さを想像すると共に、今後は一生この生活をさせてあげたいと再認識する。

でも、ちょっと野生の誇りみたいなのを忘れてるんじゃないかな…?

おまけ

このブログをGithub PagesからFirebase Hostingに移行する

Wed, 29 Nov 2023 00:00:00 +0000

まとめ

ブログのお引越しをした。
(old) https://uzimihsr.github.io/ → (new) https://blog.uzimihsr.com/

GitHub Pagesでホスティングしていたこのブログのサイズが1GBを超えて更新できなくなってしまった
Firebase Hostingにブログを移行した
GitHub Actions上でのHugoビルドとFirebase Hostingへの自動デプロイを設定した
Cloudflare Registrarで取得したドメインをFirebase Hostingで使えるようにした
移行元のGitHub Pagesから移行先のFirebase HostingにJavaScriptでリダイレクトさせた

経緯

薄々気づいてはいたが、Hugo+GitHub Pagesで作ってるこのブログ(https://uzimihsr.github.io/)の合計サイズがかなり大きくなっていて、
GitHub Pagesのビルドにめっちゃ時間がかかったり、たまにコケたりするようになった。

Uploaded artifact size of 1111429120 bytes exceeds the allowed size of 1 GB. Deployment might fail.

GitHub Pagesの利用上の制限のページにもGitHub Pagesサイトのサイズは1GBが上限とちゃんと書いてある。
(読んでなかったか、読んだことを忘れていた。ごめんなさい…)

かといってこれまで書き殴ってきた記事を消したりするのもあまり嬉しくないので、
おとなしく別の場所にお引越しする。

やること

Webサイトのお引越し、あまりやったことがないのでほぼ手探りだが以下のような作業を想定している。

移行先の選定
- どこにお引越しするか決める
移行先にページを作成
- 実際にお引越し先にページを置いてみる
(やる気があれば)移行先でのCI/CD設定
- お引越し先でも自動でページがデプロイされるようにする
(やる気があれば)移行先のドメイン設定
- 自分の好きなドメイン名でアクセスできるようにする
移行元(GitHub Pages)から移行先へのリダイレクト設定
- 元のページを辿ってきた人が迷わないようにする

移行先の選定

まずは移行先を決める。

令和の時代、Webサイトのホスティングサービスは星の数ほど存在する。
“Webホスティングサービス比較"とかで検索すれば候補がいくらでも出てくるが、
自分の要件とコストに合ったものを選ぶべき…

なのだが、今回は脳死でGoogle Cloudに乗っかることにする。
理由は単純で、

規模がデカくて当分サ終しなさそうだから
個人的な事情(ひみつ)によりGoogle Cloudのクレジットが溜まっているから

という感じ。
こんなテキトーでいいのかな？いいよ(個人の趣味だし)

ただ、Google Cloudでのホスティング方法にも色々ある。
一応クラウドをお仕事にしてきたエンジニアなので、
練習としてCompute EngineやCloud Runでサーバ(コンテナ)を立ててデプロイや運用を頑張るべきなのでは…とも思ったが、
静的サイトなのにそんなことするの無駄に感じちゃったのと、
何より運用を頑張りたくないからFirebase Hostingを採用する。
料金を見た感じ10GBまでなら無料枠で使えそうなのもGood。

移行先にページを作成

Hugo公式でHugo製のページをFirebase Hostingに載せる手順が紹介されているのでそれに従う。

まずはブログ用のFirebaseプロジェクトを新規に作成。
UIから作る方法は世の中にいっぱい転がってそうなので敢えてCLIで作ってみる。

# Firebase CLIの更新
$ npm install -g firebase-tools

# CLIバージョン確認
$ firebase --version
12.9.1

# ログイン
$ firebase login --reauth

プロジェクト作成。
全世界で一意なプロジェクトIDを先に指定しなきゃいけないのが若干面倒。

# 適当なIDでプロジェクトを作成
$ PROJECT_ID=(project ID)
$ firebase projects:create $PROJECT_ID
? What would you like to call your project? (defaults to your project ID) blog
✔ Creating Google Cloud Platform project
✔ Adding Firebase resources to Google Cloud Platform project

🎉🎉🎉 Your Firebase project is ready! 🎉🎉🎉

Project information:
 - Project ID: (project ID)
 - Project Name: blog

Firebase console is available at
https://console.firebase.google.com/project/(project ID)/overview

世の中に同じプロジェクトID(他の人が先に作ったやつ)がある場合はこんな感じで怒られるので、
どうにかして一意なやつを考える必要がある。

$ firebase projects:create $PROJECT_ID
? What would you like to call your project? (defaults to your project ID)
✖ Creating Google Cloud Platform project

Error: Failed to create project because there is already a project with ID (project ID). Please try again with a unique project ID.

Having trouble? Try again or contact support with contents of firebase-debug.log

次にHugoプロジェクトのディレクトリでFirebaseプロジェクトを初期化する。
Firebase featuresはHosting: Configure files for Firebase Hosting and (optionally) set up GitHub Action deploysを選択。
Firebaseプロジェクトは先ほど作成したものを選択。
HugoでビルドしたページのHTMLとかはpublicディレクトリに出力されているのでそれをそのまま使う。
CI/CDの設定は一旦スキップし、
ページを上書きする系の質問はなんとなくNoとした。

$ firebase init

 ######## #### ######## ######## ######## ### ###### ########
 ## ## ## ## ## ## ## ## ## ## ##
 ###### ## ######## ###### ######## ######### ###### ######
 ## ## ## ## ## ## ## ## ## ## ##
 ## #### ## ## ######## ######## ## ## ###### ########

You''re about to initialize a Firebase project in this directory:

 /path/to/blog

? Which Firebase features do you want to set up for this directory? Press Space to select features, then Enter to confirm your choices. Hosting: Configure files for Firebase Hosting and (optionally) set up GitHub Action deploys

=== Project Setup

First, let''s associate this project directory with a Firebase project.
You can create multiple project aliases by running firebase use --add,
but for now we''ll just set up a default project.

? Please select an option: Use an existing project
? Select a default Firebase project for this directory: (project ID) (blog)
i Using project (project ID) (blog)

=== Hosting Setup

Your public directory is the folder (relative to your project directory) that
will contain Hosting assets to be uploaded with firebase deploy. If you
have a build process for your assets, use your build''s output directory.

? What do you want to use as your public directory? public
? Configure as a single-page app (rewrite all urls to /index.html)? No
? Set up automatic builds and deploys with GitHub? No
? File public/404.html already exists. Overwrite? No
i Skipping write of public/404.html
? File public/index.html already exists. Overwrite? No
i Skipping write of public/index.html

i Writing configuration info to firebase.json...
i Writing project information to .firebaserc...

✔ Firebase initialization complete!

そうするとこんなファイルが生成されている。

.firebaserc

{
 "projects": {
 "default": "(project ID)"
 }
}

firebase.json

{
 "hosting": {
 "public": "public",
 "ignore": [
 "firebase.json",
 "**/.*",
 "**/node_modules/**"
 ]
 }
}

本当は文法とかちゃんと勉強するべきだろうけど、
なんとなく.firebasercでFirebaseプロジェクトのIDを指定していて、
firebase.jsonでFirebase featureの種類と公開用ディレクトリの場所、
ホスティングしないファイルのパターンが指定されてそう。

早速Firebaseへのデプロイを試してみる。

$ hugo && firebase deploy
Start building sites …
hugo v0.98.0+extended darwin/arm64 BuildDate=unknown

 | EN
-------------------+-------
 Pages | 236
 Paginator pages | 123
 Non-page files | 753
 Static files | 0
 Processed images | 1982
 Aliases | 44
 Sitemaps | 1
 Cleaned | 0

Total in 5024 ms

=== Deploying to '(project ID)'...

i deploying hosting
i hosting[(project ID)]: beginning deploy...
i hosting[(project ID)]: found 5998 files in public
✔ hosting[(project ID)]: file upload complete
i hosting[(project ID)]: finalizing version...
✔ hosting[(project ID)]: version finalized
i hosting[(project ID)]: releasing new version...
✔ hosting[(project ID)]: release complete

✔ Deploy complete!

Project Console: https://console.firebase.google.com/project/(project ID)/overview
Hosting URL: https://(project ID).web.app

指定されたHosting URLを開くとページが閲覧できるようになっている。

やった〜。

CI/CDの設定

ページの手動デプロイができたので、
さらに自動で簡単にデプロイできるようCI/CDを設定する。
firebase initを再度実行し、今度はHosting: Set up GitHub Action deploysを選択する。
途中でGitHubへのログインを求められるが、
これに応えることでFirebaseへのリリース権限を持つTokenがGitHub ActionsのSecrets(FIREBASE_SERVICE_ACCOUNT_(project ID))に自動登録される。

$ firebase init

 ######## #### ######## ######## ######## ### ###### ########
 ## ## ## ## ## ## ## ## ## ## ##
 ###### ## ######## ###### ######## ######### ###### ######
 ## ## ## ## ## ## ## ## ## ## ##
 ## #### ## ## ######## ######## ## ## ###### ########

You''re about to initialize a Firebase project in this directory:

 /path/to/uzimihsr/blog

Before we get started, keep in mind:

 * You are initializing within an existing Firebase project directory

? Which Firebase features do you want to set up for this directory? Press Space to select features, then Enter to confirm your choices. Hosting: Set up GitHub Action deploys

=== Project Setup

First, let''s associate this project directory with a Firebase project.
You can create multiple project aliases by running firebase use --add,
but for now we''ll just set up a default project.

i Using project (project ID) (blog)

=== Hosting:github Setup

i Detected a .git folder at /path/to/uzimihsr/blog
i Authorizing with GitHub to upload your service account to a GitHub repository''s secrets store.

Visit this URL on this device to log in:
https://github.com/login/oauth/authorize?client_id=...

Waiting for authentication...

✔ Success! Logged into GitHub as uzimihsr

? For which GitHub repository would you like to set up a GitHub workflow? (format: user/repository) uzimihsr/blog

✔ Created service account github-action-201048321 with Firebase Hosting admin permissions.
✔ Uploaded service account JSON to GitHub as secret FIREBASE_SERVICE_ACCOUNT_(project ID).
i You can manage your secrets at https://github.com/uzimihsr/blog/settings/secrets.

? Set up the workflow to run a build script before every deploy? No

✔ Created workflow file /path/to/uzimihsr/blog/.github/workflows/firebase-hosting-pull-request.yml
? Set up automatic deployment to your site''s live channel when a PR is merged? Yes
? What is the name of the GitHub branch associated with your site''s live channel? master

✔ Created workflow file /path/to/uzimihsr/blog/.github/workflows/firebase-hosting-merge.yml

i Action required: Visit this URL to revoke authorization for the Firebase CLI GitHub OAuth App:
https://github.com/settings/connections/applications/...
i Action required: Push any new workflow file(s) to your repo

i Writing configuration info to firebase.json...
i Writing project information to .firebaserc...

✔ Firebase initialization complete!

指示にしたがって最後まで進めると今度は次のようなファイルが生成される。

.github/workflows/firebase-hosting-merge.yml

# This file was auto-generated by the Firebase CLI
# https://github.com/firebase/firebase-tools

name: Deploy to Firebase Hosting on merge
'on':
 push:
 branches:
 - master
jobs:
 build_and_deploy:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 - uses: FirebaseExtended/action-hosting-deploy@v0
 with:
 repoToken: '${{ secrets.GITHUB_TOKEN }}'
 firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_(project ID) }}'
 channelId: live
 projectId: (project ID)

.github/workflows/firebase-hosting-pull-request.yml

# This file was auto-generated by the Firebase CLI
# https://github.com/firebase/firebase-tools

name: Deploy to Firebase Hosting on PR
'on': pull_request
jobs:
 build_and_preview:
 if: '${{ github.event.pull_request.head.repo.full_name == github.repository }}'
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 - uses: FirebaseExtended/action-hosting-deploy@v0
 with:
 repoToken: '${{ secrets.GITHUB_TOKEN }}'
 firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_(project ID) }}'
 projectId: (project ID)

これらの変更をcommitしてmasterブランチに取り込む。

$ git add .
$ git commit -m "Firebase"
$ git push origin master

masterブランチにcommitが取り込まれると、早速.github/workflows/firebase-hosting-merge.ymlで定義されたGitHub Actionsが実行される。

これだけだとちょっとわかりづらいが、
Firebase側で確認すると確かにGitHub Actionsからリリースが走ったことが確認できる。

が、ここで問題が…
さっきまで見えていたFirebaseのページがPage Not Foundになってしまった。

元々このディレクトリではpublicディレクトリの内容をGitHub Pages用のリポジトリ(uzimihsr/uzimihsr.github.io)に反映させるためにsubmodule化しており、
おそらくGitHub Actions上ではこのディレクトリのファイルがファイルとして参照できてない?ような気がする。
(ローカルでfirebase deployしたときはpublic内のファイルが参照できていたのでリリース後にページが見られた)

actions/checkoutのREADMEを確認したところ、
submodulesというパラメータを指定することでsubmodule先のリポジトリが参照できるらしい。

.github/workflows/firebase-hosting-merge.ymlを次のように変更、masterにpushして再挑戦。

name: Deploy to Firebase Hosting on merge
"on":
 push:
 branches:
 - master
jobs:
 build_and_deploy:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4 # v3→v4に変更
 with:
 submodules: recursive # submodulesを参照するためのパラメータ
 - uses: FirebaseExtended/action-hosting-deploy@v0
 with:
 repoToken: "${{ secrets.GITHUB_TOKEN }}"
 firebaseServiceAccount: "${{ secrets.FIREBASE_SERVICE_ACCOUNT_(project ID) }}"
 channelId: live
 projectId: (project ID)

今度はActionsがコケてしまった。

repository ‘https://github.com/uzimihsr/uzimihsr.github.io.git/' not found clone of ‘git@github.com:uzimihsr/uzimihsr.github.io.git’ into submodule path ‘/home/runner/work/blog/blog/public’ failed

エラーメッセージ的に対象のリポジトリが参照できずエラーになっているっぽい。
ここで思い出したのだが、対象のリポジトリ(uzimihsr/uzimihsr.github.io)はPrivateリポジトリだった。

こういうときどうすんだろう…と思い再度actions/checkoutのREADMEを確認するとちゃんと答えがあった。
checkout対象のPrivateリポジトリに関する権限を持つトークンをtokenパラメータで指定すればいいらしい。
本当は真面目にGitHub App作るべきな気もするが、
今回はサクッとFine-grained PATで対象Repoに対するRead権限を持つトークンを作成する。

このトークンをGitHub Actionsを実行するリポジトリのSecretsに追加。

.github/workflows/firebase-hosting-merge.ymlにこのSecretを参照する記述を追加して再挑戦。

name: Deploy to Firebase Hosting on merge
"on":
 push:
 branches:
 - master
jobs:
 build_and_deploy:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 with:
 submodules: recursive
 token: "${{ secrets.PRIVATE_REPO_READ_TOKEN }}" # Secretsに追加したFine-grained PAT
 - uses: FirebaseExtended/action-hosting-deploy@v0
 with:
 repoToken: "${{ secrets.GITHUB_TOKEN }}"
 firebaseServiceAccount: "${{ secrets.FIREBASE_SERVICE_ACCOUNT_(project ID) }}"
 channelId: live
 projectId: (project ID)

今度はActionsが通った。
Firebase上のページも404が解消されてコンテンツが表示できている。

やった〜。

…と思ったけど、ここで気になったことが1点。
ビルドしたページを格納するpublicディレクトリをgit repoで管理し続ける必要ってあるんだろうか…?

Hugo公式のCI/CD設定手順でも

Don’t forget to update your static pages before push!

と紹介されているように、
この手順だとmarkdownの更新とhugoによるページのビルド(publicディレクトリの更新)は変わらずローカルPCで実施する必要がある。

どうせGitHub Actionsを使うなら、
Actions上でhugoを動かしてpublicディレクトリを更新するようにして、
ローカルでの作業はmarkdownの更新とgit pushだけにできないだろうか…?
(要はローカルPCからhugoを抜いても困らないようにしたい)

GitHub Actions上でHugoを動かす方法についてちょっと調べるとpeaceiris/actions-hugo@v2というものが出てきた。
(Hugo公式のGitHub Pages対応ページでもGitHub Actions上でHugoを動かす例はあるんだけど、今回はこのActionsを利用することにする)

READMEにしたがって.github/workflows/firebase-hosting-merge.ymlに追記してみる。

name: Deploy to Firebase Hosting on merge
"on":
 push:
 branches:
 - master
jobs:
 build_and_deploy:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 with:
 submodules: recursive
 token: "${{ secrets.PRIVATE_REPO_READ_TOKEN }}"
 - uses: peaceiris/actions-hugo@v2 # Actions上でのHugoセットアップ
 with:
 hugo-version: "0.119.0"
 extended: true
 - run: hugo --minify # Hugoビルドの実施
 - uses: FirebaseExtended/action-hosting-deploy@v0
 with:
 repoToken: "${{ secrets.GITHUB_TOKEN }}"
 firebaseServiceAccount: "${{ secrets.FIREBASE_SERVICE_ACCOUNT_(project ID) }}"
 channelId: live
 projectId: (project ID)

publicディレクトリ(submodule)が残ってると邪魔そうなのでついでに消す。

$ git submodule
 e328611c605affe6d4672527704f3f5c730f5289 public (heads/master)
 907f881f5d773d9d94a470fa5643fcaade904555 themes/hugo-theme-stack (v1.1.0-282-g907f881)

$ git submodule deinit -f public
Cleared directory 'public'
Submodule 'public' (git@github.com:uzimihsr/uzimihsr.github.io.git) unregistered for path 'public'

$ git submodule
-e328611c605affe6d4672527704f3f5c730f5289 public
 907f881f5d773d9d94a470fa5643fcaade904555 themes/hugo-theme-stack (v1.1.0-282-g907f881)

$ git rm public
rm 'public'

$ rm -rf .git/modules/public

$ git submodule
 907f881f5d773d9d94a470fa5643fcaade904555 themes/hugo-theme-stack (v1.1.0-282-g907f881)

この状態でmaster pushしてみるとどうなるか…?

やった〜。

最終的なGitHub Actionsの設定ファイルはこんな感じ。
結局Privateリポジトリへの参照が要らなくなったのでPAT(Secrets)は削除した。

.github/workflows/firebase-hosting-merge.yml

name: Deploy to Firebase Hosting on merge
"on":
 push:
 branches:
 - master
jobs:
 build_and_deploy:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 with:
 submodules: recursive
 - uses: peaceiris/actions-hugo@v2
 with:
 hugo-version: "0.119.0"
 extended: true
 - run: hugo --minify
 - uses: FirebaseExtended/action-hosting-deploy@v0
 with:
 repoToken: "${{ secrets.GITHUB_TOKEN }}"
 firebaseServiceAccount: "${{ secrets.FIREBASE_SERVICE_ACCOUNT_(project ID) }}"
 channelId: live
 projectId: (project ID)

.github/workflows/firebase-hosting-pull-request.yml

name: Deploy to Firebase Hosting on PR
"on": pull_request
jobs:
 build_and_preview:
 if: "${{ github.event.pull_request.head.repo.full_name == github.repository }}"
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 with:
 submodules: recursive
 - uses: peaceiris/actions-hugo@v2
 with:
 hugo-version: "0.119.0"
 extended: true
 - run: hugo -D --minify
 - uses: FirebaseExtended/action-hosting-deploy@v0
 with:
 repoToken: "${{ secrets.GITHUB_TOKEN }}"
 firebaseServiceAccount: "${{ secrets.FIREBASE_SERVICE_ACCOUNT_(project ID) }}"
 projectId: (project ID)

ドメインの設定

Firebaseで公開したページはデフォルトで無料のドメイン(project ID).web.appが付与されている。
これがプロジェクト作成時にidをユニークにしたために結構ダサい名前になってしまったので、
いい感じのドメインに変えてあげたい。
(HTTPS化されてればドメインはあんまり気にしないつもりだったけど、idが想像以上にダサかったので…)

ドメイン取得はGoogle Domainsでやりたかったが、サ終しているので他を探す。
いろいろ探した結果、Cloudflare Registrarが一番安くてUIもしっかりしているので採用。
uzimihsr.comを取得した。
(手順のメモを忘れたけど、クレカの登録ができれば後はとにかく簡単だった。費用は1年で$9.77くらい。)

Firebase公式のカスタムドメインを接続するを参考に進めてみる。

まずはFirebase Hosting側で先ほど取得したドメインを追加する。

この状態で続行するとDNSに登録すべきレコードが表示される。

この表示されているレコードをCloudflare側でDNSに追加する。

TXTレコードの設定をしてから反映されるまでにちょっと時間がかかる。
30分くらい経つとドメインの準備が完了し、
ホスティングへの誘導で追加のレコードが表示されるのでこれを再度DNS側で追加する。

ここからの待ち時間が結構長い。
最大24時間かかると言われたが、それ以上待っても状況が変化しなかった。

泣きながら色々調べたらこんなのを発見。
https://community.cloudflare.com/t/flexible-ssl-redirect-loop-with-google-firebase/2063/3
https://developers.cloudflare.com/ssl/troubleshooting/too-many-redirects/#flexible-encryption-mode

どうやらオリジン(今回はFirebase Hosting)側でhttp→httpsへのリダイレクト設定がある状態でCloudflare側のSSL/TLS暗号化モードがフレキシブル(デフォルト)だとリダイレクトループが発生するらしい。
解決するにはこの暗号化モードをフルに変更すれば良いとのこと。

するとあっさりホスティングへの誘導が完了し、対象のドメイン名でページが表示できるようになった。

0.00001%くらいの確率で今度ブログ以外にもページを作りたくなるかも…と思ったので、
ブログ専用のサブドメイン(blog.uzimihsr.com)なども同様の手順で追加した。
https://blog.uzimihsr.com/

最終的な設定はこんな感じ。

移行元から移行先へのリダイレクト設定

ブログの移行ができたので、いよいよ移行元のGitHub Pagesが不要になった。

本当はいきなり爆破できれば楽なんだけど、
割といろんなところに記事のリンクを貼って(貼られて)しまっているので404になるのは好ましくない。

というわけで移行元のURLでアクセスされたときに移行先の同じページにリダイレクトするようなページを作成して、
既存のGitHub Pagesを差し替えるようにしたい。
(例) https://uzimihsr.github.io/post/2023-11-11-handmade-pc/ → https://blog.uzimihsr.com/post/2023-11-11-handmade-pc/

ちょっとググってみたところGitHub Pagesでは.htaccessが使えず301リダイレクトができないっぽいので、
脳死でJavaScriptを使ったリダイレクトを試してみる。
参考: https://www.w3docs.com/snippets/javascript/how-to-redirect-a-web-page-with-javascript.html

index.html

<!DOCTYPE html>
<html lang="en">

<head>
 <meta charset="UTF-8">
 <title>Moved!</title>
</head>

<body>
 <h1>Moved!</h1>
 <p>You will be redirected in 5 seconds...</p>
 <p>If you are not redirected, <a href="https://blog.uzimihsr.com">click here</a>.</p>
 <script>
 const newHost = "https://blog.uzimihsr.com";
 setTimeout(() => {
 window.location.href = newHost;
 }, 5000);
 </script>
</body>

</html>

404.html

<!DOCTYPE html>
<html lang="en">

<head>
 <meta charset="UTF-8">
 <title>Moved!</title>
</head>

<body>
 <h1>Moved!</h1>
 <p id="newUrl"></p>
 <p>You will be redirected in 5 seconds...</p>
 <p>If you are not redirected, <a href="https://blog.uzimihsr.com">click here</a>.</p>
 <script>
 const newHost = "https://blog.uzimihsr.com";
 const redirectUrl = window.location.href.replace(
 window.location.origin,
 newHost
 );
 document.getElementById("newUrl").innerHTML = "new URL: " + redirectUrl;
 setTimeout(() => {
 window.location.href = redirectUrl;
 }, 5000);
 </script>
</body>

</html>

あとはGitHub Pagesにこの2枚のHTMLだけを残し、それ以外のファイルを全削除。

$ pwd
/path/to/uzimihsr/uzimihsr.github.io

$ ls -a1
.
..
.git
404.html
index.html

$ git add . 
$ git commit -m "bye-bye GitHub Pages"
$ git push origin master

元のhttps://uzimihsr.github.io/を開くとindex.htmlが開かれてこんな感じになる。

5秒放置するとhttps://blog.uzimihsr.com/にジャンプ(リダイレクト)する。
(JavaScriptが無効だと動かないけど)

https://uzimihsr.github.io/post/2023-11-11-handmade-pc/みたいにホスト名以降のパスが指定されている場合、404.htmlによってhttps://blog.uzimihsr.com/post/2023-11-11-handmade-pc/にリダイレクトする。

これで移行元から移行先へのリダイレクト設定もできた。

ブログのお引越し作業は以上で終わり。

おつかれさまでした…

おわり

手探りでめちゃめちゃ時間はかかったが、
なんとかブログのお引越しができた(はず)。

たいへんだった〜。
Firebase Hostingならページのサイズは10Gまで無料だし、
それを超えても課金すれば継続して利用できるはずなので
きっと二度とやることはないでしょう…🚩

おまけ

自作PCを組んだ

Sat, 11 Nov 2023 00:00:00 +0000

まとめ

初めて(ちゃんとした)自作PCを組んでみた。
その過程で自作初心者の自分が考えたこととかのメモ。

種類	名前+型番	税込価格(円)
CPU	Intel® Core™ i5-13500	34,980
マザーボード	ASUS TUF GAMING B660-PLUS WIFI D4 (CPUとセット売り)	20,000
グラフィックボード	MSI GeForce RTX™ 4070 VENTUS 2X 12G OC	85,800
CPUクーラー	DeepCool AK400 R-AK400-BKNNMN-G-1	3,480
メモリ	Crucial 64GB Kit (2 x 32GB) DDR4-3200 UDIMM CT2K32G4DFD832A	16,500
SSD	Western Digital WD_BLACK SN850X NVMe™ SSD WDS100T2X0E	12,980
電源	玄人志向 KRPW-GA750W/90+	13,480
ケース	ADATA XPG VALOR AIR JP2 VALORAIR-WHJ2	7,480
OS	Windows 11 Home	17,980
合計		212,680

BTOの方が安く済んだとか言っちゃいけない。
これは趣味です。

性能については後で記述するが、
ホグワーツ・レガシーが解像度UWQHD(3440×1440)の75fpsでそこそこ快適に遊べている。

自分の理解度

組み始める前の自作PCに関する知識はこんな感じ(だった)。
ガッチガチのPC初心者というわけではないと思う。

各パーツの役割やソフトウェア周り(BIOS/UEFI, OS)はなんとなく理解している
組み立ての手順はわかっていない

だいぶ昔にBTOを利用したことはあるけど、
自力で組んだことはないしパーツの選び方とかもよくわかっていなかった。

目的/予算

自作経験者に「自作PC組みたいんだよね〜」と聞くと必ず返ってくるのが
「目的と予算は？」だと思う。
今回はこんな感じ。

目的
- 家にMacしかないのでWindows機が欲しい
  - Windows on MacOSの構成はあまりやりたくなかった…
- ホグワーツ・レガシーをストレスなく遊びたい
- ついでに動画編集もできるとうれしい
予算
- 20万円前後

それっぽい理由を並べているが、
実際のところはただ単に自作という行為に憧れがあったというのが大きい。

構成

組み終わった今振り返ると、
自作の工程で一番大変で一番楽しいのがパーツ選びだったように思う。

とりあえず初心者がいろいろ考えたところでろくな結果にはならないと思い、
今回は金だけ持って脳死でツクモに行ってきた。

なのでほぼ店員さんの受け売りにはなってしまうが、
パーツ選びのときに考えたことを将来の自分のために書いておく。
(店員さん忙しそうなのにめちゃ優しかったです、ありがとうございました)

※情報は購入時(2023年9~10月ごろ)のもの

CPU

Intel® Core™ i5-13500

Intelにした理由
お店に行くまではAMD(Ryzen)の方がIntel(Core)よりお手頃価格だと思っていたのだが、
実際には最新のRyzen7000シリーズだとメモリの規格がDDR5に縛られてしまい、
マザーボードとメモリを合わせたトータルだと13世代Intel Coreシリーズの方が若干安くなる計算になった。

13世代はDDR4,5両対応だし、将来DDR5で組みたいとなった時にも使えるはず。
(その頃にはCPUも新しいのが欲しくなってそうだが…)

13世代Core i5にした理由
性能について強いこだわりはなく、
13世代Coreシリーズであればi5で十分、
i7との差額をグラボの費用にあてるべきと判断した。

i7以上だと冷却も水冷/簡易水冷を検討しなきゃいけなくて値段が嵩張るというのもある。

12世代にしてもっと安くできたかもしれないが、
自分が購入した時期だと12世代の在庫(選択の幅)が少なかった。

内蔵GPU有りにした理由
内蔵GPU非搭載のモデル(近いやつだとi5-13400F)と若干迷ったが、
グラボがぶっ壊れたときのトラブルシュートを考えて内蔵GPU有りのモデルにした。
あと内蔵GPUの有無でそこまで値段が変わらなかった。

本当の理由
マザーボードとセット売りされてて安かった。

マザーボード

ASUS TUF GAMING B660-PLUS WIFI D4

ATXにした理由
デカいと組みやすい。
組み終わった後で考えてみると、確かにパーツ同士の干渉とかを気にせず組めた気がする。
(Micro-ATXとかの規格で組んだことないから正確なところはわからんが…)

DDR4にした理由
CPU選びの際にも触れたが、安いから。
自分が選んだタイミングではDDR5対応のマザーボードが軒並みお高めだった。

Wi-fiモデルにした理由
ルーターとの距離とかもそんなにないので有線LANで良いのだが、
Bluetoothを楽に使いたかった。
組んだ後もネットワークは有線、デバイスはBluetoothで繋いでいる。

本当の理由
CPUとセット売りされてて安かった。
あと元々は12世代Coreシリーズ向けのモデルだが、
お店でBIOSアップデート済みだったので余計な作業が発生せず助かった。
(13世代CPUとセット売りだから当然と言われたらそれはそう)

グラフィックボード

MSI GeForce RTX™ 4070 VENTUS 2X 12G OC

NVIDIAにした理由
なんとなく馴染みのあるメーカーだから。
AMD Radeonも一瞬考えたけど、
そこまで安くなかったのとCPUがAMDじゃないので相性とかも別にいいかな…となった。

RTX 4070にした理由
最初はVRAMの容量重視で4060Ti(VRAM 16GB)を考えていたんだけど、
自分が使うモニターのスペック(UWQHD/75Hz)だとVRAMよりもコア数の方がカギになるとのことでちょっとお金を積んで4070にした。

あとは電力効率が良く冷却のことをそこまで考えなくて良さそうだったのもポイント。

MSIにした理由
一番安かった。

本当の理由
RTX 4080以上のハイエンドだと流石に予算的にキツかったし、
万が一壊したときのことを想像したくもなかった。
あとCPUのボトルネックガーとか言われると泣きそうだった。

CPUクーラー

DeepCool AK400 R-AK400-BKNNMN-G-1

空冷にした理由
水冷はメンテが面倒…と思っていたらメンテが簡単な簡易水冷というのもあるらしい。
が、簡易水冷も冷却水が補充できないとかで寿命があったり、
価格もお高めということで初心者も安心な空冷に落ち着いた。

CPU付属のクーラーにしなかった理由
今回のCPUにはトップフロー型のファンが付属でついていたが、
性能が低いとのことで諦めた。

このモデルにした理由
光ってないから。
虹色は個人的に好きじゃないのと、
下手に光ってねこちゃんにいたずらされるのが怖かった。

あと安かった。
この価格帯の中では性能が良くてかなり人気らしい。

組み立てのことを考えるとグリス塗布済みなので自分で塗る必要がなくてうれしい。
取り付け方の動画が公式で提供されてたのも助かった。

メモリ

Crucial 64GB Kit (2 x 32GB) DDR4-3200 UDIMM CT2K32G4DFD832A

DDR4にした理由
CPU選びの際にも触れたが、やっぱり安いから。
64GBだと特にDDR5より安かった。

64GBにした理由
~~メモリサイズでマウントをとりたかったから~~
趣味で長めの動画や4K動画を書き出すことがあるので、
快適に作業できるようにしたかった。

このモデルにした理由
DDR4, 64GBの中では一番コスパが良さそうだった。
あと光ってないから(重要)

SSD

Western Digital WD_BLACK SN850X NVMe™ SSD WDS100T2X0E

1TBにした理由
2TBでも良いかと思ったんだけど、値段を考慮して1TBにした。
もし足りなくなってもメモリよりは追加しやすいはずだし…

このモデルにした理由
読み出し速度が爆速だから。
ゲーム用途を考えると速ければ速いほどいいらしい。

あと光ってないから。
(最近はSSDも光るらしい。気を抜くとPCパーツはすぐ光る)

電源

玄人志向 KRPW-GA750W/90+

750Wにした理由
グラボとCPUの消費電力(200W+65W)を考慮するとだいたい2~~3倍の650~~750Wくらいが良いと考えていた。

このモデルにした理由
入門用の価格帯で一番パフォーマンスが良いとされるものを選んだ。
あとケーブルがプラグイン方式なのも組み立ての際に配線が楽だった。

ケース

ADATA XPG VALOR AIR JP2 VALORAIR-WHJ2

選んだ理由
とにかく安かった。
ケースファンが元々3(前面)+1(背面)台ついていて、
かつファンコントロール機能があるものの中では一番安かった。

とにかく見た目を地味にしたかったので本当は側面が透明でないものがよかったが、
今そんなモデルはほとんどないらしく実際にお店にも在庫がなかった。

組み立て

ねこに手伝ってもらいながらなんとか組み立てられた。

パーツの取り付けは割とカンタンだった。
決められたソケットに端子をはめ込んでいくだけなのでプラモデル感覚でできた。

動画には残せてないが一番手間取ったのが配線。
電源ケーブルをマザーボードのどこに刺すかでめちゃくちゃ迷った。

最初の電源投入時は絶対失敗するとか画面に何も映らないとか聞いてたのでめちゃめちゃビビってたが、
今回は運良く一発で起動できたので嬉しかった。

最終的にパーツの取り付けからOSインストールまでは合計で4,5時間くらいかかった。
休日を消しとばすにはいい趣味になりそう。

性能

動くものが組めたので性能を見てみる。

CINEBENCH

自作PCを組んだらまずはベンチマークを回すものらしいのでCINEBENCH 2024を試してみた。

スコアはこんな感じ。

Type	Score(pts)
GPU	16598
CPU(Multi Core)	1051
CPU(Single Core)	98

正直スコアの見方がよくわかっていないが、
概ね他サイト等で公表されている値より10%低い程度なのでまあこんなものか…? 誤差…?
何かが足を引っ張ってるのかもだけど、冷却の度合いとか色々条件があるんだろうな〜。
極端に低いわけじゃないので、初期不良とか取り付けミスの線はあまりなさそうでひとまず安心。

以下、ベンチマークの参考にさせていただいたサイト
https://www.cgdirector.com/cinebench-2024-scores/
https://pcrecommend.com/cpu/cinebench2024/

ホグワーツ・レガシー

そして自作PCを組んだ大きな目的だった、ホグワーツ・レガシー起動中の状況はこんな感じ。
MSI Afterburnerで左上にCPU,GPUの状態を表示させている。

ゲーム側の設定は画質が最高品質、
フレームレートは75fps(ディスプレイのリフレッシュレートが75Hzのため)、
レイトレーシングOFF、
その他はたぶんいじってない。

解像度はUWQHD(3440×1440)なんだけど綺麗に表示できていて、
フレームレートも常時75fpsに張り付いている。

レイトレーシングをONにするとたまに重く感じることもあるが、
素人の自分には正直ON/OFFの違いがわからなかったのでOFFにして遊んでいる。
(まだ光が反射するような場面で遊んでないからかも…)

あとはVRAMの使用量が10GBくらいほどあり、
12GBのVRAMで一応耐えられているか…?という感じ。
CPU, GPUの使用率は落ち着いているので多分楽しく遊べているんじゃないかな…?
一応推奨スペックのULTRA仕様くらいは満たせてそうだし…

おわり

新しい趣味が増えるのはたのしい。
ほぼ初めての経験でちょっと不安だったが、意外と動くものが組めてよかった。
相談に乗ってくれたおともだちのみんなとツクモの優しい店員さんに感謝でございます。🙏

またお金と時間に余裕ができたら今度はRyzen+Radeonで小型のものも組んでみたい。
パーツ選びで見るべきポイントとかもなんとなくわかったので、
暇な時にふらっとPC専門店に行ってパーツを眺めるのも楽しそうだな〜。

おまけ

10月のそとちゃん(2023)

Sun, 05 Nov 2023 00:00:00 +0000

まとめ

まるい

最近はそとちゃんがまるまっていることが多かった。

なんかおとなしいな〜と思ったらだいたいバリバリボウルで丸くなっている。
(ひなたぼっことか遊んでるときはそとちゃんがちょこちょこ喋るので音でわかる)

さほど暖かくないボウル(段ボール製)の上でまるまるのは何か意図があるのだろうか…?

「私はこんなに寒い思いをしています」
とアピールしてはやくこたつを出させようとする作戦かもしれない。

でもこたつ出すとそとちゃん本当に動かなくなっちゃうし…

右目の調子

8月くらいから怪しかった右目の目ヤニだが、
だんだんと良くなってきた感じがする。

もちろん完全に出なくなることはないんだけど、
ひどい時に比べるとドロっとした目ヤニは少なくなった。

目ヤニが少なければウェットシートで簡単に拭き取れるのでこちらも助かるし、
そとちゃんも嫌なお手入れが短く済んでうれしそう。

いいね〜

よく遊ぶ

元々よく遊ぶそとちゃん。

薄明薄暮性だからか、
特に朝と夕方は元気に走り回っている。

朝は7~8時ごろにエンジンがかかり出す。
(もしかしたらもっと早く起きてるかも?その時間は俺が寝てるからわからない)

遊ぶところを見ていてほしいのか、
一人遊びできるおもちゃで遊ぶ前にも必ず俺に向かって鳴いてくる。

かわいい。

夕方も17~18時くらいになると急に爆鳴きして走り回る。

朝に比べると、
夕方は一緒に遊ぶ系のおもちゃ(猫じゃらしとかねずみのおもちゃ)を期待していることが多い。

それ以外におもちゃに強いこだわりはなく、
目の前にあるものでなんでも遊んでくれる。

たくさん遊んでえらい！

ハロウィン

今年のハロウィンもそとちゃんに仮装してもらった。

やっぱりマントは嫌がらずに着てくれてかわいい。

次はクリスマスかな…?

おわり

9月に救急にお世話になったのを忘れてしまうくらい、
10月のそとちゃんは元気だった。

今年は10月でもまだまだ暖かい日が続いていて、
体温調節がぶっ壊れるかと心配したがねこは平気な様子。

そとちゃんははやくこたつに入りたがっているようだが、
当分の間は暖房なしでも暮らせちゃいそう…
果たして11月はこたつの出番があるのだろうか…?

おまけ

9月のそとちゃん(2023)

Fri, 13 Oct 2023 00:00:00 +0000

まとめ

病院

年1回のワクチン接種で病院へ。

毎度のことながらキャリーには自分から飛び込んでいく。

いくらやる気があっても車移動がやっぱり苦手で、
道中はずっと鳴いていた。

病院についたころにはお疲れの様子。

診察室に入ると最初はビビって出てこなかったが、
キャリーから出したあとは落ち着いていた。

体重は4.1kg、体温は37.5℃。
触診と心音も問題なしだった。

前回と違って、
おしりで体温を測るときにあまり暴れずえらかった。

先生が薬を取りに行っている間にまた探検。

元々注射は得意なので、ワクチンは暴れずにあっさり接種完了。
たくさん探検して落ち着けたのも良かったかもしれない。

帰りの車内でもわんわん鳴いて、
家に着いたらすぐお昼寝。

おつかれさまでした。

ソファ

そとちゃんはソファの主である。

そもそも家の主がそとちゃんだろうと言われればそれはそう…
なんだけど、最近は特にお気に入り。

爪とぎ防止のためにかけてた布を6月くらいから違うものに変えたのだが、
その触感が気に入ったっぽい？

気がつけばだいたいソファに座っている。

主なので当然なのだがそとちゃんはソファの真ん中に座る🤔

元々2人がけの小さめソファなので、
そとちゃんが真ん中に居ると人間が座る余地はない。

俺が床に直座りしてても譲る気はないらしい😭

気にいってくれたなら何よりです…

病院その2

月末のある日のこと。

晩ごはんを食べた後いつものようにそとちゃんをお腹の上に載せてまったりしていたら、
体勢を変えようとしたそとちゃんがバランスを崩してベッドに落ちてしまった。

嫌な予感がした。
いつもならベッドに落ちそうになると爪を立ててふんばる(痛い)はず。

抱っこしてみるといつもより力が抜けていてぐったりしていて、
やっぱり様子がおかしい。

意識ははっきりしていて呼びかけにも応えるんだけど、
普段より元気が無くて一度座るとそのまま全然動かない。

試しに歩行を促しても数歩歩いたところですぐ座り込んでしまう。

骨折や脱臼を疑い手足をさすってみても痛がるような反応はなかった。

これはまずいと思い、深夜だったが病院に電話。
幸いすぐに診てくれるとのことだったので車で病院へ。

車中ではいつも以上にそとちゃんが大騒ぎ。
キャリーの中で爆鳴きしたかと思ったらすぐに吐いてしまった。

病院に到着してすぐに診察。
(事前に受け入れの準備をしてもらえていて非常にありがたかった)

車中ではよく確認できなかったが嘔吐物は茶色で、
晩ごはんの猫缶を吐いたような感じだった。

診察でまず聞かれたのは誤飲の可能性。
過去に一度やらかしているがそれ以降一度も変なものを飲みこんだことはなく、
紐状や口に入るサイズのおもちゃの管理は気をつけていたはず。
直近でおもちゃが消えたこともなかったのでこれはなさそう。

先生によると呼吸が荒く、
肺の音に乱れがあるので急いでレントゲンとエコーを撮ることになった。

待合室で検査を待つこと30分。
先生に「状態が良くないかもしれない」と言われたのを頭の中で繰り返してしまい、
正気ではいられなかった。

…診察の結果。
エコーやレントゲンの結果はとても綺麗で、内臓や骨に大きな問題はなかった。

強いて言えば血中酸素濃度が少し低く、胃と膵臓に若干炎症があるかも？というくらいだが、
急性膵炎の場合はもっと高頻度で嘔吐するので違うだろうという診断。
可能性を考えられるのは急性胃腸炎だが、
1度吐いた後すっかり元気なので、なんとなくただ気持ち悪かっただけかもしれないとのこと😭
(呼吸や肺の音が荒かったのは吐いた直後だったからっぽい)

精密検査は不要になったが、
念のため急性胃腸炎の対症療法を行うことに。
吐き気止めと消化器促進のお薬としてセレニアとプリンペランの注射、
それと嘔吐で失った水分を補う皮下注射(点滴のようなもの)を打ってもらった。

処置後も元気にしていたので入院せずそのまま帰宅。
注射をしたのでご飯を無理に食べさせる必要はないが(食べられるなら食べてもOK)、
再度吐いたり呼吸が荒くなったらまた連れてくるようにとのことだった。

帰宅後はそれまでが嘘だったかのように元気に部屋の中をうろうろ。

なんとなくごはんを欲しがる素ぶりをしていたので試しにちゅーるをちらつかせたらあっさり食いつき、
ものすごいスピードで完食。

その後はいつも通り元気に夜鳴き&運動会をしてから就寝。

翌朝も何事もなかったかのように寝ていた。

それ以降も吐いたり様子がおかしくなることはなく、
いつもの元気に叫んで走り回るそとちゃんになった。
よかった…

(お財布には大ダメージ💸)

おわり

9月は2回も病院に行くことになってしまい、
しもべとしては大変だったが本人(ねこ)は至って元気だった。

夜間救急にお世話になった件ではお金は飛んだが、
様子が怪しいと思った時にすぐに行ける病院があることと、
深夜でも躊躇なく病院に行く判断ができたのは良かったと思う。
お金は飛んだが(重要)。

ここからだんだん寒くなってくるはずだが、
病院にかかることがないくらい元気に過ごしてもらいたい。

おまけ

8月のそとちゃん(2023)

Sat, 09 Sep 2023 00:00:00 +0000

まとめ

ハンモック

窓に取り付けてあるねこ用ハンモック。

8月はここがお気に入りだった。

毎朝必ずここにいて、どうやら夜もハンモックで寝ている様子。

寝てない時は外で飛んでる鳥を観察したり、
ベランダの洗濯物を監視してくれている。
たすかる(?)

(ちなみにクラッキングはしない。シャーと同様にやり方がわかってなさそう😹)

窓のカーテンが閉まっているとそとちゃん1人ではハンモックに登れないので、
開けろ開けろとわんわん鳴いたりする。

かわいいね〜

電動ねこじゃらし

だいぶ前に買った電動ねこじゃらし。
すぐ電池が切れちゃうのであんまり使っていなかった。

最近充電式電池を買ったので、
久しぶりに出してみたらねこ大喜び。

飽きずによく遊んでいる。

たまに興奮しすぎて(ねこが)どっかに飛んでいくのが意味わかんなくておもしろい。

安全のために何分か経ったら勝手に止まるようになってるんだけど、
ねこは遊び足りなくてプレッシャーをかけてくる。

たのしそうだし運動不足も解消できていいね〜

涙やけ問題

8月の後半あたりから右目の目ヤニというか涙やけがひどくなってきた。

毎年梅雨の時期にこの症状が出ていて、
今年は珍しく落ち着いていると思ったが結局ちょっと遅れて来てしまった。😿

これ(猫風邪の後遺症)は保護されたときからのことで、
病院でも治すのは難しいと言われているが…

やっぱりみてるとこっちがつらくなってくる。

例年涼しくなると症状がマシになるので、
早くおさまってほしい。

おわり

8月も元気だったそとちゃん。

右目はかわいそうだけど、
本人(ねこ)はあんまり気にしてないし毎日元気に食べて遊んで寝ている。

今年の夏は暑すぎてあまりできていなかったが、
またキャリーおさんぽにも行きたいので(というかねこが行きたがってそう)早く涼しくなってほしい。

おまけ

7月のそとちゃん(2023)

Thu, 17 Aug 2023 00:00:00 +0000

まとめ

ひなたぼっこ

夏。

あつすぎる。

なのにねこは毎日窓際でひなたぼっこ。

暑くないのだろうか。

最近は日の出も早いので、
欠かさず朝からスタンバイ。

天気が悪いと不機嫌になるくらいにはお日様が好き。

日に当たりすぎるのも良くないと思い時々抱っこして移動させるが、
目を離すと勝手に窓際に戻ってしまう。

ねこは常に自分の気持ちよさ優先で、
たとえ暑いと感じていても日差しが気持ちいいとやめられないとかなんとか。

ちょっとアホなのがかわいい。

常にエアコンガンガンで部屋はそこまで暑くないし、
そとちゃんが楽しいならいいか…

袋

何十回目かの袋ブーム到来。

ニトリさんのでかいレジ袋にクタクタになった紙袋を入れただけのいつものやつ。

いつか捨てようとおもって放置していたらまた気に入られてしまった。

最近はこの袋がもうビリビリに破けていて、
ただ上から乗るだけの寝床になっている。

いい加減新しい袋に替えたいけど、
捨てたら怒りそうだな…

おわり

ただただ書くのが遅い。

そとちゃんは相変わらず元気。
むしろ俺の方が暑さにやられてしまっているかもしれない。

おまけ

6月のそとちゃん(2023)

Mon, 17 Jul 2023 00:00:00 +0000

まとめ

草

一瞬の気の迷いでうっかり猫草を買ってしまった。
(前科があるのに…)

やっぱりそとちゃんは草が大好き🌱

というか草ジャンキー。😵‍💫

大喜びでカッ喰らう。

そして吐く🤮
(汚いので写真なし)

あまりにも勢いよく食べては吐くのを繰り返してしまうので、
ごほうびとしてたまにお風呂場であげることにした。

右の奥歯を抜いてしまったので、
うまく噛みきれずどうしても顔が左に傾いちゃうのがかわいそうだけどちょっとかわいい。

草が室内にあるとそとちゃんが食べすぎてしまうので基本はベランダに置いていたが、
そとちゃんはあまりにも草が好きすぎて窓に張り付く始末。

日中はずーっと草を眺め続ける生活になってしまった。

また、お風呂場で草をあげるのが習慣化していたので
「お風呂場に行く→草が出てくる」と覚えてしまった様子。

脱衣所のドアを閉めて入れないようにすると今度はその下から無理やり手を突っ込んできた。

草への執着心がもはや中毒者のそれである。

そんな草ライフを送っていたそとちゃんに悲劇。

連日の猛暑に耐えきれず、
草が日焼けして枯れてしまった😢

吐きすぎるとそとちゃんの健康にもよくないので、
そのまま処分して代わりの草も買わないことにした。

また俺の気が狂った時に買おう…

カーテン

草を見張る目的で窓際にいることが多かったそとちゃんがカーテン遊びにハマってしまった。

元々カーテンの生地が好きみたいでよく上に乗っていたのだが、
最近は薄い布がひらひらするのが面白いようでよく遊んでいる。

もぐったりしばいたり(?)、遊び方は多彩。

カーテンが丈夫な素材でそとちゃんの爪では破けないのが幸い。

思う存分遊んでストレス解消してくれればそれでいいです。

ソファ

そとちゃんのストレス解消法は他にもある。

それはソファでの爪研ぎ😭

以前から肘掛けのところをよく破壊していたのだが、
流石にやりすぎて手応えがなくなったのか最近は座るところの側面がターゲットになっている。

ひっくり返って仰向けになり、
バリバリしながら移動していく。
まるで天井に張り付いたクモのような洗練された動き🕷️
(動画を撮れなかったのが残念)

うちはのびのび教育がモットーなので
そとちゃんに危険がない限りは何やっても怒らないんだけど、
それでも糸くずが出たりクッションの中身が出るのが怖いので対策することにした。

破壊された部分に雑に当て布をして補強🪡
さらに座面に毛布をかけてバリバリしづらくした。

当て布にちょっと硬めの素材を選んだので、
そとちゃんがバリバリしてもなかなか破けない👍

なお、背もたれ側…😭

おわり

自分が最近妙に忙しく、
書くのがめっちゃ遅くなってしまった。

最近は猛暑日が続くけどそとちゃんは元気(エアコンガンガンだし)。
毎日叫んで走り回っている。
このまま夏バテ知らずで乗り切りたい。

おまけ

5月のそとちゃん(2023)

Tue, 06 Jun 2023 00:00:00 +0000

まとめ

誕生日

元野良なので誕生日がわからないそとちゃん。
一応5月生まれということにしていて、今年でたぶん7さいになった。

今年の誕生日プレゼントはでかいキャットタワー。

(たぶん)誕生日プレゼント pic.twitter.com/gYZXuybmcA
— ずみし (@uzimihsr) May 1, 2023

組み立て中から興味津々。

今回買ったやつは天井と床に突っ張るタイプで、
本当に天井ギリギリくらいまでの高さがある。

最大の特徴はこの透明なボウル。

ここに入ってるところを下からみたらめっちゃかわいいんだろうな…と思って買ったが、
そとちゃんは透明な部分が穴に見えたみたいでなかなか入ってくれない。

慣れてもらうためにお気に入りのおもちゃをボウルに入れてみた。

浮いてるように見えるのが不思議みたいで興味を持ちはじめるそとちゃん。

そこからは割とあっさりで、
おもちゃでちょこちょこ遊んでるな〜と思ってたら数分後にはすっぽり入っていた。

たすかる〜〜😊

おまちかねのローアングルはこんな感じ。

ご自慢のピンク肉球がぺったりついてて超かわいい…🥰

誕生日ごはんは例年ケーキを買ってアホみたいに残されるので、
今年はシンプルにいつものおやつとちゅーるだけでお祝いした。

今年も余裕の完食。

ごちそう pic.twitter.com/NjpaUe1vd8
— ずみし (@uzimihsr) May 1, 2023

今年も無事に誕生日が迎えられてよかった。

ちなみに今まで使ってたキャットタワーもいまだに現役。

というか、1週くらいしたら結局元のタワーに登る方が多くなってしまって、
新しいやつでは全然遊ばなくなってしまった…

しっぽです pic.twitter.com/zdi0FkQ7AY
— ずみし (@uzimihsr) May 29, 2023

一瞬でも楽しんでくれたならOKです。

記念写真

ここ数年は毎年写真屋さんで誕生日の記念写真を撮ってもらっている。

今年も同じところで撮ってもらった。

被写体 pic.twitter.com/6q4AFayOG7
— ずみし (@uzimihsr) May 21, 2023

そとちゃんはやっぱりスタジオで大興奮。

隅から隅まで探検する。

気が済むまでうろうろしてからいざ撮影。

今年はそとちゃんが協力的だったのかカメラマンさんが上手なのか、
結構スムーズに撮ることができた。

あとはおもちゃを大量に持参してカメラマンさんの後ろで振りまくったのがよかったのかもしれない。😂

今年は集中力が切れることもなく、そとちゃん単体でもたっぷり撮ってもらうことができた。
(去年は落ち着きがなさすぎて俺が無理やり抱っこして撮ったものが多かった)

今年もかわいい写真をたくさん撮ってもらえてよかった。

おわり

そとちゃんが無事に7さいを迎えられた。
推定3さいのころにお迎えしたので、もう丸4年一緒に暮らしていることになる。

そとちゃんが保護されるまでよりも俺と暮らしている時間の方が長くなった(推定)というのはなんかうれしい。

8さいも健康に迎えられるように頑張ろう…

おまけ

4月のそとちゃん(2023)

Fri, 05 May 2023 00:00:00 +0000

まとめ

手術

ついにスケーリング手術を行うことになったそとちゃん。

全身麻酔の手術は2回目なので、そとちゃんも俺も慣れたもの。
当日の体調もよく、キャリーにも自分から入り意気揚々と病院へ。

それでも診察室に入ると急にぐずりだす。
昔はあんなにはしゃいでたのに…

なんとか(無理やり)引っ張り出し、
当日の検査も体重4.1kg, 体温37.8℃でほぼ問題なし。

全身麻酔と手術内容についての説明をしっかり受け、
そとちゃんを預けた。

俺はそのまま前回同様近所の神社で神頼み。

術前術後の電話をもらい(手術自体はかなり早く終わった)、
麻酔が切れたあとの経過観察が終わってから夕方にお迎え。

ここで悲しいお知らせ。

一番症状がひどかった右上の奥歯だが、
ぐらつきがひどかったため抜歯になってしまった。

これが術前の状態。
奥歯が黒くなっているのと、他の歯も根本が若干黄色くなっている。

術後がこんな感じ。
抜歯したほか、黄色く歯石がついていた部分を綺麗にしてもらった。

術後の説明も上記画像などを混ぜながら丁寧にしてもらった。
口腔内にウイルス性の症状は見受けられなかった(単純に歯石がついていただけ)とのことで、
追加の通院などは不要になった。

術後のそとちゃんはこの表情。
超しょんぼりしている。

前回の手術のときもそうだったけど、
麻酔で寝てる間におしっこがちょっと漏れておしりが汚れるのがめちゃめちゃ嫌みたい。
かわいそう…

帰宅後は疲労困憊かと思いきやごはんをよこせと大騒ぎ。

先生から「術後は痛みもあるしお水だけで大丈夫ですよ…」と言われていたが、
この日のそとちゃんは麻酔に備えて前日の夜10時から何も食べておらず腹ペコなのだった。

すこしだけおやつを出したらすぐ完食。

そんな感じで大変な一日が終了。

翌日は心配なので丸一日付きっきりで様子を見ていたが、
初めこそちょっとだるそうにしていたもののお昼頃にはいつも通り遊んで食べて寝ての生活に戻った。

ちょっと元気出てきた pic.twitter.com/oQPbuuYKAO
— ずみし (@uzimihsr) April 3, 2023

一応処方してもらった痛み止めの薬もちゃんと飲んだ。
えらい。

抜歯跡は出血もなく、綺麗に塞がった。
1本だけ抜いたので噛み合わせが悪くなるのでは？と心配だったが、
よくわかんないけどねこはそういうのあまり気にしない生き物らしい。

くわ〜っ pic.twitter.com/mGdzi8pNCw
— ずみし (@uzimihsr) April 26, 2023

とりあえずお口まわりの問題が無事に終わって良かった。

ちなみに今回かかった費用はこんな感じ。
お財布に大ダメージ…

こたつとさようなら

そとちゃんにとって悲しい出来事がもう一つ。

ついにこたつを撤去した。

こたつなくなった pic.twitter.com/Bo4fdRMWY6
— ずみし (@uzimihsr) April 28, 2023

片付ける片付けると言い続けてもう4月。
4月も中旬からかなり暖かくなってきたのでいよいよ片付けることにした。

まずはこたつがなくても部屋が暖かいことを理解してもらうため、
こっそり電源を落とすところから…

こたつの電源を落とすところから始めていく pic.twitter.com/v1huvgXKV7
— ずみし (@uzimihsr) April 13, 2023

が、ダメ。
毎日こたつでゴロゴロしているそとちゃんにはすぐバレてしまった。

そとちゃんは意志が強いので、
電源が入るまでこたつの周りをうろうろにゃんにゃんする。

こうなるとそとちゃんと俺で根比べになるのだが、
集中力が続かない俺と違ってそとちゃんはおもちゃやおやつにも釣られず命懸けで抗議を続ける。
そんなそとちゃんに勝てるはずもなく、
このときは片付けを断念。

懸命の抗議活動で暖かいこたつを取り戻したねこ pic.twitter.com/REhyHn031i
— ずみし (@uzimihsr) April 19, 2023

しかしこの1週間後、転機が訪れる。
たまたまタイミング良く(?)、そとちゃんがこたつ布団の上にGEROを吐いてしまったのだ。

これでは仕方ないので速攻で布団を外して洗濯に。

そんなわけで長く続いたそとちゃんのこたつ生活は割とあっけなく終了したのだった。

かなしそう pic.twitter.com/ONevBHblnK
— ずみし (@uzimihsr) April 28, 2023

今回の冬もたくさんお世話になったこたつ。
また半年後くらいに会いましょう…

こたつがなくても太陽がある pic.twitter.com/G9S7Zu8kKU
— ずみし (@uzimihsr) April 13, 2023

おわり

春は別れの季節なので(?)、4月はそとちゃんにとって悲しいイベントが多かった。
かわいそう。

歯の件は心配だったけど本人(ねこ)はあんまり気にしてない様子。
せっかく綺麗にしてもらったのでこれを継続できるように歯みがきをがんばりたいところ。

こたつは結構むりやり撤去してしまったが、
2日も経たないうちに他の場所でごろごろするようになったのでこれもそんなに気にしてないと思いたい。
というか4月下旬は流石にもう暑かったし…

5月でそとちゃんは(たぶん)7さいになる。
一緒に暮らし始めてからもう4年になることにただただ驚き。

おまけ

3月のそとちゃん(2023)

Thu, 06 Apr 2023 00:00:00 +0000

まとめ

表情

そとちゃんの表情はよくわからない。

イカ耳になってるときのねこって不機嫌なはずなんだけど、
そとちゃんはこんな感じで思いっきり耳を絞ってても喉をゴロゴロ鳴らしていたりする。

この顔で超ごきげんなのよくわからない pic.twitter.com/HVxjfpJN9k
— ずみし (@uzimihsr) March 24, 2023

この状態のときはなかなかひざから降りないので本当に機嫌がいいはず。

逆に仰向けになってリラックスしてるようにみえるときでもめちゃめちゃ機嫌が悪いことがある。

激おこねこちゃん pic.twitter.com/63boxsg8AP
— ずみし (@uzimihsr) March 17, 2023

このときは頭をなでようとしただけでも攻撃してくる。
どうして…

こんな感じでそとちゃんのご機嫌は表情からではよくわからない。
結局のところ喉を鳴らしているかどうかで判断している。

…ちなみに喉を鳴らしながら何故か攻撃してくることもあるので本当のところはなにもわかっていない。

テレビっ子

去年の年末くらいに我が家にでかいテレビを導入した。

#WorldBaseballClassic pic.twitter.com/XtlfABJaZE
— ずみし (@uzimihsr) March 21, 2023

それまで使っていた小さいテレビにはあまり興味がなさそうだったそとちゃんだが、
さすがにこの大きさと明るさ(あと画質がチョーきれい)だと気になる様子。

世界ネコ歩きを流しっぱなしにしてると結構集中して見ている。
(前のテレビで流しても全然見なかった)

ちなみにテレビに向かって話しかけたり画面にちょっかい出したりはしないので、
映っているねこが本物じゃないというか本当はそこにいないことは理解してるっぽい。
かしこい。

最近のテレビはYouTubeも見られるということで、
試しにこんな感じの鳥やら小動物がぴょこぴょこ映る猫用動画を流したら大ハマり。

こたつの上にどかっと座ってずーっと見ている。
カウチポテト？

YouTubeを観る現代っ子 pic.twitter.com/h5MNczcJJZ
— ずみし (@uzimihsr) March 26, 2023

仕事中にそとちゃんがめちゃ暴れてるときとかに流すと一瞬で大人しくなるので助かる。

子供にYouTubeを観せて大人しくさせる親の気持ちがちょっとわかった気がする…

病院

だいぶ前から歯石が気になっていたそとちゃんだったが、
3月の中旬から毎日の歯磨きを本当に痛がるようになってしまったため病院へ行った。

体重は4.08kgでいい感じ、
体温は37.6度でちょっと低めだった。

診察してもらったところやはり歯肉炎が酷くなっていて、
スケーリング(歯石除去)をすることになった。

この日は施術を行わず、
全身麻酔の準備として血液検査だけやってもらった。

結果は毛包嚢胞の手術のときと同様にグロブリン(免疫機能を示すやつ)が高めで、
やはり猫風邪の後遺症があるのだろうという話。
それ以外の数値は問題なく健康だった。

この日は天気が良かったので、
診察後は久しぶりのお散歩がてら歩いて家まで帰った。

病院から家の途中にはいい感じの池がある公園があって、
そとちゃんは結構満喫していた様子。

10分くらいずーっと見ていた。

結局1時間くらいお散歩して、家についたらごほうびタイム。
ものすごい勢いでちゅーるを貪る。

全身麻酔の手術は不安だけど、
とりあえずそとちゃんは元気だった。

おわり

かなりあったかくなってきて、そとちゃんは毎日いい感じ。
よく遊んで食べて寝て元気に過ごしている。
テレビばかりだと退屈しそうなのでそろそろお散歩を再開してもよさそう。

ちなみにこたつはまだ片付けられていない。
4月こそは強い意志を持って片付けたい。

(ネタバレ?になるけどこの日記を書いている時点でスケーリングの手術は成功しているが、いろいろあったので来月ちゃんと書く)

おまけ

2月のそとちゃん(2023)

Tue, 14 Mar 2023 00:00:00 +0000

まとめ

お留守番

大変申し訳ないのだが2月はそとちゃんにお留守番してもらう機会がちょっと多かった。

そとちゃんは自立した大人の女性(推定6歳)だし、そんなのは余裕…

ではない。

お留守番のときはこんな感じでめちゃめちゃ機嫌が悪くなる。

普段俺が家にいてもごはんのときと遊ぶとき以外ほとんど寝てるのに、
外出から戻ったタイミングでは高確率で起きて文句を言いにくる。

ごはんは自動給餌器で出している(しかもこの場合はちゃんと完食する)ので、
空腹ではなくお留守番させられたことに腹を立てているのは確か。

ちなみにこのとき顔は怒っていて耳もイカ耳になるのだが、
しっぽはピンと立って震えているので
お留守番させられた怒りとしもべ(俺)が帰ってきた喜びが混ざり合った変な感情になっている。
ような気がする。

とてもかわいい。

また、お留守番中はずっと寝ているわけではなく、
結構元気に走り回っていることもある。

たまに外出先からペットカメラで見ているので何をしてるかはだいたい筒抜けなのだが、
そうとは知らないそとちゃんはこのとき結構悪さをする。

普段登ると怒られる台所に乗ったり、ソファを破壊したりと割とやりたい放題。

最初お迎えした頃(まだ毎日出社していた時期)はお留守番余裕ねこちゃんだったので、
この数年の在宅勤務で俺が常に家に居る状況に慣れてしまったのかもしれない。
(お留守番中に吐いたりトイレの失敗はないのでひどい分離不安とかではないと思いたいが…)

こたつのプロ

こたつの上に乗る楽しみを見つけたそとちゃんだったが、
2月はどちらかというとこたつの中で過ごすことが多かったように思った。

こたつ pic.twitter.com/e4N7cZFaWu
— ずみし (@uzimihsr) February 2, 2023

2月は部屋の乾燥が気になってエアコンを止めることが多かったりしたのでそのせいかもしれない。

特に寒い日の朝なんかは気づいたらこたつの中にいた。

こたつの中で寝るときにはこだわりがあって、
入るときに頭で布団を押して内側に折り込んでその上に寝っ転がるのがけっこう好き。

こたつ pic.twitter.com/YQ0umUlguz
— ずみし (@uzimihsr) February 8, 2023

もちろんそうじゃないときもある。

ねてる pic.twitter.com/oESUDYjISD
— ずみし (@uzimihsr) February 7, 2023

こたつの中で溶けてるときのそとちゃんがかわいくて、
ついつい写真を撮ってしまう。

こたつ pic.twitter.com/MuhlU0mWTI
— ずみし (@uzimihsr) February 16, 2023

が、やりすぎると普通に嫌そうにする。
むずかしい。

おわり

そとちゃんは2月もごろごろして元気だった。

これを書いている時点(3月中旬)でだいぶ暖かくなっているのでこたつはそろそろ片付けたいが、
果たして無事にいくだろうか…

おまけ

jq/yqでオブジェクトのキーを正規表現でフィルタする

Mon, 13 Feb 2023 00:00:00 +0000

まとめ

jq(yq)のwith_entries, select, testを組み合わせるとオブジェクトのキー名の正規表現でフィルタをかけることができる。

# regexには正規表現のパターンを記述する
jq "with_entries(select(.key|test(\"${regex}\")))"
yq "with_entries(select(.key|test(\"${regex}\")))"

環境

jq 1.6
yq v4.30.8

キーに正規表現を当てる

こんな感じのJSONまたはYAMLについて、.config配下のspec111とspec222の要素だけを正規表現で抜きたいとする。

こんなときはwith_entriesとselect, testを使うと良い感じにできる。

# 先頭がspecで始まり数字で終わるパターン
$ regex='^spec[0-9]+$'

$ cat example.json | jq ".config | with_entries(select(.key|test(\"${regex}\")))"

{
 "spec111": {
 "aaa": 123,
 "bbb": 456
 },
 "spec222": {
 "aaa": "abc",
 "bbb": "def"
 }
}

$ cat example.yaml | yq ".config | with_entries(select(.key|test(\"${regex}\")))" 

spec111:
 aaa: 123
 bbb: 456
spec222:
 aaa: abc
 bbb: def

なにが起こっているのか

jq Manualによるとwith_entries(foo)は
to_entries | map(foo) | from_entriesと同じ意味なので、
先ほどのコマンドを下記のように分解して何が起こっているのか詳細を追っていく。
(yqについてもjqとほぼ同じはず)

# 下記2行は同じ操作
jq ".config | with_entries(select(.key|test(\"${regex}\")))"
jq ".config | to_entries | map(select(.key|test(\"${regex}\"))) | from_entries"

# yqについても同じ
yq ".config | with_entries(select(.key|test(\"${regex}\")))" 
yq ".config | to_entries | map(select(.key|test(\"${regex}\"))) | from_entries"

まずはto_entriesから。

これを噛ませるとキーの文字列に.keyとしてアクセスできるようになる。
https://stedolan.github.io/jq/manual/#to_entries,from_entries,with_entries
https://mikefarah.gitbook.io/yq/operators/entries

$ cat example.json | jq ".config | to_entries" 

[
 {
 "key": "spec111",
 "value": {
 "aaa": 123,
 "bbb": 456
 }
 },
 {
 "key": "spec222",
 "value": {
 "aaa": "abc",
 "bbb": "def"
 }
 },
 {
 "key": "metadata",
 "value": {
 "hoge": "fuga"
 }
 }
]

$ cat example.yaml | yq ".config | to_entries"

- key: spec111
 value:
 aaa: 123
 bbb: 456
- key: spec222
 value:
 aaa: abc
 bbb: def
- key: metadata
 value:
 hoge: fuga

to_entriesを噛ませた結果は配列として出力されるので、
この配列の要素を正規表現でフィルタするためにmap, select, testを噛ませてやる。

https://stedolan.github.io/jq/manual/#map(x),map_values(x)
https://stedolan.github.io/jq/manual/#select(boolean_expression)
https://stedolan.github.io/jq/manual/#test(val),test(regex;flags)

https://mikefarah.gitbook.io/yq/operators/map
https://mikefarah.gitbook.io/yq/operators/select
https://mikefarah.gitbook.io/yq/operators/string-operators#test-using-regex

select, testの条件にto_entriesで追加された.keyを指定することでキー名で正規表現をかけることができる。

$ regex='^spec[0-9]+$'

$ cat example.json | jq ".config | to_entries | map(select(.key|test(\"${regex}\")))"

[
 {
 "key": "spec111",
 "value": {
 "aaa": 123,
 "bbb": 456
 }
 },
 {
 "key": "spec222",
 "value": {
 "aaa": "abc",
 "bbb": "def"
 }
 }
]

$ cat example.yaml | yq ".config | to_entries | map(select(.key|test(\"${regex}\")))" 

- key: spec111
 value:
 aaa: 123
 bbb: 456
- key: spec222
 value:
 aaa: abc
 bbb: def

あとはto_entriesのフォーマットの配列をfrom_entriesで元のキーと値の形式に戻してやる。

$ regex='^spec[0-9]+$'

$ cat example.json | jq ".config | to_entries | map(select(.key|test(\"${regex}\"))) | from_entries"

{
 "spec111": {
 "aaa": 123,
 "bbb": 456
 },
 "spec222": {
 "aaa": "abc",
 "bbb": "def"
 }
}

$ cat example.yaml | yq ".config | to_entries | map(select(.key|test(\"${regex}\"))) | from_entries"

spec111:
 aaa: 123
 bbb: 456
spec222:
 aaa: abc
 bbb: def

最初のコマンドと同じ結果が得られた。

おわり

jq(yq)でオブジェクトのキーに対して正規表現でフィルタをかけることができた。
マジで便利。

おまけ

1月のそとちゃん(2023)

Fri, 10 Feb 2023 00:00:00 +0000

まとめ

こたつの上

前からちょいちょいこたつの上でごろごろしていたそとちゃん。

たまたまそこにタオルを放置していたら、いつのまにかそとちゃんのものになってしまった。

タオルすき pic.twitter.com/KDL1YSQVtb
— ずみし (@uzimihsr) January 13, 2023

あったかくて肌触りがやわらかいのが気に入った？

せまいのにはみ出さないように乗っかっててかわいい。

おまんじゅう pic.twitter.com/IltrJi9gfu
— ずみし (@uzimihsr) January 20, 2023

訂正。
はみ出てるときもある。

とけた pic.twitter.com/8e16Anh8DC
— ずみし (@uzimihsr) January 17, 2023

この後一回タオルにうっかり吐いてしまい洗うことになったが、
その間すげー悲しそうだったのでよっぽど気に入ったんだと思う。
(なかったらなかったでこたつの上には乗る)

ドア

あったかい時期は部屋のドアを開けっぱなしにしていたのだが、
最近は廊下の冷気がキツいので頻繁に閉めている。

そしてそとちゃんは自力でドアが開けられない。
(世の中には器用にドアノブを回しちゃうねこもいるみたいだけど…)

ドアを開けてほしいねこ pic.twitter.com/Fdq16nBJGC
— ずみし (@uzimihsr) January 31, 2023

廊下を走り回るのが好きなそとちゃんはこれが不満で、
昼夜問わずドアの前でわんわん鳴いている。

仕方がないので開けてあげるとそとちゃんが廊下に飛び出す。
うっかり締め出してしまわないように、戻ってくるのを待ってからドアを閉める。
またそとちゃんが走りたくなって鳴く。

日中はこれがずっと続いている。
猫は寒い所が苦手とはなんだったのか。
なぜ廊下より広くて暖かい部屋で遊ばないのか。
謎である。

でも開けてあげたときのそとちゃんがめちゃごきげんでかわいいのでOKです。

ドア開けてもらって機嫌良い pic.twitter.com/GlBBhdU60b
— ずみし (@uzimihsr) January 24, 2023

おわり

年があけてさらに寒くなってきたけど、そとちゃんは元気に寒い廊下を走り回っている。

ごはんもよく食べるし(カリカリも食べる)、うんちももりもり出して健康でなにより。

そとちゃんが今年も健康を維持できるように頑張りたい。

おまけ

12月のそとちゃん(2022)

Sat, 31 Dec 2022 00:00:00 +0000

こたつ

めちゃんこ寒くなってきたのでついにこたつを出した。

こたつ pic.twitter.com/deHYXBAjS3
— ずみし (@uzimihsr) December 17, 2022

そとちゃんはこたつが大好き。

ほぼ毎日中で寝ている。

普段布団なんか絶対入らないのに(被せると逃げる)、こたつには自分から器用に潜っていく。

ぬるり pic.twitter.com/9IGxBZdyfG
— ずみし (@uzimihsr) December 18, 2022

ちなみにそとちゃんがこたつにいるときに俺が後から入ると高確率で出ていってしまう。

冷たいつま先が触れるのがどうしても嫌みたい。
~~(ただ単に俺の足が臭い説もある)~~

俺がこたつ入ったのが気に入らない様子 pic.twitter.com/GEPcdQk9L0
— ずみし (@uzimihsr) December 29, 2022

それでもそとちゃんが後からくるときはこたつの上に乗ってくれるようになって、
うまいこと共存できている。

こたつの上もあったかいことに気づいた pic.twitter.com/1DjQsydKbE
— ずみし (@uzimihsr) December 28, 2022

が、欲を言えばやっぱり一緒に入りたい。
かなしい…

寝落ち

前述のとおりそとちゃんはほぼ毎日こたつの中で溶けているのだが、
日が差す時間になるとちゃんと窓際でひなたぼっこする。

超ごきげん pic.twitter.com/vHZiSXGNh8
— ずみし (@uzimihsr) December 12, 2022

問題はその後で、なぜかそとちゃんはこたつに戻れずカーテンの裾で寝落ちしてしまう。

光が多く入るように毎日カーテンの裾を上げているのだが、
ある日裾を縛るのがめんどくさくてベッドの上にそのまま放置したら気に入られてしまった。

こたつにいないと思ったら変なとこで寝てた pic.twitter.com/jQ5G1tGK1z
— ずみし (@uzimihsr) December 22, 2022

理由はよくわかんない。謎。

生地の肌触りが好きなのか…？

裾を縛ってるときはすぐこたつに戻るので、場所というよりはカーテンがよっぽど気に入った様子。

珍しいときにはまだひなたぼっこできる時間でもここで寝てることがある。

またカーテン踏んづけて寝てる pic.twitter.com/lJDLNRui70
— ずみし (@uzimihsr) December 23, 2022

よくわからない。

クリスマス

去年は手術後でクリスマスっぽいことがあまりできなかったが、
今年はそとちゃんに変身してもらった。

クリスマスねこちゃん pic.twitter.com/bPFOwb97e1
— ずみし (@uzimihsr) December 24, 2022

今回は赤いマント。
あんまり重くないし、動きも制限されないので結構気に入ったみたい。

人間のわがままに付き合ってもらったので、報酬としてごちそうを献上。

ごちそう pic.twitter.com/FjoYqyJ9Il
— ずみし (@uzimihsr) December 24, 2022

翌朝はプレゼントを開封。
去年あんまりお祝いできなかったので、今年のクリスマスプレゼントは気持ち多めになった。

🎅🎁 pic.twitter.com/I4PuPQqSSf
— ずみし (@uzimihsr) December 25, 2022

今まで持ってなかった光を追いかける系のおもちゃを手に入れたのだが、
そとちゃんはかしこい(?)ので、ライトで照らされる場所でなくライトの発光部分を直接追いかけてしまう。

ちなみにこのおもちゃの光はレーザーではない(LED)のでそれらに比べれば安全という話だが、
実際のところどうなんだろう…?

直視して良いものでは無い気がしたので、結局このおもちゃはほぼお蔵入りとなってしまった。

遊び方が違う pic.twitter.com/1vQiSt2qhc
— ずみし (@uzimihsr) December 25, 2022

こんなこともあろうかと(?)
クリスマスに関係なく 100 均で適当に買ってきたおもちゃを出したらこちらにめちゃめちゃ食いついた。

楽しく過ごせてよかった。

おわり

今年のそとちゃんは大きな病気や怪我もなく健康で何よりだった。

そとちゃん的に良い 1 年だったかはよくわからないが、俺的にはまあまあだったと思う。

大きなイベントとして引越しがあったけどすぐに慣れてくれたし、
引越しの目的でもあったひなたぼっこをたくさんしてくれたので嬉しかった。

そとちゃんは来年いよいよシニアねこ(たぶん 7 歳)になる。
まだまだうるさいくらいに元気いっぱいだけど、これからも元気に過ごせるように気をつけたい。

おまけ

11月のそとちゃん(2022)

Wed, 07 Dec 2022 00:00:00 +0000

まとめ

日課
新ベッド
えらい

日課

そとちゃんは11月もひなたぼっこを毎日がんばっていた。

くわ〜っ pic.twitter.com/aobiS002r9
— ずみし (@uzimihsr) November 7, 2022

日が入ってくる時間帯になると窓際で待機。

鳥が来ないか少しだけ見張って(最近あんまりこない)、
あとは横になって満足するまでしっかり日を浴びる。

いそがしい pic.twitter.com/oeN8RYWEKu
— ずみし (@uzimihsr) November 16, 2022

(だいたい寝落ちする)

あんまり元気じゃない日もひなたぼっこは欠かさない。
まるで仕事のよう。

機嫌悪い pic.twitter.com/e9NowqEQ0t
— ずみし (@uzimihsr) November 25, 2022

天気が悪い日も一応窓際に出勤する。

ハンモックの上で日が出るのをずっと待っていて、
そのまま晴れなかったら文句を言いながら降りてくる。

…毎日と言ったがあれは嘘だった。
早朝の運動で疲れすぎて夕方まで寝てる日もある。

今日はひなたぼっこサボって寝てた pic.twitter.com/dvWQD36L6H
— ずみし (@uzimihsr) November 4, 2022

自分のペースでがんばってほしい(?)。

新ベッド

10月後半あたりからそうなんだけどお気に入りの場所がまた増えた。

今までもあったバリバリボウルにブランケットかけただけのベッドがいい感じ。

テーブルの下に置いたらやたらと乗る。
こたつ出せアピール？

ひなたぼっこしてないときはだいたいここだし、
最近は寝る時も本棚の上よりこっちにいることが多い。

よくわかんないけど気に入ってくれてよかった。

えらい

朝昼のカリカリ完食率が上がってきた。

理由は謎だけどトッピング付与率の仕組みに気づいたか、部屋が乾燥してきてカリカリの風味が良くなった？

うまいうまい pic.twitter.com/dwdzWzXDwR
— ずみし (@uzimihsr) November 12, 2022

おかげでちゅーるごはんの機会も増えていい感じ。

マシマシ pic.twitter.com/CbD7S9AT00
— ずみし (@uzimihsr) November 15, 2022

でも毎日カリカリ完食って感じではなくて、
たまに食べ忘れてノートッピングになることもある。

プレーン猫缶 pic.twitter.com/xy1FYeo6m3
— ずみし (@uzimihsr) November 14, 2022

ちなみにそとちゃんはかしこいので絶対に美味しいところから食べる。

絶対トッピングから食べる pic.twitter.com/5LXKYrZESC
— ずみし (@uzimihsr) November 29, 2022

カリカリを一口も食べずに残したりしてた夏頃に比べると格段に良くなった。
えらい！

おわり

だんだん寒くなってきたが11月もそとちゃんはよく寝てよく食べて元気だった。

新居の断熱性能がそこそこいい感じで11月まではエアコンだけで寒さをしのいだが、
ここからもっと寒くなるはずなのでこたつの出番は近いかもしれない。

おまけ

Install kube-state-metrics, cAdvisor and Prometheus on a Kubernetes cluster

Mon, 28 Nov 2022 00:00:00 +0000

Summary

This is a working log of the installation of kube-state-metrics, cAdvisor, and Prometheus on a Kubernetes cluster.

Create a single-node Kubernetes cluster with kind
Install kube-state-metrics as a Deployment
Install cAdvisor as a DaemonSet
Install Prometheus as a Deployment and configure it to scrape these metrics

Prerequisites

kind v0.17.0 go1.19.2 darwin/arm64
kubernetes v1.25.3
kubectl v1.25.0
prometheus version 2.40.3
kube-state-metrics v2.7.0
cAdvisor v0.45.0

Logs

Create a Kubernetes cluster

Let’s go with kind.

$ kind create cluster

Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.25.3) 🖼
 ✓ Preparing nodes 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂

Install kube-state-metrics

kube-state-metrics generates the metrics of Kubernetes objects such as Nodes, Services and Pods.

You can install it using the sample manifests.

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/kube-state-metrics/master/examples/standard/service-account.yaml && \
 kubectl apply -f https://raw.githubusercontent.com/kubernetes/kube-state-metrics/master/examples/standard/cluster-role.yaml && \
 kubectl apply -f https://raw.githubusercontent.com/kubernetes/kube-state-metrics/master/examples/standard/cluster-role-binding.yaml && \
 kubectl apply -f https://raw.githubusercontent.com/kubernetes/kube-state-metrics/master/examples/standard/deployment.yaml && \
 kubectl apply -f https://raw.githubusercontent.com/kubernetes/kube-state-metrics/master/examples/standard/service.yaml

serviceaccount/kube-state-metrics created
clusterrole.rbac.authorization.k8s.io/kube-state-metrics created
clusterrolebinding.rbac.authorization.k8s.io/kube-state-metrics created
deployment.apps/kube-state-metrics created
service/kube-state-metrics created

In this case, kube-state-metrics is run as a Deployment.

Let’s port-forward to this Service and check the metrics.

$ kubectl -n kube-system get deploy,service -l app.kubernetes.io/name=kube-state-metrics

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/kube-state-metrics 1/1 1 1 115s

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kube-state-metrics ClusterIP None <none> 8080/TCP,8081/TCP 115s

$ kubectl -n kube-system port-forward service/kube-state-metrics 8080:8080 8081:8081
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080
Forwarding from 127.0.0.1:8081 -> 8081
Forwarding from [::1]:8081 -> 8081
...

# from different terminal
$ curl localhost:8080/metrics
...
# HELP kube_configmap_labels [STABLE] Kubernetes labels converted to Prometheus labels.
# TYPE kube_configmap_labels gauge
kube_configmap_labels{namespace="local-path-storage",configmap="local-path-config"} 1
kube_configmap_labels{namespace="default",configmap="kube-root-ca.crt"} 1
...

Good. It works fine.

The docs has more information about the metrics.

kube-state-metrics can also be accessed via a browser.

http://localhost:8080/

http://localhost:8081/

Install cAdvisor

cAdvisor exports the container metrics such as CPU usage, Memory usage, etc.

Kustomized manifests are available. Yes!

$ kubectl apply -k https://github.com/google/cadvisor//deploy/kubernetes/base

namespace/cadvisor created
serviceaccount/cadvisor created
daemonset.apps/cadvisor created

cAdvisor runs as a DaemonSet and collects container information from each Node.

$ kubectl -n cadvisor get daemonset -l app=cadvisor

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
cadvisor 1 1 1 1 1 <none> 6m54s

$ pod=`kubectl -n cadvisor get pod -l app=cadvisor -o jsonpath="{.items[0].metadata.name}"`
$ kubectl -n cadvisor port-forward pod/"${pod}" 8080:8080

Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080

# from different terminal
$ curl localhost:8080/metrics

# HELP cadvisor_version_info A metric with a constant '1' value labeled by kernel version, OS version, docker version, cadvisor version & cadvisor revision.
# TYPE cadvisor_version_info gauge
cadvisor_version_info{cadvisorRevision="86b11c65",cadvisorVersion="v0.45.0",dockerVersion="",kernelVersion="5.10.124-linuxkit",osVersion="Alpine Linux v3.16"} 1
# HELP container_blkio_device_usage_total Blkio Device bytes usage
# TYPE container_blkio_device_usage_total counter
container_blkio_device_usage_total{container_label_app="",container_label_app_kubernetes_io_component="",container_label_app_kubernetes_io_name="",container_label_app_kubernetes_io_version="",container_label_component="",container_label_controller_revision_hash="",container_label_description="",container_label_io_cri_containerd_kind="",container_label_io_kubernetes_container_name="",container_label_io_kubernetes_pod_name="",container_label_io_kubernetes_pod_namespace="",container_label_io_kubernetes_pod_uid="",container_label_k8s_app="",container_label_maintainers="",container_label_name="",container_label_pod_template_generation="",container_label_pod_template_hash="",container_label_tier="",device="/dev/vda",id="/",image="",major="254",minor="0",name="",operation="Read"} 0 1669642901054
...

Metrics with names like container_** are container metrics.

Of course, cAdvisor can also be accessed via a browser.

http://localhost:8080/

Install Prometheus

Next, install Prometheus to scrape these metrics.

Here is an example manifest that installs Prometheus as a Deployment.

Apply it.

$ kubectl create namespace prometheus

namespace/prometheus created

$ kubectl -n prometheus apply -f deployment.yaml

deployment.apps/prometheus created

$ kubectl -n prometheus expose deployment prometheus --port=9090 --target-port=9090

service/prometheus exposed

Make sure it is working properly.

$ kubectl -n prometheus port-forward service/prometheus 9090:9090

Forwarding from 127.0.0.1:9090 -> 9090
Forwarding from [::1]:9090 -> 9090

http://localhost:9090/

Good.

Configure Prometheus for service discovery (kubernetes_sd_config)

Finally, configure Prometheus to scrape metrics in the cluster.

kubernetes_sd_config is the key.

Follow the example and create prometheus.yml.

In this case, Prometheus scrapes only Services of kube-state-metrics and Pods of cAdvisor.
(Without this config, kube-state-metrics is scraped by both “role: service” job and “role: pod” job, then the metrics are duplicated.)

$ kubectl -n cadvisor get pods --show-labels

NAME READY STATUS RESTARTS AGE LABELS
cadvisor-fngj6 1/1 Running 0 23h app=cadvisor,controller-revision-hash=df8bf66b4,name=cadvisor,pod-template-generation=1

$ kubectl -n kube-system get service kube-state-metrics --show-labels

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE LABELS
kube-state-metrics ClusterIP None <none> 8080/TCP,8081/TCP 24h app.kubernetes.io/component=exporter,app.kubernetes.io/name=kube-state-metrics,app.kubernetes.io/version=2.7.0

$ kubectl apply -f configmap.yaml

configmap/prometheus-config created

Update the Deployment to load the config.

$ kubectl apply -f deployment.yaml

deployment.apps/prometheus configured

Open Status->Service Discovery to check operation.

http://localhost:9090/service-discovery

Oops! Service discovery has failed.

Check the Pod log…

$ pod=`kubectl -n prometheus get pods -l app=prometheus -o jsonpath="{.items[0].metadata.name}"`
$ kubectl -n prometheus logs $pod

...
ts=2022-11-28T14:26:56.150Z caller=kubernetes.go:326 level=info component="discovery manager scrape" discovery=kubernetes msg="Using pod service account via in-cluster config"
ts=2022-11-28T14:26:56.150Z caller=main.go:1234 level=info msg="Completed loading of configuration file" filename=/config/prometheus.yml totalDuration=2.798834ms db_storage=1.208µs remote_storage=1.417µs web_handler=375ns query_engine=1.042µs scrape=250.917µs scrape_sd=2.159042ms notify=1.083µs notify_sd=5.709µs rules=1.584µs tracing=12.958µs
ts=2022-11-28T14:26:56.150Z caller=main.go:978 level=info msg="Server is ready to receive web requests."
ts=2022-11-28T14:26:56.150Z caller=manager.go:944 level=info component="rule manager" msg="Starting rule manager..."
ts=2022-11-28T14:26:56.156Z caller=klog.go:108 level=warn component=k8s_client_runtime func=Warningf msg="pkg/mod/k8s.io/client-go@v0.25.3/tools/cache/reflector.go:169: failed to list *v1.Service: services is forbidden: User \"system:serviceaccount:prometheus:default\" cannot list resource \"services\" in API group \"\" at the cluster scope"
ts=2022-11-28T14:26:56.156Z caller=klog.go:108 level=warn component=k8s_client_runtime func=Warningf msg="pkg/mod/k8s.io/client-go@v0.25.3/tools/cache/reflector.go:169: failed to list *v1.Pod: pods is forbidden: User \"system:serviceaccount:prometheus:default\" cannot list resource \"pods\" in API group \"\" at the cluster scope"
ts=2022-11-28T14:26:56.156Z caller=klog.go:116 level=error component=k8s_client_runtime func=ErrorDepth msg="pkg/mod/k8s.io/client-go@v0.25.3/tools/cache/reflector.go:169: Failed to watch *v1.Service: failed to list *v1.Service: services is forbidden: User \"system:serviceaccount:prometheus:default\" cannot list resource \"services\" in API group \"\" at the cluster scope"
ts=2022-11-28T14:26:56.156Z caller=klog.go:108 level=warn component=k8s_client_runtime func=Warningf msg="pkg/mod/k8s.io/client-go@v0.25.3/tools/cache/reflector.go:169: failed to list *v1.Endpoints: endpoints is forbidden: User \"system:serviceaccount:prometheus:default\" cannot list resource \"endpoints\" in API group \"\" at the cluster scope"
ts=2022-11-28T14:26:56.156Z caller=klog.go:116 level=error component=k8s_client_runtime func=ErrorDepth msg="pkg/mod/k8s.io/client-go@v0.25.3/tools/cache/reflector.go:169: Failed to watch *v1.Endpoints: failed to list *v1.Endpoints: endpoints is forbidden: User \"system:serviceaccount:prometheus:default\" cannot list resource \"endpoints\" in API group \"\" at the cluster scope"
...

According to the log, Prometheus is failing to get information of Pods, Services and Endpoints because the default ServiceAccount is not authorized.

Then create ServiceAccount, ClusterRole and ClusterRoleBinding to gave permission.

$ kubectl -n prometheus create serviceaccount prometheus

serviceaccount/prometheus created

$ kubectl create clusterrole prometheus --verb=get,list,watch --resource=pods,services,endpoints

clusterrole.rbac.authorization.k8s.io/prometheus created

$ kubectl create clusterrolebinding prometheus --clusterrole=prometheus --serviceaccount=prometheus:prometheus

clusterrolebinding.rbac.authorization.k8s.io/prometheus created

Update the Deployment again.

$ kubectl apply -f deployment.yaml

deployment.apps/prometheus configured

This time it succeeded. Wow!

The metrics are correctly scraped.

That is all.

Kubernetesクラスタにkube-state-metricsとcAdvisorをぶちこんでPrometheusで監視する

Mon, 28 Nov 2022 00:00:00 +0000

やったことのまとめ

自分は普段すでに監視用アドオンが入った状態のマネージドKubernetesクラスタを使うのが当たり前になっている。
それがどんなにありがたいことか分かってない気がしたのと、
単純にそれらの構成がどうなっているのか興味があったので実際に手を動かして設定してみた。

お試し用にkindでKubernetesクラスタ作成
kube-state-metrics(Deployment)でKubernetesメトリクスを収集
cAdvisor(DaemonSet)でコンテナメトリクスを収集
Prometheus(Deployment)にService Discovery設定をして上記2種のメトリクスをモニタリング

つかうもの

kind v0.17.0 go1.19.2 darwin/arm64
kubernetes v1.25.3
kubectl v1.25.0
prometheus version 2.40.3
kube-state-metrics v2.7.0
cAdvisor v0.45.0

やったこと

Kubernetesクラスタの作成

今回は特に構成にこだわりもないので適当にkindでシングルノードのKubernetesクラスタをつくる。

$ kind create cluster

Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.25.3) 🖼
 ✓ Preparing nodes 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂

kube-state-metricsのインストール

Kubernetesリソース(Podとか)のメトリクスといったらkube-state-metricsって感じなのでまずはこいつを入れていく。

サンプルマニフェストが公開されているのでそれを使ってみる。

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/kube-state-metrics/master/examples/standard/service-account.yaml && \
 kubectl apply -f https://raw.githubusercontent.com/kubernetes/kube-state-metrics/master/examples/standard/cluster-role.yaml && \
 kubectl apply -f https://raw.githubusercontent.com/kubernetes/kube-state-metrics/master/examples/standard/cluster-role-binding.yaml && \
 kubectl apply -f https://raw.githubusercontent.com/kubernetes/kube-state-metrics/master/examples/standard/deployment.yaml && \
 kubectl apply -f https://raw.githubusercontent.com/kubernetes/kube-state-metrics/master/examples/standard/service.yaml

serviceaccount/kube-state-metrics created
clusterrole.rbac.authorization.k8s.io/kube-state-metrics created
clusterrolebinding.rbac.authorization.k8s.io/kube-state-metrics created
deployment.apps/kube-state-metrics created
service/kube-state-metrics created

この手順でマニフェストをapplyするとkube-state-metricsがDeploymentとして動作する。
Serviceも一緒に作られているのでport-forwardしてメトリクスを見てみる。

$ kubectl -n kube-system get deploy,service -l app.kubernetes.io/name=kube-state-metrics

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/kube-state-metrics 1/1 1 1 115s

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kube-state-metrics ClusterIP None <none> 8080/TCP,8081/TCP 115s

$ kubectl -n kube-system port-forward service/kube-state-metrics 8080:8080 8081:8081
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080
Forwarding from 127.0.0.1:8081 -> 8081
Forwarding from [::1]:8081 -> 8081
...

# from different terminal
$ curl localhost:8080/metrics
...
# HELP kube_configmap_labels [STABLE] Kubernetes labels converted to Prometheus labels.
# TYPE kube_configmap_labels gauge
kube_configmap_labels{namespace="local-path-storage",configmap="local-path-config"} 1
kube_configmap_labels{namespace="default",configmap="kube-root-ca.crt"} 1
...

こんな感じでkube-state-metricsはKubernetes APIをポーリングして得られたPodのステータスとかの情報をメトリクス化している。らしい。

ちなみにメトリクスの詳細な説明はdocsで公開されている。

実はUIも用意されているが、今回の目的ではないので割愛。

http://localhost:8080/

http://localhost:8081/

cAdvisorのインストール

cAdvisorもコンテナ単位のメトリクスが見られて便利なのでこれも入れていく。

こちらはサンプルマニフェストがkustomize化されているのでさらに簡単に入れられる。

$ kubectl apply -k https://github.com/google/cadvisor//deploy/kubernetes/base

namespace/cadvisor created
serviceaccount/cadvisor created
daemonset.apps/cadvisor created

cAdvisorは各Node上のコンテナ情報を取得するためDaemonSetとして動作している。
(昔はkubeletに勝手に入ってた気がするが、最近はDaemonSetで動かすのが普通っぽい?)

kube-state-metricsと同様にport-forwardしてメトリクスを確認する。

$ kubectl -n cadvisor get daemonset -l app=cadvisor

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
cadvisor 1 1 1 1 1 <none> 6m54s

$ pod=`kubectl -n cadvisor get pod -l app=cadvisor -o jsonpath="{.items[0].metadata.name}"`
$ kubectl -n cadvisor port-forward pod/"${pod}" 8080:8080

Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080

# from different terminal
$ curl localhost:8080/metrics

# HELP cadvisor_version_info A metric with a constant '1' value labeled by kernel version, OS version, docker version, cadvisor version & cadvisor revision.
# TYPE cadvisor_version_info gauge
cadvisor_version_info{cadvisorRevision="86b11c65",cadvisorVersion="v0.45.0",dockerVersion="",kernelVersion="5.10.124-linuxkit",osVersion="Alpine Linux v3.16"} 1
# HELP container_blkio_device_usage_total Blkio Device bytes usage
# TYPE container_blkio_device_usage_total counter
container_blkio_device_usage_total{container_label_app="",container_label_app_kubernetes_io_component="",container_label_app_kubernetes_io_name="",container_label_app_kubernetes_io_version="",container_label_component="",container_label_controller_revision_hash="",container_label_description="",container_label_io_cri_containerd_kind="",container_label_io_kubernetes_container_name="",container_label_io_kubernetes_pod_name="",container_label_io_kubernetes_pod_namespace="",container_label_io_kubernetes_pod_uid="",container_label_k8s_app="",container_label_maintainers="",container_label_name="",container_label_pod_template_generation="",container_label_pod_template_hash="",container_label_tier="",device="/dev/vda",id="/",image="",major="254",minor="0",name="",operation="Read"} 0 1669642901054
...

container_**みたいな名前のメトリクスがとれていることがわかる。

こちらも実はUIが用意されているが割愛。

http://localhost:8080/

Prometheusのインストール

Kubernetesリソースとコンテナのメトリクスが用意できたので、
次にこれをモニタリングするPrometheusを用意する。

ちょっと探したけどPrometheusについては公式っぽいKubernetesマニフェスト例が見つからなかったので自分でちょろっと書いて立ててみる。

$ kubectl create namespace prometheus

namespace/prometheus created

$ kubectl -n prometheus apply -f deployment.yaml

deployment.apps/prometheus created

$ kubectl -n prometheus expose deployment prometheus --port=9090 --target-port=9090

service/prometheus exposed

今回は特にメトリクスを永続化したいわけではなかったのでPrometheusをDeploymentとして立てた。
(メトリクスを永続化したいときはStatefulSetで立てたり、クラスタ外にFederateしたりいろいろやり方はあるとおもう)

これも同様にport-forwardしてUIを開いて動作確認する。

$ kubectl -n prometheus port-forward service/prometheus 9090:9090

Forwarding from 127.0.0.1:9090 -> 9090
Forwarding from [::1]:9090 -> 9090

http://localhost:9090/

いい感じ。

Prometheusの監視設定(kubernetes_sd_config)

最後にこのPrometheusでkube-state-metricsとcAdvisorのメトリクスが取れるように設定していく。

Kubernetesクラスタ内のメトリクスをPrometheusで監視する場合static_configにいちいちServiceやPodのIPを羅列していては日が暮れてしまうし、
それらが変化してしまったときに動的に追従させるのが大変というかたぶん無理。

このため通常はkubernetes_sd_configを使ってクラスタ内のServiceやPodの宛先をPrometheusが勝手に探すようにする(Service Discovery)。

これについては公式の例があるのでこちらを参考にさせてもらう。

今回はrelabel_configsの設定でモニタリングの対象をkube-state-metricsのServiceとcAdvisorのDaemonSet(Pod)に絞っている。
(role: podのsd設定を入れると全Podのメトリクスが対象となりrole: serviceのsd設定で対象となっているメトリクスと重複するため)

$ kubectl -n cadvisor get pods --show-labels

NAME READY STATUS RESTARTS AGE LABELS
cadvisor-fngj6 1/1 Running 0 23h app=cadvisor,controller-revision-hash=df8bf66b4,name=cadvisor,pod-template-generation=1

$ kubectl -n kube-system get service kube-state-metrics --show-labels

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE LABELS
kube-state-metrics ClusterIP None <none> 8080/TCP,8081/TCP 24h app.kubernetes.io/component=exporter,app.kubernetes.io/name=kube-state-metrics,app.kubernetes.io/version=2.7.0

$ kubectl apply -f configmap.yaml

configmap/prometheus-config created

ついでにこのConfigMapを読み込むようにDeploymentの設定も修正する。

$ kubectl apply -f deployment.yaml

deployment.apps/prometheus configured

この状態でPrometheusのService Discoveryの状態を確認する。

http://localhost:9090/service-discovery

…あれ？
なんかできてなさそう。

Podのログを確認してみる。

$ pod=`kubectl -n prometheus get pods -l app=prometheus -o jsonpath="{.items[0].metadata.name}"`
$ kubectl -n prometheus logs $pod

...
ts=2022-11-28T14:26:56.150Z caller=kubernetes.go:326 level=info component="discovery manager scrape" discovery=kubernetes msg="Using pod service account via in-cluster config"
ts=2022-11-28T14:26:56.150Z caller=main.go:1234 level=info msg="Completed loading of configuration file" filename=/config/prometheus.yml totalDuration=2.798834ms db_storage=1.208µs remote_storage=1.417µs web_handler=375ns query_engine=1.042µs scrape=250.917µs scrape_sd=2.159042ms notify=1.083µs notify_sd=5.709µs rules=1.584µs tracing=12.958µs
ts=2022-11-28T14:26:56.150Z caller=main.go:978 level=info msg="Server is ready to receive web requests."
ts=2022-11-28T14:26:56.150Z caller=manager.go:944 level=info component="rule manager" msg="Starting rule manager..."
ts=2022-11-28T14:26:56.156Z caller=klog.go:108 level=warn component=k8s_client_runtime func=Warningf msg="pkg/mod/k8s.io/client-go@v0.25.3/tools/cache/reflector.go:169: failed to list *v1.Service: services is forbidden: User \"system:serviceaccount:prometheus:default\" cannot list resource \"services\" in API group \"\" at the cluster scope"
ts=2022-11-28T14:26:56.156Z caller=klog.go:108 level=warn component=k8s_client_runtime func=Warningf msg="pkg/mod/k8s.io/client-go@v0.25.3/tools/cache/reflector.go:169: failed to list *v1.Pod: pods is forbidden: User \"system:serviceaccount:prometheus:default\" cannot list resource \"pods\" in API group \"\" at the cluster scope"
ts=2022-11-28T14:26:56.156Z caller=klog.go:116 level=error component=k8s_client_runtime func=ErrorDepth msg="pkg/mod/k8s.io/client-go@v0.25.3/tools/cache/reflector.go:169: Failed to watch *v1.Service: failed to list *v1.Service: services is forbidden: User \"system:serviceaccount:prometheus:default\" cannot list resource \"services\" in API group \"\" at the cluster scope"
ts=2022-11-28T14:26:56.156Z caller=klog.go:108 level=warn component=k8s_client_runtime func=Warningf msg="pkg/mod/k8s.io/client-go@v0.25.3/tools/cache/reflector.go:169: failed to list *v1.Endpoints: endpoints is forbidden: User \"system:serviceaccount:prometheus:default\" cannot list resource \"endpoints\" in API group \"\" at the cluster scope"
ts=2022-11-28T14:26:56.156Z caller=klog.go:116 level=error component=k8s_client_runtime func=ErrorDepth msg="pkg/mod/k8s.io/client-go@v0.25.3/tools/cache/reflector.go:169: Failed to watch *v1.Endpoints: failed to list *v1.Endpoints: endpoints is forbidden: User \"system:serviceaccount:prometheus:default\" cannot list resource \"endpoints\" in API group \"\" at the cluster scope"
...

エラーメッセージ的に"デフォルトで設定されたServiceAccount(prometheus:default)にPodとかServiceを見る権限が無いよ!“って感じなので、
ServiceAccount, ClusterRole, ClusterRoleBindingを作ってやる。

$ kubectl -n prometheus create serviceaccount prometheus

serviceaccount/prometheus created

$ kubectl create clusterrole prometheus --verb=get,list,watch --resource=pods,services,endpoints

clusterrole.rbac.authorization.k8s.io/prometheus created

$ kubectl create clusterrolebinding prometheus --clusterrole=prometheus --serviceaccount=prometheus:prometheus

clusterrolebinding.rbac.authorization.k8s.io/prometheus created

またまたDeploymentをいじって↑で権限を付与したServiceAccountを使ってPodを立てるようにする。

$ kubectl apply -f deployment.yaml

deployment.apps/prometheus configured

再度立ち上がったPrometheusを確認すると今度はService Discoveryに成功している。

試しにPrometheus自身のPod, コンテナのメトリクスをクエリで探すと確かに値が返ってくる。

ええやん。

おわり

Kubernetesクラスタにkube-state-metricsとcAdvisorを導入し、
クラスタ内のPrometheusでそれらのメトリクスをモニタリングするところまでやってみた。

今回はprometheus-operatorとか使わずに全部手作業で立てたので結構面倒だったが、
たまにこうやって遊ぶと楽しいし、こういうやつを勝手に作成してくれる仕組みのありがたさがよくわかる気がする。

おまけ

10月のそとちゃん(2022)

Wed, 09 Nov 2022 00:00:00 +0000

まとめ

毛布
トッピング
ハロウィン

毛布

ちょっと寒くなってきたので毛布を出した。

毛布出しました pic.twitter.com/KmlAMRIXk8
— ずみし (@uzimihsr) October 9, 2022

そとちゃんは毛布の上に乗るのが好き。

昼間はずっと毛布の上でごろごろしている。

ずっといる pic.twitter.com/TOvtXOUp2F
— ずみし (@uzimihsr) October 20, 2022

ひなたぼっこが気持ちよさそう。

かぁ〜っ pic.twitter.com/bvE24ZiB0C
— ずみし (@uzimihsr) October 28, 2022

以前とは違って、毛布の上で寝落ちするようになった。

たまらなくかわいい。

こんなに好きな毛布だけど、上からかぶせると嫌がる。

毛布より軽いブランケットを掛けても逃げるので、たぶん何かこだわりがある。

圧迫感があるのかな？

ブランケットの上はすき
被るのはだめ pic.twitter.com/PahXiRgWFL
— ずみし (@uzimihsr) October 21, 2022

ちなみに日が出てない日も毛布の上で転がって外を眺めている。

楽しそうでなにより。

トッピング

最近の我が家のルールとして、
朝昼のカリカリを食べた量に応じて晩ごはんのトッピングのレベルが変わる報酬制が採用されている。
(そとちゃんがあまりにもカリカリを残すので俺が勝手に制定した)

このため、カリカリをガッツリ残した日は晩ごはんの猫缶が素の状態で出てくる。

晩ごはんにトッピングが無くて固まるねこ

(今日はカリカリ爆残しなのでトッピングなし) pic.twitter.com/MjDE9UH051
— ずみし (@uzimihsr) October 12, 2022

トッピングがないと露骨に食いつきが悪くなり、目つきも悪くなる。

今日もトッピングなしです pic.twitter.com/9hMjBbSKdU
— ずみし (@uzimihsr) October 14, 2022

その代わりカリカリを半分くらい食べた日はかつお節がかかったり、
完食した日はなんとちゅーるがトッピングされる。

おいしそう。

でも次の日はまたカリカリをガッツリ残してトッピング無しに戻ることもしばしば。

たぶんまだこの因果関係を理解していない。

いつかそとちゃんがこれに気づいてカリカリを毎日完食してくれるといいなと思う。

ハロウィン

気づいたらハロウィンだったので今年もそとちゃんに仮装してもらった。

ドラキュラねこ#HappyHalloween pic.twitter.com/VvYsHk6jWW
— ずみし (@uzimihsr) October 31, 2022

例年通りドラキュラマント。

かわいい。

去年のこうもりポンチョはあんまり気に入ってくれなかったけど、
やっぱりこのマントは平気らしい。

マントつけたまま部屋の中をうろうろしたり、あまり気にならないようだった。

俺のわがままにつきあってくれたので、
もちろんごほうびをあげた。

来年もやろう…

おわり

今年もあっという間に10月が終わってしまった。

とはいえそとちゃんも俺も特に変わらず毎日平和にごろごろしている。

たのしい。

今は毛布で耐えていられるけど、本格的に寒くなったらそろそろ"アレ"の出番が来るかもしれない…

おまけ

9月のそとちゃん(2022)

Fri, 07 Oct 2022 00:00:00 +0000

まとめ

病院
お散歩
窓際族

病院

年に1回のワクチンを打つため、久しぶりに病院に行った。

キャリーにはすんなり入るそとちゃん。

お出かけします pic.twitter.com/jv2XlTOjq7
— ずみし (@uzimihsr) September 17, 2022

この日は雨だったので車移動。

キャリーケースに入れられて車の中だとあんまり外の景色が見られなくてつまらなさそうだった。

病院についてすぐに診察。

体重は4.04kg。

前回行ったときに聞き忘れたごはんの量は体重が4kgくらいをキープできてるならこのままでいいらしい。

ちょっと不安なのは歯石が気になると言われたこと。

去年歯肉炎の兆候があったときは塗り薬を処方してもらったり、
それからも毎晩できる範囲で(めっちゃ嫌がるが)歯みがきをしてきたものの、
あまり良くなってないようだった。

今の状態だと全身麻酔をして歯石のクリーニングをするしかないらしい。

全身麻酔は昨年末の手術で一度経験しているので大丈夫そうだが、
この日は去年歯を診てくれた先生と違う若手の先生で割とアグレッシブにおすすめしてきたので、
勢いで決めるのも怖いと思ってこの日は手術の申し込みをしなかった。

肝心のワクチンもしっかり打ってもらった。

前回と全く同じでおしりに体温計を入れるときに一番暴れて(体温は37.6℃)、
注射のときだけおとなしかった(なんで？)。

診察が終わってすぐ帰れると思ったらちょうど受付が混み出す時間帯にぶつかってしまい、
会計が出るまで待合室で待つことになった。

いつもそうだけど病院の待合室はキャリーに入ってない犬がいっぱいいて、
俺は犬がダメなのでかなりこわかった。

そとちゃんはやっぱり他の犬猫には興味ないみたいで、
いつも通りキャリーの中でごろごろしていた。

…というわけでもなく、この日はかなり興奮した子犬が1頭暴れ回っていて、
流石にちょっと驚いていた。

以降は特に何もなくさっさと帰宅。

病院に行くときはいつも診察室を探検して楽しそうなのに、
この日は混んでたこともあり診察が終わってすぐキャリーに入れられてしまったそとちゃん。

帰宅してからもなんか元気がなくて少しかわいそうだった。
(その後起きておやつをガッツリ食べた)

つかれた pic.twitter.com/JD1qG6EgY4
— ずみし (@uzimihsr) September 18, 2022

お散歩

せっかくのおでかけ(病院)がつまんなくてかわいそうだったのと、
なんか最近ドアの前で鳴くことが多かったので、
気分転換に家の周りを何回かお散歩してみた。

とはいえそとちゃんはハーネスをつけられると動かなくなってしまうので、
はじめは抱っこしてお散歩。

これだと数分で腕が疲れてくるし、
何より俺の両手が塞がってちょっと危ないので別の方法を考えた。

散歩した pic.twitter.com/IsV4NaWq6T
— ずみし (@uzimihsr) September 25, 2022

↑の写真のようにハーネスをつけた状態で昔使ってたリュック型のキャリーに入れ、
キャリーの窓を開けてみた。

これだと両手も使えるし、そとちゃんも楽な姿勢で外の景色を堪能できていい感じ。

散歩してみて気づいたのだが新居の周りは犬を散歩させてる人が結構いて、
ねこの散歩は珍しいようで何度か話しかけられた。

そとちゃんは人見知りしないので、
知らない人に話しかけられてもちゃんとお返事をしていい子だった。

その人が連れてる犬のことはガン無視していた。

窓際族

引越してから約1ヶ月経ち、
そとちゃんもちょっとずつ新居の良さ(?)がわかってきた様子。

特に日当たりの良い窓際がいい感じ。

ひなたぼっこ pic.twitter.com/Dw4PJ5J3Sc
— ずみし (@uzimihsr) September 21, 2022

天気の良い日は高確率で窓際にいる。

ねてる pic.twitter.com/h3Dy8BHqLC
— ずみし (@uzimihsr) September 28, 2022

西日をガッツリ浴びて楽しそう。

あとたまにベランダ(正確には向かいのお家の屋上)にカラスがくるのがアツいっぽい。

ねこの天敵だから怖がるかと思ったけど、
そとちゃんは自分が安全な所にいるのがわかっているから(?)いつも面白そうにみている。

ちなみにクラッキングはしない。

ベランダに鳥が来た pic.twitter.com/dM1QGdKhRQ
— ずみし (@uzimihsr) September 28, 2022

はじめはなかなかひなたぼっこしてくれなかったりして不安だったが、
今は毎日楽しそうなので、やっぱり引っ越してよかった。

おわり

9月はおでかけする機会が多かった。

そろそろ涼しくなってきて虫も減るし、散歩の頻度を増やしてもいいかもしれない。

歯石のクリーニングについては心配なので自分でももう少し情報を集めてから慎重に判断したいと思う。

おまけ

golang: Trust a self-signed certificate in a scratch image

Thu, 29 Sep 2022 00:00:00 +0000

Summary

To trust a self-signed certificate in a scratch image, copy the certificate at the build stage, update the trusted ca-certificates, and then copy it to the scratch image.

Prerequisites

Docker version 20.10.17, build 100c701
go version go1.18.1 darwin/arm64
nginx:1.23.1

Example

Create a self-signed certificate and run a HTTPS server on nginx

First, create a self-signed certificate.
There are many ways to do this, but I prefer to do it with openssl in Docker.

$ docker container run --rm -it -v="$PWD:/workdir" -w="/workdir" --entrypoint=/bin/bash nginx:1.23.1

root@e08bb1ebe3da:/workdir# openssl version
OpenSSL 1.1.1n 15 Mar 2022

root@e08bb1ebe3da:/workdir# openssl genpkey -algorithm RSA -out server-private-key.pem
...................+++++
......................................................................................................+++++

root@e08bb1ebe3da:/workdir# openssl req -x509 -key server-private-key.pem -out server-cert.pem -addext 'subjectAltName = DNS:hogehoge.uzimihsr.com'
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:hogehoge.uzimihsr.com
Email Address []:

root@e08bb1ebe3da:/workdir#
exit

# the private key and the self-signed certificates are created on the host
$ ls
server-cert.pem		server-private-key.pem

Then start a HTTPS server on nginx.

$ tree .
.
├── docker-compose.yaml
├── https.conf
├── server-cert.pem
└── server-private-key.pem

0 directories, 4 files

$ docker compose up -d

$ docker compose ps
NAME COMMAND SERVICE STATUS PORTS
hogehoge.uzimihsr.com "/docker-entrypoint.…" nginx running 80/tcp, 0.0.0.0:443->443/tcp

$ curl -I https://hogehoge.uzimihsr.com --cacert ./server-cert.pem --resolve "hogehoge.uzimihsr.com:443:127.0.0.1"
HTTP/1.1 200 OK
...

Create an application that sends HTTP requests in Go

Next, create a simple HTTP status checker in Go.

$ go run main.go https://example.com
2022/09/28 23:45:32 target: https://example.com, insecure: false
2022/09/28 23:45:33 status: 200 OK

Build and run this application with Docker.

Oops! The http-status-checker container failed due to the certificate error.😭

$ tree .
.
├── Dockerfile
├── docker-compose.yaml
├── go.mod
├── https.conf
├── main.go
├── server-cert.pem
└── server-private-key.pem

0 directories, 7 files

$ cat go.mod
module http-status-checker

go 1.18

$ docker compose up -d

$ docker compose ps
NAME COMMAND SERVICE STATUS PORTS
hogehoge.uzimihsr.com "/docker-entrypoint.…" nginx running 80/tcp, 0.0.0.0:443->443/tcp
http-status-checker "./app https://hogeh…" http-status-checker exited (1)

$ docker compose logs http-status-checker
http-status-checker | 2022/09/28 12:17:41 target: https://hogehoge.uzimihsr.com/, insecure: false
http-status-checker | 2022/09/28 12:17:41 [ERROR] HTTP(S) request failed: Get "https://hogehoge.uzimihsr.com/": x509: certificate signed by unknown authority

Trust the certificate in a scratch image

To avoid the certificate error, the self-signed certificate should be trusted in a scratch image.
(Of course, it is possible to set tls.Config.InsecureSkipVerify as a workaround, but I have tried to trust the self-signed certificate.)

Since the golang image is Debian-based, the list of CA certificates can be updated with the update-ca-certificates command.

The Dockerfile is rewrited as follows.

The following operations are added: copy the certificate we want to trust with .crt extension and run the update-ca-certificates command.
This allows /etc/ssl/certs/ca-certificates.crt in the build stage to trust the specified certificate.

COPY server-cert.pem /usr/local/share/ca-certificates/server-cert.crt
RUN update-ca-certificates

Finally, rebuild and restart the container.
This time it worked fine with no certificate errors.🎉

$ docker compose up -d --remove-orphans --build

$ docker compose ps
NAME COMMAND SERVICE STATUS PORTS
hogehoge.uzimihsr.com "/docker-entrypoint.…" nginx running 80/tcp, 0.0.0.0:443->443/tcp
http-status-checker "./app https://hogeh…" http-status-checker exited (0)

$ docker compose logs http-status-checker
http-status-checker | 2022/09/28 13:44:43 target: https://hogehoge.uzimihsr.com/, insecure: false
http-status-checker | 2022/09/28 13:44:43 status: 200 OK

scratchイメージ上のGoで任意の証明書を信頼する

Thu, 29 Sep 2022 00:00:00 +0000

まとめ

マルチステージビルドで実行用のバイナリをscratchに載せる場合、
ビルドと同じタイミングで信頼したい証明書を用意して、
CA証明書のリストを更新したものをアプリと一緒にコピーすればよさそう。

環境

Docker version 20.10.17, build 100c701
go version go1.18.1 darwin/arm64
nginx:1.23.1

やったこと

オレオレ証明書を作成してnginxをHTTPSで建てる

まずは検証用にオレオレ証明書を作成する。
opensslが使えるならどんなやり方でもいいが、自分はDocker上で作ってホストに持ってくるのがすき。

# ホストOSのボリュームをマウントする
$ docker container run --rm -it -v="$PWD:/workdir" -w="/workdir" --entrypoint=/bin/bash nginx:1.23.1

root@e08bb1ebe3da:/workdir# openssl version
OpenSSL 1.1.1n 15 Mar 2022

# 秘密鍵の作成
root@e08bb1ebe3da:/workdir# openssl genpkey -algorithm RSA -out server-private-key.pem
...................+++++
......................................................................................................+++++

# オレオレ証明書の作成
root@e08bb1ebe3da:/workdir# openssl req -x509 -key server-private-key.pem -out server-cert.pem -addext 'subjectAltName = DNS:hogehoge.uzimihsr.com'
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:hogehoge.uzimihsr.com
Email Address []:

root@e08bb1ebe3da:/workdir#
exit

# ホスト上に鍵と証明書が置かれている
$ ls
server-cert.pem		server-private-key.pem

作成した秘密鍵とオレオレ証明書を使ってnginxをHTTPSで立ててみる。

# ディレクトリの状態
$ tree .
.
├── docker-compose.yaml
├── https.conf
├── server-cert.pem
└── server-private-key.pem

0 directories, 4 files

# nginxを起動
$ docker compose up -d

$ docker compose ps
NAME COMMAND SERVICE STATUS PORTS
hogehoge.uzimihsr.com "/docker-entrypoint.…" nginx running 80/tcp, 0.0.0.0:443->443/tcp

# CA証明書を指定して叩くとHTTPSで通信できている
$ curl -I https://hogehoge.uzimihsr.com --cacert ./server-cert.pem --resolve "hogehoge.uzimihsr.com:443:127.0.0.1"
HTTP/1.1 200 OK
...

HTTPリクエストを送るGoアプリの作成

先ほど立てたnginx(HTTPS)に対してHTTPリクエストを送る簡単なアプリを実装する。

内容としては引数で指定されたURLに対してHTTP GETしてそのステータスコードを表示する(200系以外は異常終了する)だけのもの。

$ go run main.go https://example.com
2022/09/28 23:45:32 target: https://example.com, insecure: false
2022/09/28 23:45:33 status: 200 OK

これをマルチステージビルドでscratchに乗せて動かしてみる。

起動したコンテナを確認すると、オレオレ証明書を信頼できずにエラーとなっている。

$ tree .
.
├── Dockerfile
├── docker-compose.yaml
├── go.mod
├── https.conf
├── main.go
├── server-cert.pem
└── server-private-key.pem

0 directories, 7 files

$ cat go.mod
module http-status-checker

go 1.18

$ docker compose up -d

$ docker compose ps
NAME COMMAND SERVICE STATUS PORTS
hogehoge.uzimihsr.com "/docker-entrypoint.…" nginx running 80/tcp, 0.0.0.0:443->443/tcp
http-status-checker "./app https://hogeh…" http-status-checker exited (1)

$ docker compose logs http-status-checker
http-status-checker | 2022/09/28 12:17:41 target: https://hogehoge.uzimihsr.com/, insecure: false
http-status-checker | 2022/09/28 12:17:41 [ERROR] HTTP(S) request failed: Get "https://hogehoge.uzimihsr.com/": x509: certificate signed by unknown authority

オレオレ証明書を信頼する

こんなとき、実装にもあるようにtls.Config.InsecureSkipVerifyを指定することで証明書エラーを回避することは可能だが、
どうしてもオレオレ証明書を信頼する設定で動かしたくなった。

どうしたものかと悩んだが、単純にupdate-ca-certificatesで信頼した証明書をコピーする方法に落ち着いた。

Dockerfileの設定を次のように書き換える。

変更点は次の部分。
信頼したい証明書を/usr/local/share/ca-certificates/配下に.crtという名前でコピーして、update-ca-certificatesを実行している。
これにより、ビルド用コンテナ内の/etc/ssl/certs/ca-certificates.crtが更新されて対象の証明書を信頼できるようになる。

COPY server-cert.pem /usr/local/share/ca-certificates/server-cert.crt
RUN update-ca-certificates

再度実行してみると、今度はオレオレ証明書が信頼できていてエラーが発生しなくなった。

$ docker compose up -d --remove-orphans --build

$ docker compose ps
NAME COMMAND SERVICE STATUS PORTS
hogehoge.uzimihsr.com "/docker-entrypoint.…" nginx running 80/tcp, 0.0.0.0:443->443/tcp
http-status-checker "./app https://hogeh…" http-status-checker exited (0)

$ docker compose logs http-status-checker
http-status-checker | 2022/09/28 13:44:43 target: https://hogehoge.uzimihsr.com/, insecure: false
http-status-checker | 2022/09/28 13:44:43 status: 200 OK

今回はgolangのimageがdebian系だったのでこの手順で試したが、
Red Hat系なら同様に.crtファイルを/usr/share/pki/ca-trust-source/anchors/配下にコピーして、
update-ca-trustすると/etc/pki/tls/certs/ca-bundle.crtが更新されたはず。(試してない)

おわり

久しぶりにGo+scratchでimageを作ったときに詰まったのでおさらいした。
こんなことしてる暇があったらdistrolessに移行しろと言われればそれはそう…

おまけ

8月のそとちゃん(2022)

Wed, 07 Sep 2022 00:00:00 +0000

まとめ

引越し
ひなたぼっこ
袋

引越し

色々あってまた家を引っ越すことになった。

今回も荷造りを~~邪魔する~~手伝うそとちゃん。

布団袋(かなりでかい)に興味津々。

段ボールの調査も抜かりない。

新居到着後は早速探検。
そとちゃんは新しい場所が大好きなので速攻で慣れてくれて助かった。
~~というかむしろ大興奮で暴れまわり荷解きをめちゃくちゃ邪魔した~~

ひなたぼっこ

今回引越しを決断した一番の理由は前の家の日当たりの悪さだった。

全く日が入らないわけではないが日照時間が極端に短いので、
前の家では抱っこ状態で外に出して陽に当てていた。

それだと昼に毎回抱っこして外まで行くのが面倒だったのと、
やっぱり自分のタイミングで好きなようにひなたぼっこさせてあげたいと思い引越しを決断。
(そとちゃん的に抱っこは好きでも嫌いでもなさそうだが)

新居の日当たりはそこそこ良く、
昼間は部屋の中にしっかり陽が入ってくる。

…のだが、引越して数日間はそとちゃんがなかなか自分から陽に当たらず…
この2年弱の間抱っこされてひなたぼっこするのが当たり前になっていて、
自分でひなたぼっこすることを忘れてしまっていたのかも？

せっかく引越したのにこれじゃあんまりなので、
陽が入るたびにそとちゃんを窓際に運ぶのを数日繰り返したところ(低頻度だが)自分でもひなたぼっこしてくれるようになった。

とはいえ陽に当たり過ぎても良くないと思うので、適度に楽しんでもらいたい。

袋

やっぱり袋が好き。

袋 pic.twitter.com/ArcBAlCQ8W
— ずみし (@uzimihsr) August 22, 2022

最近は特にニトリの大きいサイズのレジ袋に入って暴れるのが好き。

袋の中で動く→カサカサ音がする→獲物と勘違いして追っかけ回す→カサカサ音がするをひたすら繰り返す。

あとは王道(そとちゃん基準)だけど袋の中に投げ入れたおもちゃをひたすら外からしばくのも楽しいらしい。

引越し後にニトリで買うものがちょいちょいあったので、さらに新しい袋が補給された。
これで当分は耐えられそう。

おわり

2度目の引越しを終えて、やっぱりそとちゃんは環境の変化に強いなと感じた。
本当はストレスになっているのかもしれないが、
病院に行った時の様子とかを見ると肝が据わっているというか単純に普段と違う場所に行くのが好きなんだと思う。

何はともあれ無事に引っ越しできてよかった。

おまけ

7月のそとちゃん(2022)

Sat, 06 Aug 2022 00:00:00 +0000

まとめ

ごろごろ
お風呂
カリカリ

ごろごろ

いつものことなんだけどそとちゃんはよくごろごろしている。

転がってる pic.twitter.com/PFpU1soXb8
— ずみし (@uzimihsr) July 4, 2022

遊び疲れてごろごろするときもあるけど、
なにもなくただ床に落ちていることが多い。

落ちてる pic.twitter.com/vTzBUMGNGY
— ずみし (@uzimihsr) July 12, 2022

あとはなんとなく左側を下にして落ちてる傾向がある気がする。

落ちてる時におなかを突っつくとよく転がって面白い。

踊ってる pic.twitter.com/GiUotnoYNF
— ずみし (@uzimihsr) July 28, 2022

たまに椅子の下とかドアの前で転がってて危ないのでやめてほしい。😅

椅子を動かせなくする技 pic.twitter.com/sBhW26qLrT
— ずみし (@uzimihsr) July 21, 2022

お風呂

流石に抜け毛が多くなってきたので、約1年ぶりのお風呂に入ってもらった。🛁

前回はシャワーだけだったけど、
今回はしっかり洗って抜け毛を流すためにお風呂(バスタブ)に挑戦。

シャワーは耐えられるそとちゃんでもバスタブにはかなりビビっていた。
顔の近くにお湯があるのが怖いみたいで、若干パニックになっていてかわいそうだった。
(が、シャンプーのためにちゃんと濡らした😂)

脱走を繰り返しながらもバスタブでしっかり毛を濡らして、ようやくシャンプー。
みゃおみゃお文句言いながらもなんとか耐えてくれた。えらい。

最後にもう1回お風呂に浸かってしっかり抜け毛を流してもらった。
そとちゃんの「もう終わりだと思ってたのに…なんでや…」みたいな顔がかわいそうだけど面白くてちょっと笑ってしまった。

あとは乾かして今度こそお風呂は終わり。
ここまでされても噛んだり引っ掻いたり「シャーッ」とか言わないのでそとちゃんは本当に優しい。

大変な思いをしてかわいそうだったけど、
毛はフワッフワになったし毛玉も吐かなくなったので良かった。

カリカリ

そとちゃんがカリカリをちょっとだけ食べるようになった。

(ちょっとかわいそうだけど)猫缶をあげるときのトッピングとか夜のおやつを少なめにしたら、
流石にお腹が空いたみたいで次の日から朝と昼のカリカリを渋々食べてくれた。

まだ完食とまではいかないけど、全然食べなかった時期に比べるとだいぶ進歩した。
完食したらもっとえらい…

おわり

7月のそとちゃんは水責めに遭ったりおやつを減らされたりで散々だった。

それでいじけることもあるけど、おしりを叩いたり撫でたりすればすぐごきげんになってしまうので助かる。
単純でかわいい。えらい。

おまけ

6月のそとちゃん(2022)

Fri, 22 Jul 2022 00:00:00 +0000

まとめ

またたび
キャリーケース
吐く
カリカリ食べない

またたび

新しいおもちゃを買った。

CAT CHAP ペンタゴン

そとちゃんは結構気に入ってくれたみたいでゴロゴロ転がして遊んでくれた。

せっかくなので動画を撮ってみた。

以前から俺がヤベーと思っていたそとちゃんのまたたびのキメ方をようやく映像に残すことができた。🌿

動画にも映ってるが実は転がして遊ぶのは本当に最初だけで、
一度動きを止めるコツを掴んだらあとは押さえてひたすら舐めてヤバい成分を摂取し続ける。

またたびジャンキーのそとちゃんは耐性がついてしまっているようで、
10分程度キメ続けてようやくトリップ。🥴

最後は謎のうねうね踊り(かわいい)を見せてから数十秒で寝落ちしてしまった。

満足してくれたようでよかった。

キャリーケース

ちょっと前まで地震が多かったのもあって、
万が一に備えて大きめのキャリーケースを買ってみた。

キャンピングキャリー折りたたみ

梱包を開ける前からそとちゃんは興味津々で、
廊下に置いたらすぐに入ってくれた。

実物を見ずに通販で買ったので大きさが不安だったが、
4kgくらいのそとちゃんには十分だった。

両サイドの扉が取り外しできたのでいい感じのお部屋になり、
居間が暑い日なんかはよくここで涼んでいる。

つかれた pic.twitter.com/qWwPk5p4F3
— ずみし (@uzimihsr) June 4, 2022

ちなみにダンボールトンネル(ぼろぼろ)と組み合わせて一気に走り抜けるのが流行っている。

吐く

6月はなんかめっちゃ吐いた。

吐いた pic.twitter.com/KUyEWnres8
— ずみし (@uzimihsr) June 10, 2022

吐いた pic.twitter.com/UyW8EwZjzL
— ずみし (@uzimihsr) June 19, 2022

今までは2,3ヶ月に1回吐くか吐かないかだったのに、
6月は結構なペースで(3回くらい)吐いてしまった。

今月はおやつのにぼしをなぜか焦って飲み込んですぐにオエって吐き出したのと、
ブラッシングの後にめちゃ毛繕いして毛玉を吐いたのが数回。

前者はゆっくり食べれば防げるので今後あげるときに気をつけたい。
毛玉の方はブラッシングを頑張って抜け毛を減らすしかないが、
そとちゃんはブラシ嫌い(週に1回30分が限界)な上にブラシするとめちゃめちゃ毛繕いするのでどうしようもない…

カリカリ食べない

そとちゃんがまたカリカリを残すようになってしまった。😭

この状況で「わたしはごはんをもらえていません」みたいな顔しないでほしい

(このあと猫缶をあげました) pic.twitter.com/foZzpmEMeJ
— ずみし (@uzimihsr) June 20, 2022

おそらく湿気が高い日に食べたカリカリが若干傷んでいて、
それが美味しくなかったからそれ以降全然食べなくなってしまったのだと思う。

自動給餌器の中に乾燥剤を取り付けて湿気対策はしたものの、
そこから出たカリカリをそとちゃんが食べずに放置するとそれがまた湿気ってさらに食べない…という負のループに😭😭😭

特に湿気がひどい日には自動給餌器を使わずに手でカリカリをあげるんだけど、
それでも一度不味いと判断したものはなかなか食べてくれない。

過去にカリカリを食べなかった時期とは違って、
俺が部屋にいない時ですら食べないので本当に困ってしまった。

食欲出すためにおやつをトッピングするとそこだけ舐め取ってしまうし、
万策尽きた…
どうすりゃいいんだ…😭

おわり

なんか色々忙しくて書くのがバチクソ遅くなってしまった。

来月こそは溜めずにすぐ書きたい。

おまけ

5月のそとちゃん(2022)

Tue, 14 Jun 2022 00:00:00 +0000

まとめ

6さい
記念写真

6さい

そとちゃんがたぶん6さいになった。🎉

去年は奮発して買ったねこ用ケーキをめちゃくちゃ残したので、
今年はかなり小さめのタルトでお祝いした。

たぶん6さいになりました🎂 pic.twitter.com/oyBvP8ogSW
— ずみし (@uzimihsr) May 1, 2022

今年は表面のクリームをちょっとだけ舐めて、あとは一度も手をつけなかった。😭

仕方がないのでトッピングマシマシの特製ごはんでお祝い。

こちらはものすごい勢いで完食。
やっぱり甘いものよりしょっぱいものの方がいいみたい。

ちゅーるマシマシごはん pic.twitter.com/GLChnmvNyx
— ずみし (@uzimihsr) May 1, 2022

誕生日プレゼントは動くえびのおもちゃ。
結構おもしろそうだが…?

残念😭😭😭

でもそとちゃんがちょっとだけ嬉しそうだったのでヨシ！

満足 pic.twitter.com/36VmfBEVqk
— ずみし (@uzimihsr) May 1, 2022

記念写真

今年も去年と同じ写真屋さんに記念写真を撮りに行った。📷

そとちゃんは今年も全然おとなしくできなかった。😂

隣のスタジオ(部屋は繋がっている)で撮ってた人が気になってしまい、
ずっと目で追いかけていた。

入っちゃいけないところを探検したりなかなかカメラの方を向いてくれなかったりで撮影は本当に大変だった。

気が済むまで遊ばせたりしてなんとか最低限の枚数は撮れたが、
今度は疲れて集中力が無くなってしまったのでそれ以上はあまり撮れなかった。

俺とカメラマンさんは大変な思いをしたけどそとちゃんは楽しめたみたいなのでよかった(?)。
また来年も撮りに行きたい。

おわり

そとちゃんと暮らし始めてからもう3年経つことに驚いた。
あっという間だった。

初めて会った時から割と懐いてくれてたけど、
この3年でさらに仲良くなれたように思う。
(ちなみに一緒にベッドで寝たのは数回しかない。~~ガードが固い~~)

ついでにふてぶてしさが日に日に増している気がするが、
ねこは幸せになるほどそうなっていくものだと信じたい…

おまけ

Setting up my MacBook Pro(2021) (brew+zsh+iterm2)

Sun, 15 May 2022 00:00:00 +0000

日本語/Japanese

Summary

This is a note on setting up the terminal on my new MacBook.

Prerequisites

MacBook Pro 16-inch 2021
- macOS Monterey 12.2.1

Details

Install Homebrew
Install zsh plugins
Configure PROMPT
Install iterm2

Install Homebrew

Since Catalina, the default login shell for Mac is zsh.

uzimihsr@MacBook ~ % echo $SHELL
/bin/zsh
uzimihsr@MacBook ~ % zsh --version
zsh 5.8 (x86_64-apple-darwin21.0)

At first, install Homebrew.

Open https://brew.sh and copy and paste the command in the terminal.

uzimihsr@MacBook ~ % /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

...

Warning: /opt/homebrew/bin is not in your PATH.
 Instructions on how to configure your shell for Homebrew
 can be found in the 'Next steps' section below.
==> Installation successful!

...

==> Next steps:
- Run these two commands in your terminal to add Homebrew to your PATH:
 echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/uzimihsr/.zprofile
 eval "$(/opt/homebrew/bin/brew shellenv)"
- Run brew help to get started
- Further documentation:
 https://docs.brew.sh

Follow the instructions to update the PATH.

uzimihsr@MacBook ~ % echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/$USER/.zprofile
uzimihsr@MacBook ~ % eval "$(/opt/homebrew/bin/brew shellenv)"
uzimihsr@MacBook ~ % brew doctor
Your system is ready to brew.
uzimihsr@MacBook ~ % which brew
/opt/homebrew/bin/brew
uzimihsr@MacBook ~ % brew --version
Homebrew 3.4.10
Homebrew/homebrew-core (git revision 239cad746ef; last commit 2022-05-03)

Good.
Now I can use the brew command.

Install zsh plugins

Next, install the following zsh plugins with brew.

uzimihsr@MacBook ~ % brew install zsh-autosuggestions
...
==> Caveats
To activate the autosuggestions, add the following at the end of your .zshrc:

 source /opt/homebrew/share/zsh-autosuggestions/zsh-autosuggestions.zsh

You will also need to restart your terminal for this change to take effect.
...

uzimihsr@MacBook ~ % brew install zsh-completions
...
==> Caveats
To activate these completions, add the following to your .zshrc:

 if type brew &>/dev/null; then
 FPATH=$(brew --prefix)/share/zsh-completions:$FPATH

 autoload -Uz compinit
 compinit
 fi

You may also need to force rebuild `zcompdump`:

 rm -f ~/.zcompdump; compinit

Additionally, if you receive "zsh compinit: insecure directories" warnings when attempting
to load these completions, you may need to run this:

 chmod -R go-w '/opt/homebrew/share/zsh'
...

uzimihsr@MacBook ~ % brew install zsh-syntax-highlighting
...
==> Caveats
To activate the syntax highlighting, add the following at the end of your .zshrc:
 source /opt/homebrew/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh

If you receive "highlighters directory not found" error message,
you may need to add the following to your .zshenv:
 export ZSH_HIGHLIGHT_HIGHLIGHTERS_DIR=/opt/homebrew/share/zsh-syntax-highlighting/highlighters
...

Follow the instructions to create ~/.zshrc, then restart the terminal.

uzimihsr@MacBook ~ % cat ~/.zshrc 
# zsh-autosuggestions
source /opt/homebrew/share/zsh-autosuggestions/zsh-autosuggestions.zsh

# zsh-completions
if type brew &>/dev/null; then
 FPATH=$(brew --prefix)/share/zsh-completions:$FPATH

 autoload -Uz compinit
 compinit
fi

# zsh-syntax-highlighting
source /opt/homebrew/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh

Follow the instructions on zsh-completions to rebuild zcompdump.

The “zsh compinit: insecure directories” error did not go away with the command as instructed, so I was a bit worn out.

uzimihsr@MacBook ~ % rm -f ~/.zcompdump; compinit
zsh compinit: insecure directories, run compaudit for list.
Ignore insecure directories and continue [y] or abort compinit [n]? y
uzimihsr@MacBook ~ % chmod -R go-w '/opt/homebrew/share/zsh'
uzimihsr@MacBook ~ % rm -f ~/.zcompdump; compinit
zsh compinit: insecure directories, run compaudit for list.
Ignore insecure directories and continue [y] or abort compinit [n]? y

uzimihsr@MacBook ~ % compaudit 
There are insecure directories:
/opt/homebrew/share
uzimihsr@MacBook ~ % chmod -R go-w '/opt/homebrew/share' 
uzimihsr@MacBook ~ % rm -f ~/.zcompdump; compinit

Restart the terminal again, and all plugins are enabled.

Configure PROMPT

Set up the PROMPT to be more convenient.

My PROMPT shows the current directory and a newlined $.

The Z Shell Manual has more details on the variables that can be used with the PROMPT.

uzimihsr@MacBook ~ % PROMPT=""$'\n'"%d"$'\n'"$ "

/Users/uzimihsr
$

Finally, update ~/.zshrc.

$ cat ~/.zshrc
PROMPT=""$'\n'"%d"$'\n'"$ "
...

Install iterm2

Install iterm2 with homebrew cask.

$ brew install --cask iterm2
==> Tapping homebrew/cask
Cloning into '/opt/homebrew/Library/Taps/homebrew/homebrew-cask'...
remote: Enumerating objects: 635835, done.
remote: Counting objects: 100% (9/9), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 635835 (delta 4), reused 9 (delta 4), pack-reused 635826
Receiving objects: 100% (635835/635835), 299.65 MiB | 4.39 MiB/s, done.
Resolving deltas: 100% (450073/450073), done.
Tapped 3994 casks (4,066 files, 320.0MB).
==> Downloading https://iterm2.com/downloads/stable/iTerm2-3_4_15.zip
######################################################################## 100.0%
==> Installing Cask iterm2
==> Moving App 'iTerm.app' to '/Applications/iTerm.app'
🍺 iterm2 was successfully installed!

I like to double-tap Control(⌃) to show and hide the terminal with Hotkeys.

Open “Preference(⌘,)"→“Keys”→“Hotkey”→“Create a Dedicated Hotkey window…”.

Set up the Hotkey window as shown in the images below.

In addition, go to “Advanced”→“Open a new window when you click the dock icon…” and specify “No” to prevent opening a new terminal window except with a hotkey.

Restart iterm2 and hit Control(⌃) repeatedly and the terminal will flap open and close.

(The following is the same content in Japanese.)

まとめ

MacBookを買い換えたので、ターミナル周りの設定をした。
あんまりやる機会もないけど一応自分用にログを残しておく。

環境

MacBook Pro 16-inch 2021
- macOS Monterey 12.2.1

やったこと

Homebrewのインストール
zshプラグインのインストール
プロンプトをいじる
iterm2のインストール

Homebrewのインストール

新しいMacが起動したのでまずはシェルをzshに…
と思ったらだいぶ前(Catalina?)からデフォルトでシェルがzshになっていたらしい。

uzimihsr@MacBook ~ % echo $SHELL
/bin/zsh
uzimihsr@MacBook ~ % zsh --version
zsh 5.8 (x86_64-apple-darwin21.0)

zshのプラグインを入れたいし、後でいろんなものを入れるのに使うのでまずはbrewが使えるようにする。

ターミナルを開き、https://brew.shからコマンドをコピーしてきて貼り付け。

uzimihsr@MacBook ~ % /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

...

Warning: /opt/homebrew/bin is not in your PATH.
 Instructions on how to configure your shell for Homebrew
 can be found in the 'Next steps' section below.
==> Installation successful!

...

==> Next steps:
- Run these two commands in your terminal to add Homebrew to your PATH:
 echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/uzimihsr/.zprofile
 eval "$(/opt/homebrew/bin/brew shellenv)"
- Run brew help to get started
- Further documentation:
 https://docs.brew.sh

途中でPATHを通せ的な指示があったのでそれに従い、動作を確認する。

uzimihsr@MacBook ~ % echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/$USER/.zprofile
uzimihsr@MacBook ~ % eval "$(/opt/homebrew/bin/brew shellenv)"
uzimihsr@MacBook ~ % brew doctor
Your system is ready to brew.
uzimihsr@MacBook ~ % which brew
/opt/homebrew/bin/brew
uzimihsr@MacBook ~ % brew --version
Homebrew 3.4.10
Homebrew/homebrew-core (git revision 239cad746ef; last commit 2022-05-03)

これでbrewが使えるようになった。

zshプラグインのインストール

zshを快適に使うために下記のプラグインをbrewで入れる。

uzimihsr@MacBook ~ % brew install zsh-autosuggestions
...
==> Caveats
To activate the autosuggestions, add the following at the end of your .zshrc:

 source /opt/homebrew/share/zsh-autosuggestions/zsh-autosuggestions.zsh

You will also need to restart your terminal for this change to take effect.
...

uzimihsr@MacBook ~ % brew install zsh-completions
...
==> Caveats
To activate these completions, add the following to your .zshrc:

 if type brew &>/dev/null; then
 FPATH=$(brew --prefix)/share/zsh-completions:$FPATH

 autoload -Uz compinit
 compinit
 fi

You may also need to force rebuild `zcompdump`:

 rm -f ~/.zcompdump; compinit

Additionally, if you receive "zsh compinit: insecure directories" warnings when attempting
to load these completions, you may need to run this:

 chmod -R go-w '/opt/homebrew/share/zsh'
...

uzimihsr@MacBook ~ % brew install zsh-syntax-highlighting
...
==> Caveats
To activate the syntax highlighting, add the following at the end of your .zshrc:
 source /opt/homebrew/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh

If you receive "highlighters directory not found" error message,
you may need to add the following to your .zshenv:
 export ZSH_HIGHLIGHT_HIGHLIGHTERS_DIR=/opt/homebrew/share/zsh-syntax-highlighting/highlighters
...

インストール時の指示に従い、~/.zshrcを作成する。

uzimihsr@MacBook ~ % cat ~/.zshrc 
# zsh-autosuggestions
source /opt/homebrew/share/zsh-autosuggestions/zsh-autosuggestions.zsh

# zsh-completions
if type brew &>/dev/null; then
 FPATH=$(brew --prefix)/share/zsh-completions:$FPATH

 autoload -Uz compinit
 compinit
fi

# zsh-syntax-highlighting
source /opt/homebrew/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh

ここで一旦ターミナルを閉じてから再度起動する。

zsh-completionsのインストール時に指示された通り、zcompdumpを再作成する。

指示された通りのコマンドでは"zsh compinit: insecure directories"のエラーが消えなかったのでちょっと消耗した。

uzimihsr@MacBook ~ % rm -f ~/.zcompdump; compinit
zsh compinit: insecure directories, run compaudit for list.
Ignore insecure directories and continue [y] or abort compinit [n]? y
uzimihsr@MacBook ~ % chmod -R go-w '/opt/homebrew/share/zsh'
uzimihsr@MacBook ~ % rm -f ~/.zcompdump; compinit
zsh compinit: insecure directories, run compaudit for list.
Ignore insecure directories and continue [y] or abort compinit [n]? y

uzimihsr@MacBook ~ % compaudit 
There are insecure directories:
/opt/homebrew/share
uzimihsr@MacBook ~ % chmod -R go-w '/opt/homebrew/share' 
uzimihsr@MacBook ~ % rm -f ~/.zcompdump; compinit

もう一度再起動すると今回追加したプラグインが全て有効になっている。

プロンプトをいじる

初期設定のプロンプトだと使いづらいのでここでいじっておく。

PROMPTで使える変数についてはThe Z Shell Manualが詳しい。

自分は割とシンプルなのが好きで、
直前のコマンド実行結果から改行されてカレントディレクトリが表示できていればそれでいい。

uzimihsr@MacBook ~ % PROMPT=""$'\n'"%d"$'\n'"$ "

/Users/uzimihsr
$

色々試して気に入ったものができたので、~/.zshrcに書いておく。

$ cat ~/.zshrc
PROMPT=""$'\n'"%d"$'\n'"$ "
...

iterm2のインストール

ターミナルも標準のままだと不便なので、
homebrew caskを使ってiterm2をインストールする。

$ brew install --cask iterm2
==> Tapping homebrew/cask
Cloning into '/opt/homebrew/Library/Taps/homebrew/homebrew-cask'...
remote: Enumerating objects: 635835, done.
remote: Counting objects: 100% (9/9), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 635835 (delta 4), reused 9 (delta 4), pack-reused 635826
Receiving objects: 100% (635835/635835), 299.65 MiB | 4.39 MiB/s, done.
Resolving deltas: 100% (450073/450073), done.
Tapped 3994 casks (4,066 files, 320.0MB).
==> Downloading https://iterm2.com/downloads/stable/iTerm2-3_4_15.zip
######################################################################## 100.0%
==> Installing Cask iterm2
==> Moving App 'iTerm.app' to '/Applications/iTerm.app'
🍺 iterm2 was successfully installed!

自分はCtrl(⌃)を2回叩いてターミナルを出したり消したりできるのが好きなので、
Hotkeysを参考にitermの設定をいじっていく。

Preferenceを開き、“Keys”→“Hotkey”→“Create a Dedicated Hotkey window…“と進む。

下記画像のように設定していく。

また、ターミナルを開くのはhotkeyだけにしたいので、itermの起動時に自動で新規ターミナルを開かないようにする。

“Advanced"から"Open a new window when you click the dock icon…“を"No"に変更する。

iterm2を再起動し、Ctrl(⌃)を連打するとターミナルがパカパカ開いたり閉じたりするようになる。

他にもやりたいことはあるけど、一旦ここまで。

おわり

新しく買ったMacBookでターミナルの設定をしてみた。

M1チップが出た当初はbrewとかも結構大変だったみたいだけど、
もう1年以上経っていたおかげかだいぶ設定もしやすかった。

本当はdotfilesをちゃんと定期的に管理した方が賢いと思うけど、
手作業で設定していくのも結構楽しい…

おまけ

Convert a multi line string into a single line string leaving newline characters(LF \n) with sed

Thu, 05 May 2022 00:00:00 +0000

日本語/Japanese

Summary

sed command can convert a multi line string into a single line string without deleting \n.

# a multi line string
$ cat text
aaa
bbb
ccc

# convert a multi line string into a single line
$ cat text | sed -z 's/\n//g'
aaabbbccc

# leave newline characters(\n)
$ cat text | sed -z 's/\n/\\n/g'
aaa\nbbb\nccc\n\n

Prerequisites

sed (GNU sed) 4.7
- NOTE: BSD sed has different options

Detail

I wanted to convert a multi line string into a single line string, leaving newline characters in place.

# a multi line string
$ cat text
aaa
bbb
ccc

sed -z can treat newline characters(\n) as normal characters.
Here is what I often do.

# convert a multi line string into a single line
$ cat text | sed -z 's/\n//g'
aaabbbccc

# "-z" cannot be omitted
$ cat text | sed 's/\n//g'
aaa
bbb
ccc

This time, I tried an another method because I had to leave newline characters.

$ cat text | sed -z 's/\n/\\n/g'
aaa\nbbb\nccc\n\n

Good.
It seems to be working.

(The following is the same content in Japanese.)

まとめ

こんな感じで複数行の文字列を\nを含んだまま1行にできる。

# 複数行の文字列
$ cat text
aaa
bbb
ccc

# 普通に改行文字を消す
$ cat text | sed -z 's/\n//g'
aaabbbccc

# 改行文字を\nとして表示するが改行はしない
$ cat text | sed -z 's/\n/\\n/g'
aaa\nbbb\nccc\n\n

環境

sed (GNU sed) 4.7
- Macにデフォルトで入ってるBSD版のsedだとオプションが違うので注意

詳細

複数行の文字列を改行文字(\n)を残したまま1行に変換したいことがあった。

# 複数行の文字列
$ cat text
aaa
bbb
ccc

sedの-zオプションを使うと改行文字(\n)を操作できる。
よくやるのはこんな感じ。

# 改行文字を消して1行にする
$ cat text | sed -z 's/\n//g'
aaabbbccc

# -zオプションがないと改行文字を操作できない
$ cat text | sed 's/\n//g'
aaa
bbb
ccc

今回は改行は無くしたいが改行文字(\n)は残したかったので、
次のように書いてみた。

$ cat text | sed -z 's/\n/\\n/g'
aaa\nbbb\nccc\n\n

いい感じ。

おわり

なんかJSONの値に改行文字を含むテキストの内容を入れたくなることがあったんだけど調べてもやり方がすぐに出てこなかったので試してみた。
他にもっと簡単な方法があるかも?

おまけ

4月のそとちゃん(2022)

Wed, 04 May 2022 00:00:00 +0000

まとめ

つめとぎ
毛布だいすき
よくしゃべる

つめとぎ

先月買ったつめとぎベッドをちょっと使ってくれるようになった。

とてもえらい。

えらい pic.twitter.com/yqEarIA2J2
— ずみし (@uzimihsr) April 1, 2022

でもやっぱり元のつめとぎ(ソファ)が好きみたい。

まだソファ率の方が高い pic.twitter.com/nAGGOBtgkE
— ずみし (@uzimihsr) April 1, 2022

そして現在…

ついに布が破けて中身が見えるようになってしまった…

逆側の肘掛けももう長くないかもしれない😭

あなたがバリバリしたんですよ pic.twitter.com/j7MvKmv2Oh
— ずみし (@uzimihsr) April 9, 2022

どうして…

毛布だいすき

理由は忘れちゃったけど何かの機会にベッドに敷いてる毛布とは別の毛布を出して、
片付けるのが面倒でそのままソファに置いていたらねこに気に入られてしまった。

この毛布も好き pic.twitter.com/pDolLa3wOh
— ずみし (@uzimihsr) April 6, 2022

あんなに好きだったおひるねスポットの本棚の上にも登らずに昼間はずっとここで寝ている。

ねてる pic.twitter.com/JzyLHvRKqg
— ずみし (@uzimihsr) April 11, 2022

肌触りが好き?みたいで、よく体をこすりつけている。

毛布の上に乗っているときはいつもごきげん。

とはいえそろそろ暖かくなってきたので片付けたいが、
なかなかお許しが出ない。

攻撃の構え pic.twitter.com/Fi7Aoxm1p9
— ずみし (@uzimihsr) April 12, 2022

ちなみにベッドに敷いてる茶色の毛布もまだすき。

寝てる pic.twitter.com/Pf3qVRfLuj
— ずみし (@uzimihsr) April 16, 2022

よくしゃべる

そとちゃんはよくしゃべる。

特に夕方の晩ごはん前はすごい。

おひるねから起きてからごはんをもらうまではずっと話しかけてくる。

割とまったりしてるときにも喋ってくれる。

ひざには乗るけどかまってほしくないときがある pic.twitter.com/WTqoIZgskF
— ずみし (@uzimihsr) April 30, 2022

これくらい喋ってくれるとコミュニケーションがとれているような気分になって楽しい。

あとはまだ撮れたことがないけど、遊んでるときとか早朝は爆音で叫ぶのでいつか動画にしたい。

おわり

そとちゃんはいつも通り元気だった。

何気なく動画をいくつか撮ってみたら結構楽しかったので、
もうちょっと頻繁に撮ってもいいかもしれない。

おまけ

Read the specified YAML file with golang

Mon, 25 Apr 2022 00:00:00 +0000

日本語版/Japanese

Summary

The following code is an example of reading a YAML file with the name specified by a command line flag.

$ cat members.yaml
members:
- name: "John Doe"
 age: 20
 privileged: false
 languages:
 - language: "Java"
 years: 4
 - language: "Go"
 years: 2
- name: "Jane Doe"
 age: 30
 privileged: true

$ go run main.go -yaml-file members.yaml
name: John Doe
age: 20
privileged: false
language 0: Java for 4 year(s)
language 1: Go for 2 year(s)
name: Jane Doe
age: 30
privileged: true

Prerequisites

go 1.18

Detail

Parse a flag with the flag package
Read a YAML file with the os package
Convert YAML values into a Go struct with the yaml package

Parse a flag

Use flag package to parse command line flags.
In this case, the number of flags must be 1 and no arg is allowed.

var yamlFile string
flag.StringVar(&yamlFile, "yaml-file", "", "path to the YAML file")
flag.Parse()
if flag.NFlag() != 1 || flag.NArg() != 0 {
 log.Fatalf("you must give one flag and no arg: #(flags)=%v, #(args)=%v\n", flag.NFlag(), flag.NArg())
}
if yamlFile == "" {
 log.Fatalf("you must specify yaml file\n")
}

Read a file

os.Readfile can open a file to read.

// yamlFile: string
data, err := os.ReadFile(yamlFile)
if err != nil {
 log.Fatalf("ERROR in reading file: %v\n", err)
}

Convert YAML values into a Go struct

yaml package converts YAML values into a Go struct.
In this case, assume the following YAML and define a struct representing values.

members:
- name: "John Doe"
 age: 20
 privileged: false
 languages:
 - language: "Java"
 years: 4
 - language: "Go"
 years: 2
- name: "Jane Doe"
 age: 30
 privileged: true

Some fields can be omitted if there is no need to read it.
map[interface{}]interface{} can be used instead of the struct, but I do not like that way.

// data: []byte
y := struct {
 Members []struct {
 Name string `yaml:"name"`
 Age int `yaml:"age"`
 Privileged bool `yaml:"privileged"`
 Languages []struct {
 Language string `yaml:"language"`
 Years int `yaml:"years"`
 } `yaml:"languages"`
 } `yaml:"members"`
}{}
err = yaml.Unmarshal(data, &y)
if err != nil {
 log.Fatalf("ERROR in parsing YAML: %v\n", err)
}

Then the values can be accessed by the field name of the struct representing the key name.

fmt.Printf("name: %v\n", y.Members[0].Name)

(The following is the same content in Japanese.)

まとめ

コマンドラインで指定されたYAMLファイルを開いて要素を取り出すまでのGoコードは以下のように書けそう
(以下コピペ用)

$ cat members.yaml
members:
- name: "John Doe"
 age: 20
 privileged: false
 languages:
 - language: "Java"
 years: 4
 - language: "Go"
 years: 2
- name: "Jane Doe"
 age: 30
 privileged: true

$ go run main.go -yaml-file members.yaml
name: John Doe
age: 20
privileged: false
language 0: Java for 4 year(s)
language 1: Go for 2 year(s)
name: Jane Doe
age: 30
privileged: true

環境

go 1.18

詳細

flagで指定されたYAMLファイル名をコード内で使用する
指定されたファイルを開く
ファイルの内容を構造体にパースしてkeyで値を取り出せる状態にする

flagの処理

まずは標準のflagパッケージを使い、実行時に対象のファイル名を指定できるようにする。
4行目以降でflag数と入力値のバリデーションをかけてみたが、特に気にならなければ消してもいい。

var yamlFile string
flag.StringVar(&yamlFile, "yaml-file", "", "path to the YAML file")
flag.Parse()
if flag.NFlag() != 1 || flag.NArg() != 0 {
 log.Fatalf("you must give one flag and no arg: #(flags)=%v, #(args)=%v\n", flag.NFlag(), flag.NArg())
}
if yamlFile == "" {
 log.Fatalf("you must specify yaml file\n")
}

ファイルの読み込み

次にosパッケージで対象のファイルを開く。

// yamlFile: string
data, err := os.ReadFile(yamlFile)
if err != nil {
 log.Fatalf("ERROR in reading file: %v\n", err)
}

YAMLにパース

最後にyamlパッケージで対象のyamlを構造体にパースする。

今回は下記のようなYAMLを想定し、
その構造をパース用の構造体に定義する。

members:
- name: "John Doe"
 age: 20
 privileged: false
 languages:
 - language: "Java"
 years: 4
 - language: "Go"
 years: 2
- name: "Jane Doe"
 age: 30
 privileged: true

パースが不要な要素については定義しなくても問題ない。
また、構造体の代わりにmap[interface{}]interface{}を使う方法もあるが、
要素を呼び出すたびに型をアサーションして使うのはあまり好きではない。

// data: []byte
y := struct {
 Members []struct {
 Name string `yaml:"name"`
 Age int `yaml:"age"`
 Privileged bool `yaml:"privileged"`
 Languages []struct {
 Language string `yaml:"language"`
 Years int `yaml:"years"`
 } `yaml:"languages"`
 } `yaml:"members"`
}{}
err = yaml.Unmarshal(data, &y)
if err != nil {
 log.Fatalf("ERROR in parsing YAML: %v\n", err)
}

構造体にパースできたら、
あとはフィールド名を指定して要素にアクセスができる。

fmt.Printf("name: %v\n", y.Members[0].Name)

おわり

久しぶりにGoに触ったらいろいろ消耗してしまったので自分のコピペ用に書いてみた。

YAMLを設定ファイルとして読み込むものを書く機会が多いので、出番があるといいな…

おまけ

Read and update Kubernetes YAML with yq(v4)

Thu, 14 Apr 2022 00:00:00 +0000

日本語版/Japanese

Summary

yq is very useful for reading or updating Kubernetes YAML.

## read the value(key=spec.containers[0].image) from YAML(pod.yaml)

# specify the file
yq '.spec.containers[0].image' pod.yaml

# pipe from stdout
cat pod.yaml | yq '.spec.containers[0].image'


## update the YAML value(key=spec.containers[0].image) to "nginx:1.20.2"

# stdout
cat pod.yaml | yq '.spec.containers[0].image = "nginx:1.20.2"'

# update the file
yq -i '.spec.containers[0].image = "nginx:1.20.2"' pod.yaml

Prerequisites

yq version 4.24.2

Read and Update Kubernetes YAML with yq

Let’s read and update the pod.yaml with yq.

Read

We can extract the value by specifying the key.

# extract the image name
$ yq '.spec.containers[0].image' pod.yaml
nginx:latest

# extract the tag
$ yq '.spec.containers[0].image' pod.yaml | grep -o '^[^:]\+'
nginx
$ yq '.spec.containers[0].image' pod.yaml | grep -o '[^:]\+$'
latest

# pipe from stdout
$ cat pod.yaml | yq '.spec.containers[0].image'
nginx:latest
$ cat pod.yaml | yq '.spec.containers[0].image' | grep -o '^[^:]\+'
nginx
$ cat pod.yaml | yq '.spec.containers[0].image' | grep -o '[^:]\+$'
latest

Update

You can change the value of the specified key.

# change the image name
$ cat pod.yaml | yq '.spec.containers[0].image = "nginx:1.20.2"'
apiVersion: v1
kind: Pod
metadata:
 name: nginx-pod
spec:
 containers:
 - name: nginx
 image: nginx:1.20.2

# update the file directly
$ yq -i '.spec.containers[0].image = "nginx:1.20.2"' pod.yaml
$ cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
 name: nginx-pod
spec:
 containers:
 - name: nginx
 image: nginx:1.20.2

(The following is the same content in Japanese.)

まとめ

yqはv4でもやっぱり便利。

## YAML(pod.yaml)の値(key=spec.containers[0].image)を抽出

# ファイル名を指定するパターン
yq '.spec.containers[0].image' pod.yaml

# 標準出力からパイプで受けるパターン
cat pod.yaml | yq '.spec.containers[0].image'


## YAML(pod.yaml)の値(key=spec.containers[0].image)を"nginx:1.20.2"で上書き

# 標準出力に出すだけ
cat pod.yaml | yq '.spec.containers[0].image = "nginx:1.20.2"'

# ファイルの値を直接更新する
yq -i '.spec.containers[0].image = "nginx:1.20.2"' pod.yaml

環境

yq version 4.24.2
- v3については過去記事を参照

yqでKubernetes YAMLをいじる

こんな感じの pod.yaml をyqでいじる。

読む

keyを指定して特定の要素を取り出す。

# image名を抜き出す
$ yq '.spec.containers[0].image' pod.yaml
nginx:latest

# grepと合わせてtagを取り出す
$ yq '.spec.containers[0].image' pod.yaml | grep -o '^[^:]\+'
nginx
$ yq '.spec.containers[0].image' pod.yaml | grep -o '[^:]\+$'
latest

# パイプで渡すパターン
$ cat pod.yaml | yq '.spec.containers[0].image'
nginx:latest
$ cat pod.yaml | yq '.spec.containers[0].image' | grep -o '^[^:]\+'
nginx
$ cat pod.yaml | yq '.spec.containers[0].image' | grep -o '[^:]\+$'
latest

更新する

指定したkeyの値を上書きする。

# image名を更新する
$ cat pod.yaml | yq '.spec.containers[0].image = "nginx:1.20.2"'
apiVersion: v1
kind: Pod
metadata:
 name: nginx-pod
spec:
 containers:
 - name: nginx
 image: nginx:1.20.2

# ファイルを直接上書きする
$ yq -i '.spec.containers[0].image = "nginx:1.20.2"' pod.yaml
$ cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
 name: nginx-pod
spec:
 containers:
 - name: nginx
 image: nginx:1.20.2

おわり

yqのv3→v4へのアップデートでかなり大規模な変更があり、
過去に書いた記事の内容がそのままだと使えなくなってしまっていたので急いで書いてみた。
今までずっとv3を使っていたので、v4になった途端動かなくてびっくりした…

おまけ

3月のそとちゃん(2022)

Thu, 07 Apr 2022 00:00:00 +0000

まとめ

ひっくり返る
病院
つめとぎベッド

ひっくり返る

そとちゃんはいつもごろごろしている。

ごろごろ pic.twitter.com/QqaIjjgXzv
— ずみし (@uzimihsr) March 10, 2022

床でもベッドでも俺の上でも、機嫌がいいときは常にごろごろ。

ごきげん pic.twitter.com/SVYYmPLxZE
— ずみし (@uzimihsr) March 31, 2022

鼻と口の⅄がひっくり返ってるところがたまらなくかわいい。

Y pic.twitter.com/4tXzJK0Acc
— ずみし (@uzimihsr) March 16, 2022

…たまにひっくり返りすぎてちょっと怖い顔になってるのもおもしろい。

？ pic.twitter.com/NxjWvGcW1w
— ずみし (@uzimihsr) March 6, 2022

病院

12月に受けた手術のときに血液検査の数値が少し怪しかったそとちゃん。

予定通り3ヶ月経ったので再検査にいった。

以前はお出かけの気配を察して自分から進んでキャリーに入ってたのに、
手術がよっぽど嫌だったのか今回はおもちゃで釣らないと入ってくれなかった。

病院いく pic.twitter.com/nrApEsqhtX
— ずみし (@uzimihsr) March 25, 2022

病院の待合室でたまたま向かいに別のねこちゃんが居て、
キャリー越しにいっぱい話しかけてくれた(ような気がした)んだけどそとちゃんはガン無視。
他のねこには興味がないのかもしれない。
(普段ねこが出てるテレビ番組とか動画を見せてもそんなに食いつかない)

今回は前回までと違うベテランの先生で、
いつもは診察室でやりたい放題のそとちゃんがあっさり捕まって検査に連れて行かれたのがちょっとおもしろかった。

血液検査の結果は良好。
12月は1.7mg/dLだったクレアチニンの値が今回は1.2mg/dLまで下がっていた。

クレアチニンの値には元々波があって、前回のようにたまに高い値が出ることがあるらしい。
本当に腎臓が悪くなっていると慢性的に高い値で推移するようになるので、
今回低い値がでたのは良い傾向ということだった。

その他聴診や触診も問題なく、追加の通院や検査も不要になって安心した。
割と健康児なので年1回の健康診断で十分らしい。🎉

ちなみに、血液検査の結果で頭がいっぱいで最近のごはんの量について相談するのを忘れてしまった…
体重が3.98kgと少し軽めだったので、おやつの量をちょっと増やすくらいはいいのかも？

病院がんばった pic.twitter.com/sr6dVRJG70
— ずみし (@uzimihsr) March 26, 2022

つめとぎベッド

そとちゃんのつめとぎ(俺のソファ)がボロボロで流石に壊れそうなので、
新しいつめとぎベッドを買ってみた。

新しい爪とぎを献上 pic.twitter.com/1tkteN4kDq
— ずみし (@uzimihsr) March 26, 2022

が、やはり使い慣れたつめとぎが良いらしく…

バリバリ pic.twitter.com/b7meXIxq0F
— ずみし (@uzimihsr) March 27, 2022

結局ソファは破壊されるもよう。

新しく買ったつめとぎガン無視で笑っちゃう pic.twitter.com/mqYvrSjGSB
— ずみし (@uzimihsr) March 29, 2022

ベッドということは理解しているみたいで、
一応乗ったり寝転がったりはするんだけどそこからなかなかつめとぎに発展しない。
せっかく買ったのに…😭

乗るけど爪とぎはしない pic.twitter.com/r05aU3njoR
— ずみし (@uzimihsr) March 28, 2022

おわり

3月もそとちゃんは元気だった。
検査の結果も問題なしで、本当に手がかからなくて助かる。

こんなに一緒に暮らしやすい子は他に居ないんじゃないか??(親バカ)

おまけ

2月のそとちゃん(2022)

Thu, 10 Mar 2022 00:00:00 +0000

まとめ

めっちゃ食べる
毛布

めっちゃ食べる

そとちゃんの食欲がすごい。

今までも晩ごはんのウェットフード(猫缶パウチ)は残さずきれいに食べるえらいねこだったんだけど、
最近はカリカリもきれいに平らげるようになった。

俺が居てもカリカリ食べるようになった
えらい pic.twitter.com/yKkktcpss7
— ずみし (@uzimihsr) February 17, 2022

そとちゃんの一日の食事はだいたいこんな感じ。

時刻	ごはん	エネルギー(kcal)
8:00 AM	療法食カリカリ約10g (カリカリマシーンで出る)	40
13:00 PM	療法食カリカリ約10g (カリカリマシーン)	40
18:00 PM	黒缶パウチ+かつお節トッピング	56+15
不定期(主に就寝前)	おやつのにぼし+かにかま	5+7
合計		163

体重約4.0kgのそとちゃんの場合1日の摂取カロリーは132~190kcalが適切らしいが、
そとちゃんはちょっと少食で、今まではこの量でもお昼のカリカリを残すことがあった。
(味にうるさいのもあるが…)

しかし手術後に元気が倍増したそとちゃんはごはんをもりもり食べる。
以前よりも運動量が増えたせいでお腹が空いているのか、カリカリもほぼ毎回完食。
カリカリマシーンの音でそとちゃんが駆け寄ってくるなんて以前は考えられなかった光景で、初めて見たときはかなり驚いた。

少し味覚が大人になったのかもしれないが、理由は何であれごはんをよく食べるようになってとてもえらい。
最近はごはんをおねだりすることも増えたので(めっちゃもじもじしてかわいい)、
あげすぎないように注意したい。

正解 pic.twitter.com/7ctanyd0Yb
— ずみし (@uzimihsr) February 19, 2022

毛布

俺のベッドに敷いてる毛布が好き。

毛布食べないで欲しい pic.twitter.com/2ZDquN2JYy
— ずみし (@uzimihsr) February 1, 2022

毎朝暴れて疲れたあとはだいたい毛布の上でごろごろしている。

しっぽ自分で踏んでる pic.twitter.com/Ek1z3OwLcM
— ずみし (@uzimihsr) February 7, 2022

お昼寝のあとから夕方もたまにごろごろしている。

ぐにゃぐにゃしてる pic.twitter.com/wJsOFQHVRY
— ずみし (@uzimihsr) February 9, 2022

だいぶ昔にド○キで適当に買った安物なんだけどなにがそんなに良いのだろうか…

スフィンクス pic.twitter.com/4PJWM0HOlt
— ずみし (@uzimihsr) February 24, 2022

ごろごろと遊びは毛布の上でするんだけど、そこで寝ることはめったに無い。
そとちゃんの中で寝る場所はキャットタワーと本棚の上だけと決まっているように見える。
むずかしい。

うおー pic.twitter.com/0fiae2qbGd
— ずみし (@uzimihsr) February 16, 2022

ちなみに毛布だけじゃなくて布団も上に乗るのだけは好き。
俺が寝てると上に乗ってくる。

起きられません pic.twitter.com/90WkQLkVj3
— ずみし (@uzimihsr) February 6, 2022

が、ガードが固い？ので布団の中に入ってくることは絶対にない。
たまに同衾チャレンジするんだけどすぐに抜け出してマウントポジションを取られる。
とにかく布を上からかけられるのが嫌みたい。
むずかしい…

おわり

そとちゃんが変わらず元気いっぱいで嬉しい。

運動量が明らかに増えたのでごはんの量はちょっと増やしてもいいのかな…?

3月に定期検診で病院に行くので、先生とも相談したい。

おまけ

Run CentOS Stream 8 on VirtualBox(Intel Mac)

Thu, 24 Feb 2022 00:00:00 +0000

Summary

This is my note on running CentOS Stream 8 via VirtualBox on MacOS.

Prerequisites

macOS Big Sur 11.6.4
- 2.5GHz quad-core Intel Core i7
VirtualBox 6.1.32
CentOS Stream release 8
Linux version 4.18.0-365.el8.x86_64

What I did

Install VirtualBox
Create a VM
Install CentOS Stream 8
Install Guest Additions

Install VirtualBox

Install the dmg for OS X hosts from https://www.virtualbox.org/ then run VirtualBox.pkg.

Follow the instructions and VirtualBox will appear on /Applications.

Create a VM

Start VirtualBox and click “New” to create a VM.

My settings are as follows.

The following is an overview of the VM I created.

Install CentOS Stream 8

In order to run CentOS on a VM, you have to download the image from https://www.centos.org/download/ .
I selected CentOS Stream 8(x86_64) for this time.

Any mirror will do, but you need to download CentOS-Stream-8-x86_64-YYYYMMDD-dvd1.iso.
The file is about 10GB and took about 20 minutes or more to download.

After downloading the .iso file, mount it in the VM on VirtualBox.
In the “Storage” section, specify the downloaded .iso file for “IDE Secondary Device 0”.
Click “Start”.

A new window will appears. Select “Install CentOS Stream 8-stream”.

Select any language you use in the next window.
When the following window appears, fix the options marked with a color.
I configured “Installation Destination”, “Root Password”, and “User Creation” for this time.
After configuration, click “Begin Installation”.

It took about 10 minutes to install.
After installation, click “Reboot System”.

A new window will appear.
Accept the license and click “FINISH CONFIGURATION”.

Some option windows will appear, but you can proceed as you wish.
Finally you can see GNOME Desktop.🎉

At first, update rpm packages.
Launch a terminal from “Activities” in the upper-left corner then run yum update.
Oops! I met the error “Could not resolve host”.

[uzimihsr@localhost ~]$ sudo yum update -y
CentOS Stream 8 - AppStream 0.0 B/s | 0 B 00:00 
Errors during downloading metadata for repository 'appstream':
 - Curl error (6): Couldn't resolve host name for http://mirrorlist.centos.org/?release=8-stream&arch=x86_64&repo=AppStream&infra=stock [Could not resolve host: mirrorlist.centos.org]
Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for http://mirrorlist.centos.org/?release=8-stream&arch=x86_64&repo=AppStream&infra=stock [Could not resolve host: mirrorlist.centos.org]

You can see the status in the upper-right corner shows “Wired Off”.
Go to “Wired Settings” > “⚙️” and enable “Connect automatically”.

Now we can see “Wired Connected” in the status.
Try yum update again. It will succeed this time.

sudo yum update -y

Install Guest Additions

Guest Additions make it easy to integrate VirtualBox VMs and the host OS.

https://www.virtualbox.org/manual/ch04.html

Back to the host OS.
Select “VirtualBox VM”→“Devices”→“Insert Guest Additions CD image…”.

You will see some windows with warnings about the software or a request for the administrator password, but proceed anyway.
A new terminal will appear and the scripts will run on it.
Aww. I met the error “Kernel headers not found for target kernel”.

Verifying archive integrity... All good.
Uncompressing VirtualBox 6.1.32 Guest Additions for Linux........
VirtualBox Guest Additions installer
Copying additional installer modules ...
Installing additional modules ...
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel 
modules. This may take a while.
VirtualBox Guest Additions: To build modules for other installed kernels, run
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup <version>
VirtualBox Guest Additions: or
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup all
VirtualBox Guest Additions: Kernel headers not found for target kernel 
4.18.0-365.el8.x86_64. Please install them and execute
 /sbin/rcvboxadd setup
modprobe vboxguest failed
The log file /var/log/vboxadd-setup.log may contain further information.
Press Return to close this window...

Let’s install kernel-headers and kernel-devel, then reboot the OS.

sudo yum install -y kernel-headers kernel-devel
sudo reboot

After rebooting, open a terminal and execute the command shown in the previous message.
Oh, no. I met the different error “Please install the gcc make perl packages from your distribution”.

[uzimihsr@localhost ~]$ sudo /sbin/rcvboxadd setup
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel 
modules. This may take a while.
VirtualBox Guest Additions: To build modules for other installed kernels, run
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup <version>
VirtualBox Guest Additions: or
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup all
VirtualBox Guest Additions: Building the modules for kernel 
4.18.0-365.el8.x86_64.

This system is currently not set up to build kernel modules.
Please install the gcc make perl packages from your distribution.
ValueError: File context for /opt/VBoxGuestAdditions-6.1.32/other/mount.vboxsf already defined
modprobe vboxguest failed
The log file /var/log/vboxadd-setup.log may contain further information.

Install them.

sudo yum install -y gcc make perl

Execute the command again.
The new error came out, but I couldn’t figure it out.

[uzimihsr@localhost ~]$ sudo /sbin/rcvboxadd setup
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel 
modules. This may take a while.
VirtualBox Guest Additions: To build modules for other installed kernels, run
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup <version>
VirtualBox Guest Additions: or
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup all
VirtualBox Guest Additions: Building the modules for kernel 
4.18.0-365.el8.x86_64.

VirtualBox Guest Additions: Look at /var/log/vboxadd-setup.log to find out what 
went wrong
ValueError: File context for /opt/VBoxGuestAdditions-6.1.32/other/mount.vboxsf already defined
modprobe vboxguest failed
The log file /var/log/vboxadd-setup.log may contain further information.

Let’s open the log file to see the details.
It said “please install libelf-dev, libelf-devel or elfutils-libelf-devel”.

[uzimihsr@localhost ~]$ cat /var/log/vboxadd-setup.log
Building the main Guest Additions 6.1.32 module for kernel 4.18.0-365.el8.x86_64.
Error building the module. Build output follows.
make V=1 CONFIG_MODULE_SIG= CONFIG_MODULE_SIG_ALL= -C /lib/modules/4.18.0-365.el8.x86_64/build M=/tmp/vbox.0 SRCROOT=/tmp/vbox.0 -j1 modules
Makefile:985: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop.
make: *** [/tmp/vbox.0/Makefile-footer.gmk:117: vboxguest] Error 2
modprobe vboxguest failed

I tried yum search for the package, but there was only elfutils-libelf-devel.
Install it.

sudo yum install -y elfutils-libelf-devel

Try again.
Maybe it worked?

[uzimihsr@localhost ~]$ sudo /sbin/rcvboxadd setup
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel 
modules. This may take a while.
VirtualBox Guest Additions: To build modules for other installed kernels, run
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup <version>
VirtualBox Guest Additions: or
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup all
VirtualBox Guest Additions: Building the modules for kernel 
4.18.0-365.el8.x86_64.

VirtualBox Guest Additions: Look at /var/log/vboxadd-setup.log to find out what 
went wrong
ValueError: File context for /opt/VBoxGuestAdditions-6.1.32/other/mount.vboxsf already defined
VirtualBox Guest Additions: Running kernel modules will not be replaced until 
the system is restarted
[uzimihsr@localhost ~]$ echo $?
0

Although there is another compilation error in the log file, but the exit code of the command was 0, and the message told me to reboot to let kernels load the modules.

[uzimihsr@localhost ~]$ cat /var/log/vboxadd-setup.log
Building the main Guest Additions 6.1.32 module for kernel 4.18.0-365.el8.x86_64.
Building the shared folder support module.
Building the graphics driver module.
Error building the module. Build output follows.
make V=1 CONFIG_MODULE_SIG= CONFIG_MODULE_SIG_ALL= -C /lib/modules/4.18.0-365.el8.x86_64/build M=/tmp/vbox.0 SRCROOT=/tmp/vbox.0 -j1 modules
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (	\
echo >&2;							\
echo >&2 " ERROR: Kernel configuration is invalid.";		\
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it.";	\
echo >&2 ;							\
/bin/false)
mkdir -p /tmp/vbox.0/.tmp_versions ; rm -f /tmp/vbox.0/.tmp_versions/*
make -f ./scripts/Makefile.build obj=/tmp/vbox.0
(cat /dev/null; echo kernel//tmp/vbox.0/vboxvideo.ko;) > /tmp/vbox.0/modules.order
 gcc -Wp,-MD,/tmp/vbox.0/.hgsmi_base.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/8/include -I./arch/x86/include -I./arch/x86/include/generated -I./include/drm-backport -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -DCC_HAVE_ASM_GOTO -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -DCONFIG_TPAUSE=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -O2 --param=allow-store-data-races=0 -Wframe-larger-than=2048 -fstack-protector-strong -Wno-unused-but-set-variable -Wno-unused-const-variable -g -gdwarf-4 -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -Wno-stringop-truncation -Wno-maybe-uninitialized -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fmacro-prefix-map=./= -Wno-packed-not-aligned -I./include -I/tmp/vbox.0/ -I./include/drm -D__KERNEL__ -DMODULE -DRT_WITHOUT_PRAGMA_ONCE -DRT_ARCH_AMD64 -DMODULE -DKBUILD_BASENAME='"hgsmi_base"' -DKBUILD_MODNAME='"vboxvideo"' -c -o /tmp/vbox.0/.tmp_hgsmi_base.o /tmp/vbox.0/hgsmi_base.c
In file included from /tmp/vbox.0/hgsmi_base.c:27:
/tmp/vbox.0/vbox_drv.h:175:11: fatal error: drm/ttm/ttm_memory.h: No such file or directory
 # include <drm/ttm/ttm_memory.h>
 ^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.build:316: /tmp/vbox.0/hgsmi_base.o] Error 1
make[1]: *** [Makefile:1577: _module_/tmp/vbox.0] Error 2
make: *** [/tmp/vbox.0/Makefile-footer.gmk:117: vboxvideo] Error 2
[uzimihsr@localhost ~]$ sudo reboot

Now the mouse pointer moves seamlessly. Yeah.

As a final touch, enable the shared clipboard.
On VirtualBox, set “Settings” > “General” > “Advanced” > “Shared Clipboard” to “Bidirectional”.
Now you can copy and paste across the VM(CentOS) and the host(macOS).

That’s it for this time.

(The following is the same content in Japanese.)

まとめ

久しぶりにVirtualBoxで遊ぼうとしたら動かなくなってたので最初から環境構築しなおした。
いろいろ詰まったので手順を残しておく。

環境

macOS Big Sur 11.6.4
- 2.5GHz quad-core Intel Core i7
VirtualBox 6.1.32
CentOS Stream release 8
Linux version 4.18.0-365.el8.x86_64

やったこと

VirtualBoxのインストール
VMの作成
CentOS Stream 8のインストールとセットアップ
Guest Additionsの導入

VirtualBoxのインストール

https://www.virtualbox.org/ からOSX用のdmgファイルをダウンロードして中に入っているインストーラを起動する。

インストーラを起動して指示に従っていけば/Applications配下にVirtualBoxがインストールされる。

VMの作成

VirtualBoxを起動して"New"からVMの作成を行う。

名前は適当で、メモリのサイズも無理のない範囲で選ぶ。
ストレージは32GB程度確保する。

作成したVMの情報はこんな感じ。

CentOS Stream 8のインストールとセットアップ

作成したVMで起動するOSのイメージが必要なので、
https://www.centos.org/download/ から持ってくる。

今回はx86_64用CentOS Stream 8を選択。
ミラーはどこでもいいのでCentOS-Stream-8-x86_64-YYYYMMDD-dvd1.isoをダウンロードする。
10GBくらいあってダウンロードには30分程度かかった。

isoを落とせたら再度VirtualBoxに戻り、
先程作成したVMの設定の"Storage"で"IDE Secondary Device 0"を押して先程ダウンロードしたisoファイルを選択した状態で"Start"する。

別ウインドウが出るので"Install CentOS Stream 8-stream"を押す。

CentOSのインストール画面が開くので適当に言語を選んで進む。
次の画面になったら色が変わっている項目を埋める。
今回は"Installation Destination", “Root Password”, “User Creation"だけいじった。
“Begin Installation"を押してインストールを開始。

インストールは10分ちょっとかかる。
インストールが終わったら"Reboot System"から再起動する。

再起動が成功するとライセンスに同意しろ的な画面が出るので同意した上で"FINISH CONFIGURATION"を押す。

またまた言語とかの設定画面が出るが適当に選択すればデスクトップ画面にたどり着ける。

まずはパッケージを更新したいので、左上の"Activities"から端末を開いてyum updateする。
すると名前解決できないぞ的なエラーに。

[uzimihsr@localhost ~]$ sudo yum update -y
CentOS Stream 8 - AppStream 0.0 B/s | 0 B 00:00 
Errors during downloading metadata for repository 'appstream':
 - Curl error (6): Couldn't resolve host name for http://mirrorlist.centos.org/?release=8-stream&arch=x86_64&repo=AppStream&infra=stock [Could not resolve host: mirrorlist.centos.org]
Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for http://mirrorlist.centos.org/?release=8-stream&arch=x86_64&repo=AppStream&infra=stock [Could not resolve host: mirrorlist.centos.org]

いろいろ見てると右上のステータスで"Wired Off"になっていて、どうやらネットワークにつながっていないっぽい。
“Wired Settings”→"⚙️"を開いて"Connect automatically"にチェックを入れて適用する。

すると右上に"wired connected"のマークが出るようになるので再度パッケージ更新を試す。
今度はうまく行った。

sudo yum update -y

Guest Additionsの導入

VirtualBoxで立てたVMにGuest Additionsっていうのを入れるとホストOSとシームレスにGUI(マウス)操作ができたりして色々便利らしい。

https://www.virtualbox.org/manual/ch04.html

ホスト(Mac)側の操作に戻り、
“VirtualBox VM”→“Devices”→“Insert Guest Additions CD image…“を選択。

なんかVMの画面でソフトウェアの警告が出たり管理者権限を要求されるけどガンガン進む。
勝手に新しい端末が開いてスクリプトが動く。
…が、“モジュールのビルドに必要なカーネルヘッダがないよ"的なエラーで失敗する。

Verifying archive integrity... All good.
Uncompressing VirtualBox 6.1.32 Guest Additions for Linux........
VirtualBox Guest Additions installer
Copying additional installer modules ...
Installing additional modules ...
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel 
modules. This may take a while.
VirtualBox Guest Additions: To build modules for other installed kernels, run
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup <version>
VirtualBox Guest Additions: or
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup all
VirtualBox Guest Additions: Kernel headers not found for target kernel 
4.18.0-365.el8.x86_64. Please install them and execute
 /sbin/rcvboxadd setup
modprobe vboxguest failed
The log file /var/log/vboxadd-setup.log may contain further information.
Press Return to close this window...

言われたとおりkernel-headersとkernel-develを入れる。
カーネル関連のパッケージを入れたときは再起動。

sudo yum install -y kernel-headers kernel-devel
sudo reboot

再起動後、さっきのエラーメッセージでカーネルヘッダのインストール後に実行するよう指定されていたコマンドを打つ。
またエラー。つらい。
今度は”gcc, make, perlが無いよ"と言われた。

[uzimihsr@localhost ~]$ sudo /sbin/rcvboxadd setup
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel 
modules. This may take a while.
VirtualBox Guest Additions: To build modules for other installed kernels, run
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup <version>
VirtualBox Guest Additions: or
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup all
VirtualBox Guest Additions: Building the modules for kernel 
4.18.0-365.el8.x86_64.

This system is currently not set up to build kernel modules.
Please install the gcc make perl packages from your distribution.
ValueError: File context for /opt/VBoxGuestAdditions-6.1.32/other/mount.vboxsf already defined
modprobe vboxguest failed
The log file /var/log/vboxadd-setup.log may contain further information.

言われたとおりに入れる。

sudo yum install -y gcc make perl

再度実行。
またまたエラー。

[uzimihsr@localhost ~]$ sudo /sbin/rcvboxadd setup
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel 
modules. This may take a while.
VirtualBox Guest Additions: To build modules for other installed kernels, run
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup <version>
VirtualBox Guest Additions: or
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup all
VirtualBox Guest Additions: Building the modules for kernel 
4.18.0-365.el8.x86_64.

VirtualBox Guest Additions: Look at /var/log/vboxadd-setup.log to find out what 
went wrong
ValueError: File context for /opt/VBoxGuestAdditions-6.1.32/other/mount.vboxsf already defined
modprobe vboxguest failed
The log file /var/log/vboxadd-setup.log may contain further information.

今度は何もわからないので、指定されたログファイルを確認する。
なんかlibelf-devがないよ的なことを言われている。

[uzimihsr@localhost ~]$ cat /var/log/vboxadd-setup.log
Building the main Guest Additions 6.1.32 module for kernel 4.18.0-365.el8.x86_64.
Error building the module. Build output follows.
make V=1 CONFIG_MODULE_SIG= CONFIG_MODULE_SIG_ALL= -C /lib/modules/4.18.0-365.el8.x86_64/build M=/tmp/vbox.0 SRCROOT=/tmp/vbox.0 -j1 modules
Makefile:985: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop.
make: *** [/tmp/vbox.0/Makefile-footer.gmk:117: vboxguest] Error 2
modprobe vboxguest failed

libelf-develはELFバイナリファイルをいじるためのユーティリティらしい(あんまり知らない)。
https://sourceware.org/elfutils/

yum searchかけた感じだとelfutils-libelf-develしか見つからなかったのでこれを入れる。

sudo yum install -y elfutils-libelf-devel

再度実行。
今度は行けたっぽい？

[uzimihsr@localhost ~]$ sudo /sbin/rcvboxadd setup
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel 
modules. This may take a while.
VirtualBox Guest Additions: To build modules for other installed kernels, run
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup <version>
VirtualBox Guest Additions: or
VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup all
VirtualBox Guest Additions: Building the modules for kernel 
4.18.0-365.el8.x86_64.

VirtualBox Guest Additions: Look at /var/log/vboxadd-setup.log to find out what 
went wrong
ValueError: File context for /opt/VBoxGuestAdditions-6.1.32/other/mount.vboxsf already defined
VirtualBox Guest Additions: Running kernel modules will not be replaced until 
the system is restarted
[uzimihsr@localhost ~]$ echo $?
0

さっきと同じログファイルにはヘッダファイルが見つからない的なエラーが出てるんだけど、
終了コードが0だしモジュールを読み込むために再起動するよう言われてるのでそれに従う。

[uzimihsr@localhost ~]$ cat /var/log/vboxadd-setup.log
Building the main Guest Additions 6.1.32 module for kernel 4.18.0-365.el8.x86_64.
Building the shared folder support module.
Building the graphics driver module.
Error building the module. Build output follows.
make V=1 CONFIG_MODULE_SIG= CONFIG_MODULE_SIG_ALL= -C /lib/modules/4.18.0-365.el8.x86_64/build M=/tmp/vbox.0 SRCROOT=/tmp/vbox.0 -j1 modules
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (	\
echo >&2;							\
echo >&2 " ERROR: Kernel configuration is invalid.";		\
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it.";	\
echo >&2 ;							\
/bin/false)
mkdir -p /tmp/vbox.0/.tmp_versions ; rm -f /tmp/vbox.0/.tmp_versions/*
make -f ./scripts/Makefile.build obj=/tmp/vbox.0
(cat /dev/null; echo kernel//tmp/vbox.0/vboxvideo.ko;) > /tmp/vbox.0/modules.order
 gcc -Wp,-MD,/tmp/vbox.0/.hgsmi_base.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/8/include -I./arch/x86/include -I./arch/x86/include/generated -I./include/drm-backport -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -DCC_HAVE_ASM_GOTO -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -DCONFIG_TPAUSE=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -O2 --param=allow-store-data-races=0 -Wframe-larger-than=2048 -fstack-protector-strong -Wno-unused-but-set-variable -Wno-unused-const-variable -g -gdwarf-4 -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -Wno-stringop-truncation -Wno-maybe-uninitialized -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fmacro-prefix-map=./= -Wno-packed-not-aligned -I./include -I/tmp/vbox.0/ -I./include/drm -D__KERNEL__ -DMODULE -DRT_WITHOUT_PRAGMA_ONCE -DRT_ARCH_AMD64 -DMODULE -DKBUILD_BASENAME='"hgsmi_base"' -DKBUILD_MODNAME='"vboxvideo"' -c -o /tmp/vbox.0/.tmp_hgsmi_base.o /tmp/vbox.0/hgsmi_base.c
In file included from /tmp/vbox.0/hgsmi_base.c:27:
/tmp/vbox.0/vbox_drv.h:175:11: fatal error: drm/ttm/ttm_memory.h: No such file or directory
 # include <drm/ttm/ttm_memory.h>
 ^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.build:316: /tmp/vbox.0/hgsmi_base.o] Error 1
make[1]: *** [Makefile:1577: _module_/tmp/vbox.0] Error 2
make: *** [/tmp/vbox.0/Makefile-footer.gmk:117: vboxvideo] Error 2
[uzimihsr@localhost ~]$ sudo reboot

再起動後はたしかにマウス操作がやりやすくなっている。

最後にクリップボード共有の設定を入れる。
VirtualBoxの画面で"Settings”→“General”→“Advanced”→“Shared Clipboard"を"Bidirectional"にすると、
ホスト(Mac)とVM(CentOS)をまたいだコピペができるようになって便利。

疲れたのでとりあえずここまで。

おわり

こういった地味な環境構築をたまにやるとたのしい。

VirtualBox使うのが久しぶりでいろいろ詰まったが良い練習になった。

おまけ

A queue and multiple workers in golang

Thu, 10 Feb 2022 00:00:00 +0000

Summary

A queue & multiple workers in golang
- We can use buffered channel as a queue, and goroutines as workers.
- WaitGroup is useful to wait for goroutines to finish.
- Context makes it easy to stop other goroutines from one goroutine.

Prerequisites

go version go1.17.3 darwin/amd64

Channel as a queue, Goroutines as workers

I wanted to write the following pattern in golang:

A queue has multiple processing targets
Each worker gets one target from the queue, processes it, and repeats the procedure until the queue is empty
All workers run in parallel
If an error occurs in one worker, all other workers will stop after processing the current target

I wrote that pattern using buffered channels and goroutines.

Here are some notes.

A queue has multiple processing targets
Each worker gets one target from the queue, processes it, and repeats the procedure until the queue is empty

In this case, we can use buffered channel as a queue.
A worker tries to get the target from the channel, and processes it if it succeeds, or exits if the channel is closed.
I implemented this pattern with select statement.

// example
target := []int{1, 8, 5, 2, 3, 9, 1}

queue := make(chan int, len(target))
for len(target) > 0 {
 queue <- target[0]
 target = target[1:]
}
close(queue)

for {
 select {
 case v, ok := <-queue:
 if !ok {
 return
 }
 // any task you want to do for v

 default:
 time.Sleep(1 * time.Second)
 }
}

If an error occurs in one worker, all other workers will stop after processing the current target

context.WithCancel is suitable for this purpose.
If the process returns an error, the worker will execute cancelFunc.
cancelFunc closes ctx(channel) and the worker will stop when ctx is closed.

// example
ctx, cancel := context.WithCancel(context.Background())
for {
 select {
 case <-ctx.Done():
 return
 default:
 }

 err := process() // any task you want

 if err != nil {
 cancel()
 }
}

All workers run in parallel

With sync.WaitGroup, it can wait for multiple goroutines to stop.
When a goroutine starts, call Add to increase the counter, and when it finishes, call Done to decrease the counter.
Wait waits until the counter reaches zero.

// example
var wg sync.WaitGroup
workers := 3

for i := 0; i < workers; i++ {
 wg.Add(1)
 go func() {
 defer wg.Done()
 // any task you want
 }()
}

wg.Wait()

In order to vary the processing time depending on the target, I created the following process.

sleep for the specified number of seconds
if the specified number is 4, raise an error

func process(n int) error {
 time.Sleep(time.Duration(n) * time.Second)
 if n == 4 {
 return errors.New("Unlucky 4!!!")
 }
 return nil
}

Then run main.go.

Go Playground

targets: [1 8 5 2 3 7 6]
number of workers: 3
Worker-1: target 1 START
Worker-0: target 5 START
Worker-2: target 8 START
Worker-1: target 1 END
Worker-1: target 2 START
Worker-1: target 2 END
Worker-1: target 3 START
Worker-0: target 5 END
Worker-0: target 7 START
Worker-1: target 3 END
Worker-1: target 6 START
Worker-2: target 8 END
Worker-2: no target...finish
Worker-0: target 7 END
Worker-0: no target...finish
Worker-1: target 6 END
Worker-1: no target...finish
All workers finished.
All targets were processed.

It is hard to understand how it worked in text, so I made a diagram below.
All workers work in parallel and each worker gets the target from the queue.
Worker 1 drew a small number and immediately went for the next target.
In contrast, Worker 2 drew a large number, and the queue had been already empty when the worker finished its first target.

Change the target to cause an error, and run main.go again.

Go Playground

targets: [1 8 4 2 3 7 6]
number of workers: 3
Worker-2: target 1 START
Worker-0: target 8 START
Worker-1: target 4 START
Worker-2: target 1 END
Worker-2: target 2 START
Worker-2: target 2 END
Worker-2: target 3 START
Worker-1: ERROR! Unlucky 4!!!
Worker-2: target 3 END
Worker-2: received ctx.Done()...finish
Worker-0: target 8 END
Worker-0: received ctx.Done()...finish
All workers finished.
7 was not processed...
6 was not processed...

Worker 1 drew “4” and raised an error, then all workers stopped after finishing the target they had.

(The following is the same content in Japanese.)

まとめ

Goで複数の処理対象を1つのキューに詰めて複数のワーカーで並行して処理するやつを書いた
- channelをキューとして、goroutineをワーカーとして使えそう
- 複数goroutineの完了を待つにはWaitGroupを使うのが良さげ
- goroutineから他のgoroutineを止めたりするのはContextを使うのが良さげ

環境

go version go1.17.3 darwin/amd64

キュー(channel)とワーカー(go routine)

Goでちょっとしたバッチ的なものを書こうとしたときに、
同じような処理を繰り返す部分があったのでgoroutineを使っていい感じの並行処理を書きたくなった。

イメージとしては

処理したい対象が1つのキューに詰められている
1つのワーカーはキューから対象を1つ取り出して処理、をキューが空になるまで繰り返す
すべてのワーカーは並行して動作する
どこかのワーカーでエラーが発生したら他の全てのワーカーにも知らせて、それを知った各ワーカーは現在処理している対象までで処理を終了する

という感じ。

今回はかんたんなものの例としてGoのchannelとgoroutineを用いて実現してみた。

重要そうなところを(数ヶ月後の自分のために)メモしておく。

処理したい対象が1つのキューに詰められている
1つのワーカーはキューから対象を1つ取り出して処理、をキューが空になるまで繰り返す

は次のように書いた。

今回の用途のキューであれば、バッファありchannelを使って実現できる。
selectを使って、channelから値が取り出せれば何らかの処理を実行、channelが閉じられたらそこで止まるようにした。

target := []int{1, 8, 5, 2, 3, 9, 1}

queue := make(chan int, len(target))
for len(target) > 0 {
 queue <- target[0]
 target = target[1:]
}
close(queue)

for {
 select {
 case v, ok := <-queue:
 if !ok {
 return
 }
 // any task you want to do for the v

 default:
 time.Sleep(1 * time.Second)
 }
}

どこかのワーカーでエラーが発生したら他の全てのワーカーにも知らせて、それを知った各ワーカーは現在処理している対象までで処理を終了する

はcontext.WithCancelを使って次のように書いた。
ワーカー(go routine)でなにかエラーが起こったらcancelFuncを実行してctx(channel )を閉じ、
ctxが閉じられたらその時点でワーカーを終了させる。

ctx, cancel := context.WithCancel(context.Background())
for {
 select {
 case <-ctx.Done():
 return
 default:
 }

 err := process() // any task you want

 if err != nil {
 cancel()
 }
}

すべてのワーカーは並行して動作する

ワーカーを複数並行して動かし、全部のワーカーが止まるまで待つような処理はsync.WaitGroupをつかって書いた。
Waitを呼び出すと待つ対象が0になるまで待ち続けるので、
各goroutineの開始時にAddして待つ対象を増やし、goroutineが終了したらDoneで待つ対象をへらすようにしている。

var wg sync.WaitGroup
workers := 3

for i := 0; i < workers; i++ {
 wg.Add(1)
 go func() {
 defer wg.Done()
 // any task you want
 }()
}

wg.Wait()

あとはこれらをいい感じに組み合わせた。

また、今回は処理対象ごとに処理時間をバラバラにしたかったので、ワーカーの処理として次のようなものを用意した。

引数の秒数ぶん待機する
引数が4ならエラーを返す

func process(n int) error {
 time.Sleep(time.Duration(n) * time.Second)
 if n == 4 {
 return errors.New("Unlucky 4!!!")
 }
 return nil
}

main.goを実際に動かしてみる。

Go Playground

targets: [1 8 5 2 3 7 6]
number of workers: 3
Worker-1: target 1 START
Worker-0: target 5 START
Worker-2: target 8 START
Worker-1: target 1 END
Worker-1: target 2 START
Worker-1: target 2 END
Worker-1: target 3 START
Worker-0: target 5 END
Worker-0: target 7 START
Worker-1: target 3 END
Worker-1: target 6 START
Worker-2: target 8 END
Worker-2: no target...finish
Worker-0: target 7 END
Worker-0: no target...finish
Worker-1: target 6 END
Worker-1: no target...finish
All workers finished.
All targets were processed.

狙い通りに動いたのだが、文字だけ追っても見づらいので図にしてみた。
各ワーカーが1つずつ対象をキューから取り出してその秒数ぶん待機、を繰り返しており、
Worker 1のように小さい数字(=処理が軽い)を引くとその分次の対象を取りに行くのが早くなっていて、
逆にWorker 2のように最初に大きい数字(=処理が重い)を引くとその間に他のワーカーが働くので対象がなくなっている。

最後にワーカーがエラーを吐くような処理対象をキューに仕込んで動かしてみる。

Go Playground

targets: [1 8 4 2 3 7 6]
number of workers: 3
Worker-2: target 1 START
Worker-0: target 8 START
Worker-1: target 4 START
Worker-2: target 1 END
Worker-2: target 2 START
Worker-2: target 2 END
Worker-2: target 3 START
Worker-1: ERROR! Unlucky 4!!!
Worker-2: target 3 END
Worker-2: received ctx.Done()...finish
Worker-0: target 8 END
Worker-0: received ctx.Done()...finish
All workers finished.
7 was not processed...
6 was not processed...

こちらも狙い通り動いていて、
この場合は4を引いたWorker 1の処理でエラーが発生し、
他のワーカーもそのタイミングで持っている対象を最後に以降の処理を行わないようになっている。

おわり

久しぶりにGoにガッツリ触った。

go routineとかchannelとか適当な理解で済ませていたもののおさらいができてよかった。

おまけ

1月のそとちゃん(2022)

Tue, 01 Feb 2022 00:00:00 +0000

まとめ

あまえんぼ
あばれんぼ

あまえんぼ

またもあまえんぼ期が再来！

ねこはあったかいねぇ pic.twitter.com/UtkGEckq0O
— ずみし (@uzimihsr) January 4, 2022

ソファで座ってると高確率で膝に乗ってくる上に、
一度乗っちゃうと全然降りなくてこまっちゃう(たすかる)。

降りない pic.twitter.com/7r9sWkOUGX
— ずみし (@uzimihsr) January 10, 2022

人の膝の上に乗ってきて勝手に暴れたりひっくり返ったり(?)やりたい放題。

自由 pic.twitter.com/Gz2gO7BHCs
— ずみし (@uzimihsr) January 8, 2022

自由 pic.twitter.com/UJmr2WYKGK
— ずみし (@uzimihsr) January 2, 2022

たまたまねこがおしりをこっちに向けたときになんとなくぽんぽん叩いたらそれ以降ハマったらしく、
最近はちゃんとぽんぽんしないと文句を言われる。

この体勢になったらねこのおしりをぽんぽんしなくてはならない pic.twitter.com/a5q8jw1A0h
— ずみし (@uzimihsr) January 27, 2022

膝に乗ってないときもぽんぽんしてほしいらしい。

おしりぽんぽん要求ちゃん pic.twitter.com/dk5iVzAbq0
— ずみし (@uzimihsr) January 23, 2022

あまえんぼすぎてちょっと心配になるくらいだけど、
甘えてる最中のねこちゃんがアホみたいにかわいいのでOKです。

あまえんぼガチ勢 pic.twitter.com/CtFjYfP6TV
— ずみし (@uzimihsr) January 28, 2022

あばれんぼ

昨年末の手術後に動けなかった時期がなにかのきっかけになってしまったのか、
そとちゃんは未だに家の中を暴れまわっている。

暴れ毛玉 pic.twitter.com/K6Gede8pTy
— ずみし (@uzimihsr) January 12, 2022

特に早朝のテンションが最高潮で、毎朝鳴くわ跳ぶわ壊すわでとてもにぎやか。

今朝は大暴れで家壊れると思った pic.twitter.com/oLiWUdgIAe
— ずみし (@uzimihsr) January 27, 2022

破壊 pic.twitter.com/LDHDq1c9YH
— ずみし (@uzimihsr) January 28, 2022

前の日の夜に多めに遊ぶとか、そんな程度で朝のそとちゃんは止められない。

日が昇れば窓際で外にいかせろと叫び、

カリカリマシンから朝ごはんが出ればドカ食いしてすぐトイレ。

うんちをもりもり出したらちゃんと大声で報告した後(重要らしい)、俺が寝ている布団の上を走り回る。

俺はその衝撃で一瞬だけ起きて仕方なくおもちゃを廊下に投げ、ねこはそれを追いかけてしばき続ける。

あとはだいたい1hくらいキャットタワーと台所で暴れまわったらようやくちょっと眠くなって、
寝ている俺のお腹の上でおしりをこっちに向けて寝始める。

これが我が家のモーニングルーティーン。

起きられない pic.twitter.com/AXnYCvPTYx
— ずみし (@uzimihsr) January 25, 2022

起床封じ pic.twitter.com/abKAgMqR2O
— ずみし (@uzimihsr) January 30, 2022

一度この体勢になるとねこが自分で起きてどこかにいくまで動くことは許されない。

おかげで朝は高確率で二度寝してしまう身体になってしまった。

でもねこちゃんが元気なのでOKです。

おわり

年末の手術を頑張ったそとちゃんを甘やかしまくっていたら、とんでもない甘え暴れん坊になってしまった…

が、ねこは幸せになるほどふてぶてしくなるとどこかで聞いた気がするので、これでいいかなとも思っている。

おまけ

Specify the API Group of the resource with kubectl

Thu, 20 Jan 2022 00:00:00 +0000

Summary

We can use the expression <Resource>.<API Group> to specify the API Group with kubectl.

# Example: the expressions of "Event v1 core" and "Event v1 events.k8s.io"
kubectl auth can-i get events
kubectl auth can-i get events.events.k8s.io

Prerequisites

Kubernetes API v1.21.1
kubectl v1.21.5

Same resource, different API Groups

In Kubernetes API 1.21, there are some different API Groups for the same kind of resource.

For example:

Event
- Event v1 events.k8s.io
- Event v1 core
  - OLD API VERSIONS

# in Kubernetes 1.21, there are two different API Groups for Events resource
$ kubectl api-resources | grep event
events ev v1 true Event
events ev events.k8s.io/v1 true Event

But if we specify “events” resource with kubectl 1.21, it will be treated as “Event v1 core”.

# create a serviceaccount with permissions to view only "Event v1 core"
$ kubectl -n default create serviceaccount user01
$ kubectl -n default create role event-corev1-reader --verb="get,list" --resource="events"
$ kubectl -n default create rolebinding event-corev1-reader --role=event-corev1-reader --serviceaccount=default:user01

# Check the permissions of the serviceaccount
# https://kubernetes.io/docs/tasks/run-application/access-api-from-pod/#without-using-a-proxy 
$ kubectl -n default run nginx --image=nginx --restart=Never --rm -it --overrides='{ "spec": { "serviceAccountName" : "user01" } }' -- /bin/bash

# The serviceaccount can list "Event v1 core"
(root@nginx)$ curl -I -X GET -k https://kubernetes.default.svc/api/v1/namespaces/default/events -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
HTTP/2 200
...

# The serviceaccount is not allowed to list "Event v1 events.k8s.io"
(root@nginx)$ curl -I -X GET -k https://kubernetes.default.svc/apis/events.k8s.io/v1/namespaces/default/events -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
HTTP/2 403
...

So, how can we specify the API Group “events.k8s.io” with kubectl?

According to the help, we can use the expression <Resource>.<API Group>.

$ kubectl create role --help
...
Usage:
 kubectl create role NAME --verb=verb --resource=resource.group/subresource
[--resource-name=resourcename] [--dry-run=server|client|none] [options]
...

This expression can be used with other kubectl subcommands such as kubectl auth can-i.

# create a serviceaccount with permissions to view only "Event v1 events.k8s.io"
$ kubectl -n default create serviceaccount user02
$ kubectl -n default create role event-eventsk8siov1-reader --verb="get,list" --resource="events.events.k8s.io"
$ kubectl -n default create rolebinding event-eventsk8siov1-reader --role=event-eventsk8siov1-reader --serviceaccount=default:user02

# user01 can view only "Event v1 core"
$ kubectl -n default auth can-i get events --as system:serviceaccount:default:user01
yes

$ kubectl -n default auth can-i get events.events.k8s.io --as system:serviceaccount:default:user01
no

# user02 can view only "Event v1 events.k8s.io"
$ kubectl -n default auth can-i get events --as system:serviceaccount:default:user02
no

$ kubectl -n default auth can-i get events.events.k8s.io --as system:serviceaccount:default:user02
yes

(The following is the same content in Japanese.)

まとめ

リソースが同じでもAPI Groupが異なるものをkubectlで指定したいときは<Resource>.<API Group>とすれば良い。

# "Event v1 core"と"Event v1 events.k8s.io"をそれぞれ指定して権限を確認する例
kubectl auth can-i get events
kubectl auth can-i get events.events.k8s.io

環境

Kubernetes API v1.21.1
kubectl v1.21.5

同じリソース名でAPI versionが複数あるとき

Kubernetes APIではv1.21時点でEventのAPI Groupがevents.k8s.ioになっていて、
それまであったcore版のEventはOLD API VERSIONSという扱い。

# 1.22時点では2種類のAPI Groupが存在する
$ kubectl api-resources | grep event
events ev v1 true Event
events ev events.k8s.io/v1 true Event

しかし、v1.22のkubectlで普通にeventsに対するRoleを作成するとAPI Groupがcoreで指定されてしまう。

# "event"を指定してRoleを作成する
$ kubectl -n default create serviceaccount user01
$ kubectl -n default create role event-corev1-reader --verb="get,list" --resource="events"
$ kubectl -n default create rolebinding event-corev1-reader --role=event-corev1-reader --serviceaccount=default:user01

# Podを立てて確認してみる
# https://kubernetes.io/docs/tasks/run-application/access-api-from-pod/#without-using-a-proxy 
$ kubectl -n default run nginx --image=nginx --restart=Never --rm -it --overrides='{ "spec": { "serviceAccountName" : "user01" } }' -- /bin/bash

# coreのAPIは利用可能
(root@nginx)$ curl -I -X GET -k https://kubernetes.default.svc/api/v1/namespaces/default/events -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
HTTP/2 200
...

# events.k8s.ioのAPIは認可エラーで利用不可
(root@nginx)$ curl -I -X GET -k https://kubernetes.default.svc/apis/events.k8s.io/v1/namespaces/default/events -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
HTTP/2 403
...

じゃあk8s.events.io版への権限はどうやって付与するんだろう?と試行錯誤していたら、helpにちゃんと書いてあった…

$ kubectl create role --help
...
Usage:
 kubectl create role NAME --verb=verb --resource=resource.group/subresource
[--resource-name=resourcename] [--dry-run=server|client|none] [options]
...

リソースの後に続いて.<API Group>を指定すればいいらしい。
(何も指定しない場合はcoreになるっぽい?)

この方法で再度Roleを指定しなおす。

$ kubectl -n default create serviceaccount user02
$ kubectl -n default create role event-eventsk8siov1-reader --verb="get,list" --resource="events.events.k8s.io"
$ kubectl -n default create rolebinding event-eventsk8siov1-reader --role=event-eventsk8siov1-reader --serviceaccount=default:user02

他のコマンドでリソースを指定するときも同様にできるらしいので、今度はPodを建てずにkubectl authで確認してみる。

# user01: core版のみの閲覧権限
$ kubectl -n default auth can-i get events --as system:serviceaccount:default:user01
yes

$ kubectl -n default auth can-i get events.events.k8s.io --as system:serviceaccount:default:user01
no

# user02: events.k8s.io版のみの閲覧権限
$ kubectl -n default auth can-i get events --as system:serviceaccount:default:user02
no

$ kubectl -n default auth can-i get events.events.k8s.io --as system:serviceaccount:default:user02
yes

やったぜ。

異なるAPI Groupをkubectlで指定できた。

おわり

ちゃんとヘルプを読んでいればなんてことない話だったんだけど、
自分は数時間ムダにしてしまったのでメモにした。

やっぱり公式ドキュメントやヘルプを読むのは大事。

おまけ

12月のそとちゃん(2021)

Thu, 30 Dec 2021 00:00:00 +0000

まとめ

手術
術後
がまん
抜糸

手術

今月は首にできた腫瘤の手術があった。

手術当日のそとちゃんはいつもどおり余裕ぶっこき状態。
それまで毎日そとちゃんと手術について(日本語で)話してはいたけど、
結局自分がなにをされるのかは最後まで理解していないようだった。
(それはそう😭)

御守りを食べるねこ pic.twitter.com/Bhp7rYojVW
— ずみし (@uzimihsr) December 16, 2021

余裕ぶっこいてる pic.twitter.com/JZpgtiQZoN
— ずみし (@uzimihsr) December 17, 2021

今回は日帰り手術ということで、
朝に診察を行い、昼は検査と手術、術後の様子を診て夕方に引き取りという流れ。

まずは診察。

これはそとちゃんというより俺のための時間という感じだった。
当日のそとちゃんの健康状態(食欲や遊ぶ元気)について軽く聞かれた後、
全身麻酔に関する説明と手術についての詳細、術後に気をつけるべきことなどについてもう一度丁寧に説明してもらい、
最後に承諾書のサインと押印を確認した。

一通りの説明を受けた後、最後にそとちゃんを少し抱きしめてから先生に預けた。
万が一のことがあればこれが最後の別れになるかもしれないと思って、恥ずかしながらこのとき少し泣いてしまった。😢

(ここからは手術前後に先生から説明を受けた内容)

次に検査。

全身麻酔には当然ながらリスクがあるので、
事故の可能性を最低限に抑えるために必ず術前に血液検査とX線検査が行われる。
先生によるとそとちゃんは注射は平気だったものの、X線検査で仰向けにされたときにめちゃくちゃ暴れたらしい。
(普段ひたすらごろごろしてるくせに、強制されるのは嫌😓)

検査結果に問題がなかったので麻酔をかけて施術が行われた。
切開から縫合までは十数分で終了し、その後そとちゃんはゆっくり目を醒ました。

手術の間はずっと心配でソワソワしていたので、術後に電話で連絡が来たときは本当に安心した。😭

術後

電話をもらった後も念のために病院で少し様子を診てもらい、
夕方ごろにそとちゃんを引き取りに行った。

診察室で5時間ぶりに対面したそとちゃんは少し不機嫌だった。😡
引き取りの直前におしっこを漏らしてしまったようで、
看護師さんにおしりを拭かれたのが気にいらなかったらしい。

その場で先生から血液検査とX線検査の結果を説明してもらった。

血液検査の数値はおおむね問題なしだが、クレアチニンとグロブリンの値が少し高め
- グロブリンは免疫が活発なときに高い数値になるもので、おそらく猫風邪の後遺症(右目の目ヤニができやすい原因)によるものだろうから仕方ない
- クレアチニンは腎臓の機能が低下したときに高くなる値なので、3ヶ月後を目安に再検査が必要😱
X線検査では肺や内臓に問題なく、その他の腫瘤などもない

切除した腫瘤は病理検査に送って1週間後に結果が返ってくるとのことで、
順調にいけばそのタイミングで抜糸できるかも?とのことだった。

ちなみに手術代の見積もりで病理検査の費用が漏れていたらしく、実際の請求額はかなり高くついてしまった…😭

病院から家に帰った後のそとちゃんは流石に少しぐったりしていたものの、ちょっとしてすぐにわんわん騒ぎ出した。
手術のタイミングで胃を空っぽにする都合で前日の夜から何も食べさせていなかったので、ほぼ丸一日ぶんお腹を空かせていたのだった。😭

手術痕から感染症にかからないための抗生剤(かなり苦い)をすりつぶしてちゅーるに混ぜてあげたところ、ものすごい勢いで完食。
術後は弱っていると思っていたが食欲があるようで安心した。🙏

ちゅーる(抗生物質入り)
爆速 pic.twitter.com/B32HKTD6IA
— ずみし (@uzimihsr) December 17, 2021

がまん

手術後は我慢の1週間だった。

そとちゃんは元気なのに、手術痕を守るためのカラーが邪魔でうまく遊べない。😢
カラーをつけた状態でできる遊びにもだんだん飽きてしまって、結局ほとんど寝て過ごしていた。

いっぱい寝ててえらい pic.twitter.com/9yw10506Wr
— ずみし (@uzimihsr) December 19, 2021

あとはトイレが大変だった。
いつもはトイレの後自分でおしりをなめてきれいにできるのに、カラーのせいで舌が届かず汚れたままになっていることが何度かあった。
ウエットタオルで拭くようにしていたが、そとちゃんはやっぱりおしりを拭かれるのが嫌いなのでちょっとかわいそうだった。😭

一番大変だったのはかゆみとの戦い。
手術痕がカラーに微妙に当たる位置で、かゆいのに舌で舐められない様子は見ていてつらそうだった。
後ろ脚の爪をカラーの隙間から無理やり入れて手術痕を掻こうとすることもあったので、なかなか目が話せなかった…

そとちゃんがずっと苦しい思いをしていたので、俺もこの1週間はほぼ家から出ずにつきっきりでみていた。
つくづく在宅勤務でよかった。

抜糸

1週間耐え抜いた後、腫瘤の検査結果が届いたとのことで再度病院へ。

抜糸できるか診てもらいにいく
いつもよりビビってる pic.twitter.com/SPE3hkiZLG
— ずみし (@uzimihsr) December 25, 2021

病理検査の結果、今回切除した腫瘤は毛包嚢胞ということで、
人間で言えばニキビとか粉瘤に近いもの?らしかった。

悪性腫瘍でなくて本当によかった…😌
完全に切除されていて再発のおそれも低いということなので、これで一安心。

手術痕もきれいにふさがっていたので、その場で抜糸してもらった。
手術と検査で病院が嫌になっちゃったのか、そとちゃんは珍しく暴れたけどなんとか無事に糸を全部外すことができた。

帰宅後、カラーが外れて7日ぶりの自由を取り戻したそとちゃんはやりたい放題。😂

抜糸成功 pic.twitter.com/qm0q0U2PbS
— ずみし (@uzimihsr) December 25, 2021

カラーが邪魔でなかなか登れなかったキャットタワーや本棚の上に昇って降りてを繰り返し、
部屋中をものすごい勢いで走り回って手がつけられなかった。🌪

ちなみにカラーがなくなって手術痕(ふさがってはいるが…)を思いっきり掻こうとしたので、
この後カラーをつけて外してを何回か繰り返した。😅

おわり

なにはともあれそとちゃんが無事で本当によかった。
手術前はごはんをもらえず、手術後はカラーをつけられてかわいそうだったがよく耐えてとてもえらかった。👏

術後の生活が大変すぎて、気がついたらクリスマスが終わっていた…
去年と違う衣装も用意していたが、手術後に着せるわけにもいかないので来年まで残しておくことにする。

今年もそとちゃんはずっと元気だったけど、最後に手術があって大変だった。
2022年はそとちゃんの健康により一層気をつけて、幸せに過ごせるようにしたい。

おまけ

Add a cronjob-name label to Kubernetes Jobs with Mutating Admission Webhook

Sat, 18 Dec 2021 00:00:00 +0000

(最後に日本語版があります)

cronjob-name labels admission webhook

Kubernetes Pods owned by Job have a job-name label, so you can easily filter Pods by the name of the owner Job with label selector.
Meanwhile, Jobs owned by CronJob don’t have such one.

# filter Pods by Job with labelSelector
$ kubectl get pod -l job-name=my-job
NAME READY STATUS RESTARTS AGE
my-job-zm4p4 0/1 Completed 0 25h

# Jobs do not have any labels related to the owner CronJob
$ kubectl get job --show-labels
NAME COMPLETIONS DURATION AGE LABELS
my-cronjob-27322002 1/1 2s 2m26s controller-uid=43e62299-838b-4f9a-96b7-e35cfc82a2ec,job-name=my-cronjob-27322002
my-cronjob-27322003 1/1 2s 86s controller-uid=56130637-ae62-42f4-b8f5-f5248c929ec0,job-name=my-cronjob-27322003
my-cronjob-27322004 1/1 3s 26s controller-uid=308090e7-2bdb-4960-bd38-ff88b3c0aaf0,job-name=my-cronjob-27322004
my-job 1/1 3s 25h controller-uid=3369540c-552b-438c-8767-8808d9c42fe6,job-name=my-job

Of course, Jobs also have a field called OwnerReferences which has the name of the owner CronJob, but it can’t be used for filtering Jobs.

# metadata.ownerReferences have the name of the owner CronJob
$ kubectl get job my-cronjob-27322004 -o jsonpath="{.metadata.ownerReferences[0].name}"
my-cronjob

# ownerReferences cannot be used to filter Job
$ kubectl get job --field-selector ".metadata.ownerReferences[0].name=my-cronjob"
Error from server (BadRequest): Unable to find "batch/v1, Resource=jobs" that match label selector "", field selector ".metadata.ownerReferences[0].name=my-cronjob": field label ".metadata.ownerReferences[0].name" not supported for Job

Therefore, when there are many Jobs in the Cluster, it is difficult to find the Jobs by the name of the owner CronJob.
Of course you can use grep or jq with kubectl, but it is sometimes not fast :(

To solve this problem, I created my own Mutating Admission Webhook for the first time.
https://github.com/uzimihsr/cronjob-name-labels-admission-webhook

# Jobs have a cronjob-name label and it can be used for filtering
$ kubectl get job -l uzimihsr.github.io/cronjob-name=my-cronjob --show-labels
NAME COMPLETIONS DURATION AGE LABELS
my-cronjob-27322012 1/1 2s 2m26s uzimihsr.github.io/cronjob-name=my-cronjob
my-cronjob-27322013 1/1 2s 86s uzimihsr.github.io/cronjob-name=my-cronjob
my-cronjob-27322014 1/1 2s 26s uzimihsr.github.io/cronjob-name=my-cronjob

Prerequisites

Kubernetes v1.21.1
kind v0.11.1
Go 1.17.3
OpenSSL 3.0.0

How it works

Mutating Admission Webhook works as an HTTP server that returns responses to admission requests and we can make it with any language.
In this case, I used the webhook example written in Go.

This HTTP server works as follows;

Convert the request body to admission.k8s.io/v1.AdmissionReview.
If the requested resource(Job) is owned by any CronJob, create a JSON Patch to add the label “uzimihsr.github.io/cronjob-name={Job.metadata.ownerReferences[0].name}”.
- You must escape / in a JSON key.
Convert the JSON Patch to admission.k8s.io/v1.AdmissionReview and return it.

The HTTP server can be located anywhere as long as it is reachable from the Kubernetes API, but I preferred to run it as Deployment in the cluster.

The TLS Secret is needed because the admission webhook requires a TLS connection between the Kubernetes API and the HTTP server.
If the HTTP server runs in the cluster, self-signed certificate is sufficient.

The ClusterIP Service exposes the Pod to the cluster.
It is referenced as "(service-name).(service-namespace).svc” from within the cluster, so the certificate of the TLS Secret must have that name as SANs.

MutatingWebhookConfiguration allows the Kubernetes API to send admission requests to the HTTP server.
It contains the conditions to send webhooks and base64-encoded CA certificate of the self-signed certificate.

How to install

The container image and manifest files are available on GitHub.

https://github.com/uzimihsr/cronjob-name-labels-admission-webhook#install

# generate a private key
openssl genrsa -out tls.key

# create a self-signed certificate
# Common Name (e.g. server FQDN or YOUR name) []:cronjob-name-labels-admission-webhook.default.svc (if you run Pod in the default namespace)
openssl req -x509 -key tls.key -out tls.crt -days 3650 -addext 'subjectAltName = DNS:cronjob-name-labels-admission-webhook.default.svc'

# create a TLS Secret
kubectl create secret tls cronjob-name-labels-admission-webhook-tls-secret --cert=tls.crt --key=tls.key

# create Deployment, Service, and MutatingWebhookConfiguration
# replace "CA_BUNDLE" in MutatingWebhookConfiguration by base64-encoded tls.crt
curl https://raw.githubusercontent.com/uzimihsr/cronjob-name-labels-admission-webhook/main/manifests/manifest.yaml \
 | sed "s/CA_BUNDLE/$(kubectl get secret cronjob-name-labels-admission-webhook-tls-secret -o jsonpath='{.data.tls\.crt}')/g" \
 | kubectl apply -f -

Once all the resources have been successfully created and the Pod is running, create some CronJobs to verify the operation.

# create some CronJobs
kubectl create cronjob cronjob-a --image=busybox --schedule="*/1 * * * *" -- date
kubectl create cronjob cronjob-b --image=busybox --schedule="*/1 * * * *" -- date
kubectl create cronjob cronjob-c --image=busybox --schedule="*/1 * * * *" -- date

# create a "normal" Job (not owned by CronJob)
kubectl create job my-job --image=busybox -- date

Wait for while and check the Jobs.

# Jobs owned by CronJob have a cronjob-name label
# The "normal" Job does not have the label
$ kubectl get job --show-labels
NAME COMPLETIONS DURATION AGE LABELS
cronjob-a-27322073 1/1 6s 2m23s uzimihsr.github.io/cronjob-name=cronjob-a
cronjob-a-27322074 1/1 5s 83s uzimihsr.github.io/cronjob-name=cronjob-a
cronjob-a-27322075 1/1 5s 23s uzimihsr.github.io/cronjob-name=cronjob-a
cronjob-b-27322073 1/1 2s 2m23s uzimihsr.github.io/cronjob-name=cronjob-b
cronjob-b-27322074 1/1 4s 83s uzimihsr.github.io/cronjob-name=cronjob-b
cronjob-b-27322075 1/1 3s 23s uzimihsr.github.io/cronjob-name=cronjob-b
cronjob-c-27322073 1/1 4s 2m23s uzimihsr.github.io/cronjob-name=cronjob-c
cronjob-c-27322074 1/1 2s 83s uzimihsr.github.io/cronjob-name=cronjob-c
cronjob-c-27322075 1/1 6s 23s uzimihsr.github.io/cronjob-name=cronjob-c
my-job 1/1 8s 23s controller-uid=27160b7f-65e0-4e48-aa6b-9319e162f422,job-name=my-job

# Wow you can filter Jobs by CronJob :)
$ kubectl get job -l uzimihsr.github.io/cronjob-name=cronjob-b
NAME COMPLETIONS DURATION AGE
cronjob-b-27322073 1/1 2s 2m39s
cronjob-b-27322074 1/1 4s 99s
cronjob-b-27322075 1/1 3s 39s

I did it. It’s working!

Finally, let’s compare the speed of filtering Jobs by the name of the CronJob with other methods.

# create 100 CronJobs
for i in $(seq -w 100); do 
 kubectl create cronjob cronjob-"${i}" --image=busybox --schedule="*/1 * * * *" -- date
done

## look for Jobs owned by the CronJob "cronjob-099" in different ways

# kubectl + grep: 0.277(kubectl) + 0.276(grep) ≃ 0.5 sec.
$ time kubectl get job | grep cronjob-099
cronjob-099-27322103 1/1 2m29s 6m33s
cronjob-099-27322104 1/1 5m35s 5m41s
cronjob-099-27322105 0/1 4m39s 4m39s
cronjob-099-27322106 0/1 3m55s 3m55s
cronjob-099-27322107 0/1 2m39s 2m39s
cronjob-099-27322108 0/1 109s 109s
cronjob-099-27322109 0/1 41s 42s
kubectl get job 0.25s user 0.04s system 105% cpu 0.277 total
grep --color=auto cronjob-099 0.00s user 0.00s system 2% cpu 0.276 total

# kubectl + jq: 0.642(kubectl) + 0.648(jq) ≃ 1.2 sec.
$ time kubectl get job -o json | jq '.items[] | select(.metadata.ownerReferences[]?.name=="cronjob-099") | .metadata.name'
"cronjob-099-27322103"
"cronjob-099-27322104"
"cronjob-099-27322105"
"cronjob-099-27322106"
"cronjob-099-27322107"
"cronjob-099-27322108"
"cronjob-099-27322109"
kubectl get job -o json 0.70s user 0.06s system 117% cpu 0.642 total
jq 0.08s user 0.01s system 13% cpu 0.648 total

# Label Selector "uzimihsr.github.io/cronjob-name" : ≃ 0.1 sec.
$ time kubectl get job -l uzimihsr.github.io/cronjob-name=cronjob-099
NAME COMPLETIONS DURATION AGE
cronjob-099-27322103 1/1 2m29s 6m40s
cronjob-099-27322104 1/1 5m35s 5m48s
cronjob-099-27322105 0/1 4m46s 4m46s
cronjob-099-27322106 0/1 4m2s 4m2s
cronjob-099-27322107 0/1 2m46s 2m46s
cronjob-099-27322108 0/1 116s 116s
cronjob-099-27322109 0/1 48s 49s
cronjob-099-27322110 0/1 1s 1s
kubectl get job -l uzimihsr.github.io/cronjob-name=cronjob-099 0.08s user 0.03s system 113% cpu 0.094 total

Wow the label added by Mutating Admission Webhook makes it so fast to filter Jobs by the name of owner CronJob!

Thank you for reading :)

(the following is the Japanese version.)

つくったもの

KubernetesのJobで起動したPodにはjob-nameというラベルがついている。
これにより、“hogehogeというJobで起動されているPodの一覧が欲しい"といったときはKubernetes APIへのリクエスト時にlabelSelectorを指定することで絞り込みができる。

# job-nameラベルを用いたPodの絞り込み
$ kubectl get pod -l job-name=my-job
NAME READY STATUS RESTARTS AGE
my-job-zm4p4 0/1 Completed 0 25h

しかし、CronJobによって起動されたJobにはそのようなラベルがなく、
“fugafugaというCronJobで起動されているJobの一覧が欲しい"というときに不便。

# JobにはCronJob名のラベルがない
$ kubectl get job --show-labels
NAME COMPLETIONS DURATION AGE LABELS
my-cronjob-27322002 1/1 2s 2m26s controller-uid=43e62299-838b-4f9a-96b7-e35cfc82a2ec,job-name=my-cronjob-27322002
my-cronjob-27322003 1/1 2s 86s controller-uid=56130637-ae62-42f4-b8f5-f5248c929ec0,job-name=my-cronjob-27322003
my-cronjob-27322004 1/1 3s 26s controller-uid=308090e7-2bdb-4960-bd38-ff88b3c0aaf0,job-name=my-cronjob-27322004
my-job 1/1 3s 25h controller-uid=3369540c-552b-438c-8767-8808d9c42fe6,job-name=my-job

一応Jobはmetadata.ownerReferencesというフィールドにどのCronJobによって作成されたかの情報を持っているのだが、
このフィールドはfieldSelectorに対応していないので少し使いづらい。

# metadata.ownerReferencesには一応CronJobの情報がある
$ kubectl get job my-cronjob-27322004 -o jsonpath="{.metadata.ownerReferences[0].name}"
my-cronjob

# fieldSelectorで指定しようとするとエラーになる
$ kubectl get job --field-selector ".metadata.ownerReferences[0].name=my-cronjob"
Error from server (BadRequest): Unable to find "batch/v1, Resource=jobs" that match label selector "", field selector ".metadata.ownerReferences[0].name=my-cronjob": field label ".metadata.ownerReferences[0].name" not supported for Job

このため、CronJobを大量に使っているときに調べたい対象のJobを絞るのが面倒で困っていた。
…だったら自分でcronjob-name的なラベルをつけちゃえば良いのでは? と思い、
最近勉強しているadmission webhookを使って実現してみた。

https://github.com/uzimihsr/cronjob-name-labels-admission-webhook

# JobにCronJob名のラベルがついたのでlabelSelectorで絞り込める
$ kubectl get job -l uzimihsr.github.io/cronjob-name=my-cronjob --show-labels
NAME COMPLETIONS DURATION AGE LABELS
my-cronjob-27322012 1/1 2s 2m26s uzimihsr.github.io/cronjob-name=my-cronjob
my-cronjob-27322013 1/1 2s 86s uzimihsr.github.io/cronjob-name=my-cronjob 
my-cronjob-27322014 1/1 2s 26s uzimihsr.github.io/cronjob-name=my-cronjob

環境

Kubernetes v1.21.1
kind v0.11.1
Go 1.17.3
OpenSSL 3.0.0

しくみ

今回は下記のような構成でつくってみた。

まずは決められた形式のリクエストに対してレスポンスを返すHTTPサーバーをDeploymentとして立てる。
Mutating Admission Webhookでラベルを付与する処理はGoで書かれた公式の例を参考にした。

このサーバーの処理の流れとしては

リクエストボディをadmission.k8s.io/v1.AdmissionReviewにパース
リクエストされているリソース(Job)のObjectをチェックし、対象のリソースがCronJobによって作成されている場合のみ “uzimihsr.github.io/cronjob-name=(CronJob名)” のラベルを付与するJSON Patchを作成
- 今回はラベルのキーに/が含まれるので、keyの指定方法に気をつけた
作成したJSONパッチをadmission.k8s.io/v1.AdmissionReviewに詰めて返す

といった感じ。

また、admission webhookでは対象のエンドポイントとの通信がTLS化されている必要があるので、
オレオレ証明書のTLS Secretを用意してPodにマウントして使用する。

Deploymentが作成できたら、そのPodをClusterIP Serviceでクラスタ内に公開する。
このときクラスタ内から参照するホスト名が "(service-name).(service-namespace).svc” となるので、前述のTLS SecretのTLS証明書のSANsがこの名前を含む必要がある。

最後にMutatingWebhookConfigurationを作成すると、
Kubernetes APIが指定されたAPIオブジェクトを操作するときに指定されたService宛にwebhookするようになる。
今回はオレオレ証明書を使用しているので、信頼するCA証明書(すなわちオレオレ証明書そのもの)をbase64エンコードしたものをwebhooks.clientConfig.caBundleに指定する。

つかいかた

Deployment用のimageと各種yamlファイルはGitHubに用意しているので、
あとはTLS証明書用のSecretさえ用意すれば動くはず。

https://github.com/uzimihsr/cronjob-name-labels-admission-webhook#install

# 秘密鍵の作成
openssl genrsa -out tls.key

# オレオレ証明書の作成
# Common Name (e.g. server FQDN or YOUR name) []:cronjob-name-labels-admission-webhook.default.svc とする
openssl req -x509 -key tls.key -out tls.crt -days 3650 -addext 'subjectAltName = DNS:cronjob-name-labels-admission-webhook.default.svc'

# TLS Secretの作成
kubectl create secret tls cronjob-name-labels-admission-webhook-tls-secret --cert=tls.crt --key=tls.key

# Deployment, Service, MutatingWebhookConfigurationの作成
# MutatingWebhookConfigurationのcaBundlerはbase64化したtls.crtを指定する
curl https://raw.githubusercontent.com/uzimihsr/cronjob-name-labels-admission-webhook/main/manifests/manifest.yaml \
 | sed "s/CA_BUNDLE/$(kubectl get secret cronjob-name-labels-admission-webhook-tls-secret -o jsonpath='{.data.tls\.crt}')/g" \
 | kubectl apply -f -

すべてのリソースが作成できたら、動作確認用のCronJobを作成する。

# CronJobの作成
kubectl create cronjob cronjob-a --image=busybox --schedule="*/1 * * * *" -- date
kubectl create cronjob cronjob-b --image=busybox --schedule="*/1 * * * *" -- date
kubectl create cronjob cronjob-c --image=busybox --schedule="*/1 * * * *" -- date

# CronじゃないJobの作成
kubectl create job my-job --image=busybox -- date

すこし放置して、Jobが起動したら結果を確認する。

# JobにCronJob名のラベルがついている
# 手動で作ったJobのラベルはデフォルトのまま
$ kubectl get job --show-labels
NAME COMPLETIONS DURATION AGE LABELS
cronjob-a-27322073 1/1 6s 2m23s uzimihsr.github.io/cronjob-name=cronjob-a
cronjob-a-27322074 1/1 5s 83s uzimihsr.github.io/cronjob-name=cronjob-a
cronjob-a-27322075 1/1 5s 23s uzimihsr.github.io/cronjob-name=cronjob-a
cronjob-b-27322073 1/1 2s 2m23s uzimihsr.github.io/cronjob-name=cronjob-b
cronjob-b-27322074 1/1 4s 83s uzimihsr.github.io/cronjob-name=cronjob-b
cronjob-b-27322075 1/1 3s 23s uzimihsr.github.io/cronjob-name=cronjob-b
cronjob-c-27322073 1/1 4s 2m23s uzimihsr.github.io/cronjob-name=cronjob-c
cronjob-c-27322074 1/1 2s 83s uzimihsr.github.io/cronjob-name=cronjob-c
cronjob-c-27322075 1/1 6s 23s uzimihsr.github.io/cronjob-name=cronjob-c
my-job 1/1 8s 23s controller-uid=27160b7f-65e0-4e48-aa6b-9319e162f422,job-name=my-job

# labelSelectorを使った絞り込みができる
$ kubectl get job -l uzimihsr.github.io/cronjob-name=cronjob-b
NAME COMPLETIONS DURATION AGE
cronjob-b-27322073 1/1 2s 2m39s
cronjob-b-27322074 1/1 4s 99s
cronjob-b-27322075 1/1 3s 39s

CronJobから作成されたJobに所望のラベルが追加されていて、ラベルを用いた絞り込みができることを確認できた。

最後に、CronJobから作られたJobを絞り込む際の速度を他の方法と比較してみる。

# CronJobが100個稼働している状態
for i in $(seq -w 100); do 
 kubectl create cronjob cronjob-"${i}" --image=busybox --schedule="*/1 * * * *" -- date
done

## 色んな方法でcronjob-099のJobを探してみる

# 愚直にgrepするとkubectlで0.277+grepで0.276==約0.5秒かかる
$ time kubectl get job | grep cronjob-099
cronjob-099-27322103 1/1 2m29s 6m33s
cronjob-099-27322104 1/1 5m35s 5m41s
cronjob-099-27322105 0/1 4m39s 4m39s
cronjob-099-27322106 0/1 3m55s 3m55s
cronjob-099-27322107 0/1 2m39s 2m39s
cronjob-099-27322108 0/1 109s 109s
cronjob-099-27322109 0/1 41s 42s
kubectl get job 0.25s user 0.04s system 105% cpu 0.277 total
grep --color=auto cronjob-099 0.00s user 0.00s system 2% cpu 0.276 total

# jqとの組み合わせ技だとkubectlで0.642+jqで0.648=約1.2秒...
$ time kubectl get job -o json | jq '.items[] | select(.metadata.ownerReferences[]?.name=="cronjob-099") | .metadata.name'
"cronjob-099-27322103"
"cronjob-099-27322104"
"cronjob-099-27322105"
"cronjob-099-27322106"
"cronjob-099-27322107"
"cronjob-099-27322108"
"cronjob-099-27322109"
kubectl get job -o json 0.70s user 0.06s system 117% cpu 0.642 total
jq 0.08s user 0.01s system 13% cpu 0.648 total

# webhookで付与したラベルを使うと約0.1秒で済む
$ time kubectl get job -l uzimihsr.github.io/cronjob-name=cronjob-099
NAME COMPLETIONS DURATION AGE
cronjob-099-27322103 1/1 2m29s 6m40s
cronjob-099-27322104 1/1 5m35s 5m48s
cronjob-099-27322105 0/1 4m46s 4m46s
cronjob-099-27322106 0/1 4m2s 4m2s
cronjob-099-27322107 0/1 2m46s 2m46s
cronjob-099-27322108 0/1 116s 116s
cronjob-099-27322109 0/1 48s 49s
cronjob-099-27322110 0/1 1s 1s
kubectl get job -l uzimihsr.github.io/cronjob-name=cronjob-099 0.08s user 0.03s system 113% cpu 0.094 total

ラベルをつけたおかげでCronJobのJobがそこそこ速く絞り込めるようになった。
やったぜ。

おわり

admission webhookを自分で作って動かしてみた。
いい勉強になったし、自分で使う上でもそこそこ便利なものができたと思っている。

カッコつけてそれっぽくリポジトリをつくったものの、まだテストが書けてなかったりするので暇なときにちょくちょく修正していきたい。

おまけ

11月のそとちゃん(2021)

Mon, 06 Dec 2021 00:00:00 +0000

まとめ

ひざ上占拠ちゃん
箱がアツい
病院

ひざ上占拠ちゃん

通算n度目のひざブームがきた。

俺がソファでだらだらしてるとだいたい乗っかってくる。

乗り pic.twitter.com/Zozm0vMcf1
— ずみし (@uzimihsr) November 14, 2021

そとちゃんに乗られるとねこを撫でる/スマホをいじる以外の行動が封じられてとても幸せ。

ただし少しでも脚が動けば機嫌を損ねてしまう…

勝手に乗ってきてイカ耳されるの納得いかない pic.twitter.com/lvRsdEwgpl
— ずみし (@uzimihsr) November 27, 2021

乗ってきたからと言って必ずしも撫でられたいわけでもないらしい。

むずかしい…
(ひざの上で寝返りされるとめっちゃ嬉しい)

ねこ撫でたら反撃された pic.twitter.com/0LP3CEd008
— ずみし (@uzimihsr) November 28, 2021

ソファにこだわりがある訳でもないらしく、仕事用のイスに座ってるときでも乗ってくる。

イスの場合はちょっと高さがあるので万が一落ちたら怖いが、
そとちゃんはそんなのお構いなしで自由に動いてしまう。

ヒトの膝の安定感を信用しすぎている(毛づくろい中) pic.twitter.com/ZvyIcN0NCC
— ずみし (@uzimihsr) November 16, 2021

自由すぎて寝ちゃうときもある。

寝た pic.twitter.com/Q4rheVsyQr
— ずみし (@uzimihsr) November 5, 2021

超かわいい。

(なお、長いときは1時間くらいそのまま動かないので脚が死ぬ😇)

箱がアツい

箱より袋派のそとちゃん。

最近しもべがお高いものを買わないせいで紙袋の供給が減ってピンチ!

とはならず、袋がないときは箱でも十分楽しめるみたい。

横向きの箱に入って待ち構えたところに俺がねずみのおもちゃを投げてそれをしばくのが流行っている。

これ5回くらいやってる pic.twitter.com/f6hfKLFsLP
— ずみし (@uzimihsr) November 5, 2021

ねずみをしばく、箱に隠れる、ねずみをしばく、をエンドレスに繰り返す。

野良だったころの狩りの動きに近くて楽しいのかも？

横着して箱から出ずにねずみをしばくだけのパターンもある。

ゴールキーパー pic.twitter.com/NuNUXIlcQT
— ずみし (@uzimihsr) November 15, 2021

逆に箱に入っていくねずみを追いかけてしばくときもある。

結局横向きの箱とねずみがあれば何でも楽しいらしい。

箱めっちゃたのしい pic.twitter.com/tsy2BTjJES
— ずみし (@uzimihsr) November 18, 2021

今まで使ってた引っ越しダンボールはそとちゃんにはちょっと大きくて、

最近しもべが食べ始めたnoshの宅配ダンボールがちょうどそとちゃんサイズにフィットしていてかわいい。

横向きの箱は入る率高い pic.twitter.com/5h0KAFRbVv
— ずみし (@uzimihsr) November 15, 2021

そとちゃんも広すぎるダンボールよりはちょっと狭い方が好きみたい。

たのしそう pic.twitter.com/QI1FYWBvx4
— ずみし (@uzimihsr) November 26, 2021

新しいダンボールにお熱なうちに古い引っ越しダンボールはこっそり捨ててしまいたい…
(たぶん無理)

病院

そとちゃんがやたらとお出かけしたがっていたのと、
前回見つかった首のしこりがちょっと大きくなってきた気がしたので9月以来の病院に行ってきた。

病院いく pic.twitter.com/SlS3EaY6IG
— ずみし (@uzimihsr) November 23, 2021

触診の結果やはりしこりが大きくなっていて、
前回はヒトの小指の先くらいのサイズだったのが今回は人差し指くらいの太さになっていた。

その場で超音波検査をしてもらい、
(検査のために先生に両手両足をガッツリ掴まれてブーブー文句言ってる姿がちょっとかわいそうだけど面白かった)

エコーを診たところ水が溜まっているとかではなく固形の腫瘤ができていた。😱

超音波検査だけではこの腫瘤が良性か悪性かは判定できないとのことで、
先生から2つの対応を提案してもらった。

注射針を入れて腫瘤の一部を吸い取って化学検査
外科手術での切除

前者はある程度様子見、後者は全身麻酔のリスクがある方法。

今の所は腫瘤を触っても痛そうにする素振りがないので問題なさそうだが、
これが良性にしろ悪性にしろこのまま大きくなり続けると血管を圧迫する恐れがあるということで今回は腫瘤を切除してもらうことになった。

スケジュールの都合で手術は少し先の12/17に行うことが決まり、見積もりも出してもらった。

自分が外科手術をしてもらったことがないので全身麻酔についてよくわかっていないのと、
さらにそれが小さいそとちゃんのこととなると正直不安でしょうがない。

めちゃめちゃ怖いけど、
手術の内容について繰り返し質問しても優しく答えてくれた先生の人柄と、
避妊手術で一度お腹を切っているそとちゃんの強さを信じることにした。

腫瘤以外の話だと、
下痢対策で引っ越す前の病院に勧めてもらった療法食のカリカリを食べ続けても問題ないか聞いたところ、
この療法食の場合は必要な栄養素が充分含まれていて、問題になる成分がないので食べ続けて問題ないとのことだった。
手術のことで混乱していて、歯肉炎の状態を診てもらうのは忘れてしまった。

病院大好きなそとちゃんも今回の超音波検査は嫌だったみたいで、
帰るときはちょっと元気がなくておとなしかった。

がんばってえらかったので家に帰ってすぐおやつをあげた。
爪が刺さってめちゃ痛かった。

病院がんばった pic.twitter.com/jyouQMh30d
— ずみし (@uzimihsr) November 23, 2021

おわり

最近は手術が心配で毎晩寝る前にそとちゃんに大丈夫か聞いてるけど「にゃん」しか言わない。
たぶんなにもわかってなさそう…

とりあえず無事を祈ってお守りを買ってこようと思う。

おまけ

Kubernetes Podが生きている間にNamespaceとかServiceAccountを消すとどうなるの?

Sun, 28 Nov 2021 00:00:00 +0000

まとめ

あんまりやる機会はないだろうけど、
Podが生きている間にそれに紐づくNamespaceとServiceAccountを削除したときの挙動は次のようになる。

Podが生きている間にmetadata.namespaceのNamespaceを削除した場合
- Podが削除される
Podが生きている間にspec.serviceAccountNameのServiceAccountを削除した場合
- Podは削除されない
- 自動マウントされたServiceAccount Tokenはそのまま残る
  - ただしServiceAccountが削除された時点でKubenretes APIの認証が通らなくなる

環境

kind
- v0.11.1 go1.17.3 darwin/amd64
Kubernetes
- v1.21.1

# じゅんび
$ kubectl create namespace space-1
$ kubectl -n space-1 create serviceaccount user-1 
$ kubectl -n space-1 run nginx --image=nginx --overrides='{ "spec": { "serviceAccountName" : "user-1" } }'

# Namespace: space-1でspec.serviceAccountName: user-1のPodが動いている状態
$ kubectl -n space-1 get pod nginx
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 15s
$ kubectl -n space-1 get pod nginx -o jsonpath="{.spec.serviceAccountName}"
user-1

# Podが動いてるNamespace消す
$ kubectl delete namespace space-1
namespace "space-1" deleted

# どこにもPodが残ってない
$ kubectl get pod -A | grep -c nginx
0

Namespaceを削除すると、動いているPodがあっても一緒に削除されるらしい。

ServiceAccount消す

今度はPodのspec.serviceAccountNameに指定されたServiceAccountをPodが生きている間に消してみる。

# さっきと同じ状態
$ kubectl -n space-1 get pod nginx
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 15s
$ kubectl -n space-1 get pod nginx -o jsonpath="{.spec.serviceAccountName}"
user-1
$ kubectl -n space-1 get serviceaccount user-1
NAME SECRETS AGE
user-1 1 75s

# Podに紐付いてるServiceAccount消す
$ kubectl -n space-1 delete serviceaccount user-1
serviceaccount "user-1" deleted

# Podは生きてる上にserviceAccountNameもそのまま
$ kubectl -n space-1 get pod nginx
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 2m46s
$ kubectl -n space-1 get pod nginx -o jsonpath="{.spec.serviceAccountName}"
user-1

# PodにマウントされているServiceAccount Tokenは削除したServiceAccountのものが残っている
$ kubectl -n space-1 get pod nginx -o jsonpath="{.spec.volumes}"
[{"name":"kube-api-access-fdd7d","projected":{"defaultMode":420,"sources":[{"serviceAccountToken":{"expirationSeconds":3607,"path":"token"}},{"configMap":{"items":[{"key":"ca.crt","path":"ca.crt"}],"name":"kube-root-ca.crt"}},{"downwardAPI":{"items":[{"fieldRef":{"apiVersion":"v1","fieldPath":"metadata.namespace"},"path":"namespace"}]}}]}}]
$ kubectl -n space-1 exec nginx -it -- cat /var/run/secrets/kubernetes.io/serviceaccount/token | jq -R 'split(".") | .[1] | @base64d | fromjson | ."kubernetes.io"'
{
 "namespace": "space-1",
 "pod": {
 "name": "nginx",
 "uid": "c1595cec-699d-41dd-bb51-6f648b23e832"
 },
 "serviceaccount": {
 "name": "user-1",
 "uid": "e1d20d3d-5f9f-4ab0-b8e0-d021a42d189c"
 },
 "warnafter": 1637856366
}

なるほど…?

Podのspec.serviceAccountNameに指定されたServiceAccountが削除されてもPodは消されることはなく、
volumeとしてコンテナにマウントされたServiceAccount Tokenもそのままの状態で残るらしい。

じゃあそのTokenを使ったKubernetes APIの認証/認可はどうなるんだろう?

# またまたさっきと同じ状態
$ kubectl -n space-1 get pod nginx
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 15s
$ kubectl -n space-1 get pod nginx -o jsonpath="{.spec.serviceAccountName}"
user-1
$ kubectl -n space-1 get serviceaccount user-1
NAME SECRETS AGE
user-1 1 75s

# user-1にspace-1のPod操作権限を付与
$ kubectl -n space-1 create role pod-owner --verb="*" --resource="pods"
$ kubectl -n space-1 create rolebinding pod-owner-bind --role=pod-owner --serviceaccount=space-1:user-1

# この状態でServiceAccount Tokenを用いてKubernetes APIをたたくと成功(200 OK)する
$ kubectl -n space-1 exec nginx -it -- bash -c 'curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt --header "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" -I -X GET https://kubernetes.default.svc/api/v1/namespaces/space-1/pods'
HTTP/2 200
...

# ServiceAccountを削除
$ kubectl -n space-1 delete serviceaccount user-1

# Podに残ったServiceAccount Tokenを用いてKubernetes APIをたたくと失敗(401 Unauthorized)する
$ kubectl -n space-1 exec nginx -it -- bash -c 'curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt --header "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" -I -X GET https://kubernetes.default.svc/api/v1/namespaces/space-1/pods'
HTTP/2 401
...

# 同名のServiceAccountを再作成
$ kubectl -n space-1 create serviceaccount user-1

# しかし結果は変わらず
$ kubectl -n space-1 exec nginx -it -- bash -c 'curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt --header "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" -I -X GET https://kubernetes.default.svc/api/v1/namespaces/space-1/pods'
HTTP/2 401
...

はえ〜

ServiceAccountが削除された時点でTokenでの認証ができなくなるみたい。
後から同名のServiceAccountを作ってもたぶんTokenのuidが新しいServiceAccountと合わないから認証ができないんじゃないかな…?

ちなみにkubectl edit podでspec.serviceAccountNameをいじろうとすると

Forbidden: pod updates may not change fields other than `spec.containers[*].image`, `spec.initContainers[*].image`, `spec.activeDeadlineSeconds` or `spec.tolerations` (only additions to existing tolerations)`

って怒られちゃうので、
Podが生きてる間にServiceAccountを消してしまった場合はそのTokenでのAPI認証は諦めてPodを作り直すのがよさそう。
(というかPodが生きているうちはあまり消さないほうがいい)

おわり

こんなことは普段仕事でKubernetesを運用しているときは絶対やらないとは思うけど、すこし気になったので試してみた。

NamespaceもServiceAccountもPodを巻き添えにして削除されるものだと思いこんでいたので、
ServiceAccountが消えてもPodとマウントされたTokenが残るのは勉強になった。

おまけ

10月のそとちゃん(2021)

Mon, 08 Nov 2021 00:00:00 +0000

まとめ

歯みがき
まるい?
ハロウィン

歯みがき

やっぱり歯みがきが嫌い。

この世の全てに絶望して引きこもった(はみがきが嫌) pic.twitter.com/OKWGazGWnw
— ずみし (@uzimihsr) October 21, 2021

9月に病院で診てもらってからは薬を塗らない日も毎日歯みがきをするようになったんだけど、
歯肉炎になってる右の奥歯に触れられるのがどうしても嫌みたい。

ふだんはやさしくて滅多に怒らないそとちゃんでもこのときだけは手加減なしで暴れてくるのでひどいときは(俺が)流血沙汰になる。

それでも最後は抵抗虚しく捕まえられて歯みがきと塗り薬をやられて拗ねちゃう。

抵抗むなしく歯みがきされて拗ねてる pic.twitter.com/CPtY0LJqGZ
— ずみし (@uzimihsr) October 17, 2021

(あんまり怒り慣れてないからいじけ方もぎこちなくてちょっとかわいい)

歯肉炎の塗り薬は処方されたぶんをしっかり使い終わって、9月のはじめよりもちょっと赤みが引いたような気もする。

近いうちにまた病院で診てもらいたい。　　

まるい?

ちょっと寒くなってきたのか、そとちゃんがまるくなっていることが増えた。

まるい pic.twitter.com/kppQydVKzb
— ずみし (@uzimihsr) October 1, 2021

まるくなった pic.twitter.com/tfgERaqHAN
— ずみし (@uzimihsr) October 6, 2021

でもまるくないときもある。

まるくない pic.twitter.com/FaIo4SFUkd
— ずみし (@uzimihsr) October 6, 2021

ぴーぴー言いながら寝てる pic.twitter.com/rCTVPBzljc
— ずみし (@uzimihsr) October 28, 2021

…というかまるくないことのほうが多いかもしれない。

最近まるくないことのほうが多い pic.twitter.com/Z88hN28lPA
— ずみし (@uzimihsr) October 8, 2021

たまに四角いときもある。

もはやちょっと四角い pic.twitter.com/Lq1cEji2c8
— ずみし (@uzimihsr) October 28, 2021

毎日おもしろい寝かたをしているので見ていて飽きない。
かわいい。

ハロウィン

今年もそとちゃんにハロウィンの仮装をしてもらった。

ドラキュラマント#HappyHalloween2021 pic.twitter.com/DxTVkM6xLI
— ずみし (@uzimihsr) October 31, 2021

例年(嫌々ながら)着てもらっていたドラキュラマントに加えて、今年はこうもりポンチョもご用意させていただいた。

これがまたバチクソにかわいい。

こうもりポンチョ#HappyHalloween2021 pic.twitter.com/u3r6HBFzU2
— ずみし (@uzimihsr) October 31, 2021

本当は小型犬用の服なんだけど、頭からかぶってボタンで留めるだけなのでそとちゃんでも着られた。
(手を通すタイプだとめちゃくちゃ嫌がる)

でも最後は自分で脱いじゃった。

脱ぐ pic.twitter.com/eP6mv2Heuz
— ずみし (@uzimihsr) November 1, 2021

逆にドラキュラマントはそんなに気にならないみたいで、脱がずにずっとウロウロしていた。
(着たままトイレしようとしたので流石に脱がせた)

俺のわがままに付き合ってもらったので、最後はちゃんと報酬を支払った。
(耳がでてくるとこが最高にかわいい)

おやつ pic.twitter.com/x56SDNygRO
— ずみし (@uzimihsr) November 1, 2021

クリスマスもまたかわいい服を着てもらいたい。

おわり

そとちゃんは10月も元気によく遊んでよく寝るいい子だった。

歯みがきでどれだけ不機嫌になっても絶対に"シャーッ!“とか"フーッ!“って怒ることがないので(暴れはする)、
そとちゃんが保護されるまで関わってきた周りのねこもみんな優しい性格で、そとちゃんは怒りの表現を知らないまま成猫になったのかな…と思ったりもした。

そろそろ本格的に寒くなってくるころなので、暖かくして幸せに過ごせるようにしたい。

おまけ

kubeadmで作ったクラスタにNGINX Ingress Controllerを入れる

Thu, 28 Oct 2021 00:00:00 +0000

やったことのまとめ

自分は普段マネージドKubernetesばかり使っていて、当たり前のようにIngressを使ってアプリをクラスタ外に公開している。
でもよくよく考えるとIngressが使えるのはクラスタの管理者がIngress Controllerを用意してくれているからで、
今までそれ自体を自分で設定したことはなかった。

仕事でこれだけKubernetes触ってるのにIngress Controllerを設定したことがないのは流石に恥ずかしいと思い、
kubeadmで作った自前のクラスタにNGINX Ingress Controllerを設定して、サービスがクラスタ外に公開できるところまで試した。

kubeadmで作った自前クラスタにingress-nginx(NGINX Ingress Controller)を入れてNodePort Serviceで動かした
Ingress Classの設定をした
MetalLBを使ってingress-nginxをLoadBalancer Serviceで動かした

つかうもの

Ubuntu 20.04.3 LTS (GNU/Linux 5.11.0-1020-gcp x86_64)
containerd 1.4.11
Calico v3.20.2
Kubernetes v1.22.2
NGINX Ingress controller v1.0.4
MetalLB 0.10.3

やったこと

自前クラスタの作成
ingress-nginxのインストール(NodePort)
動作確認(NodePort)
MetalLBのインストール
ingress-nginxのインストール(with MetalLB)
動作確認(with MetalLB)

自前クラスタの作成

前回作ったクラスタをそのまま使う。

$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
kubernetes-master Ready control-plane,master 5m56s v1.22.2 10.240.0.2 <none> Ubuntu 20.04.3 LTS 5.11.0-1020-gcp containerd://1.4.11
kubernetes-worker Ready <none> 3m30s v1.22.2 10.240.0.3 <none> Ubuntu 20.04.3 LTS 5.11.0-1020-gcp containerd://1.4.11

$ kubectl get deploy -A
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
calico-apiserver calico-apiserver 1/1 1 1 5m15s
calico-system calico-kube-controllers 1/1 1 1 6m16s
calico-system calico-typha 2/2 2 2 6m17s
kube-system coredns 2/2 2 2 7m27s
tigera-operator tigera-operator 1/1 1 1 6m24s

$ kubectl get ds -A
NAMESPACE NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
calico-system calico-node 2 2 2 2 2 kubernetes.io/os=linux 6m36s
kube-system kube-proxy 2 2 2 2 2 kubernetes.io/os=linux 7m46s

$ kubectl get service -A
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
calico-apiserver calico-api ClusterIP 10.96.0.75 <none> 443/TCP 6m2s
calico-system calico-kube-controllers-metrics ClusterIP 10.97.190.112 <none> 9094/TCP 6m27s
calico-system calico-typha ClusterIP 10.97.47.173 <none> 5473/TCP 7m4s
default kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 8m16s
kube-system kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 8m14s

$ kubectl get ingress -A
No resources found

ingress-nginxのインストール(NodePort)

Ingress Controllerにはいくつか種類があるが、Kubernetes公式でサポートされている中ではNGINX Ingress Controllerが自前クラスタに使えそう。

公式の手順に従ってインストールしてみる。

# https://kubernetes.github.io/ingress-nginx/deploy/#bare-metal
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.4/deploy/static/provider/baremetal/deploy.yaml

今回の手順だとクラスタ外のロードバランサーを用意していないので、Ingress Controller自体がNodePort Serviceでクラスタ外からのリクエストを受けてIngressのルールに則ったトラフィックの振り分けを行うらしい。

# Ingress ControllerのDeploymentが立っている
$ kubectl -n ingress-nginx get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
ingress-nginx-controller 1/1 1 1 7m34s
$ kubectl -n ingress-nginx get pods --field-selector=status.phase=Running -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
ingress-nginx-controller-644555766d-4pwm2 1/1 Running 0 7m8s 192.168.231.195 kubernetes-worker <none> <none>
$ kubectl -n ingress-nginx exec -it ingress-nginx-controller-644555766d-4pwm2 -- /nginx-ingress-controller --version
-------------------------------------------------------------------------------
NGINX Ingress controller
 Release: v1.0.4
 Build: 9b78b6c197b48116243922170875af4aa752ee59
 Repository: https://github.com/kubernetes/ingress-nginx
 nginx version: nginx/1.19.9

-------------------------------------------------------------------------------

# Ingress Controller自体がNodePort Serviceで公開されている
$ kubectl -n ingress-nginx get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx-controller NodePort 10.104.81.185 <none> 80:31862/TCP,443:30703/TCP 8m29s
ingress-nginx-controller-admission ClusterIP 10.98.56.107 <none> 443/TCP 8m29s

$ kubectl -n ingress-nginx describe service ingress-nginx-controller
Name: ingress-nginx-controller
Namespace: ingress-nginx
Labels: app.kubernetes.io/component=controller
 app.kubernetes.io/instance=ingress-nginx
 app.kubernetes.io/managed-by=Helm
 app.kubernetes.io/name=ingress-nginx
 app.kubernetes.io/version=1.0.4
 helm.sh/chart=ingress-nginx-4.0.6
Annotations: <none>
Selector: app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx
Type: NodePort
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.104.81.185
IPs: 10.104.81.185
Port: http 80/TCP
TargetPort: http/TCP
NodePort: http 31862/TCP
Endpoints: 192.168.231.195:80
Port: https 443/TCP
TargetPort: https/TCP
NodePort: https 30703/TCP
Endpoints: 192.168.231.195:443
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>

動作確認(NodePort)

Ingress Controllerが用意できたので、適当なPodとIngressを用意して動作を確認する。
手順はKubernetes公式のものを一部改変して試した。

# 動作確認用Deployment, Service, Ingressの作成
kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0 --port=8080
kubectl expose deployment web --port=8080
kubectl create ingress example-ingress --rule="hello-world.info/*=web:8080"

作成したリソースはこんな感じ。

$ kubectl get pods -l app=web -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
web-7c884bf475-tt9g6 1/1 Running 0 8m21s 192.168.231.196 kubernetes-worker <none> <none>

$ kubectl get service web -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
web ClusterIP 10.99.167.187 <none> 8080/TCP 6m7s app=web

# ちょっとあやしい...?
$ kubectl describe ingress example-ingress
Name: example-ingress
Namespace: default
Address:
Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
 Host Path Backends
 ---- ---- --------
 hello-world.info
 / web:8080 (192.168.231.196:8080)
Annotations: <none>
Events: <none>

試しにmaster nodeからクラスタを介さずIngress経由で疎通できるか試してみる。
インストール後に確認したようにIngress Controller自体がNodePort Serviceで公開されているので、そこにリクエストを飛ばす。

# <nodeのIP>:<NodePort>にリクエストしたけどダメ...
$ curl -H "Host: hello-world.info" 10.240.0.3:31862/
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

は？失敗したんだが😭

どうやら作ったIngressにIngress Classの指定がないのでIngress Controllerに認識されてないっぽい。
(1クラスタに複数のIngress Controllerが存在することがあるので、Ingress Classが指定されていないといろいろ問題になる)

対応方法としては

Ingress作成時にspec.ingressClassNameフィールドを指定する
Ingress Classにアノテーションをつけてデフォルト設定にするのどちらかだと思う。

今回はデフォルトIngress Classを設定する方法を試してみる。

# Ingress Classにアノテーションをつけてデフォルト設定にする
kubectl annotate ingressclass nginx ingressclass.kubernetes.io/is-default-class=true

# ingressを作り直す
kubectl delete ingress example-ingress
kubectl create ingress example-ingress --rule="hello-world.info/*=web:8080"

# (optional)IngressClassのデフォルト設定をしない場合は--classでIngressClassを指定する
kubectl create ingress example-ingress --class=nginx --rule="hello-world.info/*=web:8080"

Ingress Classの設定をした上で再度挑戦してみる。

# アノテーションがついている
$ kubectl describe ingressclass nginx
Name: nginx
Labels: app.kubernetes.io/component=controller
 app.kubernetes.io/instance=ingress-nginx
 app.kubernetes.io/managed-by=Helm
 app.kubernetes.io/name=ingress-nginx
 app.kubernetes.io/version=1.0.4
 helm.sh/chart=ingress-nginx-4.0.6
Annotations: ingressclass.kubernetes.io/is-default-class: true
Controller: k8s.io/ingress-nginx
Events: <none>

# さっきと違ってIngress Controllerに認識されてそう
$ kubectl describe ingress example-ingress
Name: example-ingress
Namespace: default
Address: 10.240.0.3
Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
 Host Path Backends
 ---- ---- --------
 hello-world.info
 / web:8080 (192.168.231.196:8080)
Annotations: <none>
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal Sync 2m8s (x2 over 2m12s) nginx-ingress-controller Scheduled for sync

# 今度は疎通できる
$ curl -H "Host: hello-world.info" 10.240.0.3:31862/
Hello, world!
Version: 1.0.0
Hostname: web-7c884bf475-tt9g6

今度はちゃんとIngress経由で通信できた。🎉
やったぜ。

MetalLBのインストール

とはいえやっぱりクラスタ外からアクセスするときにデカいポートをいちいち指定するのはしんどい。
次はNodePort ServiceではなくLoadBalancer Serviceを使って普通のポートでトラフィックを受けられるようにしてみる。

NGINX Ingress Controllerのドキュメントによると、クラウドプロバイダで管理されていないベアメタルクラスタでもMetalLBを導入すればLoadBalancer Serviceが使えるようになるらしい。

# NodePort版Ingress Controllerの削除
kubectl delete -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.4/deploy/static/provider/baremetal/deploy.yaml

# MetalLBのインストール
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.10.3/manifests/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.10.3/manifests/metallb.yaml

# L2 modeの設定
# https://metallb.universe.tf/configuration/#layer-2-configuration
# nodeのネットワークで使われていないIPを使用する(今回は10.240.0.0/24の中でnodeに割り当てられていないIP)
cat << EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
 namespace: metallb-system
 name: config
data:
 config: |
 address-pools:
 - name: default
 protocol: layer2
 addresses:
 - 10.240.0.10-10.240.0.15
EOF

MetalLBのインストールと設定が正常にできていればこんな感じになる。

$ k -n metallb-system get all
NAME READY STATUS RESTARTS AGE
pod/controller-77c44876d-wgqzj 1/1 Running 0 5m43s
pod/speaker-fdcrw 1/1 Running 0 5m43s
pod/speaker-kgz2w 1/1 Running 0 5m43s

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/speaker 2 2 2 2 2 kubernetes.io/os=linux 5m43s

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/controller 1/1 1 1 5m43s

NAME DESIRED CURRENT READY AGE
replicaset.apps/controller-77c44876d 1 1 1 5m43s

ingress-nginxのインストール(with MetalLB)

あとはLoadBalancer Serviceを使う設定のingress-nginxをインストールする。

# LoadBalancerになるはず
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.4/deploy/static/provider/cloud/deploy.yaml

外部からリクエストを受けてトラフィックを振り分けるためのIngress Controllerが今度はNodePort ServiceでなくちゃんとLoadBalancer Serviceで公開されていて、しかもExternalIPにMetalLBで指定したIPが設定されている。

$ k -n ingress-nginx get all
NAME READY STATUS RESTARTS AGE
pod/ingress-nginx-admission-create--1-fbqsf 0/1 Completed 0 28s
pod/ingress-nginx-admission-patch--1-l2pz5 0/1 Completed 1 28s
pod/ingress-nginx-controller-5c8d66c76d-wfbjf 1/1 Running 0 29s

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ingress-nginx-controller LoadBalancer 10.111.44.72 10.240.0.10 80:31646/TCP,443:32459/TCP 29s
service/ingress-nginx-controller-admission ClusterIP 10.99.244.117 <none> 443/TCP 29s

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ingress-nginx-controller 1/1 1 1 29s

NAME DESIRED CURRENT READY AGE
replicaset.apps/ingress-nginx-controller-5c8d66c76d 1 1 1 29s

NAME COMPLETIONS DURATION AGE
job.batch/ingress-nginx-admission-create 1/1 4s 29s
job.batch/ingress-nginx-admission-patch 1/1 4s 28s

動作確認(with MetalLB)

最後に、同じネットワークのnodeからMetalLBで払い出されたLoadBalancer ServiceのIP越しにIngress経由のリクエストを送ってみる。

# 払い出したExretnalIPで接続できた!
$ curl -H "Host: hello-world.info" 10.240.0.10/
Hello, world!
Version: 1.0.0
Hostname: web-7c884bf475-tt9g6

できた〜〜🎉

10.240.0.10にサーバが立ってないのにリクエストができるのはMetalLBのspeakerが同じネットワークに送られたARPリクエストに対して応答するおかげらしい(まだちゃんと理解してない)。

よくわかってないけどとりあえず普通のポートでIngressが動いたのでヨシ!

おわり

自前のクラスタにIngress Controllerを突っ込む練習をしてみた。
正直なところドキュメント通りにyamlをapplyするだけで簡単に設定できてしまったので本当に身についたかは怪しいが、
Ingress ClassについてはIngress Controllerを意識しないと触れる機会が少ないし、実際あまりわかってなかったので勉強になってよかった。
MetalLBについてはまたどこかでお世話になりそうなのでそのときにちゃんと勉強したい。

おまけ

Ubuntu+kubeadm+containerd+CalicoでシングルmasterのKubernetesクラスタをつくる

Fri, 15 Oct 2021 00:00:00 +0000

やったことのまとめ

クラスタ操作の練習用にGKEみたいなマネージドではない自前のKubernetesクラスタがほしくて、
かつ運用の練習としてはkindやMinikubeみたいなやつだと物足りない。
とはいえKubernetes The Hard Wayするほどじゃないんだよな…みたいな気分になったので、
おさらいも兼ねてkubeadmでクラスタを立てることにした。
基本的にCreating a cluster with kubeadmをなぞっているだけ。

GCPでVMとネットワークを作成した
kubeadmを使ってKubernetesクラスタをつくった
コンテナランタイムにはcontainerd, ネットワークアドオンはCalicoを使用した
あまり長くつかっているとお金がかかるのでおかたづけした

つかうもの

macOS Big Sur 11.2.3
Google Cloud SDK 360.0.0
- GCP操作に使用
Ubuntu 20.04.3 LTS (GNU/Linux 5.11.0-1020-gcp x86_64)
- node用のVMとして使用
containerd 1.4.11
- コンテナランタイム
Calico v3.20.2
- ネットワークアドオン
Kubernetes v1.22.2

やったこと

ネットワークとVMの準備(GCP)
- VPCネットワークの作成
- VMインスタンスの作成
nodeの準備
- コンテナランタイム(containerd)のインストール
- kubelet,kubeadm,kubectlのインストール
masterの起動
ネットワークアドオン(Calico)のインストール
workerの起動
おかたづけ

ネットワークとVMの準備(GCP)

gcloudのセットアップはmacOS用のクイックスタートで終わっている前提。

VPCネットワークの作成

まずはnode同士をつなぐためのネットワークを設定する。
GCPではVPCネットワークを使う。

# Macで実行

# VPCネットワークの作成
# サブネットのIPレンジは10.240.0.0/24(最大256node使用可能)にする
gcloud compute networks create kubernetes-vpc-network --subnet-mode=custom
gcloud compute networks subnets create kubernetes-vpc-network-subnet --range=10.240.0.0/24 --network=kubernetes-vpc-network

# ネットワークのIPレンジ内からネットワーク上の任意のnodeへの任意のプロトコルでの接続を許可(kubernetes-vpc-network-allow-internal)
# 任意の送信元からネットワーク上の任意のnodeへの特定ポートへの特定プロトコルでの接続を許可(kubernetes-vpc-network-allow-external)
# tcp:22はnodeへのSSHに, tcp:6443はkube-apiserverへのリクエストに, icmpはpingでの監視に使用
gcloud compute firewall-rules create kubernetes-vpc-network-allow-internal --network=kubernetes-vpc-network --allow all --source-ranges=10.240.0.0/24
gcloud compute firewall-rules create kubernetes-vpc-network-allow-external --network kubernetes-vpc-network --allow tcp:22,tcp:6443,icmp

VMインスタンスの作成

つぎにクラスタのnodeとして使うVMインスタンスをmaster用とworker用にそれぞれ1台ずつ建てる。
Creating a cluster with kubeadmによるとmasterは最低でも2GiB RAM, 2CPUsがあるといいらしいのでマシンタイプはそれを満たすように気をつける。
OSの起動imageはUbuntu 20.04 LTSを使用した。

# Macで実行

# master(e2-medium),worker(e2-small)用インスタンスの作成
gcloud compute instances create kubernetes-master --machine-type=e2-medium --image-family=ubuntu-2004-lts --image-project=ubuntu-os-cloud --subnet=kubernetes-vpc-network-subnet
gcloud compute instances create kubernetes-worker --machine-type=e2-small --image-family=ubuntu-2004-lts --image-project=ubuntu-os-cloud --subnet=kubernetes-vpc-network-subnet

最終的に以下のようになっていればOK。

$ gcloud compute networks list --filter="name=kubernetes-vpc-network"
NAME SUBNET_MODE BGP_ROUTING_MODE IPV4_RANGE GATEWAY_IPV4
kubernetes-vpc-network CUSTOM REGIONAL

$ gcloud compute networks subnets list --filter="name=kubernetes-vpc-network-subnet"
NAME REGION NETWORK RANGE STACK_TYPE IPV6_ACCESS_TYPE IPV6_CIDR_RANGE EXTERNAL_IPV6_CIDR_RANGE
kubernetes-vpc-network-subnet us-central1 kubernetes-vpc-network 10.240.0.0/24 IPV4_ONLY

$ gcloud compute firewall-rules list --filter="network=kubernetes-vpc-network"
NAME NETWORK DIRECTION PRIORITY ALLOW DENY DISABLED
kubernetes-vpc-network-allow-external kubernetes-vpc-network INGRESS 1000 tcp:22,tcp:6443,icmp False
kubernetes-vpc-network-allow-internal kubernetes-vpc-network INGRESS 1000 all False

$ gcloud compute instances list
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS
kubernetes-master us-central1-a e2-medium 10.240.0.4 xx.xx.xx.xxx RUNNING
kubernetes-worker us-central1-a e2-small 10.240.0.5 yy.yyy.yyy.yy RUNNING

nodeの準備

ネットワークとnode用VMが準備できたので、いよいよクラスタを構築していく。

# SSHするときは以下のコマンドを使う
gcloud compute ssh kubernetes-master
gcloud compute ssh kubernetes-worker

コンテナランタイム(containerd)のインストール

masterとworkerで共にPod(コンテナ)を動かすために必要なコンテナランタイムをインストールする。
コンテナランタイムにはいくつか候補があるが、今回はcontainerdを使う。
Ubuntuでのインストール手順はInstall Docker Engine on Ubuntuを参考にする。

# master/worker両方でそれぞれ実行する

# VM起動時にkernelモジュール(overlay, br_netfilter)を読み込むための設定
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF
# kernelモジュール(overlay, br_netfilter)の手動読み込み
sudo modprobe overlay && sudo modprobe br_netfilter
# kernelパラメータを変更(永続化)する設定
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
# kernelパラメータの適用
sudo sysctl --system

# (ないと思うが)古いpackageを削除
sudo apt-get remove docker docker-engine docker.io containerd runc
# aptのpackage indexの更新とHTTPSでリポジトリを使うために必要なpackageのインストール
sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl gnupg lsb-release
# Docker公式のGPG鍵追加 
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
# Dockerのstableリポジトリ追加
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
# containerdのインストール
sudo apt-get update && sudo apt-get install -y containerd.io
# containerdの設定ファイル作成(96行目付近にsystemdのcgroupドライバーを使う設定を入れる)
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
sudo vim /etc/containerd/config.toml
# containerdの再起動
sudo systemctl restart containerd

containerdを動かすcgroupがsystemdになる/etc/containerd/config.tomlの設定はUsing the systemd cgroup driverに従った。

 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
 runtime_type = "io.containerd.runc.v2"
 runtime_engine = ""
 runtime_root = ""
 privileged_without_host_devices = false
 base_runtime_spec = ""
 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
 SystemdCgroup = true

systemdでcontainerdが動いていることを確認できればOK。

kubernetes-worker:~$ systemctl is-active containerd
active

kubelet,kubeadm,kubectlのインストール

コンテナランタイムがインストールできたら、次はInstalling kubeadm, kubelet and kubectlに従ってKubernetesクラスタに必要なコンポーネントをmasterとworker両方にインストールする。

# master/worker両方でそれぞれ実行する

# Google CloudのGPG鍵追加
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
# Kubernetesリポジトリ追加
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
# kubelet,kubeadm,kubectlのインストールとバージョン固定
sudo apt-get update && sudo apt-get install -y kubelet kubeadm kubectl && sudo apt-mark hold kubelet kubeadm kubectl

masterの起動

コンテナランタイムとkubeadmの準備ができたらまずはmaster node (control-plane)を作成する。
今回はネットワークアドオンにCalicoを使うため、kubeadm initのオプションを付与する。

# masterでのみ実行する

# master nodeのセットアップ
sudo kubeadm init --pod-network-cidr=192.168.0.0/16

# kubeconfigの準備
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

# kubectlの準備
source <(kubectl completion bash)
alias k=kubectl
complete -F __start_kubectl k

これでmaster nodeが作成できた…と思いきや、
この時点ではまだネットワークアドオンが入っていないためPod間の通信ができず、CoreDNSが立ち上がらない。

kubernetes-master:~$ k get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-78fcd69978-dzwrb 0/1 Pending 0 3m25s
kube-system coredns-78fcd69978-ffpvj 0/1 Pending 0 3m25s
kube-system etcd-kubernetes-master 1/1 Running 0 3m33s
kube-system kube-apiserver-kubernetes-master 1/1 Running 0 3m33s
kube-system kube-controller-manager-kubernetes-master 1/1 Running 0 3m33s
kube-system kube-proxy-zk7mn 1/1 Running 0 3m25s
kube-system kube-scheduler-kubernetes-master 1/1 Running 0 3m33s

ネットワークアドオン(Calico)のインストール

kubeadm initが終わったので、
つぎにネットワークアドオンとしてCalicoをインストールする。

# masterでのみ実行する

# Calicoのインストール
k create -f https://docs.projectcalico.org/manifests/tigera-operator.yaml
k create -f https://docs.projectcalico.org/manifests/custom-resources.yaml

Calicoに必要なPodの作成には時間がかかるのですこし待つ。
次のようになっていればOK。
CoreDNSも立ち上がっている。

kubernetes-master:~$ k get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
calico-apiserver calico-apiserver-6dd4bc68c6-lslcj 1/1 Running 0 12s
calico-system calico-kube-controllers-767ddd5576-64dj8 1/1 Running 0 80s
calico-system calico-node-2fx6b 1/1 Running 0 80s
calico-system calico-typha-5bf9887dd7-hrtwj 1/1 Running 0 80s
kube-system coredns-78fcd69978-dzwrb 1/1 Running 0 12m
kube-system coredns-78fcd69978-ffpvj 1/1 Running 0 12m
kube-system etcd-kubernetes-master 1/1 Running 0 12m
kube-system kube-apiserver-kubernetes-master 1/1 Running 0 12m
kube-system kube-controller-manager-kubernetes-master 1/1 Running 0 12m
kube-system kube-proxy-zk7mn 1/1 Running 0 12m
kube-system kube-scheduler-kubernetes-master 1/1 Running 0 12m
tigera-operator tigera-operator-59f4845b57-qgq6c 1/1 Running 0 111s

workerの起動

master1台のKubernetesクラスタができたので、
次にworkerをこのクラスタに追加する。

nodeの追加に必要なトークンとCA証明書のハッシュ値はmaster側で取得する。

# masterでのみ実行する

# 新規tokenの作成
kubernetes-master:~$ kubeadm token create
<token>

# CA証明書ハッシュの取得
kubernetes-master:~$ openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
<hash>

# master nodeのホストとIPを取得
kubernetes-master:~$ k cluster-info | grep control
Kubernetes control plane is running at https://<control-plane-host>:<control-plane-port>

masterで取得した情報を使ってworkerをkubeadm joinしてクラスタに追加する。

# workerでのみ実行する
sudo kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>

This node has joined the clusterと表示されればworkerがクラスタに追加できている。

master側で確認するとworkerが認識されていて、各種DaemonSetのPodもちゃんとworkerに配置されている。

kubernetes-master:~$ k get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
kubernetes-master Ready control-plane,master 25m v1.22.2 10.240.0.4 <none> Ubuntu 20.04.3 LTS 5.11.0-1020-gcp containerd://1.4.11
kubernetes-worker Ready <none> 91s v1.22.2 10.240.0.5 <none> Ubuntu 20.04.3 LTS 5.11.0-1020-gcp containerd://1.4.11

kubernetes-master:~$ k get all -A -o wide
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
calico-apiserver pod/calico-apiserver-6dd4bc68c6-lslcj 1/1 Running 0 19m 192.168.237.5 kubernetes-master <none> <none>
calico-system pod/calico-kube-controllers-767ddd5576-64dj8 1/1 Running 0 20m 192.168.237.2 kubernetes-master <none> <none>
calico-system pod/calico-node-2fx6b 1/1 Running 0 20m 10.240.0.4 kubernetes-master <none> <none>
calico-system pod/calico-node-vkmhc 1/1 Running 0 7m7s 10.240.0.5 kubernetes-worker <none> <none>
calico-system pod/calico-typha-5bf9887dd7-hrtwj 1/1 Running 0 20m 10.240.0.4 kubernetes-master <none> <none>
calico-system pod/calico-typha-5bf9887dd7-v8plr 1/1 Running 1 (6m33s ago) 7m4s 10.240.0.5 kubernetes-worker <none> <none>
kube-system pod/coredns-78fcd69978-dzwrb 1/1 Running 0 31m 192.168.237.1 kubernetes-master <none> <none>
kube-system pod/coredns-78fcd69978-ffpvj 1/1 Running 0 31m 192.168.237.3 kubernetes-master <none> <none>
kube-system pod/etcd-kubernetes-master 1/1 Running 0 31m 10.240.0.4 kubernetes-master <none> <none>
kube-system pod/kube-apiserver-kubernetes-master 1/1 Running 0 31m 10.240.0.4 kubernetes-master <none> <none>
kube-system pod/kube-controller-manager-kubernetes-master 1/1 Running 0 31m 10.240.0.4 kubernetes-master <none> <none>
kube-system pod/kube-proxy-xj444 1/1 Running 0 7m7s 10.240.0.5 kubernetes-worker <none> <none>
kube-system pod/kube-proxy-zk7mn 1/1 Running 0 31m 10.240.0.4 kubernetes-master <none> <none>
kube-system pod/kube-scheduler-kubernetes-master 1/1 Running 0 31m 10.240.0.4 kubernetes-master <none> <none>
tigera-operator pod/tigera-operator-59f4845b57-qgq6c 1/1 Running 0 20m 10.240.0.4 kubernetes-master <none> <none>

NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
calico-apiserver service/calico-api ClusterIP 10.110.66.91 <none> 443/TCP 19m apiserver=true
calico-system service/calico-kube-controllers-metrics ClusterIP 10.106.106.192 <none> 9094/TCP 19m k8s-app=calico-kube-controllers
calico-system service/calico-typha ClusterIP 10.110.34.28 <none> 5473/TCP 20m k8s-app=calico-typha
default service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 31m <none>
kube-system service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 31m k8s-app=kube-dns

NAMESPACE NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE CONTAINERS IMAGES SELECTOR
calico-system daemonset.apps/calico-node 2 2 2 2 2 kubernetes.io/os=linux 20m calico-node docker.io/calico/node:v3.20.2 k8s-app=calico-node
kube-system daemonset.apps/kube-proxy 2 2 2 2 2 kubernetes.io/os=linux 31m kube-proxy k8s.gcr.io/kube-proxy:v1.22.2 k8s-app=kube-proxy

NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
calico-apiserver deployment.apps/calico-apiserver 1/1 1 1 19m calico-apiserver docker.io/calico/apiserver:v3.20.2 apiserver=true
calico-system deployment.apps/calico-kube-controllers 1/1 1 1 20m calico-kube-controllers docker.io/calico/kube-controllers:v3.20.2 k8s-app=calico-kube-controllers
calico-system deployment.apps/calico-typha 2/2 2 2 20m calico-typha docker.io/calico/typha:v3.20.2 k8s-app=calico-typha
kube-system deployment.apps/coredns 2/2 2 2 31m coredns k8s.gcr.io/coredns/coredns:v1.8.4 k8s-app=kube-dns
tigera-operator deployment.apps/tigera-operator 1/1 1 1 20m tigera-operator quay.io/tigera/operator:v1.20.4 name=tigera-operator

NAMESPACE NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
calico-apiserver replicaset.apps/calico-apiserver-6dd4bc68c6 1 1 1 19m calico-apiserver docker.io/calico/apiserver:v3.20.2 apiserver=true,pod-template-hash=6dd4bc68c6
calico-apiserver replicaset.apps/calico-apiserver-788fc95f55 0 0 0 19m calico-apiserver docker.io/calico/apiserver:v3.20.2 apiserver=true,pod-template-hash=788fc95f55
calico-system replicaset.apps/calico-kube-controllers-767ddd5576 1 1 1 20m calico-kube-controllers docker.io/calico/kube-controllers:v3.20.2 k8s-app=calico-kube-controllers,pod-template-hash=767ddd5576
calico-system replicaset.apps/calico-typha-5bf9887dd7 2 2 2 20m calico-typha docker.io/calico/typha:v3.20.2 k8s-app=calico-typha,pod-template-hash=5bf9887dd7
kube-system replicaset.apps/coredns-78fcd69978 2 2 2 31m coredns k8s.gcr.io/coredns/coredns:v1.8.4 k8s-app=kube-dns,pod-template-hash=78fcd69978
tigera-operator replicaset.apps/tigera-operator-59f4845b57 1 1 1 20m tigera-operator quay.io/tigera/operator:v1.20.4 name=tigera-operator,pod-template-hash=59f4845b57

これで1master-1workerのKubernetesクラスタをつくることができた。

後はVMのリソースが尽きない限り何でも自由にやりたい放題できる。

おかたづけ

GCPで建てたVMは今回masterに使用したe2-mediumだけでも1ヶ月で約3000円くらいかかってしまう。

お金に余裕があればいいんだけど、練習用のクラスタなので使わなくなったらさっさと片付けるべき。
(昔デカめのKubernetesクラスタを放置してたら無料枠$300が1ヶ月で吹き飛んた)

VMをそのまま吹き飛ばしても良いのだが、練習としてkubeadmを使ったお掃除をしてみる。

# masterでのみ実行する

# workerのPodを退去させる
kubectl drain kubernetes-worker --delete-local-data --force --ignore-daemonsets

# workerでのみ実行する

# kubadm joinによって設定されたものを設定前に戻す
sudo kubeadm reset
sudo rm -rf /etc/cni/net.d

# masterでのみ実行する

# workerを削除する
kubectl delete node kubernetes-worker

# kubeadm initによって設定されたものを設定前に戻す
sudo kubeadm reset
sudo rm -rf /etc/cni/net.d

あとは粛々とKubernetesコンポーネントとコンテナランタイムを削除していく。

# master/worker両方でそれぞれ実行する

# Kubernetesコンポーネントの削除
sudo apt-get purge -y --allow-change-held-packages kubelet kubeadm kubectl
sudo apt-get purge -y --allow-change-held-packages containerd.io

最後にgcloudで作ったリソースを削除する。

# Macで実行

# GCPリソースの削除(いきなりこれをやってもOK)
gcloud compute instances delete kubernetes-master kubernetes-worker
gcloud compute firewall-rules delete kubernetes-vpc-network-allow-internal kubernetes-vpc-network-allow-external
gcloud compute networks subnets delete kubernetes-vpc-network-subnet
gcloud compute networks delete kubernetes-vpc-network

これで綺麗さっぱりおかたづけできたのでお財布のダメージも少ないはず。

おわり

Creating a cluster with kubeadmをなぞって練習用のKubernetesクラスタをつくった。
基本的にはドキュメントさえ見ればできるんだけど、参照するドキュメントが何枚もあったりしてたまに混乱するので具体的な手順を1枚にできてよかった。

おまけ

CKSを受験した

Sun, 10 Oct 2021 00:00:00 +0000

まとめ

CKSを受験した
今回も試験シミュレータ(Killer Shell)で十分対策できた
試験中に参照できるドキュメントはCKAよりも多い

まずはCKSにバンドルされた教材(LFS260)を1週間で一通り読み込んだ。
今回は初めて触る内容も多かったので割と真面目に読んで、Exerciseもちゃんと手を動かして解いた。
trivyやkube-benchなどのKubernetesにデフォルトで含まれていないツールについての練習もできてよかったと思う。
量的にはCKA用の教材(LFS258)よりすこし少ない程度だったが、連休だったのもあってなんとか終わらせることができた。

教材を終わらせた後、前回同様にKiller Shellの試験シミュレータで模擬試験を解いた。
CKA合格が前提とされている試験だけあり、クラスタの設定に関する問題は普通に出てくるしさらに先述のツール類を使う問題も出るので内容としてはかなり難しかったように思う。
初回はドキュメントを見ないとほぼ0点だった。

また、CKSではCKADやCKAと異なりKubernetes公式ドキュメント以外にもtrivy, sysdig, Falco, AppArmorのドキュメントが試験中に参照可能であることをここで初めて知った。
これらのツールも模擬試験では容赦なく出題されていたので、試験で使えそうなページをブックマークしておいた。

試験本番

今回も自宅で試験を受けた。
もちろんねこもいっしょ。

今回は試験開始時刻になっても試験官が来ない?トラブルがあったため、5分遅れくらいでスタートした。
試験前の試験官とのやりとりはこれまでと全く一緒。

今回も試験時間は2時間で問題数は17問くらいだった。
やはりKiller Shellの試験シミュレータでやった内容と似た問題が多く、今回も余裕を持って回答できた(つもり)。

それぞれの問題の難しさ的にはCKAと同じくらいかそれ以上だと感じたが、CKSで出る問題の場合はKubernetes以外のツールの使い方を問うようなものが多く、
そういった汎用的な手順はだいたい公式ドキュメントに書いてあるのでそれを見れば解けてしまうようなものがいくつかあった。

ちなみに試験を受けたのが普段ねこにおやつをあげている時間だったので、今回そとちゃんがめちゃくちゃうるさかった。
試験前にその日のぶんのおやつはあげていたのに…😭
結構ガッツリ鳴いていたが、試験官に怒られることはなかった。

結果

結果は…?

合格だった。🎉

合格点67点に対して75点とかなりギリギリの結果だった。
今回は配点比率がかなり高めの問題で1つ致命的なミスをした自覚があるので、それが点数に響いたように思う。
CKAD, CKAはそこそこの点数が取れていたのと比較すると、
やはり実務であまり触れていないモノに対して試験勉強だけでなんとかしようとしたためにまだ本質を理解できていないことがよくわかった。

おわり

CKSに合格した。
CKAD, CKAと併せてこれでKubernetesの認定資格(2021年10月時点で公開されているもの)をすべて取得できたので、
†Kubernetes完全に理解した† と言って良いのでは？(アカン)

とはいえCKSだけ点数が低かったあたり、やっぱり実務でさわんないとダメだなという気持ちになった。
今後も慢心せずに頑張りたい。

おまけ

9月のそとちゃん(2021)

Thu, 30 Sep 2021 00:00:00 +0000

まとめ

草
病院

草

約2年ぶりくらいに猫草を買った。

草 pic.twitter.com/13K07YSLUy
— ずみし (@uzimihsr) September 20, 2021

またたびジャンキーのそとちゃんは猫草も大好きで食いつきがヤバい。

昔あげたときにごはんそっちのけで食べては吐いてを繰り返し部屋中GEROまみれにした前科があるので、
今回は猫草を部屋の外に出して、特定の時間だけ食べられるようにした。
(部屋の中に置くとずっと食べ続けちゃう😭)

なお…😭

草めっちゃ食べて吐いた pic.twitter.com/DgfwfqmsNF
— ずみし (@uzimihsr) September 29, 2021

(なんで吐いた後のねこっていつもどや顔してるの？)

病院

そとちゃんのワクチンを打ちに病院に行った。

病院いく pic.twitter.com/nxuDU9nnZY
— ずみし (@uzimihsr) September 22, 2021

そとちゃんは病院大好きねこ。
お出かけするとわかったとたんキャリーバッグに自分から入る。

病院についてからも余裕ぶっこき状態。
待合室で騒ぐ子犬など眼中になく、バッグの中でごろごろして成猫の余裕を見せつける。
(俺は犬が苦手なので怯えまくっていた)

診察室に入ると今度は診察台の上で寝転んだり先生の机の上を探検してしまう。
あまりの傍若無人ぶりに耐えかねた先生に「気に入ってくれてうれしいけど、ここはおうちじゃないのよ〜🏥」とやんわり(?)怒られる始末。😭

注射も全然平気で、全く暴れず「にゃん」とも言われなかった。
それよりも体温測定(おしりの*に体温計を入れてはかる)が嫌だったらしい。
体温計を入れるときだけは暴れて「に"ゃ"ん”💢」だった。
(ちなみに体温は38.2℃だった。ねこって温かい)

今回打ったのは3種混合ワクチンというやつ。
そとちゃんはワクチンを最後に打ったのが2018年に保護されたときで、それ以降うちに来てからは打っていなかった。
完全室内飼いかつ1匹だけなので今まで頭から抜けていたんだけど、それでも本当は年に1回の接種がおすすめらしい。

#Vaccinated pic.twitter.com/t0WgPwBO0h
— ずみし (@uzimihsr) September 22, 2021

ワクチンを打ったついでにいろいろ診てもらった。

先生によると首にちょっとだけしこりがあるのが気になったらしい。
精密検査とかが必要なレベルではないらしいけど、毎日触ってみてもし肥大するようなら要検査らしいので注意したい。

あと、右の奥歯が歯肉炎になっていて、何かが触れるだけで痛みを感じる状態らしい。😭
歯みがきをやたら嫌がるのはこれが原因だった。

左の奥歯は綺麗なので問題ないけど、歯周病菌がこれ以上増えないよう歯肉に塗る薬を処方してもらうことになった。
インターベリーα
犬用って書いてあるけど猫にも効果があるみたい。

これを週に2回×5週間、計10回塗る必要がある。
まだ歯肉の痛みがあるそとちゃんはなかなか塗らせてくれないけど、よくなると信じてがんばるしかない。

歯肉炎の薬塗られるの嫌すぎて立てこもり pic.twitter.com/Xoq49MCnH6
— ずみし (@uzimihsr) September 29, 2021

その他はだいたい健康で、体型も普通なので食事は今のままで問題ないとのことだった。
(体重は4.05kgだった)

ワクチンを打った後は人間と同じく副反応が出ることがあるらしく、
接種後は目を離さないように言われたのでその日はつきっきりで看ていた。

が、特に何も変化はなくいつもどおりごろごろしていた。
このあたりは俺に似たのかもしれない。

ワクチン接種後2時間くらいは目を離さないよう言われてたけどなんもなかった
元気 pic.twitter.com/ORRLgRletl
— ずみし (@uzimihsr) September 22, 2021

(ほとんど遊んでただけだが)そとちゃんは病院をがんばってえらかった。

病院がんばった pic.twitter.com/PvxJYKrTGq
— ずみし (@uzimihsr) September 22, 2021

おわり

9月は病院に行ったのがかなり大きなイベントだった。

最近はそとちゃんがいつも元気にしているのであまり病院に連れて行っていなかったけども、
今回みたいにちょっと怪しい部分(特に歯)を診てもらえたり、何よりそとちゃんが楽しそうなので今後は定期的に連れていくようにしたい。

おまけ

kubectl auth can-iでService Accountの権限を確認する

Thu, 16 Sep 2021 00:00:00 +0000

まとめ

kubectl --asでService Accountを使いたいときはsystem:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)を指定すると良い。

# resourceに対するverbが許可されているかチェック
kubectl auth can-i <verb> <resource> -n <namespace> --as system:serviceaccount:<namespace>:<serviceAccountName>
# ServiceAccountに許可されたresource, verbをリストで表示
kubectl auth can-i --list -n <namespace> --as system:serviceaccount:<namespace>:<serviceAccountName>

環境

kind
- v0.11.0 go1.16.4 darwin/amd64
Kubernetes
- v1.21.1

# namespace(myhome)のservice account(sotochan)がnamespace: myhomeのpodに対して何でもできる権限を付与
$ kubectl create namespace myhome
$ kubectl create serviceaccount sotochan -n myhome
$ kubectl create role pod-owner --verb="*" --resource="pods" -n myhome
$ kubectl create rolebinding pod-owner-bind --role=pod-owner --serviceaccount=myhome:sotochan

このとき、kubectl auth can-iでService Accountの権限を確認しようとしたらうまくいかなかった。

# どうして...
$ kubectl auth can-i get pod -n myhome --as sotochan
no
$ kubectl auth can-i --list -n myhome --as sotochan | grep -c pod
0

正しいやり方

公式ドキュメントをテキトーに探してもよくわからず"わからん！わからん！“って騒いでいたら会社の素晴らしい同期が教えてくれた。

--asでService Accountを指定する場合はsystem:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)と指定すればいいらしい。

# やったぜ。
$ kubectl auth can-i get pod -n myhome --as system:serviceaccount:myhome:sotochan
yes
$ kubectl auth can-i --list -n myhome --as system:serviceaccount:myhome:sotochan | grep pod
pods [] [] [*]

落ち着いて探したら公式ドキュメントにも一応関連する情報が書いてあった。
Service Accountのユーザー名がそもそもsystem:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)として扱われているらしい。¹

知らなかった…😭

おわり

Service Accountについてちゃんと理解してればこんなところで詰まらないとは思うけど、
公式ドキュメントでkubectl --asでService Accountを指定する例が見つけづらかった+自分は30分くらい消耗してしまったので一応メモとして残しておく。

かなしい…

おまけ

https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens ↩︎

CKAはねこと一緒に受験できる

Tue, 14 Sep 2021 00:00:00 +0000

まとめ

CKAを受験した
CKA-JPを受ける意味はないと思う
試験シミュレータの出来が良いのである程度慣れている人なら試験対策はこれだけでよさそう
ねこちゃんは持ち込み可(重要)
CKADを先に受けておいてよかった

結局のところ、業務で経験を積んだおかげで教材の内容がほとんどわかる状態だったのと、
いつまで経っても教材が終わらなかったので(主にソシャゲのせい)、
先に試験日を決めてその前の数日で試験対策をして臨むことにした。

試験の申し込みの流れはCKADを受験したときとほとんど同じだったので割愛。
前回は日本語版で受けたが試験官とのやり取りが普通に英語だったりとあまりメリットを感じなかったので、CKA-JPではなく普通のCKAを受けた。
何故かCKAのほうがちょっと安いし(2021年9月時点でCKAが$375, CKA-JPが$410)、やろうと思えば問題文も日本語にできるので普通にCKAを受けたほうが良いと思う。

試験対策

試験対策はほとんど一夜漬け。
LFS258のExerciseも良さそうだったけど、
クラスタ構築のためにパブリッククラウド使うとお片付け忘れてお金無駄にしちゃうマンなので手は動かさずに内容をさらっと読む程度だった。

前からあったのかもしれないが今はCKAに申し込むとKiller Shellとかいう試験シミュレータが無料で使えるので(36hx2回まで)、どちらかというとこっちのほうが役に立った。

“本番の試験よりも難しいよ!(意訳)“との触れ込み通り、このシミュレータが結構難しい。
練習問題25問+プレビュー問題3問が用意されているのだが、
ドキュメントを見ないと最初は練習問題が半分、プレビュー問題は1つくらいしか解けなかった。
よくわからなかったところを回答と公式ドキュメントを見ながら再度解いた。

特に自分はクラスタ構築をKubernetes The Hard Wayでしかやったことがなかった(普段はマネージドk8sを使っている)ので、
主にkubeadmのコマンドまわりがわからず急いでドキュメントを読み込んだ。

公式ドキュメントは本番試験中も参照可能なので、難しいと思った内容に関連するドキュメントはブックマークしておいた。
PersistentVolume(Claim), NetworkPolicyあたりはkubectl create --dry-run -o yamlできないのでこれらのYAML例があるページも併せてブックマークした。

試験本番

CKADと同様、自宅で試験を受けた。

試験前の指示も前回と全く同じ(カメラを持って部屋を一周しろ、机を片付けろ、などなど)だったので割愛。

前回そとちゃんを廊下で待たせたら試験中に爆鳴きして大変だったので、そとちゃんをカメラに映しながら試験官に
“ウチにはねこちゃんいるんだけど、この子部屋の外に出さなきゃダメ?”
と確認したところ
“おとなしくできるなら彼女は部屋に居てもいいよ!”
とのことだった。

見た目だけでなんでそとちゃんが女の子(she)だってわかったのかは謎だけど(英語だと猫の代名詞でsheを使うことが多い?)、
OKをもらえたのでよかった。

また、試験中に開けるタブは2つまで(試験用+ドキュメント用)とされているが、1タブずつで2ウィンドウ開いても良いとのことだった。
自分の場合はディスプレイが横長なのでこれがかなり有利に働いたと思う。

試験時間は2時間で問題数は17問くらい。
具体的な内容は避けるが問題の傾向は試験シミュレータとかなり似ていて、
たしかに本番のほうが少し簡単なものが多かった。
また、シミュレータと違って「n問目が正解できてないとm問目で詰む」というケースがなかったので、難しい問題は飛ばして後回しにできて良かった。
CKAD(2時間で19問)のときは少し慎重になりすぎて時間が足りなかったので、
今回はスピード重視でやったところ30分くらい時間が余って見直しする余裕もあった。

ちなみにそとちゃんは試験開始後に1回鳴いただけで、その後はずっとおとなしく寝てくれていた。えらい!

結果

結果は…?

合格だった。🎉

合格点66点に対して得点はまたも91点だった。
今回は時間にも余裕があって、完答したつもりだったのですこしくやしい。

おわり

CKAに合格した。
正直これを獲っただけで実用レベルのクラスタ管理者になれるかというとすこし疑問だけど、
少なくともKubernetesの基本を押さえたことの証明にはなると思う。

個人的にはCKADと比べると問題の内容はすこし難しいものの、制限時間のあるテストとして考えるとCKAのほうが問題数も少なくて簡単だった。
(CKADを受けたおかげでkubectlの操作がやたら早くなっていたり、もちろん自分の経験値が増えていることもあるが…)

CKAD、CKAと来てしまったので次はCKSを受ける予定(いつ?)。
噂によるとかなり難しいらしいので頑張りたい(ほんまか?)。

おまけ

8月のそとちゃん(2021)

Thu, 09 Sep 2021 00:00:00 +0000

まとめ

おでかけ
ねずみ大捜索
ボロボロダンボール

おでかけ

そとちゃんがいつもより窓際で鳴いたりして外に出たがってるように見えたので、
ハーネス+抱っこの状態で何回か家の外に出してみた。

セミを見てきた pic.twitter.com/Z5sqSvsCqd
— ずみし (@uzimihsr) August 25, 2021

元々野良猫だったそとちゃんだけど外に出ても意外とおとなしくできる。えらい。

というよりはハーネスが嫌いすぎて動く気がないと言ったほうが正しい。

つけられた時点で石のように動かなくなる(抱っこしやすくて助かる)。

外に出てもあんまり遠くは見ずに、近くに落ちてる死にかけの虫をずっと睨んでいる。

よくわからないけどこのときはしっぽをぶんぶん振るのでそとちゃん的にはめっちゃ楽しいらしい。
(たまに反撃されてびっくりする)

一応完全室内飼いなのでそとちゃんだけで外に出すことは絶対にしないけど、
ずっと室内だと退屈そうなのでたまにはこうやってお出かけしてもいいと思った。

ねずみ大捜索

実は6月くらいからねずみのおもちゃが全部行方不明になっていた。

1ヶ月くらい失くしてたねずみが出てきた pic.twitter.com/cGhpu2NHxS
— ずみし (@uzimihsr) August 21, 2021

そとちゃんは遊んでるときにおもちゃが取れなくなると一応鳴いて教えてくれるんだけど、
どこで失くしたかまでは教えてくれないのでその場で見つからなかったときはそのまま迷宮入りしてしまう。

そんな感じでどんどんねずみが消えていって、ついに全部なくなっちゃったので気合をいれて大捜索。

狭い部屋の中なのに1時間くらいかかってなんとか全部見つけられた。

猫トイレの裏、洗面台の下、ベッドフレームとマットレスの隙間、冷蔵庫の裏側…
ねこの手じゃ届かないのにどうやって入れた？ってところにも隠れててびっくりした。

次は失くさずに上手に遊んでほしい。
(この後すぐ白いのが1つ消えた😭)

ボロボロダンボール

そとちゃんお気に入りのダンボールトンネル(元は自動給餌器の空き箱)。

箱より袋派のそとちゃんだけどこれはほぼ毎日入る。
(この中から飛び出して俺をビビらせるのがすき)

そんなダンボールトンネルも2年使っているのでもうボロボロ。

そとちゃんが入ったときに興奮して内側をバリバリしちゃうので、ついに大きな穴が空いてしまった。

バリバリするたびにダンボールのカスが出るし、流石にもう捨てたいのだけど、なかなか許可が降りない…😭

おわり

8月のそとちゃんは元気いっぱいでよく遊んでいた。

遊ぶ時間は毎日確保してるので運動不足ではないとおもうけど、この元気はどこからくるのだろうか…

おまけ

mtailでnginxのaccess.logをメトリクス化する

Thu, 19 Aug 2021 00:00:00 +0000

やったことのまとめ

ログファイルをtailしてメトリクス化するmtailを使ってnginxのアクセスログをメトリクス化した
- https://github.com/uzimihsr/mtail-nginx

つかうもの

macOS Big Sur 11.2.3
Docker Desktop for Mac
- Version 3.5.2
- Docker Engine Version 20.10.7
- Docker Compose Version 1.29.2
mtail version 3.0.0-rc47
nginx 1.21.1
Prometheus v2.29.1

やったこと

mtailのビルド
mtail programの作成
動作確認

mtailのビルド

mtailはアプリケーションのログをメトリクス化するツール。
自身でメトリクスを公開できないアプリの監視なんかに使えそう。

nginxのメトリクスを扱うexporterとしてはnginx-prometheus-exporterがあるんだけど、
stub_statusの設定が必要だったりOSS版nginxだとメトリクスの種類が少なかったりするので今回はmtailを使ってみる。

mtailのビルド方法はいくつかある¹が、今回はかんたんに試したいのでGitHub Releasesで配布されているバイナリ²を仕込んだDockerイメージを作成する。
(自前でビルドしようとしたら自分の環境ではテストのエラーが発生してうまくできなかった…)

# Docker imageのビルド
$ ls Dockerfile
Dockerfile
$ docker image build -t mtail .
$ docker container run -it --rm mtail --version
mtail version 3.0.0-rc47 git revision 5e0099f843e4e4f2b7189c21019de18eb49181bf go version go1.16.5 go arch amd64 go os linux

mtail programの作成

続いてログをメトリクスに変換するためのmtail programと呼ばれるスクリプトを作成する。
mtail programはpattern(ログの各行に対する条件)とaction(patternを満たしたログに関する処理)から構成されている。³
(awkにちょっと似ている)

patternは主に正規表現で記述するので、まずはメトリクス化したいnginxのアクセスログのフォーマットを確認する。

# nginxのログフォーマットを確認
$ docker container run -it --rm nginx:1.21.1 cat /etc/nginx/nginx.conf
...(省略)
http {
...
 log_format main '$remote_addr - $remote_user [$time_local] "$request" '
 '$status $body_bytes_sent "$http_referer" '
 '"$http_user_agent" "$http_x_forwarded_for"';
...
}

このときのログの具体例は次のとおり。

172.20.0.1 - - [18/Aug/2021:14:04:48 +0000] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36" "-"

このフォーマットのログに対して正規表現で名前付きキャプチャグループを設定すると次のような感じになる。
$requestはメソッド、URI、バージョンに分割するようにした。　　

^(?P<remote_addr>\S+) - (?P<remote_user>.+) \[(?P<time_local>.+)\] "(?P<request_method>\S+) (?P<request_uri>\S+) (?P<request_version>\S+)" (?P<status>\S+) (?P<body_bytes_sent>\S+) "(?P<http_referer>\S+)" "(?P<http_user_agent>.+)" "(?P<http_x_forwarded_for>\S+)"$

この正規表現をpatternとしたmtail programを次のように作成した。
nginx_requestはリクエスト数を数えるカウンタで、ラベルとしてリクエストメソッドとステータスコードを付与するようにした。
nginx_request_pattern_matching_failedはpatternにマッチしなかったログの行数を数えるカウンタとして使用する。
また、どちらもログファイル名としてsourceラベルを付与するようにした。

動作確認

これでmtailを使う準備ができたのでDocker ComposeでnginxやPrometheusと一緒に起動してみる。
mtailの実行時引数などは公式ドキュメント⁴を参考にした。　　

Docker版のnginxはアクセスログ(/var/log/nginx/access.log)とエラーログ(/var/log/nginx/error.log)がそれぞれ標準出力(/dev/stdout)と標準エラー出力(/dev/stderr)へのシンボリックリンクになっていて、
ファイルとして参照するのが難しかったのでログの出力先を変更するようにした。

# ログファイルが標準出力へのシンボリックリンクになっている
$ docker container run -it --rm nginx:1.21.1 ls -l /var/log/nginx
total 0
lrwxrwxrwx 1 root root 11 Aug 17 11:46 access.log -> /dev/stdout
lrwxrwxrwx 1 root root 11 Aug 17 11:46 error.log -> /dev/stderr

# 起動前のディレクトリの状態
$ tree
.
├── Dockerfile
├── README.md
├── docker-compose.yaml
├── mtail
│   └── nginx.mtail
├── nginx
│   └── nginx.conf
└── prometheus
 └── prometheus.yml

# 起動
$ docker compose up -d --force-recreate
$ docker compose ps
NAME COMMAND SERVICE STATUS PORTS
mtail-nginx_mtail_1 "./mtail --progs=/et…" mtail running 0.0.0.0:3903->3903/tcp, :::3903->3903/tcp
mtail-nginx_nginx_1 "/docker-entrypoint.…" nginx running 0.0.0.0:80->80/tcp, :::80->80/tcp
mtail-nginx_prometheus_1 "/bin/prometheus --c…" prometheus running 0.0.0.0:9090->9090/tcp, :::9090->9090/tcp

この状態でhttp://localhost:3903/を開くとmtailが正常に動作していることを確認できる。

次にnginxhttp://localhost/に対していくつかリクエストを送ってみる。

# nginxにホストOSからリクエストを送る
$ curl -X GET "http://localhost/index.html"
$ curl -X GET "http://localhost/index.html"
$ curl -X GET "http://localhost/hogehoge.html"
$ curl -X POST "http://localhost/index.html"
$ curl -X PUT "http://localhost/index.html"
$ curl -X DELETE "http://localhost/index.html"

# ログファイルの内容
$ docker compose exec nginx cat /var/log/mtail-nginx/access.log
172.22.0.1 - - [19/Aug/2021:11:09:05 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "curl/7.64.1" "-"
172.22.0.1 - - [19/Aug/2021:11:09:06 +0000] "GET /index.html HTTP/1.1" 200 612 "-" "curl/7.64.1" "-"
172.22.0.1 - - [19/Aug/2021:11:09:12 +0000] "GET /hogehoge.html HTTP/1.1" 404 153 "-" "curl/7.64.1" "-"
172.22.0.1 - - [19/Aug/2021:11:09:18 +0000] "POST /index.html HTTP/1.1" 405 157 "-" "curl/7.64.1" "-"
172.22.0.1 - - [19/Aug/2021:11:09:22 +0000] "PUT /index.html HTTP/1.1" 405 157 "-" "curl/7.64.1" "-"
172.22.0.1 - - [19/Aug/2021:11:09:27 +0000] "DELETE /index.html HTTP/1.1" 405 157 "-" "curl/7.64.1" "-"
$ docker compose exec nginx cat /var/log/mtail-nginx/error.log
2021/08/19 11:09:12 [error] 31#31: *3 open() "/usr/share/nginx/html/hogehoge.html" failed (2: No such file or directory), client: 172.22.0.1, server: localhost, request: "GET /hogehoge.html HTTP/1.1", host: "localhost"

mtailのメトリクスはPrometheusのフォーマットに対応していて、
http://localhost:3903/metricsで内容を確認できる。

nginx.mtailで定義したとおり、
アクセスログの内容は正規表現のpatternにマッチするのでメソッドとステータスがラベル化されてnginx_requestとしてカウントされていて、
エラーログの内容はpatternにマッチしないのでnginx_request_pattern_matching_failedとしてカウントされている。

最後に一応Prometheushttp://localhost:9090/graphでもメトリクスを確認する。

mtailのメトリクスは通常のexporterと同様に扱えるので、時系列データとしてグラフ化もできている。

やったぜ。🎉

おわり

mtailでnginxのログファイルをメトリクス化できた。
nginxに限らず、ログのフォーマットが決まっていてそれにマッチする正規表現が書ければ何でもメトリクス化できるのでかなり便利だと思った。　　

おまけ

COVID-19ワクチン(モデルナ筋注)を打った

Wed, 11 Aug 2021 00:00:00 +0000

はじめに(予防線)

これはCOVID-19ワクチンモデルナ筋注を打った私個人の感想を書きなぐっただけの自己満日記です。
COVID-19やそれに関連する情報に対する個人の思想等は極力切り離して客観的に書いたつもりです。
特定の人物または団体を攻撃したり擁護するような意図はなく、
読者に同ワクチンの接種を強く勧めたり逆に止めさせようということもありません。
仮にそう読めたとしてもそれは筆者の未熟な文章力によるものなのでお察しください。

まとめ

COVID-19ワクチンモデルナ筋注を打った
筋肉注射は痛くなかったり痛かったりした
- 1回目と2回目で別の腕に打っても問題ないらしい
副反応は軽めだった
- 1回目はほぼ何もなし
- 2回目は体調を崩したが接種翌々日以降は何もなし
ある程度体調を崩すのに備えておいてよかった

予約前に厚生労働省のサイト²はちょっとだけ読んだ。
化学はさっぱりなので成分とかはよくわからなかったけど、臨床試験の概要とか統計のとり方はおもしろかった。
副反応があるという話は聞いていたので、それに備えてスポーツドリンクと頭に貼る冷却シートを多めに用意した。

当日は午前10時~12時ごろに接種。
健康状態は問題なく、普通に問診してそのままワクチンを打ってもらった。

利き腕が右なので左肩に注射。
結構ガッツリ肩を出して打ってもらうので、半袖Tシャツを着ていったのは正解だったと思う。
筋肉注射がたぶん初めてなので緊張していたが、担当の方が上手だったのか針が刺さっていることすら気づかず数秒で接種終了。
当日は激しい運動をしない、打ったところは強く触らないように言われた。³

接種後は会場内の椅子に座って15分待つよう指示があった。
持病があったりしてリスクの高い人は30分待つように言われる場合もあるらしい。
待機する場所には接種を終えた人(年齢性別バラバラ)がだいたい10~30人くらいいた。
緊急時に備えて看護師?医師?の方が複数人準備してくれていたが、自分がお世話になることはなかったし、周りで具合が悪くなった人もいなかった。

幸いなことに15分経っても何も起こらなかったのでそのまま退場。
後述のとおり副反応?も軽かったので普通に仕事をして、
昼ごはんは担々麺、晩ごはんはラーメンを食べて帰宅後はシャワーを少しだけ短めに浴びて普通に寝た。

副反応?(1回目)

一応副反応というか普段と接種後で違う体の症状は次のようなものがあった。

注射した左腕に筋肉痛に似た症状(接種から2時間後~24時間後)
- 腕を体の前方に向かって挙げる動き(フロントレイズ)はちょっと痛い
- 体の横から腕を挙げる動き(サイドレイズ)はめちゃくちゃ痛い
顎の下のリンパ節？のあたりに痛み(接種から24時間後~48時間後)
- 口を閉じていると特に気にならないが、大きく口をあけたり手で押すと痛い
下痢(接種当日夜)

とはいえ、特に生活に支障をきたすほどの症状はなかった。
翌日以降も顎下リンパ節?の痛み以外は何もなかったのでこれまで通りの生活をした。

接種(2回目)

1回目とほぼ同じ時間帯に同じように接種。

違う点があったとすれば、
接種前日までにトラブルがあり左肩を強く打って内出血していたので、
1回目とは異なり利き腕の右肩に注射を打ってもらった。
問診のときに心配になって質問したけど、1回目と2回目で違う腕に打っても効果に問題はないらしい。

また、2回目の注射は針が刺さったのがわかるくらいの痛みがちょっとだけあった。
このあたりは打つ人のテクニックによる気がする。

接種後の指示も1回目とは変わらず、同じように待機して同じように何もなかったので同じように退場。
後述のだるさがあったので仕事も早めに切り上げた。
昼ごはんはカレー、晩ごはんはラーメンを食べて軽くシャワーを浴びていつもより早めに寝た。

副反応?(2回目)

前評判どおり2回目は1回目よりも体調の変化が大きかった。

注射した右腕に筋肉痛に似た症状(接種から2時間後~12時間後)
- 1回目とだいたい同じだが、期間がちょっと短く接種当日の夜には治まった
全身の疲労感、関節の痛み、眠気(接種から4時間後~36時間後)
- 座ってるとなにもしたくなくなる、すぐ横になりたくなるくらいのだるさ
発熱(接種から24時間後~36時間後)
- 平熱+2℃くらい
- 寝ている間に熱でうなされて目が冷めた
下痢(接種当日~翌日夕方)

特に翌日朝からの発熱がつらかった。
風邪のときほど苦しくはないけど、動くのがめんどくさかったり食欲が出なかったりで夕方まで寝て過ごした。
1回目の接種前に用意した冷却シートがまるまる残っていたのと、保冷剤を首や脇に当てたおかげでいくらか楽だった。
とにかく喉が渇いたので、スポーツドリンクを多めに用意しておいたのも正解だったと思う。

俺が発熱してるのでねこが暖をとりにきた pic.twitter.com/FpddgoBsRF
— ずみし (@uzimihsr) July 27, 2021

2回目の副反応?はその後接種翌日の夕方(接種から36時間後)にはほとんどおさまり、
以降は大きく体調を崩すこともなかった。
(この記事は2回目の接種から2週後に書いているが、今現在体調で困っていることはない)

周りで同じワクチンを接種した人の話を聞くともっと高い熱が2日以上出たケースもあったみたいで、
自分はかなり軽く済んだ方だったらしい。
よかった(?)。

おわり

COVID-19のワクチンについて周りの人の話やメディアを見ると「副反応が強い」というケースが多いように見えたので、
副反応が結構軽め(?)だった人の話も少しはあると良いかと思って駄文を書いてみた。
若者と呼ばれる世代の中では比較的早めに打ったほうだと思うので、人柱として誰かの参考になればいいと思う。

おまけ

7月のそとちゃん(2021)

Sun, 08 Aug 2021 00:00:00 +0000

まとめ

かわいいポーズ
パソコン妨害ねこ

かわいいポーズ

そとちゃんの得意技、おでこを床につけるポーズ

はみがき断固拒否のポーズ pic.twitter.com/FfkCxGBvM2
— ずみし (@uzimihsr) July 1, 2021

甘えてるのか「かかってこいや」なのかはわからないけど、
特に夕方のごはん前とか俺が外出して戻ってきたときによくやる。

ちなみにこのときおなかを触るとバチボコに噛んで掴んで蹴ってくる。

椅子取られた pic.twitter.com/TqR1zFoYMx
— ずみし (@uzimihsr) July 7, 2021

かわいい。🥰

パソコン妨害ねこ

ちょっと前まで仕事はMacBookを普通に開いてやっていたんだけど、
最近ついにディスプレイを買ってMacBookを閉じて使うようになった。

机が広くなって快適！生産性向上！
と思ったのだが、うちには妖怪パソコン妨害ねこちゃんがいるのを忘れていた。

仕事バチクソ妨害ねこちゃんが現れた pic.twitter.com/nSR5Xde428
— ずみし (@uzimihsr) July 29, 2021

まずはシンプルに画面を観にくるパターン。

これがエスカレートすると次はディスプレイとキーボードの間に挟まってくる。

このとき躊躇なくキーを踏んだりするので普通に仕事に支障をきたす。

また、今までトラックパッドで作業していたのをマウスに変えたのだが、
これがそとちゃんの新たなおもちゃになってしまった。

マウスは枕 pic.twitter.com/ftCYn2UfXZ
— ずみし (@uzimihsr) July 31, 2021

マウスの滑りが良いので、
力の弱いそとちゃんでもかんたんに動かせるのが楽しいらしい。

マウスを机から落としてご満悦 pic.twitter.com/hKeaNWWO3J
— ずみし (@uzimihsr) July 29, 2021

よかったね。😭

おわり

7月のそとちゃんはよくつっかかってきた。

これまでに比べるとちょっと出社が多かったり(月に数回だが…)して寂しい思いをさせているので、
またあまえんぼ期がきているかもしれない。

おまけ

Kubernetesのsample-controllerをDeploymentとして動かす

Tue, 13 Jul 2021 00:00:00 +0000

やったことのまとめ

sample-controllerをDeploymentとしてkindのクラスタ内で動かした

つかうもの

macOS Big Sur 11.2.3
Docker Desktop for Mac
- Version 3.4.0
- Docker Engine Version 20.10.7
- Docker Compose Version 1.29.2
kind
- v0.11.0 go1.16.4 darwin/amd64
Kubernetes
- v1.21.1

やったこと

コードの修正とimageのビルド
kindでローカルimageを使う設定とDeploymentの作成
ClusterRoleとClusterRoleBindingの作成
再度動かしてみる

コードの修正とimageのビルド

前回sample-controllerを動かしたときはコントローラー自体はクラスタ外で動かし,
Kubernetes APIへの接続にはローカルのkubeconfigを使用していた.

今回はコントローラー自体もPodとしてクラスタ内で動かすため,
Kubernetes APIに接続するための情報をPodに持たせる必要がある.

ここで使えるのがclient-goのrest.InClusterConfig().
PodにマウントされたServiceAccountのトークンを使ってKubernetes APIへ接続する設定を作ってくれる¹.

kubeconfigを使わないようにしたmain.go

rest.InClusterConfig()を使うようにコードを書き換えた状態でDocker imageをビルドする.

DockerfileはGo用のものをいい感じに書いてみた.

# Docker imageのビルド
$ ls Dockerfile
Dockerfile
$ docker image build -t sample-controller:develop .

# Dockerでこのまま実行しても必要な情報が無いので怒られる
$ docker container run sample-controller:develop
panic: unable to load in-cluster configuration, KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT must be defined

goroutine 1 [running]:
main.main()
	/sample-controller/main.go:56 +0x685

とりあえず動きそう.

kindでローカルimageを使う設定とDeploymentの作成

次にローカルでビルドしたカスタムコントローラーのDocker imageをkindで作ったクラスタで使えるように設定する².

# CRDが作成されていない場合は作成しておく
$ kubectl apply -f artifacts/examples/crd.yaml
customresourcedefinition.apiextensions.k8s.io/foos.samplecontroller.k8s.io created

# ローカルDockerのimageをkindのクラスタで使えるようにする
$ kind load docker-image sample-controller:develop
Image: "sample-controller:develop" with ID "sha256:dde0eac9c3c272e80dc1e98c705c34ddf35b7d5c585fc32364563d2d96db386d" not yet present on node "kind-control-plane", loading...

このimageを使ったDeploymentを作成する.

# Deploymentの作成
$ kubectl create deployment sample-controller --image=sample-controller:develop
deployment.apps/sample-controller created
$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
sample-controller 1/1 1 1 2m11s
$ kubectl get pods -l app=sample-controller
NAME READY STATUS RESTARTS AGE
sample-controller-f48d54cf4-drqwl 1/1 Running 0 2m31s

# PodにデフォルトのServiceAccount(default:default)が設定されている
# Tokenなどの情報が/var/run/secrets/kubernetes.io/serviceaccountにマウントされている(rest.InClusterConfig()はこれを参照している)
$ kubectl get pod sample-controller-f48d54cf4-drqwl -o yaml
apiVersion: v1
kind: Pod
metadata:
 ...
spec:
 containers:
 - image: sample-controller:develop
 ...
 name: sample-controller
 ...
 volumeMounts:
 - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
 name: kube-api-access-vx85f
 readOnly: true
 ...
 serviceAccount: default
 serviceAccountName: default
 ...
 volumes:
 - name: kube-api-access-vx85f
 projected:
 defaultMode: 420
 sources:
 - serviceAccountToken:
 expirationSeconds: 3607
 path: token
 - configMap:
 items:
 - key: ca.crt
 path: ca.crt
 name: kube-root-ca.crt
 - downwardAPI:
 items:
 - fieldRef:
 apiVersion: v1
 fieldPath: metadata.namespace
 path: namespace

すると今度はDockerで動かしたときと異なり,
ServiceAccountの情報が取得できるのでコントローラーが動いた!

…が, 次はPodに自動で紐づくデフォルトのServiceAccount(default:default)にこのコントローラーで操作するDeploymentとFoo(カスタムリソース)の一覧を取得する権限(list)がないためエラーになってしまった.

# 今度はconfigが作成できて動作を開始している
# ...が, DeploymentとFoo(カスタムリソース)を参照する権限がないためうまく動いていない
$ kubectl logs sample-controller-f48d54cf4-drqwl
I0707 09:01:00.813715 1 controller.go:115] Setting up event handlers
I0707 09:01:00.813806 1 controller.go:156] Starting Foo controller
I0707 09:01:00.813810 1 controller.go:159] Waiting for informer caches to sync
E0707 09:01:00.826284 1 reflector.go:138] pkg/mod/k8s.io/client-go@v0.0.0-20210701054555-843bb800b12a/tools/cache/reflector.go:167: Failed to watch *v1alpha1.Foo: failed to list *v1alpha1.Foo: foos.samplecontroller.k8s.io is forbidden: User "system:serviceaccount:default:default" cannot list resource "foos" in API group "samplecontroller.k8s.io" at the cluster scope
E0707 09:01:00.826385 1 reflector.go:138] pkg/mod/k8s.io/client-go@v0.0.0-20210701054555-843bb800b12a/tools/cache/reflector.go:167: Failed to watch *v1.Deployment: failed to list *v1.Deployment: deployments.apps is forbidden: User "system:serviceaccount:default:default" cannot list resource "deployments" in API group "apps" at the cluster scope
...(以下繰り返し)

# いったん消しておく
$ kubectl delete deployment sample-controller
deployment.apps "sample-controller" deleted

ClusterRoleとClusterRoleBindingの作成

というわけで次はServiceAccountでDeployemntとFooのリソースを操作するための権限(ClusterRole)を作成する.
今回は使用するsample-controllerが全namespaceを対象に操作を行うため³,
namespaceレベルの権限のRoleではなくクラスタレベルのClusterRoleを使用した.

# ClusterRoleの作成
# DeploymentとFoo(カスタムリソース)とEventに対する全ての操作を許可する権限
$ kubectl create clusterrole foo-control --verb="*" --resource=foo,deployment,event
clusterrole.rbac.authorization.k8s.io/foo-control created
$ kubectl get clusterrole foo-control -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 creationTimestamp: "2021-07-12T14:04:28Z"
 name: foo-control
 resourceVersion: "4126888"
 uid: 9b628c44-0320-48eb-8861-0e3c5d8f9ddf
rules:
- apiGroups:
 - ""
 resources:
 - events
 verbs:
 - '*'
- apiGroups:
 - apps
 resources:
 - deployments
 verbs:
 - '*'
- apiGroups:
 - samplecontroller.k8s.io
 resources:
 - foos
 verbs:
 - '*'

最後に, 作成したClusterRoleをServiceAccountに紐付けるためのClusterRoleBindingを作成する.

# ClusterRoleBindingの作成
# ClusterRole(foo-control)をServiceAccount(default:default)に紐付ける
$ kubectl create clusterrolebinding foo-control-binding --clusterrole=foo-control --serviceaccount=default:default
clusterrolebinding.rbac.authorization.k8s.io/foo-control-binding created
$ kubectl get clusterrolebinding foo-control-binding -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 creationTimestamp: "2021-07-12T14:06:04Z"
 name: foo-control-binding
 resourceVersion: "4127049"
 uid: 09bde8fd-752a-433b-845a-5584aa1324a8
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: foo-control
subjects:
- kind: ServiceAccount
 name: default
 namespace: default

これでPodにデフォルトで紐づくServiceAccount(default:default)にクラスタ内のDeploymentとFoo(カスタムリソース)を操作する権限が与えられた.

再度動かしてみる

以上でコントローラーをDeploymentとして動かすために必要な準備ができたはずなので,
もう一度挑戦してみる.

# Deploymentの作成
$ kubectl create deployment sample-controller --image=sample-controller:develop
deployment.apps/sample-controller created
$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
sample-controller 1/1 1 1 8s
$ kubectl get pods -l app=sample-controller
NAME READY STATUS RESTARTS AGE
sample-controller-f48d54cf4-jgv4w 1/1 Running 0 12s

# 動いた...!
$ kubectl logs sample-controller-f48d54cf4-jgv4w
I0712 14:07:14.403608 1 controller.go:115] Setting up event handlers
I0712 14:07:14.404169 1 controller.go:156] Starting Foo controller
I0712 14:07:14.404319 1 controller.go:159] Waiting for informer caches to sync
I0712 14:07:14.705485 1 controller.go:164] Starting workers
I0712 14:07:14.706297 1 controller.go:170] Started workers

動いた…!
Podのログの内容も前回と同じで, 問題なく動いているように見える.

最後にFooリソースを作成してみる.

# Fooを作成
$ cat << EOF | kubectl apply -f -
apiVersion: samplecontroller.k8s.io/v1alpha1
kind: Foo
metadata:
 name: my-foo
spec:
 deploymentName: my-foo
 replicas: 10
EOF
foo.samplecontroller.k8s.io/my-foo created

# Fooとそれによって管理されるDeploymentが作成されている
$ kubectl get foo
NAME AGE
my-foo 40s
$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
my-foo 10/10 10 10 27s
sample-controller 1/1 1 1 5m15s
$ kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
my-foo-65f55f8578-2j2g6 1/1 Running 0 47s app=nginx,controller=my-foo,pod-template-hash=65f55f8578
my-foo-65f55f8578-44tbj 1/1 Running 0 47s app=nginx,controller=my-foo,pod-template-hash=65f55f8578
my-foo-65f55f8578-5n58m 1/1 Running 0 47s app=nginx,controller=my-foo,pod-template-hash=65f55f8578
my-foo-65f55f8578-bdtwp 1/1 Running 0 47s app=nginx,controller=my-foo,pod-template-hash=65f55f8578
my-foo-65f55f8578-gq7hh 1/1 Running 0 47s app=nginx,controller=my-foo,pod-template-hash=65f55f8578
my-foo-65f55f8578-jb258 1/1 Running 0 47s app=nginx,controller=my-foo,pod-template-hash=65f55f8578
my-foo-65f55f8578-kr6mt 1/1 Running 0 47s app=nginx,controller=my-foo,pod-template-hash=65f55f8578
my-foo-65f55f8578-mmtlk 1/1 Running 0 47s app=nginx,controller=my-foo,pod-template-hash=65f55f8578
my-foo-65f55f8578-pk847 1/1 Running 0 47s app=nginx,controller=my-foo,pod-template-hash=65f55f8578
my-foo-65f55f8578-vpvf6 1/1 Running 0 47s app=nginx,controller=my-foo,pod-template-hash=65f55f8578
sample-controller-f48d54cf4-jgv4w 1/1 Running 0 5m35s app=sample-controller,pod-template-hash=f48d54cf4

# Fooで管理されているのでDeploymentを手で消してもすぐ復活する
$ kubectl delete deployment my-foo
deployment.apps "my-foo" deleted
$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
my-foo 0/10 10 0 17s
sample-controller 1/1 1 1 6m58s

# Statusも正常に更新されている
$ kubectl get foo my-foo -o yaml
apiVersion: samplecontroller.k8s.io/v1alpha1
kind: Foo
metadata:
 annotations:
 kubectl.kubernetes.io/last-applied-configuration: |
 {"apiVersion":"samplecontroller.k8s.io/v1alpha1","kind":"Foo","metadata":{"annotations":{},"name":"my-foo","namespace":"default"},"spec":{"deploymentName":"my-foo","replicas":10}}
 creationTimestamp: "2021-07-12T14:11:58Z"
 generation: 23
 name: my-foo
 namespace: default
 resourceVersion: "4128510"
 uid: a38bc894-769c-4dd0-9d2b-8b3be3ec864b
spec:
 deploymentName: my-foo
 replicas: 10
status:
 availableReplicas: 10

# ログを見る限り正常にEventも吐かれている
$ kubectl logs -f sample-controller-f48d54cf4-jgv4w
I0712 14:07:14.403608 1 controller.go:115] Setting up event handlers
I0712 14:07:14.404169 1 controller.go:156] Starting Foo controller
I0712 14:07:14.404319 1 controller.go:159] Waiting for informer caches to sync
I0712 14:07:14.705485 1 controller.go:164] Starting workers
I0712 14:07:14.706297 1 controller.go:170] Started workers
I0712 14:11:58.920953 1 controller.go:228] Successfully synced 'default/my-foo'
I0712 14:11:58.948805 1 event.go:291] "Event occurred" object="default/my-foo" kind="Foo" apiVersion="samplecontroller.k8s.io/v1alpha1" type="Normal" reason="Synced" message="Foo synced successfully"
...(以下繰り返し)

Deploymentとして動かしたコントローラーでもちゃんとカスタムリソース(Foo)の管理ができた.
やったぜ.

おわり

sample-controllerをDocker image化して, Deploymentとして動かすことができた.

途中権限まわりでちょっとつまづいたけどなんとか乗り切れたので謎の達成感がある. うれしい.

次は自分でカスタムコントローラーを書いてみたいけど, だいぶめんどくさい…

おまけ

Kubernetesのsample-controllerで遊ぶ

Mon, 12 Jul 2021 00:00:00 +0000

やったことのまとめ

sample-controllerを読んで動かしてCRD(CustomResourceDefinition)とCustom Controllerの概要をつかんだ

つかうもの

macOS Big Sur 11.2.3
Docker Desktop for Mac
- Version 3.4.0
- Docker Engine Version 20.10.7
- Docker Compose Version 1.29.2
kind
- v0.11.0 go1.16.4 darwin/amd64
Kubernetes
- v1.21.1

やったこと

CRDの作成
Controllerのデプロイ

CRDの作成

Kubernetesには既存のPodやDeploymentなどのリソースに加えて独自のリソースを定義できるCustomResourceDefinition(CRD)¹というリソースがある.
これを使うことで既存のリソースでは物足りない機能なんかを自分で作ることができるらしい. すごい.

CRDを自分で書くのは骨が折れるので, 今回は公式のsample-controllerに付属のCRDを使ってみる.
https://github.com/kubernetes/sample-controller/blob/master/artifacts/examples/crd.yaml

動かす前に重要そうな設定項目(ほんとは全部重要だが…)を確認しておく.

key	value
`apiVersion`	“apiextensions.k8s.io/v1"で固定
`kind`	“CustomResourceDefinition"で固定
`metadata.name`	“{spec.names.plural}.{spec.group}“とする
`spec.group`	KubernetesのREST APIで使用するgroup
`spec.versions[].name`	KubernetesのREST APIで使用するAPIのversion
`spec.versions[].schema`	CustomResourceの構造の定義(たぶん一番重要)
`spec.scope`	CustomResourceをNamespace単位で管理する場合:“Namespaced”, Cluster単位で管理する場合:“Cluster”
`spec.names`	Kubernetes APIやkubectlで扱うときの名前の定義

これを実際にクラスタに適用する.

# CRDを適用
$ pwd
/path/to/sample-controller
$ kubectl apply -f artifacts/examples/crd.yaml
customresourcedefinition.apiextensions.k8s.io/foos.samplecontroller.k8s.io created
$ kubectl get crd
NAME CREATED AT
foos.samplecontroller.k8s.io 2021-06-28T13:49:53Z

# CRDで定義したリソース(Foo)がAPIで操作可能になる
$ kubectl api-resources | grep foo
foos samplecontroller.k8s.io/v1alpha1 true Foo

クラスタにCRD(foos.samplecontroller.k8s.io)が追加された.

次にこのCRDに従ったリソースを作成する.
https://github.com/kubernetes/sample-controller/blob/master/artifacts/examples/example-foo.yaml

# CustomResourceを作成
$ kubectl apply -f artifacts/examples/example-foo.yaml
foo.samplecontroller.k8s.io/example-foo created

# CRDで定義した名前(Foo)で参照できる
$ kubectl get foo
NAME AGE
example-foo 105s
$ kubectl get foo example-foo -o yaml
apiVersion: samplecontroller.k8s.io/v1alpha1
kind: Foo
metadata:
 annotations:
 kubectl.kubernetes.io/last-applied-configuration: |
 {"apiVersion":"samplecontroller.k8s.io/v1alpha1","kind":"Foo","metadata":{"annotations":{},"name":"example-foo","namespace":"default"},"spec":{"deploymentName":"example-foo","replicas":1}}
 creationTimestamp: "2021-06-28T13:59:25Z"
 generation: 1
 name: example-foo
 namespace: default
 resourceVersion: "2385464"
 uid: 560ced47-d085-4b92-b92c-1be78639f878
spec:
 deploymentName: example-foo
 replicas: 1
$ kubectl delete foo example-foo
foo.samplecontroller.k8s.io "example-foo" deleted

apiVersion, kindがCRDで独自に定義した内容に合致しているので,
それに沿ったFooというリソースを作成することができた.

ただし, この時点ではただ構造化されたデータがREST APIで扱えるようになっただけで,
このリソースがどういった振る舞いをするかなどの情報はどこにも定義されていない.

これについては次のカスタムコントローラーで定義していく.

Controllerのデプロイ

カスタムコントローラーではリソースのstatusがspecで定義した所望の状態に近づくように対象のオブジェクトについて操作を繰り返す.
これを自分で書くのは大変なので, こちらも公式のサンプルをそのまま使う.
https://github.com/kubernetes/sample-controller/blob/master/controller.go

実際に動かす前にこのコントローラーを構成するコンポーネントについて確認しておく.

Informer
- Kubernetes API(正確にはAPIをwatchしたReflectorによってオブジェクトが追加されたキュー)から変化のあったオブジェクトを順番に取り出す
- 取り出したオブジェクトをIndexerに渡す
- オブジェクトの状態に応じたEvent Handlerを呼び出す
Indexer
- Informerから受け取ったオブジェクトをメタ情報(namespace/オブジェクト名)で参照可能な状態にしてスレッドセーフな領域に保持する
- 必要なKeyが与えられた場合は対象のオブジェクトを返す
Resource Event Handlers
- Informerで取り出したオブジェクトの状態に応じた処理を行う
- 基本的には対象のオブジェクトのKeyをWork queueに追加する
Work queue
- 処理が必要なオブジェクトのKeyを保持するキュー
Process Item
- Work queueから取り出したKeyを参照してIndexerからオブジェクトを取り出し必要な操作を行う

(画像は公式²のもの)

この中で実際のCRD(Foo)の挙動を決めているのはProcess Itemの部分で,
今回使用するコントローラーの場合はsyncHandler()³がそれにあたる.

syncHandler()により, FooというCRDは

SpecにDeployment名とレプリカ数の情報を, Statusに利用可能なレプリカ数の情報を持つ(ここまではCRDで定義)
nginxコンテナ1台のPodをSpecで定義されたレプリカ数ぶん保持するDeploymentを管理する(syncHandler()で定義)
- Deploymentがなければ作り, Deploymentが保持するPod数(レプリカ数)がSpecで定義されたレプリカ数を満たすようDeploymentを更新する
Deploymentの状態によってStatusを更新する(syncHandler()で定義)

という振る舞いをするリソースとなる.

実際にカスタムコントローラーを動かしてみる.

# カスタムコントローラーのビルド
$ go build -o sample-controller .

# 有効なkubeconfigを指定して起動
$ ./sample-controller -kubeconfig=$HOME/.kube/config
I0704 00:35:30.758496 96780 controller.go:115] Setting up event handlers
I0704 00:35:30.758719 96780 controller.go:156] Starting Foo controller
I0704 00:35:30.758731 96780 controller.go:159] Waiting for informer caches to sync
I0704 00:35:30.858942 96780 controller.go:164] Starting workers
I0704 00:35:30.858973 96780 controller.go:170] Started workers

# (別のターミナルで実行)Fooリソースの作成
$ kubectl apply -f artifacts/examples/example-foo.yaml

# カスタムコントローラー適用前とは異なりstatusに変化が生じている
$ kubectl get foo example-foo -o yaml
apiVersion: samplecontroller.k8s.io/v1alpha1
kind: Foo
metadata:
 annotations:
 kubectl.kubernetes.io/last-applied-configuration: |
 {"apiVersion":"samplecontroller.k8s.io/v1alpha1","kind":"Foo","metadata":{"annotations":{},"name":"example-foo","namespace":"default"},"spec":{"deploymentName":"example-foo","replicas":1}}
 creationTimestamp: "2021-07-03T15:37:32Z"
 generation: 3
 name: example-foo
 namespace: default
 resourceVersion: "3127576"
 uid: 5bbab9a1-0baf-41b1-8f68-93be619a6048
spec:
 deploymentName: example-foo
 replicas: 1
status:
 availableReplicas: 1

# Fooで定義されたDeploymentが作成されている
$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
example-foo 1/1 1 1 96s

# Deploymentを削除してもカスタムコントローラーによりFooのspecを満たすようにすぐ再作成される
$ kubectl delete deployment example-foo
deployment.apps "example-foo" deleted
$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
example-foo 1/1 1 1 5s

# FooリソースのSpecをいじっても問題なく作成できる
$ cat << EOF | kubectl apply -f -
apiVersion: samplecontroller.k8s.io/v1alpha1
kind: Foo
metadata:
 name: my-foo
spec:
 deploymentName: my-foo
 replicas: 10
EOF
$ kubectl get foo my-foo
NAME AGE
my-foo 23s
$ kubectl get deployment my-foo
NAME READY UP-TO-DATE AVAILABLE AGE
my-foo 10/10 10 10 36s

CRD(Foo)で定義したリソースに対して所望の処理が行われることが確認できた.

ここで面白いのはこのコントローラーがクラスタ外で稼働しているという点.

各種リソースの操作はKubernetes APIを通じて行われるので,
APIに接続さえできればコントローラーの実体はどこで動いていても関係ないらしい.
(デフォルトのkube-controller-managerと同様にDeploymentとして動かしても問題ないはず)

おわり

CRDとカスタムコントローラーのサンプルで遊んでみた.

実際にコードを読んだりしてカスタムリソースとかコントローラーの仕組みがわかった気がする.

時間があれば今回使ったカスタムコントローラーをクラスタ内でDeploymentとして動かしてみたい.

おまけ

6月のそとちゃんまとめ(2021)

Thu, 08 Jul 2021 00:00:00 +0000

まとめ

イス
おもちゃ
目ヤニがひどい

イス

そとちゃんが以前にも増して仕事用のイスに座るようになった.

仕事だめです pic.twitter.com/bINUc9pAab
— ずみし (@uzimihsr) June 3, 2021

前はたまに座っている程度だったのが,
今ではほぼ毎朝, というか俺が座っていないときは基本的にそとちゃんが座っている.
おかげで仕事を始めるのがいつも遅くなる…

もういる pic.twitter.com/qqDOhstuVR
— ずみし (@uzimihsr) June 9, 2021

おもちゃで気を引くと降りてくれるんだけど,
休憩とかで一時的に離席するとその間にまた座っちゃう.

昼休憩 pic.twitter.com/aYl0sp6zzq
— ずみし (@uzimihsr) June 22, 2021

イスの座り心地が気に入っているのと,
どうも"ここに座るとかまってもらえる"と覚えてしまったように思う.
かしこい.

またいる pic.twitter.com/7EBNE8qOkC
— ずみし (@uzimihsr) June 10, 2021

でもたまに俺が座ってるときに"どけ!“って言ってる気もする.

お昼寝終わっていきなりにゃんにゃん騒ぐから何事かと思ったら椅子を譲れということだった pic.twitter.com/b0jBCViXhH
— ずみし (@uzimihsr) May 31, 2021

なんでこんなに座りたがるのかはよくわからないが座っているときはとりあえず機嫌が良いので助かる.
あとかわいい.😊

ご満悦 pic.twitter.com/ciAjNIslWf
— ずみし (@uzimihsr) June 28, 2021

おもちゃ

またおもちゃをいくつか買ってしまった.

まずはねこじゃらし.
本物のエノコログサではなく人工のやつだけど, 割と喰い付きが良い.

じゃれ猫　猫のお遊び草　２本セット

緑と茶色の2本入りで, そとちゃん的には緑色のほうが好きみたい.

これ"は"買ってよかった.

次はこのニジマス.

ニジマス pic.twitter.com/voQLvW0Sr8
— ずみし (@uzimihsr) June 13, 2021

じゃれぐるみ

中にマタタビの枝と葉っぱがパンパンに詰まっているヤバいブツとの評判に期待して購入.
評判通り, 俺の鼻でもわかるくらいにマタタビの匂いがプンプンする.

またたびジャンキーのそとちゃんは大興奮!

…だったのは初日だけ.

初めこそ本能むき出しでベロンベロンに舐めていたものの,
表面のマタタビが薄くなってからはたまに匂いを嗅ぐくらいになった.

あとこのニジマスの重さが200gくらいあって,
あんまり力が強くないそとちゃんには咥えて歩いたりするのも難しかったみたい.

ちなみに今までまたたびをあげたときも匂いを嗅ぐよりベロベロ舐めて舐めてトリップすることが多かった気がする.
鼻から吸うより経口摂取のほうが"効く"んだろうか…?🤔

最後は猫ちゃんテンション爆アゲＢＯＸ.

猫ちゃんテンション爆アゲBOXを買いました pic.twitter.com/xFrXfryxH1
— ずみし (@uzimihsr) June 24, 2021

開ける前からわかる圧倒的出オチ感.

完成前からテンション爆アゲ pic.twitter.com/nnjzh6LRES
— ずみし (@uzimihsr) June 24, 2021

…結局組み立て中がピークで,
完成直後にちょっと遊んだだけで二度とテンションが爆アゲすることはなかった.

はい.😭

目ヤニがひどい

ちょっと暖かくなって湿度も上がるとそとちゃんの右目の目ヤニがひどくなってくる.

そとちゃんは子猫のころの猫風邪の後遺症で右目の涙腺が詰まっていて,
涙がそのまま目から溢れてしまって目ヤニができやすい.

因果関係はよくわからないけど,
寒くて乾燥していた時期に比べるとその症状がひどくなるように思う.

お昼寝の後とかはちょっと痛々しいくらいに茶色い目やにが固まってしまうのがかわいそう.
こまめに拭いてはいるのだが…😭

おわり

梅雨の時期は部屋がじめじめするし,
外の景色もどんよりしていてそとちゃんもあまり元気がなさそう.

そとちゃんがだらだらごろごろしてるのもかわいいけど,
このままだと運動不足になっちゃうのではやく梅雨明けしてほしい.

おまけ

KubernetesのactiveDeadlineSecondsはJobとPodでちょっと違う

Sat, 12 Jun 2021 00:00:00 +0000

まとめ

KubernetesのPodとJobにそれぞれ稼働時間の上限activeDeadlineSecondsが指定できるけど, ちょっと挙動が違うので調べてみた.

種類	`activeDeadlineSeconds`超過時の挙動
`Pod`	`kubelet`によりコンテナがKILL(停止)される `Kubernetes API`上には`phase:Failed`の`Pod`が残る `node`上には停止したコンテナが残る `Pod`とコンテナはガベージコレクションのタイミングで削除される
`Job`	`Job Controller`により`phase:Active`の`Pod`が明示的に削除される (それ以外のphaseは残る) `Kubernetes API`上には`Job`が残り, `Pod`は削除される `Pod`が削除されるため, `node`上のコンテナも削除される

環境

macOS Big Sur 11.2.3
Docker Desktop for Mac
- Version 3.4.0
- Docker Engine Version 20.10.7
- Docker Compose Version 1.29.2
kind
- v0.11.0 go1.16.4 darwin/amd64
Kubernetes
- v1.21.1

$ kubectl explain pod.spec.activeDeadlineSeconds
KIND: Pod
VERSION: v1

FIELD: activeDeadlineSeconds <integer>

DESCRIPTION:
 Optional duration in seconds the pod may be active on the node relative to
 StartTime before the system will actively try to mark it failed and kill
 associated containers. Value must be a positive integer.

(意訳) Podが開始してからactiveDeadlineSecondsより長く稼働してるとシステムがPodを失敗扱いにしてコンテナをKILLするよ

ということで適当なPodを作成して確認してみる.

# Pod作成
$ kubectl apply -f pod-01.yaml

# Podが開始した時刻(startTime)の20秒後に削除されている(containerStatuses[].state.terminated.finishedAt)
# プロセスのexitCodeが137(シグナルを受けて終了)となっているので, 
# おそらくkubeletからコンテナランタイム(containerd)経由でSIGTERMが送られている.
$ kubectl get pod -o yaml pod-01 | yq -C r - "status"
containerStatuses:
 - containerID: containerd://f32f5d2995838397faaf0d2c4f312d941c1047001cb85e968fb4685cc75b5bda
 image: docker.io/library/busybox:latest
 imageID: docker.io/library/busybox@sha256:930490f97e5b921535c153e0e7110d251134cc4b72bbb8133c6a5065cc68580d
 lastState: {}
 name: main-container
 ready: false
 restartCount: 0
 state:
 terminated:
 containerID: containerd://f32f5d2995838397faaf0d2c4f312d941c1047001cb85e968fb4685cc75b5bda
 exitCode: 137
 finishedAt: "2021-06-11T13:32:19Z"
 reason: Error
 startedAt: "2021-06-11T13:31:31Z"
message: Pod was active on the node longer than the specified deadline
phase: Failed
podIP: 10.244.0.36
podIPs:
 - ip: 10.244.0.36
qosClass: Guaranteed
reason: DeadlineExceeded
startTime: "2021-06-11T13:31:29Z"

# ログ(途中まで)は残っている
$ kubectl logs pod-01 --timestamps
2021-06-11T13:31:41.951165516Z 1
2021-06-11T13:31:51.933749153Z 2
2021-06-11T13:32:01.934770631Z 3
2021-06-11T13:32:11.936129723Z 4

起動した時刻(startTime)からactiveDeadlineSecondsで設定した秒数以上経過したあと(containerStatuses[].state.terminated.finishedAt)にPodがphase:Failedになっている.
(たぶん同期のタイミングとかで少し遅れている)

試しにnode上のコンテナの状態も確認してみる.

# kindなのでnodeもdockerコンテナとして動いている
$ docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
05f0d805c4dc kindest/node:v1.21.1 "/usr/local/bin/entr…" 25 hours ago Up 25 hours 127.0.0.1:53211->6443/tcp kind-control-plane

# nodeの中のコンテナをcontainerStatuses[].containerIDで探してみると確かにコンテナが残っている(プロセスは終了している)
$ docker container exec 05f0d805c4dc ctr --namespace k8s.io container ls | grep f32f5d2995838397faaf0d2c4f312d941c1047001cb85e968fb4685cc75b5bda
f32f5d2995838397faaf0d2c4f312d941c1047001cb85e968fb4685cc75b5bda docker.io/library/busybox:latest io.containerd.runc.v2

以上より,
Podの稼働時間がactiveDeadlineSecondsを超えてしまった場合はPodの情報がKubernetes APIに残り,
nodeにもコンテナの情報が残ることがわかった(プロセスはシグナルを受けて異常終了する).

JobのactiveDeadlineSeconds

JobにもactiveDeadlineSecondsを設定できる. 説明は以下の通り.

# JobのactiveDeadlineSecondsの説明
$ kubectl explain job.spec.activeDeadlineSeconds
KIND: Job
VERSION: batch/v1

FIELD: activeDeadlineSeconds <integer>

DESCRIPTION:
 Specifies the duration in seconds relative to the startTime that the job
 may be continuously active before the system tries to terminate it; value
 must be positive integer. If a Job is suspended (at creation or through an
 update), this timer will effectively be stopped and reset when the Job is
 resumed again.

(意訳) Jobが開始してからactiveDeadlineSecondsより長く稼働してるとシステムがJobを消すよ, アップデート(nodeの更新?)等でJobが中断した場合は再度稼働時間を数え直してくれるよ

Podのときと同様にJobを作成して動作を確認してみる.
コンテナの中身はだいたいおなじ.

# Job作成
$ kubectl apply -f job-01.yaml

# DeadlineExceededによりJobがFailedになっている
$ kubectl get job -o yaml job-01 | yq -C r - "status"
conditions:
 - lastProbeTime: "2021-06-11T14:02:17Z"
 lastTransitionTime: "2021-06-11T14:02:17Z"
 message: Job was active longer than specified deadline
 reason: DeadlineExceeded
 status: "True"
 type: Failed
failed: 1
startTime: "2021-06-11T14:01:57Z"

# Podが見つからない...
$ kubectl get pods -l job-name=job-01
No resources found in default namespace.
$ kubectl get pods
No resources found in default namespace.

# Eventを確認するとPod(job-01-xntdw)が明示的に削除されている
$ kubectl describe job job-01
...(省略)
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal SuccessfulCreate 7m44s job-controller Created pod: job-01-xntdw
 Normal SuccessfulDelete 7m24s job-controller Deleted pod: job-01-xntdw
 Warning DeadlineExceeded 7m24s job-controller Job was active longer than specified deadline

# 念の為nodeをimage名で探しても見つからない...
# (kindなのでnodeもdockerコンテナとして動いている)
$ docker container exec 05f0d805c4dc ctr --namespace k8s.io container ls | grep -c busybox
0

今度はJobは残っているもののPodが消えてしまった…
Jobの稼働時間がactiveDeadlineSecondsを超えた場合はPodがKubernetes APIから削除され,
node上のコンテナも削除されてしまうらしい.

ちなみにPodとJob両方にactiveDeadlineSecondsを設定した場合はどうなるか?
まずはPodのactiveDeadlineSeconds < JobのactiveDeadlineSecondsの条件で試してみる.

# Job作成
$ kubectl apply -f job-02.yaml

# 今度はDeadlineExceededでなくBackoffLimitExceededによりJobがFailedになっている
$ kubectl get job -o yaml job-02 | yq -C r - "status"
conditions:
 - lastProbeTime: "2021-06-11T14:30:25Z"
 lastTransitionTime: "2021-06-11T14:30:25Z"
 message: Job has reached the specified backoff limit
 reason: BackoffLimitExceeded
 status: "True"
 type: Failed
failed: 1
startTime: "2021-06-11T14:30:05Z"

# Podが残っている
$ kubectl get pods -l job-name=job-02
NAME READY STATUS RESTARTS AGE
job-02-d2w6v 0/1 Error 0 2m16s

# PodのactiveDeadlineSeconds超過時の挙動をしている
$ kubectl get pod -o yaml job-02-d2w6v | yq -C r - "status"
containerStatuses:
 - containerID: containerd://607cdbd019d8a1dc97473f6e62960ec68c0e70575b9c8dc7ac1fdfa18dab1dbd
 image: docker.io/library/busybox:latest
 imageID: docker.io/library/busybox@sha256:930490f97e5b921535c153e0e7110d251134cc4b72bbb8133c6a5065cc68580d
 lastState: {}
 name: main-container
 ready: false
 restartCount: 0
 state:
 terminated:
 containerID: containerd://607cdbd019d8a1dc97473f6e62960ec68c0e70575b9c8dc7ac1fdfa18dab1dbd
 exitCode: 137
 finishedAt: "2021-06-11T14:30:55Z"
 reason: Error
 startedAt: "2021-06-11T14:30:08Z"
message: Pod was active on the node longer than the specified deadline
phase: Failed
podIP: 10.244.0.39
podIPs:
 - ip: 10.244.0.39
qosClass: Guaranteed
reason: DeadlineExceeded
startTime: "2021-06-11T14:30:05Z"

# ログが残っている
$ kubectl logs job-02-d2w6v --timestamps
2021-06-11T14:30:18.567995219Z 1
2021-06-11T14:30:28.568766279Z 2
2021-06-11T14:30:38.570408867Z 3
2021-06-11T14:30:48.548898562Z 4

# nodeにコンテナも残っている
# (kindなのでnodeもdockerコンテナとして動いている)
$ docker container exec 05f0d805c4dc ctr --namespace k8s.io container ls | grep 607cdbd019d8a1dc97473f6e62960ec68c0e70575b9c8dc7ac1fdfa18dab1dbd
607cdbd019d8a1dc97473f6e62960ec68c0e70575b9c8dc7ac1fdfa18dab1dbd docker.io/library/busybox:latest io.containerd.runc.v2

おそらくPodのactiveDeadlineSecondsのほうが短いため, JobのactiveDeadlineSecondsを超える前にPodがphase:Failedになったように見える.

次にPodのactiveDeadlineSeconds > JobのactiveDeadlineSecondsの条件で試してみる.

# Job作成
$ kubectl apply -f job-03.yaml

# 今度はDeadlineExceededでJobがFailedになっている
$ kubectl get job -o yaml job-03 | yq -C r - "status"
conditions:
 - lastProbeTime: "2021-06-11T14:47:00Z"
 lastTransitionTime: "2021-06-11T14:47:00Z"
 message: Job was active longer than specified deadline
 reason: DeadlineExceeded
 status: "True"
 type: Failed
failed: 1
startTime: "2021-06-11T14:46:40Z"

# Podが残っていない
$ kubectl get pods -l job-name=job-03
No resources found in default namespace.

# Podが明示的に削除されている
$ kubectl describe job job-03
...(省略)
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal SuccessfulCreate 83s job-controller Created pod: job-03-h66hc
 Normal SuccessfulDelete 63s job-controller Deleted pod: job-03-h66hc
 Warning DeadlineExceeded 63s job-controller Job was active longer than specified deadline

# nodeを探してもコンテナが見つからない
# (kindなのでnodeもdockerコンテナとして動いている)
$ docker container exec 05f0d805c4dc ctr --namespace k8s.io container ls | grep -c busybox
0

今度はJobのactiveDeadlineSecondsのほうが短いため, その時点でphase:ActiveだったPodとコンテナが削除されてしまった.

詳しく見てみる

これらの挙動の違いはおそらく各オブジェクトを管理しているコンポーネントの違いから来ている.

Pod

Podはkubeletによって管理されていて,
activeDeadlineSecondsを超過している場合はactiveDeadlineHandler.ShouldEvict()¹とKubelet.generateAPIPodStatus()²によってKubernetes API上のPodがphase:Failedにされ, Kubelet.KillPod()³によってコンテナがKILLされるみたい.
また, 公式Docsにも次のように書かれているあたりkubeletがKubernetes API上からPod情報を削除するような処理はほぼないと思われる.

失敗したPodは人間またはcontrollerが明示的に削除するまで存在します。⁴

(詳しく調べたところkubeletがKubernetes API上のPod情報を消してそうな部分が一つだけ見つかった⁵が, これはStatic Podを扱う場合にしか呼び出されないため, 通常のPodには関係ないはず.)

このため, PodがactiveDeadlineSecondsを超過したときの挙動は通常のPodが異常終了してFailedとなる場合と変わらず,
やがてはガベージコレクションで削除される.

activeDeadlineSecondsを超過してもPodとコンテナが残っていたのはこのためだと思う.

Job

じゃあJobはどうなのかというと, こちらはkubeletではなくJob Controllerによって管理されている.
JobがactiveDeadlineSecondsを超過した場合はController.syncJob()⁶とRealPodControl.DeletePod()⁷によってKubernetes APIを呼び出してその時点でPhase: ActiveなPodを明示的に削除するみたい.

したがって, backoffLimitの設定によりJobのPodが失敗しても再度作成されるような場合は最後の1つだけがAPI上から削除される.

# Job作成
$ kubectl apply -f job-04.yaml

# 今度はDeadlineExceededによりJobがFailedになっている
$ kubectl get job -o yaml job-04 | yq -C r - "status"
conditions:
 - lastProbeTime: "2021-06-12T00:35:57Z"
 lastTransitionTime: "2021-06-12T00:35:57Z"
 message: Job was active longer than specified deadline
 reason: DeadlineExceeded
 status: "True"
 type: Failed
failed: 1
startTime: "2021-06-12T00:35:07Z"

# Podが1つ(自身のactiveDeadlineSecondsによりphase:Failedとなったもの)だけ残っている
$ kubectl get pods -l job-name=job-04
NAME READY STATUS RESTARTS AGE
job-04-vsw8x 0/1 Error 0 2m43s

# JobのactiveDeadlineSeconds超過時にActiveだったPod(job-04-5bjnz)が明示的に削除されている
$ kubectl describe job job-04
...(省略)
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal SuccessfulCreate 2m59s job-controller Created pod: job-04-vsw8x
 Normal SuccessfulCreate 2m19s job-controller Created pod: job-04-5bjnz
 Normal SuccessfulDelete 2m9s job-controller Deleted pod: job-04-5bjnz
 Warning DeadlineExceeded 2m9s (x2 over 2m9s) job-controller Job was active longer than specified deadline

# nodeを探してもコンテナは1つだけ
# (kindなのでnodeもdockerコンテナとして動いている)
$ docker container exec 05f0d805c4dc ctr --namespace k8s.io container ls | grep -c busybox
1

おわり

PodとJobのactiveDeadlineSecondsの違いを確認した.

個人的にはPodが消えちゃうと後から処理に時間がかかった理由がわからなくなっちゃうので,
単純なJobの場合はPodのactiveDeadlineSecondsを設定するほうが良い気がする.

コードを読むのは疲れる…

おまけ

クライアント認証のかかったPrometheusにGrafanaでアクセスする

Mon, 07 Jun 2021 00:00:00 +0000

やったことのまとめ

クライアント認証がかかったPrometheusにGrafanaでアクセスした.

Prometheusへの認証に必要な情報(証明書と秘密鍵)をGrafanaに持たせることができるので,
Grafanaへアクセスする権限さえあればクライアント認証のかかったPrometheusのメトリクスが閲覧できるようになる.

つかうもの

macOS Big Sur 11.2.3
Docker Desktop for Mac
- Version 3.3.1
- Docker Engine Version 20.10.5
- Docker Compose Version 1.29.0
Prometheus (Docker)
- v2.27.1
nginx (Docker)
- 1.21.0
Grafana (Docker)
- 7.5.7

やったこと

クライアント認証をかけたPrometheusの準備
Grafanaでクライアント認証を突破する

クライアント認証をかけたPrometheusの準備

Prometheusにクライアント認証をかけるで用意したものを使う.
秘密鍵や証明書もそのまま同じもの.
(ただしGrafanaにはクライアント認証をかけないのでMacに証明書を読み込ませる必要はなし)

今回はnginxを挟んで使う方法を採用するが, Prometheus単独でクライアント認証をかけた場合でもGrafanaの設定は同じはず.

Grafanaでクライアント認証を突破する

GrafanaはDataSource(Prometheus)への認証方法としてクライアント認証に対応しているので,
クライアント証明書とクライアント秘密鍵(クライアントの身元を証明するのに使用),
サーバー認証局の証明書(サーバーの身元を確認するのに使用)を持たせる.

GrafanaがDataSourceへクライアント認証で接続するための設定はdatasource.yaml¹に記述する.
証明書と秘密鍵をベタ書きしたくないので, File provider²を使ってファイル名を指定して指定して読み込むようにした.
(このあたりはissue³を参考にした)

各種ファイルをGrafanaのコンテナにマウントして起動する.
(今回はProemtheus+nginxの構成にしているが, Prometheus単独でクライアント認証をかけた場合でもGrafana側の設定は同じになる)

# ディレクトリの状態(使わないものを消している)
$ ls -1
client-ca-cert.pem
client-cert.pem
client-private-key.pem
datasource.yaml
docker-compose.yml
https.conf
server-cert.pem
server-private-key.pem

# コンテナを起動する
$ docker compose up -d --force-recreate --remove-orphans

今回Grafanaは単独で動かしている(HTTPS化もしていない)のでChromeでhttp://localhost:3000を開く.
(GrafanaはデフォルトでBasic認証がかかっているので, admin:adminで突破する)

Grafanaでnginxのクライアント認証を突破し,
Prometheusのメトリクスを取得できることが確認できた.

# コンテナを終了しておく
$ docker compose down

おわり

Grafanaでクライアント認証のかかったPrometheusからメトリクスを習得する流れを確認した.

Prometheusのセキュリティまわりはこれで一安心な感じもするが, 要件によってはGrafanaにも別の認証をかけたほうがいいかも…

おまけ

Prometheusにクライアント認証をかける

Sat, 05 Jun 2021 00:00:00 +0000

やったことのまとめ

Prometheusにクライアント認証をかけてみた.

Prometheus単独でクライアント認証を行う方法と,
クライアント認証をかけたnginxでリバースプロキシする方法をそれぞれ試した.

Prometheus, nginxはすべてDocker Desktop for Macで動かした.

つかうもの

macOS Big Sur 11.2.3
Docker Desktop for Mac
- Version 3.3.1
- Docker Engine Version 20.10.5
- Docker Compose Version 1.29.0
Prometheus (Docker)
- v2.27.1
nginx (Docker)
- 1.21.0
OpenSSL
- 1.1.1d

やったこと

各種秘密鍵と証明書の作成
Prometheus単独でクライアント認証をかける
Prometheus+nginxでクライアント認証をかける

各種秘密鍵と証明書の作成

まずはクライアント認証に必要なサーバーとクライアントの秘密鍵+証明書をOpenSSLで作成する.

# nginxコンテナを起動してOpenSSLを使う
$ docker container run --rm -it -v="$PWD:/workdir" -w="/workdir" --entrypoint=/bin/bash nginx:1.21.0

# サーバー用のオレオレ証明書を作成
# ホスト名はprometheus.hogehoge.comとしてSANsの設定もしておく(Chromeで開くため)
$ openssl genpkey -algorithm RSA -out server-private-key.pem
$ openssl req -x509 -key server-private-key.pem -out server-cert.pem -addext 'subjectAltName = DNS:prometheus.hogehoge.com'
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:prometheus.hogehoge.com
Email Address []:

# クライアント認証局の証明書を作成(オレオレ認証局)
$ openssl genpkey -algorithm RSA -out client-ca-private-key.pem
$ openssl req -x509 -key client-ca-private-key.pem -out client-ca-cert.pem -days 365
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:client-ca
Email Address []:

# 署名のための準備
$ mkdir -p demoCA/newcerts && touch demoCA/index.txt
$ echo 01 > ./demoCA/serial

# クライアント証明書を作成(クライアント認証局で署名する)
# PKCS#12形式のものも作成しておく
$ openssl genpkey -algorithm RSA -out client-private-key.pem
$ openssl req -new -key client-private-key.pem -out client-csr.pem
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:client
Email Address []:
A challenge password []:
An optional company name []:

$ openssl ca -in client-csr.pem -out client-cert.pem -keyfile client-ca-private-key.pem -cert client-ca-cert.pem -days 365
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y

$ openssl pkcs12 -export -clcerts -in client-cert.pem -inkey client-private-key.pem -out client-cert.p12
Enter Export Password: fugafuga
Verifying - Enter Export Password: fugafuga

# コンテナから出ると鍵と証明書が作成されている
$ exit
$ ls -1
client-ca-cert.pem
client-ca-private-key.pem
client-cert.p12
client-cert.pem
client-csr.pem
client-private-key.pem
demoCA
server-cert.pem
server-private-key.pem

今回は鍵と証明書をたくさん使っていて後で混乱しそうなのでここに内容をまとめておく.

サーバー認証局の証明書(server-cert.pem)
- サーバー証明書に署名した認証局の証明書
- 今回はオレオレ証明書なのでサーバー証明書と同一だが, ちゃんとした認証局(CA)によってサーバー証明書を発行した場合は認証局の証明書を使う.
サーバー認証局の秘密鍵(server-private-key.pem)
- サーバー証明書に署名した認証局の秘密鍵
- 今回はオレオレ証明書なのでサーバー秘密鍵と同一
- このあとは使わない
サーバー証明書(server-cert.pem)
- サーバー(Prometheus)の身元を証明する証明書. 今回はオレオレ証明書を使う.
- ホスト名はprometheus.hogehoge.comとした(オレオレ証明書なので任意の名前)
サーバー秘密鍵(server-private-key.pem)
- サーバー(Prometheus)に持たせる秘密鍵
クライアント認証局の証明書(client-ca-cert.pem)
- クライアント証明書に署名した認証局の証明書
クライアント認証局の秘密鍵(client-ca-private-key.pem)
- クライアント証明書に署名した認証局の秘密鍵
- このあとは使わない
クライアント証明書(client-cert.pem, client-cert.p12)
- クライアントの身元を証明する証明書
- クライアント(Prometheus, Grafana, User)ごとに分けてもいいけど, 面倒なので全部同じものを使う
クライアント秘密鍵(client-private-key.pem)
- クライアントに持たせる秘密鍵
クライアントのCSR(client-csr.pem)
- クライアント証明書を発行するときに使ったCSR
- このあとは使わない

ついでにブラウザでも動作確認できるように, Macでサーバー証明書を信頼する設定とクライアント証明書を持たせる設定を行う.

Finderからclient-cert.p12とserver-cert.pemをそれぞれダブルクリックして,
証明書をキーチェーンアクセスで信頼するように設定する.

最後に, 今回はサーバー証明書で実在しないドメイン(prometheus.hogehoge.com)を指定しているので,
Macの/etc/hostsに名前解決の設定を記述しておく.

# /etc/hostsにprometheus.hogehoge.com(localhostに飛ばす)を追加
$ echo "127.0.0.1 prometheus.hogehoge.com" | sudo tee -a /etc/hosts

以上で証明書とか秘密鍵の準備は完了.

Prometheus単独でクライアント認証をかける

Prometheus自体にクライアント認証の仕組みがあるので¹,
サーバー証明書とサーバー秘密鍵(HTTPS化してサーバーの身元を証明するのに使用),
クライアント認証局の証明書(クライアントの身元を確認するのに使用)を持たせる.

クライアント認証の設定はweb-config.ymlに記述する.

Prometheus自身のメトリクスを取得する際にもクライアント認証を突破する必要があるので,
クライアント証明書とクライアント秘密鍵(クライアントの身元を証明するのに使用),
サーバー認証局の証明書(HTTPSサーバーの身元を確認するのに使用)も持たせることにする.
(Prometheus自身のメトリクスを取得しない場合は不要)

クライアント認証を突破するための設定はprometheus.ymlのscrape_configs²に記述する.

あとは指定のパスにそれぞれの秘密鍵, 証明書ファイルを配置する.
今回はDockerで起動するのでパスを指定してマウントしてあげれば良い.

以上で準備ができたので, いよいよDockerで起動する.

# ディレクトリの状態(使わないものは消している)
$ ls -1
client-ca-cert.pem
client-cert.pem
client-private-key.pem
docker-compose.yml
prometheus.yml
server-cert.pem
server-private-key.pem
web-config.yml

# コンテナを起動する
$ docker compose up -d --force-recreate --remove-orphans

動作確認のため,
Chromeで https://prometheus.hogehoge.com を開く.

Macにクライアント証明書をもたせたため, 問題なく閲覧できた.

今度はクライアント証明書を使わずに https://prometheus.hogehoge.com を開いてみる.

要求されたクライアント証明書を提示しなかったため, 閲覧ができない.
以上でPrometheusにクライアント認証がかかっていることを確認できた.

# コンテナを終了しておく
$ docker compose down

Prometheus+nginxでクライアント認証をかける

Prometheusの前段にnginx(リバースプロキシ)を用意して, そこでクライアント認証をかけることもできる.

nginxにサーバー証明書とサーバー秘密鍵(HTTPSサーバーの身元を証明するのに使用),
クライアント認証局の証明書(クライアントの身元を確認するのに使用)を持たせる.

今回はHTTPS化と認証まわりの設定をhttps.confに記述する.
今回はクライアント認証を行うポート(443)と別に認証をかけないポート(44433)も用意してみる.

この場合Prometheus自体にはクライアント認証をかけないのでweb-config.ymlは不要,
さらに自身のメトリクスを取得する場合でもクライアント証明書とクライアント秘密鍵は不要となる.
(したがってprometheus.ymlも自分で作らずデフォルトのものを使用する)

あとは各種ファイルをnginxのコンテナにマウントして起動する.
(先程とは異なり, Prometheusにファイルを持たせないなど設定が変わっていることに注意)

# ディレクトリの状態(使わないものを消している)
$ ls -1
client-ca-cert.pem
docker-compose.yml
https.conf
server-cert.pem
server-private-key.pem

# コンテナを起動する
$ docker compose up -d --force-recreate --remove-orphans

Chromeでhttps://prometheus.hogehoge.comを開く.

クライアント証明書を提示しなかったので認証に失敗した.
(クライアント証明書を要求された際に"OK"を選択すると認証に成功する)

この状態で次はhttps://prometheus.hogehoge.com:44433を開く.

44433ポートにはクライアント認証をかけていないため, そのまま開くことができた.

こんな感じの出し分けをPrometheus単独でやるのは難しいが,
nginxを使うと比較的カンタンに実現できるし, Prometheus自身のメトリクスを取得するためにクライアント証明書などを持たせる必要もなくなる.

クライアント認証以外の認証方式も設定しやすいので,
個人的にはこちらのほうがすき.

# コンテナを終了しておく
$ docker compose down

おわり

Prometheusにクライアント認証をかけてみた.

セキュリティ要件でPrometheusへのアクセスに認証が必要な場合は,
基本は前段のnginxで認証設定をかけてクライアント側(Grafanaとか)に認証情報を持たせてアクセスするのが良いと思う.

おまけ

5月のそとちゃんまとめ(2021)

Tue, 01 Jun 2021 00:00:00 +0000

まとめ

誕生日
記念写真

誕生日

そとちゃんは5月1日でたぶん5さいになった.

元野良なので本当の誕生日はわからないけど,
うちに来た記念日と病院で推測してもらった日にちから5月1日生まれということにしている.

今年は気合を入れて猫用の誕生日ケーキも買った.

そとちゃんも大喜び.🤗

たぶん5さいになった🎉 pic.twitter.com/OnaNLYQUGJ
— ずみし (@uzimihsr) May 1, 2021

…だったのは最初の一口だけで,
その後はまたたびをふりかけても見向きもしなかった.😭
お口に合わなかったらしい.

お気に召さなかった😭 pic.twitter.com/W3XCohhG4F
— ずみし (@uzimihsr) May 1, 2021

ケーキはダメだったけど, 誕生日プレゼントに用意したおもちゃは喜んでくれた.

キャッチ・ミー・イフ・ユー・キャン 2 猫と音符

もともと評判が良いおもちゃだったけど, そとちゃんもかなり喰い付きが良かった.
電池を入れっぱなしにすると延々と遊び続ける.

成猫のそとちゃんが電池切れまで遊ぶのは初めてみた.

ねこもおもちゃも電池切れ pic.twitter.com/8sTYWa9qBn
— ずみし (@uzimihsr) May 9, 2021

気に入ってくれてよかった.

記念写真

5さいになった記念に写真屋さんでそとちゃんを撮ってもらった.

そとちゃんは妙に肝が据わっているので初めての場所でもガンガン探検しちゃう.

楽しすぎて撮影用のポジションになかなか止まってくれない.

こんなこともあろうかと持ってきていたお気に入りのねずみのおもちゃで目線を釣ってもらい,
なんとか撮影できた.

それでもそとちゃん単独だとすぐに動いちゃって枚数が確保できないとのことで後半は俺も一緒に撮ってもらった.

はしゃいで相当疲れたのか, うちに帰ってからはすぐに寝てしまった.💤

つかれた pic.twitter.com/vQjeA8us06
— ずみし (@uzimihsr) May 16, 2021

がんばってくれてえらかった.

おわり

そとちゃんが5さいになった. めでたい.🎉

そとちゃんからしたらいきなり変なものを食わされたり,
知らないところを探検したいのに無理やり写真を撮られたりでいい迷惑だったかもしれない.

それでも, そとちゃんはたぶん俺より長くは生きられないのでできるだけお祝いとか記録に残ることをしたい.
(これは俺のエゴだとわかっているけども…)

仕方なく(~~あるいはおもちゃやおやつに釣られながら~~)付き合ってくれるそとちゃんには感謝しかないし,
そとちゃんが6さいの誕生日を元気に迎えられるように俺もまた1年頑張ろうと思った.

…猫用ケーキは二度と買わない.

おまけ

GoでSQLのユニットテストを書く(dockertest)

Fri, 14 May 2021 00:00:00 +0000

まとめ

dockertestを使うとGoのコード内からテスト対象のDBをDockerコンテナとして起動して接続することができる.

これを使ってDBを都度立ち上げて, 実際にレコード操作の検証をするテストを書いてみた.

環境

macOS Big Sur 11.2.3
go version go1.15.5 darwin/amd64
dockertest v3.3.5
Docker Desktop for Mac
- Version 3.3.0
- Docker Engine Version 20.10.5

やりかた

この前はDBをモックしたテストを試したけど,
やっぱり実際にテスト用のDBを立てて期待値が得られるか検証したいときもある.

テスト対象となるのは前回同様こんな感じの処理.

今回はGoからDockerをいじることができるdockertestを使ってテスト用DBを起動し,
それに接続してテストを行う.

まずはテーブル定義を記述したファイルをつくる.

ついでにMySQLの設定ファイルを作っておく.

次に公式の例¹を参考に, MySQL²のコンテナを立ち上げる関数を書いてみる.

頑張ったのはcreateContainer()でRunOptions³を使ってコンテナ起動時に細かいオプションを指定したり必要な設定ファイルをマウントできるようにしたところ.
こうしておくことで大体のDBの設定をこのテストコードに封じ込めることができる.

closeContainer()を呼び忘れるとテストが終わってもコンテナが残ってしまうので注意する(deferで呼んでおくのが良さそう).

各機能のテストではそれぞれこの関数を呼び出してテスト用のDBを作成する.

前回同様Create()についてテストを作るとこんな感じ.

一応テスト対象の関数以外のDB操作(挿入したレコードを取得するときなど)もRead()などの自分で定義している関数ではなく都度SQLを実行するようにした.

最終的なテストコードはこんな感じ.

最後にテストを実行してみる.

# ディレクトリの状態
$ tree .
.
├── go.mod
├── go.sum
├── main.go
├── main_test.go
├── my.cnf
└── todo.sql

# テスト実行
$ go test -v ./...
=== RUN TestCreateWithDB
=== RUN TestCreateWithDB/レコードが正しく追加されることのテスト
[mysql] 2021/05/13 23:41:36 packets.go:37: unexpected EOF
[mysql] 2021/05/13 23:41:36 packets.go:37: unexpected EOF
[mysql] 2021/05/13 23:41:36 packets.go:37: unexpected EOF
--- PASS: TestCreateWithDB (27.14s)
 --- PASS: TestCreateWithDB/レコードが正しく追加されることのテスト (27.14s)
=== RUN TestReadWithDB
=== RUN TestReadWithDB/レコードが正しく取得できることのテスト
[mysql] 2021/05/13 23:42:03 packets.go:37: unexpected EOF
[mysql] 2021/05/13 23:42:03 packets.go:37: unexpected EOF
[mysql] 2021/05/13 23:42:03 packets.go:37: unexpected EOF
--- PASS: TestReadWithDB (26.95s)
 --- PASS: TestReadWithDB/レコードが正しく取得できることのテスト (26.95s)
=== RUN TestUpdateWithDB
=== RUN TestUpdateWithDB/レコードが正しく更新できることのテスト
[mysql] 2021/05/13 23:42:30 packets.go:37: unexpected EOF
[mysql] 2021/05/13 23:42:30 packets.go:37: unexpected EOF
[mysql] 2021/05/13 23:42:30 packets.go:37: unexpected EOF
--- PASS: TestUpdateWithDB (27.15s)
 --- PASS: TestUpdateWithDB/レコードが正しく更新できることのテスト (27.15s)
=== RUN TestDeleteWithDB
=== RUN TestDeleteWithDB/レコードが正しく削除できることのテスト
[mysql] 2021/05/13 23:42:58 packets.go:37: unexpected EOF
[mysql] 2021/05/13 23:42:58 packets.go:37: unexpected EOF
[mysql] 2021/05/13 23:42:58 packets.go:37: unexpected EOF
--- PASS: TestDeleteWithDB (28.51s)
 --- PASS: TestDeleteWithDB/レコードが正しく削除できることのテスト (28.51s)
PASS
ok 	github.com/uzimihsr/golang-db-test	110.730s

コンテナを立ち上げてから疎通できるまでにちょっと時間がかかるのでunexpected EOFのエラーが何回か出てるけど, 内部でリトライをしてるので問題ないはず.

都度Dockerの操作をしてるせいでかなり時間がかかっているので, t.Parallel()⁴とかを使って並列実行させたほうが良いかも.

おわり

dockertestを使ってテスト用のMySQLコンテナをGoのコードから立てて操作してみた.

別にDBに限らず外部とのやりとりをする部分は対象をDocker化できるなら何でも使えちゃいそう.

ただしテスト環境でGo以外にDockerが必要になったり,
コンテナの立ち上げにかなり時間がかかるなどクセも強いのでどこまでやるかはテスト要件と相談して使いたい.

おまけ

4月のそとちゃんまとめ(2021)

Wed, 12 May 2021 00:00:00 +0000

まとめ

シャンプー
ひざ
ついに捉えた

シャンプー

定期的にブラッシングはしてるものの,
それでも静電気と抜け毛がすごかったので約1年半ぶりにそとちゃんにお風呂に入ってもらった.

ご機嫌なところに大変残念なお知らせですが今日はお風呂に入ります pic.twitter.com/pmsgsHc8KQ
— ずみし (@uzimihsr) April 4, 2021

そとちゃんはお風呂場がけっこう好きで, 普段も湯船のフタの上でごろごろしてたりする.

この日もお風呂場の浴室乾燥を入れて暖かくなったところに自分から出向いてきた.
(洗われるとは思っていない)

before pic.twitter.com/LkLXZyI7Dv
— ずみし (@uzimihsr) April 4, 2021

まずはぬるめのシャワーで毛を濡らす.
(そとちゃんはねこだけどシャワーは平気. えらい!)

つぎに猫用シャンプーで体を洗っていく.

そとちゃんはここが一番つらかったらしく, 暴れはしないけどわんわん鳴いていた.

シャンプー pic.twitter.com/qsmDLQloSi
— ずみし (@uzimihsr) April 4, 2021

再びシャワーでシャンプーを洗い流す.

このあたりで開始から20分くらいが経ち, そとちゃんも心が折れて鳴き声が弱々しくなった. かわいそう.

すすぎ pic.twitter.com/UK4abqsbwt
— ずみし (@uzimihsr) April 4, 2021

でもしんどいのはここまで. あとは乾かしていくだけ.

浴室乾燥とタオルで乾かす pic.twitter.com/esBDF7cpZ7
— ずみし (@uzimihsr) April 4, 2021

タオルで水気を吸い取り, ドライヤーで仕上げたら毛がふわふわに元通り.
(そとちゃんはドライヤーも平気. えらい!)

ごほうびのちゅーるをあげて終了.

after pic.twitter.com/6BSAmgPK4c
— ずみし (@uzimihsr) April 4, 2021

そとちゃんは結局一度も暴れなかった. えらい.😊

(シャンプー後に毛づくろいしすぎて次の日珍しく毛玉を吐いた)

毛玉吐いた pic.twitter.com/xirdjVBh5q
— ずみし (@uzimihsr) April 5, 2021

ひざ

そとちゃんは最近ほぼ毎日ひざに乗ってくる.

あまえんぼ pic.twitter.com/3RqRbh12ni
— ずみし (@uzimihsr) April 7, 2021

俺がソファでだらだらしてるときによく乗ってくる.

この体勢だとねこをなでながらスマホがいじれちゃうので時間が爆速で溶ける.

支配者 pic.twitter.com/kcNNtHVRyK
— ずみし (@uzimihsr) April 16, 2021

ちょっとお留守番したときなんかも乗ってくるけど,
このときはスマホをいじると不機嫌になるのでやらない.

おるすばんしたねこは膝を占領する権利がある pic.twitter.com/Edj5otupQV
— ずみし (@uzimihsr) April 18, 2021

かわいい〜

ついに捉えた

ついにカメラが決定的瞬間を捉えた!!!

現行犯 pic.twitter.com/Gdgjkor4zr
— ずみし (@uzimihsr) April 24, 2021

めっちゃ悪い顔してる😭😭😭

スパゲッティみたいだ…😭

おわり

そとちゃんはえらいねこなので, 久しぶりのお風呂も頑張ってくれた.

濡れたらいつもより痩せて見えるかとおもったけど, そんなことはなかった…

おまけ

GoでSQLのユニットテストを書く(go-sqlmock)

Fri, 30 Apr 2021 00:00:00 +0000

まとめ

GoでSQLのテストを書くときはgo-sqlmockを使うとデータベースのモックがかんたんに作れる.

環境

macOS Big Sur 11.2.3
go version go1.15.5 darwin/amd64
go-sqlmock v1.5.0

やりかた

こんな感じでDB(MySQL)のテーブル操作(CRUD)を行う関数について, ユニットテストを書きたくなった.

テスト用のDBを立てて実際に操作しても良いんだけど,
CIするときに面倒だったりするのでできればGoだけでDBをモックして完結したテストを書きたい.

こんなときにはgo-sqlmockが使える.

公式README¹を参考にしながら関数Create()についてテストを書いてみるとこんな感じ.

ArrangeでDBのモックを作成し, 想定される引数に対する挙動を設定している.
エラーの有無や返す値の内容などもmock.Expect~().With~().With~()²で細かく設定できる.

同様にRead(), Update(), Delete()についても書いていく.
最終的なテストコードはこんな感じ.

最後にテストを実行してみる.

$ tree .
.
├── go.mod
├── go.sum
├── main.go
└── main_test.go

# テスト実行
$ go test -v ./...
=== RUN TestCreate
=== RUN TestCreate/Createが成功するケース
=== RUN TestCreate/Createが失敗するケース
--- PASS: TestCreate (0.00s)
 --- PASS: TestCreate/Createが成功するケース (0.00s)
 --- PASS: TestCreate/Createが失敗するケース (0.00s)
=== RUN TestRead
=== RUN TestRead/Readが成功するケース
=== RUN TestRead/Readが失敗するケース(QueryRowでエラー)
=== RUN TestRead/Readが失敗するケース(Scanでエラー)
--- PASS: TestRead (0.00s)
 --- PASS: TestRead/Readが成功するケース (0.00s)
 --- PASS: TestRead/Readが失敗するケース(QueryRowでエラー) (0.00s)
 --- PASS: TestRead/Readが失敗するケース(Scanでエラー) (0.00s)
=== RUN TestUpdate
=== RUN TestUpdate/Updateが成功するケース
=== RUN TestUpdate/Updateが失敗するケース
--- PASS: TestUpdate (0.00s)
 --- PASS: TestUpdate/Updateが成功するケース (0.00s)
 --- PASS: TestUpdate/Updateが失敗するケース (0.00s)
=== RUN TestDelete
=== RUN TestDelete/Deleteが成功するケース
=== RUN TestDelete/Deleteが失敗するケース
--- PASS: TestDelete (0.00s)
 --- PASS: TestDelete/Deleteが成功するケース (0.00s)
 --- PASS: TestDelete/Deleteが失敗するケース (0.00s)
PASS
ok 	github.com/uzimihsr/golang-db-test	0.170s

できた.

おわり

go-sqlmockを使うことで, テスト用のDBを立ち上げることなくGoでSQLのテストができた. べんり.

おまけ

3月のそとちゃんまとめ(2021)

Fri, 23 Apr 2021 11:08:42 +0900

まとめ

おもちゃ
毛布
ブラッシング

おもちゃ

3月は新しいおもちゃをいくつか買った.

まずはねこじゃらし.

じゃれ猫　トリオ

なんとこれ, おもちゃの部分がそとちゃんが大好きなねずみのおもちゃにそっくり.

同じメーカーだから(?)かはわからないけど振るとシャカシャカ音がするのも同じで,
当然そとちゃんは大興奮.

うおお pic.twitter.com/IpdQslzcZm
— ずみし (@uzimihsr) March 19, 2021

これならヒモがついてるのでそとちゃんが失くすこともないので安心.
買ってよかった.

次に買ったのはペットショップでバラ売りされていたドギツい色のねずみのおもちゃ.

新しいねずみ pic.twitter.com/8fksuAyoNh
— ずみし (@uzimihsr) March 25, 2021

これは大失敗.

他のねずみと同じく軽くて振るとシャカシャカ音はするんだけど,
音が少し小さいのが悪いのか色が悪いのかそとちゃんのお気に召さなかった.
数回遊んでおもちゃ箱(戻ってこない)行き.

さらに期待はずれだったのはまたたびボール.

じゃれ猫　またたびタックル

中にまたたびの粒?が入っていて如何にもねこが食いつきそう.
またたびがついてるおもちゃは手でガッツリ押さえてまたたび部分だけベロベロ舐めちゃうジャンキーのそとちゃんだけど,
この形ならねこの手じゃ押さえづらいし飽きずに追いかけてくれるかな…という期待もあった.

結局最初の数分は匂いで興奮してたんだけど,
何回か押さえようとして失敗したらすぐ興味をなくしてしまった.
例のブツを効率良く摂取したいそとちゃんには合わなかったらしい.🌿

ねこの好みは難しい…

毛布

3月上旬はまだ寒かったので俺のベッドに茶色の毛布を敷いていて,
この毛布がそとちゃんのお気に入りになってしまった.

ひっくり返っておでこをつけちゃうくらいの気に入りよう.

かわいいポーズしてる pic.twitter.com/952eTB4SXU
— ずみし (@uzimihsr) March 2, 2021

流石に暖かくなってきたので片付けようとしたんだけど,
なかなか許可が降りず…

ベッドに敷いてたのを畳んでソファに置いたらすぐに占拠されてしまった.

毛布片付けの許可が出ない pic.twitter.com/icem8UyvPy
— ずみし (@uzimihsr) March 24, 2021

強い意志を感じる pic.twitter.com/pwUdYB5D14
— ずみし (@uzimihsr) March 29, 2021

しかたがないのでソファにそのまま置いておいて,　俺が座るときだけどかすようにしている.

夏まで置いておくわけにもいかないので, 頃合いを見計らって片付けたい.

ブラッシング

部屋が乾燥してたのと毛布でゴロゴロしまくったのが原因でそとちゃんが帯電してしまい,
撫でるたびに静電気でバチバチしてたのでブラッシングをした.

そとちゃんはブラッシングが大嫌いで,
あまりにも嫌がるので普段は2週に1回くらいの頻度でしかやっていない.

ブラシをかける→我慢できなくなって逃げる→おもちゃとおやつで機嫌を取る→捕まえてブラシをかける…
を10回くらい繰り返すのでいつもだいたい1時間くらいかかるんだけど,
今回は特によく逃げるので長期戦だった.

途中でおひるねタイムまで入る始末.

ブラシから逃げ回って疲れ果てた pic.twitter.com/c0TJQpRXH2
— ずみし (@uzimihsr) March 13, 2021

かわいそうだけど起こしてなんとか終了.

約2時間の激戦で過去最大級の抜け毛が取れた.

2時間 pic.twitter.com/CSQyDdXobb
— ずみし (@uzimihsr) March 13, 2021

丸めたらピンポン球くらいのサイズになったのでそとちゃんのおもちゃになった.

おわり

先月に引き続きまたも遅筆. 良くない.
時間を見つけて書いてはいるけどなかなかまとめきれずに公開できない.

4月はそとちゃんがお風呂に入ったりといろいろあったので早めに書きたい.

おまけ

2月のそとちゃんまとめ(2021)

Sun, 21 Mar 2021 00:00:00 +0000

まとめ

揺れた
猫の日
つめとぎ
GERO
クソデカトイレマット

揺れた

2月はかなりでかい地震があった.

うちもかなり揺れたんだけど, そとちゃんは本棚の上でぐーすか寝ていた…

危機感がまるで感じられない.

ねこが地震に気づかず寝ていたので少しだけお説教した pic.twitter.com/P8KKo9pQvT
— ずみし (@uzimihsr) February 13, 2021

万が一のことを考えて一応避難の準備もしたけど,
そとちゃんはお出かけ大好きねこなのですんなりキャリーに入ってくれた.

協力的で助かる〜 pic.twitter.com/thPoCTHDvQ
— ずみし (@uzimihsr) February 13, 2021

結局避難せずに済んだけどごはんとトイレの道具を準備するのに結構時間がかかったし,
災害への備えが全然できてなかったことを実感した…

猫の日

2/22は猫の日だったらしい.

去年に続けて今年もイエローハットが面白そうなキャンペーンをやっていたので,
そとちゃんには交通にゃん全クイズに挑戦してもらった.

結果は…?

😭

つめとぎ

今まで使っていたつめとぎがぼろぼろだったので, 全く同じものを買った.

つめとぎボロボロなので2台目を買いました pic.twitter.com/bLhtsCQ6Uh
— ずみし (@uzimihsr) February 22, 2021

Gari Gari Wall Scratcher PLUS

これはねこが立った姿勢でつめとぎができるスグレモノで, そとちゃんのお気に入り.

好きすぎて組み立て中にバリバリしちゃう.

完成を待てない pic.twitter.com/08YHEILJs6
— ずみし (@uzimihsr) February 22, 2021

新品と古いのを比べると一目瞭然で, そとちゃんがどれだけ今までバリバリしてくれたかがよくわかる.

職人ねこは造り終えたものに興味は無い
また次の現場へ向かう pic.twitter.com/RrUGGUGzFx
— ずみし (@uzimihsr) February 22, 2021

ちなみにつめとぎが新しくなってもそとちゃんはソファをバリバリし続けている…
どうして😭

GERO

久しぶりにそとちゃんが吐いた.

早朝の5時くらいにかなり大きめの「オエッ、ゴポッ」とした音がしたのでびっくりして飛び起きた.

現場を見てみるとけっこうガッツリやっていた.
(画像はモザイクをかけてるけど, 直前に食べたらしいカリカリと胃液?が混ざった茶色いGEROが撒き散っていた)

そとちゃんは普段滅多に吐かない(誤飲騒動以来全く吐いてなかった)ので俺はもうパニック.

急いで獣医さんに電話したけど,
吐いたのが1回で終わっていたのと吐いた直後も食欲があったことから急患にはかからず家で様子を見ることに.

早朝に半年ぶりのGEROを吐いてしもべを叩き起こしたねこ
余裕ぶっこいてるし食欲も遊ぶ元気もあるので獣医さんと相談した上で様子見 pic.twitter.com/dZfoQu162E
— ずみし (@uzimihsr) February 17, 2021

結局その後は何も起こらず元気に運動会をしていたので, 病院にも行っていない.

大変なことにならなくてよかった.

ごはんめっちゃ食べよる pic.twitter.com/6ze6P56hdq
— ずみし (@uzimihsr) February 17, 2021

どうして吐いたのかはわからずじまいだけど,
フードの形がわかるくらいのGEROだったので空腹状態で食べ急いで胃がびっくりしたのかと推測している.🤔
(GEROの前日は夕方のカリカリをガッツリ残していたのでおやつを抜いていた)

GEROカーペットもすぐに外して洗濯したので今ではわからないくらいきれいになった.
タイルカーペットにしておいてよかった.

クソデカトイレマット

そとちゃんは掃除がめっちゃ便利なロボットトイレを使ってくれている. えらい.😊

が, このトイレは横からの入り口が大きく開いていて,
そとちゃんはうんちした後にハイテンションで飛び出てくるので周りに猫砂が飛び散る.😭

一応小さめのトイレマットを敷いてたんだけど,
そとちゃんの射出角度(?)によってはマットを超えちゃったりしてあんまり意味がなかった.

そこでこのクソデカトイレマットを購入.

Petio necoco 猫トイレマットワイド

今度はかなりの範囲がカバーできるようになった.

飛び散った猫砂を裸足で踏んで悲しい思いをすることがなくなってうれしい.

おわり

2月はそとちゃんも俺もいろいろありすぎて, 書くのが遅くなってしまった…

3月も既に新しいおもちゃをいくつか買ったりしているので, はやめに書いておきたい.

おまけ

GrafanaをHTTPS化する

Mon, 15 Feb 2021 00:00:00 +0000

やったことのまとめ

Prometheusと同様にGrafanaもHTTPS化してみた.

Prometheusと同様にGrafana自体に証明書と秘密鍵をもたせる方法とHTTPS対応したリバースプロキシを使う方法の2通りを試した.

つかうもの

macOS Mojave 10.14
- Dockerのホストとして使用, 動作確認用のブラウザもこちらで起動する
Google Chrome
- バージョン: 88.0.4324.150（Official Build）（x86_64）
Docker Desktop for Mac
- Version 3.1.0
- Docker Engine Version 20.10.2
- docker-compose version 1.27.4
Grafana (Docker)
- version 7.3.7
nginx (Docker)
- version 1.18.0
openssl
- version 1.1.1d

やったこと

秘密鍵とオレオレ証明書の作成
Grafanaに証明書と秘密鍵を持たせる
nginxでリバースプロキシする

秘密鍵とオレオレ証明書の作成

前回と全く同じ手順で秘密鍵と証明書を作成する.

# cert.pemはSANsでhogehoge.comが指定されたSSL証明書
$ openssl x509 -in cert.pem -noout -text
Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number:
 24:4c:ec:40:cc:94:5c:a2:af:30:6a:e9:7d:5c:17:28:5e:fb:ec:fc
 Signature Algorithm: sha256WithRSAEncryption
 Issuer: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd, CN=hogehoge.com
 Validity
 Not Before: Feb 10 16:13:01 2021 GMT
 Not After : Mar 12 16:13:01 2021 GMT
 Subject: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd, CN=hogehoge.com
 ...
 X509v3 extensions:
 ...
 X509v3 Subject Alternative Name:
 DNS:hogehoge.com, DNS:fugafuga.com
 ...

# private-key.pemはcert.pemに紐づく秘密鍵
$ openssl rsa -in private-key.pem -text -noout
Private-Key: (2048 bit)
modulus:
 ...

作成したオレオレ証明書はMacで信頼する設定にしておく.

Grafanaに証明書と秘密鍵を持たせる

Grafanaは元からHTTPS化に対応しているので, SSL証明書とその秘密鍵をもたせる¹だけで良さそう.

証明書(cert_file)と鍵の場所(cert_key)などはgrafana.iniで設定できる.

あとはこのgrafana.iniと証明書, 秘密鍵を適切な場所に配置してGrafanaを起動する.

今回はDocker Composeで試すが, 非コンテナ環境でもやることは同じはず.

$ tree .
.
├── cert.pem
├── docker-compose.yml
├── grafana.ini
└── private-key.pem

# コンテナ起動
$ docker-compose up -d --force-recreate --remove-orphans

# localhostの443番ポートがGrafanaコンテナの443に割り当てられている
$ docker-compose ps
 Name Command State Ports
----------------------------------------------------------
grafana /run.sh Up 3000/tcp, 0.0.0.0:443->443/tcp

https://hogehoge.comを開く.
(hogehoge.comでlocalhostにアクセスするためには/etc/hostsを編集しておく)

GrafanaがHTTPS化されていることが確認できた.
かんたん.😊

nginxでリバースプロキシする

もちろんPrometheusと同様にHTTPS化したnginxでリバースプロキシすることもできるはず.

前回と同様にnginxに証明書と鍵を持たせて, Grafana側でリバースプロキシ用の設定を入れてみる.

$ tree .
.
├── cert.pem
├── docker-compose.yml
├── grafana.ini
├── https.conf
└── private-key.pem

# コンテナ起動
$ docker-compose up -d --force-recreate --remove-orphans

# localhostの443番ポートがnginxコンテナの443に割り当てられている
$ docker-compose ps
 Name Command State Ports
-------------------------------------------------------------------------------
grafana /run.sh Up 3000/tcp
nginx /docker-entrypoint.sh ngin ... Up 0.0.0.0:443->443/tcp, 80/tcp

Grafanaとnginxが起動したらhttps://hogehoge.com/grafana/を開く.

先ほどと同様にHTTPSでGrafanaが公開されていることが確認できた.

やったぜ.

おわり

GrafanaをHTTPS化してみた.

Grafana自体にHTTPS対応機能があるので設定はわりとカンタンだった.
nginxを使う場合もPrometheusをHTTPS化したときと同じようにできたのでそんなにつまづくところはなかったと思う.

おまけ

https://grafana.com/docs/grafana/latest/administration/configuration/#cert_file ↩︎

PrometheusをHTTPS化する

Thu, 11 Feb 2021 00:00:00 +0000

やったことのまとめ

PrometheusはデフォルトだとHTTP(暗号化なし)で公開されるが, セキュリティの観点からどうしてもHTTPSで動かしたい場合がある.

今回はnginxを使ってリバースプロキシする方法とPrometheus自体をHTTPS化する方法の2通りの方法を試してみた.

つかうもの

macOS Mojave 10.14
- Dockerのホストとして使用, 動作確認用のブラウザもこちらで起動する
Google Chrome
- バージョン: 88.0.4324.150（Official Build）（x86_64）
Docker Desktop for Mac
- Version 3.1.0
- Docker Engine Version 20.10.2
- docker-compose version 1.27.4
Prometheus (Docker)
- version 2.24.1
nginx (Docker)
- version 1.18.0
openssl
- version 1.1.1d

やったこと

秘密鍵とオレオレ証明書の作成
nginxを挟んでHTTPS化する
Prometheus単独でHTTPS化する

秘密鍵とオレオレ証明書の作成

まずはHTTPSで通信を行うためにopensslで秘密鍵とSSL証明書(オレオレ証明書)を作成する.
(公的な証明書と鍵のペアがある場合は不要. 文中のhogehoge.comは適切なホスト名に置き換える.)

オレオレ証明書を作るときは以前のやり方に加えて,
ページをChromeで開いた場合も怒られないようにSANs(Subject Alternative Names)を設定するようにする.

今回の鍵と証明書の作成に使用するopensslはnginxのDocker imageに入っているものを使う.

# nginxコンテナの中で実行(カレントディレクトリをマウントしておく)
$ docker container run --rm -it -v="$PWD:/workdir" -w="/workdir" --entrypoint=/bin/bash nginx:1.18.0

## ここからコンテナ内
$ openssl version
OpenSSL 1.1.1d 10 Sep 2019

# 秘密鍵(private-key.pem)の作成
$ openssl genpkey -algorithm RSA -out private-key.pem

# オレオレ証明書(cert.pem)の作成(CSRの作成と署名)
# SANsの設定もやっておく(Chrome対応)
$ openssl req -x509 -key private-key.pem -out cert.pem -addext 'subjectAltName = DNS:hogehoge.com,DNS:fugafuga.com'
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:hogehoge.com
Email Address []:

# 証明書の中身を確認(SANsが追加されている)
$ openssl x509 -in cert.pem -noout -text
Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number:
 24:4c:ec:40:cc:94:5c:a2:af:30:6a:e9:7d:5c:17:28:5e:fb:ec:fc
 Signature Algorithm: sha256WithRSAEncryption
 Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = hogehoge.com
 Validity
 Not Before: Feb 10 16:13:01 2021 GMT
 Not After : Mar 12 16:13:01 2021 GMT
 Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = hogehoge.com
 ...
 X509v3 extensions:
 ...
 X509v3 Subject Alternative Name:
 DNS:hogehoge.com, DNS:fugafuga.com

# コンテナから出る
$ exit 

## ここからホストOS(Mac)

# 秘密鍵と証明書ができている
$ ls
cert.pem
private-key.pem

次にSANsに指定したhogehoge.comでlocalhost(127.0.0.1)にアクセスできるよう,
Mac(Prometheusを起動するマシン)の名前解決設定(/etc/hosts)を編集する.

# /etc/hostsにhogehoge.com(localhost)を追加
$ echo "127.0.0.1 hogehoge.com" | sudo tee -a /etc/hosts

最後に今回作った証明書(cert.pem)は公的な認証局が署名したものではないので,
証明書をMacのキーチェーンアクセスで開いて常に信頼するよう設定する.

これでHTTPS化に必要な証明書の設定は完了.

nginxを挟んでHTTPS化する

次に公式の手順¹に従ってnginxをHTTPS化して, その後ろでPrometheusが動く構成(リバースプロキシ)をつくる.

今回も例に依ってDocker Composeで試すが, 非コンテナ環境の場合はコンテナ名で名前解決している部分を適切な名前(ホスト名)に置き換えて,
docker-compose.ymlで指定している場所に各種の設定ファイルを配置すれば動くはず.

Prometheus
- リバースプロキシ用の設定を引数で設定
  - --web.external-url : 証明書のSANsに指定した名前+リクエストを受け付けるパス
  - --web.route-prefix : /を明示的に指定
nginx
- PrometheusのリバースプロキシとHTTPSの設定をhttps.confに記述する
- 秘密鍵, 証明書を指定の場所に配置する

コンテナを立ち上げてみる.

# cert.pemとprivate-key.pemは先ほど作ったオレオレ証明書と秘密鍵
$ tree .
.
├── cert.pem
├── docker-compose.yml
├── https.conf
└── private-key.pem

# コンテナ起動
$ docker-compose up -d --force-recreate --remove-orphans

# localhostの443ポートがnginxコンテナに割り当てられている
$ docker-compose ps
 Name Command State Ports
----------------------------------------------------------------------------------
nginx /docker-entrypoint.sh ngin ... Up 0.0.0.0:443->443/tcp, 80/tcp
prometheus /bin/prometheus --config.f ... Up 9090/tcp

# オレオレ証明書(cert.pem)を信頼する設定でPrometheus APIを叩いてみる
$ curl --cacert ./cert.pem https://hogehoge.com/prometheus/api/v1/label/job/values
{"status":"success","data":["prometheus"]}

コンテナが立ち上がり, hogehoge.comがHTTPSで公開されていることが確認できた.

念の為Chromeでhttps://hogehoge.com/prometheus/を開いてみる.

PrometheusがHTTPSで公開されていて, Chromeがオレオレ証明書を信頼していることが確認できた.

Prometheus単独でHTTPS化する

今までPrometheusをHTTPS化する際は先ほど試したようにリバースプロキシを使うのが推奨されていたのだが,

なんとversion 2.24からはPrometheus単独でのHTTPS化にも対応した²らしい(まだお試し機能らしいが)ので試してみる.

まずは新しいHTTPS関連の設定ファイルweb-config.yml³で証明書と秘密鍵の場所を指定する.
(この他にもクライアント認証やBasic認証も設定できるらしい.)

次にPrometheusの実行時引数--web.config.fileでweb-config.ymlの場所を指定する.
また, hogehoge.comでアクセスを受けられるように--web.external-urlを設定する(nginxを使う場合と異なり/prometheusは不要).

コンテナを立ち上げてみる.

# cert.pemとprivate-key.pemは先ほど作ったオレオレ証明書と秘密鍵
$ tree .
.
├── cert.pem
├── docker-compose.yml
├── private-key.pem
└── web-config.yml

# コンテナ起動
$ docker-compose up -d --force-recreate --remove-orphans

# localhostの443ポートがPrometheusコンテナに割り当てられている
$ docker-compose ps
 Name Command State Ports
------------------------------------------------------------------------------------
prometheus /bin/prometheus --config.f ... Up 0.0.0.0:443->443/tcp, 9090/tcp

# オレオレ証明書(cert.pem)を信頼する設定でPrometheus APIを叩いてみる
$ curl --cacert ./cert.pem https://hogehoge.com/api/v1/label/job/values
{"status":"success","data":["prometheus"]}

次にChromeでhttps://hogehoge.com/を開くと, nginxを使ったときと同様にPrometheusがHTTPSで公開されていることがわかる.

やったぜ.

ただしnginxを使う場合には無かった注意点として, 今回はPrometheus自身がHTTPSで起動しているため,
自身のメトリクス(/metrics)のスクレイプ設定がデフォルトのままだとプロトコルがHTTPのままなのでスクレイプに失敗する.

今回はとりあえずPrometheusをHTTPS化するのが目的だったので, ここでおわり.

おわり

PrometheusをHTTPS化してみた.
nginxを使う方法はそれはそう…という感じだけど, Prometheus単体でHTTPS化できるのは知らなかった.

ただしPrometheus単独でのHTTPS対応はまだお試し機能っぽいのと,
Alertmanagerはまだ対応してない?みたいなので, 併せて対応する場合はnginxを使うように統一したほうが良さそう.

おまけ

PrometheusとAlertmanagerの冗長構成を試す

Sun, 07 Feb 2021 00:00:00 +0000

やったことのまとめ

同じ設定のPrometheusを単純に複数台動かして冗長化した
複数台のAlertmanagerをメッシュとして動かして冗長化した

PrometheusとAlertmanagerでサービスを監視するのは良いんだけど, 1台ずつで運用してると監視コンポーネント自身がダウンしたときに監視できなくなってしまう.

だったら監視コンポーネント自体も冗長化すれば可用性を上げられるのでは?と思い試してみた.

Prometheusの時系列DBの冗長化はかなり難しいっぽいので今回はやらない.

Prometheusは単純に同じ設定のものを複数同時に動かし, Alertmanagerは複数台を同期してメッシュとして動かすのが良さそう.

設定ファイルとか

つかうもの

macOS Mojave 10.14
Docker Desktop for Mac
- Version 3.1.0
- Docker Engine Version 20.10.2
- docker-compose version 1.27.4
Prometheus (Docker)
- version 2.24.1
Alertmanager (Docker)
- version 0.21.0
Grafana (Docker)
- version 7.3.7
nginx (Docker)
- version 1.18.0

やったこと

Prometheusを冗長化する
Alertmanagerも冗長化する

Prometheusを冗長化する

Prometheus公式のFAQによると可用性を高めるには
「同じ設定のものを複数台動かせ. 複数のPrometheusで同じアラートが発火した場合でもAlertmanager側で勝手に重複排除してくれる.(意訳)」¹
とのこと. 単純で良い.

とりあえずPrometheusを3台立ててnginxで負荷分散(ラウンドロビン)する²ような構成をDocker Composeで作ってみた.

その他の設定は下記のとおり.

Prometheus x3
- prometheus.yml : 互いを監視するような設定を入れる
- rules.yml : 任意の設定
Alertmanager
- alertmanager.yml : 任意の設定
Grafana
- grafana.ini : 任意の設定(リバースプロキシ対応)
- datasource.yaml : PrometheusをData Sourceとする設定
nginx
- default.conf : Prometheusのロードバランシング設定(やらなくても良い)

Prometheus, Alertmanager, Grafanaのリバースプロキシ設定は前回やったときとほぼ同じだけど, 今回の目的はPrometheusの冗長化なのでここらへんはやらなくても良い.

rules.yml, alertmanager.ymlの設定は有効なものなら何でも良いので前回と同じものを使う.

grafana.iniも一応前回と同じものを使うけど今回の目的はあくまでPrometheusの冗長化なのでデフォルト設定のままでも良い.

設定ファイルが準備できたらコンテナを立ち上げる.

# ディレクトリ構成
$ tree .
.
├── deployment
│   ├── alertmanager
│   │   └── alertmanager.yml
│   ├── grafana
│   │   ├── datasource.yaml
│   │   └── grafana.ini
│   ├── nginx
│   │   └── default.conf
│   └── prometheus
│   ├── prometheus.yml
│   └── rules.yml
└── docker-compose.yml

# コンテナ起動
$ docker-compose up -d --force-recreate

$ docker-compose ps
 Name Command State Ports
---------------------------------------------------------------------------
alertmanager /bin/alertmanager --config ... Up 9093/tcp
grafana /run.sh Up 3000/tcp
nginx /docker-entrypoint.sh ngin ... Up 0.0.0.0:80->80/tcp
prometheus-01 /bin/prometheus --config.f ... Up 9090/tcp
prometheus-02 /bin/prometheus --config.f ... Up 9090/tcp
prometheus-03 /bin/prometheus --config.f ... Up 9090/tcp

nginxで80番ポートが開けてあるので, http://localhost/prometheus/を開くとPrometheusが起動していることを確認できる.

画面上ではどのPrometheusコンテナがレスポンスを返しているのかわからないが, 実際にはnginxにより1台ずつ順番にリクエストを受け付けている(ラウンドロビン). はず. 　

http://localhost/grafanaを開きGrafanaでダッシュボードを作成する.

Data SourceとしてnginxのPrometheus用エンドポイントと念の為それぞれのPrometheus3台のエンドポイントを設定してあるのでそれぞれのData Sourceに対して同じメトリクス(up)のダッシュボードを作ってみる.

余談だけど今回はnginxロードバランサの下で複数台のPrometheusを動かしているので, GrafanaのData Sourceがnginx上のPrometheusエンドポイントを見ている場合はロードするたびに微妙にグラフ(メトリクス)が変わったりする.

この挙動が気持ち悪い場合はnginx上のエンドポイントじゃなくて個別のPrometheusをData Sourceにするほうが良いかもしれない(あとで気づいた).

この状態で3台あるPrometheusを一部落としてみる.

# Prometheusを2台落とす
$ docker-compose stop prometheus-01 prometheus-02

$ docker-compose ps
 Name Command State Ports
----------------------------------------------------------------------------
alertmanager /bin/alertmanager --config ... Up 9093/tcp
grafana /run.sh Up 3000/tcp
nginx /docker-entrypoint.sh ngin ... Up 0.0.0.0:80->80/tcp
prometheus-01 /bin/prometheus --config.f ... Exit 0
prometheus-02 /bin/prometheus --config.f ... Exit 0
prometheus-03 /bin/prometheus --config.f ... Up 9090/tcp

1台目と2台目のPrometheusを落としたので, 3台目のPrometheusでInstanceDownのアラートが発火する.

Alertmanagerが反応し, アラートの通知が届く.
(通知はAlertmanagerからGmail経由で送る設定にしている)

冗長構成にしたおかげで複数台用意したPrometheusが一部落ちてもメトリクスは継続して収集されていることと,
相互監視の設定により一部が落ちた場合にも残りのPrometheusでアラートが発火して検知できることが確認できた.

今度はAlertmanagerで複数のPrometheusから送られた同じアラートが重複排除されることを確かめるため, 3台目のPrometheusだけを落としてみる.

# Prometheusを復旧させる
$ docker-compose start prometheus-01 prometheus-02

# 3台目だけを落とす
$ docker-compose stop prometheus-03

$ docker-compose ps
 Name Command State Ports
----------------------------------------------------------------------------
alertmanager /bin/alertmanager --config ... Up 9093/tcp
grafana /run.sh Up 3000/tcp
nginx /docker-entrypoint.sh ngin ... Up 0.0.0.0:80->80/tcp
prometheus-01 /bin/prometheus --config.f ... Up 9090/tcp
prometheus-02 /bin/prometheus --config.f ... Up 9090/tcp
prometheus-03 /bin/prometheus --config.f ... Exit 0

今度は3台目のPrometheusが落ちたので, 1台目と2台目のPrometheusで同じInstanceDownのアラートが発生する.

ただしAlertmanager側で重複が排除されるようになっているので, アラートは1件として扱われて通知も1件のみ届く.

以上で複数のPrometheusで同じアラートが発火した場合でもAlertmanagerで重複排除されることが確認できた.

Alertmanagerも冗長化する

Prometheusは冗長化できたが, Alertmanagerだって絶対落ちないとは限らないのでこれも冗長化したい.

ただしAlertmanagerの場合は実際に通知を送る機能があるため, Prometheusのように単純に同じものを複数用意するのはあまり良い方法ではなさそう.
(1つのアラートに対して複数のAlertmanagerがそれぞれ通知を送ってしまう)

このため, 複数のAlertmanagerを同時に動かす場合は互いの状況を知るためにメッシュを構成する³.

難しそうに思えるがAlertmanagerの冗長化機能はあらかじめ有効化されているので, 実行時引数--cluster.peerで同時に動かす対象のホスト名を指定してやれば良い.
(相互の確認に使うポートは9093でなく9094であることに注意)

Prometheus x3
- prometheus.yml : 監視対象とアラートを送る対象に複数のAlertmanagerを追加する(必須)
- rules.yml : そのまま
Alertmanager x3
- alertmanager.yml : そのまま
- 実行時引数--cluster.peerで他のAlertmanagerを指定(必須)
- 動作確認用に9093番ポートを疎通可能にしておく(やらなくても良い)
Grafana
- grafana.ini : そのまま
- datasource.yaml : そのまま
nginx
- default.conf : 複数のAlertmanagerのロードバランシング設定を追加(やらなくても良い)

prometheus.ymlでアラートの送信先を指定する際はnginxで負荷分散しているAlertmanagerのエンドポイント(/alertmanager)を指定したくなるが,
公式FAQによると「PrometheusからはすべてのAlertmanagerにアラートを送れ」とあるので今回はそれに従っている.

設定ファイルが準備できたら再度コンテナを立ち上げる.

# ディレクトリ構成
$ tree .
.
├── deployment
│   ├── alertmanager
│   │   └── alertmanager.yml
│   ├── grafana
│   │   ├── datasource.yaml
│   │   └── grafana.ini
│   ├── nginx
│   │   └── default.conf
│   └── prometheus
│   ├── prometheus.yml
│   └── rules.yml
└── docker-compose.yml

# コンテナ起動
$ docker-compose up -d --force-recreate --remove-orphans

# 今回は動作確認用にlocalhostから直接Alertmanagerにつながるようにしている
$ docker-compose ps
 Name Command State Ports
---------------------------------------------------------------------------------
alertmanager-01 /bin/alertmanager --config ... Up 0.0.0.0:8093->9093/tcp
alertmanager-02 /bin/alertmanager --config ... Up 0.0.0.0:8094->9093/tcp
alertmanager-03 /bin/alertmanager --config ... Up 0.0.0.0:8095->9093/tcp
grafana /run.sh Up 3000/tcp
nginx /docker-entrypoint.sh ngin ... Up 0.0.0.0:80->80/tcp
prometheus-01 /bin/prometheus --config.f ... Up 9090/tcp
prometheus-02 /bin/prometheus --config.f ... Up 9090/tcp
prometheus-03 /bin/prometheus --config.f ... Up 9090/tcp

まずはそれぞれのAlertmanagerを開いてメッシュが有効になっていることを確認する.

alertmanager-01 : http://localhost:8093/#/status
alertmanager-02 : http://localhost:8094/#/status
alertmanager-03 : http://localhost:8095/#/status

Cluster Statusを見るとそれぞれのNameを互いにPeersとして認識していることがわかる.

この状態で試しに1台目のAlertmanagerでSilence(アラートを一時的に無視する設定)を作成してみる⁴.

すると2台目と3台目のAlertmanagerにも同じSilenceが勝手に作成されており, これで3台のAlertmanagerがメッシュとして正しく動作していることがわかる.

最後にAlertmanagerの動作確認のため, Grafanaを落としてInstanceDownのアラートを発火させてみる.

# Grafanaを落とす
$ docker-compose stop grafana

$ docker-compose ps
 Name Command State Ports
----------------------------------------------------------------------------------
alertmanager-01 /bin/alertmanager --config ... Up 0.0.0.0:8093->9093/tcp
alertmanager-02 /bin/alertmanager --config ... Up 0.0.0.0:8094->9093/tcp
alertmanager-03 /bin/alertmanager --config ... Up 0.0.0.0:8095->9093/tcp
grafana /run.sh Exit 0
nginx /docker-entrypoint.sh ngin ... Up 0.0.0.0:80->80/tcp
prometheus-01 /bin/prometheus --config.f ... Up 9090/tcp
prometheus-02 /bin/prometheus --config.f ... Up 9090/tcp
prometheus-03 /bin/prometheus --config.f ... Up 9090/tcp

今までと同じくupが0になり, Prometheusでアラートが発火する.

Alertmanager側でもアラートを受け取っているが,
先程確認したとおり3台のAlertmanagerはメッシュとして動作しているのでそれぞれが動作して3回通知が送られるということはなく通知は1件のみ届く.

やったぜ.
PrometheusだけでなくAlertmanagerも冗長構成で動かすことができた.

おわり

PrometheusとGrafanaを冗長構成で動かしてみた.

今回はGrafanaの冗長化はしなかったけど, 落ちたところでグラフが見られなくなるくらいしか困ることがないのでやらなくて正解だったかも.
(やったとしてもnginxの下に複数台ぶらさげるだけになりそう)

今回はDocker Composeで試してみたけど, 実際にそれぞれ別のサーバーで動かす場合もコンテナ名で名前解決している部分をホスト名に変えてやれば同様の動作になるはず.
お金と時間に余裕があればVMとかで試してみたい(たぶんやらない).

おまけ

自作Exporter+Prometheus+Alertmanager+GrafanaをまとめてDocker Composeで動かす

Fri, 05 Feb 2021 00:00:00 +0000

やったことのまとめ

自作Exporter, Prometheus, Alertmanager, GrafanaをまとめてDocker Composeで動かした
nginxコンテナを追加してリバースプロキシした

Prometheus用のExporterを自作するときに動作確認の時点でGrafanaのグラフが見られたりAlertmanagerで通知されるメッセージとかが確認できるとメトリクスやラベルの設計がしやすい(気がする)ので,
それらが全部入りの環境をDocker Composeで作ってみた.

その他もろもろの設定ファイル

つかうもの

macOS Mojave 10.14
Docker Desktop for Mac
- Version 3.1.0
- Docker Engine Version 20.10.2
- docker-compose version 1.27.4
Prometheus (Docker)
- version 2.24.1
Alertmanager (Docker)
- version 0.21.0
Grafana (Docker)
- version 7.3.7
nginx (Docker)
- version 1.18.0
自作Exporter
- 2112番ポートで起動できてDockerコンテナ化できるものなら何でも良い

やったこと

とりあえず起動する
リバースプロキシする

とりあえず起動する

それぞれDocker imageが公式で提供されているのでそれをそのまま起動すれば良さそう.

自作Exporterの動作確認をしたときと同様に適当にdocker-compose.ymlを書いてみる.

重要なのは以下の設定ファイルをそれぞれのコンテナにマウントしていること.

Prometheus
- 自作Exporterなどをスクレイプするための設定(prometheus.yml)
  - Docker Composeで起動しているので他のコンテナについてはすべてコンテナ名で名前解決できる
- アラートルール(rules.yml)
  - 任意のルールで良い
Alertmanager
- アラート通知設定(alertmanager.yml)
  - 任意の設定で良い
Grafana
- 基本設定(grafana.ini)
  - ログイン不要の設定をしておく
- Data Source設定(datasource.yaml)
  - Prometheusコンテナを指定する
- Dashboard設定(dashboard.yaml, dashboard.json)
  - dashboard.jsonは後から作っても良い

(rules.yml, alertmanager.ymlは何でも良いので前回のものを流用)

rules.yml

alertmanager.yml

(dashboard.jsonはあらかじめ作成済みのものがなければこの後作成する)

あとはこれらのファイルが以下のように配置されている状態でDocker Composeでコンテナを立ち上げる.

# ローカルでビルドしない場合はDockerfileとGo関連のファイルは不要
$ tree .
.
├── Dockerfile
├── deployment
│   ├── alertmanager
│   │   └── alertmanager.yml
│   ├── grafana
│   │   ├── dashboard.json
│   │   ├── dashboard.yaml
│   │   ├── datasource.yaml
│   │   └── grafana.ini
│   └── prometheus
│   ├── prometheus.yml
│   └── rules.yml
├── docker-compose.yml
├── go.mod
├── go.sum
└── main.go

# コンテナを起動(コードを編集したなどの理由で再度ビルドしたい場合はさらに--buildを付与する)
$ docker-compose up -d --force-recreate

$ docker-compose ps
 Name Command State Ports
------------------------------------------------------------------------------
alertmanager /bin/alertmanager --config ... Up 0.0.0.0:9093->9093/tcp
exporter ./app Up 0.0.0.0:2112->2112/tcp
grafana /run.sh Up 0.0.0.0:3000->3000/tcp
prometheus /bin/prometheus --config.f ... Up 0.0.0.0:9090->9090/tcp

あとはそれぞれのエンドポイントで動作確認する.

自作Exporter
- http://localhost:2112/metrics
Prometheus
- http://localhost:9090/
Alertmanager
- http://localhost:9093/
Grafana
- http://localhost:3000/

dashboard.jsonが未作成の場合はここで動作確認も兼ねてGrafana上でダッシュボード(自作Exporterのメトリクスがグラフ化できれば何でも良い)を作成し, Share➔Export➔Save to fileからJSONをダウンロードして以降はそれを使うようにする.

設定が正しく効いていれば予めPrometheusがData Sourceとして登録されていて, 全コンテナのメトリクスがスクレイプできていることも確認できる.

リバースプロキシする

このままでもいいんだけどせっかくなのでnginxでリバースプロキシする.

docker-compose.ymlにnginxコンテナを追加して, 以前やったときと同様の設定ファイルを作成してマウントする.

(リバースプロキシしているので, nginx以外のそれぞれのコンテナのポートは閉じておく)

Prometheus
- prometheus.yml, rules.yml: そのまま
- command(CMD)にリバースプロキシ用の設定¹を追加
Alertmanager
- alertmanager.yml: そのまま
- command(CMD)にリバースプロキシ用の設定を追加
Grafana
- datasource.yaml, dashboard.yaml, dashboard.json : そのまま
- grafana.ini
  - リバースプロキシ用の設定²を追加
nginx
- リバースプロキシ設定(default.conf)
- リンク用ページ(index.html)

再度コンテナを起動する.

$ tree .
.
├── Dockerfile
├── deployment
│   ├── alertmanager
│   │   └── alertmanager.yml
│   ├── grafana
│   │   ├── dashboard.json
│   │   ├── dashboard.yaml
│   │   ├── datasource.yaml
│   │   └── grafana.ini
│   ├── nginx
│   │   ├── default.conf
│   │   └── index.html
│   └── prometheus
│   ├── prometheus.yml
│   └── rules.yml
├── docker-compose.yml
├── go.mod
├── go.sum
└── main.go

$ docker-compose up -d --force-recreate

$ docker-compose ps
 Name Command State Ports
--------------------------------------------------------------------------
alertmanager /bin/alertmanager --config ... Up 9093/tcp
exporter ./app Up
grafana /run.sh Up 3000/tcp
nginx /docker-entrypoint.sh ngin ... Up 0.0.0.0:80->80/tcp
prometheus /bin/prometheus --config.f ... Up 9090/tcp

ここまでの設定に問題がなければそれぞれのパスでコンテナの動作確認ができる.

自作Exporter
- http://localhost/exporter/metrics
Prometheus
- http://localhost/prometheus/
Alertmanager
- http://localhost/alertmanager/
Grafana
- http://localhost/grafana/

もしくは, http://localhost/でリンクを張ったHTML(index.html)が表示できるのでそこから飛んでも良い.

最後に一応Alertmanagerの動作確認をする.

rules.ymlでInstanceDown(upが0になるだけで発火)のアラートルールを設定しているので, 試しに自作Exporterのコンテナを落としてみる.

$ docker-compose stop exporter

$ docker-compose ps
 Name Command State Ports
---------------------------------------------------------------------------
alertmanager /bin/alertmanager --config ... Up 9093/tcp
exporter ./app Exit 2
grafana /run.sh Up 3000/tcp
nginx /docker-entrypoint.sh ngin ... Up 0.0.0.0:80->80/tcp
prometheus /bin/prometheus --config.f ... Up 9090/tcp

それぞれのコンテナでメトリクスの変化に対応した処理が行われていることが確認できる.

アラートはAlertmanagerからGmail経由で送る設定にしているのでメールが届くことも確認できる.

やったぜ.

自作ExporterとPrometheus, Alertmanager, Grafanaを同時に動かして動作確認することができた.

おわり

終わってみれば大したことはないんだけど, 一回この構成をつくっておくと自作Exporterの開発が楽しくなる(メトリクスがすぐ可視化されアラートの動作確認までできる)のでやってよかったと思う.

Docker Composeの練習にもなってよかった.

おまけ

1月のそとちゃんまとめ(2021)

Tue, 02 Feb 2021 00:00:00 +0000

まとめ

腹の上にねこ
トンネル
ねずみ
ソファ

腹の上にねこ

俺のお腹の上に乗るのが癖になったらしい.

腹の上に乗るの完全に癖になってる pic.twitter.com/9bKr8zVZo0
— ずみし (@uzimihsr) January 18, 2021

前から俺が寝っ転がってるとたまに乗ってくることはあったんだけど,
そのタイミングでたくさん撫でたりおやつをあげたりしてたら習慣化した.

やっぱりねこは良いことがあるとちゃんと覚えるみたい. かしこい.😊

人の腹をベッドだと思っている pic.twitter.com/8vAcFHhgmK
— ずみし (@uzimihsr) January 25, 2021

俺がソファとかベッドに寝っ転がるとそとちゃんが乗ってきて,
そのまま俺の顔に頭を向けたりおしりを向けたり何回か向きを変えてベストポジションを探す.

ねこのすりすりこうげき pic.twitter.com/eBX2X6bvwL
— ずみし (@uzimihsr) January 9, 2021

おしり pic.twitter.com/kLcfzk1JOX
— ずみし (@uzimihsr) January 10, 2021

そしてそのまま1時間くらい動かずに撫でられるのがお決まりのパターン.

こうなってからが長い pic.twitter.com/DL6ReXMZet
— ずみし (@uzimihsr) January 15, 2021

そとちゃんが満足するまで俺が勝手に起きることは許されない!😱

おしりぽんぽんされてゴロゴロ言ってるし気持ちいいはずなのに怖い顔なの難しすぎ pic.twitter.com/G7Me4xKayS
— ずみし (@uzimihsr) January 18, 2021

でもねこが腹の上に乗るとやわらかくてあったかくて気持ち良いしめんどくさいことを全部忘れられるのでとても良い.

トンネル

普段と違うペットショップに行く機会があって, たまたま目についたねこ用トンネルを買ってみた.

トンネルがうちにきた pic.twitter.com/q5hRboMbim
— ずみし (@uzimihsr) January 5, 2021

キャットトンネル　木目柄

えらく気に入ったらしく, 毎日飽きずに遊んでいる.

はしゃいでる pic.twitter.com/j3esWctCdf
— ずみし (@uzimihsr) January 28, 2021

だいたい前足と頭だけ突っ込んだ状態で待機しているので, あとは横穴か向かいの出口からおもちゃを投げ込んであげると大はしゃぎであそぶ.

ちくわみたいでいいね〜 pic.twitter.com/6rYEBApoaV
— ずみし (@uzimihsr) January 5, 2021

おしり pic.twitter.com/cqBzzk8aF7
— ずみし (@uzimihsr) January 29, 2021

買ってよかった.

ねずみ

そとちゃんお気に入りのねずみのおもちゃだけど, 流石に遊びすぎてボロボロになってきた…

ねずみの毛がハゲてきた pic.twitter.com/23lSq8Yq1g
— ずみし (@uzimihsr) January 21, 2021

非売品だと思ってたので代わりが見つからず困ってたんだけど, 偶然にもトンネルを買ったのと同じお店で遂にそれっぽいおもちゃを見つけた.

ネズミごっこ

毛の色も同じで, 目鼻耳のパーツの色も同じだから流石に同じものだと信じたい.
(しっぽは遊んでるうちに切れた)

…が, 転がしたときの音が微妙に違うのでまだ遊んだり遊ばなかったりする.🤔

ねずみドリブル pic.twitter.com/c3u5PI29tr
— ずみし (@uzimihsr) December 31, 2020

(↑の動画のシャカシャカ鳴ってるねずみは古いやつ, 新しいのはもっとカラカラ鳴る)

ねこのこだわりは難しい…

ソファ

😭

😭😭

😭😭😭

😭😭😭😭

その気になればいつでもバリバリしてやるぞという顔 pic.twitter.com/zyeU2lBaDX
— ずみし (@uzimihsr) January 27, 2021

おわり

1月はそとちゃんとたくさん~~遊んであげられて~~遊ばせていただけてよかった.

今月みたいに普段と違うペットショップにいけるとおもちゃのレパートリーも広がるので, 出かけるたびに気にかけるようにしたい.

おまけ

promtool/amtoolでPrometheus/Alertmanagerの設定をチェックする

Thu, 28 Jan 2021 00:00:00 +0000

まとめ

promtoolとamtoolを使うとPrometheusの設定とアラートルール, Alertmanagerの設定をそれぞれ反映前にチェックすることができる.

Docker上でも動かせるのでCIにも組み込めそう.

# Prometheus設定ファイルのチェック
$ promtool check config prometheus.yml
# Docker版
$ docker container run --rm -v="$PWD/prometheus.yml:/prometheus-config/prometheus.yml" --entrypoint="promtool" prom/prometheus check config /prometheus-config/prometheus.yml

# アラートルールファイルのチェック
$ promtool check rules rules.yml
# Docker版
$ docker container run --rm -v="$PWD/rules.yml:/prometheus-config/rules.yml" --entrypoint="promtool" prom/prometheus check rules /prometheus-config/rules.yml

# Alertmanager設定ファイルのチェック
$ amtool check-config alertmanager.yml
# Docker版
$ docker container run --rm -v="$PWD/alertmanager.yml:/prometheus-config/alertmanager.yml" --entrypoint="amtool" prom/alertmanager check-config /prometheus-config/alertmanager.yml

環境

macOS Mojave 10.14
Docker Desktop for Mac
- Version 3.1.0
- Docker Engine Version 20.10.2
Prometheus
- version 2.24.1
promtool
- version 0.21.0
Alertmanager
- version 0.21.0
amtool
- version 0.20.0

# prometheus設定ファイル(prometheus.yml)とアラートルールファイル(rules.yml)を準備
$ ls
prometheus.yml rules.yml

# prometheus.ymlの内容をチェック
# prometheus.ymlでルールファイルを参照している場合はその対象もチェックしてくれる
$ promtool check config prometheus.yml
Checking prometheus.yml
 SUCCESS: 1 rule files found

Checking rules.yml
 SUCCESS: 1 rules found

# rulesだけのチェックも可能
$ promtool check rules rules.yml
Checking rules.yml
 SUCCESS: 1 rules found

# alertmanager設定ファイルも同様にチェックできる
$ amtool check-config alertmanager.yml
Checking 'alertmanager.yml' SUCCESS
Found:
 - global config
 - route
 - 1 inhibit rules
 - 1 receivers
 - 0 templates

これを使えばPrometheusやAlertmanagerの設定反映前に構文エラーをチェックすることができて便利.

試しにわざと間違ったPrometheus設定ファイルとアラートルールファイル, Alertmanager設定ファイルをチェックしてみる.

# 間違ったprometheus設定ファイル(prometheus.yml)をチェックする
$ promtool check config prometheus-error.yml
Checking prometheus-error.yml
 FAILED: parsing YAML file prometheus-error.yml: yaml: unmarshal errors:
 line 13: field target not found in type struct { Targets []string "yaml:\"targets\""; Labels model.LabelSet "yaml:\"labels\"" }

# 間違ったアラートルールファイルをチェックする
$ promtool check rules rules-error.yml
Checking rules-error.yml
 FAILED:
rules-error.yml: group "instance", rule 0, "InstanceDown": could not parse expression: 1:4: parse error: could not parse remaining input "= 0"...

# 間違ったAlertmanager設定ファイルをチェックする
$ amtool check-config alertmanager-error.yml
Checking 'alertmanager-error.yml' FAILED: yaml: unmarshal errors:
 line 7: field receiver not found in type config.plain

amtool: error: failed to validate 1 file(s)

ちゃんとエラー箇所とエラーの内容が表示された.

べんり.😊

Dockerで起動する

便利なpromtoolとamtoolだけど, PrometheusやAlertmanagerがインストールされていない環境ではなかなか使いづらい.

(実務でPrometheus/Alertmanagerの設定を直接手でいじることはあんまりなくて, リポジトリ上で設定ファイルを管理してCI/CDすることが多い. と思う.)

ということでDockerを使ってPrometheusがインストールされていない環境でもpromtoolを使えないか試してみる. 　

# Dockerでもできそう
$ docker container run --rm --entrypoint="promtool" prom/prometheus --version
promtool, version 2.24.1 (branch: HEAD, revision: e4487274853c587717006eeda8804e597d120340)
 build user: root@0b5231a0de0f
 build date: 20210120-00:09:36
 go version: go1.15.6
 platform: linux/amd64

$ docker container run --rm --entrypoint="amtool" prom/alertmanager --version
amtool, version 0.21.0 (branch: HEAD, revision: 4c6c03ebfe21009c546e4d1e9b92c371d67c021d)
 build user: root@dee35927357f
 build date: 20200617-08:54:02
 go version: go1.14.4

コマンドは実行可能みたいなので, あとはDockerコンテナ起動時のオプションで設定ファイルをマウントすれば良さそう.

$ ls
alertmanager-error.yml prometheus-error.yml rules-error.yml

# Dockerでもできた
$ docker container run --rm -v="$PWD:/prometheus-config" --entrypoint="promtool" prom/prometheus check config /prometheus-config/prometheus-error.yml
Checking /prometheus-config/prometheus-error.yml

 FAILED: parsing YAML file /prometheus-config/prometheus-error.yml: yaml: unmarshal errors:
 line 13: field target not found in type struct { Targets []string "yaml:\"targets\""; Labels model.LabelSet "yaml:\"labels\"" }

$ docker container run --rm -v="$PWD:/prometheus-config" --entrypoint="promtool" prom/prometheus check rules /prometheus-config/rules-error.yml
Checking /prometheus-config/rules-error.yml
 FAILED:
/prometheus-config/rules-error.yml: 5:13: group "instance", rule 1, "InstanceDown": could not parse expression: 1:4: parse error: unexpected "="

$ docker container run --rm -v="$PWD:/prometheus-config" --entrypoint="amtool" prom/alertmanager check-config /prometheus-config/alertmanager-error.yml
Checking '/prometheus-config/alertmanager-error.yml'amtool: error: failed to validate 1 file(s)

 FAILED: yaml: unmarshal errors:
 line 7: field receiver not found in type config.plain

# エラー時はちゃんと終了ステータスがnot 0になっている
$ echo $?
1

やったぜ.

PrometheusやAlertmanagerがインストールされていない環境でもDocker上でpromtoolとamtoolを使って設定ファイルの検証ができた.

おわり

promtoolとamtoolを触ってみて, Dockerで起動するところまで試した.

Docker imageさえあれば起動できるので, あとは細かい設定さえすればGitHub ActionsとかのCIツールで設定ファイルのチェックができると思う.

今回はpromtoolで設定ファイルのチェックしか試してないけど, 他にもアラートルールのユニットテストなんかもできるみたい²なので余裕があったらそっちも触ってみたい.

おまけ

Kubernetes Podのcommandに/bin/shを使うときは終了ステータスの扱いに気をつけようという話

Sun, 24 Jan 2021 17:58:02 +0900

まとめ

Pod終了時のphaseはコンテナのcommandとargsで指定されたメインプロセスの終了ステータスで判定されるので,

commandに/bin/sh -cを指定し, argsにコマンドを羅列するような場合は子プロセスの終了ステータスの扱いに気をつけないとエラーが発生しているのに異常終了しないことがある.

set -eや&&, $?を適宜使い分けるのが大切.

# falseコマンドで終了ステータス=1が返っているがハンドリングされていないので最後まで実行される
$ /bin/sh -c 'echo "abc"; false; echo "def"'
abc
def
$ echo $?
0

# set -eで途中0以外の終了ステータスが発生したらそこでプロセスを止める
$ /bin/sh -c 'set -e; echo "abc"; false; echo "def"'
abc
$ echo $?
1

# $?で終了ステータスを扱うことでも止められる
$ /bin/sh -c 'echo "abc"; false; result=$?; if [ $result -ne 0 ]; then exit $result; fi; echo "def"'
abc
$ echo $?
1

# &&を使って前のコマンドが正常に終了したときだけ次のコマンドを実行させる
$ /bin/sh -c 'echo "abc" && false && echo "def"'
abc
$ echo $?
1

環境

macOS Mojave 10.14
Docker Desktop for Mac
- Version 2.5.0.0
- Docker version 19.03.13
kind
- v0.9.0 go1.15.5 darwin/amd64
kubectl
- Client Version: v1.19.3
- Server Version: v1.19.1

# JobのPodが正常終了している
$ kubectl apply -f job-01.yaml
$ kubectl get job example-job-command-not-found
NAME COMPLETIONS DURATION AGE
example-job-command-not-found 1/1 7s 3m42s

$ kubectl get pod -l job-name=example-job-command-not-found
NAME READY STATUS RESTARTS AGE
example-job-command-not-found-j2dbv 0/1 Completed 0 3m20s

# not foundのエラーはちゃんと発生しているのに最後(echo "def")まで実行されている
$ kubectl logs example-job-command-not-found-j2dbv
abc
/bin/sh: yourcoolcmd: not found
def

コマンドの結果がなにかおかしかったら異常終了してほしいようなときにこの挙動は少し困ってしまう.

なんで?

結論から言うと, 原因は先のJob(というかPod)で起動したコンテナのプロセス

/bin/sh -c 'echo "abc"; yourcoolcmd; echo "def"'

が異常終了していなかった(終了ステータスが0だった)ため.

# exitCodeが0(正常終了)になっている
$ kubectl get pod example-job-command-not-found-j2dbv -o yaml | yq r - "status"
...
containerStatuses:
 - containerID: containerd://36c7d09a5f262ff2c18bb328f006059c87aafb8414ae293517eca3ec1e75844f
 image: docker.io/library/busybox:latest
 imageID: docker.io/library/busybox@sha256:c5439d7db88ab5423999530349d327b04279ad3161d7596d2126dfb5b02bfd1f
 lastState: {}
 name: busybox
 ready: false
 restartCount: 0
 started: false
 state:
 terminated:
 containerID: containerd://36c7d09a5f262ff2c18bb328f006059c87aafb8414ae293517eca3ec1e75844f
 exitCode: 0
 finishedAt: "2021-01-24T07:40:28Z"
 reason: Completed
 startedAt: "2021-01-24T07:40:28Z"
phase: Succeeded
...

まず大前提として, コンテナが終了したときのPodのステータス(phase)は次のどちらかの状態になる¹.

Succeeded
- Pod内のすべてのコンテナが正常に終了した
Failed
- Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了した(コンテナが0以外のステータスで終了したか、システムによって終了された)

Failedの条件のコンテナが0以外のステータスで終了したというのが重要.

先程のPodのコンテナでargsに指定したコマンド

echo "abc"
yourcoolcmd
echo "def"

はそれぞれ/bin/sh -c echo ...というプロセスの子プロセスとして起動される.

試しにMac上で同じコマンドを実行してみるとよくわかるが, たとえ途中のコマンド(yourcoolcmd)が失敗しても親プロセスが止まらず最後のコマンド(echo "def")が正常に終了しているので/bin/sh -c echo ...の終了ステータスは0(正常終了)になる.

# 途中の子プロセスが異常終了しても親プロセスが最後まで実行されている
$ /bin/sh -c 'echo "abc"; yourcoolcmd; echo "def"'
abc
/bin/sh: yourcoolcmd: command not found
def

$ echo $?
0

したがって, Podのcommandとargsで指定されたプロセスの終了ステータスが0になってしまうので,
PodのphaseがSucceededとなりJobも成功扱いになっている(たぶん).

これを防ぐためには, それぞれの終了ステータス($?)を観てエラーハンドリングするか, set -eもしくは&&を使うのが良い.

# 終了ステータス($?)を観てエラーハンドリングする
$ /bin/sh -c 'echo "abc"; yourcoolcmd; if [ $? -ne 0 ]; then exit 1; fi; echo "def"'
abc
/bin/sh: yourcoolcmd: command not found
$ echo $?
1

# set -eを使う
# 途中で0以外の終了ステータスが発生したときにそこで終了する
$ /bin/sh -c 'set -e; echo "abc"; yourcoolcmd; echo "def"'
abc
/bin/sh: yourcoolcmd: command not found
$ echo $?
127

# &&を使う
# 前のコマンドが正常終了しない場合は次のコマンドが実行されない
$ /bin/sh -c 'echo "abc" && yourcoolcmd && echo "def"'
abc
/bin/sh: yourcoolcmd: command not found
$ echo $?
127

試してみる

原因がなんとなくわかったので,
さっきのJobをちゃんと0以外の終了ステータスで終わるようにした.
(バッチ処理を想定して&&を使っているが, もちろん用途に応じて適宜set -eとか$?を使い分けるべき.)

# JobがBackoffLimitExceededで終了している
$ kubectl apply -f job-02.yaml
$ kubectl get job example-job-command-not-found-2
NAME COMPLETIONS DURATION AGE
example-job-command-not-found-2 0/1 2m14s 2m14s

$ kubectl get job example-job-command-not-found-2 -o yaml | yq r - "status"
conditions:
 - lastProbeTime: "2021-01-24T09:10:53Z"
 lastTransitionTime: "2021-01-24T09:10:53Z"
 message: Job has reached the specified backoff limit
 reason: BackoffLimitExceeded
 status: "True"
 type: Failed
failed: 2
startTime: "2021-01-24T09:10:40Z"

# Podのコンテナがちゃんと0以外の終了ステータス(exitCode)で終了している
$ kubectl get pod -l job-name=example-job-command-not-found-2
NAME READY STATUS RESTARTS AGE
example-job-command-not-found-2-bq4bl 0/1 Error 0 3m16s
example-job-command-not-found-2-jkdcw 0/1 Error 0 3m13s

$ kubectl get pod example-job-command-not-found-2-bq4bl -o yaml | yq r - "status"
...
containerStatuses:
 - containerID: containerd://09caecce3d813e48cacd53f90eefd5e4f18b7565af7c9351c7fef47dbe397834
 image: docker.io/library/busybox:latest
 imageID: docker.io/library/busybox@sha256:c5439d7db88ab5423999530349d327b04279ad3161d7596d2126dfb5b02bfd1f
 lastState: {}
 name: busybox
 ready: false
 restartCount: 0
 started: false
 state:
 terminated:
 containerID: containerd://09caecce3d813e48cacd53f90eefd5e4f18b7565af7c9351c7fef47dbe397834
 exitCode: 127
 finishedAt: "2021-01-24T09:10:42Z"
 reason: Error
 startedAt: "2021-01-24T09:10:42Z"
phase: Failed
...

$ kubectl logs example-job-command-not-found-2-bq4bl
abc
/bin/sh: yourcoolcmd: not found

ちゃんとPodの終了ステータスが0以外となり, Jobが失敗扱いになったことを確認できた.

おわり

Kubernetesというよりはシェルスクリプトの基本のおさらいになってしまったが, たまにやってしまうので戒めとして書いた.

終了ステータスの扱いは大切.

おまけ

https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase ↩︎

12月のそとちゃんまとめ(2020)

Wed, 30 Dec 2020 00:00:00 +0000

まとめ

パソコン絶対邪魔するねこ
成長
クリスマス

パソコン絶対邪魔するねこ

今まであんまり邪魔してこなかったのに,
俺が机で仕事をするようになってからやたらとパソコンの近くで遊ぶようになった.

ねこちゃんがキーボードに乗れないようにMacBook用のスタンド導入したんだけど…😭 pic.twitter.com/RApI7y92MD
— ずみし (@uzimihsr) December 8, 2020

一度こうなるとそとちゃんが満足するまで撫でないといけないので, とても困る(うれしい).

かまってタイム pic.twitter.com/JWFFwY9U3f
— ずみし (@uzimihsr) December 17, 2020

また, 今月導入した在宅勤務用のイスが気に入ったらしくて気を抜くとしょっちゅう占領していた.

パソコンの次は椅子
仕事妨害の手段が日々効率化されていく pic.twitter.com/eB9v0SSaHY
— ずみし (@uzimihsr) December 9, 2020

そとちゃんは変なところで肝が据わっているので, ちょっと動かしたくらいじゃぜんぜん降りようとしない…

回した pic.twitter.com/xTI9NqPx57
— ずみし (@uzimihsr) December 10, 2020

俺が仕事してなくても夜はイスで寝てたりするので, 単純に座り心地が気に入ったのかも?

ねた pic.twitter.com/9I0hipHXoF
— ずみし (@uzimihsr) December 14, 2020

成長

以前はねずみのおもちゃを失くすとそのままやる気をなくして寝てたりしたんだけど,

最近は失くしたらすぐに鳴いて教えてくれるようになった. えらい😊

「おもちゃが取れないところに入っちゃったからとってください」の顔 pic.twitter.com/SYw2YPjRau
— ずみし (@uzimihsr) December 22, 2020

でもそれ以前におもちゃを失くさずに遊べるようになると, もっとえらいなあ…😅
(そとちゃんはなぜか台所でねずみをドリブルするのが好きなので, 冷蔵庫の下によくシュートして取れなくなっちゃう)

ねこおちてた pic.twitter.com/uehluq1cmd
— ずみし (@uzimihsr) December 22, 2020

クリスマス

今年もそとちゃんがかわいいサンタさんになってくれた😊

サンタねこ pic.twitter.com/cK1ZWEUct4
— ずみし (@uzimihsr) December 24, 2020

…しかし服が結構動きづらくてそとちゃんが不機嫌だったので, サンタさんは数分で終了…

詫びちゅーるでなんとか許してもらった.

クリスマスちゅーる pic.twitter.com/lP8DkHjiJy
— ずみし (@uzimihsr) December 24, 2020

来年は腕を通さないマントタイプの服にしよう…

クリスマスプレゼントにはニャンコロビーをあげた🎁

今年もいい子にしてたねこにクリスマスプレゼント pic.twitter.com/vzOqXSmFjR
— ずみし (@uzimihsr) December 24, 2020

喜んでくれてよかった🎉

(この後1日で飽きちゃったのは秘密…😭)

おわり

今月もそとちゃんはよく遊んでよく食べて良い子だった.

世間は大変な1年だったけどそとちゃんは今年も特に大きな病気(誤飲騒動を除く)はなかったし,

俺が在宅勤務になったのもあって去年よりも一緒に遊べる時間が増えて楽しかった.

来年もそとちゃんが幸せに暮らせるようにしたい.

おまけ

Hugoを新しくしてThemeを変えた

Wed, 23 Dec 2020 22:30:18 +0900

やったことのまとめ

Hugoを更新した
HugoのThemeをBeautiful HugoからHugo Theme Stackに乗り換えた

つかうもの

macOS Mojave 10.14
Hugo v0.79.0
- 今回v0.56.3からv0.79.0に更新した
Hugo Theme Stack

やったこと

Hugoの更新
なんかおかしい
Themeの変更

Hugoの更新

使っているHugoのバージョンが結構古くなっていたので, 最新版にする.

自分の場合はbrewでインストールしているので, まずはbrew upgrade…

しようとしたら怒られた.

なんかGitHubとbrewの間でいろいろあって, shallow cloneをしないように変更があったらしい¹.

# どうして...
$ brew update
Error:
 homebrew-core is a shallow clone.
 homebrew-cask is a shallow clone.
To `brew update`, first run:
 git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core fetch --unshallow
 git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask fetch --unshallow
This restriction has been made on GitHub's request because updating shallow
clones is an extremely expensive operation due to the tree layout and traffic of
Homebrew/homebrew-core and Homebrew/homebrew-cask. We don't do this for you
automatically to avoid repeatedly performing an expensive unshallow operation in
CI systems (which should instead be fixed to not use shallow clones). Sorry for
the inconvenience!

# 言われたとおりにする
$ git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core fetch --unshallow
$ git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask fetch --unshallow

# できた
$ brew update
Updated 2 taps (homebrew/core and homebrew/cask).

気を取り直してHugoを更新する.

# 更新前の状態
$ hugo version
Hugo Static Site Generator v0.56.3/extended darwin/amd64 BuildDate: unknown

# hugoを更新
$ brew upgrade hugo

# 最新版になった
$ hugo version
Hugo Static Site Generator v0.79.0/extended darwin/amd64 BuildDate: unknown

できた.

なんかおかしい

Hugoの更新後にブログの状態をローカルで確認するためにhugo serverを実行したらなんかやたらと警告が出た.

# ページを立ち上げてみる...
$ cd blog
$ hugo server -D
...
WARN 2020/12/17 23:55:53 Failed to get translated string for language "en" and ID "postedOnDate": template: :1:13: executing "" at <.Count>: can't evaluate field Count in type string
...

なんかテンプレートに渡されるべきフィールドが変わっちゃってる?っぽくて直し方がよくわからなかった(無能)のと,
今まで使ってたBeautiful Hugoの開発が2019年の11月で止まっちゃってた²のもあって, これを機にThemeを変えることにした.
~~(自分で作ろうとしないあたりがダメ)~~

Themeの変更

適当にThemeの一覧³を漁ってたら良さそうなのがあった.

Hugo Theme Stack⁴

シンプルなデザインでいい感じ.

このままtheme配下にsubmodule addしてもいいんだけど,
どうしても細かい変更がしたいことがあったりするのでforkして使わせていただく…
(ライセンスなどはいじらないこと!)

# themeを追加する
$ git submodule add https://github.com/uzimihsr/hugo-theme-stack.git themes/hugo-theme-stack

# サンプルサイトの内容をコピーする
$ cp -r ./themes/hugo-theme-stack/exampleSite/* ./

あとはconfig.tomlの内容をconfig.yamlに書き直したり,
今までの記事の内容をcontent/post配下に移動したり画像ファイルの場所を変えたりしてお引越しは完了.

あまりにも泥臭い作業だったので詳細は省くけど,
今までとはpost配下の構造が違う(記事タイトルのディレクトリ配下にindex.mdと画像ファイルを配置する方式)ので元のブログ用ディレクトリの内容をいい感じにコピーするスクリプトを書いたりもした.
(ほんとにしょぼかったので割愛)

とりあえず元の記事は全部引っ越せたのでおしまい.

おわり

ブログのThemeを変えてみた.

前のデザインもシンプルで良かったけど, 新しいThemeもかなりいい感じ.

おまけ

kindで作ったKubernetesクラスタでHelmを試した

Thu, 17 Dec 2020 12:10:24 +0900

めっちゃべんり

kindで作成したKubernetesクラスタを使ってHelmクイックスタートの内容を試した.

やったことのまとめ

HelmのCLIをMacにインストールした
サンプルChartをKubernetesクラスタにインストールした

# Chartリポジトリの追加
$ helm repo add <リポジトリ名> <リポジトリURL>

# Chartリポジトリの更新
$ helm repo update

# 利用可能なChartの一覧を確認
$ helm search repo <キーワード>

# Chartの簡易情報
$ helm show chart <Chart名>

# Chartのインストール
$ helm install <Chart名> --generate-name

# リリースの確認
$ helm ls

# Chartのアンインストール
$ helm uninstall <リリース名>

つかうもの

macOS Mojave 10.14
Docker Desktop for Mac
- Version 2.5.0.0
- Docker version 19.03.13
- インストール済み
kind v0.9.0 go1.15.5 darwin/amd64
- インストール済み
Kubernetes v1.19.1
- kindで作成
kubectl Client Version: v1.19.3
- インストール済み
Helm v3.4.2+g23dd3af
- 今回インストールする

やったこと

Helmについて
Kubernetesクラスタの準備
MacにHelmをインストール
Chartのインストール
Chartのアンインストール

Helmについて

Helm¹はKubernetes用のパッケージマネージャー.

アプリケーションを動かすために必要な各種Kubernetesリソース(Pod, Service, ConfigMapなど)の定義や依存関係, 設定をまとめたChartを使うことでアプリケーションのデプロイを簡単にしてくれる. らしい.
(Ubuntuでいうapt, CentOSでいうyumみたいなもの)

以前はChartを解釈するためのTillerというHelm専用のコンポーネントをKubernetesクラスタにデプロイする必要があって面倒そうだったのでちょっと敬遠してたんだけど,
いつの間にか(Helm v3.0以降)Tillerが不要になった²らしいので試してみた.

Kubernetesクラスタの準備

まずはHelmでアプリを動かすためのKubernetesクラスタをkindで作成する.

今回は一応Ingressが使えるよう設定したけど, それも省けばかなりかんたんにクラスタを作成できる.

やっぱりkindはすごい.

# kindでクラスタを作成
$ cat <<EOF | kind create cluster --name helm-practice --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
 kubeadmConfigPatches:
 - |
 kind: InitConfiguration
 nodeRegistration:
 kubeletExtraArgs:
 node-labels: "ingress-ready=true"
 extraPortMappings:
 - containerPort: 80
 hostPort: 80
 protocol: TCP
 - containerPort: 443
 hostPort: 443
 protocol: TCP
EOF
Creating cluster "helm-practice" ...
 ✓ Ensuring node image (kindest/node:v1.19.1) 🖼
 ✓ Preparing nodes 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Set kubectl context to "kind-helm-practice"
You can now use your cluster with:

kubectl cluster-info --context kind-helm-practice

Thanks for using kind! 😊

# contextは自動で切り替わるけど念の為明示的に変えておく
$ kubectl config use-context kind-helm-practice
Switched to context "kind-helm-practice".

# Ingress Controllerのデプロイ
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/kind/deploy.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
configmap/ingress-nginx-controller created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
service/ingress-nginx-controller-admission created
service/ingress-nginx-controller created
deployment.apps/ingress-nginx-controller created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created
serviceaccount/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
$ kubectl wait --namespace ingress-nginx \
 --for=condition=ready pod \
 --selector=app.kubernetes.io/component=controller \
 --timeout=90s
pod/ingress-nginx-controller-6df69bd4f7-brc52 condition met

MacにHelmをインストール

以降はクイックスタート³の内容をなぞっていく.

Helmを使うにはまずChartをKubernetesクラスタに投下するためのCLIが必要になる.

…が, Macの場合はbrewで入るのでらくちん.

# helmをインストール
$ brew install helm
$ which helm
/usr/local/bin/helm

# 動作確認
$ helm version --short
v3.4.2+g23dd3af

# completionを効かせておくと楽
$ source <(helm completion zsh)

CLIがインストールできたら, Chartを取得するためのリポジトリを追加する.

# Chartリポジトリの追加
$ helm repo add stable https://charts.helm.sh/stable
"stable" has been added to your repositories

# Chartリポジトリを更新する
$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈

これでHelmの準備はOK.

Chartのインストール

いよいよChartをKubernetesクラスタにインストールする.

今回は例としてMySQLのChartを使う.

HelmのCLIはkubectlのcontextを参照してKubernetes APIへ操作を行うので,
contextが所望の設定になっているか注意する.

# Chartをインストールする前の状態
$ kubectl get all
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 10m

# Chart(stable/mysql)の簡易情報を確認
$ helm show chart stable/mysql
apiVersion: v1
appVersion: 5.7.30
deprecated: true
description: DEPRECATED - Fast, reliable, scalable, and easy to use open-source relational
 database system.
home: https://www.mysql.com/
icon: https://www.mysql.com/common/logos/logo-mysql-170x115.png
keywords:
- mysql
- database
- sql
name: mysql
sources:
- https://github.com/kubernetes/charts
- https://github.com/docker-library/mysql
version: 1.6.9

# Chartをインストール
$ helm install stable/mysql --generate-name
WARNING: This chart is deprecated
NAME: mysql-1608125461
LAST DEPLOYED: Wed Dec 16 22:31:04 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
MySQL can be accessed via port 3306 on the following DNS name from within your cluster:
mysql-1608125461.default.svc.cluster.local

To get your root password run:

 MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace default mysql-1608125461 -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo)

To connect to your database:

1. Run an Ubuntu pod that you can use as a client:

 kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il

2. Install the mysql client:

 $ apt-get update && apt-get install mysql-client -y

3. Connect using the mysql cli, then provide your password:
 $ mysql -h mysql-1608125461 -p

To connect to your database directly from outside the K8s cluster:
 MYSQL_HOST=127.0.0.1
 MYSQL_PORT=3306

 # Execute the following command to route the connection:
 kubectl port-forward svc/mysql-1608125461 3306

 mysql -h ${MYSQL_HOST} -P${MYSQL_PORT} -u root -p${MYSQL_ROOT_PASSWORD}

# DeploymentとServiceが作成されている
$ kubectl get all
NAME READY STATUS RESTARTS AGE
pod/mysql-1608125461-bfdcccddb-h97b8 1/1 Running 0 66s

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 11m
service/mysql-1608125461 ClusterIP 10.96.6.222 <none> 3306/TCP 66s

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/mysql-1608125461 1/1 1 1 66s

NAME DESIRED CURRENT READY AGE
replicaset.apps/mysql-1608125461-bfdcccddb 1 1 1 66s

# Helmでデプロイされたリリースの確認
$ helm ls
NAME 	NAMESPACE	REVISION	UPDATED 	STATUS 	CHART 	APP VERSION
mysql-1608125461	default 	1 	2020-12-16 22:31:04.174492 +0900 JST	deployed	mysql-1.6.9	5.7.30

MySQLのDeploymentとそれに対応したServiceが作成されている.

あとはChartインストール時のメッセージに従って動作確認してみる.

# Macからクラスタ内のServiceにポート転送する(別のシェルで実行)
$ kubectl port-forward svc/mysql-1608125461 3306
Forwarding from 127.0.0.1:3306 -> 3306
Forwarding from [::1]:3306 -> 3306

# Chartで自動生成されたSecretからDBのパスワードを取得
$ MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace default mysql-1608125461 -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo)

# クラスタ外(Mac)からクラスタ内のMySQLに接続
$ MYSQL_HOST=127.0.0.1
$ MYSQL_PORT=3306
$ mysql -h ${MYSQL_HOST} -P${MYSQL_PORT} -u root -p${MYSQL_ROOT_PASSWORD}
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 167
Server version: 5.7.30 MySQL Community Server (GPL)

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
+--------------------+
4 rows in set (0.01 sec)

mysql> ^DBye

ChartでインストールしたMySQLがちゃんと動いていることを確認できた.

やったぜ.

Chartのアンインストール

最後にChartをアンインストールしてみる.

これもコマンド1発.

# Chartをアンインストール
$ helm uninstall mysql-1608125461
release "mysql-1608125461" uninstalled

# リリースが消えている
$ helm ls
NAME	NAMESPACE	REVISION	UPDATED	STATUS	CHART	APP VERSION

# KubernetesもChartをインストールする前の状態に戻っている
$ kubectl get all
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 33m

あっさり消えた.

おわり

Helmを使ってChartをKubernetesにインストールしてみた.

なんとYAMLを1度も書かずに, CentOSでyum installするような感覚でKubernetes上でアプリを動かせてしまった. すごい.

どうして今まで使ってこなかったんだろうというくらい便利.

helmは神.

おまけ

Docker Desktop for MacのHyperKit VMに入る

Tue, 15 Dec 2020 21:10:35 +0900

コンテナのログファイルが見たい

Docker Desktop for MacでDockerのホストOSに入ってコンテナのログファイルが確認したかったんだけど詰まったのでメモ.

まとめ

特権コンテナでnsenterを実行するのがかんたん.

# 特権コンテナを実行してホストOSに入る
$ docker run -it --rm --privileged --pid=host justincormack/nsenter1

環境

macOS Mojave 10.14
Docker Desktop for Mac
- Version 2.5.0.0
- Docker version 19.03.13

やりかた

Macにはない?

Linux上でDockerコンテナを実行したときのログファイルはホストOSの/var/lib/docker/containers/<ContainerID>に吐き出されるんだけど,
Docker Desktop for Macで動かしたコンテナのログを見ようとしてもそんなディレクトリがそもそもmacOS上に存在しない…

# hellp-worldの実行
$ docker container run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
 (amd64)
 3. The Docker daemon created a new container from that image which runs the
 executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
 to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

# コンテナIDの確認
$ docker container ls -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f9a220a39165 hello-world "/hello" 17 seconds ago Exited (0) 16 seconds ago busy_matsumoto
$ docker container inspect f9a220a39165 -f {{.Id}}
f9a220a391654fd66c8094a2965da6e1255ffb97c6db047d0aef1985d2e49659

# ディレクトリがない
$ ls /var/lib/docker/containers/f9a220a391654fd66c8094a2965da6e1255ffb97c6db047d0aef1985d2e49659
ls: /var/lib/docker/containers/f9a220a391654fd66c8094a2965da6e1255ffb97c6db047d0aef1985d2e49659: No such file or directory
$ ls /var/lib/docker/containers
ls: /var/lib/docker/containers: No such file or directory

これはDocker Desktop for MacのDockerがmacOS上で直接動作しているわけではなく,
macOS上に構築されたHyperKit VMの上で動作している¹ため.

VMに入る

じゃあHyperKit VMに入ればいいじゃんという話.

ちょっと調べると

~/Library/Containers/com.docker.docker/Data/vms/0/ttyをscreenで呼び出す
特権コンテナを立ち上げてnsenterでホストOSに入る

といった方法²が出てきた.

…が, 自分の環境だとscreenを実行してもCannot exec '/Users/uzimihsr/Library/Containers/com.docker.docker/Data/vms/0/tty': No such file or directoryと表示されて落ちてしまった.

# どうして...
$ screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty
[screen is terminating]

# そもそもttyコマンドが見当たらない
$ ls ~/Library/Containers/com.docker.docker/Data/vms/0/tty
ls: /Users/uzimihsr/Library/Containers/com.docker.docker/Data/vms/0/tty: No such file or directory

なんかIssueに似た症状のコメント³も上がってるので, 自分だけじゃないはず…🤔

回避方法もよくわかんなかったのでscreenを使う方法は諦めて,
特権コンテナ⁴を使う方法を試してみる.

# 特権コンテナを使ってホストOS(VM)に入る
$ docker run -it --rm --privileged --pid=host justincormack/nsenter1
/ # hostname
docker-desktop
/ # uname -a
Linux docker-desktop 5.4.39-linuxkit #1 SMP Fri May 8 23:03:06 UTC 2020 x86_64 Linux

VMに入れたっぽい…!

目的のコンテナログも表示できる.

## 以下すべて特権コンテナ(ホストOS)内で実行
# コンテナのログファイルを探す
$ ls /var/lib/docker/containers/f9a220a391654fd66c8094a2965da6e1255ffb97c6db047d0aef1985d2e49659
checkpoints hosts
config.v2.json mounts
f9a220a391654fd66c8094a2965da6e1255ffb97c6db047d0aef1985d2e49659-json.log resolv.conf
hostconfig.json resolv.conf.hash
hostname

# ログファイルの表示
$ cat /var/lib/docker/containers/f9a220a391654fd66c8094a2965da6e1255ffb97c6db047d0aef1985d2e49659/f9a220a391654fd66c8094a2965da6e1255ffb97c6db047d0aef1985d2e49659-json.log
{"log":"\n","stream":"stdout","time":"2020-12-15T12:25:05.3727159Z"}
{"log":"Hello from Docker!\n","stream":"stdout","time":"2020-12-15T12:25:05.3727757Z"}
{"log":"This message shows that your installation appears to be working correctly.\n","stream":"stdout","time":"2020-12-15T12:25:05.372871Z"}
{"log":"\n","stream":"stdout","time":"2020-12-15T12:25:05.3728948Z"}
{"log":"To generate this message, Docker took the following steps:\n","stream":"stdout","time":"2020-12-15T12:25:05.3729341Z"}
{"log":" 1. The Docker client contacted the Docker daemon.\n","stream":"stdout","time":"2020-12-15T12:25:05.3729571Z"}
{"log":" 2. The Docker daemon pulled the \"hello-world\" image from the Docker Hub.\n","stream":"stdout","time":"2020-12-15T12:25:05.3729785Z"}
{"log":" (amd64)\n","stream":"stdout","time":"2020-12-15T12:25:05.372997Z"}
{"log":" 3. The Docker daemon created a new container from that image which runs the\n","stream":"stdout","time":"2020-12-15T12:25:05.3730192Z"}
{"log":" executable that produces the output you are currently reading.\n","stream":"stdout","time":"2020-12-15T12:25:05.3731413Z"}
{"log":" 4. The Docker daemon streamed that output to the Docker client, which sent it\n","stream":"stdout","time":"2020-12-15T12:25:05.3731663Z"}
{"log":" to your terminal.\n","stream":"stdout","time":"2020-12-15T12:25:05.3732665Z"}
{"log":"\n","stream":"stdout","time":"2020-12-15T12:25:05.3732845Z"}
{"log":"To try something more ambitious, you can run an Ubuntu container with:\n","stream":"stdout","time":"2020-12-15T12:25:05.3733071Z"}
{"log":" $ docker run -it ubuntu bash\n","stream":"stdout","time":"2020-12-15T12:25:05.3733248Z"}
{"log":"\n","stream":"stdout","time":"2020-12-15T12:25:05.373345Z"}
{"log":"Share images, automate workflows, and more with a free Docker ID:\n","stream":"stdout","time":"2020-12-15T12:25:05.3733674Z"}
{"log":" https://hub.docker.com/\n","stream":"stdout","time":"2020-12-15T12:25:05.3733901Z"}
{"log":"\n","stream":"stdout","time":"2020-12-15T12:25:05.3734126Z"}
{"log":"For more examples and ideas, visit:\n","stream":"stdout","time":"2020-12-15T12:25:05.3734351Z"}
{"log":" https://docs.docker.com/get-started/\n","stream":"stdout","time":"2020-12-15T12:25:05.3734587Z"}
{"log":"\n","stream":"stdout","time":"2020-12-15T12:25:05.3734814Z"}

# コンテナから出る
$ exit

Docker Desktop for Macで動かしたDockerコンテナの標準出力の内容がログファイルとして閲覧できた.

やったぜ.

おわり

Docker Desktop for MacでDockerを動かしているVMに入り, コンテナのログファイルを閲覧することができた.

DockerがそもそもMacOSで直接動作していないことを理解できてなかったので, 勉強になった…

HyperKitじゃなくてVirtualBoxでmacOS上にVMを立ててDockerを動かす方法もあるみたいなので, 余裕があれば試してみたい.

おまけ

kind(Kubernetes IN Docker)を試した

Mon, 14 Dec 2020 22:13:17 +0900

かんたんすぎる

Kubernetesの動作確認環境として, 簡単にクラスタを用意できるkindを使ってみた.

やったことのまとめ

kindをMacにインストールした
kindでKubernetesクラスタを作成, 削除した
kindで作ったクラスタにIngress Controllerをデプロイした

つかうもの

macOS Mojave 10.14
Docker Desktop for Mac
- Version 2.5.0.0
- Docker version 19.03.13
- インストール済み
anyenv 1.1.1
- インストール済み
goenv 2.0.0beta11
- インストール済み
go version go1.15.5 darwin/amd64
- 今回入れる
kind v0.9.0 go1.15.5 darwin/amd64
- 今回入れる
kubectl Client Version: v1.19.3
- インストール済み

やったこと

kindってなに
Goの更新
kindのインストール
クラスタの起動
Ingressの設定
クラスタの削除

kindってなに

kind¹はDockerコンテナをNodeとして動かすことでローカル環境でKubernetesクラスタを動作させるツール.

今までローカルでの動作確認にはDocker Desktopで作れるKuberentesクラスタを使ってたんだけど,
この前Kubernetes v1.20以降はDockerがNodeのコンテナランタイムとして非推奨²になるとのお知らせが出ていた.

Docker DesktopのKubernetesクラスタはDockerをコンテナランタイムとして使っているので, そのうち使えなくなるかも…

# Docker Desktopで立てたKubernetesクラスタのコンテナランタイムはDocker
$ kubectl get nodes -o wide --context=docker-desktop
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
docker-desktop Ready master 33d v1.19.3 192.168.65.3 <none> Docker Desktop 5.4.39-linuxkit docker://19.3.13

ということで, これを機にローカルでの動作確認用Kubernetesクラスタはkindで作ることにした.
(kindではNodeでcontainerd³をランタイムとして使っているので問題ないらしい)

Goの更新

(Goの最新版がインストールされている環境なら飛ばしてOK)

kindのクイックスタート⁴によるとGoの最新版を使ってね!とのことなのでせっかくだし新しいGo(1.15)をインストールする.

$ go version
go version go1.14.6 darwin/amd64

# goenvを更新
$ anyenv install goenv
anyenv: /Users/uzimihsr/.anyenv/envs/goenv already exists
Reinstallation keeps versions directories
continue with installation? (y/N) y
...
Install goenv succeeded!
Please reload your profile (exec $SHELL -l) or open a new session.

# シェルを再起動
$ exec $SHELL -l

# インストール可能なバージョンの一覧を確認
$ goenv install -l | grep 1.15
 1.15.0
 1.15beta1
 1.15rc2
 1.15.1
 1.15.2
 1.15.3
 1.15.4
 1.15.5

# Go 1.15.5をインストール
$ goenv install 1.15.5
Downloading go1.15.5.darwin-amd64.tar.gz...
-> https://golang.org/dl/go1.15.5.darwin-amd64.tar.gz
Installing Go Darwin 64bit 1.15.5...
Installed Go Darwin 64bit 1.15.5 to /Users/uzimihsr/.anyenv/envs/goenv/versions/1.15.5

# このMacで常にGo 1.15.5を使うようにする
$ goenv global 1.15.5
$ goenv rehash

# 確認
$ goenv versions
 1.12.9
 1.13.0
 1.14.6
* 1.15.5 (set by /Users/uzimihsr/.anyenv/envs/goenv/version)

$ go version
go version go1.15.5 darwin/amd64

$ echo $GOPATH
/Users/uzimihsr/go/1.15.5

OK.

kindのインストール

次にkindをインストールする.

といってもgo getで入るのでインストール自体は1行で終わっちゃう.

クッソかんたん.

# kindのインストール
$ GO111MODULE="on" go get sigs.k8s.io/kind@v0.9.0

# $GOPATH/bin/kindに入っている
$ which kind
/Users/uzimihsr/go/1.15.5/bin/kind

# 動作確認
$ kind version
kind v0.9.0 go1.15.5 darwin/amd64

クラスタの起動

いよいよKubernetesクラスタを起動する.

…これもコマンド1発でできる.

めっちゃかんたん.

# Kubernetesクラスタ(kind-kind)の作成
$ kind create cluster
Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.19.1) 🖼
 ✓ Preparing nodes 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Not sure what to do next? 😅 Check out https://kind.sigs.k8s.io/docs/user/quick-start/

kubectlのcontextが勝手に切り替わるので, すぐにクラスタの操作もできる.

# kubectlのcontextが自動で変更されている
$ kubectl config view --minify
apiVersion: v1
clusters:
- cluster:
 certificate-authority-data: DATA+OMITTED
 server: https://127.0.0.1:63917
 name: kind-kind
contexts:
- context:
 cluster: kind-kind
 user: kind-kind
 name: kind-kind
current-context: kind-kind
kind: Config
preferences: {}
users:
- name: kind-kind
 user:
 client-certificate-data: REDACTED
 client-key-data: REDACTED

# うまく切り替わっていない場合もkindコマンドから有効なkubeconfigを取得可能
$ kind get kubeconfig --name kind
apiVersion: v1
clusters:
- cluster:
 certificate-authority-data: ...
 server: https://127.0.0.1:63917
 name: kind-kind
contexts:
- context:
 cluster: kind-kind
 user: kind-kind
 name: kind-kind
current-context: kind-kind
kind: Config
preferences: {}
users:
- name: kind-kind
 user:
 client-certificate-data: ...
 client-key-data: ...

# 動作確認
$ kubectl cluster-info --context kind-kind
Kubernetes master is running at https://127.0.0.1:63917
KubeDNS is running at https://127.0.0.1:63917/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

実際にNode用のコンテナが起動していることも確認できる.

# Nodeが1つ作成されている(コンテナランタイムがcontainerd!)
$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
kind-control-plane Ready master 19m v1.19.1 172.19.0.2 <none> Ubuntu Groovy Gorilla (development branch) 5.4.39-linuxkit containerd://1.4.0

# Nodeとして動いているコンテナ
$ docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
24117f8d397f kindest/node:v1.19.1 "/usr/local/bin/entr…" 21 minutes ago Up 20 minutes 127.0.0.1:63917->6443/tcp kind-control-plane

ちゃんとPodも動く. すごい.

# Podも作れる
$ kubectl run nginx --image=nginx
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 37s 10.244.0.5 kind-control-plane <none> <none>

# Podの動作確認
$ kubectl run busybox --image=busybox --restart=Never --rm -it -- wget -O- 10.244.0.5:80
Connecting to 10.244.0.5:80 (10.244.0.5:80)
writing to stdout
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
 body {
 width: 35em;
 margin: 0 auto;
 font-family: Tahoma, Verdana, Arial, sans-serif;
 }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
- 100% |********************************| 612 0:00:00 ETA
written to stdout
pod "busybox" deleted

Ingressの設定

簡単なPodやJobの動作確認だけならこれでも良いんだけど,
クラスタ外からの動作確認がしたい場合は追加でIngressの設定が必要なので試してみる.

まずは新たなクラスタを設定ファイル⁵を使って作成する.
extraPortMappingsとnode-labelsが設定されていることが重要らしい.

# kindのクラスタ設定ファイルの作成
$ vim config.yaml

# 新規クラスタ(kind-ingress-enabled)の起動
$ kind create cluster --name ingress-enabled --config config.yaml
Creating cluster "ingress-enabled" ...
 ✓ Ensuring node image (kindest/node:v1.19.1) 🖼
 ✓ Preparing nodes 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Set kubectl context to "kind-ingress-enabled"
You can now use your cluster with:

kubectl cluster-info --context kind-ingress-enabled

Thanks for using kind! 😊

作ったばかりのクラスタ(kind-ingress-enabled)にIngress Controllerをデプロイする⁶.
今回はNGINX Ingress Controller⁷を使用する.

# NGINX Ingress Controllerのデプロイ
$ kubectl apply --context kind-ingress-enabled -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/kind/deploy.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
configmap/ingress-nginx-controller created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
service/ingress-nginx-controller-admission created
service/ingress-nginx-controller created
deployment.apps/ingress-nginx-controller created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created
serviceaccount/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created

# 起動確認
$ kubectl wait --context kind-ingress-enabled --namespace ingress-nginx \
 --for=condition=ready pod \
 --selector=app.kubernetes.io/component=controller \
 --timeout=90s
pod/ingress-nginx-controller-6df69bd4f7-57bkk condition met

これでこのクラスタでIngressを使う準備ができた.

最後にサンプルアプリ⁸を動かして, Ingressの動作を確認する.

# サンプルアプリ(Pod, Service, Ingress)のデプロイ
$ kubectl apply -f https://kind.sigs.k8s.io/examples/ingress/usage.yaml
pod/foo-app created
service/foo-service created
pod/bar-app created
service/bar-service created
Warning: networking.k8s.io/v1beta1 Ingress is deprecated in v1.19+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
ingress.networking.k8s.io/example-ingress created

# リクエストに対してそれぞれfoo, barを返すPodとそれに対応したService
$ kubectl get all
NAME READY STATUS RESTARTS AGE
pod/bar-app 1/1 Running 0 33s
pod/foo-app 1/1 Running 0 33s

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/bar-service ClusterIP 10.96.251.3 <none> 5678/TCP 33s
service/foo-service ClusterIP 10.96.170.161 <none> 5678/TCP 33s
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 16m

# /foo, /barへのトラフィックをそれぞれのServiceに振り分けるIngress
$ kubectl get ingress
Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
example-ingress <none> * localhost 80 16m
$ kubectl describe ingress example-ingress
Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
Name: example-ingress
Namespace: default
Address: localhost
Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
 Host Path Backends
 ---- ---- --------
 *
 /foo foo-service:5678 10.244.0.10:5678)
 /bar bar-service:5678 10.244.0.9:5678)
Annotations: <none>
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal Sync 17m (x2 over 17m) nginx-ingress-controller Scheduled for sync

# クラスタ外から叩いて動作確認
$ curl localhost/foo
foo
$ curl localhost/bar
bar

やったぜ.

kindで立てたクラスタでもIngressを使ってクラスタ外からアクセスすることができた.

クラスタの削除

最後にクラスタをお掃除する.

これもコマンド1発なのでめちゃくちゃ簡単.

# 削除前の状態
$ kind get clusters
ingress-enabled
kind

# Node用のコンテナが2クラスタぶん存在する
$ docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d5c5aa156df9 kindest/node:v1.19.1 "/usr/local/bin/entr…" 23 hours ago Up 23 hours 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 127.0.0.1:57487->6443/tcp ingress-enabled-control-plane
24117f8d397f kindest/node:v1.19.1 "/usr/local/bin/entr…" 24 hours ago Up 24 hours 127.0.0.1:63917->6443/tcp kind-control-plane

# クラスタの削除
$ kind delete cluster --name kind
Deleting cluster "kind" ...

# 一括削除も可能
$ kind delete clusters --all
Deleted clusters: ["ingress-enabled"]

# Nodeのコンテナがすべて消えている
$ docker container ls -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

# kubeconfigの設定も勝手に消えている(残っているのは別途作成したDocker DesktopとMinikubeの設定のみ)
$ kubectl config view
apiVersion: v1
clusters:
- cluster:
 certificate-authority-data: DATA+OMITTED
 server: https://kubernetes.docker.internal:6443
 name: docker-desktop
- cluster:
 certificate-authority: /Users/uzimihsr/.minikube/ca.crt
 server: https://192.168.99.110:8443
 name: minikube
contexts:
- context:
 cluster: docker-desktop
 user: docker-desktop
 name: docker-desktop
- context:
 cluster: minikube
 user: minikube
 name: minikube
current-context: ""
kind: Config
preferences: {}
users:
- name: docker-desktop
 user:
 client-certificate-data: REDACTED
 client-key-data: REDACTED
- name: minikube
 user:
 client-certificate: /Users/uzimihsr/.minikube/client.crt
 client-key: /Users/uzimihsr/.minikube/client.key

…こんなに簡単でいいのか?

おわり

kindを使ったKubernetesクラスタの作成, Ingress Controllerのデプロイ, クラスタの削除を一通り試してみた.

Ingress対応だけちょっと面倒だけどそれもほぼコピペでできるし,
基本はコマンド1行でクラスタが簡単に作れるのがすごい. 便利すぎる.

おまけ

Goで無限ループのテストの書き方がわかんなかった

Sat, 05 Dec 2020 13:40:34 +0900

鬼滅のテスト無限ループ編

わかんなかったので自分なりにやってみたメモ
サブタイトルはおふざけ

まとめ

ループ1回分の処理を抜き出して, それをテストするのが良さそう.
ループ1回分のモックが作れるなら, 無限ループの部分を呼び出して任意の回数でループを止めることもできる.

(無限ループを含むコード例)

(テストコード例)

環境

macOS Mojave 10.14
go version go1.14.6 darwin/amd64

やりかた

Goでこんな感じの無限ループ処理があるときに,
どうやってテストを書いたらいいかわかんなかった.

# 処理としてはhogehoge.txtの内容を1秒ごとに読み込んで出力するだけ
$ echo fugafuga > hogehoge.txt
$ go run main.go
fugafuga

fugafuga

fugafuga

fugafuga

fugafuga

^Csignal: interrupt
# 無限ループなので強制終了する

テキトーに調べたけど¹, 提案されているのは

ループの回数を指定できるような仕組みを仕込んでおいてテストのときだけ回数を有限にする
ループ1回分の処理だけをテストするようにする

のどっちかという感じだった.

自分の場合はDI(Dependency Injection)以外でテストのためだけに変な引数を追加したりしたくないので, ループ1回分だけを取り出してテストするほうが良いかな, と思った.

まずはmain.goを修正して, ループ1回分の処理を別のメソッド(Loop.Run)に分ける.
(実行される処理の内容は変わらない)

次にgomock²でループ1回分のinterface(Loop)のモックを作る.

# go.modの作成($GOPATH配下で作業している場合は不要)
$ go mod init github.com/uzimihsr/infinite-loop-test
go: creating new go.mod: module github.com/uzimihsr/infinite-loop-test

# mockの生成
$ go get github.com/golang/mock/mockgen@v1.4.4
$ mockgen -source=./main.go -destination=mock_main.go -package=main Loop

mock_main.go(生成されたモック)

(後で気づいたけど, main関数のテストはしないのでちゃんとパッケージを分ければよかった…)

ループ1回分(Loop.Run)のテストと無限ループ(InfiniteLoop.Run)のテストを作成する.

ループ1回分のテストでは実際に1回分の処理だけをテストしている.
(今回はloop.Run()内部で標準パッケージのioutil.ReadFile()を直接呼び出してしまっているけど, 可能であればここも依存している関数やメソッドのモックを使ったほうが良い気がする)

無限ループのテストではmockgenで生成したループ1回分のモックを利用して,
任意の回数を超えた時点でエラーを発生させてループが止まるようにしている.
こうすることで, 結果的には無限ループの回数を指定してテストしているのと同じことができた.

実際にテストを実行してみる.

# 最終的な作業ディレクトリの状態
$ tree .
.
├── go.mod
├── go.sum
├── hogehoge.txt
├── main.go
├── main_test.go
├── mock_main.go
└── test-hogehoge.txt

# テスト実行
$ echo test-fugafuga > test-hogehoge.txt
$ go test -v -cover ./...
=== RUN TestLoop
=== RUN TestLoop/正常にファイルが開けるケースのテスト
test-fugafuga

=== RUN TestLoop/ファイルが開けず異常終了するケースのテスト
--- PASS: TestLoop (0.00s)
 --- PASS: TestLoop/正常にファイルが開けるケースのテスト (0.00s)
 --- PASS: TestLoop/ファイルが開けず異常終了するケースのテスト (0.00s)
=== RUN TestInfiniteLoop
=== RUN TestInfiniteLoop/ループが1回正常に呼び出されることのテスト
=== RUN TestInfiniteLoop/ループが任意の回数(例えば10回)正常に呼び出されることのテスト
--- PASS: TestInfiniteLoop (11.03s)
 --- PASS: TestInfiniteLoop/ループが1回正常に呼び出されることのテスト (1.01s)
 --- PASS: TestInfiniteLoop/ループが任意の回数(例えば10回)正常に呼び出されることのテスト (10.02s)
PASS
coverage: 63.4% of statements
ok 	github.com/uzimihsr/infinite-loop-test	11.034s	coverage: 63.4% of statements

mock_main.goがmainパッケージに入ってたりmain関数のテストができていなかったりで,
カバレッジは100%になっていないけど一応やりたかった内容は実行できた.

テストの目的はカバレッジを100%にすることではないので, これでいいはず…

おわり

無限ループがあるコードを書いた経験があまりなかったので, けっこう詰まってしまった.

自分なりにやってみたけど, 他にもっといい方法があるんだろうか…
もっと厳密にやりたいならosパッケージ³を呼び出してプロセスを扱ったりしてもいいんだろうけど, そこまでする必要があるかは謎🤔
(個人的には"無限に繰り返されること"の確認にそこまでの価値があると思えなかった)

おまけ

11月のそとちゃんまとめ(2020)

Thu, 03 Dec 2020 12:09:40 +0900

もふもふ

ちょっと寒くなってきたけどそとちゃんは相変わらず元気だった.

まとめ

まるい
ハミ毛処理
ソファ

まるい

11月もそとちゃんはころころしていた.

なんだこれ pic.twitter.com/swNMCbukZs
— ずみし (@uzimihsr) November 10, 2020

まるい pic.twitter.com/sVjWH7icHI
— ずみし (@uzimihsr) November 12, 2020

早朝から運動会して, お昼ごろには疲れてまるくなってお昼寝してるのが最近のパターン.

14時くらいにいったん起きてごはんを食べるけど, その後はまたまるくなって夕方くらいまで寝てる.

遊び疲れ果てた pic.twitter.com/bTvAfAoYor
— ずみし (@uzimihsr) November 12, 2020

ねてる pic.twitter.com/QQz5Qbn34Z
— ずみし (@uzimihsr) November 18, 2020

寒いから丸まってるのかと思ってヒーターも買ったけど,
エアコンと違って温風が直接当たるのがそんなに好きじゃないらしい.

ちゃんと離れてるのえらいねえ pic.twitter.com/1M0OmOhNjJ
— ずみし (@uzimihsr) November 17, 2020

横から見るとおまんじゅうみたいでかわいい.

これなに？ pic.twitter.com/V6J0WGABj8
— ずみし (@uzimihsr) November 20, 2020

ハミ毛処理

ときどきフローリングですべってるから怪しいとは思ってたけど, 足のハミ毛が立派に伸びていた.

毛深いもみじ pic.twitter.com/egVKmWiyex
— ずみし (@uzimihsr) November 26, 2020

特に後ろ足のハミ毛が肉球を隠すくらい伸びていて, ちょっと危ないのでハミ毛の処理をしてみた.

ハサミでやるのはちょっと怖かったのでバリカンを購入.

ホームバーバー　エキスパートスタイル　コンパクト

初めて知ったんだけど猫専用バリカンというものはなくて, だいたい小型犬とかと兼用のものが使えるらしい.

バリカンに挑戦 pic.twitter.com/oDPNO2Pg2c
— ずみし (@uzimihsr) November 29, 2020

途中の写真は撮れてないけど, そとちゃんは今回も協力的でおとなしく剃らせてくれた.

うちのねこはほんとにいい子で助かる.
(バリカンの音が思ったよりうるさくなかったのが良かったかもしれない…)

ハミ毛処理後の足はこんな感じ.

とりあえず肉球がちゃんと見えるくらいまでハミ毛を剃れた pic.twitter.com/42ufY9RTdh
— ずみし (@uzimihsr) November 29, 2020

きれいなピンクの肉球がよく見えるようになってかわいい.

ねてる pic.twitter.com/41aBsgwCWP
— ずみし (@uzimihsr) November 30, 2020

ソファ

😭😭😭

もうだめだ😭😭😭

先月に引き続きソファバリバリするたびに叱ってたんだけど, どうやら

バリバリする → しもべが寄ってくる = かまってもらえる!

と学習してしまったようで😭

最近は朝俺が起きたときや夕方の仕事が終わりかけてるときだったり,
かまってもらえるタイミングを見計らってわざとバリバリしてるようにも見える…

自分が怒られてるとは微塵にも思ってないらしく, 現行犯で叱っても「なんか用？」みたいな顔をする.

どうすりゃいいんだ…😭

おわり

11月もそとちゃんは良い子だった.
これからさらに寒くなるけどヒーターはあまり気に入ってもらえなかったので, 他の寒さ対策も考えたい.

ソファはもうダメかも…😭

おまけ

Dockerとdocker-composeでMySQLを動かした

Fri, 27 Nov 2020 12:10:37 +0900

環境構築が面倒

DBを使ったアプリケーションを開発するときに毎回MySQLやテーブルを準備するのが嫌だったので,
コンテナを使ってMySQLが動作する環境を簡単に作成できるようにした.

やったことのまとめ

MySQLのコンテナをDockerで起動した
docker-composeを使ってコンテナの起動時に初期設定用SQLが自動で実行されるようにした

docker-compose.yml

# コンテナを直接起動する例
$ docker container run -d -p 3306:3306 --name mysql-container -e MYSQL_ROOT_PASSWORD=<rootユーザのパスワードに設定したい文字列> mysql:5.7.32

# docker-composeで起動する例
# 上記docker-compose.ymlの他にpassword-root(rootパスワードを記述したファイル), member.sql初期設定用SQLファイルを用意して実行する
$ docker-compose up -d

# ホストOSからDBを操作するにはコンテナに入るか, 別のコンテナを建てるか, ホストOSのクライアントを使う
$ docker container exec -it mysql-container mysql -u root -p
$ docker container run --rm -it mysql:5.7.32 mysql -h host.docker.internal -P 3306 -u root -p
$ mysql -h 127.0.0.1 -P 3306 -u root -p

つかうもの

macOS Mojave 10.14
Docker Desktop for Mac
- Version 2.5.0.0
- Kubernetes: v1.19.3
- Docker version 19.03.13
- docker-compose version 1.27.4
MySQL (Docker image)
- Server version: 5.7.32

やったこと

Dockerで起動する
docker-composeで起動する

Dockerで起動する

MySQLの公式Docker image¹が用意されているので, これを使う.

# localhostからアクセスできるよう3306ポートを割り当てて起動
# 環境変数(MYSQL_ROOT_PASSWORD)でrootユーザのパスワード(hogehoge)を設定する
$ docker container run -d -p 3306:3306 --name mysql-container -e MYSQL_ROOT_PASSWORD=hogehoge mysql:5.7.32

# コンテナに入ってMySQLクライアントを起動
$ docker container exec -it mysql-container mysql -u root -p
Enter password: # hogehoge
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.32 MySQL Community Server (GPL)

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
+--------------------+
4 rows in set (0.01 sec)

mysql> exit
Bye

# ホストOSのMySQLクライアントからも接続できる
$ mysql -h 127.0.0.1 -P 3306 -u root -p
Enter password: # hogehoge
...
mysql> exit
Bye

# 使い捨てのコンテナからホストOSのlocalhost:3306で起動しているMySQLのコンテナに接続
$ docker container run --rm -it mysql:5.7.32 mysql -h host.docker.internal -P 3306 -u root -p
Enter password: # hogehoge
...
mysql> exit
Bye

# クライアント用のコンテナを使用するパターン
# 事前にdocker network(bridge)内のmysql-containerのIPを確認する
$ docker container inspect mysql-container -f "{{.NetworkSettings.IPAddress}}"
172.17.0.2
$ docker container run --rm -it mysql:5.7.32 mysql -h 172.17.0.2 -P 3306 -u root -p
Enter password: # hogehoge
...
mysql> exit
Bye

# コンテナを削除
$ docker container rm -f mysql-container

流石にDockerなら簡単に動かせた.

docker-composeで起動する

もうちょっと複雑なことがしたいので, docker-composeで起動してみる.

# パスワードファイルの作成
$ vim password-root # パスワード文字列(hogehoge)を入力する
$ cat password-root
hogehoge

# パスワードファイル(password-root), 初期設定用SQLファイル(member.sql), docker-compose.ymlが存在する状態
$ ls
docker-compose.yml member.sql password-root

# コンテナの起動
$ docker-compose up -d
Starting mysql-container ... done

# データベースの確認
# mysql -h 127.0.0.1 -P 3306 -u root -p でも同じことができる(ホストOSのMySQLクライアントを使う場合)
$ docker-compose exec mysql mysql -u root -p
Enter password: # hogehoge
...
mysql> use mydb
Database changed

mysql> SELECT * FROM members;
+----+----------+------+---------+------+
| id | name | team | role | age |
+----+----------+------+---------+------+
| 1 | Alice | A | manager | 30 |
| 2 | Ben | B | manager | 50 |
| 3 | Charlie | A | member | 40 |
| 4 | Daniel | A | member | 30 |
| 5 | Emily | A | member | 20 |
| 6 | Florence | A | member | 30 |
| 7 | George | A | trainee | 20 |
| 8 | Harry | B | member | 40 |
| 9 | Isabel | B | member | 40 |
| 10 | Jack | B | trainee | 20 |
| 11 | Katie | B | trainee | 20 |
+----+----------+------+---------+------+
11 rows in set (0.00 sec)
# 初期設定用SQLが実行されているので最初からデータベースとテーブルが作成されている

ポイントは2つ.

1つめはrootユーザのパスワードをファイルから読み込む形にしていること.

先程使用した環境変数のMYSQL_ROOT_PASSWORDではなくMYSQL_ROOT_PASSWORD_FILEでファイルのパスを指定すればその中身をパスワードとして設定できるので,
パスワード文字列(hogehoge)が記述されたファイル(password-root)をホストOSからコンテナにマウントしてそのパスをMYSQL_ROOT_PASSWORD_FILEで指定するようにしている.

こうするとdocker-compose.ymlからパスワードの情報を分離できて,
そのままリポジトリとかで共有できるようになる.

2つめはデータベースの初期設定用のSQLがコンテナの起動時に勝手に実行されるようにしていること.

コンテナのディレクトリ/docker-entrypoint-initdb.dの配下にある拡張子が.sh, .sql, .sql.gzのスクリプトは勝手に実行されるので,
ここに実行したいSQLファイル(member.sql)をマウントしている.

こうするとわざわざ起動後のコンテナに入って初期設定用のSQLを実行する必要がなくなり,
docker-composeを立ち上げるだけで使いたいデータベースとテーブルが準備できるので便利.

おわり

Dockerとdocker-composeを使ってMySQLを起動する手順を試してみた.

特にdocker-composeを使う方法だと設定ファイルさえ用意すればコマンド1つでレコード入りのテーブルが簡単に用意できるのでめっちゃ便利だと思う.

おまけ

https://hub.docker.com/_/mysql ↩︎

kube-apiserverのversionをcurlで確認する

Thu, 12 Nov 2020 20:20:40 +0900

それもそう

これも大した話ではないんだけど勉強になったのでメモ.

まとめ

Kubernetes APIの/versionをたたけばversion情報を取得できる.

# kube-apiserverのversion情報を取得
$ curl -s --insecure https://<Kubernetes API>/version | jq '.gitVersion'

# jqが使えない場合でも生のjsonのgitVersionから読み取れる
$ curl --insecure https://<Kubernetes API>/version

環境

macOS Mojave 10.14
Docker Desktop for Mac
- Version 2.5.0.0
- Kubernetes: v1.19.3
jq-1.6

やりかた

KubernetesクラスタのAPIのバージョンを調べたいとき, kubectlが使えるならkubectl versionで確認できる.

# Docker DesktopのKubernetesクラスタを使用
$ kubectl cluster-info
Kubernetes master is running at https://kubernetes.docker.internal:6443
KubeDNS is running at https://kubernetes.docker.internal:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

# Kubernetesのversionを確認
$ kubectl version --short
Client Version: v1.19.3 # クライアント(kubectl)のversion
Server Version: v1.19.3 # サーバー(kube-apiserver)のversion

これをkubectlが使えない環境で確認する方法がわかんなかった.
とはいえkubectlも中身はwebクライアントなので, API側にHTTPリクエストを飛ばして結果を表示しているはず。

ということでkubectlのコードを読んでみた.
kubectl versionを実行したときの処理はたぶんここ¹.
呼び出されているdiscoveryClient.ServerVersion()の処理はおそらくここ².
APIエンドポイントの/versionにGETを飛ばしてるだけっぽい.

というわけでcurlでやってみる.
今回使うKubernetesクラスタはDocker Desktopで立てたものなのでクライアント認証をしているが,
他の認証方法を使っているクラスタの場合でもエンドポイント等は同じはず.

$ curl --insecure --cert ./client.crt --key ./client.key https://kubernetes.docker.internal:6443/version
{
 "major": "1",
 "minor": "19",
 "gitVersion": "v1.19.3",
 "gitCommit": "1e11e4a2108024935ecfcb2912226cedeafd99df",
 "gitTreeState": "clean",
 "buildDate": "2020-10-14T12:41:49Z",
 "goVersion": "go1.15.2",
 "compiler": "gc",
 "platform": "linux/amd64"
}

取れた.
せっかくなのでjqで欲しい文字列を抜いてみる.

$ curl -s --insecure --cert ./client.crt --key ./client.key https://kubernetes.docker.internal:6443/version | jq '.gitVersion'
"v1.19.3"

やったぜ.
kubectlを使わずにcurlでkube-apiserverのバージョン情報を取得することができた.

ちなみにコードを探さなくても, /をたたけば使えるエンドポイントの一覧が取得できた.

$ curl --insecure --cert ./client.crt --key ./client.key https://kubernetes.docker.internal:6443/
{
 "paths": [
 "/api",
 "/api/v1",
 "/apis",
 "/apis/",
 ...,
 "/version"
 ]
}

まあ今回は解決したのでヨシ!

おわり

kubectlを使わずにcurlで直接Kubernetes APIをたたいてバージョン情報を確認する方法がわかった.
Kubernetes APIを呼び出して何かする処理を自分で0から実装しようとすると結構たいへんなので, kubectlのコードを読んで参考にするのが良さそう.
やっぱりちゃんとコードを読むのは大事だと思った.
というかkubectlが便利すぎる. 偉大.

おまけ

kubeconfigにベタ書きされたclient-certificate-dataをファイル化して使う

Tue, 10 Nov 2020 21:43:47 +0900

それはそう

冷静に考えれば大したことないんだけどちょっと詰まったので一応メモ.

まとめ

kubeconfigにベタ書きされているclient-certificate-data(クライアント証明書)とclient-key-data(秘密鍵)はbase64デコードするとファイルとして普通に使える.

# kubeconfigにベタ書きされたクライアント証明書(client.crt)と秘密鍵(client.key)をファイルに出力する
$ kubectl config view --minify --raw -o jsonpath='{.users[].user.client-certificate-data}' | base64 --decode > client.crt
$ kubectl config view --minify --raw -o jsonpath='{.users[].user.client-key-data}' | base64 --decode > client.key

# kubectlじゃなくてもOK
## awkでやるパターン
$ cat ~/.kube/config | grep client-certificate-data | awk '{print $2}' | base64 --decode > client.crt
$ cat ~/.kube/config | grep client-key-data | awk '{print $2}' | base64 --decode > client.key
## yqつかうパターン
$ cat ~/.kube/config | yq r - "users[*].user.client-certificate-data" | base64 --decode > client.crt
$ cat ~/.kube/config | yq r - "users[*].user.client-key-data" | base64 --decode > client.key

# クライアント証明書(client.crt)と秘密鍵(client.key)を使ってcurlでKubernetes APIにアクセス
$ curl --insecure --cert ./client.crt --key ./client.key https://<Kubernetes API>

環境

macOS Mojave 10.14
Docker Desktop for Mac
- Version 2.5.0.0
- Kubernetes: v1.19.3
yq version 3.3.2

やりかた

Docker Desktopで作ったKubernetesクラスタへのクライアント認証の情報は~/.kube/config(kubeconfig)に自動でベタ書きされている.

# client-certificate-data : クライアント証明書
# client-key-data : クライアントの秘密鍵
$ kubectl config view --minify --raw
apiVersion: v1
clusters:
- cluster:
 certificate-authority-data: LS0t...Cg==
 server: https://kubernetes.docker.internal:6443
 name: docker-desktop
contexts:
- context:
 cluster: docker-desktop
 user: docker-desktop
 name: docker-desktop
current-context: docker-desktop
kind: Config
preferences: {}
users:
- name: docker-desktop
 user:
 client-certificate-data: LS0t...LS0K
 client-key-data: LS0t...Cg==

このクラスタのAPIへcurlで接続しようとすると, クライアント認証で弾かれてしまう.

# k8s API側がオレオレ証明書なので --insecure が必要
$ curl --insecure https://kubernetes.docker.internal:6443
{
 "kind": "Status",
 "apiVersion": "v1",
 "metadata": {

 },
 "status": "Failure",
 "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
 "reason": "Forbidden",
 "details": {

 },
 "code": 403
}

おとなしくkubectlを使えばいいんだけど, 理由はさておきどうしてもcurlで接続したいことがあった.
curlでクライアント認証を突破するには--cert(クライアント証明書)と--key(クライアント秘密鍵)が必要なので,
kubeconfigにベタ書きされている値をbase64でデコードする.

# クライアント証明書をbase64デコード
$ kubectl config view --minify --raw -o jsonpath='{.users[].user.client-certificate-data}' | base64 -D
-----BEGIN CERTIFICATE-----
MIIDFTCCAf2gAwIBAgIICzCv4rM20vUwDQYJKoZIhvcNAQELBQAwFTETMBEGA1UE
...
QCUVil5khgn66X0Pd2GAs37k66Yyx7urGw==
-----END CERTIFICATE-----

# クライアントの秘密鍵をbase64デコード
$ kubectl config view --minify --raw -o jsonpath='{.users[].user.client-key-data}' | base64 -D
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAx6UtMTtlcvZWKPiQcDSlP7Ic2b2QOpigVifG6HOU5OtBc+Fn
...
PEUMoWLF7jKfAGRtKrnY9DTE4HeDoohXlDG47KC+TLrm1bSwxMIn
-----END RSA PRIVATE KEY-----

よくみるPEM形式の証明書と秘密鍵が確認できる.
あとはこれをファイルに出力するだけ.

# クライアント証明書(client.crt)と秘密鍵(client.key)をファイルに出力する
$ kubectl config view --minify --raw -o jsonpath='{.users[].user.client-certificate-data}' | base64 -D -o client.crt
$ kubectl config view --minify --raw -o jsonpath='{.users[].user.client-key-data}' | base64 -D -o client.key

作成したクライアント証明書と秘密鍵のファイルを使って再度KubernetesクラスタのAPIを叩いてみる.

# クライアント証明書(client.crt)と秘密鍵(client.key)を使って認証を突破
$ curl --insecure --cert ./client.crt --key ./client.key https://kubernetes.docker.internal:6443
{
 "paths": [
 "/api",
 "/api/v1",
 ...,
 "/version"
 ]
}

クライアント認証を突破できた.
やったぜ.

今回はクライアント証明書と秘密鍵をkubeconfigから取り出すのにkubectlを使ったけど,
yaml形式のファイルから任意の値を取り出せるならもちろん他の方法でもできる.
kubectlが使えなくてkubeconfigしかないような場合はこっちの方法を使うことが多そう.

# grepとawkでやる例
$ cat ~/.kube/config | grep client-certificate-data | awk '{print $2}' | base64 -D
$ cat ~/.kube/config | grep client-key-data | awk '{print $2}' | base64 -D
# yqでやる例
$ cat ~/.kube/config | yq r - "users[*].user.client-certificate-data" | base64 -D
$ cat ~/.kube/config | yq r - "users[*].user.client-key-data" | base64 -D
# いずれも出力はkubectl config viewから取り出したときと同じ

おわり

kubectlは使えないけどkubeconfigは存在する, みたいな環境でどうしてもKubernetesクラスタのAPIをたたく必要があったので一応やってみた.
kubectlが使える環境だけどcurlでのアクセスを試したい, というような場合は事前にServiceAccountを作ってBearer Tokenを発行したほうがたぶんはやい¹.

おまけ

Kubernetes Docs ↩︎

10月のそとちゃんまとめ(2020)

Tue, 03 Nov 2020 13:55:49 +0900

ドラキュラねこ

10月のそとちゃんは新居にも慣れて元気いっぱいだった.

まとめ

ソファだいすき
ハロウィン

ソファだいすき

引っ越しに合わせて買ったソファがだいぶ気に入ったらしく, 最近はずっとごろごろしている.

しろくてかわいいね pic.twitter.com/Q4Kz1wf518
— ずみし (@uzimihsr) October 1, 2020

ソファを占拠 pic.twitter.com/zSil5iCdUf
— ずみし (@uzimihsr) October 7, 2020

気に入ってくれたのは良かったんだけど,
ちょっと座ろうと思ってもど真ん中で寝てたりするのでたまに座れなくて困る.
どうして人間2人がけのソファをねこ1匹で占領するのか…🤔

また, 最近寒くなってきたおかげで俺がソファに座ってるとひざの上に乗ってくれる. うれしい.

家の暖房を点けるかどうかで家族会議中
(議長:ねこ) pic.twitter.com/dOv8elCMme
— ずみし (@uzimihsr) October 15, 2020

仕事させる気0 pic.twitter.com/2rthPAJQLj
— ずみし (@uzimihsr) October 22, 2020

そとちゃんに乗られると柔らかいし暖かいしとても幸せ(何もできなくなるけど).

流石に仕事中は困るので降りていただくことになるが, その後のプレッシャーがすごい…😭

ひざから降ろされたときの顔 pic.twitter.com/KETV5dBnve
— ずみし (@uzimihsr) October 22, 2020

そして危惧していた事態が現実に…

なんとそとちゃんがソファで爪とぎするようになってしまった.

買ってから最初の数週間は爪を立てるそぶりも無かったのに,
どのタイミングで気づいたのかはわからないけど爪が布にひっかかっておもしろくなっちゃったらしい…

我が家の教育方針はのびのび教育, 自由に育てるがモットーなのであまり叱らないようにしているんだけど,
ボロボロにされて中身が出ちゃったりすると誤飲とかが怖いので今回ばかりはちょっと怒った.

そしてこの顔である.

ソファバリバリにしたからめっちゃおこられた pic.twitter.com/HYGaXuNwVC
— ずみし (@uzimihsr) October 28, 2020

ねこには日本語が通じないので, 全く効果なし…

ソファをバリバリしてる場面を見つけ次第やめさせてるんだけど,
そとちゃんは賢いので俺が寝てる間に思う存分バリバリしているっぽい.

ソファのすぐ横にお気に入りのつめとぎもあるんですけどね…😭

ハロウィン

今年のハロウィンもそとちゃんにドラキュラになってもらった.

ドラキュラそとちゃん pic.twitter.com/WnBGWyKpSZ
— ずみし (@uzimihsr) October 31, 2020

着せてるのは去年と同じ100均のペット用マントだけど,
これくらい作りがシンプル(首とお腹に巻くだけ)だとつけててもそこまで嫌じゃないらしく着せてる間も協力的だった.

宇宙一かわいいねえ
おやついくらでもあげちゃう pic.twitter.com/5Osrj2dvYT
— ずみし (@uzimihsr) October 31, 2020

マントが似合っててめっちゃかわいい.
なんかキメ顔してるように見えるのも最高.

ソファバリバリやねずみドリブルでお忙しい中俺のわがままに付き合ってもらったので,
お礼に一番お気に入りのおやつをプレゼントした.

1人じゃハロウィンなんて絶対スルーしてるけど, そとちゃんと一緒だと祝おうという気持ちになるのがふしぎ.
いつまで祝えるかはわからないけど, できるだけ長く毎年祝えるようにしたい.

おわり

10月のそとちゃんはちょっとわるいこと(ソファバリバリ)に目覚めてしまったけど, 基本は良い子にしてたし元気いっぱいだった.

ソファバリバリの件はこのまま放っておくとソファが破壊されてしまうので, どうにかしつけの方法を考えたい…

おまけ

Github Actionsを使ってDocker ImageをGitHub Container RegistryにPushする

Sun, 11 Oct 2020 23:01:22 +0900

CI/CDっぽいことがしたい

GitHub公式のCI/CDサービスGitHub Actionsを使って, リポジトリ上のDockerfileからimageをbuildしてpushする手順を試した.

まとめ

GitHubのPAT(個人アクセストークン)をリポジトリのSecretsにCR_PATとして登録した状態で以下のような.github/workflows/docker-publish.ymlを作成すると,
masterブランチへのcommitやrelease(tag)の作成時にDocker imageをGitHub ActionでGitHub Container Registryにpushすることができる.
pushしたimage : https://github.com/users/uzimihsr/packages/container/package/echo

# ghcr.io/<GitHubアカウント>/<image名>:<タグ>のimageをGitHub Packagesにpushするworkflow
name: Docker

on:
 # masterブランチまたはvから始まるtag(例:`v1.2.3`)のpushでjobsを実行する
 push:
 branches:
 - master
 tags:
 - v*
 # 全ブランチのPRに対してもjobsを実行
 pull_request:
env:
 # <image名>を指定
 IMAGE_NAME: echo
jobs:
 # テスト用のjob
 test:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v2
 - name: Run tests
 run: |
 if [ -f docker-compose.test.yml ]; then
 docker-compose --file docker-compose.test.yml build
 docker-compose --file docker-compose.test.yml run sut
 else
 docker build . --file Dockerfile
 fi
 # imageをpushする
 push:
 # test jobが成功した場合のみトリガーされる
 needs: test
 runs-on: ubuntu-latest
 # pushイベント以外(PRなど)では実行されない
 if: github.event_name == 'push'
 steps:
 - uses: actions/checkout@v2
 - name: Build image
 run: docker build . --file Dockerfile --tag $IMAGE_NAME
 - name: Log into GitHub Container Registry
 # `read:packages`と`write:packages`の権限を持つPAT(個人アクセストークン)をSecretに`CR_PAT`として登録しておく
 # PATの作成手順 : https://docs.github.com/ja/free-pro-team@latest/github/authenticating-to-github/creating-a-personal-access-token
 run: echo "${{ secrets.CR_PAT }}" | docker login https://ghcr.io -u ${{ github.actor }} --password-stdin
 - name: Push image to GitHub Container Registry
 run: |
 # <GitHubアカウント>が自動で選択される
 IMAGE_ID=ghcr.io/${{ github.repository_owner }}/$IMAGE_NAME
 IMAGE_ID=$(echo $IMAGE_ID | tr '[A-Z]' '[a-z]')
 VERSION=$(echo "${{ github.ref }}" | sed -e 's,.*/\(.*\),\1,')
 # git tagの値を<タグ>として付与
 [[ "${{ github.ref }}" == "refs/tags/"* ]] && VERSION=$(echo $VERSION | sed -e 's/^v//')
 # masterブランチへのcommitでトリガーされている場合はlatestを<タグ>として使う
 [ "$VERSION" == "master" ] && VERSION=latest
 echo IMAGE_ID=$IMAGE_ID
 echo VERSION=$VERSION
 docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
 docker push $IMAGE_ID:$VERSION

https://github.com/uzimihsr/echo-image/blob/master/.github/workflows/docker-publish.yml

環境

macOS Mojave 10.14
GitHub
GitHub Packages
Git
- git version 2.20.1 (Apple Git-117)
Docker Desktop for Mac
- Version 2.1.0.3
- Docker Engine 19.03.13

やりかた

PATの発行とログイン
手動でpush
GitHub Actionsでpush

PATの発行とログイン

まずは公式ドキュメント¹を参考に, GitHub Container Registryの認証に必要なPAT(個人アクセストークン)を発行する.

GitHubにログインした状態で
https://github.com/settings/tokens
を開き, Generate new tokenをクリック.

PATの権限設定画面ではwrite:packages, read:packagesにのみチェックを入れてGenetate tokenをクリック.

PATが発行される.

発行されたPATを使って, コマンドラインからGitHub Container Registryにログインする.

# GitHub Container Registryにログイン
$ echo <PAT> | docker login ghcr.io -u <GitHubアカウント> --password-stdin
Login Succeeded

これでログインは成功.

手動でpush

上記の手順でGitHub Container Registryにログインした状態で, まずはコマンドラインからimageをpushしてみる.

適当なimageを作成.

# 適当なディレクトリで適当なDockerfileを作成
$ cd /path/to/workspace
$ touch Dockerfile

# Docker imageをビルド, 動作確認
$ docker image build -t echo:latest .
$ docker container run --rm echo:latest
hello, world!

次にこのimageにGitHub Container Registry用のタグをつけ, pushする.

# imageのタグをつけ直す
$ docker image tag echo:latest ghcr.io/uzimihsr/echo:latest

# Docker imageをpush
$ docker image push ghcr.io/uzimihsr/echo:latest
The push refers to repository [ghcr.io/uzimihsr/echo]
be8b8b42328a: Pushed
latest: digest: sha256:c7926eae1c1aef6291e5eef1673c9815b5644fa9c417bfab65a4baba50c046a2 size: 527

pushしたimageの情報はGitHub PackagesのUIから確認できる.
https://github.com/users/uzimihsr/packages/container/package/echo

もちろんこのimageをpullして使うこともできる.

# ローカルのimageを削除
$ docker image rm ghcr.io/uzimihsr/echo:latest

# imageをpull
$ docker image pull ghcr.io/uzimihsr/echo:latest
latest: Pulling from uzimihsr/echo
Digest: sha256:c7926eae1c1aef6291e5eef1673c9815b5644fa9c417bfab65a4baba50c046a2
Status: Downloaded newer image for ghcr.io/uzimihsr/echo:latest
ghcr.io/uzimihsr/echo:latest

# 動作確認
$ docker container run --rm ghcr.io/uzimihsr/echo:latest
hello, world!

これでGitHub Container Registryを使ったimageのpush/pullができるようになった.

GitHub Actionsでpush

次にGitHub Actionsを使ってimageをGitHub Container Registryにpushしてみる.

新たにGitHubリポジトリを作成し, 先程作成したDockerfileをgit pushする.
作ったリポジトリ : https://github.com/uzimihsr/echo-image

# Dockerfileが存在する状態
$ ls
Dockerfile

# git initからpushまで
$ git init
$ git remote add origin https://github.com/uzimihsr/echo-image.git
$ git add .
$ git commit -m "initial commit"
$ git push origin master

リポジトリのActionsタブを開き, Publish Docker ContainerアクションのSet up this workflowをクリック.

workflowの定義ファイルdocker-publish.ymlを編集する画面が開く.
このままでも動くけど, 自分用にenv.IMAGE_NAMEだけ任意のimage名に修正する.

docker-publish.yml

# ghcr.io/<GitHubアカウント>/<image名>:<タグ>のimageをGitHub Packagesにpushするworkflow
name: Docker

on:
 # masterブランチまたはvから始まるtag(例:`v1.2.3`)のpushでjobsを実行する
 push:
 branches:
 - master
 tags:
 - v*
 # 全ブランチのPRに対してもjobsを実行
 pull_request:
env:
 # <image名>を指定
 IMAGE_NAME: echo
jobs:
 # テスト用のjob
 test:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v2
 - name: Run tests
 run: |
 if [ -f docker-compose.test.yml ]; then
 docker-compose --file docker-compose.test.yml build
 docker-compose --file docker-compose.test.yml run sut
 else
 docker build . --file Dockerfile
 fi
 # imageをpushする
 push:
 # test jobが成功した場合のみトリガーされる
 needs: test
 runs-on: ubuntu-latest
 # pushイベント以外(PRなど)では実行されない
 if: github.event_name == 'push'
 steps:
 - uses: actions/checkout@v2
 - name: Build image
 run: docker build . --file Dockerfile --tag $IMAGE_NAME
 - name: Log into GitHub Container Registry
 # `read:packages`と`write:packages`の権限を持つPAT(個人アクセストークン)をSecretに`CR_PAT`として登録しておく
 # PATの作成手順 : https://docs.github.com/ja/free-pro-team@latest/github/authenticating-to-github/creating-a-personal-access-token
 run: echo "${{ secrets.CR_PAT }}" | docker login https://ghcr.io -u ${{ github.actor }} --password-stdin
 - name: Push image to GitHub Container Registry
 run: |
 # <GitHubアカウント>が自動で選択される
 IMAGE_ID=ghcr.io/${{ github.repository_owner }}/$IMAGE_NAME
 IMAGE_ID=$(echo $IMAGE_ID | tr '[A-Z]' '[a-z]')
 VERSION=$(echo "${{ github.ref }}" | sed -e 's,.*/\(.*\),\1,')
 # git tagの値を<タグ>として付与
 [[ "${{ github.ref }}" == "refs/tags/"* ]] && VERSION=$(echo $VERSION | sed -e 's/^v//')
 # masterブランチへのcommitでトリガーされている場合はlatestを<タグ>として使う
 [ "$VERSION" == "master" ] && VERSION=latest
 echo IMAGE_ID=$IMAGE_ID
 echo VERSION=$VERSION
 docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
 docker push $IMAGE_ID:$VERSION

https://github.com/uzimihsr/echo-image/blob/master/.github/workflows/docker-publish.yml

docker-publish.ymlの編集が終わったら, Start commit -> Commit new fileと進みworkflowを作成する.

次にこのworkflowでGitHub Container Registryの認証を行うためのSecretsの設定をする.

リポジトリのSettingsタブを開き, New sectetをクリック.

Secretの作成画面ではNameをCR_PAT(docker-publish.yml内で参照している名前)に設定し, Valueには先程作成したPATを貼り付けてAdd secretをクリック.

Secretが作成された.

Secretを作成した状態でリポジトリのActionsタブを開くと,
先程のdocker-publish.yml作成時のcommitで起動したworkflowが失敗している.
(CR_PAT のSecretを作る前に実行されたため, 認証部分でコケている)
Re-run all jobsから再度workflowを実行してみる.

今度はCR_PATが作成済みなのでworkflowが正常に終了し, imageがghcr.io/uzimihsr/echo:latestにpushされた.

再度GitHub Packageの画面
https://github.com/users/uzimihsr/packages/container/package/echo
を開くと, 確かにLast publishedが更新されている.

以上でGitHub Actionsを使ってimageをGitHub Container Registryにpushする設定ができたので, 試しにimageを更新してみる.

# masterからhogeブランチを切る
$ git checkout master
$ git pull origin master
$ git checkout -b hoge

# Dockerfileを修正
$ vim Dockerfile
$ cat Dockerfile
FROM busybox

ENTRYPOINT [ "echo" ]

CMD [ "good morning!" ] # CMDを変更した

# commitしてhogeブランチをpush
$ git add ./Dockerfile
$ git commit -m "fixed Dockerfile: CMD"
$ git push origin hoge

Dockerfileの修正commitを積んだhogeブランチがpushされた状態でPR(master <- hoge)を作成すると, PRにトリガーされたworkflowが実行される.
testのjobのみが実行されpushのjobがスキップされているが, これは今回作成したdocker-publish.ymlでGitHub eventがpushの場合にのみ実行するよう設定しているため.

if: github.event_name == 'push'

このPRをmergeすると今度はmasterブランチへのpushが行われるので, それにトリガーされたworkflowでtestとpushのjobが実行される.
以降のimageがpushされるまでの流れは先程試した流れと同じで, latestタグのimageがpushされる.

latestタグだけではimageのバージョン管理が不便なので,
最新版のimageにバージョンタグを付与してみる.
やり方としては最新のcommitにgit tagをつけてpushするだけ.

# masterブランチで作業
$ git checkout master
$ git pull origin master

# masterブランチの最新のcommitにvから始まるtagをつけてpushする
$ git tag -a v0.0.1 -m "hogehoge"
$ git push origin v0.0.1

するとtagのpushにトリガーされてworkflowが実行される.
今度はtagで指定したvからはじまる文字列がimageのタグとして付与されていることがわかる.

再度Packagesの画面を開くと確かにgit tagで指定した0.0.1のimageがpushされている.

今回はコマンドラインでtagをつけたけど, UIからreleaseを作っても同様にimageのpushができる.

最後にimageの動作確認を行う.

# 動作確認
$ docker container run --rm ghcr.io/uzimihsr/echo:0.0.1
good morning! # CMDの変更が反映されている

やったぜ.
GitHub Actionsを使ってGitHub Container Registryにimageをタグ付けしてpushできるようになった.

おわり

GitHubリポジトリ上のDockerfileからimageを作れるようになった.
GitHub Actionsを使うのも初めてだったので, 練習にもなってよかった.
Docker Hubが無料プランだといろいろ制限が厳しくなってきてるので², (今のところは無料の)GitHub Container Registryに乗り換えていこうと思う.

おまけ

9月のそとちゃんまとめ(2020)

Wed, 07 Oct 2020 22:26:28 +0900

新居

9月のそとちゃんは環境が変わって大変だった.

まとめ

おひっこし
ねずみのおもちゃ

おひっこし

いろいろ事情があって, 9月に引っ越しをした.

そとちゃんはうちに来る前は保護主さんのところで暮らしていたので, たぶん人間と一緒に引っ越すのは初めて.

俺はもちろんねこと引っ越すのが初めてなので, いろいろ大変だった.

まずは普段家に無いサイズのダンボールにそとちゃん大興奮.
引っ越し用のダンボールを組み立てるたびに中に入って出てこないので, 荷物を詰めるのにめっちゃ時間がかかった…

勝手にダンボール入って出られなくなってる pic.twitter.com/TEUyKIQqOW
— ずみし (@uzimihsr) September 1, 2020

荷物詰めが終わったら終わったで, 積み上げたダンボールで大はしゃぎ.
やっぱり猫はダンボール好きなんすね…

ダンボールの王 pic.twitter.com/3hMV5pcpIs
— ずみし (@uzimihsr) September 6, 2020

今回頼んだ引っ越し業者は猫は一緒に運べなかったので, そとちゃんは荷物と別に車で移動.

忙しすぎて写真を撮り忘れちゃったけど, 移動中はキャリーケースの中で不安そうに鳴いててちょっとかわいそうだった.😭

でも新居は1日くらい探検したらすぐに慣れてくれて, すぐにそとちゃんの家になったみたい.
特に新しく買ったソファと仕事用の机がお気に入り.

ゲーミングキャット pic.twitter.com/HMpT2Kwzw0
— ずみし (@uzimihsr) September 26, 2020

仕事監視ねこ pic.twitter.com/Ue1QjyWi8v
— ずみし (@uzimihsr) September 23, 2020

ねずみのおもちゃ

また, だいぶ前に失くしたと思っていたねずみのおもちゃが引っ越しのおかげで見つかった.

お気に入りのねずみのおもちゃがなくていじけてる
(片付けたんじゃなくてそとちゃんが失くした) pic.twitter.com/tt1P6N25zy
— ずみし (@uzimihsr) June 1, 2020

なんと冷蔵庫の裏側, 壁との間に入っていた…
ねこが入れる隙間なんてなかったのに, どうやったのか謎すぎる…🤔

このねずみのおもちゃはまたたびのおまけに付いてきたやつで,
そとちゃんの一番のお気に入り.

失くしたときにあまりにも落ち込んでてかわいそうだったから同じメーカーの似たおもちゃを買ってあげたんだけど, おまけのねずみほどには食いつかなかった.

ペットショップ行けたのでバチクソおもちゃ買ってあげた(失くしたねずみのおもちゃ含む) pic.twitter.com/k4CZJNWD8r
— ずみし (@uzimihsr) June 2, 2020

このおもちゃ自体にまたたびの匂いがついてるとかそんなことはなくて, 売り物のおもちゃよりも色合いも地味.
だけど一緒に出しても絶対おまけのおもちゃの方で遊ぶ. なぜ…?

きっとねこには人間ごときにはわからないこだわりがあるんだろう…

ちなみに遊び方はちょっと変で,
ねずみを自分で咥えて放り投げる -> 落下点にダッシュ -> 落ちたねずみにねこパンチ -> 再度咥えて放り投げる…
をねずみが手の届かないところに入るまで延々と繰り返している.
見ていてかなり面白いので, 今度動画を撮ってみたい.

ねずみ発見 pic.twitter.com/DYX4u7wTMP
— ずみし (@uzimihsr) September 30, 2020

ひとりで楽しそうに遊んでくれるのでしもべとしては楽なんだけど,
すぐに失くすし, 誤飲の前科もあるので頃合いを見計らって片付けるようにしている.

ねずみのおもちゃ出しっぱなしにしたら案の定すぐ失くしてふてくされてる pic.twitter.com/BJnfvgyx8y
— ずみし (@uzimihsr) September 30, 2020

片付けるとぷーぷー文句言うのがちょっとかわいい.😂

ねずみのおもちゃを片付けられてきげんわるい pic.twitter.com/CrZbjrzkXS
— ずみし (@uzimihsr) September 28, 2020

おわり

9月のそとちゃんは環境の変化にもすぐに対応して, 元気いっぱいだった.
ほんとに手がかからない良い子でいつも助かる…

ねずみのおもちゃも見つかって, 運動不足も解消できそうでほんとに良かった.

おまけ

client-goを使ってKubernetesのPodをクラスタ外からwatchする

Wed, 30 Sep 2020 10:23:13 +0900

Podを見張りたい

Go用のKubernetesクライアントを使ってクラスタ内のPodの様子を見張るやつを作った.

やったことのまとめ

Kubernetesクラスタ内のPodをwatchし, Podの状態変化に応じて任意の処理を行うobserver.goを作った
RetryWatcherを使う方法とInformerを使う方法を試したが, Informerを使うほうがよさそう

kubernetes-pod-observer

つかうもの

macOS Mojave 10.14
go version go1.14.6 darwin/amd64
kubernetes/client-go v0.19.2
Kubernetesクラスタ v1.15.12-gke.20

やったこと

RetryWatcherでwatchする
Informerを使ってみる

RetryWatcherでwatchする

PodをListするAPI¹でwatchオプションを指定すると, Podの情報(event)がリアルタイムで流れてくる.
このeventを見ることで, Podが作成/更新/削除されたタイミングを把握することができる.

# PodのList APIにwatchオプションをつけて実行(kubectlは内部でAPIを叩いている)
$ kubectl get pods -w

# この状態で別ターミナルからJobを実行して削除
$ kubectl create job busybox --image=busybox -- /bin/sh -c 'echo hello'
$ kubectl delete job busybox

# kubectl get pods -w の出力
NAME READY STATUS RESTARTS AGE
busybox-8kzpz 0/1 Pending 0 1s # Pod作成予約
busybox-8kzpz 0/1 Pending 0 1s # Pod作成
busybox-8kzpz 0/1 ContainerCreating 0 1s # コンテナ起動
busybox-8kzpz 0/1 Completed 0 3s # Pod(コンテナ)完了
busybox-8kzpz 0/1 Terminating 0 12s # 削除直前の状態
busybox-8kzpz 0/1 Terminating 0 12s # Pod削除完了

今回はGo純正のKubernetesクライアントライブラリclient-goを使い,
watch用のAPIを利用してPodをひたすら見張りつづけて状態変化に応じた処理を行うようなしくみを作ってみた.

# 作業用ディレクトリとgo.modの作成
$ pwd
/path/to/workspace
$ mkdir kubernetes-pod-observer && cd kubernetes-pod-observer
$ go mod init github.com/uzimihsr/kubernetes-pod-observer
$ touch observer.go

observer.goはこんな感じで作った.
Kubernetes APIクライアントの認証情報はkubeconfig(~/.kube/config)を参照して,
Podをwatchし, watchしたeventの内容を元に処理を分けるような形になっている.
kubeconfig読み込みからクライアント立ち上げまでの流れは公式のサンプルコード²を参考にした.

少しこだわったのはPodをwatchする際にRetryWatcher³を使用しているところ.
普通にwatch用のAPIを叩く場合一定時間が経つとAPIサーバー側が接続を切ってしまう仕様なのだが⁴⁵,
これを使うとwatchの接続が切れたときにクライアント側で勝手に再接続してくれる.

また, watchを再開するとすでに観測したことのあるeventも拾ってしまうので,
eventに紐づくResourceVersionを参照して既に見たことのあるeventは無視するようにした.

実際にobserver.goが動いている状態で, Podを手で作ったり, Jobから作成してみる.

# observer.goを実行
$ go run observer.go

# 以下は別のターミナルから実行
# Podを作成(1)
$ kubectl run busybox --image=busybox --restart=Never -- /bin/sh -c 'echo hello'

# Podを削除(2)
$ kubectl delete pod busybox

# Job経由でPodを作成(3)
$ kubectl create job busybox --image=busybox -- /bin/sh -c 'echo hello'

# Jobを削除(4)
$ kubectl delete job busybox

このときのobserver.goの出力は次のようになる.

# observer.goの出力

# (1)
ResourceVersion: 60844265
the Pod < busybox > has been created.
ResourceVersion: 60844266
the Pod < busybox >'s phase is < Pending >.
ResourceVersion: 60844267
the Pod < busybox >'s phase is < Pending >.
ResourceVersion: 60844271
the Pod < busybox >'s phase is < Succeeded >.

# (2)
ResourceVersion: 60844359
the Pod < busybox >'s phase is < Succeeded >.
ResourceVersion: 60844360
the Pod < busybox > has been deleted.

# (3)
ResourceVersion: 60844936
the Pod < busybox-dx4f8 > has been created by the Job < busybox >.
ResourceVersion: 60844937
the Pod < busybox-dx4f8 >'s phase is < Pending >.
ResourceVersion: 60844940
the Pod < busybox-dx4f8 >'s phase is < Pending >.
ResourceVersion: 60844948
the Pod < busybox-dx4f8 >'s phase is < Succeeded >.

# (4)
ResourceVersion: 60845063
the Pod < busybox-dx4f8 >'s phase is < Succeeded >.
ResourceVersion: 60845064
the Pod < busybox-dx4f8 > has been deleted.

こんな感じで, watchしたPodの状態に応じた処理を行うことができた.

Informerを使ってみる

…実は同じようなことをする公式のサンプルコード⁶がある,
こっちはeventをwatchする部分でRetryWatcherの代わりに, Informer⁷というやつを使っている.
Informerはwatchに関する処理をさらに抽象化したものらしくて, watchが途切れたときに再度接続を復活させたり,
watchしたeventの種類で処理を分けたりとwatch対象のリソース(Pod)の状態変化に応じた処理がしやすくなっている. らしい.
(observer.goでは自分で記述していたような処理も内部でやってくれている)

サンプルコードを真似てobserver.goを書き直してみる.

ポイントはInformerの作成時にeventのType(ADDED, MODIFIED, DELETED)に応じた処理をそれぞれAddFunc, UpdateFunc, DeleteFuncで設定するところ.
こうしておくことで, 対象のリソース(Pod)の状態が変化したときにそれに応じた処理を設定することができる.

実際に動かしてみる.

# observer.goを実行
$ go run observer.go

# 以下は別のターミナルから実行
# Job経由でPodを作成(1)
$ kubectl create job busybox --image=busybox -- /bin/sh -c 'echo hello'

# Jobを削除(2)
$ kubectl delete job busybox

# observer.goの出力

# (1)
Pod <busybox-m5cd6> was added by Job <busybox>.
Pod <busybox-m5cd6> is Pending phase.
Pod <busybox-m5cd6> is Pending phase.
Pod <busybox-m5cd6> is Succeeded phase. previous: Pending phase

# (2)
Pod <busybox-m5cd6> is Succeeded phase.
Pod <busybox-m5cd6> was deleted.

observer.goを起動した状態でJobを実行し, Podの作成, 状態変化, 削除のタイミングで任意の処理を行うことができた.
今回はデフォルトNamespaceのPod名を標準出力しただけだが, 頑張れば特に重要なNamespaceのPodについては変化のタイミングで特定の相手に通知を送ったりとかもできるはず.

今回はPodの状態変化を見張る部分とそれに応じた処理を1つにしてしまっているが, もちろんサンプルコード⁶のようにAddFuncなどでキューにデータを送り, 別のgo routineでキューからデータを取り出して処理することもできる. はず.
(ここで力尽きたのでやめた)

おわり

Kubernetesクラスタの外からPodをwatchして, その状態変化に応じた任意の処理を行うやつを作った.
RetryWatcherを使う方法とInformerを使う方法の2通りを試してみたけど, Informerを使うほうがwatchを行う部分について難しいことを考える必要がなくて楽な感じがした.
どっちを使うべきか迷ったらInformerを使うほうがおすすめ?らしい⁸.

Informerはカスタムコントローラとかでも使われているみたいなので⁹, 時間があったらもう少し勉強してみたい.

おまけ

GoでPrometheus用のExporterをつくる

Wed, 16 Sep 2020 22:32:00 +0900

自作Exporter

Prometheusでスクレイプする用のExporterを自作してみた.

やったことのまとめ

GoのPrometheusクライアント¹を使って, 自分で設定したメトリクスを表示できるExporterを作成した
作成したExporterとPrometheusをDockerで動かし, スクレイプできることを確認した

https://github.com/uzimihsr/example-exporter

つかうもの

macOS Mojave 10.14
go version go1.14.6 darwin/amd64
prometheus/client_golang v1.7.1
Docker Desktop for Mac 2.1.0.3
- Docker version 19.03.2
- docker-compose version 1.24.1

やったこと

Exporterの作成
Prometheusでスクレイプ

Exporterの作成

# 作業用ディレクトリとgo.modの作成
$ pwd
/path/to/workspace
$ mkdir example-exporter && cd example-exporter
$ go mod init github.com/uzimihsr/example-exporter
go: creating new go.mod: module github.com/uzimihsr/example-exporter
$ touch main.go

main.goはこんな感じで作る.
書き方はDocsの例²とPrometheusクライアントのサンプルコード³を参考にした.

ポイントは/metricsへのリクエストをハンドリングする処理と別にgo routineを使ってメトリクスを更新する処理を入れているところ.
こうすることで各メトリクスが並行に更新され, リクエストが来るたびにメトリクスの最新の値を返すことができる.

試しに動かしてみる.

# exporterの実行
$ go run main.go

ブラウザで http://localhost:2112/metrics を開く.

こんな感じでPrometheusが読めるフォーマットのメトリクスが表示された.
メトリクス定義に記述したメトリクス名, 説明文, ラベルが反映されていることがわかる.

# HELP example_number Example Gauge
# TYPE example_number gauge
example_number{fuga="fugafuga"} -0.0056473753420378525
# HELP example_total Example Counter
# TYPE example_total counter
example_total{hoge="hogehoge"} 13

Prometheusでスクレイプ

せっかくなので, Prometheusでスクレイプしてみる.
今回は試しにDocker上でPrometheusのコンテナと今回作った example-exporter のコンテナを同時に動かす.

example-exporter 用のDockerfileの書き方はGoアプリをDockerのscratchイメージで動かすを参考にする.

さらにPrometheusの設定ファイルprometheus.ymlと,
2つのコンテナを動かすためにdocker-compose.ymlを作成する.

この状態でdocker-composeで2つのコンテナを起動する.

# ディレクトリの状態
$ tree .
.
├── Dockerfile
├── docker-compose.yml
├── go.mod
├── go.sum
├── main.go
└── prometheus.yml

# docker-composeでコンテナを起動
$ docker-compose up -d
Creating network "example-exporter_default" with the default driver
Creating example-exporter ... done
Creating prometheus ... done

コンテナが起動した状態で http://localhost:9090/graph をホストのブラウザで開くと, Prometheusの画面が表示される.
無事に起動できていれば example-exporter がスクレイプできている.

試しに example-exporter のメトリクス名でクエリを投げてみると, ちゃんと時系列の値が表示される.

example_total はmain.goで設定した通り30秒ごとに値が加算され,
example_number はmain.goで設定した値の変化の間隔(10秒)がPrometheusのscrape_interval(15秒)より短いために15秒ごとに値が変化している.

やったぜ.
自作のExporterをスクレイプして, 設定したとおりにメトリクスが変化していることが確認できた.

おわり

PrometheusでスクレイプできるかんたんなExporterを自作してみた.
Prometheus自体がGoで書かれているだけあって, Goだとかなり楽に記述できた. と思う.
特にgo routineのおかげでメトリクスとHTTPハンドラの並行処理が簡単に書けるのがいいと思った.
自作のAPIとかにこんな感じでExporterを実装すれば監視がめちゃめちゃ楽になりそう.

おまけ

cobraでかんたんなCLIツールをつくった

Thu, 03 Sep 2020 22:10:37 +0900

Goでコマンドラインツール

golangでCLIツールを作るときに引数とかサブコマンドをいい感じにしてくれるライブラリのcobraを試した.

やったことのまとめ

cobraを使ってコマンドラインであいさつするおもちゃgreetingをつくった.

# hello
$ greeting hello hoge fuga piyo --message 'Nice to meet you!'
Hello, hoge, fuga, and piyo!
Nice to meet you!

# こんにちは
$ greeting hello 鈴木 --message 'お会いできて嬉しいです!' -l ja
鈴木さん, こんにちは!
お会いできて嬉しいです!

# goodbye
$ greeting goodbye hoge fuga piyo
Goodbye, hoge, fuga, and piyo!

# さようなら
$ greeting goodbye A -l ja
Aさん, さようなら!

つかうもの

macOS Mojave 10.14
go version go1.14.6 darwin/amd64
cobra v1.0.0

やったこと

cobraのインストールとサンプルコードの作成
サブコマンドの実装

cobraのインストールとサンプルコードの作成

cobraはこれ自身がコマンドとしても提供されているので, まずはこれをインストールする.

# cobraをインストール
$ go get -u github.com/spf13/cobra/cobra
$ which cobra
/GOPATH/bin/cobra
$ cobra
Cobra is a CLI library for Go that empowers applications.
This application is a tool to generate the needed files
to quickly create a Cobra application.

Usage:
 cobra [command]

Available Commands:
 add Add a command to a Cobra Application
 help Help about any command
 init Initialize a Cobra Application

Flags:
 -a, --author string author name for copyright attribution (default "YOUR NAME")
 --config string config file (default is $HOME/.cobra.yaml)
 -h, --help help for cobra
 -l, --license string name of license for the project
 --viper use Viper for configuration (default true)

Use "cobra [command] --help" for more information about a command.

cobra initを使うと動く状態のサンプルコードを生成してくれる.¹
昔は空のディレクトリじゃないとできなかったみたいだけど, 今は気にしなくて大丈夫.

# 新規ディレクトリを作成+go.modを作成
$ mkdir -p greeting && cd greeting
$ go mod init github.com/uzimihsr/greeting
go: creating new go.mod: module github.com/uzimihsr/greeting

# サンプルコードの作成
$ cobra init --pkg-name github.com/uzimihsr/greeting
Your Cobra application is ready at
/path/to/greeting
$ tree .
.
├── LICENSE
├── cmd
│   └── root.go
├── go.mod
└── main.go

1 directory, 4 files

作成されたサンプルコードはこんな感じ.

試しに動かしてみる.

# アプリの実行
$ go run main.go
A longer description that spans multiple lines and likely contains
examples and usage of using your application. For example:

Cobra is a CLI library for Go that empowers applications.
This application is a tool to generate the needed files
to quickly create a Cobra application.
# root.goで設定されたヘルプメッセージ

ちゃんと動いた.

さらに, cobra addでサブコマンドを作成できる.
追加したサブコマンドのファイルはroot.goと同じくcmd配下に作成される.

# サブコマンド(hello)の作成/実行
$ cobra add hello
hello created at /Users/uzimihsr/Workspace/greeting
$ ls cmd
hello.go root.go

$ go run main.go hello
hello called
$ go run main.go hello -h
A longer description that spans multiple lines and likely contains examples
and usage of using your command. For example:

Cobra is a CLI library for Go that empowers applications.
This application is a tool to generate the needed files
to quickly create a Cobra application.

Usage:
 greeting hello [flags]

Flags:
 -h, --help help for hello

Global Flags:
 --config string config file (default is $HOME/.greeting.yaml)

サブコマンドの実装

あとはこのルートコマンド(root.go)とサブコマンド(hello.go)をいじっていく.
どちらもinit()関数で引数やコマンドに必要な変数の設定を行い,
Command.Runのfunc()で実際に行う処理を記述しているので, この形式に従っていろいろいじってみる.

最終的なディレクトリ構造はこんな感じ.
出会いと別れの挨拶をするサブコマンドcmd/hello.goとcmd/goodbye.goを実装した.

$ tree .
.
├── cmd
│   ├── goodbye.go
│   ├── hello.go
│   └── root.go
├── go.mod
├── go.sum
└── main.go

1 directory, 6 files

実際に動かしてみる.
go installするとPATHが通ってすぐ使えるようになるのでべんり.

# ビルドして実行
$ go build
$ ./greeting hello World
Hello, World!

# GOPATHが通っている場合はinstallするとパスが通る
$ go install
$ which greeting
$GOPATH/bin/greeting

# -l で言語(en/ja)の指定ができる
$ greeting goodbye A B -l ja
Aさん, Bさん, さようなら!

# --message で追加のメッセージを指定できる
$ greeting hello A B C --message 'Nice to meet you!'
Hello, A, B, and C!
Nice to meet you!

# goodbyeには敢えて --message のflagをつけていないので指定するとエラーになる
$ greeting goodbye A --message 'See you again!'
Error: unknown flag: --message
Usage:
 greeting goodbye [NAME] [flags]

Flags:
 -h, --help help for goodbye

Global Flags:
 -l, --lang string Language : en, ja (default "en")

unknown flag: --message

# 引数の数が不正でもエラーになる
$ greeting hello
Error: requires at least 1 arg(s), only received 0
Usage:
 greeting hello [NAME] [flags]

Flags:
 -h, --help help for hello
 -m, --message string Help message for toggle

Global Flags:
 -l, --lang string Language : en, ja (default "en")

requires at least 1 arg(s), only received 0

やったぜ.
機能はしょぼいけど, サブコマンドごとに違う機能を持つCLIツールができた.

おわり

Cobraを使って簡単なCLIツールを作った.
サブコマンドごとにflag(オプション)が管理できたり, Argsで引数の条件を指定できたりするのがいいと思う.
今までGoでCLIを作るときは標準パッケージのflagを使ってたけど,
これからはCobraでサクッと作るようにしたい.

おまけ

Cobra Generator ↩︎

8月のそとちゃんまとめ(2020)

Wed, 02 Sep 2020 21:28:29 +0900

大騒ぎ

8月のそとちゃんはたいへんだった.

まとめ

誤飲事件
ひなたぼっこを満喫
カリカリ問題の進捗

誤飲事件

なんと言ってもヒモ誤飲事件があった.

やばいことにならなくて本当によかった

しもべの不注意が原因なので反省します pic.twitter.com/tsGqCQD8Q0
— ずみし (@uzimihsr) August 6, 2020

もともとそんなにおもちゃを咥えたりしないかしこいねこだったんだけど,
その日はおもちゃにまたたびをかけてたので興奮して食べちゃったんじゃないかと推測している.

というわけでまたたびは当分の間禁止になった(かわいそう).

きげんわるい pic.twitter.com/nkanUTcHit
— ずみし (@uzimihsr) August 29, 2020

また, 今回の件でやっぱりペット保険に入ろうと思ったので, 診察ついでに獣医さんにそとちゃんのだいたいの年齢を調べてもらった.
(元野良とかで正確な生年月日がわからないねこは獣医さんに推測してもらう必要がある)
歯の生え方とかからだいたい推測できるらしい.

2016年5月生まれ(推定). やっぱり4さいくらいだった.

うちに来たのが5月1日なので,
記念日も兼ねて 2016年5月1日生まれ ということにする.

知らなかった #世界猫の日 pic.twitter.com/40M6d3G8IY
— ずみし (@uzimihsr) August 8, 2020

やっぱり4さいのねこは威厳がありますね…(ほんまか?)

ひなたぼっこを満喫

8月は天気のいい日が多くて, ひなたぼっこが捗ったらしい.
とくに窓際のダンボールとハンモックがお気にいりだった.

https://twitter.com/uzimihsr/status/1290172623884705793

ひなたぼっこ pic.twitter.com/lJdQchyKDA
— ずみし (@uzimihsr) August 20, 2020

あとはベランダで力尽きたセミの観察にも熱心だった.

ベランダを監視 pic.twitter.com/NJD1eaGO2S
— ずみし (@uzimihsr) August 17, 2020

陽に当たるのは健康にもいいはずなんだけど,
そのまま寝落ちするのは熱中症が心配なのでやめてほしい…

まーた直射日光浴びてる pic.twitter.com/z6NQd2fgi8
— ずみし (@uzimihsr) August 2, 2020

すやすや pic.twitter.com/YGmSbf1HC0
— ずみし (@uzimihsr) August 5, 2020

カリカリ問題の進捗

カリカリ食べない問題がちょっとだけ改善?した.

俺がいない間ならカリカリをちゃんと食べるのがよくわかったので,
今月は夕方にときどき外出するようにしてみた.

割と効果はあって, 午後に出しているカリカリを残さず食べるようになった.

←しもべが出かける前帰宅時(2h後)→ pic.twitter.com/Bajm6CzAoO
— ずみし (@uzimihsr) August 15, 2020

さらに何日か繰り返すと夕方にカリカリを食べるのが習慣化されたみたいで,
俺が家にいても半分くらいは食べてくれるようになった.

えらい.🎉
ちゃんとカリカリをたべられるねこはかっこいいですね.

おわり

8月のそとちゃんは大変なこともあったけどやっぱりだいたい元気だった.

9月はちょっと大変な予定があるので, なるべくそとちゃんに負担をかけずに終わらせられるようにしたい…

おまけ

CKAD-JPを受験した

Mon, 17 Aug 2020 21:35:13 +0900

Kubernetes完全に理解した()

CKADを受験したので受験記的なやつ. 個人の感想. n番煎じ.

CKAD受験の流れ

受験の経緯
試験対策
申し込み
試験当日
試験について
結果

受験の経緯

CKADはKubernetesクラスタでアプリを開発したり動かしたりする能力を証明する公式の認定試験.
他にもクラスタ管理者向けのCKAっていう試験もある.

去年の10月くらいから業務でKubernetesを半年くらい使っていてだんだん勉強のモチベーションが保てなくなってきたので, 目先の目標として受験することにした.

試験対策

7月に受験を決めてから1ヶ月の間, 普段の業務の他に以下の教材を使って試験対策をした.

Kubernetes完全ガイド
基本はこれ.
PodとかDeploymentとかの基本的なk8sリソースについてしっかり勉強できる.
一通り読んだけど, 11章以降のクラスタ自体の操作とかの内容はあんまり試験に出なかったように思う. 13章(セキュリティ)の内容はちょっとだけ出たかも.
最近第2版が出たらしい. 試験に関係なく持っておくと役に立つ.
CKAD-exercises
CKADの問題を解くための基本的なリソース操作などの練習問題集.
実際の問題とは少し違うけど, 基本操作はこれで一通り練習できる.
2周くらいやってコツをつかんだ.
A Cloud GuruのCKADコース
本番の対策用. 有料(7日間無料).
HANDS-ON-LAB, 特に Practice Exam の問題は本番の問題にけっこう近かったように感じる.
Kubernetes完全ガイドを読んでいるのでハンズオン以外の内容は飛ばしても問題なかった.
1週間だけ無料なので, 試験直前に登録して終わったあとにすぐ解約した.

申し込み

英語イキリオタクだけど母語は日本語なので, できるだけ合格の確率を上げるために日本語で受験できるという触れ込みのCKAD-JPを受けることにした.

…が, 後述のように実際は申し込みの手順も試験官とのやり取りも全部英語だったので普通のCKADを受けたほうがよかったのかも.

申し込みにはLinux Foundationとpsiのアカウントが必要になるけど, 1つのGoogleアカウントで全部登録できるのでかんたんだった.
やることは名前とかの情報を入力して, クレカで受験料を払って, 試験日を予約するだけ.
試験日の予約は結構空きが少なかったので, もっと余裕を持って予約すればよかった.

受験用のブラウザはChromeがおすすめで, 事前に拡張機能をインストールしておく必要がある.
さらに念の為にCompatibility Checkをやっておくと安心.

試験当日

試験は自分の部屋で受けた.

試験開始の15分前くらいにmy portalで 試験開始 的なボタンを押すと勝手に画面が切り替わって, 試験官がライブチャットで以下の内容を指示してきたのでその通りにした.

拡張機能を使って画面とカメラ, マイクを共有しろ(顔を映せ)
使ってるOSを教えろ
強制終了メニュー(⌘+⌥+Esc)を表示して起動中のアプリを見せろ(ブラウザ以外消せ)
カメラ越しに身分証(パスポートとクレジットカード)を見せろ
机の上のものを全部片付けろ
カメラを持ったまま部屋を一周しろ
試験中はカメラに顔が映るようにして目線を画面から外すな

要はオンライン試験なのでカンニングができないように注意しろってことだと思う.

特に片付けのタイミングで, “鼻をかむための箱ティッシュは試験中使えないよ!” って言われたのが面白かった.
鼻炎だから無いと辛かったんだけどカンニング対策なので許されず, 最終的に無地のハンカチを胸ポケットに入れて使うことになった.

ちなみに, CKAD-JPで受験したのになぜか試験官とのやりとりは最後までずっと英語だった.
とはいえ音声会話ではなくテキスト形式なのでそんなに困ることもなかった.

最初の試験官とのやりとりが終わったあとはすぐに試験問題の画面に切り替わるので, あとは問題を解くだけだった.
残り時間が15分になったときと試験終了時に再度試験官とやりとりが発生したけど, 特に何もなくおわった.

試験について

具体的な問題の内容を公開するのは許されていないので, 簡単なメモ.

試験用の画面はこんな感じ
左側に問題, 右側にターミナルの画面. Katacodaっぽさがある.
Kubernetesクラスタとかkubectlはすでにセットアップされていて, 問題の内容をコマンドラインでガンガン解いていく感じ.
tmuxが使えるので, 自分はターミナルの画面を左右分割して片方でkubectl -hとかkubectl explainの内容を表示しながらもう片方で操作するようにした.
この画面以外にも1タブだけ公式Docsを開くことが許されてたけど, そこまで使わなかった. というかDocsをちんたら調べてる暇はなかった.
試験時間は2時間で問題数は19問
"~のimageを使ったPodを作れ. それをXX番ポートで公開するServiceを作れ" とか,
"~のnamespaceに壊れているPodがあるのでそれを探して修復しろ" 的な問題が立て続けに来た.
問題を解く順序は決められていないので, 飛ばした問題をあとから解き直したりもできた.
問題文は英語, 日本語, 中国語が自由に切り替えられる
…が, 日本語の翻訳が割とガバめなのと普段英語で覚えてる用語がカタカナになっただけでかなり混乱したので, 結局最後まで英語で解いた.
スピード勝負
約20問を2時間, 平均で約6分/1問のペースで解かなければならなかった.
いちいちYAMLを0から手で書いていては到底間に合わない ので, kubectlでサクッと作るか, 公式Docsからコピペするのが良さげ.
すでに存在するリソースを修正するような問題も出るので, kubectl editやkubectl get -o yamlとかも使う必要があった.
まさに YAML地獄.
namespaceが指定されている問題とそうでない問題がある
これは結構重要.
リソースを操作するnamespaceが指定されている問題がある一方, 何の指定もない問題もあったのでちょっとだけ混乱した.
何も指定されていない場合はdefaultで操作したけど, 結果を見るにそれでよかったっぽい.
複数のクラスタを操作する必要がある
これも重要だけど, どの問題も最初にcontextを切り替えるコマンドが指定されているので忘れずコピペすればそこまで問題にはならなかった.

結果

結局時間はギリギリで, 最後の19問目を解いている途中で時間切れになった.

結果は試験終了後36時間以内に届くことになっていたが, 結構待たされて34時間後にメールで結果が届いた.

結果は…?

合格だった. 🎉

合格点66点に対して得点は91点だったので, そこそこ余裕を持って合格できたんじゃなかろうか.
たぶん100点満点なので解ききらなかった最後の1問以外はほとんど正解. だったらいいな.

おわり

というわけでCKADに合格した.
合格したから会社の給料が上がるとか特にそういったことはないけど, なんかうれしい.
とりあえずYAML耐性は大幅に上がったはず.

ようやくKubernetes完全に理解した()のでこの勢いで次はCKAも獲りたいけど, もっと勉強する必要がありそう…

おまけ

ねこがおもちゃのヒモを誤飲した話

Thu, 13 Aug 2020 22:55:13 +0900

肝を冷やした

結果的に問題はなかったけど, 不注意でそとちゃんを危険な目に遭わせてしまったので自分への戒めとして記録しておく.

まとめ

今回の教訓.

ねこがヒモ付きのおもちゃで遊んでるときは目を離しちゃだめ
ヒモの誤飲は最悪死に至るほど危険
誤飲の疑いがある時点で急患で病院に行く, 様子見は危険
誤飲してから検査までの間は水とごく少量のウェットフードだけ食べさせる

おもちゃのヒモが消えた

ある日の夜のこと.

ヒモ付きのボールのおもちゃ

あたらしいおもちゃ pic.twitter.com/EqbMGAtRMg
— ずみし (@uzimihsr) June 26, 2020

でねこをひとりで遊ばせていたところ, 突然ヒモが無くなっていたことに気づいた.

遊んでて抜けたのか, ヒモが付いてた場所にぽっかり穴が空いている.

まわりを探しても見つからなかったので, ねこが食べたかもしれない.

そとちゃん「みゃーん」

そとちゃん「(ごろーん)」

でもなんかねこは元気っぽい.
もしかして, 食べてない? ヒモはどこか見つけづらいところに入ってしまっただけ?

とりあえず一晩様子を見て, 朝になってから動物病院にいくことにした.
(今だから言えるけどこの判断は危険だった. 本当は急患で行くべきだった.)

急変

夜中に容態が急変することはなく, 朝になったので速攻で診察予約の電話をかける.

電話してる途中にいきなり,

そとちゃん「ぐっ, くぽっ」

そとちゃん「げっ, ぐげっ, がっ」

なんか吐いた!!!

やっぱりヒモを食べていた…

全部吐き出せたので最悪の事態は避けられたっぽい.

獣医さんに電話で相談.

この日は朝から診察の予約が埋まっていて, 異物が全部吐き出せていて急患じゃないのなら夕方に診てくれるとのこと.

さらにそれまでにやるべきことも教えてもらえた.

内蔵が傷ついているかもしれないので基本的に水以外は与えないでおく
吐き出してからある程度時間が経ってから少しだけウェットフードを食べさせて様子を見る
もしフードを吐いたり容態が急変したら急患ですぐ病院に行く

言われたとおりにして様子を見て, ねこも元気なままだったので少し安心した.

おもちゃの紐食べてゲロ吐いたのにかっこつけてるねこ

病院行ってきます pic.twitter.com/592Av5ytND
— ずみし (@uzimihsr) August 5, 2020

検査結果

夕方に動物病院へ行き, X線検査と超音波検査をしてもらった.

幸いなことに内蔵に問題は見つからなかった.

めっちゃ安心した.

と同時に, 先生にめっちゃ怒られた.

15cmくらいの毛糸状のヒモは誤飲すると本当に危険, 死ぬこともある
ヒモ付きのおもちゃで遊んでる間は目を離してはいけない
誤飲の疑いがある時点で急患で動物病院に行くべき

そのとおり. 完全に俺の不注意が原因だった.

普段はおもちゃをくわえたりしないねこだけど, この日はまたたびで興奮していたのでもっと注意すべきだった.

反省しかない.

ちなみに俺が怒られてる横でもそとちゃんは診察台でごろごろして余裕ぶっこき丸だった.
やっぱり病院は嫌いじゃないみたい.

おわり

ちなみに今回誤飲して吐き出したヒモはこんな感じ.

こんな異物がねこのお腹の中にあったと思うとゾッとする.

今回は運良く全部吐き出せただけで, 最悪の事態だってありえた.

二度とこんな事が起こらないようにしたい.

おまけ

パラメータがあるときだけWHERE句が有効になるようなSQLを書こうとして詰んだ

Wed, 05 Aug 2020 20:55:20 +0900

クエリ1個で済ませたかった

SELECT文のWHEREで絞りたい条件が複数あるときに静的なクエリでできないか試したけど, あんまり良くなさそうだった.

まとめ

ORとかCASEとかを使うと一応動くものは作れる.
けどあんまりパフォーマンスが良くなさそうなのでおとなしく動的SQLを使うほうが良さげ.

# どちらもTEAMとROLEに空文字('')以外の文字列が指定された場合のみWHERE句が有効になる

mysql> SELECT * FROM employee
 -> WHERE (team = @TEAM OR @TEAM = '')
 -> AND (role = @ROLE OR @ROLE = '')
 -> ;

mysql> SELECT * FROM employee
 -> WHERE CASE WHEN @TEAM = '' THEN @TEAM ELSE team END = @TEAM
 -> AND CASE WHEN @ROLE = '' THEN @ROLE ELSE role END = @ROLE
 -> ;

環境

macOS Mojave 10.14
MySQL 5.7.25

やりかた

まずは適当なテーブルを作成する.

mysql> source employee.sql

mysql> DESC employee;
+-------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| name | varchar(10) | YES | | NULL | |
| team | varchar(10) | YES | | NULL | |
| role | varchar(10) | YES | | NULL | |
| age | int(11) | YES | | NULL | |
+-------+-------------+------+-----+---------+----------------+
5 rows in set (0.00 sec)

mysql> SELECT * FROM employee;
+----+----------+------+---------+------+
| id | name | team | role | age |
+----+----------+------+---------+------+
| 1 | Alice | A | manager | 30 |
| 2 | Ben | B | manager | 50 |
| 3 | Charlie | A | member | 40 |
| 4 | Daniel | A | member | 30 |
| 5 | Emily | A | member | 20 |
| 6 | Florence | A | member | 30 |
| 7 | George | A | trainee | 20 |
| 8 | Harry | B | member | 40 |
| 9 | Isabel | B | member | 40 |
| 10 | Jack | B | trainee | 20 |
| 11 | Katie | B | trainee | 20 |
+----+----------+------+---------+------+
11 rows in set (0.00 sec)

このテーブルから「teamがAで, かつroleがmember」のレコードを抽出するクエリは次のように書ける.

mysql> SELECT * FROM employee WHERE team = 'A' AND role = 'member';
+----+----------+------+--------+------+
| id | name | team | role | age |
+----+----------+------+--------+------+
| 3 | Charlie | A | member | 40 |
| 4 | Daniel | A | member | 30 |
| 5 | Emily | A | member | 20 |
| 6 | Florence | A | member | 30 |
+----+----------+------+--------+------+
4 rows in set (0.00 sec)

ここまではいいんだけど,
外部からクエリを投げるときなんかにteamとroleがそれぞれ指定されたときだけWHEREの条件を増やして, 次のようなクエリを自動で作れないか考えてみる.

# roleだけ指定された場合
mysql> SELECT * FROM employee WHERE role = 'member';

# teamだけ指定された場合
mysql> SELECT * FROM employee WHERE team = 'A';

# 両方指定された場合
mysql> SELECT * FROM employee WHERE team = 'A' AND role = 'member';

# 何も指定されなかった場合
mysql> SELECT * FROM employee;

これをプログラム側で実現するなら次のように動的にクエリを組み立てればできる.
(これは簡単すぎる例, 本当はこんな適当な文字列連結でクエリを組み立てるのはSQLインジェクションとかを考えるとたぶんセキュリティ的によろしくない)

sql_example.go

これでも問題なさそうなんだけど,
プログラム側の処理に頼らずSQLだけでこんな感じのクエリを組み立てたくなった.

できそうなのは2通り.

ORを使う

レコードの要素にNULLがない場合はORで複数の条件を合わせればできそう.

mysql> SELECT * FROM employee
 -> WHERE (team = @TEAM OR @TEAM = '')
 -> AND (role = @ROLE OR @ROLE = '')
 -> ;

WHERE (team = @TEAM OR @TEAM = '')はパラメータ@TEAMの内容によって次のように変わる.

@TEAM = ''の場合
WHERE (team = '' OR '' = '')
-> team = ''となるレコードはないので'' = ''を満たすレコード(即ち全件)を抽出
@TEAM = 'A'の場合
WHERE (team = 'A' OR 'A' = '')
-> 'A' = ''となるレコードはないのでteam = 'A'を満たすレコードのみ抽出

実際に試してみる.

mysql> SET @TEAM=''; SET @ROLE='';
mysql> SELECT * FROM employee WHERE (team = @TEAM OR @TEAM = '') AND (role = @ROLE OR @ROLE = '');
+----+----------+------+---------+------+
| id | name | team | role | age |
+----+----------+------+---------+------+
| 1 | Alice | A | manager | 30 |
| 2 | Ben | B | manager | 50 |
| 3 | Charlie | A | member | 40 |
| 4 | Daniel | A | member | 30 |
| 5 | Emily | A | member | 20 |
| 6 | Florence | A | member | 30 |
| 7 | George | A | trainee | 20 |
| 8 | Harry | B | member | 40 |
| 9 | Isabel | B | member | 40 |
| 10 | Jack | B | trainee | 20 |
| 11 | Katie | B | trainee | 20 |
+----+----------+------+---------+------+
11 rows in set (0.00 sec)
# SELECT * FROM employee; と同じ

mysql> SET @TEAM='A'; SET @ROLE='';
mysql> SELECT * FROM employee WHERE (team = @TEAM OR @TEAM = '') AND (role = @ROLE OR @ROLE = '');
+----+----------+------+---------+------+
| id | name | team | role | age |
+----+----------+------+---------+------+
| 1 | Alice | A | manager | 30 |
| 3 | Charlie | A | member | 40 |
| 4 | Daniel | A | member | 30 |
| 5 | Emily | A | member | 20 |
| 6 | Florence | A | member | 30 |
| 7 | George | A | trainee | 20 |
+----+----------+------+---------+------+
6 rows in set (0.00 sec)
# SELECT * FROM employee WHERE team = 'A'; と同じ

mysql> SET @TEAM=''; SET @ROLE='member';
mysql> SELECT * FROM employee WHERE (team = @TEAM OR @TEAM = '') AND (role = @ROLE OR @ROLE = '');
+----+----------+------+--------+------+
| id | name | team | role | age |
+----+----------+------+--------+------+
| 3 | Charlie | A | member | 40 |
| 4 | Daniel | A | member | 30 |
| 5 | Emily | A | member | 20 |
| 6 | Florence | A | member | 30 |
| 8 | Harry | B | member | 40 |
| 9 | Isabel | B | member | 40 |
+----+----------+------+--------+------+
6 rows in set (0.00 sec)
# SELECT * FROM employee WHERE role = 'member'; と同じ

mysql> SET @TEAM='A'; SET @ROLE='member';
mysql> SELECT * FROM employee WHERE (team = @TEAM OR @TEAM = '') AND (role = @ROLE OR @ROLE = '');
+----+----------+------+--------+------+
| id | name | team | role | age |
+----+----------+------+--------+------+
| 3 | Charlie | A | member | 40 |
| 4 | Daniel | A | member | 30 |
| 5 | Emily | A | member | 20 |
| 6 | Florence | A | member | 30 |
+----+----------+------+--------+------+
4 rows in set (0.00 sec)
# SELECT * FROM employee WHERE team = 'A' AND role = 'member'; と同じ

やったぜ.
と思ったらこのやり方は個別の条件を指定するクエリに比べるとINDEXが使えなくなるので, 性能が良くないらしい…¹
今はまだテーブルが小さいからうまくいってるように見えるだけなんだろうか.
SQLチューニングはちゃんと勉強したことがないのでよくわからん.

CASEでがんばる

ちょっと探してみたらCASEを使う別の方法もあった².

mysql> SELECT * FROM employee
 -> WHERE CASE WHEN @TEAM = '' THEN @TEAM ELSE team END = @TEAM
 -> AND CASE WHEN @ROLE = '' THEN @ROLE ELSE role END = @ROLE
 -> ;

こっちも構文が違うだけで結果は同じになるけど, パフォーマンスも変わらないんだろうか…

mysql> SET @TEAM='A'; SET @ROLE='member';
mysql> SELECT * FROM employee WHERE CASE WHEN @TEAM = '' THEN @TEAM ELSE team END = @TEAM AND CASE WHEN @ROLE = '' THEN @ROLE ELSE role END = @ROLE;
+----+----------+------+--------+------+
| id | name | team | role | age |
+----+----------+------+--------+------+
| 3 | Charlie | A | member | 40 |
| 4 | Daniel | A | member | 30 |
| 5 | Emily | A | member | 20 |
| 6 | Florence | A | member | 30 |
+----+----------+------+--------+------+
4 rows in set (0.00 sec)
# SELECT * FROM employee WHERE team = 'A' AND role = 'member'; と同じ

mysql> SET @TEAM='A'; SET @ROLE='';
mysql> SELECT * FROM employee WHERE CASE WHEN @TEAM = '' THEN @TEAM ELSE team END = @TEAM AND CASE WHEN @ROLE = '' THEN @ROLE ELSE role END = @ROLE;
+----+----------+------+---------+------+
| id | name | team | role | age |
+----+----------+------+---------+------+
| 1 | Alice | A | manager | 30 |
| 3 | Charlie | A | member | 40 |
| 4 | Daniel | A | member | 30 |
| 5 | Emily | A | member | 20 |
| 6 | Florence | A | member | 30 |
| 7 | George | A | trainee | 20 |
+----+----------+------+---------+------+
6 rows in set (0.00 sec)
# SELECT * FROM employee WHERE team = 'A'; と同じ

mysql> SET @TEAM=''; SET @ROLE='member';
mysql> SELECT * FROM employee WHERE CASE WHEN @TEAM = '' THEN @TEAM ELSE team END = @TEAM AND CASE WHEN @ROLE = '' THEN @ROLE ELSE role END = @ROLE;
+----+----------+------+--------+------+
| id | name | team | role | age |
+----+----------+------+--------+------+
| 3 | Charlie | A | member | 40 |
| 4 | Daniel | A | member | 30 |
| 5 | Emily | A | member | 20 |
| 6 | Florence | A | member | 30 |
| 8 | Harry | B | member | 40 |
| 9 | Isabel | B | member | 40 |
+----+----------+------+--------+------+
6 rows in set (0.00 sec)
# SELECT * FROM employee WHERE role = 'member'; と同じ

mysql> SET @TEAM=''; SET @ROLE='';
mysql> SELECT * FROM employee WHERE CASE WHEN @TEAM = '' THEN @TEAM ELSE team END = @TEAM AND CASE WHEN @ROLE = '' THEN @ROLE ELSE role END = @ROLE;
+----+----------+------+---------+------+
| id | name | team | role | age |
+----+----------+------+---------+------+
| 1 | Alice | A | manager | 30 |
| 2 | Ben | B | manager | 50 |
| 3 | Charlie | A | member | 40 |
| 4 | Daniel | A | member | 30 |
| 5 | Emily | A | member | 20 |
| 6 | Florence | A | member | 30 |
| 7 | George | A | trainee | 20 |
| 8 | Harry | B | member | 40 |
| 9 | Isabel | B | member | 40 |
| 10 | Jack | B | trainee | 20 |
| 11 | Katie | B | trainee | 20 |
+----+----------+------+---------+------+
11 rows in set (0.00 sec)
# SELECT * FROM employee; と同じ

おわり

一応動くものは作れたけど, このやり方だとパフォーマンス面を考えると微妙みたい…
参考にした記事にもあるように, やっぱりクエリを変化させたいときは動的に組み立てるほうがいいんだろうか?

目的の用途はそこまでスピードが求められるものではないので一旦はこれで良しとしたいけど, やっぱりちょっとひっかかる…
SQLの勉強は正直あまりやりたくないので多分ORMとか使って動的SQLを組み立てるほうが楽そう.

おまけ

7月のそとちゃんまとめ(2020)

Mon, 03 Aug 2020 21:03:58 +0900

割とごきげん

7月もそとちゃんは元気だった.

まとめ

ダンボールブーム再来
カリカリ食べない問題
歯みがきの進捗

ダンボールブーム再来

またダンボールが増えた📦

新しいはこも気に入った pic.twitter.com/h5S6t7lLpg
— ずみし (@uzimihsr) July 4, 2020

今まで使ってたAmazonのダンボールより浅くて, フチによっかかったりできるのがお気に入りらしい.

nyamazon pic.twitter.com/SlJKDmv2cn
— ずみし (@uzimihsr) July 2, 2020

あごのっけてるのかわいい pic.twitter.com/GPBwyDkHSb
— ずみし (@uzimihsr) July 6, 2020

夜~朝はだいたいこのダンボールで寝てる.

おはようございます pic.twitter.com/mW6raTOkOT
— ずみし (@uzimihsr) July 9, 2020

昼間はいつも窓際のダンボールベッドで寝てる.
ダンボールに猫用ベッドを詰めただけなんだけどこれもかなりお気に入り.

ごめん寝的ななにか pic.twitter.com/7mm7cqs7yL
— ずみし (@uzimihsr) July 19, 2020

おててまくらにしてる pic.twitter.com/JARBjliSWk
— ずみし (@uzimihsr) July 22, 2020

なんでそんな窮屈な姿勢で寝るの？ pic.twitter.com/wrUa9hyEnZ
— ずみし (@uzimihsr) July 27, 2020

結論: そとちゃんは常に寝ている💤

カリカリ食べない問題

そとちゃんがカリカリ食べない問題が発生した😭

おるすばんのときはカリカリ一粒残らず綺麗に食べるのにしもべが家に居ると全く食べない
猫缶を要求されている pic.twitter.com/4aV7VISHlR
— ずみし (@uzimihsr) July 14, 2020

食欲が無いとか味が気にいらないとかじゃなくて,
俺が家にいる間だけ食べない. どうして😭

朝と昼に自動給餌器でカリカリを出してるんだけど,
俺が寝てる間に出る朝のカリカリはきれいに食べてたり,
昼に出したカリカリでも俺が夕方に出かけて戻ってくると食べてたりする.

直接あげてる晩ごはんの黒缶パウチとかおやつのにぼしは喜んで食べるので,
どうやら俺がいるともっと美味しいウェットフードとかおやつがもらえると思ってるみたい…

カリカリ残しまくってるのにおなかすいたアピールしてくる
ちゃんとごはん食べないとおやつはあげません pic.twitter.com/RajRpJvc3G
— ずみし (@uzimihsr) July 3, 2020

そとちゃんは元々下痢気味で療法食のカリカリを食べさせてるので, ちゃんと食べてくれないと困る…

獣医さんに相談しようか…

歯みがきの進捗

歯みがき苦手問題は少しだけ改善した.

歯みがきシートはあまりにも嫌がるので一旦やめて,
歯みがきジェルを指に塗って直接磨くようにしたらおとなしく触らせてくれるようになった.

匂いを嗅いでも嫌な顔しない.

もうちょっと歯みがきジェルを使って慣れさせてから再度歯みがきシートに挑戦したい.

おわり

そとちゃんは7月も元気だった.

元気だけどもごはんをちゃんとたべなかったりするので,
8月はいろいろ試して改善できるようにしたい.

おまけ

YAMLを使わずにkubectl run/createでサクッとリソースを作る

Wed, 29 Jul 2020 20:43:33 +0900

YAMLめんどくさい

CKAD対策でCKAD-exercisesの問題をやってみたんだけどいちいちYAMLを書くのがめんどくさすぎたのでメモ.

まとめ

kubectl runとkubectl createでだいたいのリソースは作れそう.

# Pod
$ kubectl run nginx --image=nginx --restart=Never

# Deployment
$ kubectl create deployment nginx --image=nginx

# Job
$ kubectl create job busybox --image=busybox -- /bin/sh -c 'date; echo Hello'

# CronJob
$ kubectl create cronjob busybox --image=busybox --schedule="*/10 * * * *" -- /bin/sh -c 'date; echo Hello'

# ConfigMap
$ kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2

# Secret
$ kubectl create secret generic my-secret --from-literal=key1=supersecret --from-literal=key2=topsecret

環境

macOS Mojave 10.14
kubectl v1.14.6
Kubernetes v1.14.10-gke.36

やりかた

Pod

kubectl runのオプションで--restart=NeverをつけてあげるとPodが作成できる.

# nginxのPodを作成
$ kubectl run nginx --image=nginx --restart=Never
pod/nginx created

Podと同時にService(ClusterIP)を作成することもできる.
また, 使い捨てのPodを作成することもできる.
他のPodの疎通確認するときなんかに便利.

# PodとServiceを同時に作成
$ kubectl run nginx --image=nginx --restart=Never --port=80 --expose
service/nginx created
pod/nginx created
$ kubectl get service nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx ClusterIP 10.4.0.85 <none> 80/TCP 14m

# 使い捨てのbusyboxのPodでServiceの疎通確認をする
$ kubectl run busybox --image=busybox --restart=Never --rm -it -- wget -O- 10.4.0.85:80
Connecting to 10.4.0.85:80 (10.4.0.85:80)
writing to stdout
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
written to stdout
pod "busybox" deleted

# 使い捨てのbusyboxのPodを作成してshに入る
$ kubectl run busybox --image=busybox --restart=Never --rm -it -- /bin/sh
/ $ hostname
busybox
/ $ # Ctrl+Dで抜ける
pod "busybox" deleted

実際のPodはつくらずにマニフェストのYAMLだけ生成することもできる.
とりあえず下書きだけでも用意してさらに詳細な設定を書きたいときとかに便利.

# Podは作成せずYAMLだけを表示させる
$ kubectl run nginx --image=nginx --restart=Never --port=80 --env=key1=value1 --limits='cpu=200m,memory=512Mi' --labels=app=v1 -o yaml --dry-run
apiVersion: v1
kind: Pod
metadata:
 creationTimestamp: null
 labels:
 app: v1
 name: nginx
spec:
 containers:
 - env:
 - name: key1
 value: value1
 image: nginx
 name: nginx
 ports:
 - containerPort: 80
 resources:
 limits:
 cpu: 200m
 memory: 512Mi
 dnsPolicy: ClusterFirst
 restartPolicy: Never
status: {}

Deployment

Pod以外のリソースはkubectl createで作れる.
kubectl runでも作れるんだけど, Deprecatedなのであんまり使わないほうがよさそう.
kubectl createだと今の所レプリカ数を指定するオプションがないっぽいのが残念.

# kubectl runでのDeployment作成はDeprecatedらしい
$ kubectl run nginx --image=nginx
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/nginx created

# Deploymentを作成
$ kubectl create deployment nginx --image=nginx
deployment.apps/nginx created

kubectl runと同様に実際のリソース作成はせずYAMLだけ生成することもできる.
こっちのほうが出番が多そう.

# Deploymentを作成せずYAMLを表示させる
$ kubectl create deployment nginx --image=nginx -o yaml --dry-run
apiVersion: apps/v1
kind: Deployment
metadata:
 creationTimestamp: null
 labels:
 app: nginx
 name: nginx
spec:
 replicas: 1
 selector:
 matchLabels:
 app: nginx
 strategy: {}
 template:
 metadata:
 creationTimestamp: null
 labels:
 app: nginx
 spec:
 containers:
 - image: nginx
 name: nginx
 resources: {}
status: {}

CronJob, Job

CronJobとJobもDeploymentと同様に作成できる.

# Jobの作成
$ kubectl create job busybox --image=busybox -- /bin/sh -c 'date; echo Hello'
$ kubectl get pods -l job-name=busybox
NAME READY STATUS RESTARTS AGE
busybox-rvsr9 0/1 Completed 0 34s
$ kubectl logs busybox-rvsr9
Tue Jul 28 14:48:24 UTC 2020
Hello

# CronJobの作成
$ kubectl create cronjob busybox --image=busybox --schedule="*/10 * * * *" -- /bin/sh -c 'date; echo Hello'

また, すでに存在するCronJobからJob部分だけを抜き出して作成することもできる.

# CronJobからJobを作成
$ kubectl create job busybox --from=cronjob/busybox -o yaml --dry-run
apiVersion: batch/v1
kind: Job
metadata:
 annotations:
 cronjob.kubernetes.io/instantiate: manual
 creationTimestamp: null
 name: busybox
spec:
 template:
 metadata:
 creationTimestamp: null
 spec:
 containers:
 - command:
 - /bin/sh
 - -c
 - date; echo Hello
 image: busybox
 imagePullPolicy: Always
 name: busybox
 resources: {}
 terminationMessagePath: /dev/termination-log
 terminationMessagePolicy: File
 dnsPolicy: ClusterFirst
 restartPolicy: OnFailure
 schedulerName: default-scheduler
 securityContext: {}
 terminationGracePeriodSeconds: 30
status: {}

ConfigMap, Secret

ConfigMapやSecretもkubectl createのオプションにKey-Valueの情報を渡して作ることができる.

# ConfigMapの作成
$ kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2
$ kubectl get configmap my-config -o jsonpath={.data.key1}
config1

# Secretの作成
$ kubectl create secret generic my-secret --from-literal=key1=supersecret --from-literal=key2=topsecret
$ kubectl get secret my-secret -o jsonpath={.data.key1} | base64 -D
supersecret

おわり

kubectl run/createでかんたんなリソースが作れることを確認できた. いちいちYAMLを書く必要がないので便利.
さらに--dry-runと-o yamlを使うとYAMLの雛形を生成できるので, 細かい設定を書きたい場合も便利に使えそう.

おまけ

参考

https://github.com/dgkanatsios/CKAD-exercises

Kubernetes完全に理解したい 7章

Sat, 25 Jul 2020 17:57:31 +0900

ConfigMapとかSecretとか

Kubernetes完全ガイドの続き.
ConfigMapとかSecretとか, Podから利用できるリソースの話.

読んだもの

Kubernetes完全ガイド 7章(Config & Storageリソース)

重要そうなところとかよく使いそうなところだけまとめる.

読んだことのまとめ

ConfigMap
Secret
Volume
PersistentVolume
PersistentVolumeClaim

ConfigMap

Podから利用できる情報をKey-Value形式で保持するリソース.
平文ファイル, 直接入力, マニフェストファイル(YAML)の3種類の方法で作成できる.

# 平文ファイルからConfigMapを作成
$ cat config.txt
abc
def
ghi
1234
$ kubectl create configmap --save-config sample-configmap-01 --from-file=./config.txt
configmap/sample-configmap-01 created

# kubectlで値を直接入力してConfigMapを作成
$ kubectl create configmap --save-config web-config \
 --from-literal=connection.max=100 \
 --from-literal=connection.min=10
configmap/web-config created

# マニフェストファイルから作成する
$ kubectl apply -f sample-configmap.yaml
configmap/sample-configmap created

# 値がKey-Value形式で保存されている
$ kubectl get configmap sample-configmap-01 -o json | jq '.data'
{
 "config.txt": "abc\ndef\nghi\n1234\n"
}
$ kubectl get configmap web-config -o json | jq '.data'
{
 "connection.max": "100",
 "connection.min": "10"
}
$ kubectl get configmap sample-configmap -o json | jq '.data'
{
 "connection.max": "100",
 "connection.min": "10",
 "nginx.conf": "user nginx;\nworker_processes auto;\nerror_log /var/log/nginx/error.log;\npid /run/nginx.pid;\n",
 "sample.properties": "property.1=value-1\nproperty.2=value-2\nproperty.3=value-3\n",
 "thread": "16"
}

sample-configmap.yaml

作成したConfigMapはPodから環境変数またはマウントしたファイルとして扱うことができる.

# ConfigMap(sample-configmap)のValue(Key=connection.max)が環境変数CONNECTION_MAXとして利用されている
$ kubectl get pod sample-configmap-single-env -o json | jq '.spec.containers[].env[]'
{
 "name": "CONNECTION_MAX",
 "valueFrom": {
 "configMapKeyRef": {
 "key": "connection.max",
 "name": "sample-configmap"
 }
 }
}
$ kubectl exec -it sample-configmap-single-env env | grep CONNECTION_MAX
CONNECTION_MAX=100

# ConfigMap(sample-configmap)のKey-ValueがVolume(config-volume)として/configにマウントされている
$ kubectl get pod sample-configmap-multi-volume -o json | jq '.spec.volumes[0]'
{
 "configMap": {
 "defaultMode": 420,
 "name": "sample-configmap"
 },
 "name": "config-volume"
}
$ kubectl get pod sample-configmap-multi-volume -o json | jq '.spec.containers[0].volumeMounts[0]'
{
 "mountPath": "/config",
 "name": "config-volume"
}
$ kubectl exec -it sample-configmap-multi-volume ls /config
connection.max	connection.min	nginx.conf sample.properties thread
$ kubectl exec -it sample-configmap-multi-volume cat /config/nginx.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

sample-configmap-single-env.yaml
sample-configmap-multi-volume.yaml

Secret

ConfigMapとは異なり, 秘密情報を扱うためのリソース.
対応するSecretを利用するPodがある場合のみetcdからNodeの一時的な領域(tmpfs)にKey-Valueのデータが送られるようになっているので, ConfigMapに比べて機密性が高い.
また, 安全のためにKey-ValueのValueがbase64エンコードされていて少し見えにくくなっている.

OpaqueタイプのSecretは基本的にConfigMapと同じような使い方ができる.

# 平文ファイルからSecretを作成
$ echo -n "root" > ./username
$ echo -n "rootpassword" > ./password
$ kubectl create secret generic --save-config sample-db-auth-from-file \
 --from-file=./username --from-file=./password
secret/sample-db-auth-from-file created

# envfileからSecretを作成
$ cat << 'EOF' > env-secret.txt
username=root
password=rootpassword
EOF
$ kubectl create secret generic --save-config sample-db-auth-from-env-file \
 --from-env-file ./env-secret.txt
secret/sample-db-auth-from-env-file created

# kubectlで値を直接入力してSecretを作成
$ kubectl create secret generic --save-config sample-db-auth-from-literal \
 --from-literal=username=root --from-literal=password=rootpassword
secret/sample-db-auth-from-literal created

# マニフェストファイルからSecretを作成
$ kubectl apply -f sample-db-auth.yaml
secret/sample-db-auth created

# describeしても見えない
$ kubectl describe secret sample-db-auth-from-literal
Name: sample-db-auth-from-literal
Namespace: default
Labels: <none>
Annotations:
Type: Opaque

Data
====
password: 12 bytes
username: 4 bytes

# 中身はbase64エンコードされている
$ kubectl get secret sample-db-auth-from-literal -o json | jq '.data'
{
 "password": "cm9vdHBhc3N3b3Jk",
 "username": "cm9vdA=="
}
$ kubectl get secret sample-db-auth-from-literal -o json | jq -r '.data.username' | base64 -D
root
$ kubectl get secret sample-db-auth-from-literal -o json | jq -r '.data.password' | base64 -D
rootpassword

sample-db-auth.yaml

IngressなどからTLSに必要な証明書と秘密鍵を扱うためのkubernetes.io/tlsタイプのSecretもある.

# 秘密鍵(tls.key)とオレオレ証明書(tls.crt)を同時に作成
$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
 -keyout ./tls.key -out ./tls.crt -subj "/CN=sample1.example.com"
Generating a 2048 bit RSA private key
......+++
.........................................................................................................................................................................................................+++
writing new private key to './tls.key'
-----
$ ls
tls.crt tls.key

# 秘密鍵と証明書からSecretを作成
$ kubectl create secret tls --save-config tls-sample --key ./tls.key --cert ./tls.crt
secret/tls-sample created

# 秘密鍵と証明書のpemをbase64エンコードしたものが登録されている
$ kubectl get secret tls-sample -o json | jq '.data'
{
 "tls.crt": "LS0tLS...tLS0K",
 "tls.key": "LS0tLS...tLS0K"
}
$ kubectl get secret tls-sample -o json | jq -r .data'["tls.crt"]' | base64 -D | openssl x509 -noout -text
Certificate:
 Data:
 Version: 1 (0x0)
 Serial Number: 12508610311645361173 (0xad9782ce1368f415)
 Signature Algorithm: sha256WithRSAEncryption
 Issuer: CN=sample1.example.com
 Validity
 Not Before: Jul 8 14:54:37 2020 GMT
 Not After : Jul 8 14:54:37 2021 GMT
 Subject: CN=sample1.example.com
 ...

DockerHubのプライベートリポジトリなど, 認証のかかったDockerレジストリからimageを取得するための認証情報を扱う場合はkubernetes.io/dockerconfigjsonタイプのSecretを使用する.
Podから認証がかかったリポジトリのimageをpullするにはマニフェストファイルの.spec.imagePullSecretsにSecret名を指定する(例 : sample-pull-secret.yaml).

# 認証情報からSecretを作成
$ kubectl create secret docker-registry --save-config sample-registry-auth \
 --docker-server=SERVER \
 --docker-username=USER \
 --docker-password=PASSWORD \
 --docker-email=EMAIL
secret/sample-registry-auth created

# dockercfg形式の認証情報が保存されている
$ kubectl get secret sample-registry-auth -o json | jq -r .data'[".dockerconfigjson"]' | base64 -D
{"auths":{"SERVER":{"username":"USER","password":"PASSWORD","email":"EMAIL","auth":"VVNFUjpQQVNTV09SRA=="}}}

作成したSecretはPodから環境変数またはマウントしたファイルとして扱うことができる.

# Secret(sample-db-auth)のValue(Key=username)が環境変数DB_USERNAMEとして利用されている
$ kubectl get pod sample-secret-single-env -o json | jq '.spec.containers[].env[]'
{
 "name": "DB_USERNAME",
 "valueFrom": {
 "secretKeyRef": {
 "key": "username",
 "name": "sample-db-auth"
 }
 }
}
$ kubectl exec -it sample-secret-single-env env | grep DB_USERNAME
DB_USERNAME=root

# Secret(sample-db-auth)のKey-ValueがVolume(config-volume)として/configにマウントされている
$ kubectl get pod sample-secret-multi-volume -o json | jq '.spec.volumes[0]'
{
 "name": "config-volume",
 "secret": {
 "defaultMode": 420,
 "secretName": "sample-db-auth"
 }
}
$ kubectl get pod sample-secret-multi-volume -o json | jq '.spec.containers[].volumeMounts[0]'
{
 "mountPath": "/config",
 "name": "config-volume"
}
$ kubectl exec -it sample-secret-multi-volume ls /config
password username
$ kubectl exec -it sample-secret-multi-volume cat /config/username
root

Volume

Podからディスクを扱うためのリソース.
いくつか種類があるが, どれもPod上に静的に領域を指定して使用する.

emptyDirはPodに一時的なディスク領域を作成し, Podが終了すると同時に削除される.
Pod内の複数のコンテナ間でファイルを共有したりするのに使える.

# emptyDirが /cache にマウントされている
$ kubectl get pod sample-emptydir -o json | jq '.spec.volumes[0]'
{
 "emptyDir": {},
 "name": "cache-volume"
}
$ kubectl get pod sample-emptydir -o json | jq '.spec.containers[0].volumeMounts[0]'
{
 "mountPath": "/cache",
 "name": "cache-volume"
}
# 中身は空
$ kubectl exec -it sample-emptydir -- ls -la /cache
total 8
drwxrwxrwx 2 root root 4096 Jul 9 14:26 .
drwxr-xr-x 1 root root 4096 Jul 9 14:26 ..

sample-emptydir.yaml

hostPathはNode上の領域を指定してPodのコンテナにマウントする.
Nodeに直接影響を与えるので扱いには注意が必要.

# Node(gke-k8s-01-pool-2-641104a4-7r06)の /etc が /srv としてPodにマウントされている
$ kubectl get pod sample-hostpath -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
sample-hostpath 1/1 Running 0 3m22s 10.0.1.5 gke-k8s-01-pool-2-641104a4-7r06 <none> <none>
$ kubectl get pod sample-hostpath -o json | jq '.spec.volumes[0]'
{
 "hostPath": {
 "path": "/etc",
 "type": "DirectoryOrCreate"
 },
 "name": "hostpath-sample"
}
$ kubectl get pod sample-hostpath -o json | jq '.spec.containers[0].volumeMounts[0]'
{
 "mountPath": "/srv",
 "name": "hostpath-sample"
}

# マウントしたNodeの領域にアクセスする
$ kubectl exec -it sample-hostpath cat /srv/os-release | grep PRETTY_NAME
PRETTY_NAME="Container-Optimized OS from Google" # NodeのOS
# コンテナ自体の領域にアクセスする
$ kubectl exec -it sample-hostpath cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Debian GNU/Linux 9 (stretch)" # コンテナのOS
# 実際にNodeの同じ領域のファイルを確認する
$ gcloud compute ssh gke-k8s-01-pool-2-641104a4-7r06
gke-k8s-01-pool-2-641104a4-7r06 ~ $ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Container-Optimized OS from Google"

sample-hostpath.yaml

downwardAPIはPodの情報をPod上の領域にファイルとして配置する.

# /srv/podnameと/srv/cpu-requestにmetadata.nameとrequests.cpuの値がファイルとして配置されている
$ kubectl get pod sample-downward-api -o json | jq '.spec.volumes[0]'
{
 "downwardAPI": {
 "defaultMode": 420,
 "items": [
 {
 "fieldRef": {
 "apiVersion": "v1",
 "fieldPath": "metadata.name"
 },
 "path": "podname"
 },
 {
 "path": "cpu-request",
 "resourceFieldRef": {
 "containerName": "nginx-container",
 "divisor": "0",
 "resource": "requests.cpu"
 }
 }
 ]
 },
 "name": "downward-api-volume"
}
$ kubectl get pod sample-downward-api -o json | jq '.spec.containers[0].volumeMounts[0]'
{
 "mountPath": "/srv",
 "name": "downward-api-volume"
}

# ファイルを確認する
$ kubectl exec -it sample-downward-api cat /srv/podname
sample-downward-api
$ kubectl exec -it sample-downward-api cat /srv/cpu-request
1

sample-downward-api.yaml

projectedは複数のVolume, Secret, ConfigMapなどを1つのvolumeMountsにまとめる.

# Secret(sample-db-auth), ConfigMap(sample-configmap), downwardAPIが /srv にまとめてマウントされている
$ kubectl get secret sample-db-auth
NAME TYPE DATA AGE
sample-db-auth Opaque 2 24h
$ kubectl get configmap sample-configmap
NAME DATA AGE
sample-configmap 5 12d
$ kubectl get pod sample-projected -o yaml | yq read - 'spec.volumes[0]'
name: projected-volume
projected:
 defaultMode: 420
 sources:
 - secret:
 items:
 - key: username
 path: secret/username.txt
 name: sample-db-auth
 - configMap:
 items:
 - key: nginx.conf
 path: configmap/nginx.conf
 name: sample-configmap
 - downwardAPI:
 items:
 - fieldRef:
 apiVersion: v1
 fieldPath: metadata.name
 path: podname
$ kubectl get pod sample-projected -o yaml | yq read - 'spec.containers[0].volumeMounts[0]'
mountPath: /srv
name: projected-volume

# 中身を確認
$ kubectl exec -it sample-projected ls /srv
configmap podname secret
$ kubectl exec -it sample-projected cat /srv/secret/username.txt
root
$ kubectl exec -it sample-projected cat /srv/configmap/nginx.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
$ kubectl exec -it sample-projected cat /srv/podname
sample-projected

sample-projected.yaml

PersistentVolume

永続化領域を扱うためのVolumeで, 個別のリソースとして扱う.
ネットワーク経由でPod等から利用するため, アクセス可能な場所にディスクを用意する必要がある.
(Ingressみたいな感じ?)

# GCPでディスクを作成
$ gcloud compute disks create --size=10GB sample-gce-pv --zone us-central1-a
NAME ZONE SIZE_GB TYPE STATUS
sample-gce-pv us-central1-a 10 pd-standard READY

# PersistentVolume(sample-pv)を作成
$ kubectl apply -f sample-pv.yaml
persistentvolume/sample-pv created
$ kubectl get pv sample-pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
sample-pv 10Gi RWO Retain Available manual 56s

sample-pv.yaml

PersistentVolumeClaim

Pod等から利用できるPersistentVolumeを払い出すためのリソース.
クラスタが認識しているPersistentVolumeの中でPersistentVolumeClaimの条件に合ったものがPodに接続される.

# PersistentVolume(sample-pv)が存在する状態でPersistentVolumeClaim(sample-pvc)を作成
$ kubectl apply -f sample-pvc.yaml
persistentvolumeclaim/sample-pvc created
$ kubectl get pvc sample-pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
sample-pvc Bound sample-pv 10Gi RWO manual 26s

# PersistentVolume(sample-pv)がsample-pvcに確保(Bound)されている
$ kubectl get pv sample-pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
sample-pv 10Gi RWO Retain Bound default/sample-pvc manual 111s

# Podの/usr/share/nginx/htmlにsample-pvcで払い出されたPersistentVolumeがマウントされている
$ kubectl get pod sample-pvc-pod -o yaml | yq read - 'spec.volumes[0]'
name: nginx-pvc
persistentVolumeClaim:
 claimName: sample-pvc
$ kubectl get pod sample-pvc-pod -o yaml | yq read - 'spec.containers[0].volumeMounts[0]'
mountPath: /usr/share/nginx/html
name: nginx-pvc

sample-pvc.yaml
sample-pvc-pod.yaml

また, StorageClassの設定によっては,
事前にPersistentVolumeを用意しなくてもPersistentVolumeClaimに応じたPersistentVolumeを自動で払い出すことができる(Dynamic Provisioning).

# GKEのデフォルトStorageClass
$ kubectl describe sc standard
Name: standard
IsDefaultClass: Yes
Annotations: storageclass.kubernetes.io/is-default-class=true
Provisioner: kubernetes.io/gce-pd
Parameters: type=pd-standard
AllowVolumeExpansion: True
MountOptions: <none>
ReclaimPolicy: Delete
VolumeBindingMode: Immediate
Events: <none>

# PersistentVolumeがない状態でStorageClassを指定しないPersistentVolumeClaimを作成する
$ kubectl get pv
No resources found.
$ kubectl apply -f sample-pvc-default-storageclass.yaml
persistentvolumeclaim/sample-pvc created

# GCPのディスクとPersistentVolumeが自動で払い出されている
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-332c4de9-ce56-11ea-a3f9-42010a80005d 4Gi RWO Delete Bound default/sample-pvc standard 69s
$ gcloud compute disks list
NAME LOCATION LOCATION_SCOPE SIZE_GB TYPE STATUS
gke-k8s-01-08fea67e-dy-pvc-332c4de9-ce56-11ea-a3f9-42010a80005d us-central1-a zone 4 pd-standard READY

# 使用したPersistentVolumeClaimはsample-pvc.yamlを改変したもの
$ cat sample-pvc-default-storageclass.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
 name: sample-pvc
spec:
 resources:
 requests:
 storage: 4Gi
 accessModes:
 - ReadWriteOnce

おまけ

GoでサイコロAPIを作る

Thu, 23 Jul 2020 14:10:10 +0900

Web APIつくってみる

Web APIを自分で最初から作ったことがなかったので, Goの練習も兼ねてやってみた.

やったことのまとめ

以下のようにランダムなサイコロの出目(number)とサイコロの面の数(faces)をJSONで返すだけのWeb APIをGoで作った.

# 普通に叩くと6面サイコロを振る
$ curl -X GET "localhost:8080"
{"number":1,"faces":6}
$ curl -X GET "localhost:8080"
{"number":5,"faces":6}

# クエリパラメータで面の数を指定できる
$ curl -X GET "localhost:8080?faces=100"
{"number":71,"faces":100}

# ズルをするためのエンドポイントも用意
$ curl -X GET "localhost:8080/cheat"
{"number":6,"faces":6}
$ curl -X GET "localhost:8080/cheat?faces=100&number=99"
{"number":99,"faces":100}

つかうもの

macOS Mojave 10.14
anyenv 1.1.1
- インストール済み
goenv 2.0.0beta11
- インストール済み
go version go1.14.6 darwin/amd64
- 今回入れる

やったこと

準備
サイコロの作成
HTTPハンドラの作成
テストの作成

準備

まずは開発環境の準備.

公式によると現在(2020/07/16)Goの最新版が 1.14.6 なので, これを使うようにする.

# goenvの更新
$ anyenv install goenv
anyenv: /Users/uzimihsr/.anyenv/envs/goenv already exists
Reinstallation keeps versions directories
continue with installation? (y/N) y
...

Install goenv succeeded!
Please reload your profile (exec $SHELL -l) or open a new session.
$ exec $SHELL -l

# Go 1.14.6のインストール
$ cd
$ goenv install 1.14.6
$ goenv global 1.14.6
$ goenv rehash
$ exec $SHELL -l

# 確認
$ goenv version
1.14.6 (set by /Users/uzimihsr/.anyenv/envs/goenv/version)
$ go version
go version go1.14.6 darwin/amd64
$ echo $GOPATH
/Users/uzimihsr/go/1.14.6

次にGitHubリポジトリを新規作成する.

作ったリポジトリ : https://github.com/uzimihsr/dice-api

作成したリポジトリをローカルにcloneして, Go Modulesとか.gitignoreの準備をする.
Go Modulesの使い方は公式を参考にする.
.gitignoreはgitignore.ioを使って作るのが楽.

# 適当なディレクトリで作業
$ cd workspace
$ git clone https://github.com/uzimihsr/dice-api.git
Cloning into 'dice-api'...
warning: You appear to have cloned an empty repository.
$ cd dice-api

# Go Moduleの初期化
$ go mod init github.com/uzimihsr/dice-api
go: creating new go.mod: module github.com/uzimihsr/dice-api
$ ls
go.mod

# gitignore.ioのAPIを利用して.gitignoreを作成する
$ curl -o ./.gitignore https://www.toptal.com/developers/gitignore/api/go,macos,linux

# いったんpushしておく
$ echo "# dice-api" > README.md
$ git add .
$ git commit -m "first commit"
$ git push origin master

このときのリポジトリはこんなかんじ.

サイコロの作成

まずはサイコロの動作を作ってみる.
以前作ったものを流用する.

$ mkdir dice && cd dice
$ vim dice.go

今回は普通にサイコロの出目を返すメソッドRoll()の他に指定した出目を返すCheat()を作ってみた.

ためしに動かしてみる.

$ cd ..
$ vim main.go
$ go run main.go
6
5
$ go run main.go
1
5

いい感じ.

HTTPハンドラの作成

次にこれをWeb APIとして動かすためのハンドラ関数を作る.

$ mkdir handler && cd handler
$ vim handler.go

ポイントはハンドラ関数DiceHandler(), CheatDiceHandler()の引数でinterfaceを受けるようにしているところ.
こうしておくと後でテストを書くときにmockを使いやすくなる.

これらのハンドラ関数を扱ってHTTPサーバーを動かすため, main.goを修正する.

$ cd ..
$ vim main.go
$ go run main.go
# 動作を確認したら Ctrl+C で終了

こちらはhttp.NewServeMux()を使ってリクエストパスごとに異なるハンドラを呼び出すようにしているのがポイント.

main.goを実行するとMacの警告が出るので, 許可を選択するとアプリが動く.

試しに別のターミナルからAPIを叩いてみる.

# 正常系
$ curl "localhost:8080"
{"number":1,"faces":6}
$ curl "localhost:8080?faces=12"
{"number":10,"faces":12}
$ curl "localhost:8080/cheat"
{"number":6,"faces":6}
$ curl "localhost:8080/cheat?number=1"
{"number":1,"faces":6}
$ curl "localhost:8080/cheat?number=1&faces=18"
{"number":1,"faces":18}

# 異常系
$ curl -i -X POST "localhost:8080"
HTTP/1.1 404 Not Found
Content-Type: application/json
Date: Thu, 23 Jul 2020 08:12:39 GMT
Content-Length: 24

{"message": "not found"}
$ curl -i -X GET "localhost:8080?faces=hoge"
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Thu, 23 Jul 2020 08:13:04 GMT
Content-Length: 45

strconv.Atoi: parsing "hoge": invalid syntax
$ curl -i -X POST "localhost:8080/cheat"
HTTP/1.1 404 Not Found
Content-Type: application/json
Date: Thu, 23 Jul 2020 08:13:58 GMT
Content-Length: 24

{"message": "not found"}
$ curl -i -X GET "localhost:8080/cheat?number=hoge"
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Thu, 23 Jul 2020 08:14:12 GMT
Content-Length: 45

strconv.Atoi: parsing "hoge": invalid syntax

サイコロの出目(number)と面の数(faces)がJSONで返ってきて,
異常なクエリパラメータやHTTPメソッドでリクエストした場合には指定したステータスコード(404, 500)が返ってくることが確認できた.
やったぜ.

このときのリポジトリはこんなかんじ.

テストの作成

作りたいものは作れたのでここで終わってもいいけど, せっかくなのでテストコードを書いてみる.

まずはdiceパッケージから.

$ cd ./dice
$ vim dice_test.go

カバレッジ100%になるように書いたけど, 無駄なテストも含まれている.

次にhandlerパッケージのテストを作る.
handlerパッケージは自作のdiceパッケージに依存しているので, diceパッケージのmockを用意したい.
(今回はDBとかに接続してないのでdiceを直接呼び出してもいいんだけど, サイコロの出目が確率で変わっちゃうのでテストがしづらい)

こんなときにはgomockを使う.
mockしたいinterfaceのファイルを指定するだけでmock用のコードを作成してくれるのでめちゃ便利.

# mockパッケージのインストール
$ cd ..
$ go get github.com/golang/mock/mockgen

# diceのmockを作成
$ mockgen -source ./dice/dice.go -destination ./mock_dice/mock_dice.go

このmockを使ったテストを書いてみる.

$ cd handler
$ vim handler_test.go

準備したmockを各ハンドラ関数の引数に渡してやることで, 実際のdiceを呼び出すことなくハンドラ関数のテストができるようになる.
ハンドラ関数を作るときにdiceのinterfaceを引数で受けるようにしたのはこのため.

テストコードが作れたので, 実際にテストを実行する.

$ cd ..
# diceパッケージのテスト
$ go test -cover ./dice
ok 	github.com/uzimihsr/dice-api/dice	0.006s	coverage: 100.0% of statements
# handlerパッケージのテスト
$ go test -cover ./handler
ok 	github.com/uzimihsr/dice-api/handler	0.016s	coverage: 100.0% of statements
# 全部まとめてテスト
$ go test -cover ./...
? 	github.com/uzimihsr/dice-api	[no test files]
ok 	github.com/uzimihsr/dice-api/dice	(cached)	coverage: 100.0% of statements
ok 	github.com/uzimihsr/dice-api/handler	(cached)	coverage: 100.0% of statements
? 	github.com/uzimihsr/dice-api/mock_dice	[no test files]

これでテストも(一応)できた.

最終的なディレクトリの構成はこんなかんじ.
テストを実行したのでパッケージの依存関係を管理するためのファイルgo.modとgo.sumが修正/追加されている.
こいつらも一緒にGitで管理しておくと, 別の環境でこれをビルドするときに便利だったりする. らしい.

$ tree .
.
├── README.md
├── dice
│   ├── dice.go
│   └── dice_test.go
├── go.mod
├── go.sum
├── handler
│   ├── handler.go
│   └── handler_test.go
├── main.go
└── mock_dice
 └── mock_dice.go

3 directories, 9 files

最終的なリポジトリはこんなかんじ.

おわり

Web APIっぽいものを0から作ってみた. テストまでやったのでけっこうしんどかった.
あとはビルドすれば普通に動くはずなので,
暇があったらKubernetesで動かすところまでやってみたい.

おまけ

参考にしたもの

Prometheusで不要なメトリクスを除外する

Tue, 14 Jul 2020 22:49:32 +0900

いらないメトリクスは拾いたくない

Prometheusでスクレイプする対象にいらないメトリクスがあったときに無視したかった.

まとめ

特定のメトリクスだけ除外したいときはmetric_relabel_configsで除外したいメトリクスのラベルを正規表現で記述してdropするのが良さそう.

# メトリクス名がnode_cpu_seconds_totalでmode="idle"のラベルを持つメトリクスを除外する例
scrape_configs:
 - job_name: 'node'
 static_configs:
 - targets: ['localhost:9100']
 metric_relabel_configs:
 - source_labels: [__name__, mode]
 regex: 'node_cpu_seconds_total;idle'
 action: drop

環境

Raspberry Pi 3 Model B+
- OSはRaspbian(10.0)
- 監視サーバとして使用
Prometheus version 2.15.2
- インストール済み
Node exporter version 0.18.1
- インストール済み

やりかた

例えばNode exporterで取れるCPU時間のメトリクスnode_cpu_seconds_totalをPrometheusで見ているとき,
普通はこんな感じでmodeラベルの値が異なる複数のメトリクスが取れる.

node_cpu_seconds_total{cpu="0"}

メトリクスの用途はさておき, この中でmode="idle"のラベルがついているメトリクスだけを除外したいとする.

そんなときはPrometheusのスクレイプ設定でmetric_relabel_configsの設定を追加する.
この設定により, __name__ラベル(メトリクス名)がnode_cpu_seconds_totalかつmodeラベルがidleであるメトリクスだけが除外(drop)される.

設定変更後, Prometheusを再起動する.

# prometheusのスクレイプ設定を変更して再起動
$ vim /usr/local/prometheus/prometheus.yml
$ sudo systemctl restart prometheus

再度Prometheusで先程と同じクエリを投げると, mode="idle"のラベルがついたメトリクスだけがなくなっていることがわかる.

今度は逆にmode="idle"のラベルがついているメトリクスだけを残して, 他のメトリクスを拾わないようにしてみる.
この設定により, __name__="node_cpu_seconds_total"とmode="idle"の両方のラベルを持つメトリクスのみが保持(keep)され,
それ以外のメトリクスがすべて除外される.

これでも問題なさそうだけど, 実はこの設定を入れるとメトリクス名(__name__)がnode_cpu_seconds_totalでないメトリクスがすべて捨てられてしまうので,
node_filesystem_free_bytes(ファイルシステムの空き容量)のようなNode exporterの他のメトリクスが取れなくなってしまう.

うまいこと__name__="node_cpu_seconds_total"かつmode!="idle"のような条件を正規表現で書ければいいんだけど,
Prometheusで使うRE2正規表現は(?!idle)みたいな否定先読みに対応していないらしいのでちょっと難しい.

よくわかんなかったので苦肉の策として除外したい個別のラベルを列挙してみた.

これなら__name__="node_filesystem_free_bytes"のような他のメトリクスを捨てずに__name__="node_cpu_seconds_total"のメトリクスの中でmode="idle"なものだけを残せるけど,
除外するラベルを全部列挙するのはあんまり現実的じゃないような気がする…

おわり

正規表現にマッチするメトリクスだけ除外するdropとその逆のkeepだと本当は除外対象を列挙しないで済むkeepを使いたくなるけど,
現状は正規表現の仕様でdropのほうが使いやすいという感じがする.
そもそもそこまで排除対象のメトリクスが多いようなスクレイプ対象だったらそれ自体を見直したほうがいいのだろうか.

とりあえずはdropで頑張ってみて, keepでいい感じに他のメトリクスを残せるような方法があったら試してみたい.

おまけ

参考

yq(v3)でKubernetesのYAMLをいじる

Mon, 06 Jul 2020 17:58:37 +0900

[注意]この記事の執筆時点ではyq version3系を使用していたため、コマンド例にversion4系で使用できないオプションが含まれています。
→yq(v4)でKubernetesのYAMLをいじる

yqすごい

yqでKubernetesのYAMLから値を抽出したり値を書き換えたりした.

まとめ

yqはべんり.

# YAMLの値(key=spec.containers[0].image)を抽出
$ yq read 'pod.yaml' 'spec.containers[0].image'

# 正規表現でimageとtagを抜き出す
$ yq read 'pod.yaml' 'spec.containers[0].image' | grep -o '^[^:]\+'
$ yq read 'pod.yaml' 'spec.containers[0].image' | grep -o '[^:]\+$'

# YAMLの値(key=spec.containers[0].image)を上書き
$ yq write -i 'pod.yaml' 'spec.containers[0].image' 'nginx:1.19.0'

環境

macOS Mojave 10.14
yq version 3.3.2

やりかた

こんな感じのKubernetesのマニフェストファイル(YAML)を扱っていたときに,
使用しているimage(nginx)のtagが latest だったのを 1.19.0 みたいなimageのdigestが一意に定まるようなバージョンごとのtagに変更したくなった.

pod.yaml

手で直接編集するのもいいんだけど,
ゆくゆくは自動化したりしたいのでyqを使ってスクリプトを書いてみる.

image-tag-fix.sh

作成したスクリプトを実行する.

$ ls
image-tag-fix.sh pod.yaml

# タグ置換スクリプト実行
$ chmod +x ./image-tag-fix.sh
$ ./image-tag-fix.sh
image : nginx
tag : latest
replaced: nginx:latest => nginx:1.19.0

# 内容確認
$ cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
 name: nginx-pod
spec:
 containers:
 - name: nginx
 image: nginx:1.19.0

いい感じ.
yqを使ってYAMLの値を書き換えることができた.

おわり

yqはjqみたいな感じでYAMLを扱えるのでかなり便利.
うまく使いこなせるようになりたい.

おまけ

参考

https://github.com/mikefarah/yq/blob/master/README.md

6月のそとちゃんまとめ(2020)

Wed, 01 Jul 2020 22:33:16 +0900

じめじめするけど

6月もそとちゃんは元気だった.

まとめ

おもちゃがたくさん
ねこがおちている
はみがきできない

おもちゃがたくさん

先月はあまり遊んであげられなかったので,
今月はおもちゃでたくさん遊んであげた.

ペットショップ行けたのでバチクソおもちゃ買ってあげた(失くしたねずみのおもちゃ含む) pic.twitter.com/k4CZJNWD8r
— ずみし (@uzimihsr) June 2, 2020

特に小さいねずみのおもちゃが最近のお気に入りらしい.
箱の中に入れるとずっといじって遊んでる.

ねずみの入った箱に夢中 pic.twitter.com/Za5H5Iy7Ym
— ずみし (@uzimihsr) June 4, 2020

頭突っ込んでるのかわいい pic.twitter.com/MtEJgOL3Go
— ずみし (@uzimihsr) June 4, 2020

この大玉のおもちゃはそんなに食いつかなかった…
自分で持ち上げられるくらいの軽さのおもちゃが好きみたい.

あたらしいおもちゃ pic.twitter.com/EqbMGAtRMg
— ずみし (@uzimihsr) June 26, 2020

運動量を増やそうとしてねこじゃらしのレベルを上げるとすぐ諦めちゃうのがかわいかった.

今月買ったおもちゃたちの現在.
じゃらしは3/5が破壊, ねずみは4つ出して2つが行方不明…
遊び方が激しすぎませんかね…

ねこがおちている

梅雨でじめじめしているのと関係があるかはわからないけど,
家にねこがおちていることが多くなった.

人間のベッドにねこが落ちてた pic.twitter.com/EtDdIRFwrY
— ずみし (@uzimihsr) June 7, 2020

バテた pic.twitter.com/JbcVqTDykU
— ずみし (@uzimihsr) June 8, 2020

元気がないわけじゃないのでそこまで気にしてないけど,
あんまりひなたぼっこできないから退屈なのかもしれない.

朝 pic.twitter.com/DwSURYPUcd
— ずみし (@uzimihsr) June 18, 2020

のびる pic.twitter.com/XQTgzSD7T4
— ずみし (@uzimihsr) June 25, 2020

あとは単純に遊びすぎて疲れてる説もある.
溶けてるみたいでかわいい.

はみがきできない

将来のためにはみがきの練習を始めたんだけど, めちゃくちゃ嫌いみたい…

はみがきシートの匂いを嗅ぐだけで嫌な顔する.

大好物のにぼしで釣ってなんとか歯には触らせてくれるようにはなったけど,
終わった後はいつもいじける.

おやつで釣られて歯みがきさせられたからもう何も信じたくなくなったねこ(日課) pic.twitter.com/eaWzS1wXge
— ずみし (@uzimihsr) June 17, 2020

↓の動画を参考にちょっとずつやってるけど,
成猫になってからなのでなかなか慣れてくれない.

こればかりは気長に頑張るしかないのかもしれない…

しもべはこんなにそとちゃんの健康を考えているのに,
そとちゃんはお手入れのたびにしもべのことが嫌いになっていく. かなしい😭

おわり

そとちゃんは6月も元気だった.

ひなたぼっこできないのはかわいそうなので, はやく梅雨明けしてほしい.

はみがきできるようになる日は来るのか…?

おまけ

awkコマンドを使って文字列の先頭と末尾を削除する

Mon, 29 Jun 2020 21:19:05 +0900

awkすき

Shellで文字列を扱うときにちょっとだけ困ったのでメモ.

まとめ

substr()とlength()を使う.

# 先頭から1文字削除
$ echo 'abcdefghijkl' | awk '{print substr($0, 2)}'
bcdefghijkl

# 末尾から1文字削除
$ echo 'abcdefghijkl' | awk '{print substr($0, 1, length($0)-1)}'
abcdefghijk

# 先頭と末尾から1文字ずつ削除
$ echo 'abcdefghijkl' | awk '{print substr($0, 2, length($0)-2)}'
bcdefghijk

環境

macOS Mojave 10.14
awk version 20070501

やりかた

substr(string, start, length)は文字列(string)の頭n文字目(start)からm文字(length)を抜き出して表示する.
引数のlengthは省略可能で, 省略した場合は文末まで表示される.

# qwerty の2文字目(w)から末尾まで抽出
$ awk 'BEGIN {print substr("qwerty", 2)}'
werty

# qwerty の2文字目(w)から4文字ぶんを抽出
$ awk 'BEGIN {print substr("qwerty", 2, 4)}'
wert

先頭から文字を抜き出せたが, 末尾から文字を抜き出したい場合もある.
length(string)は文字列(string)の文字数を数えてくれるので, これとsubstr()を組み合わせてみる.

# qwertyの文字数は6
$ awk 'BEGIN {print length("qwerty")}'
6

# qwerty の1文字目(q)から(length-1=5)文字ぶんを抽出
$ awk 'BEGIN {print substr("qwerty", 1, length("qwerty")-1)}'
qwert

あとはパイプでつないでいい感じにすればいい.

# ダブルクォート("")で囲まれた文字列("qwerty")から文字列(qwerty)のみを抽出
$ echo '"qwerty"' | awk '{print substr($0, 2, length($0)-2)}'
qwerty

やったぜ.

おわり

やっぱりawkは神.
もっと使いこなしていきたい.

おまけ

参考

https://www.gnu.org/software/gawk/manual/html_node/String-Functions.html

nginxとOpenSSLでクライアント認証を行う

Fri, 26 Jun 2020 23:32:10 +0900

特定の人だけ許可したい

サーバー証明書のしくみを学んだので, 今度はクライアント認証のしくみを作ってみる.

やったことのまとめ

認証局を立ててクライアント証明書を作成した
nginxでクライアント認証の設定をした
MacからcurlとChromeでクライアント認証のかかったnginxに接続した

サーバー証明書がサーバーの正当性を証明してクライアントがサーバーを信頼するためのものであるのに対し,
クライアント証明書はその逆でクライアントの正当性を証明してサーバーがクライアントを信頼するためのもの.

不特定多数の相手に公開したくないサーバーにクライアント認証をかけることで,
有効なクライアント証明書を持つ特定の相手だけにこれを公開することができる.

つかうもの

Raspberry Pi 3 Model B+
- OSはRaspbian(10.0)
- SSLサーバーとして使用
- IP固定済み
OpenSSL
- OpenSSL 1.1.1c 28 May 2019
- ラズパイの初期装備
nginx
- version 1.14.2
- ラズパイにインストール済み
macOS Mojave 10.14
- クライアントとして使用
Google Chrome
- バージョン: 83.0.4103.61（Official Build）（64 ビット）

やったこと

クライアント証明書の作成
nginxの設定
クライアント証明書を用いた接続

クライアント証明書の作成

まずはクライアント証明書を作成する.
といっても途中までの手順はサーバー証明書を作成したときとほとんど同じ.

まずはオレオレ認証局を建てる.

## 以下すべてラズパイで実行
# オレオレ認証局用ディレクトリ(ClientCA)で作業
$ mkdir ClientCA && cd ClientCA

# 認証局用の秘密鍵(ClientCA-private-key.pem)を作成
$ openssl genpkey -algorithm RSA -out ClientCA-private-key.pem

# 認証局の秘密鍵(ClientCA-private-key.pem)を使ったオレオレ証明書(ClientCA.pem)の作成
$ openssl req -x509 -key ClientCA-private-key.pem -out ClientCA.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:ClientCA
Email Address []:

# 署名のための準備
$ mkdir -p demoCA/newcerts
$ touch ./demoCA/index.txt
$ echo 01 > ./demoCA/serial

次にクライアント証明書用の秘密鍵と証明書署名要求(CSR)を作成する.

# クライアント用ディレクトリ(Client)で作業
$ cd ../
$ mkdir Client && cd Client

# クライアント用の秘密鍵(Client-private-key.pem)を作成
$ openssl genpkey -algorithm RSA -out Client-private-key.pem

# クライアントの秘密鍵(Client-private-key.pem)からCSR(Client-csr.pem)を作成
$ openssl req -new -key Client-private-key.pem -out Client-csr.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:Client
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

次はクライアントのCSRを認証局で署名してクライアント証明書を作成する.
これによりこの証明書を持つクライアントの正当性を認証局(ClientCA)が証明したことになる.

# クライアントのCSR(Client-csr.pem)を認証局(ClientCA)に渡す
$ cp Client-csr.pem ../ClientCA/

# 認証局の秘密鍵(ClientCA-private-key.pem)と証明書(ClientCA.pem)で
# クライアントのCSR(Client-csr.pem)に署名してクライアント証明書(Client.pem)を作成
$ cd ../ClientCA
$ openssl ca -in Client-csr.pem -out Client.pem -keyfile ClientCA-private-key.pem -cert ClientCA.pem
Using configuration from /usr/lib/ssl/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
 Serial Number: 1 (0x1)
 Validity
 Not Before: Jun 24 14:02:29 2020 GMT
 Not After : Jun 24 14:02:29 2021 GMT
 Subject:
 countryName = AU
 stateOrProvinceName = Some-State
 organizationName = Internet Widgits Pty Ltd
 commonName = Client
 X509v3 extensions:
 X509v3 Basic Constraints:
 CA:FALSE
 Netscape Comment:
 OpenSSL Generated Certificate
 X509v3 Subject Key Identifier:
 13:E6:B2:5D:88:06:CC:2C:17:BE:AA:98:92:B2:09:C3:BF:D4:AA:A4
 X509v3 Authority Key Identifier:
 keyid:9C:C0:54:1F:93:4C:F1:F9:0A:6D:2B:AF:8E:B0:80:54:F1:2A:EC:F3

Certificate is to be certified until Jun 24 14:02:29 2021 GMT (365 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

# クライアントに証明書(Client.pem)を渡す
$ mv ./Client.pem ../Client/

さいごにクライアントの秘密鍵と証明書をくっつけてPKCS#12形式に変換する.
なんかしらんけどクライアント認証で使うときに一番メジャーなフォーマットらしい.

# 証明書(Client.pem)と秘密鍵(Client-private-key.pem)からPKCS#12形式のファイル(Client.p12)を作成
$ cd ../Client/
$ openssl pkcs12 -export -clcerts -in Client.pem -inkey Client-private-key.pem -out Client.p12
Enter Export Password: # 任意のパスワードを設定する
Verifying - Enter Export Password: # 再度パスワードを入力

以上の手順でクライアント証明書と秘密鍵をあわせたPKCS#12形式ファイルが作成できた.
これでクライアント側の準備は完了.

nginxの設定

次にnginxでクライアント認証の設定を行う.

まずはクライアント証明書を発行した認証局の証明書をnginx用のディレクトリに配置する.

# CA証明書(ClientCA.pem)をnginx用ディレクトリに配置
$ cd ..
$ sudo cp ClientCA/ClientCA.pem /etc/nginx/
$ ls /etc/nginx/ClientCA.pem
/etc/nginx/ClientCA.pem

次にnginxの設定を変更して再起動する.

# nginxの設定ファイル(https.conf)を編集
$ sudo vim /etc/nginx/conf.d/https.conf

# nginx再起動
$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo systemctl restart nginx

今回変更した部分以外(サーバー証明書など)は前回と全く同じ状態.

これでnginxにはクライアント認証がかかり,
信頼しているCA証明書(ClientCA.pem)の認証局によって署名されたクライアント証明書を持つ相手のみを信頼して内容を公開するようになった.

クライアント証明書を用いた接続

サーバー(nginx)側の設定が終わったので, 試しにMacからnginxに接続してみる.

なにもしない状態でcurlで https://<ラズパイのIP>/ をたたくとクライアント証明書がないので怒られる.

## 以下はすべてMacから実行

# nginx(ラズパイ)にcurlしてみる
# nginxの持ってるサーバーの証明書が信頼できないものなので --insecure をつけて実行する
$ curl https://raspberrypi --insecure
<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
<hr><center>nginx/1.14.2</center>
</body>
</html>
# クライアント証明書がないので怒られる

次にMacにPKCS#12形式のクライアント証明書をもたせた状態で接続してみる.
今度はnginx側が持つCA証明書とMacが持つクライアント証明書の照合が行われ,
問題がなければクライアント認証を突破できる.

# ラズパイからMacにPKCS#12のクライアント証明書を持ってくる
$ scp pi@raspberrypi://path/to/Client/Client.p12 ./

# PKCS#12形式のファイル(Client.p12)からクライアント証明書(Client.pem)を取り出す
$ openssl pkcs12 -in ./Client.p12 -out Client.pem -clcerts -nokeys
Enter Import Password: # pkcs12作成時に設定したパスワードを入力
MAC verified OK

# PKCS#12形式のファイル(Client.p12)からクライアント秘密鍵(Client-private-key.pem)を取り出す
# 秘密鍵にパスフレーズをつけていないので -nodes をつける
$ openssl pkcs12 -in ./Client.p12 -out Client-private-key.pem -nocerts -nodes
Enter Import Password: # pkcs12作成時に設定したパスワードを入力
MAC verified OK

# クライアントの証明書(Client.pem)と秘密鍵(Client-private-key.pem)をもたせた状態でcurlしてみると認証に成功してHTMLが表示される
$ curl --key ./Client-private-key.pem --cert ./Client.pem https://raspberrypi --insecure
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
 body {
 width: 35em;
 margin: 0 auto;
 font-family: Tahoma, Verdana, Arial, sans-serif;
 }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

ついでにブラウザでも試してみる.

何もしない状態で https://<ラズパイのIP>/ をChromeで開くと証明書がないから怒られる.

Macにクライアント証明書をもたせてみる.
先程ラズパイから持ってきたPKCS#12のファイルをダブルクリックする.

パスワードを求められるのでPKCS#12の作成時に設定したパスワードを入力する.

キーチェーンアクセスが開くので, この画面でPKCS#12ファイルをダブルクリック.

詳細画面が開くので, 信頼->この証明書を信頼するときを常に信頼に変更してウィンドウを閉じる.
これでMacがこのクライアント証明書を使えるようになった.

再度 https://<ラズパイのIP>/ をChromeで開く.
今度はこのサーバー(nginx)のクライアント認証に使用するクライアント証明書を選択する画面が開くので, OK を選択する.
これでChromeがクライアント証明書を持ってnginxにアクセスするようになる.

クライアント認証に成功し,
nginxのスタートページのHTMLが表示された.

やったぜ.
これでクライアント認証のしくみを実装することができた.

おわり

以上の手順でOpenSSLとnginxを使ったクライアント認証のしくみを試してみた.
不特定多数に公開したくない独自APIをチーム内だけに公開するときとかにサクッと作れると便利そう.

おまけ

参考

nginxとOpenSSLでHTTPSサーバーを立てる

Wed, 03 Jun 2020 22:17:33 +0900

オレオレ証明書でHTTPS

OpenSSLで証明書を作る方法を勉強したので, nginxと組み合わせてHTTPSサーバーを立ててみる.

やったことのまとめ

オレオレ証明書を使ってルート認証局を立てた
ルート認証局を使って中間認証局を立てた
中間認証局でサーバー証明書に署名した
サーバー証明書をnginxにインストールしてブラウザで確認した

サーバー証明書とはHTTPSで通信する際にサーバーの正当性を認証局が証明していることを示すもの.

クライアントがHTTPSサーバーと通信する際はサーバーの証明書を確認してサーバーの正当性を誰(認証局)が証明しているのかを確認する.
さらにその認証局(中間認証局)の正当性を証明するのがルート認証局で,
クライアントは最初から信頼できるルート認証局の情報を持っているので証明書の発行者をたどることでそのサーバーの正当性を確認することができる.

今回はこのしくみをローカルでつくって試してみる.

OpenSSLの使い方とかは既にメモを作成済み.

つかうもの

Raspberry Pi 3 Model B+
- OSはRaspbian(10.0)
- SSLサーバーとして使用
OpenSSL
- OpenSSL 1.1.1c 28 May 2019
- ラズパイの初期装備
nginx
- version 1.14.2
- インストール済み
macOS Mojave 10.14
- ブラウザ用
Google Chrome
- バージョン: 83.0.4103.61（Official Build）（64 ビット）

やったこと

オレオレ証明書とルート認証局の作成
中間証明書と中間認証局の作成
サーバー証明書の作成
nginxに証明書を持たせる

オレオレ証明書とルート認証局の作成

本来であれば正式な認証局に依頼してちゃんとしたサーバー証明書を作ってもらうべきなんだけど,
お金もかかるし自分で遊ぶだけなのでオレオレ証明書でルート認証局を立ててみる.

まずはOpenSSLでオレオレ証明書用の秘密鍵を作成する.
普段はgenrsaを使ってるんだけどgenpkeyのほうが新しくてオススメされているみたいなのでそちらで作ってみる.
(OpenSSLのサブコマンド多すぎ問題)

## 以下すべてラズパイで実行
# ルート認証局用ディレクトリ(RootCA)で作業
$ mkdir RootCA && cd RootCA

# ルート認証局用の秘密鍵(RootCA-private-key.pem)を作成
$ openssl genpkey -algorithm RSA -out RootCA-private-key.pem

秘密鍵からルート認証局の正当性を主張するためのオレオレ証明書を作成する.
質問の内容は適当でいい. はず…

# ルート認証局の秘密鍵(RootCA-private-key.pem)を使ったオレオレ証明書(RootCA.pem)の作成
$ openssl req -x509 -key RootCA-private-key.pem -out RootCA.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:RootCA # ここだけ入れてみる
Email Address []:

オレオレ証明書ができたので, これでルート認証局ができた.

この認証局は自分で自分の正当性を主張しているだけで公的な信頼は一切ないので注意.
繰り返しになるけどちゃんとしたSSLサーバーを立てたいならここは公的な認証局にお願いするべき.

中間証明書と中間認証局の作成

作成したルート認証局でそのままサーバー証明書を作ってもいいんだけど,
今回は勉強のために中間認証局を立てて, その正当性を先程作ったルート認証局で証明する.

まずは中間認証局用の秘密鍵を作成する.

# 中間認証局用ディレクトリ(IntermediateCA)で作業
$ cd ..
$ mkdir IntermediateCA && cd IntermediateCA

# 中間認証局用の秘密鍵(RootCA-private-key.pem)を作成
$ openssl genpkey -algorithm RSA -out IntermediateCA-private-key.pem

この中間認証局の正当性をオレオレ証明書以外で証明するには他の認証局にお願いするしかないので,
証明書署名要求(CSR)を作成する.
質問の内容はこちらも適当でいい. はず…

# 中間認証局の秘密鍵(IntermediateCA-private-key.pem)から中間認証局のCSR(IntermediateCA-csr.pem)を作成
$ openssl req -new -key IntermediateCA-private-key.pem -out IntermediateCA-csr.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:IntermediateCA # ここだけ入れてみる
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

作成した中間認証局のCSRをルート認証局に渡し, ルート認証局はそれに署名して中間認証局の正当性を証明する…
つもりだったのに怒られてしまった.

# 中間認証局のCSR(IntermediateCA-csr.pem)をルート認証局に渡す
$ mv IntermediateCA-csr.pem ../RootCA/

# ルート認証局の秘密鍵(RootCA-private-key.pem)とルート証明書(RootCA.pem)で
# 中間認証局のCSR(IntermediateCA-csr.pem)に署名して中間証明書(IntermediateCA-certicifation.pem)を作成
# したかったけど怒られた...
$ cd ../RootCA
$ openssl ca -in IntermediateCA-csr.pem -out IntermediateCA-certicifation.pem -keyfile RootCA-private-key.pem -cert RootCA.pem
Using configuration from /usr/lib/ssl/openssl.cnf
ca: ./demoCA/newcerts is not a directory
./demoCA/newcerts: No such file or directory

なんかディレクトリ./demoCA/newcertsが足りてないらしいので作って再挑戦.

# ディレクトリを作成
$ mkdir -p demoCA/newcerts

# 再挑戦したけどだめ
$ openssl ca -in IntermediateCA-csr.pem -out IntermediateCA-certicifation.pem -keyfile RootCA-private-key.pem -cert RootCA.pem
Using configuration from /usr/lib/ssl/openssl.cnf
1996152848:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:72:fopen('./demoCA/index.txt','r')
1996152848:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:79:

また怒られた.
ファイル./demoCA/index.txtが足りてないみたいなので空ファイルを作る.

# 空ファイルを作成
$ touch ./demoCA/index.txt

# 再挑戦したけどだめ
$ openssl ca -in IntermediateCA-csr.pem -out IntermediateCA-certicifation.pem -keyfile RootCA-private-key.pem -cert RootCA.pem
Using configuration from /usr/lib/ssl/openssl.cnf
./demoCA/serial: No such file or directory
error while loading serial number
1995452432:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:72:fopen('./demoCA/serial','r')
1995452432:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:79:

またまた怒られた. つらい.
ファイル/demoCA/serialが足りてないらしい.

# 空ファイルを作成
$ touch ./demoCA/serial

# 再挑戦したけどだめ
$ openssl ca -in IntermediateCA-csr.pem -out IntermediateCA-certicifation.pem -keyfile RootCA-private-key.pem -cert RootCA.pem
Using configuration from /usr/lib/ssl/openssl.cnf
unable to load number from ./demoCA/serial
error while loading serial number
1995870224:error:0D066096:asn1 encoding routines:a2i_ASN1_INTEGER:short line:../crypto/asn1/f_int.c:140:

またまたまた怒られた. キレそう.
今度はシリアルナンバーが読めないよ的なエラーが出ているので, 適当な数字を入れてあげる.

# 空ファイルに適当な数字を書き込む
$ echo 00 >> ./demoCA/serial

# いけた
$ openssl ca -in IntermediateCA-csr.pem -out IntermediateCA-certicifation.pem -keyfile RootCA-private-key.pem -cert RootCA.pem
Using configuration from /usr/lib/ssl/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
 Serial Number: 0 (0x0)
 Validity
 Not Before: Jun 1 14:24:19 2020 GMT
 Not After : Jun 1 14:24:19 2021 GMT
 Subject:
 countryName = AU
 stateOrProvinceName = Some-State
 organizationName = Internet Widgits Pty Ltd
 commonName = IntermediateCA
 X509v3 extensions:
 X509v3 Basic Constraints:
 CA:FALSE
 Netscape Comment:
 OpenSSL Generated Certificate
 X509v3 Subject Key Identifier:
 FF:A3:92:E0:F3:10:A9:28:AC:5F:4A:D2:BE:FD:D7:2B:19:EC:DD:02
 X509v3 Authority Key Identifier:
 keyid:A9:96:E7:CD:B2:77:F2:8F:CA:4C:4A:E9:75:52:91:3E:6C:53:42:0B

Certificate is to be certified until Jun 1 14:24:19 2021 GMT (365 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

こんどは成功した.

ちなみに./demoCA/index.txtは証明書発行の記録を残すためのファイルで,
/demoCA/serialはシリアルナンバーを設定するためのファイルだったらしい.

# index.txtの内容を確認
$ cat ./demoCA/index.txt
V	210601142419Z		00	unknown	/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=IntermediateCA

あとはルート認証局で作成した中間認証局の証明書(中間証明書)を中間認証局に渡す.

# 中間証明書(IntermediateCA-certicifation.pem)を中間認証局に返す
$ mv IntermediateCA-certicifation.pem ../IntermediateCA/

これで中間認証局の正当性をルート認証局が証明したことになる.

サーバー証明書の作成

認証局の準備ができたので,
いよいよHTTPSで使うためのサーバー証明書を作る.

まずは中間認証局を立てたときと同じようにサーバーの正当性を証明するためのCSRを作成する.

# サーバー用ディレクトリ(Server)で作業
$ cd ..
$ mkdir Server && cd Server

# サーバー用の秘密鍵(Server-private-key.pem)を作成
$ openssl genpkey -algorithm RSA -out Server-private-key.pem

# サーバーの秘密鍵(Server-private-key.pem)からCSR(Server-csr.pem)を作成
$ openssl req -new -key Server-private-key.pem -out Server-csr.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:uzimihsr.example.com # ここだけ入れてみる
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

サーバーのCSRを中間認証局に渡し,
中間認証局は受け取ったCSRに署名してサーバー証明書を作成する.

# サーバーのCSR(Server-csr.pem)を中間認証局に渡す
$ mv Server-csr.pem ../IntermediateCA/

# 署名のための準備
$ cd ../IntermediateCA
$ mkdir -p demoCA/newcerts
$ touch ./demoCA/index.txt
$ echo 01 > ./demoCA/serial

# 中間認証局の秘密鍵(IntermediateCA-private-key.pem)と中間証明書(IntermediateCA-certicifation.pem)で
# サーバーのCSR(Server-csr.pem)に署名してサーバー証明書(Server-certicifation.pem)を作成
$ openssl ca -in Server-csr.pem -out Server-certicifation.pem -keyfile IntermediateCA-private-key.pem -cert IntermediateCA-certicifation.pem
Using configuration from /usr/lib/ssl/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
 Serial Number: 1 (0x1)
 Validity
 Not Before: Jun 1 14:49:49 2020 GMT
 Not After : Jun 1 14:49:49 2021 GMT
 Subject:
 countryName = AU
 stateOrProvinceName = Some-State
 organizationName = Internet Widgits Pty Ltd
 commonName = uzimihsr.example.com
 X509v3 extensions:
 X509v3 Basic Constraints:
 CA:FALSE
 Netscape Comment:
 OpenSSL Generated Certificate
 X509v3 Subject Key Identifier:
 67:F1:62:B9:B4:FB:81:BD:E9:11:55:45:CF:43:D1:59:0B:66:D9:10
 X509v3 Authority Key Identifier:
 keyid:FF:A3:92:E0:F3:10:A9:28:AC:5F:4A:D2:BE:FD:D7:2B:19:EC:DD:02

Certificate is to be certified until Jun 1 14:49:49 2021 GMT (365 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

# サーバーに証明書(Server-certicifation.pem)を渡す
$ mv ./Server-certicifation.pem ../Server/

以上の手順でサーバーの正当性を中間認証局が証明したことになる.

nginxに証明書を持たせる

サーバーの証明書ができたので,
これをnginxに持たせてHTTPSサーバーを建てる.

まずはサーバー証明書の発行元の正当性を証明するために,
ルート証明書と中間証明書とサーバー証明書をくっつける.

# サーバー証明書(Server-certicifation.pem), 中間証明書(IntermediateCA-certicifation.pem), ルート証明書(RootCA.pem)をくっつける(cert.pem)
$ cd ../Server
$ cat Server-certicifation.pem ../IntermediateCA/IntermediateCA-certicifation.pem ../RootCA/RootCA.pem > cert.pem

次にnginxにHTTPSサーバーとして動かすための設定を追加する.

# nginx設定ファイルの作成
$ sudo vim /etc/nginx/conf.d/https.conf

nginx.confは初期設定のまま.

https.confで指定している場所にサーバーの証明書と秘密鍵を配置する.
これにより, nginxがHTTPSでリクエストを受けたときにクライアントにこの証明書を提示できるようになる.

# サーバー証明書(cert.pem)と秘密鍵(Server-private-key.pem)の配置
$ sudo mkdir /etc/nginx/https
$ sudo cp ./cert.pem /etc/nginx/https/
$ sudo cp ./Server-private-key.pem /etc/nginx/https/

ここまでできたら,
nginxを再起動する.

# nginxの設定を確認して再起動
$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo systemctl restart nginx

ここまでできたら, Macのブラウザで https://<ラズパイのIP>/ を開く.
しかしこのサーバー(nginx)から提示された証明書がMacに信頼されていないため, 警告が出てしまう.

左上の鍵マークから証明書を表示して確認する.

サーバー証明書(uzimihsr.example.com)が表示される.
この証明書は中間認証局(IntermediateCA)が発行者になっているが,
これが公的な認証局でないために信頼できない状態であることがわかる.

nginxに持たせた証明書はサーバー証明書の他に中間証明書とルート証明書が連結してあるので,
これらの内容も確認できる.

中間証明書(IntermediateCA)を確認する.
こちらはルート認証局(RootCA)によって発行されているが,
これも公的な認証局でないために信頼されていない.

ルート証明書(RootCA)についても同様.
ルート認証局はどれもオレオレ証明書で自分の正当性を主張しているが,
Macはこのルート認証局が信頼できる認証局のリストにないため,
この認証局が発行した証明書を信頼していない状態であることがわかる.

このままだとnginxの画面が開けないので,
サーバー証明書をMacに信頼させるようにする.

まずはChromeの証明書を開いている画面からサーバー証明書のアイコンをデスクトップにドラッグ&ドロップする.

デスクトップに落ちた証明書をダブルクリックすると,
キーチェーンアクセスが開く.

サーバー証明書をダブルクリックすると詳細画面が開くので,
信頼->この証明書を信頼するときを常に信頼に変更してウィンドウを閉じる.
これでMacがこの証明書を信頼するようになった.

再度Macのブラウザで https://<ラズパイのIP>/ を開く.
今度はnginxのデフォルト画面が開けた.

サーバー証明書を確認すると, 確かにこれが信頼されていることがわかる.

やったぜ.
OpenSSLとnginxでHTTPSサーバーを建てることができた.

本当は他のHTTPSで提供されているサイトみたいにアドレスの左側に緑の鍵マークを表示させたいんだけど,
Chromeはちょっと厳しくて発行時にCNだけじゃなくてSANsもちゃんと設定した証明書じゃないといけないらしい…
とりあえず今回はサーバー証明書の練習が目的だったのでここまでで終わりにする.

おわり

以上の手順でOpenSSLでサーバー証明書を作ってnginxにもたせてHTTPSサーバーを建てることができた.
時間とレンタルサーバーを借りるお金の余裕があれば,
無料で証明書を発行できるLet’s EncryptとかでちゃんとしたHTTPSサーバーを立ててみたい.

おまけ

参考

5月のそとちゃんまとめ(2020)

Sun, 31 May 2020 21:57:23 +0900

記念日だったりした

今月のそとちゃんはいろいろあったのでまとめ.

まとめ

1周年
朝のルーティン
ハンモック
元気が有り余っている

1周年

まずはなんといっても1周年記念日.
そとちゃんは元号が令和に変わった日にうちに来たので,
5/1で一緒に暮らし始めてからちょうど1年になった.
本当の年齢も誕生日もわからないので, この日でたぶん4さいということにした.

本当はたぶん4さいをちゃんと猫用ケーキでお祝いしたかったんだけど,
コロナうんぬんで慌ただしい時期だったのでそとちゃんのお気に入りおやつ全部乗せをプレゼントした.

Instagram

余裕でカロリーオーバーなのでかわいそうだけど次の日はおやつ抜きだった…

来年こそはカロリーに配慮したおいしいケーキでお祝いしてあげたい.

朝のルーティン

理由は謎だけど,
先月の終わり頃から朝お腹の上に乗ってきておしりを見せてくれることが多くなった.

朝 pic.twitter.com/1LinJL4LyT
— ずみし (@uzimihsr) April 30, 2020

朝だからおしり見せにきた pic.twitter.com/QmhZQlE5wy
— ずみし (@uzimihsr) May 18, 2020

おはようございます pic.twitter.com/zg3nprMEgC
— ずみし (@uzimihsr) May 19, 2020

朝だからおしり見せてくれる pic.twitter.com/8smYOnYCDi
— ずみし (@uzimihsr) May 28, 2020

まるいおしりがおまんじゅうみたいでかわいいけどちょっとくさい.
でも猫がおしりを向けてくるのは信頼の証らしいので嬉しくもある.

けどやっぱりちょっとくさい.
うんちのにおいで起こされると気分があまりよくない.
でもかわいいからしょうがないね.

ハンモック

そとちゃんは窓から外の景色を眺めるのが好きなので,
外が見やすくなるように窓に取り付けるタイプの猫用ハンモックを買ってみた.

最初はやっぱり警戒しておやつで釣らないと乗ってくれなかったんだけど,

instagram

1週間くらいしたら慣れて自分で乗るようになった.

https://twitter.com/uzimihsr/status/1264456579127971841

特に夜は車が走ってるのを見るのがトレンドらしい.

Instagram

うちはちょっと日当たりが悪いので, これで思う存分ひなたぼっこを楽しんでほしい.

そろそろ暑くなってくるので熱中症がちょっとだけ心配.
(ねこ, 暑さよりも居心地の良さを優先して動かないんだとか)

元気が有り余っている

今月も健康面では特に問題なく, なんかやたら元気だった.

動画は撮れてないけど,
テレビ会議してるときは特に運動会とコンサートが始まってかなりうるさい.
そとちゃん賢いのでかまってもらうためにわざとやってるまである(親馬鹿).

あとは風呂待ちがエスカレートして洗濯物になったり,

謎の落ち着きポイント pic.twitter.com/g9WyAtNlZ4
— ずみし (@uzimihsr) May 26, 2020

ねこが洗濯物になった pic.twitter.com/5d1aT4m46r
— ずみし (@uzimihsr) May 30, 2020

ふとんを攻撃したりしてた.

ふとん絶対バリバリにするマン(ねこ) pic.twitter.com/1Mzv2CWfcT
— ずみし (@uzimihsr) May 20, 2020

朝からふとんバリバリ
しっぽの躍動感 pic.twitter.com/5ffteQh617
— ずみし (@uzimihsr) May 28, 2020

最近家にいても仕事でなかなか遊んであげられなかったり,
新しいおもちゃも買ってあげられてないので刺激が足りないのかもしれない…

おわり

そとちゃんは5月も元気だった.

1年も一緒にいればお互いのことがわかってくると思ったらそんなことはなく,
毎日新しい発見があるので本当にかわいくて面白い.

ちょっと運動が足りてない感じはするので, 6月はもっと遊ぶ時間を確保してあげて,
あとは暑さ対策も気をつけてあげたい.

おまけ

OpenSSLでデジタル証明書を試す

Sat, 30 May 2020 19:58:15 +0900

身元を証明する

デジタル署名とデジタル証明書についても実際に触りながらまとめる.

まとめ

デジタル署名

# メッセージ(message)のハッシュ値を秘密鍵(private-key.pem)で暗号化して署名(signature)を作成
$ openssl dgst -sha256 -sign private-key.pem -out signature message

# 署名(signature)を公開鍵(public-key.pem)で復号化してメッセージ(message)のハッシュ値と照合
$ openssl dgst -sha256 -verify public-key.pem -signature signature message

デジタル証明書

# 秘密鍵(private-key.pem)から証明書署名要求(req.pem)を作成
# 証明書署名要求には公開鍵と, 自身の身元を証明する情報が含まれている
$ openssl req -new -key private-key.pem -out req.pem

# 証明書署名要求(req.pem)の内容確認
$ openssl req -in req.pem -text -verify -noout

# 証明書署名要求(req.pem)に認証局の証明書(ca.pem)と秘密鍵(private-key-CA.pem)で署名して証明書を作成(cert.pem)
# 証明書には証明書署名要求の公開鍵の内容と認証局の署名が含まれている
$ openssl ca -policy policy_anything -in req.pem -out cert.pem -keyfile private-key-CA.pem -cert ca.pem

# 証明書(cert.pem)の内容確認
$ openssl x509 -in cert.pem -noout -text

# 証明書(cert.pem)を信頼できる認証局の証明書(ca.pem)で検証する
$ openssl verify -CAfile ca.pem cert.pem

# 証明書(cert.pem)に含まれる公開鍵の確認
$ openssl x509 -in cert.pem -pubkey -noout

環境

Raspberry Pi 3 Model B+
- OSはRaspbian(10.0)
openssl
- OpenSSL 1.1.1c 28 May 2019
- ラズパイの初期装備

送信側で秘密鍵と公開鍵を作成し, 受信側に公開鍵を渡す
送信側でメッセージを作成し, それをハッシュ化する
送信側で得られたハッシュ値を秘密鍵で暗号化(署名)する
送信側はメッセージ, 署名, 公開鍵を受信側に渡す
受信側は受け取った署名を公開鍵で復号化し, 受け取ったメッセージをハッシュ化したものと照合する

また, これを実現するためデジタル署名には次の特徴がある.

秘密鍵でしか暗号化できない
公開鍵で復号化すると元のメッセージに戻る

実際にやってみる.

まずは送信側で秘密鍵と公開鍵を作成し, メッセージを暗号化(署名)する.

# 2つのディレクトリを送信側(dirX), 受信側(dirY)に見立てて作業
$ mkdir dirX dirY

# 送信側(dirX)で秘密鍵(private-key.pem)と公開鍵(public-key.pem)を作成して公開鍵を受信側(dirY)に渡す
$ cd dirX
$ openssl genrsa -out private-key.pem
$ openssl rsa -in private-key.pem -pubout -out public-key.pem
$ cp ./public-key.pem ../dirY

次にメッセージを作成し, ハッシュ化する.

# メッセージ(message)を作成してSHA-256でハッシュ化(hashed-message)
$ echo qwerty > message
$ openssl sha256 -out hashed-message message
$ cat hashed-message
SHA256(message)= 9ceece10cf8b97d1f1924dae5d14c137fd144ce999ede85f48be6d7582e2dd23

ハッシュ値を秘密鍵で暗号化(署名)する.

# ハッシュ値(hashed_message)を秘密鍵(private-key.pem)で暗号化して署名(signature)を作成
$ openssl rsautl -sign -in hashed-message -out signature -inkey private-key.pem
$ cat signature
����������������

メッセージ, 署名を受信側に渡す.

# メッセージ(message), 署名(signature)を受信側(dirY)に渡す
$ cp ./message ../dirY
$ cp ./signature ../dirY/
$ cd ../dirY
$ ls
message public-key.pem signature

受信側で署名を復号化して, メッセージをハッシュ化したものと照合する.
一致すればメッセージが改ざんされておらず, 送り主が秘密鍵の持ち主であることを証明できる.

# 署名(signature)を公開鍵(public-key.pem)で復号化(signature-verify)
$ openssl rsautl -verify -in signature -out signature-verify -inkey public-key.pem -pubin

# メッセージ(message)をハッシュ化(hashed-message-verify)
$ openssl sha256 -out hashed-message-verify message

# 復号化した署名(signature-verify)とメッセージのハッシュ値(hashed-message-verify)を照合
$ cat signature-verify
SHA256(message)= 9ceece10cf8b97d1f1924dae5d14c137fd144ce999ede85f48be6d7582e2dd23
$ cat hashed-message-verify
SHA256(message)= 9ceece10cf8b97d1f1924dae5d14c137fd144ce999ede85f48be6d7582e2dd23
$ diff signature-verify hashed-message-verify

メッセージのハッシュと署名を復号化した値が一致する組み合わせを作れるのは公開鍵に対応する秘密鍵を持つ者だけなので,
仮にメッセージが改ざんされたり, 同じメッセージが別の秘密鍵で署名された場合は
受信側で照合したときに一致せず, 異常を検知することができる.

以上の手順を踏むことで, 通信時のなりすましや改ざん, 事後否認を防ぐことができる.

また, ハッシュ計算と署名を1つのコマンドで実行することもできる.

# メッセージ(message)のハッシュ値を秘密鍵(private-key.pem)で暗号化して署名(signature)を作成
$ openssl dgst -sha256 -sign private-key.pem -out signature message

# 署名(signature)を公開鍵(public-key.pem)で復号化してメッセージ(message)のハッシュ値と照合
$ openssl dgst -sha256 -verify public-key.pem -signature signature message

デジタル証明書

盗聴を防ぐための方法として用いる公開鍵暗号方式やハイブリッド暗号方式,
そしてなりすまし, 改ざん, 事後否認を防ぐために用いるデジタル署名だが,
これらはすべて受信側が受け取った公開鍵を信頼できるという条件の上で成り立っている.

仮に公開鍵を受け取る際にそれが悪意のある第三者によってすり替えられていた場合,
これらの仕組みが全く意味を持たなくなってしまう(公開鍵の信頼性の問題).

この問題を解決し, 公開鍵の正当性を証明するのがデジタル証明書.
以下の流れで証明書の作成と検証を行う.

自分の身分を証明したい人(A)が秘密鍵と公開鍵を用意する.
Aは自分の公開鍵と自分の身元を証明できる情報を用意(証明書署名要求)して認証局(CA)に送る.
CAはAの証明書署名要求からAの身元を確認した後それらの情報にCA自身の秘密鍵で署名して証明書を作成し, Aに渡す.
Aは通信したい人(B)に自分の証明書を渡す.
BはCA自体の証明書(公開鍵)でAの証明書を検証する.

また, この仕組みを実現するために証明書には次の性質がある.

Aの証明書署名要求はA本人しか作れない
証明書には身元が証明される人の公開鍵情報とそれに署名した認証局の情報が含まれる
信頼している認証局が署名した証明書であれば信頼性が保証される
認証局自身の信頼性はさらに上位の認証局が発行する証明書で保証する

実際にやってみて確認する.
まずはAとCAの秘密鍵, 公開鍵を用意する.

# 3つのディレクトリを通信者(dirA, dirB), 認証局(dirCA)に見立てて作業する
$ mkdir dirA dirB dirCA

# CAとAはそれぞれ秘密鍵を持っている状態
$ cd dirCA
$ openssl genrsa -out private-key-CA.pem
$ openssl rsa -in private-key-CA.pem -pubout -out public-key-CA.pem
$ cd ../dirA
$ openssl genrsa -out private-key-A.pem
$ openssl rsa -in private-key-A.pem -pubout -out public-key-A.pem

次にAは自分の公開鍵と身元を証明する情報を合わせたデータ(証明書署名要求)を作成し,
CAに渡す.

# Aの秘密鍵(private-key-A.pem)から証明書署名要求(req.pem)を作成
# 実際は秘密鍵から公開鍵を取り出して使っている(秘密鍵そのものを渡すわけではない)
$ openssl req -new -key private-key-A.pem -out req.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
----- # 以下, 身元を証明するための情報を入力する
Country Name (2 letter code) [AU]:JP #国
State or Province Name (full name) [Some-State]:Tokyo # 都道府県
Locality Name (eg, city) []: # 市区町村
Organization Name (eg, company) [Internet Widgits Pty Ltd]: # 組織名
Organizational Unit Name (eg, section) []: # 部署名
Common Name (e.g. server FQDN or YOUR name) []:uzimihsr.example.com # 名前
Email Address []:example@mail.com # メールアドレス

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
$ cat req.pem
-----BEGIN CERTIFICATE REQUEST-----
MIICxjCCAa4CAQAwgYAxCzAJBgNVBAYTAkpQMQ4wDAYDVQQIDAVUb2t5bzEhMB8G
...
cH32EBVTnecz4nSPVYHwr9xcgKi+i0ol4ea0lMNWz5m0O0dYOc6H0Qqc
-----END CERTIFICATE REQUEST-----

# 証明書署名要求(req.pem)をCAに渡す
$ cp req.pem ../dirCA/

CAは受け取ったAの証明書署名要求の内容を確認する.

# 証明書署名要求(req.pem)の内容を検証する
$ cd ../dirCA
$ openssl req -in req.pem -text -verify -noout
verify OK
Certificate Request:
 Data: # Aの公開鍵と身元の情報
 Version: 1 (0x0)
 Subject: C = JP, ST = Tokyo, O = Internet Widgits Pty Ltd, CN = uzimihsr.example.com, emailAddress = example@mail.com
 Subject Public Key Info:
 Public Key Algorithm: rsaEncryption
 RSA Public-Key: (2048 bit)
 Modulus:
 00:b7:51:7c:41:9c:c9:f2:4d:c0:a8:43:bb:96:2a:
 ...
 0c:d7
 Exponent: 65537 (0x10001)
 Attributes:
 a0:00
 Signature Algorithm: sha256WithRSAEncryption
 26:88:97:d7:c4:57:da:24:1b:d5:b4:e2:e8:82:23:b5:1c:e0:
 ...
 87:d1:0a:9c

証明書署名要求の内容に問題がなければ署名してAの証明書を作る…前に認証局もそれ自身の身元を証明する必要があるので,
自己証明証明書(オレオレ証明書)を作ってCAを認証局として動かすための設定をする.

# CA自身の身元を証明し鍵(private-key-CA.pem)の正当性を保証するためのオレオレ証明書(ca.pem)を作成
# こちらも内部で秘密鍵から公開鍵を取り出して使用している(証明書に秘密鍵を埋め込むわけではない)
$ openssl req -x509 -key private-key-CA.pem -out ca.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
----- # その場しのぎの証明書なので何も入れなくてもOK
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

# 証明書に署名するために必要な設定
$ mkdir -p demoCA/newcerts
$ touch demoCA/index.txt
$ echo 01 > demoCA/serial

CAはAの証明書署名要求に署名してAの証明書を作成し, Aに渡す.
これによりAの身元と公開鍵の正当性をCAが保証することになる.

# Aの証明書署名要求(req.pem)にCA自身の秘密鍵(private-key-CA.pem)と証明書(ca.pem)を使って署名する(cert-A.pem)
$ openssl ca -policy policy_anything -in req.pem -out cert-A.pem -keyfile private-key-CA.pem -cert ca.pem
Using configuration from /usr/lib/ssl/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
 Serial Number: 1 (0x1)
 Validity
 Not Before: May 30 09:15:17 2020 GMT
 Not After : May 30 09:15:17 2021 GMT
 Subject:
 countryName = JP
 stateOrProvinceName = Tokyo
 organizationName = Internet Widgits Pty Ltd
 commonName = uzimihsr.example.com
 emailAddress = example@mail.com
 X509v3 extensions:
 X509v3 Basic Constraints:
 CA:FALSE
 Netscape Comment:
 OpenSSL Generated Certificate
 X509v3 Subject Key Identifier:
 F2:CC:D3:94:F9:57:AE:F3:4E:A9:12:1F:15:29:87:8C:58:4B:6C:56
 X509v3 Authority Key Identifier:
 keyid:57:A6:BC:47:C9:76:6C:E3:93:48:D7:09:9E:03:8A:86:3F:A5:08:80

...
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

# 証明書をAに渡す
$ cp cert-A.pem ../dirA/

Aは通信を行いたい相手(B)に自分の証明書を渡す.

# Bに証明書を渡す
$ cd ../dirA
$ cp cert-A.pem ../dirB

BはAの証明書の内容を確認する.
BはCAを信頼しているので,
Aの証明書にCAが署名していることを確認できればこれを信頼し, 証明書から取り出したAの公開鍵を安心して利用することができる.

# Aの証明書(cert-A.pem)の内容を確認する
$ cd ../dirB
$ openssl x509 -in cert-A.pem -noout -text
Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number: 1 (0x1)
 Signature Algorithm: sha256WithRSAEncryption
 Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd # 認証局(CA)の情報
 Validity
 Not Before: May 30 09:15:17 2020 GMT
 Not After : May 30 09:15:17 2021 GMT
 Subject: C = JP, ST = Tokyo, O = Internet Widgits Pty Ltd, CN = uzimihsr.example.com, emailAddress = example@mail.com # Aの身元情報
 Subject Public Key Info:
 Public Key Algorithm: rsaEncryption
 RSA Public-Key: (2048 bit)
 Modulus: # Aの公開鍵情報
 00:b7:51:7c:41:9c:c9:f2:4d:c0:a8:43:bb:96:2a:
 ...
 0c:d7
 Exponent: 65537 (0x10001)
 X509v3 extensions:
 X509v3 Basic Constraints:
 CA:FALSE
 Netscape Comment:
 OpenSSL Generated Certificate
 X509v3 Subject Key Identifier:
 F2:CC:D3:94:F9:57:AE:F3:4E:A9:12:1F:15:29:87:8C:58:4B:6C:56
 X509v3 Authority Key Identifier:
 keyid:57:A6:BC:47:C9:76:6C:E3:93:48:D7:09:9E:03:8A:86:3F:A5:08:80

 Signature Algorithm: sha256WithRSAEncryption
 39:a3:7f:a3:dd:9c:ff:21:b7:b3:1b:44:07:c1:38:e0:ae:7a:
 ...
 bc:d0:36:70

# 信頼している認証局(CA)の証明書(ca.pem)を使ってAの証明書(cert-A.pem)が正しいか検証する
$ openssl verify -CAfile ../dirCA/ca.pem cert-A.pem
cert-A.pem: OK

# 検証が成功したので証明書からAの公開鍵を取り出す
$ openssl x509 -in cert-A.pem -pubkey -noout
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt1F8QZzJ8k3AqEO7liqz
...
1wIDAQAB
-----END PUBLIC KEY-----

# 以降はAの公開鍵を信頼して通信する

Bが信頼できる証明書はBが信頼している認証局とA本人によってのみ作成できるので,
悪意のある第三者がAになりすましてBに自身の公開鍵を渡すことはできない.
したがって, 証明書を使うことで公開鍵の正当性を保証することができる.

以上の手順で公開鍵の信頼性を保証することができた.
やることが多くて混乱するけど,
要は信頼できる認証局が相手の身元を保証していれば自分も相手を信頼する, という仕組み.

今回は認証局(CA)の身元を自身で保証したけど(オレオレ証明書),
実際は上位の認証局がその正当性を保証する.
その上位の認証局の正当性はさらに上位の認証局が保証し… というように,
認証局の保証は木構造になっている.
最上位の認証局の正当性は自身の証明書では保証できないので,
公的に信頼できる政府関連の機関などが最上位の認証局を努めている.
以上が公開鍵基盤(PKI)の仕組み.

おわり

公開鍵暗号方式, ハイブリッド暗号方式に続いてデジタル証明書を実際に試してみた.
証明書署名要求から証明書の作成までの手順も確認できたので,
機会があればオレオレ証明書でSSL通信したり, クライアント認証とかを試してみたい.

おまけ

参考

OpenSSLで共通鍵暗号方式とハイブリッド暗号方式を試す

Sun, 24 May 2020 17:09:44 +0900

欠点を補いあう

共通鍵暗号方式とハイブリッド暗号方式についても実際に触りながらまとめる.

まとめ

共通鍵でのデータの暗号化と復号化

# 32bytesの乱数パスワードファイル(password)の作成
$ openssl rand -base64 -out password 32

# 平文データ(data)を公開鍵(password)を使ってaes256で暗号化(encrypted-data)
$ openssl enc -aes256 -in data -out encrypted-data -pass file:password -base64

# 暗号データ(encrypted-data)を公開鍵(password)を使ってaes256で復号化(decrypted-data)
$ openssl enc -d -aes256 -in encrypted-data -out decrypted-data -pass file:password -base64

ハイブリッド暗号方式

# 秘密鍵(private-key.pem)と公開鍵(public-key.pem)の作成
# 作成した公開鍵はもう片方に渡す
$ openssl genrsa -out private-key.pem
$ openssl rsa -in private-key.pem -pubout -out public-key.pem

# 共通鍵(password)の作成 (秘密鍵を持たない方が実行)
$ openssl rand -base64 -out password 32

# 公開鍵(public-key.pem)を使って共通鍵(password)を暗号化(encrypted-password) (秘密鍵を持たない方が実行)
# 暗号化した共通鍵をもう片方に渡す
$ openssl rsautl -encrypt -in password -out encrypted-password -inkey public-key.pem -pubin

# 秘密鍵(private-key.pem)を使って暗号化された共通鍵(encrypted-password)を復号化(decrypted-password) (秘密鍵を持つ方が実行)
$ openssl rsautl -decrypt -in encrypted-password -out decrypted-password -inkey private-key.pem

# 以降は共通鍵で暗号化したデータをやりとりする

環境

Raspberry Pi 3 Model B+
- OSはRaspbian(10.0)
openssl
- OpenSSL 1.1.1c 28 May 2019
- ラズパイの初期装備

# ディレクトリを送信側(dirA)と受信側(dirB)に見立てて作業
$ mkdir dirA dirB
$ cd dirA

# 共通鍵(password)を作成
# 本当はこんな適当な値ではなく乱数が望ましい
$ echo 1234567 > password
$ cat password
1234567

# 共通鍵(password)を受信側(dirB)に共有
$ cp password ../dirB/
$ ls
password
$ ls ../dirB
password

次に平文データを共通鍵で暗号化する.
これにより, 共通鍵がわからない場合はデータの内容を読むことができなくなる.

# 送信側(dirA)で作業
$ pwd
/path/to/dirA

# 平文データ(data.txt)を作成
$ echo abcdefg > data.txt

# 暗号化アルゴリズム(aes256)を使って平文データ(data.txt)を暗号化(encrypted-data.txt)
# アルゴリズムが非推奨のものなので警告が出ているがとりあえずはOK
$ openssl enc -aes256 -in data.txt -out encrypted-data.txt -pass file:password
*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.
$ ls
data.txt encrypted-data.txt password

# 暗号化されているので読めない
$ cat encrypted-data.txt
Salted__aGo�r�ʵ�3�Z��ċ�D

暗号データを受信側に渡し,
受信側で共通鍵を使って復号化する.

# 暗号データ(encrypted-data.txt)を受信側(dirB)に渡す
$ pwd
/path/to/dirA
$ cp encrypted-data.txt ../dirB/

# 受信側(dirB)で作業
$ cd ../dirB
$ ls
encrypted-data.txt password

# 暗号データ(encrypted-data.txt)を共通鍵(password)で復号化(decrypted-data.txt)
$ openssl enc -d -aes256 -in encrypted-data.txt -out decrypted-data.txt -pass file:password
*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.
$ cat decrypted-data.txt
abcdefg

こんな感じでデータの暗号化と復号化ができる.

重要なのは, 送信側と受信側の間で暗号データの他に共通鍵の受け渡しをしていること.
共通鍵暗号方式では同じ鍵で暗号化と復号化が行われるため,
通信が傍受され共通鍵が流出した場合は簡単に平文データが取り出されてしまう.
(いわゆる鍵配送問題)

公開鍵暗号方式と共通鍵暗号方式の比較

公開鍵暗号方式と共通鍵暗号方式の大きな違いとしては
公開鍵暗号方式が暗号化/復号化を 別々の鍵 で行うのに対し,
共通鍵暗号方式では暗号化/復号化を 同じ鍵 で行うこと.

これらの特徴を比較すると次のようになる.

共通鍵暗号方式
- 公開鍵暗号方式よりも暗号化/復号化が高速
  - アルゴリズムが簡単なため
- 通信を傍受されると無力
公開鍵暗号方式
- 暗号化/復号化が遅い
- 通信を傍受されても問題ない

これらの特徴をうまく組み合わせて高速で安全な通信を行うのがハイブリッド暗号方式.

ハイブリッド暗号方式

ハイブリッド暗号方式の大きな特徴は,
共通鍵そのものを公開鍵暗号方式で渡すこと.

主な流れはこんな感じ.

送信側で共通鍵を作成
受信側で秘密鍵と公開鍵を作成, 送信側に公開鍵を渡す
送信側は受け取った公開鍵で共通鍵を暗号化して受信側に渡す
受信側は暗号化された共通鍵を秘密鍵で復号化
以降は2者間で共通鍵で暗号化したデータをやり取りする

最初の1回だけ公開鍵暗号方式で共通鍵を渡した後は高速な共通鍵暗号方式を使うことができるので,
高速で安全にデータをやり取りするためのSSL/TLS通信では公開鍵暗号方式単体ではなくこちらが使用されている.

実際にやってみる.

まずは送信側で共通鍵を作成する.

# ディレクトリを送信側(dir1)と受信側(dir2)に見立てて作業
$ mkdir dir1 dir2

# 送信側(dir1)で共通鍵(password)を作成
# 今回はちゃんと32bytesの乱数で作成する
$ cd dir1
$ openssl rand -base64 -out password 32
$ cat password
VAJhXVUt7aRxfFs5ba7SNkjWyIqOaI8E10t0tnmF7as=

次に受信側で秘密鍵と公開鍵を作成して公開鍵を送信側に渡す.

# 受信側(dir2)で秘密鍵(private-key.pem)と公開鍵(public-key.pem)を作成, 送信側(dir1)に公開鍵を渡す
$ cd ../dir2
$ openssl genrsa -out private-key.pem
$ openssl rsa -in private-key.pem -pubout -out public-key.pem
$ cp ./public-key.pem ../dir1/ # 公開鍵を渡す

送信側は受け取った公開鍵で共通鍵を暗号化して受信側に渡す.

# 送信側(dir1)は受け取った公開鍵(public-key.pem)で共通鍵(password)を暗号化(encrypted-password)して受信側に渡す
$ cd ../dir1
$ openssl rsautl -encrypt -in password -out encrypted-password -inkey public-key.pem -pubin
$ cat encrypted-password
��ʞ��...
$ cp ./encrypted-password ../dir2/ # 暗号化された共通鍵を渡す

最後に受信側は暗号化された共通鍵を秘密鍵で復号化する.

# 受信側(dir2)は暗号化された共通鍵(encrypted-password)を秘密鍵(private-key.pem)で復号化(decrypted-password)
$ cd ../dir2
$ openssl rsautl -decrypt -in encrypted-password -out decrypted-password -inkey private-key.pem
$ cat decrypted-password
VAJhXVUt7aRxfFs5ba7SNkjWyIqOaI8E10t0tnmF7as=

以上の手順で送信側, 受信側双方に共通鍵が存在する状態になったので,
以降は2者間で共通鍵暗号方式で通信する.

# 以降は2者間で共通鍵で暗号化したデータをやり取りする
$ echo hello > file1
$ openssl enc -aes256 -in file1 -out encrypted-file1 -pass file:decrypted-password -base64
$ cp ./encrypted-file1 ../dir1/ # 暗号データを渡す
$ cd ../dir1
$ openssl enc -d -aes256 -in encrypted-file1 -out decrypted-file1 -pass file:password -base64
$ cat decrypted-file1
hello
$ echo world > file2
$ openssl enc -aes256 -in file2 -out encrypted-file2 -pass file:password -base64
$ cp ./encrypted-file2 ../dir2/ # 暗号データを渡す
$ cd ../dir2
$ openssl enc -d -aes256 -in encrypted-file2 -out decrypted-file2 -pass file:decrypted-password -base64
$ cat decrypted-file2
world

重要なのは暗号データの他に2者間でやり取りされるデータが 公開鍵, 公開鍵で暗号化された共通鍵のみ であること.
公開鍵暗号方式の性質として公開鍵では暗号化された共通鍵の復号化ができず,
暗号化された状態の共通鍵では暗号データを復号化できないため,
仮に悪意のある第三者がこれらの通信を傍受してもやりとりされる平文データの内容を読むことはできない(秘密が守られる).

おわり

公開鍵暗号方式に続いて共通鍵暗号方式とハイブリッド暗号方式を実際に試してみた.
これでも十分そうに見えるけど, まだ公開鍵の信頼性にまつわる問題があるので次はデジタル証明書について触ってみたい.

おまけ

参考

OpenSSLで秘密鍵と公開鍵を作る

Wed, 20 May 2020 20:18:54 +0900

暗号わかんね

公開鍵暗号方式についてよくわかってないままだったので実際に触りながら自分なりにまとめる.

まとめ

秘密鍵と公開鍵の作成

# 秘密鍵(private-key.pem)を作成
## パスフレーズなし
$ openssl genrsa -out private-key.pem
## パスフレーズあり(aes256で暗号化)
$ openssl genrsa -out private-key.pem -aes256

# 秘密鍵(private-key.pem)から公開鍵(public-key.pem)を作成
$ openssl rsa -in private-key.pem -pubout -out public-key.pem

データの暗号化と復号化

# 公開鍵(public-key.pem)を使ってデータ(data.txt)を暗号化(encrypted-data.txt)
$ openssl rsautl -encrypt -in data.txt -out encrypted-data.txt -inkey public-key.pem -pubin

# 秘密鍵(private-key.pem)を使って暗号データ(encrypted-data.txt)を復号化(decrypted-data.txt)
$ openssl rsautl -decrypt -in encrypted-data.txt -out decrypted-data.txt -inkey private-key.pem

秘密鍵のパスフレーズ

# 秘密鍵(private-key.pem)にパスフレーズをつける(private-key-with-pass-phrase.pem)
$ openssl rsa -in private-key.pem -out private-key-with-pass-phrase.pem -aes256

# 秘密鍵(private-key-with-pass-phrase.pem)のパスフレーズを外す(private-key-without-pass-phrase.pem)
$ openssl rsa -in private-key-with-pass-phrase.pem -out private-key-without-pass-phrase.pem

環境

Raspberry Pi 3 Model B+
- OSはRaspbian(10.0)
openssl
- OpenSSL 1.1.1c 28 May 2019
- ラズパイの初期装備

# 適当なディレクトリを作って作業
$ mkdir dirA
$ cd dirA

# パスフレーズなしの秘密鍵(private-key.pem)を作成する
$ openssl genrsa -out private-key.pem
Generating RSA private key, 2048 bit long modulus (2 primes)
.........................................+++++
...............................+++++
e is 65537 (0x010001)

# 秘密鍵が生成される
$ ls
private-key.pem

# そのまま表示しても読めない
$ cat private-key.pem
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA58HW0I+9qZiHopidx7pUuxNzVuobgzgp7OswlvgSHn2/BbKL
...
fSy2dXrjU08OXro9YHz0d6XESG3feSinK0ND0sbsrKTD+4j7fetk
-----END RSA PRIVATE KEY-----

次に秘密鍵の内容を確認してみる.

秘密鍵には公開鍵の情報と鍵を作成したときの情報とかが入ってる.
(例: modulusが公開鍵の情報で, prime1とかprime2とあるのが鍵生成時に使用した素数の情報)

# 秘密鍵(private-key.pem)の中身を確認する
$ openssl rsa -in private-key.pem -text -noout
RSA Private-Key: (2048 bit, 2 primes)
modulus:
 00:e7:c1:d6:d0:8f:bd:a9:98:87:a2:98:9d:c7:ba:
 54:bb:13:73:56:ea:1b:83:38:29:ec:eb:30:96:f8:
 12:1e:7d:bf:05:b2:8b:c5:ff:33:fb:b1:7d:be:a6:
 7b:ec:62:5c:b2:d3:dd:b7:34:ec:5f:b2:1a:56:63:
 27:d4:f4:e0:7d:10:2b:29:8b:16:6e:f1:ce:7b:73:
 31:67:39:ca:cf:df:d3:fb:14:15:94:85:80:f4:2a:
 ee:c6:93:79:ff:81:09:51:55:29:14:e7:d3:dd:87:
 d4:82:2f:c2:80:5c:e3:89:60:c6:a7:9a:43:b3:0d:
 33:98:d1:05:1c:20:38:a4:dd:19:39:b8:0b:d1:6e:
 84:8f:e9:55:df:fd:70:16:c5:f8:5d:66:6a:03:13:
 36:7b:ab:e1:7e:30:7e:76:6b:e0:50:2d:cb:ad:59:
 9c:db:66:ba:2e:9d:61:50:ad:0f:2f:fe:22:7f:bb:
 ef:91:f5:70:02:bd:71:2f:6a:93:2f:db:85:fd:3e:
 28:cf:39:d1:d4:39:32:e8:c7:a0:3b:10:98:36:44:
 69:d3:15:57:bf:59:53:0c:88:01:02:78:9f:69:f6:
 1b:c2:20:5a:e0:0e:b2:1f:ed:10:c1:bf:9d:d0:17:
 9d:0a:7a:25:8d:84:bc:39:f1:1b:74:11:47:e0:68:
 03:21
publicExponent: 65537 (0x10001)
privateExponent:
 79:5d:79:31:1f:15:23:8b:4c:fc:49:0f:d7:58:2c:
 ...
prime1:
 00:fc:4f:d2:2b:d8:79:fa:6d:ca:c4:3f:b1:fe:67:
 ...
prime2:
 00:eb:25:19:b7:ca:02:f0:9a:09:ea:7f:19:03:40:
 ...
exponent1:
 00:e8:69:5e:5f:a4:f8:37:06:0b:50:da:9b:4a:8c:
 ...
exponent2:
 22:f6:11:2c:d2:4c:3d:99:a9:7f:c4:05:e4:05:db:
 ...
coefficient:
 4a:9f:3d:f5:6f:b6:83:02:f0:57:47:03:c3:d5:8c:
 ...

次に秘密鍵のデータから公開鍵を取り出してみる.
公開鍵の中身が秘密鍵の中身のmodulusと同じになっていることが確認できる.

# 秘密鍵から公開鍵(public-key.pem)を出力する
$ openssl rsa -in private-key.pem -pubout -out public-key.pem
writing RSA key

# 公開鍵が生成される
$ ls
private-key.pem public-key.pem

# 公開鍵もそのままでは読めない
$ cat public-key.pem
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA58HW0I+9qZiHopidx7pU
...
IQIDAQAB
-----END PUBLIC KEY-----

# 公開鍵の中身を確認する
$ openssl rsa -in public-key.pem -text -noout -pubin
RSA Public-Key: (2048 bit)
Modulus:
 00:e7:c1:d6:d0:8f:bd:a9:98:87:a2:98:9d:c7:ba:
 54:bb:13:73:56:ea:1b:83:38:29:ec:eb:30:96:f8:
 12:1e:7d:bf:05:b2:8b:c5:ff:33:fb:b1:7d:be:a6:
 7b:ec:62:5c:b2:d3:dd:b7:34:ec:5f:b2:1a:56:63:
 27:d4:f4:e0:7d:10:2b:29:8b:16:6e:f1:ce:7b:73:
 31:67:39:ca:cf:df:d3:fb:14:15:94:85:80:f4:2a:
 ee:c6:93:79:ff:81:09:51:55:29:14:e7:d3:dd:87:
 d4:82:2f:c2:80:5c:e3:89:60:c6:a7:9a:43:b3:0d:
 33:98:d1:05:1c:20:38:a4:dd:19:39:b8:0b:d1:6e:
 84:8f:e9:55:df:fd:70:16:c5:f8:5d:66:6a:03:13:
 36:7b:ab:e1:7e:30:7e:76:6b:e0:50:2d:cb:ad:59:
 9c:db:66:ba:2e:9d:61:50:ad:0f:2f:fe:22:7f:bb:
 ef:91:f5:70:02:bd:71:2f:6a:93:2f:db:85:fd:3e:
 28:cf:39:d1:d4:39:32:e8:c7:a0:3b:10:98:36:44:
 69:d3:15:57:bf:59:53:0c:88:01:02:78:9f:69:f6:
 1b:c2:20:5a:e0:0e:b2:1f:ed:10:c1:bf:9d:d0:17:
 9d:0a:7a:25:8d:84:bc:39:f1:1b:74:11:47:e0:68:
 03:21
Exponent: 65537 (0x10001)

このように秘密鍵からは公開鍵の中身が得られるが,
公開鍵から秘密鍵を逆算することはできない ので,
公開鍵は自由に公開しても問題ない.
(正しくは逆算は完全に不可能ではないんだけど, やろうとすると非現実的な計算時間が必要になるので誰もやろうとしない)

公開鍵で暗号化する

秘密鍵と公開鍵が作成できたので,
まずは試しに 公開鍵を用いてデータを暗号化する.

ここからは2つのディレクトリ(dirA, dirB)をデータの受信側, 送信側に見立てて進める.
共通鍵暗号方式でデータをやり取りするには, まず受信側(dirA)の公開鍵を送信側(dirB)に渡す.

# 秘密鍵を作ったのとは別のディレクトリで作業
$ cd ..
$ mkdir dirB
$ ls
dirA dirB

# 受信側(dirA)の公開鍵を送信側(dirB)に送る
$ cp dirA/public-key.pem dirB/

次に送信側(dirB)は受信側からもらった公開鍵でデータ(data.txt)を暗号化する.
公開鍵と平文データで数値計算をごにゃごにゃやった結果の値が暗号データとなる.

# 送信側で適当な平文データを作る
$ cd dirB
$ echo abcdefg > data.txt
$ cat data.txt
abcdefg
$ ls
data.txt public-key.pem

# 公開鍵を使ってデータを暗号化する
$ openssl rsautl -encrypt -in data.txt -out encrypted-data.txt -inkey public-key.pem -pubin

# 暗号化されたデータが出力される
$ ls
data.txt encrypted-data.txt public-key.pem

# そのまま表示しようとしても意味不明な状態
$ cat encrypted-data.txt
�����...

暗号化されたデータは秘密鍵によってのみ復号化できる ので,
この暗号データ(encrypted-data.txt)を公開鍵で復号化することはできない.

# 無理やり復号化を試みる
$ openssl rsautl -decrypt -in encrypted-data.txt -out decrypted-data.txt -inkey public-key.pem -pubin
A private key is needed for this operation
# 秘密鍵じゃないとできないよって怒られる

秘密鍵で復号化する

次に先程暗号化したデータ(encrypted-data.txt)を送信側(dirB)から受信側(dirA)に渡し,
受信側の秘密鍵で復号化してみる.

# 送信側(dirB)から暗号データ(encrypted-data.txt)を受信側(dirA)に送る
$ cd ..
$ cp dirB/encrypted-data.txt dirA/

# 秘密鍵で復号化する
$ cd dirA
$ openssl rsautl -decrypt -in encrypted-data.txt -out decrypted-data.txt -inkey private-key.pem
$ ls
decrypted-data.txt encrypted-data.txt private-key.pem public-key.pem

# 元のデータが復号化されている
$ cat decrypted-data.txt
abcdefg

以上の手順で暗号化データを平文データに復号化できた.

重要なのは
送信側と受信側の間でやりとりされるデータが受信側の公開鍵と暗号データだけになる こと.
暗号化されたデータは秘密鍵によってのみ復号化できる ので,
仮に通信が傍受されても秘密鍵が盗まれない限り情報は守られる.
これが公開鍵暗号の考え方.

パスフレーズをつける

これまで確認したように公開鍵による暗号化で情報は守られるが,
秘密鍵が流出した場合はそうではなくなってしまう.

このため, 万が一に備えて秘密鍵自体をさらに暗号化してしまうというのがパスフレーズの考え.
まずは確認のため, 秘密鍵にパスフレーズを追加してみる.

# 受信側で作業
$ cd dirA
$ ls
decrypted-data.txt encrypted-data.txt private-key.pem public-key.pem

# 秘密鍵にパスフレーズをつける(暗号化方式はaes256を使用する)
$ openssl rsa -in private-key.pem -out private-key-with-pass-phrase.pem -aes256
writing RSA key
Enter PEM pass phrase: # 任意のパスフレーズを入力
Verifying - Enter PEM pass phrase: # パスフレーズを再入力
$ ls
decrypted-data.txt encrypted-data.txt private-key.pem private-key-with-pass-phrase.pem public-key.pem

パスフレーズつきの秘密鍵を使って何かしようとすると,
必ずパスフレーズの入力を求められる.
このため, 万が一第三者に秘密鍵が流出してもパスフレーズがわからない限りは暗号データを復号化できない.

# 秘密鍵で暗号データを復号化しようとするとパスフレーズを要求される
$ openssl rsautl -decrypt -in encrypted-data.txt -out decrypted-data.txt -inkey private-key-with-pass-phrase.pem
Enter pass phrase for private-key-with-pass-phrase.pem: # 間違ったパスフレーズを入力
unable to load Private Key
# パスフレーズが違うので秘密鍵が使えない

ただパスフレーズがあると面倒なパターンもあるので,
これを外すこともできる.

# パスフレーズを外す
$ openssl rsa -in private-key-with-pass-phrase.pem -out private-key-without-pass-phrase.pem
Enter pass phrase for private-key-with-pass-phrase.pem: # 正しいパスフレーズを入力
writing RSA key

# パスフレーズが要求されなくなる
$ openssl rsautl -decrypt -in encrypted-data.txt -out decrypted-data.txt -inkey private-key-without-pass-phrase.pem

おわり

実際に手を動かして試したおかげでちょっとは理解が深まった気がする.
公開鍵暗号方式だけではまだセキュリティに問題があるので(暗号化/復号化の計算量や公開鍵の信頼性など),
時間があればハイブリッド暗号方式とかデジタル証明書についても実際に試してみたい.