Dockerトラブルシューティング：よくあるエラーと解決策ガイド 🛠️

🤔 原因

このエラーは、Dockerがシステムにインストールされていないか、インストールされていてもPATH環境変数が正しく設定されていない場合に発生します。

💡 対処法

1. Dockerのインストール確認: まず、Dockerが正しくインストールされているか確認します。インストールされていない場合は、Docker公式サイトの手順に従ってインストールしてください。
2. PATH環境変数の確認: Dockerがインストールされているにも関わらずエラーが出る場合、Dockerの実行ファイルへのパスがPATH環境変数に含まれていない可能性があります。

   LinuxやmacOSの場合、.bashrc、.zshrcなどのシェル設定ファイルにDockerのパスを追加します。通常、Dockerは /usr/bin/docker や /usr/local/bin/docker などにインストールされます。

   Windowsの場合、システムの環境変数設定でDockerのインストールディレクトリ（通常は C:\Program Files\Docker\Docker\resources\bin）をPATHに追加します。

3. シェルの再起動または再ログイン: PATH設定を変更した後は、ターミナル（シェル）を再起動するか、システムに再ログインして変更を反映させてください。

🤔 原因

このエラーは、コンテナが起動しようとしている実行ファイル（DockerfileのENTRYPOINTやCMDで指定されたもの）が見つからない場合に発生します。よくある原因は以下の通りです。

• Dockerfile内のCOPYやADD命令で、実行ファイルがコンテナ内の正しい場所にコピーされていない。
• ENTRYPOINTやCMDで指定されたパスが間違っている。
• スクリプトファイルを実行しようとしているが、そのスクリプトの1行目（Shebang: #!/bin/sh など）で指定されたインタプリタ（例: /bin/sh）がコンテナ内に存在しない、またはパスが違う。
• スクリプトファイルがWindows環境で作成され、改行コードがCRLF (\r\n) になっている。LinuxコンテナはLF (\n) を期待するため、インタプリタが正しく認識できない（例: /bin/sh\r を見つけようとしてしまう）。

💡 対処法

1. パスの確認: Dockerfile内のCOPY/ADD命令と、ENTRYPOINT/CMDで指定しているパスが正しいか、ファイルが期待される場所に存在するか確認します。

   デバッグのために、一時的にENTRYPOINT/CMDをsleep infinityなどに変更してコンテナを起動し、docker exec -it <container_id> bash (または sh) でコンテナ内に入り、lsコマンドなどでファイルパスを確認すると良いでしょう。

   # Dockerfile の例 (デバッグ用)
   FROM ubuntu:latest
   COPY ./my_script.sh /app/my_script.sh
   # CMD ["/app/my_script.sh"] # 元のCMDはコメントアウト
   CMD ["sleep", "infinity"]

   # コンテナ起動後
   docker exec -it <container_id> ls /app

2. Shebangの確認: スクリプトファイルを実行している場合、1行目のShebang (例: #!/bin/sh, #!/bin/bash, #!/usr/bin/env node など) が正しく、指定されたインタプリタがコンテナ内に存在することを確認します。Alpine Linuxベースのイメージなど、bash がデフォルトで入っていない場合もあるので注意が必要です。
3. 改行コードの修正: スクリプトファイルがWindowsで作成された場合、改行コードをLFに変換する必要があります。テキストエディタの設定で改行コードをLFに変更して保存するか、dos2unixのようなツールを使用します。

   # Linux/macOS で dos2unix がインストールされている場合
   dos2unix your_script.sh

   Gitを使用している場合、.gitattributesファイルでテキストファイルの改行コードを自動的にLFに変換するように設定することも有効です。

   * text=auto eol=lf

4. 実行権限の付与: スクリプトファイルに実行権限がない場合もあります。Dockerfile内でRUN chmod +x /path/to/your/script.shのように実行権限を付与します。

   FROM ubuntu:latest
   COPY ./my_script.sh /app/my_script.sh
   RUN chmod +x /app/my_script.sh
   CMD ["/app/my_script.sh"]

🤔 原因

Dockerを使用していると、イメージ、コンテナ、ボリューム、ビルドキャッシュなどがディスク容量を圧迫し、このエラーが発生することがあります。特にビルドを頻繁に行ったり、多くのコンテナを停止したまま放置していると発生しやすいです。

Dockerがデータを保存するデフォルトの場所 (Linuxでは通常 /var/lib/docker) があるファイルシステムの空き容量がなくなった、またはDocker Desktopなどの仮想環境で割り当てられたディスクイメージのサイズ上限に達した場合に発生します。

💡 対処法

1. Dockerのディスク使用状況の確認:

   まず、Dockerがどれくらいのディスク容量を使用しているか確認します。

   docker system df

   これにより、イメージ、コンテナ、ローカルボリューム、ビルドキャッシュがそれぞれどれくらいの容量を使用しているかが表示されます。

2. 不要なDockerリソースの削除 (Prune):

   Dockerには、使用されていないリソースを一括で削除する便利なコマンドがあります。

   注意: 以下のコマンドは停止中のコンテナ、未使用のネットワーク、danglingイメージ (どのタグからも参照されていない中間イメージ)、ビルドキャッシュを削除します。--volumes を付けると未使用のボリュームも削除されます。削除対象をよく確認してから実行してください。

   # 停止中のコンテナ、未使用のネットワーク、danglingイメージ、ビルドキャッシュを削除
   docker system prune
   
   # 上記に加えて、未使用のボリュームも削除
   docker system prune --volumes
   
   # 上記に加えて、どのコンテナからも使用されていない全てのイメージ (danglingでないものも含む) も削除 (より強力)
   docker system prune -a --volumes

   個別に削除することも可能です:

   # 停止中の全コンテナを削除
   docker container prune
   
   # danglingイメージを削除
   docker image prune
   
   # 未使用の全イメージを削除
   docker image prune -a
   
   # 未使用のボリュームを削除
   docker volume prune
   
   # 未使用のネットワークを削除
   docker network prune
   
   # ビルドキャッシュを削除
   docker builder prune

3. 特定のコンテナ、イメージ、ボリュームの削除:

   不要であることがわかっている特定の要素を手動で削除します。

   docker rm <container_id_or_name> ... # コンテナ削除
   docker rmi <image_id_or_name> ...    # イメージ削除
   docker volume rm <volume_name> ... # ボリューム削除

4. Docker Desktopのディスクイメージサイズ変更 (macOS/Windows):

   Docker Desktopを使用している場合、設定画面 (Settings > Resources > Advanced) で Dockerが使用する仮想ディスクイメージの上限サイズ (Virtual disk limit) を増やすことができます。変更後はDocker Desktopの再起動が必要です。

5. Dockerデータディレクトリの移動 (Linux):

   /var/lib/docker があるパーティションの容量が小さい場合、より容量の大きい別のファイルシステムにDockerのデータディレクトリを移動させることができます。設定ファイル (/etc/docker/daemon.json) で data-root を指定し、Dockerデーモンを再起動します。

   {
     "data-root": "/path/to/new/docker/data"
   }

6. ビルドキャッシュの管理:

   マルチステージビルドを活用して最終的なイメージサイズを小さくしたり、不要なファイルがイメージに含まれないように.dockerignoreを適切に設定したりすることで、ビルドキャッシュやイメージサイズを抑制できます。

7. inode不足の確認 (Linux):

   ディスク容量に空きがあるのに no space left on device が出る場合、ディスク容量ではなくinode（ファイルやディレクトリの管理情報）の数が上限に達している可能性があります。特に小さなファイルが大量にある場合に起こりえます。

   df -ih

   IUse% が100%に近い場合はinode不足が原因です。不要なファイルを削除するか、ファイルシステムを再フォーマットする必要があります。