このチュートリアルでは、Alibaba Cloud上でコンテナを扱う際にDocker Composeを使用して実践的な経験を積むことに焦点を当てています。
本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。
生産性のヒント
私はよく使うDockerコマンド用にいくつかのbash aliasesを定義しています。ここではそのうちの2つを紹介します。
alias nnc='nano docker-compose.yml'
alias psa='docker ps -a'
シェルで psa を入力すると、チュートリアルで docker ps -a をハイライトしてからコピーし、alt-tab でコンソールウィンドウに移動してからペーストするよりも速いです。
docker-compose.yml の編集が速くなりました。
1、Chromeを使用している場合は、オートコピー拡張機能をインストールしてください。ブラウザでハイライトしたテキストを自動的にコピーしてくれます。
2、チュートリアルでdocker-compose.ymlのテキストをハイライト表示します。
3、AltタブでLinuxコンソールへ
4、type nnc ( editorで docker-compose.yml ファイルを開きます )
5、右クリックして貼り付けます（これは使用しているコンソールソフトウェア固有のものです）。
6、保存
拡張子とエイリアスを使用しない場合、このプロセスには上記の6つのステップの代わりに12のステップが必要になります。
シェルで psa を入力するのは、チュートリアルで docker ps -a をハイライトしてからコピーし、alt-tab でコンソールウィンドウに移動してからペーストするよりも速いです。
docker-compose.yml の編集が速くなりました。
1、Chromeを使っている場合は、オートコピー拡張機能をインストールしてください。ブラウザでハイライトしたテキストを自動的にコピーします。
2、チュートリアルでdocker-compose.ymlのテキストをハイライト表示します。
3、AltタブでLinuxコンソールへ
4、type nnc ( エディタが docker-compose.yml ファイルを開く )
5、右クリックして貼り付けます（これは使用しているコンソールソフトウェアに固有のものです）。
6、保存
拡張子とエイリアスを使用しない場合、このプロセスには上記の6つのステップの代わりに12のステップが必要になります。
Deploy: placement constraints
docker-composeの配置制約は、制約を定義することで、タスクをスケジューリング/実行できるノード/サーバを制限するために使用されます。
まず、ノード/サーバのラベルを定義する必要があります。次に、これらのラベルに基づいて配置制約を定義します。
ノードにラベルを追加する構文
docker node update --label-add label-name=label-value hostnam-of-node
このためにはサーバのホスト名が必要です。シェルでホスト名を入力して、あなたのホスト名を取得します。
以下、自分のホスト名を使ってください。( localhost.localdomain = 私のホスト名)
docker node update --label-add tuts-allowed=yes localhost.localdomain
docker node update --label-add has-ssd=yes localhost.localdomain
ノードを検査してラベルが存在することを確認することができます。
head -n 13 は先頭のみを表示します。 / head 13行の長いinspectの出力。
docker node inspect self | head -n 13
期待される出力 .
[
{
"ID": "wpk3r9ypjd8f0p3koh1dikvie",
"Version": {
"Index": 443
},
"CreatedAt": "2018-11-06T09:29:29.644400514Z",
"UpdatedAt": "2018-11-07T09:55:18.065758325Z",
"Spec": {
"Labels": {
"has-ssd": "yes",
"tuts-allowed": "yes"
},
ここで、docker-compose.yml の一番下に配置規則を追加します。
docker-compose.yml に次のように追加します。
nano docker-compose.yml
version: "3.7"
services:
alpine:
image: alpine:3.8
command: sleep 600
deploy:
placement:
constraints:
- node.labels.has-ssd == yes
- node.labels.tuts-allowed == yes
stack deployコマンドは、両方の制約に一致するノードにのみサービススタックを配置します。
両方の制約が私たちのノードと一致しているので、デプロイは成功します。
docker stack deploy -c docker-compose.yml mystack
実行中のコンテナをリストアップしてみましょう。
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
42f8a9b43faf alpine:3.8 "sleep 600" 12 seconds ago Up 11 seconds mystack_alpine.1.ezwejfbrmhbk0k5yd9a53ei85
成功しました。mystackにある全てのサービスをリストアップしてみましょう。
docker stack services mystack
ID NAME MODE REPLICAS IMAGE PORTS
ji5dnn9klinx mystack_alpine replicated 1/1 alpine:3.8
成功しました。REPLICAS欄を参照してください。リクエストされた1つのサービスのうち、1つのサービスが実行されています。
それでは、デプロイができないように制約テストを変更してみましょう。
docker-compose.ymlに以下を追加します。
nano docker-compose.yml
version: "3.7"
services:
alpine:
image: alpine:3.8
command: sleep 600
deploy:
placement:
constraints:
- node.labels.has-ssd == yeszzz
- node.labels.tuts-allowed == yeszzz
以前に展開したスタックを削除します。
docker stack rm mystack
docker stack deploy -c docker-compose.yml mystack
mystackのサービスを一覧にしてみましょう。
docker stack services mystack
ID NAME MODE REPLICAS IMAGE PORTS
jdg2bgxx5nfa mystack_alpine replicated 0/1 alpine:3.8
デプロイは適切なノードを見つけることに成功しませんでした。REPLICAS カラムを参照してください。要求された 1 つのサービスのうち 0 つのサービスが実行されています。
ノードラベルの使用方法の例。
1、ssds を必要とする特定のアプリがそのようなノードでのみ実行できるように ssds でノードをラベル付けします。
2、アプリケーションがそのようなノードを見つけることができるように、グラフィックカードでノードをラベル付けします。
3、必要に応じて国名、州名、都市名をノードにラベル付けします。
4、バッチとリアルタイムのアプリケーションを分離します。
5、開発ジョブは開発用マシンでのみ実行してください。
6、開発中のアプリケーションを物理的なコンピュータ上でのみ実行してください - CPUやRAMを浪費するコードが同僚に悪影響を与えないようにしてください。
Placementeについての詳しい情報はこちらをご覧ください: https://docs.docker.com/compose/compose-file/#placement
制約についてはこちらをご覧ください: https://docs.docker.com/engine/reference/commandline/service_create/#specify-service-constraints-constraint
Deploy: replicas
任意の時間に実行するコンテナの数を指定します。
これまではデフォルトのreplicasを1つだけ使用していました。
ここでは3つのreplicasを実行するデモをしてみましょう。
docker-compose.ymlに以下のように追加します。
nano docker-compose.yml
version: "3.7"
services:
alpine:
image: alpine:3.8
command: sleep 600
deploy:
replicas: 3
以前に実行していたmystackの削除
docker stack rm mystack
期待される出力 .
Removing service mystack_alpine
Removing network mystack_default
新しいスタックを展開します。
docker stack deploy -c docker-compose.yml mystack
期待される出力 .
Creating network mystack_default
Creating service mystack_alpine
出力は期待できそうにありません - 3つのreplicasについては言及されていません。mystackのサービスをリストアップしてみましょう
docker stack services mystack
期待される出力 .
ID NAME MODE REPLICAS IMAGE PORTS
pv2ebn95au9j mystack_alpine replicated 3/3 alpine:3.8
要求された3つのレプリカが不足しています。成功しました。
実行中のコンテナをリストアップしてみましょう。
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
80de65e6e0d3 alpine:3.8 "sleep 600" 9 seconds ago Up 6 seconds mystack_alpine.2.51hlsv3s7ky5zr02fprjaxi59
440548cfcc7d alpine:3.8 "sleep 600" 9 seconds ago Up 6 seconds mystack_alpine.1.za68nt6704xobu2cxbz7x7p3l
19564317375f alpine:3.8 "sleep 600" 9 seconds ago Up 7 seconds mystack_alpine.3.1ut387z38e2hrlmahalp7hfsa
予想通りです。3つのコンテナが稼働しています。
サーバの作業負荷を調査してみました。
top - 09:45:33 up 2:02, 2 users, load average: 0.00, 0.01, 0.05
Tasks: 133 total, 1 running, 132 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.3 us, 0.2 sy, 0.0 ni, 99.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 985.219 total, 472.004 free, 171.848 used, 341.367 buff/cache
MiB Swap: 1499.996 total, 1499.996 free, 0.000 used. 639.379 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
939 root 20 0 950.7m 105.9m 29.2m S 0.7 10.8 1:19.36 dockerd
946 root 20 0 424.8m 29.1m 12.1m S 2.9 0:14.14 docker-containe
5082 root 20 0 7.2m 2.7m 2.0m S 0.3 docker-containe
4950 root 20 0 7.2m 2.6m 2.0m S 0.3 docker-containe
5075 root 20 0 7.2m 2.4m 1.9m S 0.2 docker-containe
3つの小さなコンテナはそれぞれ約2.5MBのRAMを使用しています。
これで、隔離された環境で動作する3つのフルAlpine Linuxディストロが、それぞれ2.5MBのRAMサイズで動作するようになりました。これは素晴らしいことです。
これを3つの独立した仮想マシンと比較してみてください。それぞれの仮想マシンは、存在するだけで50MBのオーバーヘッドを必要とします。さらに、それぞれに数百 MB のディスクスペースが必要になります。
各コンテナは約300msで起動しますが、これはVMでは不可能です。
Deploy: resources: reservations cpu ( オーバープロビジョニング )
reservations: cpu config settingsを使ってCPU容量を確保しています。
cpuをオーバープロビジョニングして、Dockerが指示に従うかどうかを確認してみましょう。
docker-compose.ymlに以下を追加します。
nano docker-compose.yml
version: "3.7"
services:
alpine:
image: alpine:3.8
command: sleep 600
deploy:
replicas: 6
resources:
reservations:
cpus: '0.5'
私のサーバには 2 つのコアがあるので、2 つの CPU が利用可能です。
この設定では、6 * .5 = 3CPUをプロビジョニングしようとしています。
この設定を編集して、あなたの小さなノートパソコンや、あなたの雇い主であるスーパーサーバーで失敗するようにしなければなりません。
既存のスタックを削除してみましょう。
docker stack rm mystack
展開してみましょう。
docker stack deploy -c docker-compose.yml mystack
期待されない出力 .
Creating service mystack_alpine
failed to create service mystack_alpine: Error response from daemon: network mystack_default not found
時々上記のようなことが起こりますが、エラーが出なくなるまでデプロイを再実行してください。
デプロイの結果を調査してください。
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a8861c79e3e8 alpine:3.8 "sleep 600" 40 seconds ago Up 37 seconds mystack_alpine.6.pgtvnbpxpy4ony26pmp8ekdv1
3d2a0b8e52e9 alpine:3.8 "sleep 600" 40 seconds ago Up 37 seconds mystack_alpine.5.j52dwbe7qqx0nn5nhanp742n4
5c2674b7fa36 alpine:3.8 "sleep 600" 40 seconds ago Up 37 seconds mystack_alpine.1.bb1ocs3zkz730rp9bpf6s9jux
f984a8d52393 alpine:3.8 "sleep 600" 40 seconds ago Up 38 seconds mystack_alpine.4.mr5ktkei9pn1dzhkggq2e48o9
4つのコンテナがリストアップされています。4 * .5 = 2CPUを使用していることになります。
mystackにある全てのサービスをリストアップする。
docker stack services mystack
ID NAME MODE REPLICAS IMAGE PORTS
7030g8ila28h mystack_alpine replicated 4/6 alpine:3.8
6つのコンテナのうち4つだけがプロビジョニングされました。Dockerはプロビジョニングするcpusを使い果たしました。
重要: これは存在するものだけをreservationすることができます。
Deploy: resources: reservations: RAM( オーバープロビジョニング )
RAMをオーバープロビジョニングしてみましょう。(この機能はこのチュートリアルの後半で正しく使用します。)
docker-compose.yml に以下を追加します。
nano docker-compose.yml
version: "3.7"
services:
alpine:
image: alpine:3.8
command: sleep 600
deploy:
replicas: 6
resources:
memory: 2000M
私のサーバーには1GBのラムがあります。
この設定では、私は6 * 2 = 12 MBをプロビジョニングしようとしています。
前と同じように: この設定を編集して、あなたの小さなノートパソコンやモンスターの雇用主のスーパーサーバーで失敗するようにする必要があります。
既存のスタックを削除してみましょう。
docker stack rm mystack
展開してみましょう。
docker stack deploy -c docker-compose.yml mystack
実行中のstack servicesを一覧表示します。
docker stack services mystack
期待される出力 .
ID NAME MODE REPLICAS IMAGE PORTS
l7yr2m5k6edf mystack_alpine replicated 0/6 alpine:3.8
デプロイされたサービスはゼロ。Dockerは、指定された予約RAMの50%を使用して1つのコンテナをデプロイすることさえしません。これは正しく想定しています - RAMの予約を指定した場合、コンテナが正常に動作するためにはその最小値を必要とします。したがって、予約が不可能な場合、コンテナは起動しません。
ここまでで、リソースの制限が守られることを見てきました。
どのように動作するかを確認するために、妥当な制限を定義してみましょう。
Deploy: resources: limits: cpu
以下のアルパインサービスは、20M以下のメモリと0.50(50%)以下の利用可能な処理時間(CPU)に制約されています。
docker-compose.ymlに以下を追加します。
nano docker-compose.yml
version: "3.7"
services:
alpine:
image: alpine:3.8
command: sleep 600
deploy:
replicas: 1
resources:
limits:
cpus: '0.5'
memory: 20M
ここから先はreplicasが1つしか必要ないことに注意してください。
docker stack rm mystack
スタックを展開します。
docker stack deploy -c docker-compose.yml mystack
docker ps -a
期待される出力 .
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
11b8e8c2838b alpine:3.8 "sleep 600" 3 seconds ago Up 1 second mystack_alpine.1.qsamffjd1vg0137off9xinyzg
コンテナが動いています。これを入力して、CPU速度をベンチマークしてみましょう。
docker exec -it mystack_alpine.1.qsamffjd1vg0137off9xinyzg /bin/sh
コンテナ / # プロンプトに表示されているコマンドを入力します。
/ # time dd if=/dev/urandom bs=1M count=2 | md5sum
2+0 records in
2+0 records out
real 0m 0.57s
user 0m 0.00s
sys 0m 0.28s
064be3476682daf856bb32fa00d29e2e -
/ # exit
ベンチマークの説明:
1、time: 経過時間を測定します。
2、dd if=/dev/urandom bs=1M count=2: 1 MB のランダム性を bs (ブロックサイズ) を 2 回コピーする。
3、md5sum: md5ハッシュを計算する (CPUに負荷を与える)
CPU 制限値 0.5 のベンチタイムがありますが、これを比較できなければ何の意味もありません。
そこで、docker-compose.yml で cpu limit を 0.25 に変更してみましょう。
cpus: '0.25'
その後、シェルで実行します。
docker stack rm mystack
docker stack deploy -c docker-compose.yml mystack
docker ps -a # to get our container name
docker exec -it mystack_alpine.1.cbaakbi027ue0c1rtj0z463qz /bin/sh
ベンマークを再実行します。
/ # time dd if=/dev/urandom bs=1M count=2 | md5sum
2+0 records in
2+0 records out
real 0m 1.27s
user 0m 0.00s6d9b25e860ebef038daa165ae491c965 -
sys 0m 0.30s
/ # time dd if=/dev/urandom bs=1M count=2 | md5sum
2+0 records in
2+0 records out
real 0m 1.33s
ed29ebf0ef70923f9b980c65495767eb -
user 0m 0.00s
sys 0m 0.33s
/ # exit
結果は理にかなっています。 - 約50%の速度低下 - 利用可能なCPUパワーが50%減少しています。
そこで、docker-compose.ymlでCPU制限を1.00に変更してみましょう。
cpus: '1.00'
シェルで実行します。
docker stack rm mystack
docker stack deploy -c docker-compose.yml mystack
docker ps -a
docker exec -it your-container-name /bin/sh
表示されているコマンドを入力します。
/ # time dd if=/dev/urandom bs=1M count=2 | md5sum
2+0 records in
2+0 records out
real 0m 0.25s
user 0m 0.00s
sys 0m 0.24s
facbf070f7328db3321ddffca3c4239e -
/ # time dd if=/dev/urandom bs=1M count=2 | md5sum
2+0 records in
2+0 records out
616ba74d54b8a176f559f41b224bc3a3 -real 0m 0.29s
user 0m 0.00s
sys 0m 0.28s
/ # exit
非常に高速なランタイム：100%のCPU制限は25%のCPUパワーよりも4倍速い
これで、コンテナごとのCPUパワーを制限することが期待通りに動作することを体験していただけたと思います。
本番用のサーバーが 1 台しかない場合、この知識を使って、CPU を消費するバッチプロセスを他の作業と同じサーバーで実行することができます - バッチプロセスの CPU を厳しく制限するだけです。
Resources: limits: memory
この設定オプションは、コンテナの最大 RAM 使用量を制限します。
docker-compose.yml に次のように追加します。
nano docker-compose.yml
Version: "3.7"
services:
alpine:
image: alpine:3.8
command: sleep 600
deploy:
replicas: 1
resources:
limits:
cpus: '1.00'
memory: 4M
実行します。
docker stack rm mystack
docker stack deploy -c docker-compose.yml mystack
docker ps -a
期待される出力 .
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
2e0105ce94fd alpine:3.8 "sleep 600" 3 seconds ago Up 1 second mystack_alpine.1.ykn9fdmeaudp4ezar7ev19111
これで、メモリ制限が4MBのコンテナが稼働していることになります。
典型的な好奇心旺盛なDocker管理者になって、8MBの/dev/shm RAMを使用した場合にどうなるか見てみましょう。
docker exec -it mystack_alpine.1.ykn9fdmeaudp4ezar7ev19111 /bin/sh
表示されているようにコマンドを入力します。
/ # df -h
Filesystem Size Used Available Use% Mounted on
/dev/mapper/docker-253:1-388628-c88293aae6b79e197118527c00d64fee14aec2acfb49e5f1ec95bc6af6bd874b
10.0G 37.3M 10.0G 0% /
tmpfs 64.0M 0 64.0M 0% /dev
tmpfs 492.6M 0 492.6M 0% /sys/fs/cgroup
/dev/mapper/centos00-root
12.6G 5.5G 7.2G 43% /etc/resolv.conf
/dev/mapper/centos00-root
12.6G 5.5G 7.2G 43% /etc/hostname
/dev/mapper/centos00-root
12.6G 5.5G 7.2G 43% /etc/hosts
shm 64.0M 0 64.0M 0% /dev/shm
tmpfs 492.6M 0 492.6M 0% /proc/acpi
tmpfs 64.0M 0 64.0M 0% /proc/kcore
tmpfs 64.0M 0 64.0M 0% /proc/keys
tmpfs 64.0M 0 64.0M 0% /proc/timer_list
tmpfs 64.0M 0 64.0M 0% /proc/timer_stats
tmpfs 64.0M 0 64.0M 0% /proc/sched_debug
tmpfs 492.6M 0 492.6M 0% /proc/scsi
tmpfs 492.6M 0 492.6M 0% /sys/firmware
/ # dd if=/dev/zero of=/dev/shm/fill bs=1M count=4
4+0 records in
4+0 records out
/ # df -h
Filesystem Size Used Available Use% Mounted on
/dev/mapper/docker-253:1-388628-c88293aae6b79e197118527c00d64fee14aec2acfb49e5f1ec95bc6af6bd874b
10.0G 37.3M 10.0G 0% /
tmpfs 64.0M 0 64.0M 0% /dev
tmpfs 492.6M 0 492.6M 0% /sys/fs/cgroup
/dev/mapper/centos00-root
12.6G 5.5G 7.2G 43% /etc/resolv.conf
/dev/mapper/centos00-root
12.6G 5.5G 7.2G 43% /etc/hostname
/dev/mapper/centos00-root
12.6G 5.5G 7.2G 43% /etc/hosts
shm 64.0M 4.0M 60.0M 6% /dev/shm
tmpfs 492.6M 0 492.6M 0% /proc/acpi
tmpfs 64.0M 0 64.0M 0% /proc/kcore
tmpfs 64.0M 0 64.0M 0% /proc/keys
tmpfs 64.0M 0 64.0M 0% /proc/timer_list
tmpfs 64.0M 0 64.0M 0% /proc/timer_stats
tmpfs 64.0M 0 64.0M 0% /proc/sched_debug
tmpfs 492.6M 0 492.6M 0% /proc/scsi
tmpfs 492.6M 0 492.6M 0% /sys/firmware
/ # dd if=/dev/zero of=/dev/shm/fill bs=1M count=8
Killed
/ # df -h
Filesystem Size Used Available Use% Mounted on
/dev/mapper/docker-253:1-388628-c88293aae6b79e197118527c00d64fee14aec2acfb49e5f1ec95bc6af6bd874b
10.0G 37.3M 10.0G 0% /
tmpfs 64.0M 0 64.0M 0% /dev
tmpfs 492.6M 0 492.6M 0% /sys/fs/cgroup
/dev/mapper/centos00-root
12.6G 5.5G 7.2G 43% /etc/resolv.conf
/dev/mapper/centos00-root
12.6G 5.5G 7.2G 43% /etc/hostname
/dev/mapper/centos00-root
12.6G 5.5G 7.2G 43% /etc/hosts
shm 64.0M 5.4M 58.6M 9% /dev/shm
tmpfs 492.6M 0 492.6M 0% /proc/acpi
tmpfs 64.0M 0 64.0M 0% /proc/kcore
tmpfs 64.0M 0 64.0M 0% /proc/keys
tmpfs 64.0M 0 64.0M 0% /proc/timer_list
tmpfs 64.0M 0 64.0M 0% /proc/timer_stats
tmpfs 64.0M 0 64.0M 0% /proc/sched_debug
tmpfs 492.6M 0 492.6M 0% /proc/scsi
tmpfs 492.6M 0 492.6M 0% /sys/firmware
/ # exit
上で起こったことの説明。
最初に df -h を実行して /dev/shm のサイズと使用量を調べます。
shm 64.0M 0 64.0M 0% /dev/shm
そして、/dev/shmに4MBを追加します。
dd if=/dev/zero of=/dev/shm/fill bs=1M count=4
使用方法を再確認してください - 4Mを参照してください。
shm 64.0M 4.0M 60.0M 6% /dev/shm
そして、/dev/shm に 8MB を追加して、以前の内容を上書きします。
dd if=/dev/zero of=/dev/shm/fill bs=1M count=8
Killed
で、このコマンドは強制終了されます。
dev/shm の使用状況を再度確認してください。
shm 64.0M 5.4M 58.6M 9% /dev/shm
コンテナがRAMを使い果たす前に4MBを少し使いました。
結論:Dockerのdocker-composeのメモリ制限が適用されます。
デフォルトではコンテナはRAMの使用量が制限されていません。そのため、このリソース制限を利用して、暴走したコンテナによってRAMが完全に消費されるのを防ぎましょう。
20MB、50MB、100MBのいずれも240GBを消費させるよりは良いでしょう。
アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ