Docker のヒント: マシンからジャンクを削除する

おい、ハブル！ 記事の翻訳をご紹介します 「Docker のヒント: ローカル マシンをクリーンアップする」 作者 リュック・ジャジェリー.

今日は、Docker がホスト マシンのディスク領域をどのように使用するかについて説明し、未使用のイメージとコンテナのスクラップからこの領域を解放する方法についても説明します。

総消費量

Docker は素晴らしいものであり、おそらく今ではそれを疑う人はほとんどいないでしょう。 ほんの数年前、この製品により、あらゆる環境を構築、提供、実行するまったく新しい方法が提供され、CPU と RAM のリソースを大幅に節約できるようになりました。 これに加えて (これが最も重要なことになる人もいますが)、Docker のおかげで、運用環境のライフサイクル管理が驚くほど簡素化され、統合されるようになりました。

しかし、現代生活のこれらすべての楽しみには代償が伴います。 コンテナーを実行したり、独自のイメージをダウンロードまたは作成したり、複雑なエコシステムをデプロイしたりするには、料金を支払わなければなりません。 そして、とりわけディスク容量に対して料金を支払います。

Docker が実際にマシン上でどれだけのスペースを占めるか考えたことがない場合は、次のコマンドの出力を見て不愉快に驚かれるかもしれません。

$ docker system df

これは、さまざまなコンテキストでの Docker のディスク使用量を示しています。

• イメージ – イメージ リポジトリからダウンロードされ、システム上に構築されたイメージの合計サイズ。
• コンテナ – 実行中のコンテナによって使用されるディスク容量の合計 (すべてのコンテナの読み取り/書き込み層の合計容量を意味します)。
• ローカル ボリューム – コンテナにマウントされたローカル ストレージのボリューム。
• ビルド キャッシュ – イメージ構築プロセスによって生成される一時ファイル (BuildKit ツールを使用。Docker バージョン 18.09 以降で利用可能)。

この単純な転送の後、あなたはディスクからゴミを取り除き、貴重なギガバイトを生き返らせたいと切望しているでしょう (注: 特に毎月これらのギガバイトの家賃を払っている場合)。

コンテナごとのディスク使用量

ホスト マシン上でコンテナーを作成するたびに、いくつかのファイルとディレクトリが /var/lib/docker ディレクトリに作成されます。そのうちの次の点に注目してください。

• ディレクトリ /var/lib/docker/containers/container_ID – 標準のログ ドライバーを使用する場合、ここにイベント ログが JSON 形式で保存されます。 詳細すぎるログや、誰も読み取ったり処理したりしないログは、ディスクがいっぱいになることがよくあります。
• /var/lib/docker/overlay2 ディレクトリには、コンテナーの読み取り/書き込みレイヤーが含まれています (overlay2 は、ほとんどの Linux ディストリビューションで優先されるドライバーです)。 コンテナがそのファイル システムにデータを保存する場合、データはこのディレクトリに配置されます。

コンテナーの起動やイメージの構築にまったく関与していない、純粋な Docker がインストールされているシステムを想像してみましょう。 ディスク容量の使用状況レポートは次のようになります。

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         0          0          0B         0B
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

たとえば、NGINX などのコンテナを起動してみましょう。

$ docker container run --name www -d -p 8000:80 nginx:1.16

ディスクに何が起こるか:

• 画像は 126 MB を占めます。これはコンテナ内で起動したものと同じ NGINX です。
• コンテナはとんでもない 2 バイトを消費します。

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          1          2B         0B (0%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

結論から言うと、解放できるスペースはまだありません。 2 バイトというのはまったく無意味なので、NGINX が予期せずどこか 100 メガバイトのデータを書き込み、まさにこのサイズのファイル test.img を内部に作成したと想像してみましょう。

$ docker exec -ti www 
  dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1024*100]

ホスト上のディスク領域の使用状況をもう一度調べてみましょう。 そこでは、コンテナーが 100 メガバイトを占有していることがわかります。

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          1          104.9MB    0B (0%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

あなたの好奇心旺盛な脳は、test.img ファイルがどこにあるのかすでに疑問に思っていると思います。 探してみましょう:

$ find /var/lib/docker -type f -name test.img
/var/lib/docker/overlay2/83f177...630078/merged/test.img
/var/lib/docker/overlay2/83f177...630078/diff/test.img

詳細には立ち入りませんが、test.img ファイルは読み書きレベルに配置されており、overlay2 ドライバーによって制御されていることがわかります。 コンテナを停止すると、ホストは原則としてこのスペースを解放できることを通知します。

# Stopping the www container
$ docker stop www

# Visualizing the impact on the disk usage
$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          0          104.9MB    104.9MB (100%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

どうすればこれができるでしょうか？ コンテナーを削除すると、対応するスペースが読み取り/書き込みレベルでクリアされます。

次のコマンドを使用すると、インストールされているすべてのコンテナを一度に削除し、コンテナによって作成されたすべての読み取り/書き込みファイルをディスクからクリアできます。

$ docker container prune
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Deleted Containers:
5e7f8e5097ace9ef5518ebf0c6fc2062ff024efb495f11ccc89df21ec9b4dcc2

Total reclaimed space: 104.9MB

そこで、コンテナを削除することで 104,9 メガバイトを解放しました。 ただし、以前にダウンロードしたイメージはもう使用しないため、削除してリソースを解放する候補にもなります。

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          0          126M       126M (100%)
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

注: イメージが少なくとも XNUMX つのコンテナーで使用されている限り、このトリックは使用できません。

上記で使用した prune サブコマンドは、停止したコンテナーにのみ影響します。 停止したコンテナだけでなく実行中のコンテナも削除したい場合は、次のコマンドのいずれかを使用する必要があります。

# Historical command
$ docker rm -f $(docker ps –aq)

# More recent command
$ docker container rm -f $(docker container ls -aq)

補足: コンテナーの起動時に -rm パラメーターを使用すると、コンテナーが停止すると、コンテナーが占有していたすべてのディスク領域が解放されます。

ディスクイメージの使用

数年前までは、数百メガバイトのイメージ サイズはまったく普通でした。Ubuntu イメージの重さは 600 メガバイト、Microsoft .Net イメージの重さは数ギガバイトでした。 あの毛むくじゃらの時代には、イメージ間でレベルを共有していたとしても、イメージを XNUMX つダウンロードするだけで、空きディスク容量に大きな負担がかかる可能性がありました。 現在では、偉大な方に敬意を表しますが、画像の重さははるかに軽くなりましたが、それでも、何らかの予防策を講じないと、利用可能なリソースがすぐにいっぱいになってしまう可能性があります。

エンド ユーザーには直接表示されない画像にはいくつかの種類があります。

• 中間イメージ。これに基づいて他のイメージが収集されます。これらの「他の」イメージに基づいたコンテナを使用する場合、中間イメージは削除できません。
• ダングリング イメージは、実行中のどのコンテナからも参照されない中間イメージであり、削除することができます。
• 次のコマンドを使用すると、システム上の未解決イメージを確認できます。

$ docker image ls -f dangling=true
REPOSITORY  TAG      IMAGE ID         CREATED             SIZE
none      none   21e658fe5351     12 minutes ago      71.3MB

それらは次の方法で削除できます。

$ docker image rm $(docker image ls -f dangling=true -q)

prune サブコマンドを使用することもできます。

$ docker image prune
WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N] y
Deleted Images:
deleted: sha256:143407a3cb7efa6e95761b8cd6cea25e3f41455be6d5e7cda
deleted: sha256:738010bda9dd34896bac9bbc77b2d60addd7738ad1a95e5cc
deleted: sha256:fa4f0194a1eb829523ecf3bad04b4a7bdce089c8361e2c347
deleted: sha256:c5041938bcb46f78bf2f2a7f0a0df0eea74c4555097cc9197
deleted: sha256:5945bb6e12888cf320828e0fd00728947104da82e3eb4452f

Total reclaimed space: 12.9kB

突然、XNUMX つのコマンドですべてのイメージを (ぶら下がっているだけでなく) 完全に削除したい場合は、次のようにすることができます。

$ docker image rm $(docker image ls -q)

ボリュームごとのディスク使用量

ボリュームは、コンテナのファイル システムの外部にデータを保存するために使用されます。 たとえば、アプリケーションの結果を他の方法で使用するために保存したい場合です。 一般的な例はデータベースです。

MongoDB コンテナを起動し、コンテナの外部にボリュームをマウントし、そこからデータベース バックアップを復元しましょう (bck.json ファイルで利用可能です)。

# Running a mongo container
$ docker run --name db -v $PWD:/tmp -p 27017:27017 -d mongo:4.0

# Importing an existing backup (from a huge bck.json file)
$ docker exec -ti db mongoimport 
  --db 'test' 
  --collection 'demo' 
  --file /tmp/bck.json 
  --jsonArray

データは、ホスト マシンの /var/lib/docker/volumes ディレクトリに配置されます。 しかし、コンテナの読み取り/書き込みレベルではなぜそうではないのでしょうか? MongoDB イメージの Dockerfile では、/data/db ディレクトリ (MongoDB がデフォルトでデータを保存する場所) がボリュームとして定義されているためです。

補足: データを生成する必要があるイメージの多くは、そのデータを保存するためにボリュームを使用します。

MongoDB を十分に試してコンテナを停止 (または削除) しても、ボリュームは削除されません。 次のようなコマンドで明示的に削除するまで、貴重なディスク領域を占有し続けます。

$ docker volume rm $(docker volume ls -q)

または、すでにおなじみの prune サブコマンドを使用することもできます。

$ docker volume prune
WARNING! This will remove all local volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Volumes:
d50b6402eb75d09ec17a5f57df4ed7b520c448429f70725fc5707334e5ded4d5
8f7a16e1cf117cdfddb6a38d1f4f02b18d21a485b49037e2670753fa34d115fc
599c3dd48d529b2e105eec38537cd16dac1ae6f899a123e2a62ffac6168b2f5f
...
732e610e435c24f6acae827cd340a60ce4132387cfc512452994bc0728dd66df
9a3f39cc8bd0f9ce54dea3421193f752bda4b8846841b6d36f8ee24358a85bae
045a9b534259ec6c0318cb162b7b4fca75b553d4e86fc93faafd0e7c77c79799
c6283fe9f8d2ca105d30ecaad31868410e809aba0909b3e60d68a26e92a094da

Total reclaimed space: 25.82GB
luc@saturn:~$

イメージビルドキャッシュにディスクを使用する

Docker 18.09 では、BuildKit ツールのおかげでイメージ作成プロセスがいくつか変更されました。 これにより、プロセスの速度が向上し、データ ストレージとセキュリティ管理が最適化されます。 ここでは、この素晴らしいツールの詳細をすべて検討するのではなく、このツールがディスク領域の使用の問題にどのように対処するかのみに焦点を当てます。

完全に単純な Node.Js アプリケーションがあるとします。

• Index.js ファイルは、受信した各リクエストに XNUMX 行で応答する単純な HTTP サーバーを起動します。
• package.json ファイルは依存関係を定義します。依存関係のうち、HTTP サーバーの実行には Expressjs のみが使用されます。

$ cat index.js
var express = require('express');
var util    = require('util');
var app = express();
app.get('/', function(req, res) {
  res.setHeader('Content-Type', 'text/plain');
  res.end(util.format("%s - %s", new Date(), 'Got Request'));
});
app.listen(process.env.PORT || 80);

$ cat package.json
    {
      "name": "testnode",
      "version": "0.0.1",
      "main": "index.js",
      "scripts": {
        "start": "node index.js"
      },
      "dependencies": {
        "express": "^4.14.0"
      }
    }

イメージを構築するための Dockerfile は次のようになります。

FROM node:13-alpine
COPY package.json /app/package.json
RUN cd /app && npm install
COPY . /app/
WORKDIR /app
EXPOSE 80
CMD ["npm", "start"]

BuildKit を使用せずに、通常の方法でイメージをビルドしましょう。

$ docker build -t app:1.0 .

ディスク領域の使用状況を確認すると、基本イメージ (node:13-alpine) と宛先イメージ (app:1.0) のみが領域を占有していることがわかります。

TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         2          0          109.3MB    109.3MB (100%)
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

BuildKit を使用して、アプリケーションの 1 番目のバージョンを構築しましょう。 これを行うには、DOCKER_BUILDKIT 変数を XNUMX に設定するだけです。

$ DOCKER_BUILDKIT=1 docker build -t app:2.0 .

ここでディスク使用量を確認すると、そこにビルド キャッシュ (buid-cache) が関与していることがわかります。

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         2          0          109.3MB    109.3MB (100%)
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    11         0          8.949kB    8.949kB

これをクリアするには、次のコマンドを使用します。

$ docker builder prune
WARNING! This will remove all dangling build cache.
Are you sure you want to continue? [y/N] y
Deleted build cache objects:
rffq7b06h9t09xe584rn4f91e
ztexgsz949ci8mx8p5tzgdzhe
3z9jeoqbbmj3eftltawvkiayi

Total reclaimed space: 8.949kB

すべてクリア！

そこで、コンテナ、イメージ、ボリュームが占有しているディスク領域をクリーンアップすることに注目しました。 これには prune サブコマンドが役立ちます。 ただし、Docker システム レベルでも使用でき、できる限りすべてをクリーンアップします。

$ docker system prune
WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all dangling images
  - all dangling build cache

Are you sure you want to continue? [y/N]

何らかの理由で Docker マシンのディスク領域を節約している場合は、このコマンドを定期的に実行することが習慣になるはずです。

出所： habr.com