Docker Engineのバージョンアップ手順｜更新前の影響確認・復旧
Docker Engine本体を安全に更新するための、影響確認・版の選び方・作業後の正常性と復旧判断。
この記事の目的
エンジンとコンテナイメージの更新を分け、停止影響を確認してから更新。
最初に確認
接続先context、現行Engine版、提供元パッケージ、実行中サービス。
1. 更新前に知っておくこと
対象環境と停止リスクを先に確認し、作業可否を判断します。
- 更新対象
- Docker ServerとUbuntuの実行ホストが一致するか。リモート接続や環境変数による上書きにも注意
- 無停止要件
- LB/冗長ホスト/DB/セッションの設計がないと無停止は保証できない
- 更新・復旧
- Engine・CLI・containerd・Compose、Volumeと復旧経路を確認
対象環境と更新の範囲
対象：Ubuntu ServerでDocker公式aptリポジトリのDocker CE（docker-ce）を使用するホスト。 Docker Desktop、docker.io、Snap、rootless、RHEL、Swarmは別手順です。Docker Engineの更新と、コンテナイメージやアプリデータの更新を混同しません。公式情報確認日：2026年11月1日。
単一ホストでコンテナが稼働している場合、daemon更新の際に管理接続の切断やサービス停止が発生する可能性があります。
無停止にできるかはDocker Engineではなく冗長構成で決まる
| 運用条件 | 判断・具体的な次の作業 |
|---|---|
| 単一ホスト/単一コンテナ | daemon停止や依存更新で業務断が起こり得る。live-restoreだけで無停止を保証できない。保守時間・停止許容・復旧を承認する |
| アプリが2台以上＋LB | 更新対象をLBから切り離し、既存接続をdrainして一台ずつ更新。残存系が全トラフィックを処理できるか事前負荷試験する |
| 状態保持DBが同一ホスト | フロントの冗長化だけではDB停止を防げない。レプリケーション・データ整合・フェイルオーバーを別設計する |
| Swarm等の管理下 | 本記事のstandalone Engine更新手順は使わず、オーケストレーター側の更新とquorumを確認 |
可用性要件（許容中断時間・SLO）、RTO/RPO、作業担当と中止権限を変更票に記録。冗長化、セッション保持、長寿命接続、DBの状態管理が未確認なら「無停止予定」と記載してはいけません。
脆弱性と停止影響の判断
| 結果・条件 | 次の対応 |
|---|---|
| 公式CEの更新候補あり | 対象版のリリースノート、CVEの修正有無、CLI/containerd/Composeの互換性を調べる |
| 別のDocker配布元が混在 | docker.io等とCEを混在更新しない。管理方式を特定 |
| 重要サービスが単一ホストで稼働 | 停止許容時間と代替経路、復旧責任者を合意 |
| live-restore有効 | patch更新等のサポート条件を確認。大きなバージョン差・daemon設定変更・長時間停止では再接続が保証されない |
脆弱性はバージョン文字列だけで安全と判断せず、導入元の修正情報と機能の利用状況を照合します。
パッチ更新とメジャー更新を別に判断
| 条件・結果 | 判断・対応 |
|---|---|
| 同じ系列のパッチ更新 | 修正内容とdaemon再起動・稼働コンテナへの影響を確認。無停止と決めつけない |
| メジャー更新 | Docker API・Storage・Network・廃止機能とCompose/SDK/監視ツールの対応を検証してから計画 |
| イメージのみ更新 | アプリ・DB・マウントの互換性は別案件。Engine更新とまとめて評価しない |
| OS/カーネルと同時変更 | cgroup・iptables/nftables・overlayfs等の変化が重なるため、可能なら変更窓を分離 |
リリースノートから破壊的変更を抽出する
例としてDocker 29.0.0ではEngine APIの最小バージョン変更があり、29.3.0では最小API版を引き下げる調整が入っています。つまり「29系だからAPIの互換性は一定」とは判断できません。実際に適用するパッチ版のBreaking Changes、Deprecated、Security、Networking、Storageを確認することが重要です。APIを使用する監視Exporter、SDK、CI/CD、Composeプラグインの対応も別々に確かめます。
Docker公式：29系リリースノートを例に、バージョンごとの差を調べます。
live-restoreの限界とログ停止リスク
Docker公式のlive-restoreはdaemonのパッチ更新で稼働を保つ補助機能ですが、主要版更新、bridge/storage設定の変更、長時間のdaemon停止では再接続できない場合があります。daemonがログを回収できない間にFIFOバッファが満杯になるとコンテナがログ書き込みで止まる可能性もあります。公式：live-restoreと制約。
29.0系ではDocker APIの最低版1.44、29.3以降では最低版1.40に戻された例があります。更新先の正確なパッチ版と、SDK・CI・監視ツール・Composeの通信を検証してください。
現在のホスト・版・コンテナを確認
これらは状態の読み取りです。docker context showがリモートの場合、aptで更新するホストとDocker Serverのホストが同じか確認します。docker-ceが導入されていない場合は作業を止めて配布元を調べます。
バックアップ・候補版・復旧可否を確認
/etc/docker/daemon.json、systemd drop-in、Docker/CLI/containerdのパッケージ版、Volume・bind mount、必要なイメージとCompose設定を安全に保存します。DBは単純tarではなくアプリ固有の整合性バックアップと復元試験が必要です。
apt-get updateはパッケージ索引を書き換えます。事前シミュレーションで意図しない削除や更新があれば作業中止。旧パッケージの入手可否、データ形式の互換性、サービス復旧手段も確認します。
現行環境のインベントリと作業前の停止条件
docker psは現在のcontext先を参照する一方、apt-cacheはコマンド実行ホスト上の情報です。両者が同じサーバーとは限りません。Compose以外に直接起動されたコンテナや、systemd/外部管理ツールによる起動も記録します。
- 対象ホスト・Ubuntu版・CPUアーキテクチャ・Dockerの導入元が判明している
- 現行と更新候補のEngine/CLI/containerd/Compose版、依存変更とAPI互換性が記録済み
- 監視、アプリの健康状態、レジストリ接続、ログ保全、DBバックアップ・復元試験が実施済み
- 停止許容時間、代替サービス、コンソール、担当者と復旧時の判断権限が確定している
2. 確認コマンドと結果の読み方
代表例を見てから、必要なコマンドの詳しい判定へ進みます。
以下は結果の読み方を示す想定例であり、実環境の測定結果ではありません。
| 確認 | 目安 | 要確認・異常時 |
|---|---|---|
docker version | 予定Server版とAPIの確認 | Clientのみなら接続・権限を確認 |
systemctl is-active docker | activeならdaemon起動 | 業務正常は別検証。failedならログ調査 |
docker ps -a | コンテナが期待した状態 | Upのみではアプリ正常を断定しない |
確認コマンドの出力・正常性・次の操作
Ubuntu公式Docker CE aptを対象とした想定結果であり、実機で測定した値ではありません。正常＝作業票と事前基準に一致、要確認＝停止予定・Compose非利用など想定内例外、異常＝更新を止める状態、判定不能＝接続・権限・導入元不明で合否を付けられない状態です。コマンドの終了コードと対象ホストを必ず記録します。
apt-get updateは索引更新、apt-get installは更新本体です。apt-get -s installは予行で、記載の...はプレースホルダーの省略記号。実行時は記事の版指定形式に置き換え、更新対象パッケージと依存を直前に再確認してください。全コマンドの想定出力と結果別の判断を見る
実機の環境や版によって出力は変わります。必要な箇所を開き、対象ホストと終了コードも照合してください。
| コマンド | 想定結果 | 判断基準・次行動 |
|---|---|---|
docker context show | default / 任意のcontext名 | 名前だけではローカルを保証しない。想定と違う場合は更新対象を再確認。コマンド失敗ならdocker CLIと設定を調査 |
docker context ls | context名・Docker Endpoint URI・現在の* | aptを実行するUbuntuホストとServer側接続先が一致するか確認。tcp/sshなら遠隔接続の可能性→No-Goで確認 |
docker version | Client/Server/各API version、接続失敗時Serverが欠落 | 事前承認したServer版/API互換と一致が正常。Clientのみならdaemon/context/socket/権限を調査。業務正常は別 |
docker info --format '{{.Name}} {{.ServerVersion}}' | Server名と実バージョン（接続できる場合） | 対象ホストと一致。想定外のhost/daemonは変更停止。出力不能は接続/権限を確認 |
docker info --format 'driver={{.Driver}} cgroup={{.CgroupDriver}}' | overlay2等のDriverとsystemd等cgroup driver | 変更前の値と一致/対応版で正常。予定外のstorage/cgroup変更は重大リスク→検証中止 |
docker info --format '{{.LiveRestoreEnabled}}' | true/false。未対応/取得失敗の場合もある | trueでも停止回避の保証なし。falseならdaemon停止影響を必須評価。取得できなければ設定/daemon確認 |
dpkg-query -W docker-ce docker-ce-cli containerd.io docker-compose-plugin | インストール済みパッケージ名と版。未導入で非ゼロ | 配布元のCEと対象パッケージ版が一致。未導入/一部欠落なら導入方式やCompose利用有無を調査 |
apt-cache policy docker-ce docker-ce-cli | Installed/Candidateとsource・pin priority | Docker公式apt配布と対象Ubuntuコードネームの版が一致。候補なし/混在なら更新を保留 |
apt list --all-versions docker-ce | バージョン文字列（epochとUbuntu release等） | 選定した正確な実在版のEngine/CLIを記録。候補が表示されない場合はrepo/アーキテクチャ確認 |
apt-cache madison docker-ce | repoごとの利用可能なVersion | 選定版が実際に入手できること。apt listとの不一致ならソース/索引を見直す |
apt-mark showhold | Holdされている名前。未保持なら空 | hold中のEngineや関連依存があれば理由を確認し、無断解除しない |
sudo apt-get update | repoのHit/Get、GPG署名やネットワーク警告（索引変更あり） | 公式配布元に署名警告なしでアクセスできること。エラー/署名不整合は中止 |
sudo apt-get -s install ... | Inst/Conf/Remv等のAPT予行差分（パッケージは変更しない） | Engine/CLI/依存/pluginの予定版と依存が承認に一致。削除・想定外更新・候補変化ならNo-Go |
sudo apt-get install ... | 承認済み版の実インストールとサービス再起動の可能性 | 変更内容が直前予行と同じことを確認。設定ファイル質問・差分が意図外なら中止/エスカレーション |
sudo systemctl is-active docker | active / inactive / failed、成功時exit 0 | activeはdaemon起動のみ。inactive/failed（通常非ゼロ）はjournalctl調査、誤hostなら対象確認 |
sudo systemctl cat docker | unit内容とdrop-in（参照） | daemon起動引数・overrideが承認構成に一致。予期しない変更なら設定の復旧判断 |
docker ps -a | Up/Exited/Restarting、Healthが設定済みならhealthy等 | 事前に棚卸しした重要コンテナの全件が期待状態。Exitedでも停止予定なら正常候補。対象欠落/Restartingは保留 |
docker compose ls | Compose管理のproject一覧、0件の場合もある | 管理対象のprojectが想定どおり。0件は非Compose利用の可能性→docker ps/別管理基盤を調査 |
docker network ls | Bridge/host/独自ネットワーク一覧 | 変更前とネットワークが一致。構成の欠落や予期しない再作成は疎通確認 |
docker volume ls | Volume名とdriver、利用者リストは別確認 | 重要Volumeが存在しバックアップに対応。消失/不明は削除・更新を止める。存在だけでデータ整合性は不明 |
df -h /var/lib/docker | Dockerデータ領域の容量と使用率 | 選定した更新・ログ用の余裕がある。領域がない、mountが異なるならNo-Go。Dockerのdata-root変更時はこのパスでは不足 |
docker compose version | Compose plugin版、利用不可の場合エラー | アプリが依存するなら対応版・実コマンド確認。未導入でもCompose非利用なら要確認扱い |
sudo journalctl -u docker -n 80 --no-pager | daemonのイベント/エラー、0行のこともある | 新規errorや起動失敗なしが条件。空欄は業務成功の証明ではない。エラー時は前後ログを保存 |
docker logs <CONTAINER> | 対象のstdout/stderr（ログドライバに依存） | 新規重大エラー/連続再起動がない。空欄でもHTTPとDBを別検査。ログ取得不可ならドライバ/権限を確認 |
docker ps -a --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}' | コンテナ名・Image・Statusを表形式で表示 | 作業前の対象サービスの全件と照合。Statusが変化したら原因確認 |
sudo systemctl status docker --no-pager | Loaded/Active状態と直近ログ | activeでもアプリ合格ではない。failed/restart-loopなら隔離、詳細ログ調査 |
grep -E 'install|upgrade|remove' /var/log/dpkg.log | tail -n 40 | 直近のパッケージ変更履歴（当日のログとは限らない） | 適用対象と時刻を照合。ログがローテート済みの場合はdpkgログやapt historyを調査 |
例示出力：daemonとコンテナ
次ホストへ進む条件：Server・APIの版、daemon、重要コンテナ/Volume、実アプリHTTP・DBの読み書き、CI/監視が、更新前に承認した基準値と一致。HTTP 5xx・p95遅延などの警報を超えた場合はLBから再隔離し、別ホストの更新は停止。
作業判定票：Go / Hold / Abort / Recovery を明確化
以下の欄を更新前に実環境の数値・対象・責任者で記入し、未確定のまま本番更新しません。閾値を記事の架空数値で共通化しないでください。
| 工程 | 必要な証跡・判断者 | 許可・保留・中止条件 |
|---|---|---|
| Preflight / Go | 対象host/node、現行/目標版、パッケージ差分、公式修正情報、復旧試験、切替担当と承認者 | すべて照合済みならGo。未実施/権限不足/候補違いはHold |
| Canary / Hold | 対象をLB/スケジューラで隔離、OS・アプリログ、重要ユニット・業務APIの基準値 | 事前SLOしきい値超過、データ異常、想定外の再起動ならAbort |
| 段階復帰 / Go | アプリ認証、HTTP成功率・5xx、p95、DB read/write、Job、監視、観測時間の記録 | 合格後に対象を復帰し観測完了した場合のみ次ホストへ。回復せず原因不明ならHold |
| 復旧 / Recovery | 原因ログ、バックアップと復元点、データ互換性、RTO/RPO、復旧承認者 | 変更を止め、既知の復旧手順を使用。ロールバック不能なら担当者へエスカレーション |
想定出力と結果の見方
Engineのバージョンが変わりdaemonがactiveでも、アプリのHTTPやDB接続が成功したことにはなりません。
3. 安全な進め方・完了確認と復旧
環境ごとの作業計画を前提に、変更・監視・中止・復旧の順で確認します。
次へ進める条件：Server/API・コンテナ・実業務通信・監視が合格して初めて次ホストへ。
承認後の更新操作
公式リポジトリから実在するバージョンを選び、Docker EngineとCLIを一致する版へ更新します。下記はコマンドの型で、プレースホルダーを含むためそのまま実行できません。
live-restoreを無停止保証と扱わないでください。設定ファイル変更・削除提案が出たら作業を止め承認を取り直します。Docker公式CE aptでのパッケージ版指定を具体化
Docker公式はUbuntuでapt list --all-versions docker-ceからバージョン文字列を選び、EngineとCLIに同じ版を指定する方法を案内しています。epoch・Ubuntuコードネームを含む完全な実在版を使用します。
Engine/CLIの完全版だけでなくcontainerd.io・Buildx・Composeプラグインの候補版と依存更新も固定/明示承認してから本実行します。未固定の関連パッケージは同じinstallコマンドでもリポジトリ更新で候補が変わるため、直前に同一内容の予行を再実行してください。シミュレーションの削除・意図しないアップグレード、パッケージ競合、設定ファイルの上書き提案があれば中止します。既存のdocker.ioやcontainerdパッケージとの混在を避け、公式インストール・アップグレード手順に戻ります。
段階的な更新と通過条件
- テスト環境：候補版のEngine・CLIを導入し、使用するDocker API・Compose・ビルド・監視とコンテナのネットワーク・Volumeを検証。
- 本番1台目：停止影響を監視しながら承認済みの版だけを更新。サービス切断・daemon再起動・コンテナ状態を記録。
- 正常性確認：daemon状態だけでなく、主要アプリのHTTP、DB読み書き、ログ、レジストリ認証を確認。
- 次ホスト：すべての完了条件を満たすまで次へ進まない。異常があれば残りの更新を停止。
live-restoreは対応するパッチ更新等で有効な条件付き機能です。メジャー更新時に無停止を保証しません。冗長化や切替が必要なサービスは別途設計してください。
本番の段階更新・トラフィック切替（冗長構成向け）
- 事前：HTTP成功率、5xx、p95遅延、DB接続エラー、ログ、稼働ホスト数を変更前の基準として記録。閾値と観測時間を承認。
- ステージング：選定した正確な版でEngine/CLI/containerdとAPI SDK、Volume、HTTP・DB読み書き、レジストリ操作をテスト。
- LBから対象ホストへの新規振分を停止。既存接続、WebSocket、ジョブ、sticky sessionが残らないことを確認。残存ホストのキャパシティを監視。
- 事前に版指定したaptトランザクションのみ実施。daemon/コンテナ・業務アプリ・監視の順で確認。対象ホストを退避したままアプリ検証。
- 少量のトラフィックで段階復帰し、基準値を満たした場合だけ通常振分。観測時間中の異常がなければ次ホストへ。
具体的なLBの切替コマンドはロードバランサー製品・構成に依存するため、変更承認済みの製品別手順を使ってください。単一ホストにはLBを前提とした段階更新を適用できません。
結果に応じた次の行動
| 結果・条件 | 次の対応 |
|---|---|
| aptで依存エラー | 実更新を中止して配布元、候補版、held packageを確認 |
| daemonがfailed | systemctl status docker、journalctl -u docker、daemon.jsonの設定差分を調査 |
| コンテナがExited | docker ps -a・docker logsから原因を確認し、Volumeを削除しない |
| コンテナはUpだが業務不通 | 公開ポート・名前解決・業務ヘルスチェック・アプリログを確認 |
| 全て正常 | パッケージ版と動作確認の証跡を保管し完了 |
次ホストへ進めない停止基準
| 運用条件 | 判断・具体的な次の作業 |
|---|---|
| LB退避後に残存系の応答悪化・過負荷 | 対象ホスト更新を開始せず容量・接続設計を修正 |
| 更新後にdaemon failed、APIツール接続不可 | LB隔離を維持。journal、設定差分、client API互換性を調査。次ホスト更新禁止 |
| 段階復帰後に5xx/遅延/DBエラーが閾値超過 | 当該ホストの新規受付を止め、復旧判断に切り替える |
| アプリデータの整合性が不明 | 旧Volume/DBの削除・上書きをせず、復旧点を業務責任者と確認 |
しきい値は全社共通の固定値ではなく、業務SLO・平常時ベースラインに基づき事前決定します。監視しきい値が未決定なら本番作業を開始しません。
状態を混同しない運用判断：daemon・コンテナ・業務の3層
systemctl is-active dockerがactiveでもdockerdが動いているだけです。docker ps -aのUpはプロセスの生存でありアプリ可用性ではありません。ヘルスチェックが定義されている場合のみhealthyが観測でき、さらに実トラフィックを通したHTTP/API・DB read/write・監視/CIからのDocker APIの成功を確認して初めて復帰を判断します。
更新後の完了判定
合格：対象バージョン・daemon・重要コンテナ・永続データ・実業務通信が正常。不合格：版不一致、daemon起動失敗、停止コンテナ、業務エラーが残る場合。
監視・クライアント・データまで含めた完了判定
| 条件・結果 | 判断・対応 |
|---|---|
| Server版/API版が予定と一致 | docker versionでServerとClientを確認。監視・CIのAPIクライアントで疎通試験 |
| 重要コンテナUp/healthy | 業務HTTP/DB read-write、ホストポート、DNS、外形監視を実測し、エラーが残れば失敗 |
| Volumeとログが正常 | マウント先・権限・アプリのデータ整合性を点検。Volumeを削除して作り直さない |
| 監視・Build/Push/Pullが動く | レジストリ認証、プロキシ、証明書、Docker APIの互換性を確認 |
上の判定は更新前に記録した正常値との比較が必要です。コンテナがUpであっても業務復旧の証明にはなりません。
更新失敗時の対応と切り戻し
更新を停止してapt履歴・daemonログ・旧設定を保全します。旧版への戻しは、依存関係・パッケージの入手・daemonデータ互換性を検証できる場合に限る復旧候補です。アプリDBのスキーマ変更がある場合はEngineを戻すだけでは復元できません。
docker system prune、docker compose down -v、本番Volumeの上書きは避け、復旧できない場合は基盤・アプリ担当へエスカレーションしてください。障害別の復旧ルート
| 条件・結果 | 判断・対応 |
|---|---|
| daemonが起動できない | journalctl -u docker、daemon.json、systemd drop-in、containerdを調査。データ削除は行わない |
| 古いSDK/監視だけ接続できない | API最小版の変更と対応SDKを調査し、Engineの単純ダウングレードは避ける |
| コンテナは起動するが業務障害 | Volume/ポート/名前解決/環境変数/アプリログの差分を確認 |
| データ破損または互換性不明 | 更新を止め、バックアップ復元手順とRPO/RTOを業務担当者と確認 |
旧版パッケージの入手・依存関係・daemonデータ互換性が検証できた場合のみ旧構成への復旧を検討します。復旧後は元の業務処理と監視の成功を再確認し、実際の停止時間を記録してください。
関連ガイド・公式資料
更新前の確認チェックを開く （任意・作業メモ作成）
更新前リスクをチェックして、作業メモを作る
構成・停止条件・復旧準備とDocker APIとデータ保護を確認。未確認事項と次に読む説明を整理し、チェック結果をテキスト保存できます。実機診断や更新の実行許可ではありません。
ブラウザ内で判定し、入力内容をこの機能から外部送信・自動保存しません。機密情報は入力しないでください。