コンテンツにスキップ

docker run での修正 PR の開発

  • 状態: 実装済み(手元での検証まで)
  • 開始日: 2026年10月27日
  • 最終更新: 2026年10月27日

目的

Compose を使わずに docker run で動かしているコンテナも、Dockerfile のベースイメージと言語パッケージの lockfile を更新する修正 PR の対象にする。 起動コマンドを書いたファイルがないため、起動時のイメージタグを書き換える PR は作らない。

方針

  • 修正先は利用者が設定の対応付けで明示する
  • 対応付けを信頼し、そのコンテナが指定したリポジトリから作られたことは確かめない
  • 稼働イメージとスキャンしたイメージの実体を照合し、Dockerfile のベースレイヤーや lockfile のパッケージ名・版を確認する
  • 同じ修正先の PR 作成は、複数ホストのうち1つのインスタンスに任せる

決定事項

  • コンテナ名による対応付け

    • Workload キーは container/<コンテナ名> とし、docker run --name で付けた docker ps の NAMES に出る名前を使う
    • ベースイメージは dockerfile、言語パッケージは dependencies に対応付け、両方を指定する場合は項目を分ける
    • 設定方法は docker run のコンテナの対応付けに記載

  • イメージ名で書く案の不採用

    • nginx などの公開イメージは複数の場所で使われ、修正先を決めるにはコンテナの指定が残るため、イメージ名による対応付けは採らない
    • 書き方や優先順位の規則を増やさず、人が書いて読む負担の少なさを優先する

  • 設定の信頼と PR 本文の注記

    • 設定の対応付けを信頼し、そのコンテナが指定したリポジトリから作られたことは確かめない
    • ベースレイヤーやパッケージ名・版の一致は作成元の証明にならず、名前を使い回すと別のリポジトリに PR が作られることがある
    • PR 本文には、修正先との関係が設定に基づき、KestreLynx では確かめていないことを注記する
    • 本文の長さの上限で注記を残せない場合は PR を作らない

  • Compose のコンテナ名を指定した場合の案内

    • Compose のコンテナ名を container/<コンテナ名> に書いた場合は照合せず、ログの警告で正しい compose/<project>/<service> を示す
    • 同じ状態では警告を繰り返さず、案内するキーが変わった場合などに再び知らせる

  • 複数ホストでの PR 作成

    • 重複を防ぐ仕組みはホストごとのため、同じリポジトリの同じ Dockerfile・lockfile の PR 作成は1つのインスタンスに任せる
    • 他のホストでは、その対応付けを設定しないか、PR 作成を無効にして計画だけを使う

検証方法

環境

環境 Docker の版 イメージストア
手元の WSL の Docker 29.1.3 containerd
手元で動かす Docker-in-Docker(dind) 29.9.1 従来の overlay2

  • 結合テスト

    • 両環境で実際の Docker・Trivy・Docker Hub と模擬した GitHub を使用
    • Dockerfile はコンテナを動かしたまま、タグをそのまま使う、docker tag で別のイメージへ付け替える、同じタグでビルドし直す、の3場面を確認
    • 各場面で、稼働イメージとスキャン対象・スキャン結果の一致、ベースレイヤーの照合、修正計画から PR 作成までを確認
    • npm で minimist を 1.2.5 から 1.2.8 に更新する処理と PR 作成を確認
    • Dockerfile の PR 作成後、次のサイクルで書き込みが発生しないことを確認

  • 単体テスト

    • 設定の検証、Compose のコンテナ名を指定した場合の警告、PR 本文の注記と長さの上限、既存の PR と同じ更新を識別する仕組みを確認
    • 既存のテストを含め、全パッケージの単体テストが通過

  • GitHub での検証範囲

    • 今回の検証には、本物の GitHub での PR 作成を含めない
    • PR を作る仕組みは、既存の Compose の Dockerfile の PR と同じ
    • 追加した本文の注記は、模擬した GitHub を使う結合テストと単体テストで確認

検証結果

表の PR 作成は、模擬した GitHub で確認した結果を示す。

次の場面は、どちらのイメージストアでも同じ結果になった。

確認した場面 結果
タグをそのまま使う スキャンとベースレイヤーの照合を通過し、Dockerfile の PR を作成
docker tag でタグを付け替える 古いコンテナのイメージをスキャンでき、Dockerfile の PR を作成
npm の更新 更新処理を通過し、minimist を 1.2.8 にする PR を作成
Dockerfile の PR 作成後の次のサイクル 追加の書き込みなし

同じタグでビルドし直した場合の違い

同じタグでビルドし直し、古いコンテナを動かし続けた場合は、イメージストアによって結果が分かれた。

イメージストア 結果
containerd 古いイメージが消えてスキャンに失敗し、古いコンテナの計画項目も PR も作られない
従来の overlay2 古いイメージが残り、スキャンと照合を通過して Dockerfile の PR を作成

containerd で古いイメージが消えた場合は、新しいイメージでコンテナを作り直す必要がある。

未検証・次の作業

実環境での確認

  • 同じ名前でコンテナを作り直した後に、同じ更新の PR が重複しないことの確認
  • コンテナを改名した後に、旧名の対応付けから新しい PR が作られず、既存の PR も閉じられないことの確認
  • 単体テストで確認した Compose との Dockerfile の共有、再ビルドの案内、コンテナ名を誤指定した場合の警告の実環境での確認
  • Docker の他の版・rootless・arm64 での確認

使い勝手の改善

次の改善は今後の検討対象とし、実装時期は未定とする。

  • 観測したコンテナごとに対応付けのキーを一覧で示し、表示されたキーを設定へ写せるようにする
  • 同じコンテナの Dockerfile と依存ディレクトリなど、複数の修正先を1つの対応付けの項目にまとめられるようにする

更新履歴

2026年10月27日

  • docker run のコンテナを Dockerfile と lockfile の修正 PR の対象に追加
  • コンテナ名による対応付けと、設定を信頼する範囲の記録
  • PR 本文の注記、Compose のキーの案内、複数ホストでの運用方針の整理
  • 2つのイメージストアでの結合テストの結果と未検証の範囲の記録

この記事は、KestreLynxの開発記録です。KestreLynxについて