武尊山其の弐

1月の頭にすでに一回武尊山行ったことあるが、その時は雪山登山の予定が吹雪に阻止された。コロナで自宅待機するのも飽きて車借りてもう一回挑戦しに行ってきた。結果から発表すると、今回は無事山頂に立てた。


GitOps and Kubernetes persistence

A while back I wrote about bootstrapping a Kubernetes cluster. I’ve been refining the setup so that it requires as little manual kubectl‘ing as possible. I still use ArgoCD to get everything rolling, and there is one bit that kept going red: persistent volumes.


Return to Kumotori

While other countries have pretty harsh lockdown rules (from what I hear on the news), Japan is pretty lax about that. While commuting to work by train is discouraged, I figured going up in the mountains (where there are hardly any people) it can’t hurt, right?


武尊山其の壱

以前行った北アの穂高とは間違わないこと。上越の武尊山は群馬の奥利根にあって北アの穂高よりは高さ1000m程低いが、雪が豊富。今回の計画ではスキー場のシャトルバス使って、スキー場の麓からリフト使わずに山頂に登って、そして下りてからスキー場を満喫する予定だった。予定は予定で実行はまた別物…

川場スキー場に着くまでは予定通りだった。上毛高原まで新幹線で、そこからは直結のシャトルバスで(バスは要予約なので注意)。電車からも晴れ予報がそうじゃないように見えたけど、スキー場に着いたら普通に吹雪だった。それでも上行ってみようと思った。ただ途中で徒歩はご遠慮くださいみたいな標識があったか飽きたか記憶が曖昧が上まで結局リフトで行った。そして上に着いたら登山はしない判断した。

吹雪で視界がほとんどなく、雪の中で道どころか足あと一つすらなかった。さすがに地図でしか見たことない山の、腰ぐらいの深い新雪に、スノーシューがなく踏み入れるほど狂ってはいない。スキー場もあって雪山登山に人気な山かと思ったけど、天気が悪いせいか見かけた他の登山装備の人も皆諦めたと言ってた。

無念ではあったがスキー場で楽しく一日スノボしてた。


Tanigawa-dake

If you’ve watched Yama no Susume, then you’ve heard of Mt Tanigawa. It’s the goal of a major arc of the story and an important memory to the characters. I went there in a different season though (in the snow), but didn’t climb the main summit. For no particular reason other than I didn’t realize the summit I was at wasn’t the highest point. Whoops.


2019 in review

This year was quite thick in events so I decided to write a year retrospect for a change. I read somewhere that people tend to do wild things when they’re nearing a “round” age like 30, except I read about this after I planned most of the stuff listed below… It definitely did turn into a very eventful 30th.


ArgoCD bootstrap cluster

I wish it could be completely automated… But for now I’ve just automated as much as possible (and convenient). The ingredients:

  • Helm
  • Sealed Secrets
  • Argo CD and Argo Rollouts
  • traefik
  • Prometheus and Grafana

I have a repository for the purposes of playing around with Kubernetes tooling like this – and hopefully turn it into an actual application eventually. I have big plans and lots of stuff I want to try out, but time is limited. All the code examples in this post use the namespaces and naming choices in the repository. The folder structure (relevant to this bit) is like…

system
 ├┬ apps
 │└─ (bootstrapped Argo CD app manifests)
 ├┬ argo
 │└─ the local "umbrella chart" for Argo CD and Argo Rollouts
 ├┬ bootstrap
 │└─ boilerplate project and application manifests
 └┬ manifests
  └─ manifests I didn't bother turning into a Helm chart
     referenced by the raw-manifests.yaml application

メトリクスで完全自動カナリヤデプロイ

アプリコードを変えました。後は機械がなんとかするはずのところ、そこから何十分もかかる手動のデプロイ作業が待っていた。アプリが動く台が増えるとその時間も台数の分だけ倍増する。

理想は、コードの変更がgit上で主ブランチにコミットとして現れたら、CI/CDパイプラインがコンテナイメージを生成して(マージ前にすでにテストが通っている前提)本番環境にカナリヤの方式でデプロイされる。


可変個! 可変個! そして手動gensym!

Clojureを紹介する記事はよくマクロの存在を最強の武器としてあげているが、実際にマクロはそう頻繁には使わない気がする。個人的にマクロを作る目印になるのはとあるウィキの記事に書いてある基準。

C++を主にみたデザインパターンの考え方の批判で指摘されるのは、ああやってパターンを繰り返し適応するのはまだコード化できてないなんらかの抽象化があることを示している。

コードに規則性や繰り返しが現れるのは、今使っている抽象化が十分ではない印。例えばマクロに任せるべきコード展開を手動でやっている。

Paul Graham: Revenge of the nerds

Collapse of the docker0 bridge

We’ve got a printer in the office. I’m not sure how the network is organized, but it’s on a different IP range than the rest of the dev network. And for some reason I couldn’t get it to work.