1 Minute Tips

タグ: docker

  • Dockerビルドエラーの原因と対策：apt-get updateエラーの解消方法

    Dockerビルドエラーの原因と対策：apt-get updateエラーの解消方法

    はじめに

    Dockerを利用したシステム開発・運用において、ビルドプロセス中に突然のエラーが発生するケースは少なくありません。特に、apt-get update や apt-get install コマンド実行時に見られるエラーは、ビルドの中断やデプロイの遅延につながり、業務に大きな影響を及ぼす可能性があります。この記事では、DebianベースのDockerイメージをビルド中に発生したリポジトリ署名エラーの原因と、それに対処するための具体的な手法について解説します。

    問題の発生：Dockerビルド中のエラー内容

    Dockerイメージをビルドする際、以下のエラーメッセージが表示され、プロセスが中断されました。

    #0 1.518 Err:1 http://deb.debian.org/debian bullseye InRelease
#0 1.518 At least one invalid signature was encountered.
...
#0 2.793 E: The repository 'http://deb.debian.org/debian bullseye-updates InRelease' is not signed.
ERROR: failed to solve: process "/bin/sh -c apt-get update && apt-get install -y openssh-client git libzip-dev && rm -rf /var/lib/apt/lists/*" did not complete successfully: exit code: 100

    このエラーにより、Dockerビルドプロセスが正常に完了せず、継続的な開発やデプロイに支障をきたしました。業務における生産性や信頼性確保の観点からも、迅速な原因特定と解決が求められます。

    原因の特定：リポジトリ署名エラーではなくストレージ不足

    初見では、リポジトリの署名エラーが原因と推測されるケースが多いですが、今回のエラーは異なりました。調査の結果、Dockerビルド時に一時ファイルが大量に生成され、サーバー上のストレージ容量が不足したことが根本原因でした。

    • 一時ファイルの蓄積:
      apt-get install コマンドは、パッケージのダウンロードおよびインストールの過程で一時ファイルを作成します。これが限られたストレージ領域を圧迫することで、結果的にビルドエラーを引き起こしました。
    • Dockerのキャッシュ管理:
      Dockerはビルドプロセス中にキャッシュや未使用リソースを保持するため、定期的なクリーンアップが不可欠です。ストレージ不足は、こうしたキャッシュが蓄積された結果とも言えます。

    対処法：ストレージ容量の確保とクリーンアップ手法

    問題解決には、まず十分なストレージ容量の確保が必要です。そこで、以下のコマンドを実行し、不要なDockerリソースを一掃することで、空き容量を確保しました。

    docker system prune --volumes

    このコマンドは、未使用のコンテナ、ネットワーク、イメージ、およびボリュームを削除し、システム全体のリソース管理を最適化します。特に、継続的にDockerを利用する環境では、定期的なクリーンアップを自動化する仕組みを導入することが推奨されます。

    結果：エラー解消とビルドプロセスの正常化

    上記の対処法を実施した後、再度Dockerビルドを試みたところ、エラーは解消され、プロセスが正常に完了しました。これにより、開発スケジュールへの影響を最小限に抑えることができ、運用環境の信頼性も向上しました。

    まとめ：Docker環境の健全な運用のために

    今回の事例は、Dockerビルド時のエラーメッセージが必ずしも原因を直接示していないことを示しています。エラーメッセージの裏に潜む要因（今回の場合はストレージ不足）を見極めるためには、以下のポイントが重要です。

    • 定期的なリソース管理:
      Dockerの未使用リソースやキャッシュの定期的なクリーンアップを実施し、ストレージ容量を最適化する。
    • 多角的なトラブルシューティング:
      エラー発生時には、単一の原因にとらわれず、システム全体のリソース状況や設定を総合的に確認する。
    • 自動化ツールの活用:
      Docker環境では、自動化ツールや監視システムを導入し、リソース使用状況をリアルタイムで把握することが効果的です。

    これらの対策により、Docker環境でのビルドエラーを未然に防ぎ、業務の効率化と信頼性向上を実現できます。Dockerのトラブルシューティングに関する知識とスキルは、今後の開発・運用において不可欠な要素となるでしょう。

  • What to do when /Var/Lib/Docker/Overlay2 gets bloated in Docker

    Introduction

    I ran out of storage on my docker build server. I need to delete unnecessary files, but there is a command to safely allocate space.

    What to do first

    grasp of the situation

    Identify what is putting pressure on the disk in docker.

    Use docker system df command, you can identify the disk usage related to docker.

    # docker system df
TYPE                    TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images               9              1              2.014GB   1.962GB (97%)
Containers           2              0              0B              0B
Local Volumes        4              2              824.6MB   781.2MB (94%)
Build Cache          0              0              0B              0B

    cope

    It will remove stopped containers, unused volumes, unused networks, and unused images.

    docker system prune

    However, the option to delete unused volumes and images is required.

    # docker system prune --help

Usage:	docker system prune [OPTIONS]

Remove unused data

Options:
  -a, --all             Remove all unused images not just dangling ones
      --filter filter   Provide filter values (e.g. 'label=<key>=<value>')
  -f, --force           Do not prompt for confirmation
      --volumes         Prune volumes

    Delete Volumes

    I was able to reduce the size of the file by 355.4MB.

    553d15cd6b78ad0f21788a22e9ce16a7295c4bab97609973
deleted: sha256:7ae9338aed73a0f33568db53740431038d3a1f779c4dae40d27433984e1cd97c
deleted: sha256:b1be54c8cadff1e50b87b93559320a1ae57b8d0dd326507148f7ca81d707beed
deleted: sha256:86d78f10b9718618eaae056f5dfa1edae518949aee4578e4147268e9db2e75f0

Total reclaimed space: 355.4MB

    However, this does not remove the storage.

    use –volumes optiion. you can also delete storage.

    docker system prune --volumes
WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all volumes not used by at least one container
        - all dangling images
        - all build cache
Are you sure you want to continue? [y/N] y

    Deleting Images

    If you choose –all option. you can also delete images.

    # docker system prune --all
WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all images without at least one container associated to them
        - all build cache
Are you sure you want to continue? [y/N]

    After work

    When you finish deleting unnecessary files, it will be zero.

    # 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
  • M1 mac で Dockerを使ってMySQL 5.7を外部から接続できるように設定する

    M1 mac で Dockerを使ってMySQL 5.7を外部から接続できるように設定する

     

    Dockerを使ってMySQL 5.7を外部から接続できるように設定する

    Dockerを使ってMySQLを簡単に起動する際、外部からの接続設定にちょっとしたコツが必要です。

    この記事では、その手順をシンプルにまとめています。

    1. 概要

    基本的には、MySQLの設定を変更して、どのホストからでも接続を受け入れるようにする必要があります。加えて、Dockerコンテナ内のMySQLユーザー設定も変更する必要があります。

    2. 手順

    以下のコードを実行します:

    git clone https://github.com/GitSumito/CodeArsenal.git
    cd CodeArsenal/mysql-external-access
    sh ./main.sh

     

    3. 詳細な手順の説明

    1. custom_my.cnf という設定ファイルを作成し、MySQLがどのホストからでも接続を受け入れるように bind-address を設定します。
    2. DockerでMySQLを起動します。この際、上で作成した custom_my.cnf をMySQLの設定ディレクトリにマウントします。
    3. MySQLが完全に起動するのを待ちます（この例では30秒待機していますが、環境によっては調整が必要です）。
    4. docker exec を使用してMySQLコンテナ内でユーザー設定を行います。この例では、任意のホストからの接続を受け入れるrootユーザーを作成しています。

    4. 注意点

    この設定は開発やテスト環境での利用を想定しています。セキュリティの観点から、本番環境での利用は推奨しません。特に、パスワードなしのrootユーザーを外部から接続できるようにする設定は、公開環境での利用は避けてください。

  • Dockerfile での COPY コマンドによる「cannot copy to non-directory」というエラーについて

    Dockerfile での COPY コマンドによる「cannot copy to non-directory」というエラーについて

    Dockerfile に

    COPY data /direcotry/

    上記 の通り記載したところ

    cannot copy to non-directory: /var/lib/docker/overlay2/mmfii39iwldt2x2p997ukyz4m/merged/directory/export

    というエラーになった。

    コピー先のディレクトリ名まで記載することで問題は解消できる

    COPY data /direcotry/data

     

  • error pulling image configuration: Get https://xxxx : net/http: TLS handshake timeout

    error pulling image configuration: Get https://xxxx : net/http: TLS handshake timeout

    はじめに

    docker pullした際、以下のような TLS handshake timeout が発生

    # docker pull koda/docker-knowledge
Using default tag: latest
Trying to pull repository docker.io/koda/docker-knowledge ... 
latest: Pulling from docker.io/koda/docker-knowledge
55cbf04beb70: Pulling fs layer 
1607093a898c: Pulling fs layer 
9a8ea045c926: Pulling fs layer 
1290813abd9d: Waiting 
8a6b982ad6d7: Waiting 
abb029e68402: Waiting 
8cd067dc06dc: Waiting 
1b9ce2097b98: Waiting 
d6db5874b692: Waiting 
25b4aa3d52c5: Waiting 
53ec227dabf0: Waiting 
242938ace8b4: Waiting 
85bc5aaf4ec5: Waiting 
fd5b749ebe99: Waiting 
6636846685ec: Waiting 
error pulling image configuration: Get https://production.cloudflare.docker.com/registry-v2/docker/registry/v2/blobs/sha256/9a/9ae2dde61ad6947df46e2cc416be9249f314d187feb717f6e18c0dc9a46bf5bf/data?verify=1538549397-3vZspNti03KIKxRXPmQsQeUbucI%3D: net/http: TLS handshake timeout
#

    解決方法

    docker login

    # docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: 
Password: 
Login Succeeded
#
    一度ログインすると、その後取得が可能になる
    # docker pull koda/docker-knowledge
Using default tag: latest
Trying to pull repository docker.io/koda/docker-knowledge ... 
latest: Pulling from docker.io/koda/docker-knowledge
55cbf04beb70: Pull complete 
1607093a898c: Pull complete 
9a8ea045c926: Pull complete 
1290813abd9d: Pull complete 
8a6b982ad6d7: Pull complete 
abb029e68402: Pull complete 
8cd067dc06dc: Extracting 7.242 MB/122.1 MB
1b9ce2097b98: Download complete 
d6db5874b692: Download complete 
25b4aa3d52c5: Download complete 
53ec227dabf0: Download complete 
242938ace8b4: Download complete 
85bc5aaf4ec5: Download complete 
fd5b749ebe99: Download complete 
6636846685ec: Download complete 
    

    
			
    
		
    
		
	
  • 
		
		
    
			
    コンテナ内の mysql にリクエストされたクエリを確認する
    
			
    コンテナ内の mysql にリクエストされたクエリを確認する
    
			
    

    開発している際 コンテナの mysql にどのようなクエリ走ったのか確認したいことがある。
    




    スロークエリを 0秒に設定することで、DB にリクエストされた 全クエリを確認することができる。
    




    mysql> show variables like 'slow%';
+---------------------+--------------------------------------+
| Variable_name       | Value                                |
+---------------------+--------------------------------------+
| slow_launch_time    | 2                                    |
| slow_query_log      | OFF                                  |
| slow_query_log_file | /var/lib/mysql/5c364d250748-slow.log |
+---------------------+--------------------------------------+
3 rows in set (0.00 sec)

mysql> 

    




    slow_query_log が OFF になっている場合、出力されない。
    




    set global slow_query_log_file = '/tmp/mysql-slow.log';
set global long_query_time = 0;
set global slow_query_log = ON;
    




    上記コマンドを実行し、再度確認すると、スロークエリが出力されるようになってる。
    




    mysql> show variables like 'slow%';
+---------------------+---------------------+
| Variable_name       | Value               |
+---------------------+---------------------+
| slow_launch_time    | 2                   |
| slow_query_log      | ON                  |
| slow_query_log_file | /tmp/mysql-slow.log |
+---------------------+---------------------+
3 rows in set (0.00 sec)

mysql> 

    




    スロークエリが 0秒に設定されたか確認するのは
    




    show global variables like 'long_query_time';
    




    コマンドを実行する
    




    mysql> show global variables like 'long_query_time';
+-----------------+----------+
| Variable_name   | Value    |
+-----------------+----------+
| long_query_time | 0.000000 |
+-----------------+----------+
1 row in set (0.00 sec)

mysql> 

    




    結果
    




    
SET timestamp=1624328575;
INSERT INTO `xxx_transactions` (`id`,`operation`,`request`,`requested_at`,`response`,`responsed_at`,`metadata`,`status`,`failure_code`,`failure_message`,`created_by`,`created_at`) VALUES (105,'request',NULL,NULL,NULL,NULL,NULL,'succeeded',NULL,NULL,'123456789','2021-06-22 02:22:55.1492209');
    




    無事流れたクエリを確認することができた。