カテゴリー: docker

  • 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ユーザーを外部から接続できるようにする設定は、公開環境での利用は避けてください。

  • aws cli コマンドを実行するとamazon/aws-cli コンテナが起動するようにする

    .zshrc に alias を登録するだけ

    alias aws='docker run --rm -i -v ~/.aws:/root/.aws -v $(pwd):/aws --env AWS_PAGER="" amazon/aws-cli'
    

    当然 docker などがインストールされている必要がある。

  • Baseimage-dockerとは

    Baseimage-dockerとは

    docker は 1コンテナ 1プロセスで動かすという思想のもと作られているが、普通のコンテナ思想のもと作られたコンテナではない。

    ssh でログインすることもできるし、 cron も動かすこともできる。

    supervisorなどのプロセスコントロールシステムを使えば複数プロセス起動させることもできるので、この仕組みを使っているちょっと変わった 80M 程度の軽量なコンテナだ。

    利用方法は以下の通り。まずは pull

    docker pull phusion/baseimage:master

    起動

    docker run --rm -it phusion/baseimage:master

    Baseimage-dockerのiniプログラムが実行される。

    ctrl + cで抜ける事ができる

    この ini 処理で supervisor が動き、そのプロセスの中で ssh を受け付けたり, cron を動かしたりしている。

    Debug方法

    Baseimage-dockerのiniプログラムを実行させず、直接bashを起動は以下の通り

    直接コンテナに入ることができる。

    docker run --rm -it phusion/baseimage:master bash -l
  • 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');

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

  • entrypoint の設定された docker の中に入る

    entrypoint の設定された docker の中に入る

    概要

    docker では entrypoint が設定されていると、
    docker の中に入るために 起動シェルを変更したとしても
    entrypoint の引数として認識されてしまう事がある。

    entrypoint を変更する事で、コンテナ内に入る事が可能になる。

    “`

    docker run -it --rm --entrypoint /bin/bash tsukada/image

     

  • Unable to obtain Outpost ARN from EC2 Metadata: EC2MetadataError: failed to make EC2Metadata request

    Unable to obtain Outpost ARN from EC2 Metadata: EC2MetadataError: failed to make EC2Metadata request

    はじめに

    ECSで割り当てたEC2が、クラスタに参加できない場合の対処。

    What to do when EC2 assigned by ECS cannot join the cluster.

    tail -f  /var/log/ecs/ecs-agent.log.2019-11-12-04 
    
    2019-11-12T04:20:19Z [INFO] Restored from checkpoint file. I am running as 'arn:aws:ecs:ap-northeast-1:xxx:container-instance/xxx:container-4f04-xxx:container-9da7-xxx:container' in cluster 'account-web-ec2'
    2019-11-12T04:20:19Z [INFO] Remaining mem: 3885
    2019-11-12T04:20:19Z [ERROR] Unable to register as a container instance with ECS: ClientException: Referenced container instance xxx:container-4f04-xxx:container-9da7-xxx:container not registered.
    	status code: 400, request id: xxx:container-xxx:container-47a3-90a6-xxx:container
    2019-11-12T04:20:19Z [ERROR] Error re-registering: ClientException: Referenced container instance xxx:container-4f04-xxx:container-9da7-xxx:container not registered.
    	status code: 400, request id: ea19fb3f-06e3-47a3-90a6-xxx:container
    
    
    2019-11-12T04:20:35Z [INFO] Loading configuration
    2019-11-12T04:20:35Z [INFO] Image excluded from cleanup: amazon/amazon-ecs-agent:latest
    2019-11-12T04:20:35Z [INFO] Image excluded from cleanup: amazon/amazon-ecs-pause:0.1.0
    2019-11-12T04:20:35Z [INFO] Amazon ECS agent Version: 1.32.1, Commit: 4285f58f
    2019-11-12T04:20:35Z [INFO] Creating root ecs cgroup: /ecs
    2019-11-12T04:20:35Z [INFO] Creating cgroup /ecs
    2019-11-12T04:20:35Z [INFO] Loading state! module="statemanager"
    2019-11-12T04:20:35Z [INFO] Event stream ContainerChange start listening...
    2019-11-12T04:20:35Z [INFO] Restored cluster 'account-web-ec2'
    2019-11-12T04:20:35Z [WARN] Unable to obtain Outpost ARN from EC2 Metadata: EC2MetadataError: failed to make EC2Metadata request

    対処

    待てども待てどもクラスタに参加できない場合は、

    If you can’t join the cluster,

    “` /var/lib/ecs/data/ecs_agent_data.json “`

    を削除(もしくは退避)させることで、クラスタに参加できるようになる。
    成功すると以下の通りになる。

    By deleting (or evacuating), you can join the cluster.
    If successful output is below

     tail -f  /var/log/ecs/ecs-agent.log.2019-11-12-04 
    2019-11-12T04:25:31Z [INFO] Registration completed successfully. I am running as 'arn:aws:ecs:ap-northeast-1:xxxx:container-instance/xxxx-xxxx-xxxx-xxxx-xxxx' in cluster 'account-web-ec2'
    2019-11-12T04:25:31Z [INFO] Saving state! module="statemanager"
    2019-11-12T04:25:31Z [INFO] Beginning Polling for updates
    2019-11-12T04:25:31Z [INFO] Event stream DeregisterContainerInstance start listening...
    2019-11-12T04:25:31Z [INFO] Initializing stats engine

    参考情報

    https://dev.classmethod.jp/etc/ecsec2_cluster_failed/

     

     

     

  • ERROR: Service ‘server’ failed to build: Error parsing reference: “node:10 as frontend-builder” is not a valid repository/tag: invalid reference format

    ERROR: Service ‘server’ failed to build: Error parsing reference: “node:10 as frontend-builder” is not a valid repository/tag: invalid reference format

    はじめに

    git cloneしたリポジトリで “` docker build “` を行ったところ、“` invalid reference format “`というエラーが発生したので、原因と対策について記載する。

    エラー内容

    docker build .
    Sending build context to Docker daemon 7.027 MB
    Step 1/18 : FROM node:10 as frontend-builder
    Error parsing reference: "node:10 as frontend-builder" is not a valid repository/tag: invalid reference format

    原因

    Dockerにmulti stage buildという事ができるようになった事をきっかけに、Dockerfileの書き方が数年前に変わった。

    この記事(https://qiita.com/minamijoyo/items/711704e85b45ff5d6405)にわかりやすく解説してある。

    multi stage buildの名前の通り、docker buildを複数のビルドに分割して実行できる。

    手元のdockerのversionを確認すると、確かに古かった。

    Client:
     Version:         1.13.1
     API version:     1.26
     Package version: docker-1.13.1-102.git7f2769b.el7.centos.x86_64
     Go version:      go1.10.3
     Git commit:      7f2769b/1.13.1
     Built:           Mon Aug  5 15:09:42 2019
     OS/Arch:         linux/amd64
    
    Server:
     Version:         1.13.1
     API version:     1.26 (minimum version 1.12)
     Package version: docker-1.13.1-102.git7f2769b.el7.centos.x86_64
     Go version:      go1.10.3
     Git commit:      7f2769b/1.13.1
     Built:           Mon Aug  5 15:09:42 2019
     OS/Arch:         linux/amd64
     Experimental:    false

    対処

    dockerをremoveし、最新のdocker(docker-ce)をインストールした。

    # rpm -qa | grep docker
    docker-common-1.13.1-102.git7f2769b.el7.centos.x86_64
    docker-client-1.13.1-102.git7f2769b.el7.centos.x86_64
    docker-1.13.1-102.git7f2769b.el7.centos.x86_64

    削除

    rpm -e docker
    rpm -e docker-client
    rpm -e docker-common

    その後、インストール。
    インストール手順は以下公式ドキュメントを参照。

    https://weblabo.oscasierra.net/docker-ce-install-centos7/

     

     

  • 【Docker】ストレージ容量不足時の対処法【解決済み】

    【Docker】ストレージ容量不足時の対処法【解決済み】

    はじめに

    Dockerのビルドサーバーでストレージ不足が発生しました。
    不要なファイルを削除する必要があるため、安全に容量を確保する方法を紹介します。
    dockerで/var/lib/docker/overlay2 が肥大化した時の対処になります。

    まず対応すべきこと

    現状把握

    Dockerがディスク容量を圧迫している原因を確認するため、以下のコマンドを使用します。

    docker system df このコマンドで、Dockerに関連するディスク使用状況を確認できます。

    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
    対処

    使用されていないコンテナ、ボリューム、ネットワーク、イメージを削除するには、以下のコマンドを使用します。

    docker system prune

    ただし、使用されていないボリュームとイメージを削除するには、以下のオプションが必要です。
    docker system prune --volumes --all

    volumesの削除

    上記コマンドで、不要なvolumesを削除しました。この操作で、355.4MBの容量を確保できます。ただし、storageの削除には、–volumesオプションを追加する必要があります。

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

    Total reclaimed space: 355.4MB
    ただし、storageの削除には、 --volumes オプションを追加する必要があります。

    imagesの削除

    docker system prune --all

    作業後

    上記の操作を完了した後、Dockerのディスク使用状況を再度確認すると、すべてのカテゴリーで容量が0になります。

  • standard_init_linux.go:190: exec user process caused “exec format error”

    standard_init_linux.go:190: exec user process caused “exec format error”

    概要

    dockerで起動シェルを渡した際、 “` standard_init_linux.go:190: exec user process caused “exec format error” “` というエラーが発生した際の対処

    原因

    起動シェルの中でshebangが抜けていたことが原因

    dockerの起動スクリプトでは必ず指定しなければならない

    対処

    起動シェルの1行目に

    #!/bin/bash

    を追加してあげるのみ(環境によって適宜変える)

    そもそもshebangとは

    “`  #! “` で始まる行。

    実行プログラムのインタプリタが定義される。

    ほとんどのプログラムは shebang が自動補完されるため無くても動く。しかし、dockerでは省略が不可能。shebangが必要なようだ。