What's New Qiita

20200219のdockerに関する記事は9件です。

  • 投稿日：2020-02-19T23:00:35+09:00

docker, dockercomposeの概要とチートシート

docker, docker-composeの概要

docker

dockerのイメージ図は以下の感じ. dockerhubか誰かが作成したDockerfileから, イメージを作成またはインストールし、コンテナを作成する. nginxなどのミドルウェアを, pc, serverの環境と隔離して, 再現が可能

example.png

dockerの利点として,

  • pc, serverの環境を汚さない
  • 他人が構築した環境を簡単に再現可能(infrastructure as code)
  • デプロイなどが簡単

などが存在する.

docker-compose

docker-composeはイメージのビルドやコンテナの起動・停止を簡単にするためのツール.
例えば, 他人の開発環境を構築するために,コンテナを作成しようとした時に, 全く同じポートで, ディレクトリを共有して....と考えると, コンテナ作成時に

sudo docker run -d --name コンテナ名 -p ポート番号:コンテナのポート番号 -v 共有したいdirectory:コンテナ側のdirectory image名

のような長いコマンドを打たなければならない. docker-composeを用い, 共有したいポート番号、ディレクトリの情報などが書かれたymlファイルを読み込むことで、このような長いコマンドを打つ手間を省くことが可能.

docker基本操作

  • image

    • Dockerfileからimageの作成.
    cd <dockerfileが存在するdir>
sudo docker build -t image名前 .
    • imageの確認
    sudo docker images
    • imageの削除
    sudo docker rmi <image名 or id>

  • コンテナ

    • コンテナの作成(imageから)
    sudo docker run image名
    引数 効果
    -p ポート番号:コンテナ側のポート番号 ポートを対応付ける
    -v 共有したいディレクトリ:コンテナ側のディレクトリ directoryを共有
    -d 常駐化
    --name コンテナ名 コンテナに名前つける
    • コンテナの起動
    sudo docker attach <コンテナ名 or id>
    • コンテナの確認
    sudo docker ps
    • コンテナの削除
    sudo docker rm <container名 or id>
    • コンテナに入る
    sudo docker exec -i -t <コンテナ名> bash

    docker-composeの基本コマンド

    おおむね上記のdokcerの部分をdocker-commposeに置き換えるだけ.

  • コンテナの作成

cd <docker-compose.ymlが置かれたディレクトリ>
docker-compose up -d
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T23:00:35+09:00

dockerのinstall(ubuntu)と基本コマンド

dockerのinstall(ubuntu)と基本コマンド

docker

dockerのイメージ図は以下の感じ. dockerhubか誰かが作成したDockerfileから, イメージを作成またはインストールし、コンテナを作成する. nginxなどのミドルウェアを, pc, serverの環境と隔離して, 再現が可能

example.png

dockerの利点として,

  • pc, serverの環境を汚さない
  • 他人が構築した環境を簡単に再現可能(infrastructure as code)
  • デプロイなどが簡単

などが存在する.

dockerのinstall

公式の通りにinstall. (https://docs.docker.com/install/linux/docker-ce/ubuntu/). コピペしてさっさと終わらせたい人用は以下.

sudo apt-get update
sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo apt-key fingerprint 0EBFCD88
sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
sudo apt-get update
sudo apt-get install docker-ce

docker基本操作

  • image

    • Dockerfileからimageの作成.
    sudo docker build -t image名前 .
    • imageの確認
    sudo docker images
    • imageの削除
    sudo docker rmi <image名 or id>

  • コンテナ

    • コンテナの作成(imageから)
    sudo docker run -d --name コンテナ名 -p ポート番号:コンテナのポート番号 -v 共有したいdirectory:コンテナ側のdirectory image名
    引数 効果
    p ポートを対応付ける
    v directoryを共有
    d 常駐化
    name コンテナに名前つける
    • コンテナの起動
    sudo docker attach <コンテナ名 or id>
    • コンテナの確認
    sudo docker ps
    • コンテナの削除
    sudo docker rm <container名 or id>
    • コンテナに入る
    sudo docker exec -i -t <コンテナ名> bash
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T18:16:34+09:00

深夜にDockerコンテナ使ってるとslack経由でデスクトップに通知が届くようにしてみた

深夜にdocker-compose up -dしてるとデスクトップに「GO TO BED」と通知が来るようにしてみました。

cronを稼働させるためのコンテナを用意し、自動的にcurlコマンドでのslack投稿を行うようにすることで実装しています。お試しで作ったので実用性は低いです。

cronとは

指定したコマンドやシェルスクリプト等を日時指定で自動実行するための常駐プログラム(デーモンプロセス)。

内部では、1分毎に起動、/etc/crontab などに置かれているcrontabファイルを調査、該当する時刻の場合処理を実行、という処理が行われているようです。
crontabファイルの置き場所やデーモンとして起動するか否かなど、細かい違いがあるようですが今回そこまでは調べてません。

設計

docker-compose.ymlにcron稼働用のコンテナを追加し cron -f コマンドでcronタスクを常駐させるだけです。

slack側でWebhookの設定

slack側で Incoming Webhook を設定して、HTTPリクエストでslack投稿できるようにします。
なお、 Incoming Webhook は認証がないのでURLが漏れると悪意のあるユーザーからも投稿できるようになってしまいます。

実際の手順については、以下を参考にさせていただきました。
参考：SlackのWebhook URL取得手順

URLを取得したらcurlコマンドで投稿できるか確認してみましょう。

curl -X POST --data-urlencode "payload={\"channel\": \"#general\", \"username\": \"testuser\", \"text\": \"Hello\"}" https://hooks.slack.com/services/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

実装

深夜0時から6時まで、5分毎に「GO TO BED」と投稿されるようにしてみました。

構成
.
├ cron_alert/
│  └ Dockerfile
│  └ midnight_alert.sh
└ docker-compose.yml
docker-compose.yml
cron:
  build: ./cron_alert
  volumes:
    - ./cron_alert:/cron_dir
  ports:
    - "3456:3456"
Dockerfile
FROM ubuntu:latest

# TimeZone設定
ENV TZ Asia/Tokyo
RUN DEBIAN_FRONTEND=noninteractive

RUN apt-get update && apt-get install -y cron sudo curl vim tzdata

RUN echo '*/5 0-6 * * * root /cron_dir/midnight_alert.sh' >> /etc/crontab

CMD ["cron", "-f"]
midnight_alert.sh
#!/bin/sh

CHANNEL="#general"
USERNAME="webhookbot"
TEXT="GO TO BED   GO TO BED   GO TO BED   GO TO BED   GO TO BED   GO TO BED   GO TO BED   GO TO BED   GO TO BED   GO TO BED   GO TO BED   GO TO BED"
PAYLOAD="payload={\"channel\": \"$CHANNEL\", \"username\": \"$USERNAME\", \"text\": \"$TEXT\"}"

curl -X POST --data-urlencode "${PAYLOAD}" https://hooks.slack.com/services/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

参考：Docker コンテナ内でタスクを cron 起動する
参考：Dockerコンテナのタイムゾーン変更方法

最後に

深夜にdocker-compose up -dしてるとデスクトップに通知が来るのを確認して満足しました。
変なこと書いてたら指摘してくださるとうれしいです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T17:42:18+09:00

GCPのGPU付きのCompute Engine上で、Dockerの中で、Tensorflowを動かす方法。

GCPのGPU付きのCompute Engine上で、Dockerの中で、Tensorflowを動かす方法。作業メモ的な感じです。

実現できること

  • GPU + TensorflowでDeep Learning
  • 環境構築がかんたんで、いつでもゼロからやりなおしができる

やり方

Compute EngineでGPUとGPU Driver付きのインスタンスを作る

https://cloud.google.com/compute/docs/gpus/add-gpus?hl=ja
これに従うとできます。

Ubuntu 18.04で試してうまくいきました。

Dockerインストール

https://qiita.com/myyasuda/items/cb8e076f4dba5c41afbc

Tensorflowが動くdocker imageを動かす

docker run -it --rm tensorflow/tensorflow bash

参考 https://www.tensorflow.org/install/docker#gpu_support

参考資料

GCPでGPU付きのインスタンスを作る方法
https://cloud.google.com/compute/docs/gpus/add-gpus?hl=ja

compute engineのContainer optimizedイメージにnvidea driverを入れる方法。
https://github.com/GoogleCloudPlatform/cos-gpu-installer

dockerでtensorflowを使う方法
ホスト側にgpu driverさえ入っていれば動くらしい。
https://www.tensorflow.org/install/docker#gpu_support

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T13:00:57+09:00

docker環境のメールはmailhogで決まり

docker環境でメールどうしよう問題

  • 直接送りゃいいんじゃね?
    • いやいや、事故るっしょ。1万通とかメール送信してしもたら・・・
  • そのためだけにsendgridとかmailgunとか
    • おおげさ
  • postfixのコンテナあげる?
    • 環境つくるだけで一苦労しそう(docker-hubにあるけど)

ということでいろいろ探してたらMailHogというものを発見しました

  • メリット
    • 事故らない
    • いくらメール投げてもローカルにしかとどまらないので
    • 設定が簡単
    • WEB UIでメール確認ができる
  • デメリット
    • 日本語メールは文字化けすることがある、UTF-8でおねがいしたい
    • なぜかdockerコンテナが死ぬことがある、まあコンテナのリスタートしてください

Howto

1. docker-compose.ymlにはこれだけ追加するだけ

docker-compose.yml
mailhog:
  image: mailhog/mailhog
  ports:
    - "8025:8025"

2. mhsendmailを入れてください

  • https://github.com/mailhog/mhsendmail
  • goで出来ています
  • yumとかaptでsendmailいちいち入れるの面倒なので、こいつをマウントしてやれば良い
    • 例えばこんな感じ
docker-compose.yml
volumes:
  - "./bin/mhsendmail:/usr/local/bin/mhsendmail"

3. phpの人向け

  • webサーバのコンテナのphp.iniに追加(変更)しておくと、phpの標準mail関数でメール送信できますんで既存コードをいじらなくて済む
php.ini
sendmail_path = "/usr/local/bin/mhsendmail --smtp-addr=mailhog:1025"

以上です、快適なdockerライフを!!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T11:38:21+09:00

minioクライアント(mc コマンド)の使い方

はじめに

mcコマンドにより、minio(S3, GCS等でも可)をクライアント側からCUIで操作できる。インストール手順から簡単な使い方まで説明する。

インストール方法

下記URLの通りだが、記載しておく。
https://docs.min.io/docs/minio-client-quickstart-guide.html#test-your-setup

macOS

$ brew install minio/stable/mc

GNU/Linux

# 64-bit Intel Architectureの場合
$ wget https://dl.min.io/client/mc/release/linux-amd64/mc
# 64-bit PPC Architectureの場合
$ wget https://dl.min.io/client/mc/release/linux-ppc64le/mc
$ chmod +x mc

Microsoft Windows

下記から実行ファイルをダウンロードする。
https://dl.min.io/client/mc/release/windows-amd64/mc.exe

設定方法

立ち上げたminioの設定を~/.mc/config.jsonに記載して、mcコマンドが使えるようになる。
私の環境だと"lookup": "dns"とするとうまくいかなかった。

下記のようなminioの設定の場合で~/.mc/config.jsonを記載する。
host名 : hoge
ipアドレス or ドメイン : hoge.com
ポート : 9000
アクセスキー : minio
シークレットキー : minio123

~/.mc/config.json
{
        "version": "9",
        "hosts": {
                "hoge": {
                        "url": "http://hoge.com:9000/",
                        "accessKey": "minio",
                        "secretKey": "minio123",
                        "api": "S3v4",
                        "lookup": "auto"
                }
        }
}

コマンド

簡単な使い方を記載する。詳しくはhelpを参照。

# バケットを作成する
$ mc mb hoge/test
Bucket created successfully `hoge/test`.

# バケットとオブジェクトを確認する
$ mc ls hoge
[2020-02-19 11:07:39 JST]      0B test/

# ローカルからminioにコピーする
$ touch test.txt
$ mc cp test.txt hoge/test
$ mc ls hoge/test
[2020-02-19 11:10:27 JST]      0B test.txt

# minioからローカルにコピーする
$ rm test.txt
$ mc cp hoge/test/test.txt ./

# オブジェクトを削除する
$ mc rm hoge/test/test.txt
Removing `hoge/test/test.txt`.
$ mc ls hoge/test

# バケットを削除する
$ mc rb hoge/test
Removed `hoge/test` successfully.
$ mc ls hoge
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T10:29:32+09:00

EC-CUBE4 on Docker開発環境をtmpfsで速くしたい

以前、EC-CUBE4の快適な開発環境をDocker Composeで整える for Windowsにて、I/Oが多いフォルダをDocker Volumeに持たせる事で速度改善を試みたが、新たにtmpfsオプションなるものの存在を知ったため、それで更なる速度改善が出来ないか、検証してみた。

TL;DR

  • EC-CUBE4ならびに、Symfony3のDocker開発環境を作りたいときの話
  • varフォルダはtmpfsでマウントするとちょっと速くなる
  • vendorフォルダは毎回コンテナ起動時にcomposer install走らせるのは怠いので、Docker Volumeで保つのが良さそう
  • var,vendorをホストのフォルダと直接マウントすると、やはりありえないレベルで遅い

背景

https://github.com/EC-CUBE/ec-cube/pull/4204
https://github.com/EC-CUBE/ec-cube/pull/4391

EC-CUBE4(Symfony3)のDocker開発環境を構築するにあたり、一部のフォルダのIOが激しく、ホスト-コンテナ間で共有すると使い物にならないレベルで遅いという課題があった。

対策として、I/Oが多く主な速度低下の原因となる以下のフォルダについて、ホスト-コンテナ間で共有しないように設定を行った。

  • var
    • キャッシュ・ログ等
  • vendor
    • composer install による生成(DL)物

Dockerのボリュームマウントには.gitignoreのような一部のフォルダ・ファイルのみ除外する設定がない。
ただし除外したいフォルダのみを別途ボリュームマウント指定することで、ホストとの同期対象外となる。

docker-compose.yml
  ec-cube:
    # ...
    volumes:
      - ".:/var/www/html:cached"
      ### 同期対象からコストの重いフォルダを除外 #####################
      - "var:/var/www/html/var"
      - "vendor:/var/www/html/vendor"

試したいこと

特にvarフォルダについてはキャッシュ・ログの役割を持つため、永続化する必要はあまりない。
開発環境(devモード)においては頻繁に更新されるため、後述のtmpfsによる揮発性メモリで動作させ、I/Oを更に改善することで開発環境のレスポンスが向上するのではないかと考えた。

vendorフォルダについてはcomposerの実行結果(ダウンロードしたライブラリ)を永続化して保持する利点が大きいため、ボリュームのマウントのままで良いと思われるが、せっかくなので一緒に検証する。

tmpfsについて

tmpfsはUnix系OSにおける一時ファイルのための仕組みの共通名。tmpfsはファイルシステムにマウントされることを意図しており、これによりHDDをはじめとする永続性をもつ記憶装置の代わりに揮発性メモリに保存されるようにできる
出典: フリー百科事典『ウィキペディア（Wikipedia）

tmpfsでマウントした領域についてはSSDやHDDではなく、高速なメモリ上でRead/Writeが行われるようになるらしい。代わりに永続性はなくなり、コンテナ削除と同時にデータはクリアされる。一時的なキャッシュファイルであればここでよさそう。

そしてtmpfsは以下のように、Dockerの機能で簡単にマウントできた。
Qiita -- dockerのtmpfsオプション @Hiraku

docker-compose.yml
  ec-cube:
    # ...
    volumes:
      - ".:/var/www/html:cached"
    tmpfs:
      - "/var/www/html/var"
      - "/var/www/html/vendor"

計測

計測方法

Docker for Windows環境で動かしているため、以下のようにPowerShellからコンテナのコマンドを実行し、Measure-Commandにて処理時間を計測した。

PS *> measure-command { docker-compose exec ec-cube composer install }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 29
Milliseconds      : 681
Ticks             : 296816493
TotalDays         : 0.000343537607638889
TotalHours        : 0.00824490258333333
TotalMinutes      : 0.494694155
TotalSeconds      : 29.6816493
TotalMilliseconds : 29681.6493

コマンドは以下の3種を続けて実行し、それぞれの時間を計測した。

  • composer install
    • vendorにライブラリインストール。また、後述2コマンドを内包
  • bin/console cache:clear --no-warmup
    • var内のキャッシュクリア。最低限の生成も行っている？
  • bin/console cache:warmup --no-optional-warmers
    • var内にキャッシュ生成。

※ docker-compose exec ec-cube [Command] の形式

また、コンテナのビルド 及び composer install実行前の段階でvar/vendorフォルダは存在しない状態に揃えた。

# ホストからvar,vendorを削除
PS *> rm ./var/
PS *> rm ./vendor/

# コンテナのvar,vendorボリュームを削除
PS *> docker-compose down -v

計測結果(単位 sec/秒)

※ 各1回ずつしか試行していない & composer install が回線影響を受けるため、誤差は多々あります。

青…var⇒volume, vendor⇒volume (現行)
オレンジ…var⇒tmpfs, vendor⇒volume

composer install 結果

var \ vendor vendor Host vendor Docker Volume vendor Tmpfs
var Host 845.53 132.57 110.05
var Docker Volume 822.66 16.89 33.75
var Tmpfs 未計測 11.72 29.68

bin/console cache:clear --no-warmup (キャッシュクリア) 結果

var \ vendor vendor Host vendor Docker Volume vendor Tmpfs
var Host 85.79 10.99 9.85
var Docker Volume 30.81 1.82 1.82
var Tmpfs 未計測 1.76 1.78

bin/console cache:warmup --no-optional-warmers (キャッシュ生成) 結果

var \ vendor vendor Host vendor Docker Volume vendor Tmpfs
var Host 81.52 41.18 43.40
var Docker Volume 43.93 3.64 3.43
var Tmpfs 未計測 3.32 3.25

結果所感

  1. vendorをホストにマウントした状態でcomposer installを打つのは苦行。10分以上待たされる。varだけtmpfsにするパターンはもはや計測する意味がないのでやめた。
  2. (青)両方Docker Volumeはそこそこ速い。現行のこれでも問題はなさそう
  3. (オレンジ)両方tmpfsはやっぱり一番速い。が、vendorが永続化出来ないとdocker-composeをコンテナ起動時に毎回走らせなければならないので、起動が遅くなる
  4. varだけtmpfsにするのがバランス良さそう

課題

  • sqliteのファイルがvendor以下に配置されるため、varを揮発性にするとコンテナ再作成で消える。
  • docker-compose up 時にキャッシュ作成する仕組みが必要。
  • 画面ベースでの改善度合いはを途中から面倒になって確認していない

結論

varをtmpfs, vendorをDockerVolumeでマウントすることで、キャッシュ削除→作成で良くて0.5秒ほど動作改善が見込める（どんぶり勘定。正確なdevモードでのキャッシュ更新動作を把握していないので、的外れかも）
が、実際の開発環境でストレス軽減されるほど変わるかは、実際使ってみてこれから感触を確かめることにする。

varはブランチ切り替えた時などはリセットされた方がいいと思うし、tmpfsで揮発性にしてdocker-compose.ymlのcommand指定で毎回コンテナ起動時にキャッシュクリア/生成を実行する方がいい気がしている。

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T10:12:08+09:00

docker のネットワーク (docker0) 設定変更

docker のデフォルトのネットワークアドレスを変更します。
ホスト側は docker0 ネットワークインターフェースの IP アドレス変更、docker コンテナ側のネットワークアドレス(プール)の範囲を変更します。(IPv4 のみ)

前提 (docker バージョン)

docker バージョン
$ docker --version
Docker version 19.03.6, build 369ce74
$

ネットワーク(範囲)の変更

参照: Configure and troubleshoot the Docker daemon | Docker Documentation
参照: Customize the docker0 bridge | Docker Documentation

以下の手順で、ネットワークの変更を行います。

  1. 現状の確認
  2. 設定ファイルの作成
  3. dockerd の再起動
  4. 設定反映の確認

現状の確認

まずは、設定変更前の状態を確認しておきます。

コマンド ip addr show dev docker0 と docker network inspect bridge を実行して設定状態を確認します。

docker0インタフェースの確認 (ip addr show dev docker0)
$ ip addr show docker0
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:a3:f4:1d:e1 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
$
docker brigdeの確認 (docker network inspect bridge と ip addr show docker0)
$ docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "1aa4683e24270539e0d55f04fb90256e3110ece305e6c6b37408e202fc49d33e",
        "Created": "2020-02-14T22:11:59.222703633+09:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",         <- ネットワークレンジ
                    "Gateway": "172.17.0.1"            <- brigde (docker0) の IPアドレス
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]
$

デフォルトでは、ホストの bridge (docker0) のアドレスが 172.17.0.1、割り当てのネットワーク範囲が 172.17.0.0/16 になっています。

設定ファイルの作成

docker0 インターフェース (bridge) は、dockerd によって作成されます。
IP アドレスを変更するには下の2つの方法があります。

  1. 設定ファイルに記述する。
  2. 起動時の引数で指定する。

ここでは、設定ファイルで変更する方法を記載しておきます。

daemon の設定ファイルは下の通りです。

  • Linux: /etc/docker/daemon.json
  • Windows: C:\ProgramData\docker\config\daemon.json

デフォルトでは存在しないので、作成します。

/etc/docker/daemon.json (新規作成)
{
        "bip": "172.20.0.254/24"
}

上の例では、ホスト側の (bridge) IP アドレスを 172.20.0.254 に、docker クライアントのアドレスプール (ネットワークアドレス) を 172.20.0.0/24 に設定します。
bip の "172.20.0.254/24" は 24ビットマスクの (172.20.0.254 を含む範囲の) ネットワークアドレスです。

--option= で指定するオプション (option) は daemon.json に記述できます。

上の設定は、dockerd の起動オプションに --bip=172.20.0.254/24 を指定したのと同じ意味になります。

同じネットマスクで fixed-cidr を設定している例を見かけますが、bip のネットワークレンジ(範囲)と CIDR のレンジが同じであれば、fixed-cidr を指定する必要はありません。

dockerd の再起動

設定が終わったら、dockerd を再起動します。

再起動
$ sudo systemctl restart docker

設定変更後の確認

実施した設定で、ブリッジの設定が変更されていることを確認します。

デフォルトのホスト側ネットワークインタフェースは docker0 ですので、これを確認します。

インタフェースの変更確認 (ip addr show dev docker0)
$ ip addr show dev docker0
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:00:cf:b5:ba brd ff:ff:ff:ff:ff:ff
    inet 172.20.0.254/24 brd 172.20.0.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::c1fd:cbf0:c006:8663/64 scope link
       valid_lft forever preferred_lft forever
$

ブリッジ (bridge) を確認します。

bridge の変更確認 (docker network inspect bridge)
$ docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "784e35bf73471e88a2bd8450e91c2de6b5c297875a78ca2b34af74a1772296c8",
        "Created": "2020-02-15T01:16:39.444039309+09:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.20.0.254/24",
                    "Gateway": "172.20.0.254"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

fixed-cidr の併用

fixed-cidr を指定するのは、bip で指定したネットワークレンジよりも狭い範囲を指定する場合です。

例えば、bridge の IP アドレスを 172.20.0.254 (ネットワークアドレスを 24ビットマスク 172.20.0.0/24 = 172.20.0.0 ～ 172.20.0.255) にし、CIDR レンジを 25ビットマスク 172.20.0.128/25 (172.20.0.128 ～ 172.20.0.255) とするような場合です。

/etc/docker/daemon.json fixed-cidr 例1 (ネットマスクの値が異なっているところがポイント)
{
        "bip": "172.20.0.254/24",
        "fixed-cidr": "172.20.0.128/25"
}

これは、dockerd の起動オプションに --bip=172.20.0.254/24 --fixed-cidr=172.20.0.128/25 を指定したのと同じ意味になります。

bip に合わせて、172.20.0.254/25 と記載することもできます。

/etc/docker/daemon.json fixed-cidr 例2 (ネットマスクの値が異なっているところがポイント)
{
        "bip": "172.20.0.254/24",
        "fixed-cidr": "172.20.0.254/25"
}

例1の記載方法でも、例2の記載方法でも、反映される設定は同一です。

dockerd再起動とbridge設定確認
$ sudo systemctl restart docker && docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "711fc4ed0209dd8e2e34b4f922286db4f3f205f1f471dbadf706839883dd99d7",
        "Created": "2020-02-15T14:45:57.486131257+09:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.20.0.254/24",
                    "IPRange": "172.20.0.128/25",
                    "Gateway": "172.20.0.254"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

以下は、補足。

ネットワーク設定の確認

ネットワーク設定を確認します。

ホストの docker0 インタフェース

docker が使える環境 (docker daemon が動いている環境) では、ホストのネットワークインタフェースとして、デフォルトでは docker0 が構成されています。

docker0 インターフェース
$ ip addr show dev docker0
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:00:cf:b5:ba brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::c1fd:cbf0:c006:8663/64 scope link
       valid_lft forever preferred_lft forever
$

デフォルトでは、上の例のようにネットワークアドレスが 172.17.0.0/16 (= 172.17.0.0/255.255.0.0) となり、ホストの docker0 インタフェースのアドレスは 172.17.0.1 に設定されます。

docker のデフォルト設定の確認

docker のネットワーク設定を確認するには docker network コマンドを使います。

man docker-network(1)
DOCKER(1)                                                            DOCKER(1)

NAME
       docker-network - Manage networks

SYNOPSIS
       docker network

DESCRIPTION
       Manage networks

OPTIONS
       -h, --help[=false]
           help for network

SEE ALSO
       docker(1), docker-network-connect(1), docker-network-create(1),
       docker-network-disconnect(1), docker-network-inspect(1),
       docker-network-ls(1), docker-network-prune(1), docker-network-rm(1)

Docker Community                   Feb 2020                          DOCKER(1)

docker ネットワークドライバの一覧

docker network ls コマンドで docker ネットワークドライバの一覧を確認します。

man docker-network-ls(1)
DOCKER(1)                                                            DOCKER(1)

NAME
       docker-network-ls - List networks

SYNOPSIS
       docker network ls [OPTIONS]

DESCRIPTION
       Lists all the networks the Engine daemon knows about. This includes the
       networks that span across multiple hosts in a cluster, for example:

                  $ docker network ls
                  NETWORK ID          NAME                DRIVER          SCOPE
                  7fca4eb8c647        bridge              bridge          local
                  9f904ee27bf5        none                null            local
                  cf03ee007fb4        host                host            local
                  78b03ee04fc4        multi-host          overlay         swarm

       Use the --no-trunc option to display the full network id:

              $ docker network ls --no-trunc
              NETWORK ID                                                         NAME                DRIVER
              18a2866682b85619a026c81b98a5e375bd33e1b0936a26cc497c283d27bae9b3   none                null
              c288470c46f6c8949c5f7e5099b5b7947b07eabe8d9a27d79a9cbf111adcbf47   host                host
              7b369448dccbf865d397c8d2be0cda7cf7edc6b0945f77d2529912ae917a0185   bridge              bridge
              95e74588f40db048e86320c6526440c504650a1ff3e9f7d60a497c4d2163e5bd   foo                 bridge
              63d1ff1f77b07ca51070a8c227e962238358bd310bde1529cf62e6c307ade161   dev                 bridge

＜略＞
OPTIONS
       -f, --filter=
           Provide filter values (e.g. 'driver=bridge')

       --format=""
           Pretty-print networks using a Go template

       -h, --help[=false]
           help for ls

       --no-trunc[=false]
           Do not truncate the output

       -q, --quiet[=false]
           Only display network IDs

SEE ALSO
       docker-network(1)

Docker Community                   Feb 2020                          DOCKER(1)
docker ネットワークドライバ一覧 (docker network ls)
$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
1aa4683e2427        bridge              bridge              local
85fa1cc162f0        host                host                local
756cc38e0f4e        none                null                local
$

docker bridge の確認

docker network inspect コマンドで上に表示された bridge を指定して設定を確認します。

docker brigdeの確認 (docker network inspect bridge)
$ docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "1aa4683e24270539e0d55f04fb90256e3110ece305e6c6b37408e202fc49d33e",
        "Created": "2020-02-14T22:11:59.222703633+09:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]
$

デフォルトの設定は 172.17.0.0/16 ネットワークになっています。

            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]

参考: Customize the docker0 bridge | Docker Documentation

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-19T00:19:19+09:00

Docker上のWordpressでVolumeマウント時にプラグインのインストールや削除に失敗する場合の対処法。

はじめに

Docker上のWordpressにボリュームをマウントすると、プラグインのインストールや削除ができなかったので対処法をメモしておく。
ちなみにDocker Desktop for Macではこの記事の問題は起こらなかった。

環境

  • Ubuntu 18.04
  • Docker 19.03.6
  • Docker Compose 1.25.3
  • Wordpress 5.3.2

状況説明

まず、自分はwp-content/pluginsとwp-content/uploadsにファイルシステムからマウントした。

問題1 プラグインを削除できない。

下記のようにFTP情報を入力しろと言われる。

問題2 プラグインをインストールできない。

下記のようにディレクトリを作成できないというエラーがでる。
error1.png

対処法

Dockerfileを作成し、ENTRYPOINTでwp-contentとwp-content/plugins、wp-content/uploadsの所有者を変更してやればいい。

Dockerfile
FROM wordpress:latest

ENTRYPOINT chown www-data:www-data /var/www/html/wp-content /var/www/html/wp-content/plugins /var/www/html/wp-content/uploads && docker-entrypoint.sh apache2-foreground
# chownで対象ディレクトリの所有者変更。
# docker-entrypoint.shでWordpressイメージのENTRYPOINT呼び出し。
docker-compose.yml
version: '3.3'

services:
   db:
     image: mysql:5.7
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: somewordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress

   wordpress:
     depends_on:
       - db
     build: . # Dockerfileからビルド。
     volumes:
        # pluginsとuploadsをマウント。
        - ./plugins:/var/www/html/wp-content/plugins
        - ./uploads:/var/www/html/wp-content/uploads
     ports:
       - "80:80" # SiteGuard等でアクセスエラーが出るのでポートは同じ方が望ましい。
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: wordpress
       WORDPRESS_DB_NAME: wordpress
volumes:
    db_data: {}

ダウンロード

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧