Docker がハードディスクの共有に失敗するとどうなりますか?
Docker を使用するプロセスでは、異なるマシン間で Docker イメージとコンテナーを共有する必要がある場合があります。簡単な方法は、これらのイメージとコンテナを tar ファイルにパッケージ化し、ネットワーク経由でターゲット マシンに転送し、解凍して Docker にロードすることです。ただし、これらのイメージとコンテナをターゲット マシンに正常に転送したとしても、イメージをロードしたりコンテナを起動したりできず、「デバイスに空き領域がありません」というメッセージが表示される、つまりパーティションのディスク領域が不足するという問題が発生することがよくあります。特に次の場合に不十分です。 この問題は、ストレージ ドライバー オーバーレイ 2 を使用するときに発生する可能性が高くなります。
いったい何が起こっているのでしょうか?私もかつて同様の問題に遭遇しましたが、調査と研究を行った結果、その理由と解決策が見つかりました:
- Docker がハードディスクの共有に失敗するとどうなりますか? ストレージ ドライバーの動作原理
Docker ストレージ ドライバーには以下が含まれます。 AUFS、DeviceMapper、および OverlayFS のうち、Docker がハードディスクの共有に失敗するとどうなりますか? がより一般的です。これは overlayFS ファイル システムに基づいており、次の図に示すように、複数のミラーリングされたファイル システムを重ね合わせて共同マウント ポイントを形成し、完全なファイル システムのように見えます。
図に示すように、青色の部分が基本イメージのファイル システム、緑色の部分がコンテナ層のファイル システム、赤色の部分が読み取り専用層のファイル システムです。読み取り専用レイヤーには、すべてのイメージに共通のファイル システムが含まれています。コンテナ レイヤーは、各コンテナのファイル システムです。コンテナごとに読み取り専用レイヤーを作成し、その上に書き込み可能なレイヤーを追加して、各コンテナが参照できるようにします。独立したファイル システムであり、相互に干渉しません。- Docker コンテナを作成すると、/var/lib/docker/Docker がハードディスクの共有に失敗するとどうなりますか? にコンテナごとに Docker がハードディスクの共有に失敗するとどうなりますか? ストレージ ドライバーが作成されます。 directory コンテナのファイル システムの別のサブディレクトリ。これらのサブディレクトリ内のファイル データはすべてベース イメージに保存されるため、そのサイズはストレージ ドライバーのパフォーマンスに影響しません。ただし、あるマシンから Docker イメージとコンテナをパッケージ化して別のマシンに送信すると、Docker がハードディスクの共有に失敗するとどうなりますか? ストレージ ドライバーがデータを解凍するときに、データが /var/lib/docker ディレクトリに解凍され、このディレクトリにファイル スペースが占有されます。が大きすぎるため、/var/lib/docker が配置されているパーティションのディスク容量もそれに応じて小さくなります。次の図は、この問題を反映するために /var/lib/docker ディレクトリを例にしています:
上記の問題に対応して、いくつかの解決策を提供しました:
- 3.1 パーティションのディスク領域を拡張します
これは最も一般的な方法です。仮想マシンの場合は、仮想マシン管理ツールでディスク パーティションのサイズを拡張し、仮想マシンを再起動できます。クラウドサーバーの場合、ほとんどのクラウドプラットフォームはオンラインディスク拡張の機能を提供しますが、操作プロセスは比較的複雑であり、データ損失を避けるために注意が必要です。
3.2 /var/lib/docker ディレクトリをより大きなデータディスクにマウントします
事前に 21GB を超えるディスク (20T など) を用意し、ext4 形式にフォーマットしてマウントします/data ディレクトリ上で、/var/lib/docker ディレクトリをストレージ用のデータ ディスクに移行します。具体的な操作手順は次のとおりです。
# 制作文件系统格式 mkfs.ext4 /dev/vdb # 挂载 mount /dev/vdb /data # 备份原/var/lib/docker目录下所有数据 cp -au /var/lib/docker/* /data/ # 卸载/var/lib/docker目录 umount /var/lib/docker # 将/var/lib/docker目录迁移到新的数据盘中 echo '/dev/vdb /var/lib/docker ext4 defaults 0 0' >> /etc/fstab mount -a
3.3 使用されなくなった Docker イメージとコンテナを削除します
次のコマンドを使用して、ディスク領域をクリーンアップできます:
# 清理所有停止的容器 docker container prune # 清理所有未被标记的镜像 docker image prune -a # 删除所有没有容器使用的镜像 docker image prune -a --filter "dangling=true"
まとめ
Dockerを使用する際には、ストレージドライバーが使用する容量が十分であるかどうかに常に注意する必要があり、十分でないと起動に失敗する可能性があります。これを行うには、上記の 3 つの解決策のいずれかを実行できますが、個人的には、元のファイル システムを破壊せずに問題を迅速に解決できる 2 番目の方法をお勧めします。私の共有があなたのお役に立てば幸いです。読んでいただきありがとうございます。以上がDocker がハードディスクの共有に失敗するとどうなりますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック









この記事では、プロセス中の準備、展開ステップ、セキュリティ対策をカバーするDocker Swarmへのアプリケーションの展開を詳細に説明します。

この記事では、Kubernetesのポッド、展開、およびサービスについて説明し、コンテナ化されたアプリケーションの管理における役割について詳しく説明しています。これらのコンポーネントが、アプリケーション内のスケーラビリティ、安定性、および通信をどのように強化するかについて説明します。(159文字)

この記事では、手動スケーリング、HPA、VPA、およびCluster Autoscalerを使用してKubernetesのスケーリングアプリケーションについて説明し、スケーリングを監視および自動化するためのベストプラクティスとツールを提供します。

この記事では、さまざまなツールとベストプラクティスを使用して、作成、更新、スケーリング、監視、および自動化に焦点を当てたKubernetesの展開の管理について説明します。

記事では、Docker Swarmのサービスの管理、ダウンタイムなしで作成、スケーリング、監視、更新に焦点を当てています。

この記事では、Docker Swarmにローリングアップデートを実装して、ダウンタイムなしでサービスを更新することについて説明します。サービスの更新、更新パラメーターの設定、監視の進捗状況、スムーズな更新の確保をカバーしています。

この記事では、低遅延アプリケーションのDockerを最適化する戦略について説明し、画像サイズの最小化、軽量ベース画像の使用、リソースの割り当てとネットワーク設定の調整に焦点を当てています。

記事では、マルチステージビルド、最小限のベース画像、およびDocker ScoutやDiveなどのツールを使用して、サイズとパフォーマンスのDocker画像の最適化について説明します。
