22時ぐらいから寝始めて何度か起きて6時に起きた。早く寝たから早く起きた。

selinux の微妙な振る舞い

今日は火曜日なのでチームの定例会議をやって、ドキュメントを書いて、その後はインフラの細かい作業をわちゃわちゃやって、ドキュメントを書いてとわちゃわちゃやってた。

先週、最新の almalinux 8 をインストールして、その後、lvm の論理ボリュームの結合 とか、rootless コンテナ の設定とか、テスト環境を構築していた。gitlab ci/cd から ssh で公開鍵認証を使ってデプロイしている。作り直したこのテスト環境に対してその公開鍵認証がうまく動かない現象に遭遇した。よくある設定や権限のトラブルではなく、デバッグ用の sshd を起動すると公開鍵認証できた。なにかしら systemd 経由で起動する sshd の設定ミスなんじゃないかと、2-3時間デバッグしてもわからなくて社内の有識者に尋ねてみた。

$ sudo /usr/sbin/sshd -d -p 2222

selinux を無効にしてみたら？というアドバイスをいただいて、試しに enforced から disabled にしたら動いたので selinux のなにかしらの設定を変えてしまったのかな？とそのときは思っていた。しかし、別の開発者からデフォルト設定で enforced でも動くはずという情報をもらって、もう一度 disabled から enforced に戻して再起動したら普通に動いて、その前の公開鍵認証の失敗を再現できなくなった。私にはこの先のデバッグはまったくわからない。お手伝い先のシニアエンジニアの方にみてもらって次のようなことを教えてもらった。

SElinuxが怪しいなと思ったら、/var/log/audit/audit.log とかausearch -m avcコマンドを確認。
authorized_keysのアクセスが拒否されているので確かにSELinuxの問題があったことがわかります。
type=AVC msg=audit(1696315292.258:1446): avc: denied { read } for pid=446534 comm=“sshd” name=“authorized_keys” dev=“dm-0” ino=201836096 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=file permissive=0
現在、authorized_keysのコンテキストは期待通りunconfined_u:object_r:ssh_home_t:s0となっているけど、問題が起きていたときは、unconfined_u:object_r:default_t:s0 だったことがわかります。
詳しい経緯はわからないけど、.ssh/authorized_keysを作成した時点でopenssh用のselinuxポリシーが適用されていなかったと考えられます。
その後なにかのイベント(再起動?)でrestorecon 相当が行われて、コンテキストがssh_home_tに変更され問題は解消した。
なんだかよくわかないけど、OSのマイナーバージョンアップで微妙にセキュリティコンテキストが変更されてrestoreconすると解決する、ってのは時々起きてますね。
たぶんopensshインストール前にrsyncしたのでコンテキストがdefault_tになってたんじゃないかと。なかなかの罠ですね。

おそらく lvm の論理ボリュームのバックアップ／リストアに rsync -a を使った (本当は cp -aの方がよい) ことによる問題ではないかということ。私が報告した状況と selinux のログからすぐ助言できるのが素晴らしいと思う。まだまだ私のインフラエンジニアとしての未熟さを実感した瞬間でもあった。一昔前は selinux は disabled にするものという常識だったが、最近は初期設定で動くようになっているのでなるべく selinux は有効にして運用するものという意識に変わってきているらしい。

1時に寝て何度か起きて5時に起きた。それからだらだらして寝てまた7時に起きた。

テスト環境の再整備と rootless コンテナ

インフラの式年遷宮のようなことをしていて、テスト環境をリファクタリングして再整備していた。これまで root でコンテナを実行していたが、最近は rootless コンテナがセキュリティ強化の観点から望ましいということで次のドキュメントをみながら設定した。

• Linux post-installation steps for Docker Engine

設定はとくに難しくないが、dockerd や containerd の起動を systemd のユーザーインスタンスに依存することになる。systemd のユーザーインスタンスは基本的にユーザーがログインしたときに生成されるものなので OS が再起動したときなどに困る。OS 再起動時にも systemd のユーザーインスタンスを生成するには linger という仕組みを有効にすればよいらしい。systemd –user の扱いと linger のことまで理解していれば、たぶん大丈夫なのかな？これで運用がうまくいくことを祈りたい。

$ sudo loginctl enable-linger ucidm

0時に寝て何度か起きて7時に起きた。最近は寝る前にはてブのアプリで適当に記事を読みながら寝ることが多い。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。

• 今後のお手伝いの展望
• fun/done/learn をカスタマイズする話し
• hugo のテンプレートを作る話し
• 課題管理のコンテンツを作っていく話し

ここ1-2週間ぼーっとしていて、忙しくもなく、なにかやっているわけでもないけど、のんびり過ごしている。軽いバーンアウトだと思う。先週末は休みも取った。「hugo のテンプレート作り」のような新規開発を、どこかのもくもく会やイベントに行って、その場で集中してやったらいいんじゃないか？というアドバイスをいただいて、確かにそういうやり方もよいように思えた。今週末は課題管理のコンテンツを考えて、できればブログに書いてみようと思う。

lvm の論理ボリュームの結合

新規に almalinux 8 で仮想マシンを作った。デフォルト設定でインストールしたら / と /home でパーティション分割されていて、これは使い勝手が悪いなと思ってパーティションを結合することにした。

$ df -h
ファイルシス               サイズ  使用  残り 使用% マウント位置
devtmpfs                     1.9G     0  1.9G    0% /dev
tmpfs                        2.0G     0  2.0G    0% /dev/shm
tmpfs                        2.0G  8.6M  2.0G    1% /run
tmpfs                        2.0G     0  2.0G    0% /sys/fs/cgroup
/dev/mapper/almalinux-root    70G  6.5G   64G   10% /
/dev/mapper/almalinux-home   437G  5.0G  432G    2% /home
/dev/vda1                   1014M  221M  794M   22% /boot
tmpfs                        393M   12K  393M    1% /run/user/1000

基本的には次の記事をみてやったらうまくいった。

• How to merge two or more disk partitions on Centos 7

/home をバックアップする

# mkdir /home-bkup
# cp -a /home/ /home-bkup/

emergency モードに入る？

# systemctl emergency

結合したい領域を unmount して、home の論理ボリュームを削除する。

# umount /dev/mapper/almalinux-home
# lvremove /dev/mapper/almalinux-home
Do you really want to remove active logical volume almalinux/home? [y/n]: y
  Logical volume "home" successfully removed.

バックアップからデータを戻す。

# cp -a /home-bkup/ /home/

/etc/fstab から不要なパーティション設定を削除する。

# vi /etc/fstab
...
/dev/mapper/almalinux-home  /home  xfs  defaults  0  0  # <- この行を削除
...

root の論理ボリュームに余っている領域を拡張する。

# lvextend -l +100%FREE -r /dev/mapper/almalinux-root
  Size of logical volume almalinux/root changed from 70.00 GiB (17920 extents) to <507.04 GiB (129802 extents).
  Logical volume almalinux/root successfully resized.
meta-data=/dev/mapper/almalinux-root isize=512    agcount=4, agsize=4587520 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=0 inobtcount=0
data     =                       bsize=4096   blocks=18350080, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=8960, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 18350080 to 132917248

この時点で1つの領域に結合されたことがわかる。

# df -h
ファイルシス               サイズ  使用  残り 使用% マウント位置
devtmpfs                     1.9G     0  1.9G    0% /dev
tmpfs                        2.0G     0  2.0G    0% /dev/shm
tmpfs                        2.0G   78M  1.9G    4% /run
tmpfs                        2.0G     0  2.0G    0% /sys/fs/cgroup
/dev/mapper/almalinux-root   508G   14G  494G    3% /
/dev/vda1                   1014M  221M  794M   22% /boot

バックアップを削除する。

# rm -rf /home-bkup/

マシンを再起動する。

# reboot

これで問題なければ完了。

23時に寝て何度か起きて7時に起きた。出張帰りでなんかバテててなにもせず休んでいた。少し喉に引っかかりがある。出張で飲み歩いたし、そろそろコロナ感染？の疑いをもって生活してみる。

podman と dbus-daemon とsystemd の調査

2次開発の成果物をドッグフーディングの目的で社内へ導入する。メンバーが作業していて nginx が正常に動作しないという。ログをみろとすぐにコンテナネットワーク内の dns サービスが正常に動いていないということはわかった。podman は aardvark-dns というサービスを使って dns を管理する。但し、このサービスがまだまだ安定していなくて不具合があるのを以前にも確認した。このサービスの振る舞いがよく分からなくて、意図しない状況や状態に対して正常に動作してくれない。

他にも調査をしていて rootless で podman コマンドを実行すると次の issue で書かれているようなワーニングが出力される。dbus-user-session というパッケージを導入すれば解決するとある。

• WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available #12983

dbus-daemon のサービスは systemd で動いていて、systemd のユーザーモードと dbus が正常に動いていないというところまではすぐに分かった。その状態だと rootless な podman が正常に動作しないということもすぐに分かった。ここまではすぐに調査できたが、問題はどうやれば sytemd のユーザーモードを dbus を正常に動くように復旧できるのかがまったく分からない。systemd がそもそも難しいのに、そのユーザーモードは権限管理が関係するのでさらにもっと難しい。1日調べてお手上げで他の社員さんにも相談してみた。

今日は自分の作業は進捗しなかったけど、メンバーの作業の進捗をみていて、メンバーがはまっていたところを助言して、その問題は解決してうまくいって、それだけで満足していた。

1時に寝て何度か起きて7時に起きた。昨日は少し早めにお仕事を終えて家で休んでいたので少し回復した。

msgraph-sdk-go を使った開発

昨日の続き 。前日に作ったマージリクエストをチームのメンバーにレビューしてもらっていくつか修正して、マージを終えた。一段落。

さらにこの sdk を使うことで8月の前半に開発していた差分比較のところも変更しないといけないことに気付いた。public な構造体のメンバーにアクセスして差分比較する処理を実装していたが、この sdk は getter で構造体のメンバーにアクセスしないといけないことに気付いた。reflectoin の処理に追加で実装を入れるだけなのでそんなに難しくはない。そういった修正をしていたら1日終わってしまった。開発していると時間が過ぎるのは早い。

たまたま ci/cd ジョブの実行時間の上限を10分にしていて超えるときがあってジョブが失敗した。 調べてみると、msgraph-sdk-go の api が巨大過ぎてメモリを浪費したりコンパイルに時間がかかったりするという issue をみつけた。

• Memory Leak when creating msgraph client #436

私のローカル環境で測ってみると、約36秒で完了していたテストが2分23秒かかるようになっていた。テストの実行が4-5倍ぐらい遅くなった。さらにコンテナイメージのサイズは 36 MiB から 109 MiB と3倍ほど増えた。無駄に開発を遅らせる環境要因になっているのでこれは別途調査して対応しないといけないことに気付いた。

2時に寝て6時に起きて7時に起きた。夜に作業していたら遅くなった。

厄介なインフラの問題 解決編

運用のトラブルシューティング の続き。アプリケーションアカウントを作って compose 環境を構築したら nginx のコンテナが起動して即時終了する状態になったという。これまで起きていた現象とまた違う問題が発生してさらに混迷をもたらすかに思えたが、私の中では nginx のコンテナでなにかがおかしいと問題の発生箇所を局所化できたのでそこからの調査はそんなに時間を必要としなかった。

結論からいうと podman の aardvark-dns の不具合だった。なんらかのトリガーでコンテナネットワーク内の名前解決が不整合な状態に陥る。

vagrant@bookworm:$ podman-compose exec proxy /bin/bash
...
root@3742c45c7c60:/# dig app

; <<>> DiG 9.16.37-Debian <<>> app
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56696
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 37ff0fd63315d70e (echoed)
;; QUESTION SECTION:
;app.				IN	A

;; ANSWER SECTION:
app.			86400	IN	A	10.89.0.36
app.			86400	IN	A	10.89.0.36
app.			86400	IN	A	10.89.0.136
app.			86400	IN	A	10.89.0.136
app.			86400	IN	A	10.89.0.146
app.			86400	IN	A	10.89.0.146
app.			86400	IN	A	10.89.0.156
app.			86400	IN	A	10.89.0.156

;; Query time: 4 msec
;; SERVER: 10.89.0.1#53(10.89.0.1)
;; WHEN: Thu Jun 22 02:45:26 UTC 2023
;; MSG SIZE  rcvd: 172

podman 4.0 から aardvark-dns がコンテナネットワーク内での dns を提供する。nginx が app を名前解決したときに起動しているコンテナの ip アドレスではなく、削除された過去のコンテナの ip アドレスが返される状況が発生する。app という名前に対して複数の ip アドレスが返る。

このとき nginx は複数の ip アドレスのうちの1つに接続しようとするが、正しい ip アドレスでない場合、リクエストがタイムアウトする。タイムアウトした後に fallback で他の ip アドレスに接続しにいく。このときに正しい ip アドレスがみつかればクライアントにレスポンスが返る。この fallback のリトライの回数分だけリクエストのレイテンシの時間がかかっていた。

vagrant@bookworm:$ podman logs -f proxy
...
2023/06/22 02:46:26 [error] 15#15: *41 connect() failed (113: No route to host) while connecting to upstream, client: 10.89.0.38, server: ucidmsv1-app, request: "GET / HTTP/1.1", upstream: "http://10.89.0.136:3000/", host: "localhost:4430"
2023/06/22 02:46:29 [error] 15#15: *41 connect() failed (113: No route to host) while connecting to upstream, client: 10.89.0.38, server: ucidmsv1-app, request: "GET / HTTP/1.1", upstream: "http://10.89.0.156:3000/", host: "localhost:4430"
2023/06/22 02:46:32 [error] 15#15: *41 connect() failed (113: No route to host) while connecting to upstream, client: 10.89.0.38, server: ucidmsv1-app, request: "GET / HTTP/1.1", upstream: "http://10.89.0.136:3000/", host: "localhost:4430"
10.89.0.38 - - [22/Jun/2023:02:46:32 +0000] "GET / HTTP/1.1" 200 2864 "-" "curl/7.88.1"

ワークアラウンドとして、次のファイルに複数の app の ip アドレスが登録されていれば不整合な状態なのでネットワークを削除して、このファイルも手動で削除してしまえばよい。

$ cat /run/user/$(id -u)/containers/networks/aardvark-dns/mynetwork

ファイルを監視していると、どうやら mynetwork ファイルから名前と ip アドレスの情報が削除されるのは該当のコンテナが削除されるタイミングになる。なんらかのエラーにより、コンテナ削除時にマッピングの削除が実行されないと、古いコンテナのマッピング設定が残ったままとなり、compose サービスを起動したときに複数の ip アドレスの名前解決できる状態になってしまう。ちょっと調べても aardvark-dns に関する issue はたくさん登録されている。

• https://github.com/containers/podman/issues/18783
• https://github.com/containers/podman/issues/18530
• https://github.com/containers/podman/issues/17370

コワーキングのオンラインイベント

月例のカフーツさんのオンラインイベントに参加した。先月の所感はここ 。今日はもともと予定していた話しをする参加者が急遽参加できなくなってしまったので他の参加者での雑談会になった。

いとうさん曰く、これまで外国人のデジタルノマドは自分で業務時間を選べるフリーランスの、さらにお金に余裕をもった人たちが多いと考えられていた。しかし、実際にコワーキングスペースに来られている外国人にキャリアを伺うと、大企業の普通の社員であることがわかってきた。グローバルな会社だと、働く場所に制限のない会社もあって、ただ日本へ行ってみたかった的な理由で日本へ来られて数ヶ月滞在して普通に会社のお仕事をするといったデジタルノマドもいるという。過去に私が働いていた職場の同僚も、コロナのときに会社がフルリモートワークの体制を設けて、airbnb で全国を旅しながら1年ほど働いていた。日本でもそういう社員はいるのだから外国人はなおさらという感じ。

そういった外国人のデジタルノマドが要求することが3つある。

• 24時間利用できること (勤め先の会社と時差があるから)
• セカンドモニターがあること
• ・・・ (あともう1つあったが、忘れてしまった)

コワーキングスペースに外国人のデジタルノマドを呼び込むにはどうすればよいか。実際にコワーキングスペースへ来られた外国人に理由を伺うと英語のホームページをみて来ましたということらしい。至極、当たり前の話し。英語のホームページをちゃんと作ろうねみたいな話題で話していた。

0時に寝て5時に起きて7時に起きた。もう暑くて家でもエアコンを解禁した。エアコンがあると寝心地が違う、快適。

運用のトラブルシューティング

厄介なインフラの問題 のクリティカルな方から着手し始めた。podman-compose を使って rootless な環境構築をやってみたところ、nginx を tls 終端としてリバースプロキシとするアプリケーションサーバーとの通信が数回に1回ぐらいの頻度で遅くなる。通常は 100msec 程度でレスポンスが返るのが数秒から数十秒かかる。

もともと podman-compose はサポート対象外なのでそんながんばる必要はない。しかし、これも調査の過程でコンテナの技術を学ぶ1つだと考え再現環境を構築しようとした。vagrant の debian 12 と podman-compose をインストールして同様に環境構築してみたが、仮想環境では再現しない。どうやら環境要因のようだ。そこで問題が発生しているマシンで私のアカウントで環境構築してみたが、やはり再現しない。なんと個人アカウントの違いによって起きる現象のようだ。また質が悪いのは私のアカウントでは再現しないが、メンバー2人のアカウントでは再現している。一般ユーザーから他人のユーザーのプロセスやコンテナの情報にアクセスできるわけがないので調査ができない。個人アカウントで compose 環境を構築するのは諦めてアプリケーションアカウントを作ってやりましょうという話しにした。アプリケーションアカウントで再現すれば調査するし、再現しなければこんな環境要因のトラブルシューティングの優先度を下げてもいいかなぁとも考えている。どうなるかなぁ。

サイトデザインのサンプルページ

サイトデザイン打ち合わせ の続き。実際のサンプルが出てきたのでデザインの雰囲気やコードも含めて確認していく。ざっとサンプルページを確認した。デザインはとても気に入っている。あとは私が hugo のテーマとしてテンプレートの組み込めるかどうか次第。今週末には実家帰らないといけないし、毎日やることがいっぱいいっぱい。

2時に寝て何度か起きて7時に起きた。今日は勉強会の登板なのになにも準備できてなくてどうしようとか思いながら寝た。

パッケージングとリリースのドキュメント

5月の落ち穂拾いの時期にプロジェクトの開発ドキュメントを刷新していろいろな要項を書き残している。最後に残ったまだ書いていないドキュメントに次の2つがある。水曜日から課題管理やコードレビューの隙間時間に書き出していって3日ほどかけて一通り書き終えた。私は文章を書くのが遅いのと、1回ですべての内容を網羅できなくて、書いているうちに思い出して追記したり、寝かした文章をあとで見返して推敲したりすることが多い。そのため、ドキュメントを1週間ぐらいかけて書いたりする。

• パッケージング
• リリース

たまたまメンバーにあるモジュールをリファクタリングのために再実装してもらっている。その開発を完了したら古いモジュールと入れ替える必要があるので、開発だけではなく、パッケージングやリリース周りの作業を把握してもらう、よい機会と言える。これまでパッケージングやリリース周りのインフラはほとんど私が作って運用をまわしてきたので徐々にそれらを引き継ぐタイミングとも言える。開発者はインフラのことを気にせず、アプリケーションを開発してコミットすれば後はすべて ci/cd が自動的にいろいろやってくれて便利ぐらいの感覚で扱えるようにするのが、外資系などではプラットフォームに投資しろと言われたりするものだと推測する。うちらが開発しているプロダクトはコンテナ、RPM、Windows インストーラーとパッケージングする種類が多い。その要項に加えて QA 責任の考え方などについても書いておいた。主には私がいなくなった後に役に立つドキュメントとなるだろう。

チーム勉強会

本当は go の generics の勉強会をやりますと先週宣言していた。しかし、私が遊んでいて全然準備できなかったので代わりに決済とスマートプラグの話しをした。先週末と月曜日 に作った決済とスマートプラグを組み合わせたもの。サービスや仕組みを簡単に説明して、実際にデモを動かして電球を灯す。

参加者からスマートプラグをラズベリーパイに置き換えてパワーリレーというモジュールを使えばもっとスマートにできるんじゃないかという意見が出た。たしかにラズベリーパイなら stripe の決済イベントを受け取るサーバーをデバイス内に同梱させることもできるかもしれない。そうすると、スマートプラグのような電源の on/off だけではなく、ラズベリーパイが扱えるセンサーとインテグレーションすることもできそう。また時間のあるときにやってみたい。コラボレーションって正にこういうことを言うとわかってきた。私が1人でこの仕組みを実装していたときにはラズベリーパイというキーワードはまったく頭の中になかった。他者の視点が加わるから新しいアイディアが広がる。

3時に寝て7時に起きた。昨日は連休明け初日なのに2時まで作業していた。開発が落ち着いたので夜に自社のお仕事をする余力が戻ってきたとも言える。

Docker についてのテックブログ執筆

先日から Docker エコシステムの調査 をして、そこでわかったことをテックブログとしてまとめていた。一通り書き終えてマージリクエストを作成して社内レビューを依頼した。当初は 「ライブラリとしての Docker とは何か？」 というタイトルで書いていたものの、レビューを経て「ライブラリとしての」という修飾は必要ないことに気付いた。そのまま Docker のコンポーネントのソフトウェアスタックや過去の経緯や現状の雰囲気がわかるような記事にした。Docker を中心としたコンテナプラットフォームと標準化の概要について追っていく記事に仕上がった。インフラに関心をもつ人たちは少ないかもしれないけど、個人的にはコンテナの学びになってよい記事に仕上がったと思う。調査と執筆とレビューを含めると5人日ぐらいかけている。かけた工数を考えれば当然と言えるかもしれない。

デザイナーさんと契約締結

昨日の続き。デザイナーさんからいただいたワイヤーフレームをレビューして、契約書の叩き台も送付して、先方の所感や意見も伺いながら契約を締結した。基本的にはこちらが提示した契約書の通りに進んだのでとくに揉めることなくうまくいったと言える。顧問のはらさんからデザイナーと契約をするときの要項を事前にヒアリングしていて、その詳細を盛り込めんたこともよかったと思える。サイトデザインをお願いするものの、hugo のテンプレートは私が実装しないといけない。ある意味デザイナーと協調してサイトデザインを構築すると言えるかもしれない。私もそこから学ぶ機会があるだろうし、その過程でできた成果物は hugo のテーマとして oss で公開したい。

0時に寝て何度か起きて7時に起きた。休んでもよかったんだけど、休む理由がないので飛び石でお仕事することにした。

docker エコシステムの調査

少し前に docker をライブラリとして使って運用ツールを作った 。その内容をテックブログに書こうと思って docker のソフトウェアスタックやアーキテクチャの背景を調べ直していた。もっとたくさんいろんな記事を読んだのだけど、次の記事とそこから辿れるものを読むとよいだろうと思う。

• Docker社がエンタープライズ事業を譲渡した今、Dockerの父が思うこと
• The differences between Docker, containerd, CRI-O and runc
  • Red Hat, Google Engineers Work on a Way for Kubernetes to Run Containers Without Docker

コンテナに関して cri と oci という2つの標準化があることを学び、その実装として docker 社が使っているツールに関係があるのが次の3つになる。おもしろいことにすべて docker 社のリポジトリにはなく、oss として然るべき所管の organization にリポジトリがある。

• https://github.com/moby/moby
• https://github.com/opencontainers/runc
• https://github.com/containerd/containerd

すべて docker 社がオリジナルを作って、いまも moby は docker 社が主体となって開発を継続しているだろうけれど、コンテナの実行環境のプラットフォームは k8s に取って変わられ、cri のコンテナランタイムとしての containerd があれば moby は docker daemon や docker engine のためのツールでしかなくなっている。当初 docker と moby を分割したのは、docker を開発ツール、moby を infrastructure にするという判断の下、moby を k8s のようなプラットフォームにしたかったはずである。しかし、結果的にその標準化競争に破れ containerd があれば dockerd daemon は不要になったとも解釈できる。docker という名前はコンテナのエコシステムにおいて docker 社が提供するコマンドラインやプロダクトの総称としての名前でしかなくなってしまっていて、一世を風靡した docker というパッケージングシステムの開発元に同情してしまう感もある。いまの docker engine は docker daemon と containerd の2つの daemon を起動していて docker 社としては微妙なアーキテクチャになっているのではないかと推測する。とくに swarm なんか最早削除したいだろう。

こういった docker を取り巻くエコシステムやツールの背景を説明するだけでも1つの記事になりそうなことが1日調べていてわかった。

しくじり先生

たまたま 竹原慎二先生「５０歳過ぎてもケンカを売られ続けてバリしんどい先生」 をみたらおもしろかった。ガチンコをリアルタイムでみていた世代なので竹原氏には好感をもっている。少し前に 【あの人の健康法】元プロボクサー・竹原慎二の膀胱（ぼうこう）がんとの闘い のような、闘病生活の記事もみかけていた。病気は克服してがんばっているといるようにみえる。よかった。もう51歳なのか。

この番組の中で若い頃に上京してボクシングジムへ通ったときに根性の定義が変わったという話しが出てくる。

殴られても耐えることを根性だと思っていた。そのときに初めて殴られようが何しようが毎日辛い練習を重ねるのが根性だと気付かされた。

地元で最強だったのが、ボクシングジムのヤンキーでもない先輩にまったく太刀打ちできなかったという。そのとき1番違うのはスタミナだったらしく、竹原氏は1分で息がきれるのに相手は軽く流すといった様相だった。この先輩にボコボコにされた経験を経てそれから心を改めて真面目になったと言う。その後ボクシングと真剣に向き合い、1995年に日本人初のミドル級世界チャンピオンになる。おそらく番組の主旨的に若ものへのメッセージとして「強さ」について話されていた。

「ケンカに強い」だけが「強さ」じゃない、「強さ」の意味を履き違えずに生きよう。大人になると、いろんな強さを知る。大切な人のために仕事をどれだけ頑張れるか、辛い状況でもじっと耐えることができるか。そういう強さもある。

私は誰かのために仕事をがんばったことないし、辛い状況を耐えるみたいなこともほぼやってなくて、嫌になったら仕事を辞めてて、こういう言葉にあうと自分を恥じてしまう。その後、喧嘩自慢で youtube 動画を検索していたらまさにそういうのがあった。竹原氏が「勝てるはずねぇだろ、お前らこんな茶番なことすんなよ」とぼやいていた。先の番組の中でも触れていたが、本当に真剣勝負したいと思って来ているのではなく、記念に戦ってみたいという不純な動機でやってくる人が多いらしい。たしかにそれは相手するのがしんどそう。

0時に寝て5時に起きて7時に起きた。起きたら冷やしたのかお腹痛かったが、まぁまぁ眠れたと思う。

テスト環境の構築

GitLab CI/CD にだいぶ慣れてきてジョブを追加したり改善したりしながらようやくアプリケーションの docker image もコンテナレジストリに push されるようになった。それを pull してきて、テスト環境を docker compose で構築する。Use Compose in production とドキュメントでは威勢がよいが、これが全然イケてない。複数の compose.yml で項目によっては変更したいところを置き換えるといった振る舞いになっていない。例えば、ポート番号などを dev と prod で置き換えたいといった運用の要件を考える。

• dev.yml

services:
  myapp:
    ports:
      - 18080:8080

• prod.yml

services:
  myapp:
    ports:
      - 8080:8080

これを次のように指定すると、

$ docker compose -f dev.yml -f prod.yml up -d

実際のサービスは次のように振る舞う。全然あかん。

services:
  myapp:
    ports:
      - 18080:8080
      - 8080:8080

他にもそれぞれの yml ファイルで読み込む environment file のマージなどもよくわからない振る舞いをしていて複数の compose.yml で制御するのは断念した。dry の原則に反して設定は重複するけど、それぞれの環境を個別に compose.yml として管理した方が保守コストは小さくなると私は判断した。複数の compose.yml の使い分けのデバッグを1-2日やった後に諦めてテスト環境の構築は完了した。

年金事務所の住所変更手続き

先週 法務局で法人登記の変更申請 をしていて、そのときに問題がなければ今日から登記事項証明書を取得できると案内をもらっていた。決定書が漏れていて再提出というトラブルはあったものの、最小限の損失で留めたせいか、問題なく登記事項証明書を発行できた。住所の変更だけわかればよいので履歴事項証明書ではなく現在事項証明書を発行してみた。この書類もおもしろくて1つ前の住所といまの住所の2つを確認できる。法務局へ行った帰りに年金事務所へ立ち寄って社会保険の住所変更の手続きを行った。次の3つの書類をもって窓口へ。

• 登記事項証明書: 番地まで記載されている
• オフィスの一時使用契約書: ビル名はあるがこのビル名は来月に改名
• ビル名変更の証明書類: ビル名の変更のみが記載されている

この3つの書類で完全に指定された住所 (Fully Qualified Address: 造語) を丁寧に説明したところ担当者に納得してもらえて事なきを得た。