ローカルにコンテナレジストリを構築する

出張する日は寝ないで資料を作ったりバグ修正したりして始発の新幹線の中で寝てた。寝てなくて疲れているせいか、新幹線で寝るのに慣れたのか、わりと2-3時間ぐっすり新幹線で眠れるようになってきた。普通にベッドで寝ても3時間ぐらいしか眠れないので睡眠時間はあまり変わらない。

docker registry の構築

先日の調査 の続き。Deploy a registry server に書いてあることを実際にローカルで検証した。

tls の自己証明書の作成。subjectAltName という設定をするように書いてある。

$ openssl req -newkey rsa:4096 -nodes -sha256 -keyout certs/domain.key -addext "subjectAltName = DNS:myhost.mydomain.example.com" -x509 -days 365 -out certs/domain.crt

basic 認証のための htpasswd の設定。htpasswd とか懐かしいなと思いながら実行した。

$ docker run --entrypoint htpasswd httpd:2 -Bbn user1 secret1 >> dot_htpasswd
$ docker run --entrypoint htpasswd httpd:2 -Bbn user2 secret2 >> dot_htpasswd

docker 社が提供する oss な docker registry サーバーを使って起動する。

$ mkdir /mnt/registry  # docker image を永続化する場所
$ sudo docker run -d \
  --restart=always \
  --name registry \
  -v "$(pwd)"/auth:/auth \
  -e "REGISTRY_AUTH=htpasswd" \
  -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
  -e "REGISTRY_AUTH_HTPASSWD_PATH=/auth/dot_htpasswd" \
  -v "$(pwd)"/certs:/certs \
  -e "REGISTRY_HTTP_ADDR=0.0.0.0:443" \
  -e "REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt" \
  -e "REGISTRY_HTTP_TLS_KEY=/certs/domain.key" \
  -p 8443:443 \
  -v /mnt/registry:/var/lib/registry \
  registry:2

これで basic 認証付きで https で通信できる docker registry サーバーができた。

外部のマシンから dokcer login しようとすると次のようなエラーが発生する。

$ docker login myhost.mydomain.example.com:8443
Username: user2
Password: ***
Error response from daemon: Get "https://myhost.mydomain.example.com:8443/v2/": x509: certificate signed by unknown authority

Test an insecure registry によると、自己証明書を使って外部からアクセスできるようにするためには docker client 側にさっき作った domain.crt をコピーする必要がある。

linux だとこんな設定。

$ cp domain.crt /etc/docker/certs.d/myhost.mydomain.example.com:8443/ca.crt 

Docker Desktop for Mac を使っている場合はこんな感じ。

> security add-trusted-cert -d -r trustRoot -k ~/Library/Keychains/login.keychain path/to/certs/domain.crt

これで外部からも docker login して任意の docker image を push/pull できるようになる。docker registry サーバーは Let’s Encrypt をサポートしているそうなので How It Works を参照して設定すればよいと書いてあった。

mdbook の初期設定

mdbook は新しい rust のバージョンだとビルドできなかったりするので rustup を使ってローカルに rustc をインストールするのがよいかもしれない。プラグインとしては mdbook-mermaid を使う。

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
$ ~/.cargo/bin/rustc --version
$ cargo install mdbook mdbook-mermaid

mdbook-mermaid の設定も簡単でドキュメントルート配下に mermaid の js ファイルを配置すると動いた。

$ vi book.toml
[preprocessor.mermaid]
command = "mdbook-mermaid"

[output.html]
additional-js = ["mermaid.min.js", "mermaid-init.js"]

事務手続き時々お出かけ

0時に寝て4時に起きて6時に起きて8時ぐらいまでだらだらしてた。出張前にプロジェクトの進捗を確認したり近況報告の資料を作ったり。

Mon copain (モン・コパン)

出張するときはお土産をもっていく ようにしていて、2月の中旬からお土産を探す余裕もなくてネタ切れでどうしようと思っていたものの、朝から調べてたら パティスリー モンプリュ というお店をみつけた。 Mon copain というガトーショコラの詰め合わせを選んでみた。ガトーショコラをあまり買ったことも食べたこともないので試しに購入してみた。本当は私が味見してからお土産にするかどうかを選定する (自分が食べてイマイチなものはお土産に持っていかない) のだが、先月からそんな余裕がなくて、お店を信頼して自分用と一緒にその場で購入したりしている。単品だと3個入りを1セットで購入できる。税込で580円になる。

それぞれ上から次になる。

  • 茶色の包み: au lait キャラメルのコクが味わい深いミルク・ショコラ
  • 白色の包み: blanc ほんのりレモンが香るホワイト・ショコラ
  • 焦げ茶の包み: noir ほろ苦さが大人味のスイート・ショコラ

しっとり柔らかい口当たりで上品な風味だった。神戸の洋菓子屋さんという印象がそのままのお菓子。甘いが甘過ぎない雰囲気でよいと思う。3つとも食感は似ているが、どれも風味がまったく違うので全部食べてみるのも楽しめると思う。お土産として量と値段のバランスも取れていてちょうどよかった。全然調査していなくても、即席でよいお店がみつかるのは神戸という地域のよさだと思う。

夜のお花見 at 生田川公園

昨年に引き続き生田川公園 で三ノ宮.devのお花見。今年は夜桜にしようと夕方から始めることに。私は16時ぐらいから車で買い出しへ行って17時ぐらいから参加してきた。ここ2-3週間ほど車を動かす機会を伺っていてできなかったのが、明確な目的があると車を動かすことができてよかった。初めて近所のスーパーマーケットへ車で出掛けて駐車場に停めて買いものしてきた。15分ほどで買いものして、駐車場から出るときに220円必要だった。後で調べると500円以上購入すると120分無料になったらしい。レジで駐車券ありませんか?と聞かれて車に忘れてきていたので無料化のための手続きができなかった。次回から持参するための学びの1つとなった。その後、生田川公園へ移動して、付近をまわりながらパーキングのスポットをみつけることもできた。次のお花見はまた来年になるけど、そのときに役立つはず。

昨年は4人だったのが今年は7人参加していた。昨年よりは三ノ宮.devも少し成長したのかもしれない。1月に起業相談 されていた方も来ていて、その後、デザイナーや開発者をみつけることができて、プロダクト開発をしているらしい。3ヶ月でさっそくピボットしましたという話しをしていて、起業したばかりだとそんなもんだと私も思う。うまくいっているように話していたのでよかったと思う。これから海外に3ヶ月ぐらい出かけるといった話しもされていてスケールの大きい人だなと聞いてた。

17時頃から始めて20時半でお開きになった。街灯の近くの場所をとったので暗くなっても灯りは問題なかった。始めたときは涼しくてちょうどよかったものの、さすがに20時をまわると寒くて解散することにした。私も20-21時ぐらいで帰ろうと思っていたのでちょうどよかった。食べものも飲みものもそんなに外してはなかったが、せっかく車があったので最初にコアメンバーに声を掛けて買い出しに行ってもよかったなと思えた。私が余裕なくて段取りできなかったせいでもある。16時から始めて19時に終える花見のやり方もあることを学んだ。

請求書の即時払い

今月から請求書の支払いを即時払いに切り替えることにした。いまお手伝いしているお客さんは当社から請求書を送ると即時払いしてくれる。これまで取り引きしてきたお客さんは翌月末払いが普通だったのでそういうものだと思い込んでいた。私も無条件でその慣習に従っていた。もちろん契約上の支払い期限そのものは翌月末に設定しているが、支払いを即時で行うことに問題はなにもない。

キャッシュフローの視点から「回収は早く支払いは遅く」の原則がある。レバレッジを効かせた経営 (資金繰り) をするなら正しいが、うちみたいな会社が支払いを1ヶ月遅くするメリットは何もない。これまでは請求書を受け取ったときに会計システムに取り引き登録して、銀行口座から1ヶ月後に予約振り込みの登録をしていた。そして、実際に振り込みされた1ヶ月後に、銀行の振り込み明細と会計システムの取り引き明細を付き合わせて決済が完了となる。請求書を受け取ったときに即時払いにすると、タイミング的に1ヶ月ずれる2度の事務手続きを1度にまとめられる。一言でいうと事務手続きの効率化になる。

うちみたいな会社にとっては請求書の即時払いをすると、事務手続きの工数を少なくできるというメリットがあることに気付いた。こんな簡単なことにこれまで気付いていなかったわけではないのだが、私の目が曇っていたのか、慣習に引き摺られて気付かない振りをしていた。自分の頭で考えること、実際に実践してみることの重要性を改めて学んだ。

まったく終わっていない年度始まり

23時に寝て何度か起きて7時に起きた。久しぶりに早めにお仕事を終えて、気分転換に出掛けて、帰ってきてすぐ寝てたかな。

年度を気にしている余裕がない

お仕事の納期が4月末でまだ余談を許さない状況と言える。2ヶ月以上遅延している、ある開発作業の最後の作業をメンバーから私に担当を付け替えている。前任者が作業を終えたら私がクリティカルパスになるようにしておいて、なる早で終わらせて開発を完了させたい。リリースまであと3週間なのに code freeze すらできていないという、マネジメントとしては失態を続けている。前任者が作業を終えるのを見計らって私が休出しつつ段取りを組んで正しいスケジュールに引き戻そうと調整している。

ストレッチ

今日の開脚幅は開始前154cmで、ストレッチ後158cmだった。今週は (私個人の) 開発のピークを過ぎて後半は余裕があったので体にかかる負荷も少なかったのではないかと想像していたら、ストレッチを受けていても先週より調子がよいように思えた。右股関節付近の張りは継続しているものの、腰の張りもひどくなく、すねの外側の筋も問題なく、ここ1-2ヶ月ぐらいではもっとも調子がよかったかもしれないと思えた。トレーナーさんも今日は目立って悪いところはなさそうとコメントしていたぐらい。

個人カンファレンス

ストレッチを終えてからオフィスへ行って tenntenn Conference 2023 に参加した。個人が1日中話しまくるという取り組みそのものがおもしろい。自社のお仕事をしながら並行で視聴していた。パネルディスカッション (個人カンファレンスなのにモデラーとパネラーがいて、どうやら同じ人物っぽい人が相互に話していたw) のときに次のような質問があった。

Q. なぜ個人カンファレンスをやっているのか?

A. あまり深い意味はなく、誰もやっていないので思いつきでやっている

私のような無名の開発者が個人カンファレンスを開いても誰も参加してくれないと想定される。個人カンファレンスが成り立つ開発者の知名度やコンテンツを選択するのはすごく難しいと思う。個人カンファレンスの取り組みをみていて会社のテックカンファレンスを1人でやってみるというのもおもしろそうに思えた。うちの会社は課題管理を中核にビジネスを進めていく。その一環でコンテンツをいくつも作っていく必要がある。そして、コンテンツが溜まってきたらカンファレンス形式にして一気に放出するという取り組みをいずれやってみてもよいかもしれない。

他には 昨日の雑談会 にも書いたことで、オンラインの勉強会で参加者とインタラクティブにやり取りする難しさをこの個人カンファレンスをみていても感じた。登録で300人超、そのうち6割参加で180人ぐらいが参加していると仮定して、インタラクティブにコメントしているのは数人ほどしかいなかったと思う。私も他の作業と並行しつつ、ながらで視聴していたのでインタラクティブなコメントなどはしなかった。たまに twitter に所感を投稿するぐらい。基本的にオンライン勉強会でインタラクティブなやり取りを求めず、オフラインで3-4人集まってインタラクティブにやり取りする内容をコンテンツとして流すというのがよいのかもしれないなと、視聴していて思ったりもした。

Q. 有料の勉強会を始めたきっかけは?

A. お仕事じゃないとまとまった時間を使うことに家族の了承を得られにくいと考えたから

私も有料勉強会に参加しているので興味があった。主催者が転職の隙間時間を使う理由を家族に理解してもらうためだったと話されていた。私も過去に同居人がいたときに自分の時間を勉強したり、飲み会へ行ったりするのを非難された時期があったので理解できる。私はいまや調べものや勉強をしている時間が一番幸せを感じる。私にとって他のことを考えずに集中している状態がその時間に相当する。疲れてただ寝ているときもたまにある。しかし、それはあの時間を勉強や仕事に割り当てていたらもっとうまく物事を進められたのに、、、と後になって自己嫌悪になって返ってくるときがある。いまは何をなしても満たされることはなくて、常になにかをなし続けている状態そのものに満たされる。

閑話休題。あとでアーカイブも公開されるそうなので関心がある発表はまた見返すと思う。generics 周りと静的解析に関するところに私は関心をもっている。他に個人カンファレンスをやっている人を私はみかけたことがないけれど、こういう新しい取り組みに挑戦する人は本当に尊敬できる。

chatgpt の調べものと整理して雑談した

1時に寝て6時に起きた。昨日は chatgpt の調べものをしていたら帰るのが遅くなった。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。3月はお仕事が忙しかったのでこの前はお休みして1ヶ月ぶりの雑談。主には 来季の予算 について話していた。

予算を策定するときに今回から消費税を経費に含めるとよいのではないかと考えた。というのは、法人税は赤字のときにゼロになるので売上と経費を算定したときに利益が多ければ発生するだけで利益を帳消しにするといったことはない。しかし、消費税は損益に関係なく仕入よりも売上にかかる消費税が多い場合に支払う必要がある。ここで経費の大半に相当する人件費 (給与) には消費税がかからないことから損益がゼロだったとしても消費税を支払うと赤字になるといった状況は考えられる。売上よりも仕入で支払った消費税の方が多かった場合、消費税は還付されることになるが、うちは簡易課税を選択しているので売上の消費税に対して50%を支払うことになる。簡易課税の場合、最小の消費税がゼロ (つまり売上がゼロ) であり、仕入にどれだけ消費税を支払ったとしても還付は発生しない。とはいえ、通常の事業運営をすれば仕入の消費税が売上よりも多くなるといったことは発生しない。

オフィス引越しや社用車の購入に関して前年よりも固定費は増えている。それは仕方ないとして、その他に無駄遣いをしているわけでもないので来季は赤字前提の予算を見積もる。いまのところ、お仕事は半年ぐらいしかやらない予定になる。仮にそれ以上働くことになったとしても、そのときは売上が増えて財務的には助かることになる。お仕事があってもなくてもどちらでもよいという展望で予算策定を終えた。

社員数を調べるハック

たまたまタイムラインで 厚生年金保険・健康保険 適用事業所検索システム というシステムで毎月20日時点での厚生年金保険・健康保険の被保険者数を調べられることを知った。未上場の会社だと社員数を公表する義務がないので規模感が分からないことがある。スタートアップやベンチャー企業で話題になっている会社の規模感を調べるときなどに役に立つかもしれない。試しに過去に私が働いた会社でその後どうなったのだろう?と調べてみたら私が在籍していた当時よりも人数は減っているもののまだ被保険者数がいたので会社は存続していることがわかった。会社の栄枯盛衰を測る指標の1つとして社員数は使えると思うので業界研究の手法の1つとしてよいかもしれない。

chatgpt 勉強会

今週のチーム勉強会は私が担当して chatgpt についての雑談会とした。と言っても、ほとんど私が一方的に話す感じであまり雑談会にはならなかった。オンライン勉強会で雑談会を運営するのはすごく難しい。意図的に質問やツッコミを入れるという役割を参加者に課さないと雑談会を運営するのは難しいのかもしれない。勉強会で発表すると、自分で学ぶきっかけになるのでちょうどよかった。お手伝い先でも slack に chatgpt の api を用いた bot を実装してチャットで質問できるようになっている。何人かは身近に chatgpt を使って振る舞いを確認したりもしている。雑談会では次の内容で gpt (llm) とはどういうものなのか、また chatgpt の使い方が従来にはなかったものを私が知っている中で共有した。今後もしばらくは注目していこうと思う。

  • OpenAI/ChatGPT 概要
  • ChatGPT の使い方
  • GPT 以後の世界

コンテナレジストリをプライベートに運用する

0時に寝て7時に起きた。晩ご飯を食べきれなくて調子悪いと思っていたら夜も吐き気と胃酸で気分が悪くてあまり眠れなかった。

外部向けコンテナレジストリ

いまお仕事で作っているアプリケーションは docker image としてパッケージングしている。エンドユーザーがこのアプリケーションを使うためには docker pull できるためにインターネットを経由してアクセスできる必要がある。普段はイントラネットのコンテナレジストリに push/pull して運用しているのを、外部のエンドユーザー向けにアクセスできるコンテナレジストリ (リポジトリ) を構築しないといけない。パブリックなリポジトリとして提供するのであれば、docker hubGitHub Container registry などを無料で利用できる。しかし、プライベートなリポジトリで運用しようとするとその選択肢は狭まってしまう。おそらく他社のサービスを使うのであれば、実際の運用を考慮するといくらか費用がかかるだろう。

仮に docker image が使うストレージを5GiB、インターネットへの outbound なデータ転送を30GiB/月で見積もってみた。docker hub だと利用量によって課金されないのでその後に利用増加が前提であればよさそうにみえる。

  • github (従量課金)

  • aws (従量課金)

    • region=tokyo: $3.92/month, $47.04/year
  • docker hub (容量無制限)

別の選択肢として自前でコンテナレジストリを運用するという方法もある。docker registry サーバーは oss として公開されていて docker image の push/pull をするだけのサーバーならすぐに構築できる。ベーシック認証に近い v1 の認証でよければ htpasswd を使ってアカウント管理できる。

ドメインと tls の証明書と外部からアクセスできるサーバーがあれば、自前で運用するのもそう大変ではないと思う。実際にこれらの運用コストと他サービスの利用料金とを比べて選択することになるだろう。

gitlab packages api の使い方

0時に寝て何度か起きて6時半に起きた。先週より少し早く起きれるようになってきた。

gitlab ci/cd で別プロジェクト (リポジトリ) の成果物を取得する

gitlab では複数のパッケージリポジトリに対応しているが、それらに当てはまらない汎用の成果物向けに GitLab Generic Packages Repository というものがある。zip でもバイナリファイルでも何でも置くためのリポジトリと言える。但し、同じパッケージ名でバージョン管理するといった作りにはなっていなくて、同じパッケージ名でアップロードしても別のパッケージ id が割り当てられて管理される。他バージョンとの紐付け自体はできているので、おそらく歴史的経緯でそういう仕様なのだと思う。そのために、あるパッケージの最新のバージョンを取得したいときは作成日の降順でソートして最初のパッケージを取得するといったコードを書かないといけない。それは Packages API を駆使して簡単なスクリプトを書くことになる。

もう1つ分からないことにトークンの使い分けがある。なるべく ci/cd での処理は GitLab CI/CD job token を使いたいところだが、どうも Packages API の呼び出しはできなくて別途プロジェクトでアクセストークンを作成して呼び出すようにしている。これはもしかしたら別の設定で CI/CD job token でも呼び出しできるかもしれない。rest api への呼び出し権限そのものがないのかもしれない。

最終的には次のようなスクリプトで任意のプロジェクトの generic リポジトリの最新の成果物を取得できた。

rm -rf ${TARGET_DIR}
mkdir -p ${TARGET_DIR}
for project in $PROJECTS
do
  prj=$(echo "$project" | jq -Rr @uri)
  base="${CI_API_V4_URL}/projects/${prj}"
  pkg=$(curl -s -H "PRIVATE-TOKEN: $PROJECT_ACCESS_TOKEN" "${base}/packages?order_by=created_at&sort=desc&per_page=1" | jq '.[0]')
  pkg_id=$(echo $pkg | jq -r .id)
  pkg_name=$(echo $pkg | jq -r .name)
  pkg_version=$(echo $pkg | jq -r .version)
  file_names=$(curl -s -H "PRIVATE-TOKEN: $PROJECT_ACCESS_TOKEN" "${base}/packages/${pkg_id}/package_files" | jq -r '.[].file_name')
  for file_name in $file_names
  do
    dw_endpoint="${base}/packages/generic/${pkg_name}/${pkg_version}/${file_name}"
    curl -s -H "PRIVATE-TOKEN: $PROJECT_ACCESS_TOKEN" "${dw_endpoint}" -o "${TARGET_DIR}/${file_name}"
  done
done
find ${TARGET_DIR} -type f

財布の置き場所を忘れる

3時に寝て7時に起きた。

昨日の夜に リベンジャー の最終回をみてよかった。

週次の定例会議を終えて、テスト環境の再作成を待ったり、compose.yml をデプロイするための rpm のパッケージングするための gitlab ci/cd の rest api などを調べたり、これといって特筆するようなことのない1日だった。

財布を失いかけた

家に帰るときになって財布がないことに気付いた。お昼にお弁当を購入したときに財布を使ったのでお昼まではあった。お弁当を食べるために家に帰ったのでそのときに家に置き忘れたのかな?と思って、一旦家に帰ったけど、財布はない。財布を落としてしまったんだなとがっかりして家とオフィスの道中に財布が落ちていないかを確認しつつ、もう一度オフィスへ戻った。オフィスでも一通り調べていたところ、引き出しの中から出てきた。

お昼にレシートとクレジットカードの明細をホッチキスで閉じるときに引き出しからホッチキスを取り出して、そのときにホッチキスと一緒に財布を引き出しの中にしまっていたようだ。まったく記憶になくて無意識でそうしていた。歳をとるとたまにはそういうことがあるのか、そろそろ認知能力が落ちきているのか、そんなことも起きるんだという失敗談になった。まったく自分が信頼できない。

docker/compose のモジュールの使い方がわかってきた

0時に寝て7時に起きた。前日はバテてだらだらしていたので寝過ぎた。

案ずるよりもツールできた

先週末に docker/compose 関連のライブラリ調査 を終えて実際のツール作りをしていた。本当は日曜日に作ってしまおうと思いつつ休んでしまった。なぜか今日はメンバーが全員お休みでチームで私しか働いていなかった。年度末で有休消化しているのかな?問い合わせ対応やメンバーのサポートが不要だったので1日中、自分の開発に集中できた。そして開発に集中できた結果、一通りツールの機能の開発を終えられた。火曜日までには仕上げたいと思っていたのでぎりぎり間に合った。

最終的に testcontainers-go の compose モジュールを使うのは断念して compose cli のみ go 標準の os/exec パッケージを使ってプロセスを fork するようにした。また docker image をコンテナレジストリから取得するときに認証が必要な場合、最初の docker login すると credentials store にパスワード (またはトークン) 情報が記録される。設定情報は $HOME/.docker/config.json からも確認できる。この仕組みを使ってコンテナレジストリへのログインを自動化できる。私の環境では macbook に docker desktop をインストールしているが、普通に使っていると次のように credentials が保存されてその内容を確認できる。

$ docker-credential-desktop list | jq .
{
  "https://index.docker.io/v1/": "t2y1979",
  "https://index.docker.io/v1/access-token": "t2y1979",
  "https://index.docker.io/v1/refresh-token": "t2y1979"
}
$ echo "https://index.docker.io/v1/access-token" | docker-credential-desktop get
{"ServerURL":"https://index.docker.io/v1/access-token","Username":"t2y1979","Secret":"***"}

これと同じことを docker のライブラリで行うには次のようにする。取得したい docker image の uri を参照すればコンテナレジストリがわかる。そこからこの cli でやっているようなことを順番にやっていけばよい。これらのユーティリティは3つのリポジトリで管理されていて、この雰囲気をみただけでもこのモジュール分割が本当に適切なんやろか?とか思ったりもする。

func getRegistryAuthFromImage(
	ctx context.Context, imageURI string,
) (string, error) {
	ref, err := reference.ParseNormalizedNamed(imageURI)
	if err != nil {
		return "", fmt.Errorf("failed to parse image uri: %w", err)
	}
	repo, err := registry.ParseRepositoryInfo(ref)
	if err != nil {
		return "", fmt.Errorf("failed to parse repository: %w", err)
	}
	dcli, err := command.NewDockerCli()
	if err != nil {
		return "", fmt.Errorf("failed to create docker cli: %w", err)
	}
	auth := command.ResolveAuthConfig(ctx, dcli, repo.Index)
	encoded, err := command.EncodeAuthToBase64(auth)
	if err != nil {
		return "", fmt.Errorf("failed to encode auth: %w", err)
	}
	return encoded, nil
}

春休み 2日目

2週間前に引き続き 今日も春休み。昨日まではお仕事のツール開発をしようと思っていたのだがバテた。

人は変わる

たまたまはてブで 立花さんとの対談について というエントリを読んだ。この記事だけではなんのことかわからないので、川上さんと立花さんの対談の動画を検索してみた。動画は2時間半ぐらいあった。 いや、実際にはみていない。みようとしたが、みる価値がなさそうなので飛ばし飛ばしで15分ぐらいしかみていない。みなくてよいと思う。おっさん同士が並行線のまま口喧嘩しているだけの動画だった。ちゃんとみてないから間違っているかもしれないが。

ニコニコ動画が youtube と競っていた頃、2012年頃かな?それぐらいの時期のときにニコニコ動画を応援していたし、そのときに川上さんは時代の寵児のようにみえた。川上さんの対談や記事をたくさん読んだし、著書である コンテンツの秘密 も素晴らしい本だと思う。ある時からなんか時代にあわない発言をされるように感じていた。カドカワの後継者になって身の丈を超えてしまったのか、インターネット規制の議論で体制側になってしまったからなのか、私の価値観の方向性とはあわなくなってしまった。最近はあまり活躍をみないと思っていて、たまたまみたものが口喧嘩の動画でさらにがっかりした。

過去に偉大な実績を残された方が歳を経て退化するような現象は他にもいくつかある。自分が周りからみてどのようにみえているか、私にはわからないが、謙虚に真摯に目の前のことに向き合って取り組むようにしたい。相手に敬意をもって接するといった当たり前のことができなくならないよう、気をつけたいと思えた。

ubuntu のインストール

1時に寝て5時に起きて7時に起きた。今週も開発に集中していたのでバテ気味。時間がなくて2ヶ月以上行ってなかった散髪に行ってきた。前髪が目にかかって鬱陶しかったのでいつもよりも短くしてもらった。頭が軽いと日々の生活のストレスも軽減しそう。

ストレッチ

今日の開脚幅は開始前153cmで、ストレッチ後153cmだった。ストレッチ後の開脚幅はいつもとは計り方を変えたので数値は低くなっているが普段と同じぐらいのものだろう。すねの外側の筋は気にならないぐらいになったので復調したと言っていいだろう。今日は右股関節から太ももにかけての張りと右腰の張りが大きかった。今週も根を詰めて長時間オフィスで作業していたので座っているとかかる部位の負荷が高くなっていると想定される。納期が4月末なのでこの生活はもうしばらく続くといったところ。

dell マシンに ubuntu をインストール

いつも通りオフィスで会社の事務手続きをしながら、並行して 購入した dell マシン に ubuntu をインストールする。いまお仕事で開発しているアプリケーションの成果物は amd64 をターゲットにしているのでローカルに amd64 の開発環境がないとインフラ周りやコンテナ周りの検証に一手間かかる。この状況を解消するために早くローカルの dell マシンを置き換えて開発環境を構築したい。dvd-r から ubuntu 22.04.01 (サイズ超過で dvd-r におさまらなくて 22.04.02 は断念) のインストールを行う。bios で一時的に secure boot の機能を無効にしないと署名チェックで起動しなかった。インストール作業中に予期せぬ不具合が発生しました的なポップアップが2-3回発生したけど、無視して継続できた。インストールして普通に起動すればいいやと緩い感覚で進めた。いつもはパーティションも自分で設定したりしているけれど、今回は windows 領域を残してデュアルブートな環境にしてみた。ディスク領域もインストーラーから windows 領域を 160GiB、残りをすべて ubuntu 領域にするといった設定ができた。すごい簡単。余裕があるときに windows の wsl を使うのも試してみれればと思う。

コンテナの運用ツールを作る

1時に寝て明け方に起きて7時に起きた。あまり眠れてない雰囲気がある。

docker/compose の運用

いま作っているアプリケーションは docker compose で構成している。マージ単位で gitlab ci/cd から docker image をビルドしていて、テスト環境のデプロイスクリプトで最新の docker image を取得してコンテナを再作成するようにしている。デプロイスクリプトは docker cli と docker compose cli の2つを組み合わせてシェルスクリプトで実装しているが、複数のアプリケーションやミドルウェアがあるのでそれらを統合的に扱うことはできないし、さまざまな状況を想定して動くようにもなっていない。がんばれば doccker/compose cli と jq とシェルスクリプトで細かい要件を実装することもできるけど、それをお客さんの本番環境においても使うには一定の cli 操作に慣れが必要な上、docker/compose の知識やスキルも要求してしまう。少なくとも頻繁にある運用作業として docker image の更新やコンテナの再作成が想定される。ローリングアップデートまでは実装しないけど、アプリケーションの要件にあわせた docker image の更新とコンテナの再作成 (アプリケーションの再起動) ぐらいはまとめてやってしまってよいと思う。

github.com/docker/docker は github.com/moby/moby にリダイレクトされる。docker は開発ツール、moby はインフラやライブラリという住み分けでそれぞれに関心のあることに注力するようにモジュール構成を分離している。それが2019年に行われていまもおそらくまだ途上だと思う。あと docker のモジュール群は go modules に対応していない。大きなプロジェクトが移行するのが大変なのは理解できるけれど、依存解決のような複雑なところを放置するのはまったく賛成できない。そこが不健全だと依存ライブラリの整理やモジュール分割がうまく進まない気がする。docker の client は https://github.com/moby/moby/tree/master/client に定義されていて、readme のサンプルコードにあるようにすぐに使えるようになっている。一方で compose の spec は github.com/compose-spec/compose-go で定義されていて、github.com/docker/compose はまだライブラリとして使いやすいようにはなっていない。仕様と実装が混在していて動いている状態。そういう issue もあげられている。

testcontainers-go というアプリケーションが compose をライブラリとして使う実装をしている。このコードをみれば compose をどう使えばよいのかはわかる。

自分で compose を実装してもよいけれど、compose の service を扱うための project やオプションの設定が煩雑なことも伺える。仕様と実装が混在しているというのはそこら変の整理ができていないようにみえるからだ。testcontainers-go も自前の client を用意して使いやすいようにしているのでそれを再利用した方が運用ツールを作るのは簡単になる。testcontainers-go の compose client 経由で compose の up/down を制御する。その他のコンテナの操作は docker client を直接使って実装する。この組み合わせで自分たちのアプリケーション向けの運用ツールを作ろうと思う。