# Docker [[LXC]] のメカニズム(namespace・cgroup)に基づき、Linux カーネルでプロセスを共有 OS 上で隔離する事実上の標準コンテナソリューション。Docker イメージは Linux 仮想化スタックと同様にレイヤー化されたファイルシステムで構成され、union mount により読み書き可能な top layer(コンテナ本体)を読み取り専用ベースイメージの上に重ねる。複数の読み取り専用ファイルシステムを積み重ねてベースイメージから新規イメージを構築でき、これがイメージリポジトリベースの自動化されたアプリケーションパッケージング・プロビジョニングを可能にする。([[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]]) Bernstein([S5])はガバナンスの観点から「Docker(スタートアップ Docker 社)と Kubernetes(Google 主導)のより中立な協働構造が、共通パッケージング/デプロイ標準合意のために必要」と論じる。Docker の成功要因はオープンソース化と早期リリース、豊富なイメージリポジトリエコシステム、コミュニティサポートに帰せられる。 本論文(2017 公開)時点で、Docker は LXC を凌駕する研究関心の中心となり、コンテナ単体研究を活性化させた事実上の reference technology だった。 ## ISPASS 2015 時点の性能特性 Felter ら([[@2015__ISPASS__An Updated Performance Comparison of Virtual Machines and Linux Containers]])は Docker 1.0(2014年7月)の性能を IBM FlashSystem 840 搭載の Intel Sandy Bridge-EP サーバ上で KVM と比較した。 - **ネイティブ≈Docker**: CPU(Linpack)・メモリ帯域(STREAM)・シーケンシャル I/O はほぼ同等 - **ランダム I/O**: Docker ≈ ネイティブ(IOPS・レイテンシとも)。KVM は QEMU 経由のオーバーヘッドで約 50% 低下 - **ネットワーク NAT のコスト**: Docker NAT(veth pair + bridge + NAT)は高パケットレートで Redis スループット約 15% 低下・遅延増加。Docker net=host ならネイティブと同等 - **AUFS のコスト**: Docker NAT + AUFS(デフォルトストレージドライバ)の MySQL は NAT volume より ~8% 追加低下。volume(ホスト直結)を使えば回避できる コンテナ起動時間は KVM(11秒)に対し Docker は 1秒未満と大幅に速い(定常性能ではなく起動レイテンシの差)。 ## Linux カーネル攻撃面との関係 Docker コンテナはホスト OS の Linux カーネルを共有するため、Linux カーネル自体の脆弱性が全コンテナとホストに影響する攻撃面となる。APSys ’23 の Container Transplantation 論文([[@2023__APSys__Reducing Attack Surface with Container Transplantation for Lightweight Sandboxing]])は、この攻撃面を軽減するために Linux コンテナを FreeBSD カーネルへ移植し、FreeBSD の Capsicum サンドボックスを透過適用するアプローチを提案している。 ## クラウドのリソースコントロール下でのDocker 『詳解 システム・パフォーマンス 第2版』11章は、Dockerコンテナのリソース使用状況を`docker stats`(CPU%・メモリ使用量/上限・ネットワークI/O・ブロックI/O・PID数を表示)で観察する実例を示し、その裏側で動く Linux cgroup(`/sys/fs/cgroup/cpu,cpuacct/docker/...`の`cpuacct.usage`・`cpu.stat`の`nr_throttled`/`throttled_time`)がリソースコントロールの実体であることを説明する。CPUシェアはバースティング(他コンテナのアイドルCPUを一時的に使う)を許容するため、アイドル時に測定した性能が他テナント参入後に失われるリスクがある点も指摘している。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]] §11.3.3.1.2, §11.3.4.2.2) ## CI/CDビルドにおけるDocker Bakeと BuildKit の OTel 対応 `Observability Engineering` 第2版第18章は、[[Honeycomb.io]] が [[CircleCI]] 上のビルドを高速化した過程で採用した2つのDocker機能を解説する。 - **Docker Bake**: 2019年に導入・2022年頃に普及した、複数段階のDockerイメージビルドを1つのビルド呼び出しへ連結する手法。Honeycombは、Goビルド・JavaScriptビルドを別々のCircleCIジョブとして逐次実行する代わりに、単一のDocker Bake呼び出し内でステップを並列進行させ(出力が必要になるまでブロックしない)、単一の仮想マシン上で複数の並列ビルドをインターリーブさせることでビルド時間の「床」を確立した。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] "Docker bake", "Parallel builds") - **BuildKit の OTel ネイティブ対応**: Docker BuildKitは発足時からOTel対応を統合しており、`TRACEPARENT`環境変数を`buildevents`(CircleCI計装)のトレース・スパンIDに合わせて設定することで、CircleCIのジョブ・ステップレベルのトレースと、BuildKitの個々のコマンド実行・ECRアップロード・ブロッキング待機を単一のトレースへ統合して観察できた。`docker`クライアント自体も`DOCKER_CLI_OTEL_EXPORTER_OTLP_ENDPOINT`環境変数の設定でOTelをネイティブにエクスポートでき、この場合`otel-cli`との併用は二重計装になるため避けるべきとされる。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] "Results", "Applying These Lessons to Your Build System") → [[CI-CDオブザーバビリティ|CI/CDオブザーバビリティ]] / [[OpenTelemetry]] ## イミュータブルなシステムイメージ上でのDocker(SREの探求 24章) 『SREの探求』24章は、コンテナインフラストラクチャを実行する場合、Docker イメージをビルドするためのツールが数多くあると述べたうえで、Docker イメージ自体もやはりベース OS 上で実行する必要があり、このベース OS は[[イミュータブルインフラストラクチャ|イミュータブルなシステムイメージ]]からローンチすべきだと説明する。デプロイ時には、[[HashiCorp]] の [[Packer]] や Netflix のオープンソースツール Aminator でアプリケーションコードをベースイメージへインストールし、コンテナオーケストレーションツールが Docker イメージの特定バージョンを実行時にプル(取得)する。この構成では、イミュータブルな Docker イメージがイミュータブルなシステムイメージ上で実行されることになる。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] §24.11) ## コンテナ化 対 継続的構成収束(DevOpsサーベイ6章) 『A Survey of DevOps Concepts and Challenges』第6章§6.5は、Dockerを中心とするコンテナ化を、[[Chef]]・[[Puppet]]による継続的構成収束(continuous configuration convergence)と対比する。一見両者は補完関係に見えるが実際には競合する戦略だとされる——Chefスクリプトは対象ノード上で継続的に実行され成功が対象ノードの以前の状態に依存するのに対し、コンテナ化ではコンテナ化された環境全体がビルド時に生成され、新しいソフトウェアバージョンごとに破棄・再構築される。同章はDocker・Docker Compose・[[Kubernetes]]・Rancherを、コンテナとその依存関係の仕様を可能にする関連ツール群として挙げ、Dockerがアプリケーションだけでなく基盤インフラストラクチャのデプロイにも使われてきたと述べる。Chef戦略との比較では、Dockerはより高速で信頼性の高いデプロイを実現する一方、ビルドサイズの増大という代償を伴う。Zhu et al.は「lightly baked images」(仮想マシンイメージ生成後にChefでアプリケーションをインストール)と「heavily baked images」(イメージが最初からアプリケーション全体を含む、コンテナ戦略に類似)を比較し、lightly baked方式はデプロイ時により多くの外部リソースを要するため信頼性が低いと結論づけている。(Source: [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 6 Toolset]] §6.5) ## Middleware '21 横断ベンチマークにおけるDocker [[@2021__Middleware__A Fresh Look at the Architecture and Performance of Contemporary Isolation Platforms]] は、Docker を含む10種の分離プラットフォームをCPU・メモリ・I/O・ネットワーク・起動時間・実運用ワークロード(Memcached, MySQL)の6軸で横断比較した。DockerはCPUバウンドタスクでネイティブと同等の性能(Finding 2)を示し、起動時間は約100msと全プラットフォーム中最速(Finding 13)だった。ネットワークではブリッジ方式により9.84%のペナルティを負う一方、Memcached YCSBベンチマークでは良好な性能を示した。拡張HAPメトリクスでは通常のコンテナはセキュアコンテナ([[Kata Containers]]・[[gVisor]])より少ないホストカーネル関数呼び出しを示した(Finding 26)。(Source: [[@2021__Middleware__A Fresh Look at the Architecture and Performance of Contemporary Isolation Platforms]]) ## 関連 - ソース: [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]] / [[@2015__ISPASS__An Updated Performance Comparison of Virtual Machines and Linux Containers]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] / [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] / [[@2021__Middleware__A Fresh Look at the Architecture and Performance of Contemporary Isolation Platforms]] / [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 6 Toolset]] - エンティティ: [[LXC]] / [[Kubernetes]] / [[CNCF]] / [[Wes Felter]] / [[IBM Research]] / [[Brendan Gregg]] / [[Honeycomb.io]] / [[CircleCI]] / [[OpenTelemetry]] / [[Packer]] / [[HashiCorp]] / [[Jonah Horowitz]] / [[Kata Containers]] / [[gVisor]] / [[Chef]] / [[Puppet]] - 概念: [[コンテナオーケストレーション]] / [[マイクロサービスアーキテクチャ]] / [[コンテナ配置最適化]] / [[コンテナ仮想化]] / [[CI-CDオブザーバビリティ|CI/CDオブザーバビリティ]] / [[イミュータブルインフラストラクチャ]] / [[収束型システム管理]] ## 出典 - [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]]（§2.1 Container Technology Principles、§5.2.5 Container Technologies） - [[@2015__ISPASS__An Updated Performance Comparison of Virtual Machines and Linux Containers]]（Docker 1.0 の性能特性の詳細） - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]](§11.3.3.1.2 シェアと帯域幅、§11.3.4.2.1〜§11.3.4.2.2 コンテナツールとcgroup統計) - [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]]("Docker bake", "Parallel builds", "Results", "Applying These Lessons to Your Build System") - Jonah Horowitz, 「24章 イミュータブルなインフラストラクチャと SRE」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, §24.11. - [[@2021__Middleware__A Fresh Look at the Architecture and Performance of Contemporary Isolation Platforms]](Finding 2, 13, 17, 26) - [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 6 Toolset]](§6.5 コンテナ化対継続的構成収束、Zhu et al.のlightly/heavily baked images比較)