- 投稿日:2020-02-19T23:00:35+09:00
docker, dockercomposeの概要とチートシート
docker, docker-composeの概要
docker
dockerのイメージ図は以下の感じ. dockerhubか誰かが作成したDockerfileから, イメージを作成またはインストールし、コンテナを作成する. nginxなどのミドルウェアを, pc, serverの環境と隔離して, 再現が可能
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 <コンテナ名> bashdocker-composeの基本コマンド
おおむね上記のdokcerの部分をdocker-commposeに置き換えるだけ.
コンテナの作成
cd <docker-compose.ymlが置かれたディレクトリ> docker-compose up -d
- 投稿日:2020-02-19T23:00:35+09:00
dockerのinstall(ubuntu)と基本コマンド
dockerのinstall(ubuntu)と基本コマンド
docker
dockerのイメージ図は以下の感じ. dockerhubか誰かが作成したDockerfileから, イメージを作成またはインストールし、コンテナを作成する. nginxなどのミドルウェアを, pc, serverの環境と隔離して, 再現が可能
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-cedocker基本操作
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
- 投稿日: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.ymldocker-compose.ymlcron: build: ./cron_alert volumes: - ./cron_alert:/cron_dir ports: - "3456:3456"DockerfileFROM 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
してるとデスクトップに通知が来るのを確認して満足しました。
変なこと書いてたら指摘してくださるとうれしいです。
- 投稿日: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=jacompute engineのContainer optimizedイメージにnvidea driverを入れる方法。
https://github.com/GoogleCloudPlatform/cos-gpu-installerdockerでtensorflowを使う方法
ホスト側にgpu driverさえ入っていれば動くらしい。
https://www.tensorflow.org/install/docker#gpu_support
- 投稿日: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.ymlmailhog: image: mailhog/mailhog ports: - "8025:8025"2. mhsendmailを入れてください
- https://github.com/mailhog/mhsendmail
- goで出来ています
- yumとかaptでsendmailいちいち入れるの面倒なので、こいつをマウントしてやれば良い
- 例えばこんな感じ
docker-compose.ymlvolumes: - "./bin/mhsendmail:/usr/local/bin/mhsendmail"3. phpの人向け
- webサーバのコンテナのphp.iniに追加(変更)しておくと、phpの標準mail関数でメール送信できますんで既存コードをいじらなくて済む
php.inisendmail_path = "/usr/local/bin/mhsendmail --smtp-addr=mailhog:1025"以上です、快適なdockerライフを!!
- 投稿日: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-setupmacOS
$ brew install minio/stable/mcGNU/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 mcMicrosoft 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
- 投稿日: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/4391EC-CUBE4(Symfony3)のDocker開発環境を構築するにあたり、一部のフォルダのIOが激しく、ホスト-コンテナ間で共有すると使い物にならないレベルで遅いという課題があった。
対策として、I/Oが多く主な速度低下の原因となる以下のフォルダについて、ホスト-コンテナ間で共有しないように設定を行った。
- var
- キャッシュ・ログ等
- vendor
- composer install による生成(DL)物
Dockerのボリュームマウントには
.gitignore
のような一部のフォルダ・ファイルのみ除外する設定がない。
ただし除外したいフォルダのみを別途ボリュームマウント指定することで、ホストとの同期対象外となる。docker-compose.ymlec-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オプション @Hirakudocker-compose.ymlec-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⇒volumecomposer 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 結果所感
- vendorをホストにマウントした状態でcomposer installを打つのは苦行。10分以上待たされる。varだけtmpfsにするパターンはもはや計測する意味がないのでやめた。
- (青)両方Docker Volumeはそこそこ速い。現行のこれでも問題はなさそう
- (オレンジ)両方tmpfsはやっぱり一番速い。が、vendorが永続化出来ないとdocker-composeをコンテナ起動時に毎回走らせなければならないので、起動が遅くなる
- varだけtmpfsにするのがバランス良さそう
課題
- sqliteのファイルがvendor以下に配置されるため、varを揮発性にするとコンテナ再作成で消える。
- docker-compose up 時にキャッシュ作成する仕組みが必要。
- 画面ベースでの改善度合いはを
途中から面倒になって確認していない結論
varをtmpfs, vendorをDockerVolumeでマウントすることで、キャッシュ削除→作成で良くて0.5秒ほど動作改善が見込める(どんぶり勘定。正確なdevモードでのキャッシュ更新動作を把握していないので、的外れかも)
が、実際の開発環境でストレス軽減されるほど変わるかは、実際使ってみてこれから感触を確かめることにする。varはブランチ切り替えた時などはリセットされた方がいいと思うし、tmpfsで揮発性にしてdocker-compose.ymlのcommand指定で毎回コンテナ起動時にキャッシュクリア/生成を実行する方がいい気がしている。
参考
- Measure-Command (Microsoft.PowerShell.Utility)
- tmpfs - Wikipedia
- dockerのtmpfsオプション - Qiita @Hiraku
- 投稿日: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以下の手順で、ネットワークの変更を行います。
- 現状の確認
- 設定ファイルの作成
- dockerd の再起動
- 設定反映の確認
現状の確認
まずは、設定変更前の状態を確認しておきます。
コマンド
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つの方法があります。
- 設定ファイルに記述する。
- 起動時の引数で指定する。
ここでは、設定ファイルで変更する方法を記載しておきます。
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" } ]
- 投稿日: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 プラグインを削除できない。
問題2 プラグインをインストールできない。
対処法
Dockerfileを作成し、ENTRYPOINTでwp-contentとwp-content/plugins、wp-content/uploadsの所有者を変更してやればいい。
DockerfileFROM 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.ymlversion: '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: {}ダウンロード
参考