flaky test の調査のためにテスト中で使う変数でもログに出すようにする

というのを最近試みている。

これまで遭遇してきた flaky test の多くは比較的単純な原因だった。コードを少し眺めたり、乱数が原因で落ちたテストのシード値を指定するだけで再現できることが多かったため、あまり困っていなかった。

しかし、最近遭遇したテストは、並行で実行されるテストで作られるデータと競合していたため、調査が難航していた。 周辺コードや既存のログを読んでも原因が全く分からなかったため、テストの前後で変数をダンプするログを追加して、しばらく CI の様子を観察していた。 すると、調査が一気に進み、flaky test の修正も可能になりました。

この件から、普通のアプリケーションの不具合調査の際と同じように、情報を増やすためにログを仕込むテクニックが flaly test の修正でも有効であることを認識してきた。 特に、テスト実行中だとデバッガもないので、変数の中身が出るくらいで情報は大幅に増えることがわかった。

違う話題だと、世の中には flaky test の実際の修正方法についてはあまり言及されていなさそうと思って調べてみたら、以下のブログを見つけた。 Railsプロジェクト以外でも共通するパターンがまとめられており、参考になりそう。

note.com

エスパー力を発揮したり怪しいところにログを仕込むなどして見つけるしかないこともあります。

やっていきましょう。

Emacs Lispで感じた書き散らすプログラミング体験

この記事は、はてなエンジニア Advent Calendar 2023の2024年1月16日の記事です。

昨日は id:fxwx23 さんによる「Simulator.app の「Stay On Top」をキーボードショートカットで切り替える」でした。 かゆい所に手が届かないこと、よくありますよね。その際にシュッとスクリプトを書いたりして不便を解消する姿は見習いたいと思います。

始めに

自分は普段テキストエディタEmacs を使っています。 EmacsEmacs Lisp というプログラミング言語でエディタの設定を記述できますが、今まで設定を記述する以外の目的で Emacs Lisp を書いたことがなく、プログラムっぽいプログラムを書いたことはありませんでした。

ふとこのことが気になって、年末年始の休みに簡単なプログラムを作ってみました。

実際に書いてみると、他の言語ではあまり体験したことのないようなプログラミング体験が出来ました。 ここでは Emacs Lispプログラミング言語として書いたときに得たプログラミング体験と、その感想について書いています。

Emacs Lisp でのプログラミング体験

LTSV 文字列をリストに変換する関数の実装を進めることを例として見ていきます。 以下は実装の一例です。Lisp について知らなくても、雰囲気でも何をやっているかがわかると思います。

(defun parse-ltsv-string (ltsv-string)
  "引数の LTSV の文字列を リストのリストにする ((key1 value1) (key2 value2))."
  (let ((values '()))
    (dolist (pair (split-string ltsv-string "\t"))
      (let ((key-value (split-string pair ":")))
        (push key-value values)))
    values))

(parse-ltsv-string "key:value\tname:miki_bene")
;; => (("name" "miki_bene") ("key" "value"))

この関数の実装過程で 4行目の (split-string ltsv-string "\t") の返り値が実際にどんな値が返るのか、確認してみたかったとします。 他の言語なら REPL を起動したり、ブラウザ上で実行できる Playground で試したりするところですが、Emacseval-last-sexp *1というコマンドを使うことで Emacs 上で実行が出来ます。

(defun parse-ltsv-string (ltsv-string)
 ...
)

;; 以下のコードの括弧の末尾にカーソルを配置し、
;; C-x C-e キーバインドで eval-last-sexp コマンドを実行する
(split-string "key:value\tname:miki_bene")
;; => ミニバッファに ("key:value" "name:miki_bene") が表示される

このように、編集しているプログラムから全く離れずに書いたコードを実行できます。

また、eval-last-sexp はどこでも実行できるので、例えば関数の中で全然違う処理をいきなり書いて実行することも出来ます。

(defun parse-ltsv-string (ltsv-string)
  ...

  ;; dolist でループ処理を行う際の動きを見たいので
  ;; *Messages* バッファに文字列を出力する
  (dolist (pair (split-string "key:value\tname:miki_bene" "\t"))
    (message "%s" pair)) ;; ここで C-x C-e コマンドを実行する
  ;; => *Messages* バッファに
  ;; key:value
  ;; name:miki_bene
  ;; nil
  ;; が出力される
  
  ;; 以下は書いている途中の処理
  (let ((values '()))
  ...
)

実は最初のコードもコマンドラインで実行した結果ではなく、Emacs 上で評価した結果を貼りつけているだけでした。

感想

例のように、Emacs Lisp では今書いているプログラムからほとんど離れずに処理を試したり、関数を実行できます。

実際に Emacs Lisp を書いていた際は、関数定義中の処理の中に具体的な値を入れて試す→動くことを確認したら値を変数に置き換えて続きを書き進める→また確認したくなったら具体的な値を入れて試す……を繰り返しながら実装を進めていました。 この繰り返しをすると気づいたらプログラムが出来上がっており、書いたプログラムが動くことの確信がほぼ持てているといった状態になっていました。

他のプログラミング言語で実装を進める際も似たようなことは行っているはずですが、Emacs Lisp の場合は処理の記述と実行の間がとてもシームレスで、絶え間無くプログラムを書き進められる感覚がありました。

もちろん Lisp 自体でつまずくことはあったので、言うほど絶え間無くではありませんでした。 ただ、書いてすぐに実行してフィードバックが返る素朴な楽しさがありました。

関数の中で全然違う処理を書いて実行できるのは滅茶苦茶だなと思いつつも、好きな場所に好きに書いても実行できる感覚は真っ白な自由帳に落書きを書いているみたいで、それも楽しくありました。

他のエディタで類似の機能はないのか

Emacs Lisp 以外で同様のものはないかと探してみると、VSCode の拡張に似た機能がありました。 選択した範囲を REPL に流し込み実行できるといったもので、割と感覚は近いかもしれません。

ただし Emacs Lisp の場合は評価した結果が残るので、以前評価されていれば選択していない部分の関数定義やライブラリ読み込みも使えるのは大きな違いかもしれません。 評価が残ってしまうのは意図しない結果になる時もありますが、その場で実行する場面においては基本利便性の方が高いだろうと感じています。

まとめ

Emacs Lisp を書いて、他の言語ではあまり体験できない実装体験が出来ました。 普段の業務では Perl や Go, TypeScript を書いています。これらの言語が悪いわけではない(むしろ静的型付けの方が好ましい)ですが、普段はあまり感じない書き散らす楽しさを久しぶりに感じました。

たまにはこういった自由帳のような言語で遊んでみるのもよいかもしれません。

はてなエンジニア Advent Calendar 2023、明日は id:hagihala さんです!

YAPC::Kyoto 2023 に参加してきた

3月18, 19日の2日間、YAPC::Kyoto 2023 に参加してきました。

yapcjapan.org

4年ぶりのリアルイベント

ここまで大きなリアルイベントは2019年に参加した YAPC::Tokyo 2019 以来で4年ぶりの参加だった。

リアルの会場に行って人と話すイベントはやっぱり良いものだなと思い直した2日間だと思った。

発表を聞いたり他の参加者の人と話したりすると「自分も何かしたいな」とか「コード書きたいな」など不思議とやる気になれる。

これが刺激になるって感覚なのかもしれないけど、この感覚を本当に久し振りに得ることが出来てとてもよかったと思う。

会話しに行く感覚を忘れていたことの若干の心残り

色々な人と話をしたものの以前会ったことのある人とか終わった後の別の場での会話がメインだった。 やっぱり会場で話すってことをもう少しできるとよかったなと思っていて、そこがちょっと心残り。

いきなり発表を聞いた後隣の人に話しかけられるといいけれど、やっぱり何も無しで行くのはちょっと抵抗感があるので、懇親会みたいな場があると嬉しい。

コロナ以前の他のイベントだけど、確か ScalaMatsuri でコーヒーを無限に飲めるスペースがあって、そこで隣にいる参加者と話すみたいな体験を思い出した。

あれはすごくよくて、コーヒーを飲む口実と場所があるお影で話しかける心理的ハードルを下げられる仕組みが整っていて、積極性が無い人間にも話しかける道具を与えてくれる感じがしてすごくよかった。

こういうことがが出来るといいけどまだ情勢的に微妙そうなのもすごくわかる。もしできればいつか是非……。

運営の皆様への感謝

これだけのイベントを準備してくださった運営の皆様、本当にありがとうございました!!!!!!!!!!!!!!!!!!!!!

イベント開催のための具体的な苦労は考えが及ばないことが多いけど、コロナ禍が落ち着いてきそうとはいえ本当に実施出来るのか、また延期になったりしないのか*1って不安はどうしてもあったと思うし、向こう1週間くらいまだ不安が残ると思う。 その中でも準備を進めてくれて開催してくださったのは本当にありがたかったです。そのお陰で上のような体験が出来たので本当に本当に感謝しかないと思っています。

繰り返しになりますが、YAPC::Kyoto 2023の準備してくださった運営・スタッフの皆様、本当にありがとうございました!!!!!!!!!!!!!!!!!!!!! 次の Hiroshima も行くぞ!!!!!!!!!!!!!!!

『今からはじめるインシデントレスポンス――事例で学ぶ組織を守るCSIRTの作り方』を読んだ

年始にリアル本屋で気なったので買ってみた。偶然にも買った2日後に CircleCI のインシデントが発生したけど、特に関係はない。

gihyo.jp

買った理由

CSIRT やインシデントレスポンスの本は色々あったけど、この本を選んだ理由は技術的な面ではなくて組織だったり運用面についてが書いてありそうだったから。

自分はフォレンジック調査だったり分析だったりのがっつりセキュリティの仕事をしているわけではないので、技術的なことがそこまで書いていない本の方がよいだろう。 また具体的な手法を知ってもそれを活かすのが難しいだろうと思っていた。

また目次を見ているとセキュリティ組織を作っていく中で現実によくありがちな課題について触れられていたのが印象的だったのもある。

  • 3-02 専任か兼任か
  • 4-02 経営層にCSIRTを認知させる
  • 5-06 目標設定と評価を行う
  • etc...

専任か兼任か経営層に〜 の文字だけでこれは悪くなさそうだなと思っていた。

感想

タイトル通り CSIRT の作り方が書いてある本だなと思う。強いて言うならば CSIRT を作るときに考えること・出てくる課題が書いてある本 で具体的にどう解決するかまでは書いてくれていない。 CSIRT について知らない人が CSIRT が何かについて把握し、この組織を作っていこうと思った際に考えることが網羅されているといった様子。

1つ1つのテーマについて書かれていることが短くまとまっているので、その意味では読みやすい。 他方そのテーマについて課題に思っている人が解決策を求めていると期待外れになるだろう。

目次を読んだ時に思った現実の課題について触れられているかについては印象通りだった。 特に 第4章 CSIRTを立ち上げる - 4-05 ミッションを定義する で「決して背伸びをしない」ことが強調されていたのが印象的だった。 思えばセキュリティの事を考えるにあたって、領域を広げることを意識しすぎていた気がしなくもないと、これを読んで反省できた。

具体的なことがあまり書かれていないのは企業・組織毎によって解決策が千差万別だからではないかと想像している。 組織によって文化や状況、リソースなど変数が様々あるので、一般化しづらいことなのではと思った。

とは言え、テーマ毎にパターンを提示してくれているので、全く具体化されていないかと言うとそうでもないように感じる。 組織を作っていく中で課題が出てきた際の状況整理のツールとして利用できるのではと思った。

また既に CSIRT がある場合でも、自分のところの組織との比較が出来るのでその面でもよいと思った。

まとめると

  • タイトル通り CSIRT の作り方について考える本
  • 具体的な解決策が書いてあるわけではないが、現実に起こる課題についても触れられているので網羅性が高いように思う

CSIRT について考えている人がいたらとりあえずこれを読んでみることをお勧めできると思う。

1Password で SSH の鍵生成・管理、また Git のコミット署名を行うのが便利そう。今後はこれを使っていきたい

developer.1password.com

パスワード管理ソフトで有名な 1Password に SSH の鍵管理の機能が追加されていた。 新たにセットアップする機会がなかったのでスルーしていたが、セットアップ機会が訪れたので試してみたところ、思った以上に体験が良かった。

また GitHubSSH 鍵でコミットの署名・検証を行える機能が追加された。 これらが組み合さって、これまでの鍵管理やコミット署名と比べて手間無くセキュアに出来ることに気づいてきたので紹介してみる。

1Password での SSH 鍵生成/管理

まず、1Password 8 から SSH の鍵を生成 / 管理できるようになった。

blog.1password.com

詳しいやり方は上記のブログやドキュメントを見てもらう方がわかりやすい。

この機能を使った GitHub への鍵の登録イメージはブログにもあるこの動画を見てもらうと想像出来ると思う。

youtu.be

見ての通り、1Password 拡張を入れていればブラウザだけで SSH 鍵の生成と登録が出来るようになる。 自動で公開鍵をペーストしてくれるので、よくわからずに秘密鍵の方を貼り付けるといったこともなくなる。 さらに署名アルゴリズムのデフォルトが Ed25519 で生成するので、よくあるコピペそのままを使って RSA を利用するといったこともなくなる*1

1Password で生成した SSH 鍵を使い Git のコミット署名をする

次に 1Password で生成した SSH 鍵を使って Git のコミット署名を行うことについて説明する。

これまでも GitHub は GPG や S/MIME を使った署名・検証を行えたが、この8月の機能追加で SSH 鍵を使ったコミット署名の検証に対応した。

github.blog

そして2週間後、1Passwordを使いGitのコミット署名を行うブログが出た。これがビジネスのスピード感。

blog.1password.com

これも同じようにブログにある動画を見てもらった方がわかりやすい。

youtu.be

動画の通りわずか1分で署名用の鍵の登録と Git の設定が完了した。 上手く見せてるだけと思うかもしれないが、自分自身が試したときもこれと同じステップで設定が完了した。時間を使ったのはせいぜい 1Password に登録する名前を考えるくらい。

自分はこれらの機能が出る前から GitHub でコミット検証が出来るように設定していたが、1Password を使うやり方と比べたらはるかに手間や知識が必要と感じた。

基本的には GitHub が用意しているドキュメント通りにやれば出来るものの、GnuPGを入れたりCLI操作が必要だったり、コミットに署名するための設定を .gitconfig に追記したり等、様々な手順が必要だった。

コミット署名の検証を管理する - GitHub Docs

それがこの 1Password での SSH 鍵管理と GitHubSSH 鍵によるコミット検証対応で、非常に簡単な操作かつ追加のインストールを必要とせず行えるようになった。 このことの衝撃が多少なりとも伝わればと思う。

試してみた感想

既に書いてしまっているが、実際に試してみた感想や思ったことを書き出してみる。

SSH 鍵の管理を考えなくてよくなった

これまで真面目に鍵の管理を考えていたわけではないが、1Password に保存されることで全てをそちらに任せられる。

鍵の管理を意識するのは、特に端末を移行する際鍵をどう移行させるかといったときに考える。 もちろん移行はそこまで手間のかかる作業ではないが、面倒で新しく鍵を生成することもよくあった。

これが 1Password に保存されることで 1Password のセットアップさえ出来ればそれで済むことになり、管理だけでなく SSH 鍵のポータビリティが向上していると思う。

コミット署名の設定が楽

これは既に書いているが、コミット署名の設定が非常に楽になった。

追加のインストールが必要ないだけでなく、1Password が自動で .gitconfig に追記してくれるので、ボタン1クリックでコミット署名の設定が完了した。 デフォルトでコミット署名を行うようになるので、ユーザーは何も意識せずに署名と検証が出来るようになる。

これまでは設定が手間でコミット署名を行ってこなかった人も、こんなに簡単に出来るのなら設定しておくかと思うのではないか。

全ての開発者に Git のコミット署名をお願いしやすくなった

Git のコミット署名・検証は行えた方がよいとされているはず*2GitHub でどのアカウントによる変更か正しく追跡できるようになるし、Branch Protection Rule で署名付きコミットのみに制限することも可能になる。

しかし、Git のコミット署名は面倒だったので設定しないことが多かった。自分も面倒さのために最近まで設定できていなかった。 自分自身が出来ていないので、他人に勧めたりチームや会社のルールにして必須化するまでは考えにくかったが、この 1Password と GitHub の機能追加によって状況が変わったように思う。

ターミナル操作を行わなくても10クリック程度でコミット署名の設定が行えるようになったし、1Passwordで鍵のポータビリティが上がったことで鍵の移行も間違いなく出来る。

この利便性の向上によって、全ての開発者に Git のコミット署名の設定をお願いしやすくなったと思う。 ここでの開発者はエンジニアだけでなく、デザイナーなどの職種も含んでいる。

コミット署名はやれた方がいいが、他に優先させることがあれば後回しになる類の設定になると思う*3。 署名しなくても Git は使えるし、設定不備によるサポートの手間も考えなくてはいけなくなる。 署名によるセキュリティの向上具合を考えたら、他に取り組むべき課題を優先させることがあってもおかしくはないだろう。 しかし、10クリック程度で簡単に設定できるなら、簡単なので署名をしようという方向に出来ると思う。

SSH 鍵の管理と Git のコミット署名の設定の体験が良くなったことで、特別なことをせずにセキュリティを向上させられていると感じている。 このことは 1Password もブログに書いていて、複雑さを無くすことでセキュリティリスクを下げられることについて書いている。

blog.1password.com

気になるかもしれないこと

懸念もないわけではないので、書いておく。

SSH 鍵のパスフレーズを設定できない?

既にパスフレーズが設定されているものをインポートしたときは要求されたが、新規で作る際は要求されなかった。UIも見辺らないし今は実装されていないのかもしれない。

このパスフレーズ秘密鍵が窃取されたり、端末にアクセスされた際に利用されないようにするもの*4。 端末へアクセスについては 1Password のマスターパスワードで代替できているとしてもいいだろう。 一方秘密鍵が窃取された状況はカバー出来ていないかもしれない。 そう考えるとこれはやや微妙に感じるポイントかもしれないが、そもそも 1Password 保管庫にある情報が窃取されている状況はもっと深刻な被害になるような気はする……。

秘密鍵クラウド上に保管していいのか?

秘密鍵をローカルPC以外に保存したことがなかったので一瞬考えたが、既に重要なサービスの認証情報を 1Password に置いているのなら何も気にすることはないと思い杞憂であると思った。 むしろ秘密鍵~/.ssh/ 以下にそのまま置いてあるより安全なのではないか。 これはもう 1Password をどの程度信用するかに寄ると思う。

SSH 鍵をコミット署名に利用していいのか

GPG の方が確実で信用できる、といった議論が出来る知識は乏しいのでここでは議論しない。

使いものになるかの話で言うと、1Password で管理することで鍵のポータビリティが上がり同じ SSH 鍵を利用し続けるコストが低くなったため、署名・検証が機能するのではと考えている。

まとめ

1Password で SSH の鍵生成・管理、また Git のコミット署名を行うことについて紹介した。

第一印象は今すぐにでも広めたいくらいだが、まだ気づいていない問題点があるかもしれない。 実際私用で試し始めたばかりなので、しばらく使ってみて改めて振り返ってみようと思う。

パスワードレスの世界が本当に来そうなタイミングで、1Password が開発者向けツールを模索していることはとても納得がいく。 複雑さを無くすことでセキュリティリスクを下げるといったことにも共感するので、これからの動向にも期待したい。

参考情報

自分の行っているセキュリティ関連の情報収集

聞いてるポッドキャストでセキュリティ情報収集どうしているのかといった話題があった*1ので、いい機会だから自分の行っているセキュリティ関連の情報収集をまとめてみた。

前提

  • どんな人
    • セキュリティに興味あるWebアプリケーションエンジニア*2
  • 興味の範囲
    • Webアプリケーションにまつわるセキュリティ全般
    • サービス開発・運用まわりに関するセキュリティ
  • 知りたい情報
    • 関係ありそうな脆弱性情報
    • 興味範囲の最近の話題やトレンド
    • その他セキュリティ関係で話題になっていそうなこと

話題やトレンドはキーワードを拾い後から調べられるように脳にインデックスを作っておくのが目的で、網羅や詳細に知ることはあまり意識していない。

情報ソース

前提に書いた知りたい情報を、各種サイト・ブログ、TwitterPodcast から収集している。 Twitter脆弱性情報などスピードが重要なものからトレンドまで幅広く知れてやっぱり便利。

サイト・ブログ

インシデントや脆弱性情報などのニュース的なものは Security NEXT で知り、ブログや発表などは はてなブックマーク に流れてくるものを見ている。 はてブに流れてくるものは関心ワード機能を使ってセキュリティに関する情報を集めるようにしている。

id:piyokango さんのブログは出来事を詳細にかつ客観的にまとめてくださっているので、理解の助けになる。 また、自分がでタイトルだけ見てスルーしていた出来事でも、ここで取り上げているのを切っ掛けに出来事を知ったり考えたりしているので、新たな視点を得る機会にもなっている。いつもありがとうございます。

CISA を見ているのは Known Exploited Vulnerabilities Catalog に追加される脆弱性を見てヤバそうな脆弱性を把握するため。本当は KEV の更新だけ見たいが、これだけ見るには ML に登録する必要があり、面倒で見なくなる気がしたので CISA の更新を丸ごと見ている。

他にも見ているサイトやブログはあるが、常に見ているのはこの4つが主。 他のサイトは大チェッカーにまとめておく。

Twitter

興味範囲の界隈の人をTwitterのリストに入れて見ている。 過去24時間分を遡れないくらいの人数は入れていない。今数えたら35アカウントだった。

これについては先人の方がまとめてくださっているのでそちらを参照しておく。

ポッドキャスト

日本語でセキュリティについて話すポッドキャストがいくつかあるので聞いている。

ポッドキャストは情報の内容を知ることはもちろんだが、情報そのものよりもそれを元に話される考察だったり話者の反応だったりが一番タメになると思って聞いている。 考察はニュース的なメディアだと得づらいし、テキストだと反応や雰囲気を感じにくい場合もあるので、ここがポッドキャストを聞く価値かなと思う。

また、雑談パートがあるなど聞いていて楽しくラジオ的に聞けるのも重要だと思う。 自分の性格かもしれないが、娯楽な要素があることで聞き続けられる面もあると感じている。

一時期英語圏ポッドキャストも登録していたが、英語のリスニングと内容理解を同時に行うことは今の自分にはやや負荷になるなと思いやめてしまった。いつか再チャレンジしたい。

情報収集に使っているツールと使い方

ここではツールの紹介。

  • Slack RSS
    • サイト・ブログの更新チェックに使っている
    • RSS リーダーも使っていたけど、これが一番定着した
    • Slack はずっと立ち上げているし、更新もわかりやすい
    • PC / スマホ / タブレット とマルチデバイスで同期も取れているというもの要素の一つかも
  • Twitter
    • リスト機能で気になる人のツイートを見るため
  • はてなブックマーク関心ワード
    • 話題になっている情報を見るため
    • ホットエントリーだと見たい情報を絞れないので、関心ワード機能で気になる話題だけ見ている
    • キーワードにしているのは Securityセキュリティ の2つ
      • 微妙に流れてくる情報が違うので、2つ入れることで網羅性を上げている
      • ただし、 セキュリティ の方は時期によってはサイバーセキュリティ以外の情報が多く流れてくるので注意が必要
  • Google Podcasts
    • ブラウザがあればどこでも聞けるのが便利で使っている
    • ただし質は微妙な気がするので、代わりになりそうなものがあれば検討したい

普段の情報収集の様子

毎日・週1、更新があればの3パターン。 全部丁寧に見ていると大変なので、ポッドキャスト以外はあまり時間をかけずにさっと流す程度にしている。

  • 毎日
    • Twitterのリストに入れている人の直近の更新を眺める
    • RSSの更新を眺める
    • 更新量は日に1回でも見切れる量だが、2,3回に分けてみると丁度いい
      • 自分は暇になったり休憩中に見たりしている
  • 週1
    • はてなブックマークの関心ワードを1週間分眺める
      • 週に1回会社のセキュリティ会という集まりがあるので、それにあわせて見る
      • 全部見るのではなく、気になったページを開く程度
      • 読むのに時間がかかりそうなものはブラウザのタブで開きっぱなしにしていたり あとで読む 系ものに放り込んだりする
    • セキュリティのアレを聞く
      • 月曜の夜更新なので、だいたい火曜の午前中に聞いている
  • 更新があれば

まとめ

自分のセキュリティ関連の情報収集のやり方をまとめてみた。 書き出してみると、結構色々やっていることに気がついた。

インプット分のアウトプットやそれ以外の何かが出来ているのかと言うと微妙な気もしてきたので、今後はアウトプットの方も意識していきたいなと思う。 まずは感想をツイートしてみるくらいから始めていきたい。

Best practices for writing Dockerfiles読んだメモ

docs.docker.com

何これ

  • Docker 公式ドキュメントにある Dockerfile の書き方のベストプラクティスがまとまっているページ
  • 巷に書いてあるような意識したいことや具体的なプラクティスがまとまっている
    • build context を理解しましょう、multi-stage buildを使いましょう、Dockerfile 命令の良い書き方 etc...
    • イメージサイズを小さくしたり、ビルドスピードを高速にしたりするプラクティスが目立つ
  • これまで雰囲気で Dockerfile を書いていたりプラクティスをつまみ食いしているだけの状態だったいので、改めて読んでみた

感想

  • build context について色々書かれていたのは発見
    • これまであまり意識していなかった
    • 確かにビルドサイズやスピードを抑えるために、必要なファイルしか見ないようにするのはその通り
    • セキュリティ的にも余分なファイルを加えないのは正しそう
  • 標準入力から docker build できるのは知らなかった
    • 1回限りのビルドや Dockerfile を保持し続けない場合などにいいらしい
    • 「ビルドコンテキストを省略すればもっと早いぞ!」みたいに書かれていたのは面白い
    • ただしサービス開発の場面で使えそうな時がパッと思い浮ばない
    • ツール的な使い方をするものだったら使いどころがあるのかも
    • git レポジトリなどをビルドコンテキストに出来る remote build context は使い道ありそう
  • ENTRYPOINT のコンテナ起動時にヘルパースクリプトを実行させるテクニックは使えそうで、覚えておきたい
    • 色々なイメージがこのやり方を使って機能を提供している*1*2ので、自分で使わなくても知っているとトラブルシュートの場面で役立ちそう
  • セキュリティのプラクティスがまとまっていないのは気になった
    • セキュリティの側面で書いてないだけな気もする
    • ビルドコンテキストを絞ったり、イメージサイズを減らしていくのはセキュリティの面からも良いプラクティスではあるだろう
    • とはいえ別の文書で当たった方がよさそうに思える
      • root を避けましょうとか書いてあるけど、あんまりハッキリ言ってなくて「あれれ?」といった感想を持った
    • 以前話題になっていたこの記事辺りがよいのだろうか

余談