Docker on Wayne's blog | 偉恩的部落格 | 技術博客

【Docker】數據持久化與數據共享 - tmpfsMount/BindMount/Volume

Thu, 02 Feb 2023 00:00:00 +0000

前言

在預設的 Docker daemon 下，我們常會遇到幾種情況：

當該容器不再存在時，數據將不會持久保存，並且如果另一個 Process 需要它，則可能很難從容器中取出數據。
容器的可寫層與運行容器的主機緊密耦合。您不能輕易地將數據移動到其他地方。
寫入容器的可寫層需要存儲驅動程序來管理文件系統。存儲驅動程序使用 Linux 內核提供聯合文件系統。與使用直接寫入主機文件系統的數據卷相比，這種額外的抽象降低了性能。

Container 是在 Image 之上去創建的，Container 可以讀寫數據，而 Image 只能夠讀取，但是 Container 裡面所寫入的數據，只會存在 Container 裡面，如果刪除 Container，寫入的數據會全部消失。有一種需求，資料庫的 Container 會有數據的讀寫，在這種情況下，Docker 就需要數據持久化。

為了解決這些問題就誕生了 Docker Volume。

Container 裡面會有一個 Program，把檔案寫入 File System，這些檔案會存在 Container 的 Layer 中，我們把數據的部分，額外 Mount 一個 Volume，這樣一來，數據就會被永久保存；每個 Container 都是獨立且封閉的，但有時候我們會想要不透過進入 Container 就能改變內部的程式碼，或者是想要進行 Database 升級並保留原本資料，這時就需要Docker Volume 了。

Docker 持久化數據的方案：

基於本地文件系統的 Volume：可以在執行 docker create 或是 docker run 的時，通過 -v 參數將主機目錄作為 Container 的 Volume，這部分功能便是基於本地系統的 Volume 管理。
基於外掛的 Volume：支持第三方的儲存方案，例如：AWS。

談到 Docker 容器的資料儲存(storage)問題，基本直覺就是透過掛載 Volumes，不過 Docker 的 Volumes 其實有 3 種不同類型(types)：

tmpfsMount：主機的 memory。
BindMount：可以為主機路徑下任何地方。
Volume：Container 將 Volume 存放在 Docker area，以 Linux 來說預設為 /var/lib/docker/volume。

大家常用的 -v <Host 路徑>:<Container 路徑> 參數其實就是使用 BindMount，例如以下指令：

1

docker run -it -v /home/user:/data debian /bin/bash

簡而言之，使用 BindMount 的 volume 其實就是透過 host machine 的檔案系統(filesystem)提供容器儲存的能力。

tmpfsMount

不同於 Volume、BindMound，tmpfsMount 不需要實體路徑將資料儲存，他是暫時性地儲存在主機的記憶體當中，當 Container 停止時，就會移除資料，通常用來儲存暫存性資料以及敏感資料。

如何使用 tmpfsMount？

1

docker run --name <ContainerName> -d --mount type=tmpfs,destination=<內部路徑> -p 8100:8100 <ImageName>

舉個例子：

1

docker run --name <ContainerName> -d --tmpfs <內部路徑> -p 8100:8100 <ImageName>

BindMount

BindMount 就是做映射 docker run -v /home/aaa:/root/aaa，可以將本地目錄和 Container 目錄做映射，如果本地目錄修改，Container 的數據內容也會修改，反之亦然。

如何使用 BindMount？

舊版本 Window 版的坑

window 版不能直接掛載，要先調一下設定。

選擇要掛載的目錄
打開 Docker Desktop
General > share dirve 掛載相應路徑，該路徑底下的資料夾才能被掛載

新版本 window desktop 可以直接掛載，指令：

1

docker run -v <外部絕對路徑>:<內部路徑> <ImageName>

舉例來說，我在 windows 電腦 //e/program/Wayne/DockerExample 底下放了 index.html，要映射給 /usr/local/apache2/htdocs：

1

docker run -it -d --name Web_Vol -p 8081:80 -v //e/program/Wayne/DockerExample:/usr/local/apache2/htdocs httpd:2.4

現在在外部修改就能直接影響到 Container 內部了。

當使用 -v 在掛載路徑時，若該路徑不存在於本機，則會建立該路徑，如果將綁定到容器上的目錄不為空，那目錄現有的內容會被綁定的目錄給遮蓋。

Volume

Volume 的優點

前文簡單介紹 BindMount 後，接著來認識 Docker 官方更為推薦的 Volume 吧。

Volume 與 BindMount 最大的不同在於 Volume 是由 Docker 全權進行管理，因此 Volume 比起 BindMount 有幾個優點：

Volumes 更好轉移(migration)與備份(backup)。
Volumes 能夠透過 Docker API 與 Docker CLI 進行管理與操作。
Volumes 可跨平台(Linux, Windows)。
Volumes 在 macOS 與 Windows 上效能表現較好。
Volumes 更加適合多個容器(Container)共享使用的情境。
Volumes 提供整合遠端或雲端儲存服務的能力（詳見 Docker plugin），只要使用不同的 Volume driver 即可，例如可以安裝 vieux/sshfs plugin 掛載遠端 SSH 伺服器的檔案系統。

基本上，如果你不知道用 Volume 比較好還是 BindMount 比較好，使用 Volume 就對了！

MySQL Docker file 裡面有一行，VOLUME /var/lib/mysql 就是將數據存到虛擬主機的目錄，實現數據持久化，讓數據不會因為 Container 消失而消失。

如何使用 Volumes？

-v or --mount

創建一個 Volume

1

docker volume create <VolumeName>

可以用 -d 來指定位置

1

docker volume create <VolumeName> -d <外部絕對路徑>

要是不 -d 指定特定空間，系統會自動幫你生成空間，然而具體會在電腦的哪裡呢？

Windows 版會在 \\wsl$\docker-desktop-data\version-pack-data\community\docker\volumes

Linux 版會在 /var/lib/docker/volumes/

啟動 Container 並掛載 Volume 到指定路徑

1

docker run --name <ContainerName> -d -v <外部絕對路徑>:<內部路徑> -p 8100:8100 <ImageName>

舉個例子：

1

docker run -it -v myvolume:/data nginx /bin/bash

進到容器內就可以發現路徑 /data 可以使用：

1
2
3
4
5
6


root@1630d3b4ffb8:~# touch /data/hello.txt
root@1630d3b4ffb8:~# ls -alh /data
total 8.0K
drwxr-xr-x 2 root root 4.0K Mar 18 15:53 .
drwxr-xr-x 1 root root 4.0K Mar 18 15:51 ..
-rw-r--r-- 1 root root 0 Mar 18 15:53 hello.txt

如果有在 Volume 內新增任何資料的話，也可以在 Docker Desktop 內看到：

前文提及 Volume 可以共享，因此可以打開一個新的容器並且掛載同一個 Volume 試試：

1
2
3


$ docker run -it -v myvolume:/data debian /bin/bash
root@12fa2630f490:/# ls /data
hello.txt

上述結果可以看到新啟動的容器內不僅有 /data 資料夾，該資料夾底下也有先前在其他容器建立的檔案。

若想列出所有 Volumes

1

docker volume ls

若想查看 Volume 詳細資訊

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


docker volume inspect <VolumeName>

[
 {
 "CreatedAt": "2022-03-13T06:48:16Z",
 "Driver": "local",
 "Labels": {},
 "Mountpoint": "/var/lib/docker/volumes/myvolume/_data",
 "Name": "myvolume",
 "Options": {},
 "Scope": "local"
 }
]

上述指令結果可以看到 Mountpoint，該資訊就是 Volume 實際儲存資料的路徑位置。

但如果是 macOS 的使用者就會發現找不到 /var/lib/docker/ (no such file or directory: /var/lib/docker)：

1
2
3


$ cd /var/lib/docker/volumes/

cd: no such file or directory: /var/lib/docker/volumes/

這是由於 macOS 的 Docker 是用 LinuxKit 模擬的，因此路徑又被包裝過一層，其大致在以下的路徑：

1

$ cd ~/Library/Containers/com.docker.docker/Data/vms/0/

可於上述資料夾內發現 1 個名稱為 tty 的檔案，用指令 screen tty 就能夠進入 LinuxKit 內，然後就能發現 /var/lib/docker/volumes 資料夾，然後就能順利找到相對應的 Volume 囉！

不過 Docker Desktop for Mac version 2.3.0.4 以後就沒有 tty 檔案了，但還是可以使用以下指令進入 Docker 的 host machine 並且找到 /var/lib/docker/volumes：

1

docker run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh

1

ls /var/lib/docker/volumes/

若想移除 Volume

1

docker volume rm <VolumeName>

Volume 的 2 種參數

掛載 Volume 時，除了 -v 參數可以使用之外，還有 --mount 參數可以使用，基本上 2 者功能是相同的，但差別在於參數格式不一樣之外， --mount 可設定的選項也相較多一點。

-v 參數

-v 的參數值是以 : 做為分隔的 3 個欄位值，分別是 <Volume名稱>:<容器內的掛載路徑>:<Volume選項>。

<Volume名稱>：可以是 Docker 的 Volume 名稱，該名稱可以用指令 docker volume ls 列出，其值對應的是 VOLUME NAME 一欄。如果這邊用的是實際系統路徑的話，Docker 就會自動轉為使用 bind mount，而非 Volume。
<容器內的掛載路徑>：容器(Container)內的路徑。
<Volume選項> 例如 ro 代表唯讀(read only)。

例如掛載唯讀(read only)的 Volume：

1

docker run -it -v myvolume:/data:ro debian /bin/bash

–mount 參數

--mount 參數則可以視為 -v 參數的進階版。

--mount 更加口語(verbose)化，在 Volumes 的設定上都會明確以 <key>=<value> 的形式進行設定（當 <key> 為 readonly 時，可以直接省略 =<value> 的部分），多個 key 值之間則以逗號(,)進行分割，而且設定的順序上並不像 -v 參數那般有順序上的要求。

目前可使用的 <key> 值有：

source
destination
type
readonly
volume-driver
volume-opt

source

source 是欲掛載 Volume 的名稱，該名稱可以用指令 docker volume ls 列出，其值對應的是 VOLUME NAME 一欄。

destination

destination 是容器(Container)內掛載 Volume 內的路徑。

type

其值可以是 bind、volume、tmpfs 其中 1 個，一般使用 volume 即可，是 Docker 推薦的方式；如果使用 bind 則代表使用 bind mounts；最後 1 種 tmpfs 則代表 tmpfs mount，通常 tmpfs 用以儲存非持久性(non-persistent)的資料，例如暫存檔案、快取(cache)等等，也可用以提升容器的效能，也由於 tmpfs 是非持久性(non-persistent)的儲存，所以當容器(container)關閉後，該 volume 內的資料也會跟著消失。

If your container generates non-persistent state data, consider using a tmpfs mount to avoid storing the data anywhere permanently, and to increase the container’s performance by avoiding writing into the container’s writable layer.

建立一個 tmpfs 的 Volume 指令如下：

1

docker volume create -o type=tmpfs -o device=tmpfs <VolumeName>

例如以下指令建立 1 個名為 mytmpfs 的 tmpfs volume：

1

docker volume create -o type=tmpfs -o device=tmpfs mytmpfs

除了新增 Volume 後掛載 tmpfs volume 之外，當然也可以直接以 --mount 參數方式掛載 tmpfs volume：

1

docker run -it --mount type=tmpfs,destination=/data debian /bin/bash

上述指令其實等同於， Docker 也有提供 --tmpfs 參數可以使用：

1

docker run -it --tmpfs /data debian /bin/bash

readonly

將 Volume 設定為唯讀(read only)。等同於 -v 參數中的 ro 選項。

以 --mount 參數掛載唯讀 Volume 的範例：

1

docker run -it --mount source=myvolume,destination=/data,readonly debian /bin/bash

volume-driver

Docker 將儲存(storage)的概念抽象化為 driver (或稱驅動器)，透過使用不同的 driver 可以介接各式各樣的檔案系統，例如 NFS(Network File System)、SSHFS(SSH Filesystem) 甚至是 AWS S3 等等，預設是使用 local driver，也就是 volume-driver=local。

如果想使用其他 driver 可以查看以下文件：

這些文件列出第三方提供的各種 Volume plugin 的安裝與使用方式之外，也紀錄如何使用 Docker 官方提供的指令(docker plugin install <pluginName>)安裝 Volume plugin 以及 Volume plugin 的開發方法。

volume-opt

volume-opt 用以設定 Volume 相關的選項，volume-opt 的數量並沒有限制，端看 volume driver 提供哪些選項可以使用，詳細能夠使用的選項可以參考 FILESYSTEM-SPECIFIC MOUNT OPTIONS 章節。

值得注意的是 tmpfs 並不支援 volume-opt 的用法，如果 2 者合用就會出現以下錯誤：

1

cannot mix 'volume-*' options with mount type 'tmpfs'

練習：用 Docker 跑 MySQL

目標

希望 Database 在 Container 刪除後，還能留下來被新建立的 Container 重新使用，不會一起消失不見。

方法一 (網路查找的標準步驟)

建立存放 MySQL /var/lib/mysql 資料庫檔案的 Persistent Volume，命名為 mysql-data。

1

docker create -v /var/lib/mysql --name mysql-data mysql:5.7.18

以剛建立出來的 Volume mysql-data 作為 storage 把 MySQL runner 跑起來。

指定 MySQL 版本為 5.7.18。
設定 MYSQL_RANDOM_ROOT_PASSWORD=yes 環境變數，讓 MySQL Docker 自動產生 MySQL root 帳號的亂數密碼。
命名為 mysql-runner。

指令如下：

1
2
3


docker run -p 3306:3306 -v /var/lib/mysql --volumes-from mysql-data --name mysql-runner -d -e MYSQL_RANDOM_ROOT_PASSWORD=yes mysql:5.7.18

> d746048e41b7

以 Container ID 查詢 log 找到 MySQL 自動建立的亂數密碼。

1
2
3
4
5
6


docker logs d746048e41b7

> Initializing database
> ...
> GENERATED ROOT PASSWORD: Aethov1phae2Ju5B
> ...

再起一個臨時 Container 開 shell 跑 mysql-client，配合亂數密碼連進 mysql-runner 的 MySQL server，用完即丟。

1

docker run -it --link mysql-runner:mysql --rm mysql sh -c 'exec mysql -h "$MYSQL_PORT_3306_TCP_ADDR" -P "$MYSQL_PORT_3306_TCP_PORT" -u root -p "Aethov1phae2Ju5B"'

也可以用 docker inspect 找到 mysql-runner Container 的 IP，從 host 連進去。

1

mysql -h 172.17.0.20 -u root -P 3306 -p Aethov1phae2Ju5B

方法二 (自行實驗的步驟過程)

第 1 ~ 9 步驟皆於自行測試階段，可直接跳到第 10 步驟。

創建一個 MySQL 的 Container，並使用沒有密碼的環境變數。

1

docker run -d --name mysql1 -e MYSQL_ALLOW_EMPTY_PASSWORD mysql

這時候用 docker ps 查看 Container 會發現 mysql1 沒有啟動成功，使用 docker logs mysql1 查看，就會顯示要指定 MYSQL_ROOT_PASSWORD。

1
2
3
4
5
6
7


docker logs mysql1

> 2020-03-01 02:36:05+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.19-1debian9 started.
> 2020-03-01 02:36:05+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
> 2020-03-01 02:36:05+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.19-1debian9 started.
> 2020-03-01 02:36:06+00:00 [ERROR] [Entrypoint]: Database is uninitialized and password option is not specified
> You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD

在創建 MySQL Container 的同時，也會新增一個 Volume，要將該 Volume 移除。

1
2
3


docker rm mysql1
docker volume ls
docker volume rm [Volume id]

再次創建一個 MySQL 的 Container。

1

docker run -d --name mysql1 -e MYSQL_ALLOW_EMPTY_PASSWORD=true mysql

這時候我們可以去查看新增的 Volume 的細節，裡面就會看到這個 Volume 連結到本地的 /var/lib/docker/volumes/[Volume id]/_data 這個位置。

1
2


docker volume ls
docker volume inspect [Volume id]

我們在創建第二個 MySQL 的 Container。

1

docker run -d --name mysql2 -e MYSQL_ALLOW_EMPTY_PASSWORD=true mysql

這時候再 docker volume ls，就會發現新增了一個新增的 Volume。
把 Container 停止並刪除，再查看 Container 狀態就會發現沒有任何退出或在執行的 Container 了。

1
2
3


docker stop mysql1 mysql2
docker rm mysql1 mysql2
docker ps -a

使用 docker volume ls 查看 Volume，之前新增的都還在，但是會發現命名太複雜，我們可以自定義 Volume 名稱，先把所有的 Volume 移除。

1

docker volume rm [volume1 id] [volume2 id]

創建一個 MySQL 的 Container 並指定 Volume 名稱為 mysql，路徑為 /var/lib/mysql。

1

docker run -d -v mysql:/var/lib/mysql --name mysql1 -e MYSQL_ALLOW_EMPTY_PASSWORD=true mysql

使用 docker volume ls 查看 Volume，就會看到新增的 mysql Volume。
為了驗證 MySQL 的數據持久，我們進去 mysql1 的 Container 新增一個新的 database：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 進入 mysql1 container
docker exec -it mysql1 /bin/bash

# 登入 MySQL
mysql -u root

# 列出 DB
show databases;

# 建立 DB
create database docker;

exit;
exit

停止並刪除 Container：

1

docker rm -f mysql1

創建一個新的 MySQL 的 Container，並連結到之前的 Volume：

1

docker run -d -v mysql:/var/lib/mysql --name mysql2 -e MYSQL_ALLOW_EMPTY_PASSWORD=true mysql

進去 mysql2 的 Container 查看 databases，會發現之前新增的 Database 還存在：

1
2
3
4
5
6
7
8


# 進入 mysql2 container
docker exec -it mysql2 /bin/bash

# 登入 MySQL
mysql -u root

# 列出 DB
show databases;

Docker Network

Docker Network 原理

每個 Container 會包含一項服務，如前端、後端、資料庫，Container 之間能不能互相溝通藉此串聯起一個更大的服務應用呢？可以的，以下講解 Docker Network 的簡單原理。

docker network ls：查看所有網路。
docker network inspect <NetworkName>：檢視細部網路設定。

查看所有網路可以發現默認有分成 host 與 bridge ，Bridge 是 Linux 的虛擬網路橋接技術，將 Bridge 打開可以發現裡面包含兩個 Container，也就是我上一個章節建立的 Web_App 與 Web_Vol，IP 位置分別是 172.17.0.2、172.17.0.3，詳細網路架構圖如下：

安裝 Docker 後會新增一個 Docker 網卡默認 IP 為 172.17.0.1/16 (host)，他會接收來自本網卡(eth0)的轉發封包。新建立的 Container 則是會自動生成 IP 172.17.X.X 依序排列下去。

Container 互相訪問

那 Container 的互相訪問很簡單，直接訪問 172.17.X.X 的 IP 就好了，我們來實驗看看：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 進入container
docker exec -it Web_APP bash

# 查看docker 網路
cat /etc/hosts

# 安裝相關網路工具
apt-get update
apt-get install curl

# 測試去抓其他Container
curl 172.17.0.3

如下圖，本 Docker IP 為 172.17.0.2，可以成功抓到其他 Container 的資料。

Network 映射

但是 Container 的 IP 為自動生成，我們的程式在部屬的時候不可能部屬上去後才改 IP。有一個好方法，做網路映射 --link。

1

docker run --link <外部Container>:<內部Network名稱> <ImageName>

1
2
3
4
5
6
7
8


# 建立新的有連結的 APP 叫做 Web_Network
docker run -it -d --name Web_Network -p 8082:80 --link Web_APP:Web_APP --link Web_Vol:Web_Vol httpd:2.4

# 進入 Container
docker exec -it Web_Network bash

# 查看 Network
cat /etc/hosts

可以看到 Network 自動多了兩個網路 IP，Web_APP 與 Web_Vol。

直接透過名稱抓抓看：

1
2


curl Web_APP
curl Web_Vol

成功獲得：

不過實務上也不會透過 --link 的方式來建立 Network 映射。更常使用的會是 docker-compose。

Docker Compose

Docker Compose 是什麼？

多 Container 的 App 太麻煩

要 docker build image 或是從 Docker Hub pull Image
要創建多個 container
要管理這些 container (啟動和刪除)

Docker Compose 是什麼

Docker Compose 是一個工具(基於 Docker 的命令列工具)
這個工具可以透過 YAML 定義多 Container 的 Docker 應用
通過一條命令就可以根據 YAML 文件的定義去創建或管理多個 Container

默認文件：docker-compose.yml，三大概念：Services、Networks、Volumes
Services

一個 Service 代表一個 Container，這個 Container 可以從 Docker Hub Image 來創建，或是從本地的 Dockerfile build 出來的 Image 來創建
Services 的啟動類似 docker run，我們可以給其指定 Network 和 Volume
以下用 docker-compose 的 service 和 docker run 產生同樣的容器

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Docker Compose
services:
 db:
 image: postgres:9.4
 volumes:
 - "db-data:/var/lib/postgresql/data"
 networks:
 - back-tier

# docker run
# docker run -d --network back-tier -v db-data:/var/lib/postgresql/data postgres:9.4

Volumes 和 Networks

在跟 services 一樣的級別底下會有 volumes 和 networks

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# Docker Compose
volumes:
 db-data
networks:
 front-tier:
 driver: bridge
 back-tier:
 driver: bridge

# docker volume 與 docker network
# docker volume create db-data
# docker network create -d bridge back-tier

範例：新增一個 WordPress 的 docker-compose.yml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


# docker-compose 版本
version: '3'

services:

 wordpress:
 image: wordpress
 ports:
 - 8080:80
 environment:
 WORDPRESS_DB_HOST: mysql
 WORDPRESS_DB_PASSWORD: root
 networks:
 - my-bridge

 mysql:
 image: mysql:5.7
 environment:
 MYSQL_ROOT_PASSWORD: root
 MYSQL_DATABASE: wordpress
 volumes:
 - mysql-data:/var/lib/mysql
 networks:
 - my-bridge

volumes:
 mysql-data:

networks:
 my-bridge:
 driver: bridge

使用 docker-compose.yml

在虛擬機上安裝 docker-compose，按照官方文件進行安裝。

1
2
3
4
5


# 下載 Docker Compose
sudo curl -L "https://github.com/docker/compose/releases/download/1.25.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

# 給予權限
sudo chmod +x /usr/local/bin/docker-compose

在剛剛建立 wordpress.yml 的資料夾啟動 Container，這邊的 -f 預設就是 docker-compose.yml，可以不填。

1
2
3


docker-compose -f docker-compose.yml up
# or
# docker-compose up

如果執行 docker-compose up 之後再使用 Command + C 退出會直接停止服務，所以可以讓指令在後台執行 docker-compose up -d，如果想要 debug 看 log，才會使用 docker-compose up。
docker-composer 相關指令：

docker-compose stop：會停止服務
docker-compose down：會刪除所有服務(包含 Cotainers、Images、Volumes 和 Networks)
docker-compose start：可以啟動服務
docker-compose ps：查看服務狀態
docker-compose images：查看所有 Images
docker-compose exec：對 Container 執行指令

docker-compose exec 和 docker exec 基本上是一樣的，執行以下指令可以直接進去 Container 裡：

1
2


docker-compose exec mysql bash
docker-compose exec wordpress bash

將 wordpress 服務停止並刪除：

1

docker-compose down

新增 docker-compose.yml。

docker-compose.yml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


version: "3"

services:

 redis:
 image: redis

 web:
 build:
 context: .
 dockerfile: Dockerfile
 ports:
 - 8080:5000
 environment:
 REDIS_HOST: redis

新增 Dockerfile。

Dockerfile

1
2
3
4
5
6
7


FROM python:2.7
LABEL maintaner="xxx@gmail.com"
COPY . /app
WORKDIR /app
RUN pip install flask redis
EXPOSE 5000
CMD [ "python", "app.py" ]

新增 app.py。

app.py

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


from flask import Flask
from redis import Redis
import os
import socket

app = Flask(__name__)
redis = Redis(host=os.environ.get('REDIS_HOST', '127.0.0.1'), port=6379)

@app.route('/')
def hello():
 redis.incr('hits')
 return 'Hello Container World! I have been seen %s times and my hostname is %s.\n' % (redis.get('hits'),socket.gethostname())

if __name__ == "__main__":
 app.run(host="0.0.0.0", port=5000, debug=True)

使用 docker-compose up 就可以啟動服務了，這時候打開本地的瀏覽器就可以看到 flask 的頁面了。

水平擴展和附載均衡(附載平衡)

用 docker-compose 的 --scale 啟動三個 web，但是會出現錯誤，會顯示 8080 已被佔用：

1

docker-compose up --scale= web=3 -d

修改 docker-compose.yml 把 port 刪除。

docker-compose.yml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


version: "3"

services:

 redis:
 image: redis

 web:
 build:
 context: .
 dockerfile: Dockerfile
 environment:
 REDIS_HOST: redis

這時候在分別執行以下命令，Container 就會被啟動：

1
2


docker-compose up -d
docker-compose up --scale web=3 -d

關閉所有的 Contaienr：

1

docker-compose down

修改 docker-compose.yml，加上 loadbalancer。

docker-compose.yml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


version: "3"

services:

 redis:
 image: redis

 web:
 build:
 context: .
 dockerfile: Dockerfile
 environment:
 REDIS_HOST: redis

 lb:
 image: dockercloud/haproxy
 links:
 - web
 ports:
 - 8080:80
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock 

啟動 docker-compose：

1

docker-compose up -d

把網頁內容讀取出來 curl 127.0.0.1:8080 會返回 Container 的 ID：

1

> Hello Container World! I have been seen 1 times and my hostname is 5620b14f864a.

然後把 web 服務擴展成 3 個：

1

docker-compose up --scale web=3 -d

再把網頁內容讀出來，會發現有 3 個 Container id 會輪流出現：

1
2
3
4
5
6
7
8


> Hello Container World! I have been seen 2 times and my hostname is 5620b14f864a.
> Hello Container World! I have been seen 3 times and my hostname is 923de444e90d.
> Hello Container World! I have been seen 4 times and my hostname is 1fde842de3f1.
> Hello Container World! I have been seen 5 times and my hostname is 5620b14f864a.
> Hello Container World! I have been seen 6 times and my hostname is 923de444e90d.
> Hello Container World! I have been seen 7 times and my hostname is 1fde842de3f1.
> Hello Container World! I have been seen 8 times and my hostname is 5620b14f864a.
> Hello Container World! I have been seen 9 times and my hostname is 923de444e90d.

我們也可以把服務擴展成 5 台：

1

docker-compose up --scale web=5 -d

這時候直接 curl 10 次：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


for i in `seq 10`; do curl 127.0.0.1:8080; done

> Hello Container World! I have been seen 10 times and my hostname is 5620b14f864a.
> Hello Container World! I have been seen 11 times and my hostname is 923de444e90d.
> Hello Container World! I have been seen 12 times and my hostname is 1fde842de3f1.
> Hello Container World! I have been seen 13 times and my hostname is 37c3b132c4bd.
> Hello Container World! I have been seen 14 times and my hostname is c2e3df63ddec.
> Hello Container World! I have been seen 15 times and my hostname is 5620b14f864a.
> Hello Container World! I have been seen 16 times and my hostname is 923de444e90d.
> Hello Container World! I have been seen 17 times and my hostname is 1fde842de3f1.
> Hello Container World! I have been seen 18 times and my hostname is 37c3b132c4bd.
> Hello Container World! I have been seen 19 times and my hostname is c2e3df63ddec.

同樣地，也可以減少擴展：

1

docker-compose up --scale web=3 -d

Docker Compose 是用於本地開發的一個工具，並不適合用於 Production，它就是為了方便在本地看部署的結果。

【Docker】建立私有 Docker Registry

Tue, 31 Jan 2023 00:00:05 +0000

參考網站

前言

深度應用 Docker 容器後常會走到這一步 - 自建 Docker Registry (容器 Image 倉庫)。

不管用 docker 指令或跑 Docker Compose，建立容器都需先載入 Docker Image，若是公開 Image，透過 docker pull 指令、在 docker-compose.yml 指定 image 來源、或 Dockerfile 寫 FROM imageName:tag，都可從 Docker Hub 下載，私有程式或內部應用系統不適合上傳第三方系統，企業內部主機則可能位於無法連 Internet 的環境，從 Docker Hub 下載這條路便不可行。簡單做法是用 docker save container-name > container-name.tar 再 scp 上傳到 Docker 主機用 docker load -i container-name.tar 載入，但儲存、上傳、載入(有時還需要壓縮解壓縮)程序複雜，若要部署多台主機格外沒效率。因此，建立私有 Docker Registry 取代 Docker Hub 的角色，是較省事有效率的實務做法。

(補充：關於 Container Image 部署，可參考保哥這篇遷移容器映像(Container Image)到另一台主機的各種作法)

Docker 支援自建私有 Registry 伺服器，不意外地有安裝成 Docker 容器的便捷做法。經簡單設定與安裝，架一台私有 Docker Registry 儲存非公開容器 Image 並不困難。說是一回事，做是一回事，這篇來實地演練一次。

開始

首先準備一台 Docker 主機，裝好 Nginx + Certbot 服務，我是在 Azure 開一個 B1s 小 VM 來跑。

註：Azure 有 Azure Container Registry 的現成雲端服務，做法更簡便。學習在 Linux 跑 Docker 做法是為將來在離線環境建立 Docker Registry 做準備。

以我的標準，即便內部伺服器也要控管存取身分，不能讓閒雜人等隨便用。Docker Registry 支援帳號密碼登入，但前題要啟甪 TLS HTTPS 連線，故除了安裝 htpasswd 工具設定密碼雜湊檔，並需要安裝 mkcert 建立 TLS 憑證：

1

sudo apt-get install apache2-utils mkcert

我在主機端建了一個 /var/registry 資料夾放 Docker Registry 相關檔案，接著用 mkcert 建立自簽憑證給 Registry 用：

設定帳號密碼：

準備好 Docker Compose 設定檔，REGISTRY_HTTP_TLS_CERTIFICATE 及 REGISTRY_HTTP_TLS_KEY 環境變數指向 mkcert 剛才製作的兩個 pem 檔名、REGISTRY_AUTH_HTPASSWD_PATH 指向密碼檔名；volumes 部分將 Docker 的 Image 資料、憑證、認證資料對應到 /var/registry 實體路徑保存，以免容器關閉後資料消失：

docker-compose.yml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


version: "3"
services:
 registry:
 restart: always
 image: registry:2
 ports:
 - 5000:5000
 environment:
 REGISTRY_HTTP_TLS_CERTIFICATE: /certs/localhost.pem
 REGISTRY_HTTP_TLS_KEY: /certs/localhost-key.pem
 REGISTRY_AUTH: htpasswd
 REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
 REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
 volumes:
 - /var/registry/data:/var/lib/registry
 - /var/registry/certs:/certs
 - /var/registry/auth:/auth

用 docker-compose up -d 啟動容器，若一切正常，用 curl https://localhost:5000/v2/ 測試，若傳回 {"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":null}]} 就代表成功了。

接著來測試 Push Image 到私有 Registry，操作程序是用 docker tag 為己載入容器加上 localhost:5000/aspnetapp 這種標籤，此時等同同一個 IMAGE ID 有兩個 Tag，由於 Registry 需要登入，用剛才的設定帳號密碼以指令 docker login 登入，接著 docker push localhost:5000/aspnetsapp 就能完成上傳：

檢查資料夾 /var/registry/data/docker/registry/v2/repositories/aspnetapp/_layers/sha256 可看見上傳過程出現的四個 Layer ID，成功！

接下來試試從 Windows Docker Desktop 從 VM 的對外網域名稱下載容器 Image 執行，一樣輕鬆秒殺：

以上，一台自建 Docker Registry 便上線服役囉～

ASP.NET Core Docker 筆記 4 - ASP.NET Core 網站容器化經驗分享

Fri, 09 Dec 2022 00:00:00 +0000

參考網站
 參考網站
 參考網站
 參考網站

前言

發表 Docker 筆記以來，一直有網友提醒應改用 Kubernetes (K8S)，關於這點在前篇文章已經提過，用 Docker / Docker-Compose 玩玩小網站還 OK，一旦涉及高可用性如備援、負載平衡，若不依賴現成管理架構，維運操作將複雜到會咬人。而 Kubernetes 正是目前容器管理框架的主流業界標準，尤其如打算將容器直接部署到雲端廠商(Azure、AWS、Google GCP)，不會 Kubernetes 更是寸步難行。故在次聲明以正視聽，在企業環境如需考量高可用性、負載平衡或想直接部署到廠商雲端，一般不會用 Docker-Compose 而會採用 Kubernetes，請大家注意。

這篇筆記是我將部落格網站移入 Docker 容器的經驗分享，將記錄 Miniblog.Core ASP.NET Core 網站搬進 Docker 過程遇到的一些眉角。

Reverse Proxy 問題

由於我打算在同一機器上共享對外 IP 跑多個網站，因此採行前一篇筆記所說的「以 Compose 組合網站與 DB，網站對映 Host IP/Port，Nginx 另跑容器導向各網站 Port」策略。

目錄對應

部落格網站有一些執行期間更新的內容，包含 NLog Log 檔、文章圖檔、SQLitｅ資料庫等，這些內容不適合放在容器裡，故都需設 Volume 對映到 Host OS 的實際檔案，如此容器可任意刪除重建及升級，管理運用較方便。

時區問題

踩了雷才知道：Docker 容器內的時區跟 Host OS 是脫鉤的。即便本機已設好定為台北時區，Docker 容器預設為 UTC+0 時區，有兩種做法：

在 docker-compose.yml 中加註環境參數 TZ
新增 Volume 對映 /etc/localtime:/etc/localtime:ro，要求容器以 Host OS 的時區為準

第一種做法遇到以 Alpine Linux 版 Image 建的容器需要額外裝套件，故對映 /etc/localtime 較單純。

參考：設定 Docker Container 與 Host 相同時區的方法

取得真實來源 IP 問題

Reverse Proxy 來源 IP 在 ASP.NET Core + Nginx on CentOS 安裝筆記提過，當 ASP.NET Core 架設在 Reverse Proxy 後方，直接看到的是 Reverse Proxy 的 IP，要得到真實來源 IP，在 Nginx config 需加註 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for，透過 HTTP Header 傳遞內容。而 ASP.NET Core 程式也需修改：

1
2
3
4
5
6
7


public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
 app.UseForwardedHeaders(new ForwardedHeadersOptions
 {
 ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
 });
}

不過若 ASP.NET Core 運行於容器，綁定的 IP 不是 127.0.0.1 而是隔離網段 172.1x.0.x IP，此行為打破 UseForwardedHeaders 假設 Request 來自 localhost 的前題，就算設了 ForwardedHeaders， IHttpContextAccessor.HttpContext.Connection.RemoteIpAddress 讀到的仍是 172.1x.0.1 (隔離網段的 Gateway IP)。

由 ASP.NET Core 的原始碼，檢查規則為若 ForwardedHeadersOptions.KnownNetworks 或 ForwardedHeadersOptions.KnownProxies 有設定，來源 IP 必須要是 KnownNetworks 或 KnownProxies 才會認定請求為 Proxy 轉傳。而 KnownNetworks 及 KnownProxies 預設只有本機 IP。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


 // ...

 /// <summary>
 /// Addresses of known proxies to accept forwarded headers from.
 /// </summary>
 public IList<IPAddress> KnownProxies { get; } = new List<IPAddress>() { IPAddress.IPv6Loopback };

 /// <summary>
 /// Address ranges of known proxies to accept forwarded headers from.
 /// </summary>
 public IList<IPNetwork> KnownNetworks { get; } = new List<IPNetwork>() { new IPNetwork(IPAddress.Loopback, 8) };

 // ...

解決方法有兩種，一種是將 172.x.0.0 加入 ForwardedHeadersOptions.KnownNetworks，但網段為 Docker 自由調配，最好寫成自動偵測不宜寫死。

另一個解法是將 KnownNetworks 與 KnownProxies 都清空，一般有來源 IP 被偽造的風險，但我們 ASP.NET Core 網站架構 Nginx Reverse Proxy 是唯一的入口，故我將其視為可接受做法：

1
2
3
4
5
6
7


var forwardingOptions = new ForwardedHeadersOptions()
{
 ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
};
forwardingOptions.KnownNetworks.Clear(); //its loopback by default
forwardingOptions.KnownProxies.Clear();
app.UseForwardedHeaders(forwardingOptions);

參考：

Nginx 內容壓縮問題

跑了一陣子才發現，我用的 Nginx + Certbot 容器的 Nginx 設定檔 /etc/nginx/nginx.conf 預設未開啟 GZIP 壓縮。

我的解法是新增 Volume 對映將 /etc/nginx/nginx.conf 對應到 Host /etc/nginx/nginx.conf，並修改增加 gzip 那段內容：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


user nginx;
worker_processes 1;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
 worker_connections 1024;
}


http {
 include /etc/nginx/mime.types;
 default_type application/octet-stream;

 log_format main '$remote_addr - $remote_user [$time_local] "$request" '
 '$status $body_bytes_sent "$http_referer" '
 '"$http_user_agent" "$http_x_forwarded_for"';

 access_log /var/log/nginx/access.log main;

 sendfile on;
 #tcp_nopush on;

 keepalive_timeout 65;

 gzip on;
 gzip_min_length 1000;
 gzip_buffers 4 16k;
 gzip_comp_level 5;
 gzip_types text/plain application/x-javascript text/css application/xml text/javascript;

 include /etc/nginx/conf.d/*.conf;
}

Nginx 壓縮設定的意義可參考官方文件

ASP.NET Core Docker 筆記 3 - 共用 Nginx 容器與 Certbot 整合

Thu, 08 Dec 2022 00:00:00 +0000

參考網站

前言

前篇文章介紹過使用 Docker Compose 設定關聯容器(Web、DB、Reverse Proxy)組成系統，容器被隔離在專用網段(Compose 自動建立的 Bridge)，並可透過容器名稱彼此溝通，Compose 也確保相關服務一起啟動一起關閉，是用多個容器建構系統最簡便的做法。

註：關於容器管理 Kubernetes，K8S 提供更強大的功能，支援 Cluster 高可用架構 (單一容器、主機掛掉系統不會死)，為當今在雲端掛載容器以及中大型企業實做容器架構的主流，K8S 無疑可取代 Docker Compose，但其複雜性較高。目前我在單一 Linux 機跑 Docker 還用不到牛刀(雖然有單機版 Minikube 可用)，未來若要將 Docker 應用於工作，K8S 已成必要技能。

用 Docker Compose 組合容器建立服務看似完美，但應用在 Reverse Proxy (Nginx) 時需要額外考量。

我打算在同一台 Linux 上跑多個網站，對外用同一個 IP，再依 HTTP Request 的 Host 標頭導向不同網站。

舉例

舉個例子：假設 Linux 的對外 IP 是 123.123.123.123，我申請兩個 DNS 名稱 web1.xxx.com.tw、web2.xxx.com.tw 都指向 123.123.123.123。

使用者用 http://web1.xxx.com.tw 連上 123.123.123.123 的 80 Port 時，Reverse Proxy 導向 Web1 網站；用 http://web2.xxx.com.tw 時連線時則導向 Web2 網站。由於對外靜態 IP 為珍貴資源，多網站透過 Host 共用 IP 是節省成本的常見做法。

上述以 HTTP Host 名稱導向的做法，若用 Docker Compose 將網站連同 Reverse Proxy 包在一起，就可能出問題。

例如：某 Host OS 跑兩個網站，若各自用 Docker Compose 連同 Nginx 一起包進去，網站 A 由 Web-A + MySQL-A + Nginx-A 組成，網站 B 由 Web-B + MySQL-B + Nginx-B 組成，二者跑在自己的專屬網段，僅 Nginx-A 跟 Nginx-B 對映到 Host OS IP 的 80 Port… 哦哦，衝突出現了，Nginx-A 與 Nginx-B 都需對映 Host IP 的 80 Port，但 Host OS 的 80 Port 只允許被一個程序使用。

解決方式

有幾個解決方向：

Nginx-A 與 Nginx-B 各自對應到主機不同 Port，更前端再掛一台 Nginx 聽 80 Port，依 Host Name 導向到 Nginx-A 與 Nginx- B，如此 Nginx-A 與 Nginx-B 的角色顯得多餘，多了一次轉接但未看到明顯效益，徒增複雜性又耗損效能。
將兩個系統包成一個大 Docker Compose，Web-A + MySQL-A + Web-B + MySQL-B + Nginx，共用 Nginx 可避免 Port 80 繫結衝突，但將不相關系統綁架成一團，被迫一起啟動一起停止挺鳥的，更不用提一旦加跑新服務就要改 Docker Compose，我覺得不行。
將 Nginx 從 Docker Compose 抽離，讓 Web-A 與 Web-B 對映到 Host IP 的不同 Port，整個 Host OS 只跑一份 Nginx 聽 80 Port，依 Host Name 分派給網站 A 或網站 B。也就是用 Docker Compose 執行三個容器：

Web-A + MySQL-A
Web-B + MySQL-B
Ngnix

3 是我認為較可行且有效率的做法。

Nginx 包容器的做法在第一篇筆記已提過，這次我們將重點放在整合 Certbot 及 docker-compose.yml 定義。

原本想抓 Nginx 的 Docker Image 自行加裝 certbot 實現自動安裝與更新 Let’s Encrypt SSL 憑證。

用 Docker 的好處是資源豐富，很快在網路上找到現成解決方案，超級好用的全自動化 Nginx + Certbot -> staticfloat/nginx-certbot。

staticfloat/nginx-certbot

使用方法很簡單，在 /etc/nginx/conf.d 放一個 certbot.conf 接受 80 Port 流量，只用於接收 Let’s Encrypt 的 /.well-known/acme-challenge 要求導向 Certbot 完成自動驗證，其餘則一律導向 HTTPS：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


server {
 # Listen on plain old HTTP
 listen 80 default_server;

 # Pass this particular URL off to certbot, to authenticate HTTPS certificates
 location '/.well-known/acme-challenge' {
 default_type "text/plain";
 proxy_pass http://localhost:1337;
 }

 # Everything else gets shunted over to HTTPS
 location / {
 return 301 https://$http_host$request_uri;
 }
}

接著在 /etc/nginx/conf.d 為每個網站新增一個 someweb.conf 承接 HTTPS 請求。server_name 註明該網站綁定的 Host 名稱(DNS 名稱)，ssl_certificate、ssl_certficate_key 則指向 /etc/letsencrypt/live/DNS名稱 的 fullchain.pem 及 private.pem，這兩個檔案不需事先準備，Certbot 會自動產生，至於 proxy_* 相關設定比照先前介紹過的做法。完整範例如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


server {
 listen 443 ssl;
 server_name blog.darkthread.net;
 ssl_certificate /etc/letsencrypt/live/blog.darkthread.net/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/blog.darkthread.net/privkey.pem;

 location / {
 proxy_pass http://localhost:5000;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection keep-alive;
 proxy_set_header Host $host;
 proxy_cache_bypass $http_upgrade;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 }
}

這個 Docker Image 有一段精巧設計，它在啟動時會主動掃瞄 /etc/nginx/conf.d 下的 config，一旦偵測缺少 /etc/letsencrypt/live/*/fullchain.pem 就連上 Let’s Encrypt 網站進行驗證下載 SSL 憑證，另外還設了每週一次的排程，憑證到期前會自動更新，一氣喝成，全不沾手，貼心到我想起立鼓掌。

若對它的運作原理有興趣，Github 有原始碼可以參考。

為了瞭解原理，我是依著 Github 原始碼自己跑 Dockerfile 製作 Nginx + Certbot 的 Image，如果嫌麻煩，直接從 Docker Hub 下載也成。

以下是我的 Nginx docker-compose.yml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


version: "3"
services:
 nginx:
 image: nginx-certbot
 container_name: nginx
 ports:
 - 80:80
 - 443:443
 volumes:
 - /var/log/nginx:/var/log/nginx
 - /etc/nginx/conf.d:/etc/nginx/conf.d
 - /etc/letsencrypt:/etc/letsencrypt
 restart: always
 environment:
 - CERTBOT_EMAIL=your-email@mail.com
 network_mode: "host"

我設了三個 Volume 對映：

/var/log/nginx：Log 檔
/etc/nginx/conf.d：設定檔
/etc/letsencrypt：用來存放 SSL 憑證

若為 SELinux 記得要 chcon -Rt 參考，另外 network_mode 指定 host 表示 Nginx 容器將直接使用 Host OS 網段，不另設 Bridge。

參考：Docker Compose 鏈接外部容器的幾種方式

就醬，Nginx Reverse Proxy 準備好了，下一篇來再來分享我將 ASP.NET Core 搬進 Docker 的經驗。

ASP.NET Core Docker 筆記 2 - 組合容器建構系統

Wed, 07 Dec 2022 00:00:00 +0000

參考網站
 參考網站

上篇文章體驗過在 CentOS 用 Docker Container 分別跑 Nginx 跟 ASP.NET Core 網站，並建立 Reverse Proxy 關係，接著探討在實務上當需要多個 Container 協同運作時應如何規劃整合。

一個系統常可再拆解成多個服務。以線上購物網站為例，就可能是由 ASP.NET Core 網站(Kestrel)、MySQL 資料庫、Reverse Proxy、金流 Gateway… 等多個服務組成，若要以 Docker Container 實現，有幾種策略：

策略

1. 全部裝在單一 Container

撰寫一個 Dockerfile，以 MySQL 資料資料庫為基底，在上面安裝 ASP.NET Core Runtime、Nginx 組裝合成獸。

好處是一個 Container 搞定，高內聚低耦合，不會因相依服務沒配置好或未啟動而故障。但缺點挺明顯：

某些 Container Image 為求輕巧作業系統層次的工具、程式庫很精簡(例如：Nginx Container 連 ping 都沒有)，只求目標程式能執行就好，要加裝其他軟體時要點技巧，得多花些心思。
全部綁在一起便失去動態調配的彈性，例如：當前端 Web 負載過高時，擴充不易。
當需要個別升級資料庫、ASP.NET Core 版本，或是想抽換服務組合時手續複雜，有違模組化精神。

2. 以個別 Container 執行，獨立控制

如同前篇文章的做法，ASP.NET Core 網站跑 Cotainer 繫結到 Host OS 的 5000 Port，用 Container 跑 MySQL，再用 Container 跑 Ngnix 繫結到 Host OS 80 Port，再設定 Reverse Proxy 規則。

Container 間串接配置全靠人工，系統管理員需協助哪個 Container 聽哪個 Port，確保彼此不衝突。如此做有兩個缺點：

相依服務的啟動狀態未連動，需靠人為控制確保先啟動資料庫 Container 再啟動網站 Container 的順序。
若 Host OS 跑多個系統都用到 MySQL，系統管理員需協調 TCP Port 不衝突，Docker 的 Bridge (橋接器)隔離網段機制全無用武之地。

3. 以個別 Container 執行，但使用 Docker Compose 關聯

為滿足多 Container 協同作業需求，Docker Compose 應運而生。

Docker Compose 定義了一套宣告語法(採用 YAML 格式)，在其中定義各服務 Container 的啟動參數、與 Host OS Port 對映、隸屬 Bridge 網段、Volume 資料夾/檔案對應等等。

Docker Compose 會自動為 Container 建立隔離網段並設好名稱解析，讓 Container 使用容器名稱解析成 IP 找到其他 Container，因此設定連線字串或 URL 時便可寫成 httq://myweb:5000、mongodb://mydb，清楚又方便。

最重要是透過 docker-compose up/down 指令可以一次啟動或停用相關服務，Docker Compose 還會依據相依 depends_on 指定關聯先啟動 DB 再啟動 Web，先關閉 Web 再關閉 DB，便利性讓人工操作望塵莫及。

參考：Docker Compose 初步閱讀與學習記錄

實例

針對上述三種做法，以 ASP.NET Core + Ngninx 為題，對映到以下實例：

1. 安裝成單一 Container

以 ASP.NET Core Image 為基底，安裝 Nginx，設定 nginx.conf，複製 ASP.NET Core 網站檔案並設定 service nginx start 及 dotnet /app/web.dll 分別啟動 Nginx 及 Kestrel。

細節做法可參考這篇文章：Nginx Reverse Proxy to ASP.NET Core – Same Docker Container

不過，該文用的 ASP.NET Core 版本偏舊，若為 ASP.NET Core 2.1 包成 Docker Container 的做法請參考前文

2. ASP.NET Core、Nginx 各自跑 Container

就是我們在前篇文章採行的方式，但有一點要補充，除了直接對映到 Host OS IP 的 TCP Port，也可考慮自訂 Bridge，讓 Container 在隔離網段內溝通，例如：ASP.NET Core 的 5000 Port 只有 Nginx 看得到，從 Host OS 無法存取，如此可避免網路介面(網站、資料庫…)外露到 Host OS，減少被攻擊的風險，這部分後面再找時間介紹。

3. 使用 Docker Compose 串連

ASP.NET Core 與 Nginx 各有自己的容器，使用 Docker Compose 組合串連，一次啟動兩個服務。

細節做法可參考這篇文章：Nginx Reverse Proxy to ASP.NET Core – Separate Docker Containers

綜合以上分析，Docker Compose 無疑是整合關聯 Container 較佳的方式。

練習

光說不練是假把式，寫技術文沒實作感覺怪怪的，來個 Docker Compose 練習好了。手邊沒有 ASP.NET Core + DB Server 的範例，就用 Docker 可以找到的 Image 當題材(也方便大家實地驗證)，試試用 Container 跑 Wekan 看板系統。Wekan 在 Node.js 執行，另外需要 MongoDB，這個練習會用 Docker Compose 組合兩個 Container 架設看板網站。

開始前，記得先安裝 Docker Compose，如果發生 sudo docker-compose 找不到指令，要再加上 sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose 參考。

要使用 Docker Compose 很簡單，說穿了就是將 Container 設定寫成 docker-compose.yml，寫好寫對再呼叫 docker-compose up -d 即大功告成。以 Wekan 為例，docker-compose.yml 如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


version: '3'
services:
 wekan:
 image: wekanteam/wekan:latest
 depends_on:
 - wekandb
 environment:
 - MONGO_URL=mongodb://wekandb/wekan
 - ROOT_URL=http://localhost:80
 ports:
 - 80:8080
 wekandb:
 image: mongo:3.2.14
 volumes:
 - /var/www/wekan/db:/data/db

在這個 YAML 裡，我定義了兩個 Service Container，分別叫 wekan 及 wekandb。

Wekan Container Image 來自 wekanteam/wekan 最新版，depends_on 宣告 wekan 依賴 wekandb，故 Docker Compose 會先啟動 wekandb 再啟動 wekan。

MONGO_URL、ROOTL_URL 為環境變數，其中 MONGO_URL 寫成 mongodb://wekandb/wekan，docker-compose.yml 所定義的各 Container 預設隸屬同一個 Bridge 網段，彼此可用機器名稱解析。

Wekan 網站在 Container 掛在 8080 Port，透過 ports 80:8080 會將其對映到 Host IP 80 Port。

wekandb Container 則以 Mongo DB Container Image 為基底，資料庫檔案以 Volume 方式對映到 Host OS /var/www/wekan/db 資料夾。

這裡補充一個眉角，由於 SELinux 資安管控較嚴，在 CentOS/REHL/Fedora 版 Linux 上 Docker Container 讀取 Volume 對映資料夾可能會出現 permission denied 錯誤，需對該資料夾執行 chcon -Rt svirt\_sandbox\_file\_t /var/www/wekan/db 調整權限，或在目錄名稱後方加上 :Z 由 Docker 自動執行。

參考：Using Volumes with Docker can Cause Problems with SELinux

寫好 docker-compose.yml，執行 sudo docker-compose up -d，Docker Compose 依序帶起 weknadb、wekan 兩個容器，Wekan 看板已在 Host OS 80 Port 運行成功。

最後補充一點，前面提到 Docker Compose 會為整組 Container 建立專屬 Bridge，上圖一開始的 Create network “wekan_default” with the default driver 訊息就是證明。

執行 docker network ls，可看到 wekan_default 是個 bridge，執行 docker inspect wekan_default 則可進一步看到這個網段為 172.18..，而兩個 Container 的 IP 分別為 172.28.0.3 及 172.28.0.2。

Docker Compose 非常適合用來組裝 Web、DB 等多個 Container 構建系統，但我發現針對 Nginx 時有些額外考量，這部分留待下集分解。

ASP.NET Core Docker 筆記 1 - 初探

Tue, 06 Dec 2022 00:00:00 +0000

參考網站
 參考網站

前面研究過在 CentOS 安裝及設定 ASP.NET Core + Nginx，習得徒手在 CentOS 安裝部署伺服器的技能，依循 Roadmap 來到下一階段 - 學習使用 Docker 簡化部署。

容器化及 Docker 這幾年熱到發燙，有些人甚至認為它已在軟體產業掀起一波革命。(我親身體驗的感想也是：Wow! 難怪會爆紅) 此刻才起步已算遲了，但也不是沒有好處，晚起鳥兒有更多蟲可以吃，Docker 相關的文章資源多如牛毛，這裡便不多花篇幅贅述觀念與基本操作，只簡單整理我對 Docker 的理解。

Docker 相關介紹

Container

Container (容器)可以想成極度輕量化的虛擬機器(Virtual Machine)，用法及優點與 VM 相同，能在一台 Host OS 同時運行多個彼此隔離的應用程式環境，但差別在 Container 會共用底層 Host OS，相較 VM 需各跑一份 Guest OS 能省下可觀的記憶體、磁碟，因此 Container 多了啟動速度快，耗用資源少(與直接跑應用程式相去不遠)的優勢。

一台 4GB RAM 的機器頂多跑 2 - 3 台 VM 就緊繃了，但執行數十上百個 Container 不是問題。

2 Container 跟 VM 一樣具有很好的隔離效果，每個 Container 有自己的獨立作業環境(記憶體、磁碟空間、網路)，不會彼此干擾，不必擔心 Container A 改系統設定害 Container B 跑不起來，或是兩個 Container 互相搶奪 80 Port，拿到 Image 就一定能在自己的機器跑起來。

Container 在這方面的特性與 VM 完全相同，但因為不用包入作業系統，體積縮小許多，耗用記憶體也少，但便利性完全不減，取得 Container Image，靠一行指令幾秒內就能在機器把程式跑起來。

Docker Hub

Docker Hub 上有超過 10 萬個 Container Image，從 PHP、Node,js、Apache、MySQL、Mongo DB、Nginx、Redis、ASP.NET Core… 幾乎想得到的都有，下指令自動下載 Image，幾秒鐘就裝好一台 DB、Web 伺服器，再下個指令又裝好第二台，不用擔心跟作業系統不相容、與其他軟體相衝、系統環境有誤導致安裝失敗，這就是 Docker 最迷人的所在。

而我們也可將自己的專案網站做成 Image，交給測試人員測試，交付 OP 幾秒部署上線，也能將做好的 Image 上傳到 Docker Hub 與全世界分享。

Docker Container

Docker Container 起初是基於 Linux Container 技術，故在 Container 只能跑 Linux 平台應用程式，雖然在 Windows 也有 Docker for Windows，但背後是用 Hyper-V 跑 Linux 虛擬機執行 Docker Engine 再跑 Docker Container。

後來微軟也依循相同概念發展出 Windows Container，並融入 Docker 體系，自此 Docker Container 開始有 Linux Container、Windows Container 之分，Windows Container 裡跑的就是不折不扣的 Windows 程式。

參考：安裝 Docker 容器環境 - Windows Server 2016

從此，在 Container 裡跑 ASP.NET WebForm不再是夢。

Windows Container

Windows Container 問市後，ASP.NET Core 程式容器化有 Linux Container 與 Windows Container 兩種選擇。

基於 Linux Container 資源數量上的優勢，加上耗用資源較少，軟硬體成本低，我選擇 Linux Container。

雖然 Container 間共用底層作業系統，Docker Engine 為容器中的應用程式提供隔離不受干擾的空間（記憶體、檔案系統、網路 Port）。

例如：容器 A 寫入 /etc/aaa/default.conf 不影響容器 B /etc/aaa/default.conf 的內容、容器 A 與容器 B 都繫結到 80 Port 也不會衝突。

先前文章提過將 Kestrel 轉為 Linux 服務、設定 www-data 執行權限… 等步驟，改用 Docker 後簡單很多，生命週期由 Docker 控制，在容器內部權限一律為 root 不需額外規劃權限，直接跑 dotnet WebApp.dll 聽 5000 Port 就好。

參考資料：

練習

Docker 安裝與基本操作的參考資料很多，這裡不多介紹，直接來幾個練習暖身：在 CentOS 上用 Docker 下載現成 Conatiner Image 執行 Nginx 伺服器，再用預設專案範本建立 ASP.NET Core 網站並包進 Container 執行。最後將二者串接在一起，使用 Nginx 做為 ASP.NET Core 網站的 Reverse Proxy。

執行 Nginx Container

1

sudo docker run --name mynginx -d -p 80:80 --rm nginx

不誇張，真的只要這行 Nginx 就好了。

-d：把 Container 丟到背景執行不要佔用命令列視窗
-p 80:80：表示將 Container 的 80 Port 對應到 Host OS 的 80 Port
--rm：表示 Container 停止時自動刪除。

開個 Chrome 連上 Host OS 的 80 Port，Nginx 已經準備就緒！

註：docker 指令需繫結 Unix Socket，必須以 SuperUser 權限執行，將使用者加入 Docker 群組可省去每次加 sudo 的麻煩。參考：Manage Docker as a non-root user

1
2


sudo groupadd docker
sudo usermod -aG docker $USER

但這招在 CentOS/Fedora/RHEL 不管用!，但有替代方案：在 /etc/sudoers 加入 yourUserAccount ALL=(ALL) NOPASSWD: /usr/bin/docker 開放 sudo docker 時不用敲密碼，再用 alias docker="sudo /usr/bin/docker" 建立同義詞，也可做到不必 sudo 敲密碼跑 docker 指令。

將 ASP.NET Core 專案包進 Container

將 ASP.NET Core 專案包進 Container 使用 .NET Core CLI 建立 MVC 專案，修改 Startup.cs 取消 app.UseHttpsRedirection()，以 Kestrel 執行 ASP.NET Core 網站。

1
2
3
4


dotnet new mvc
sed -i -e 's/app.UseHttps/\/\/app.UseHttps/' Startup.cs
dotnet publish
dotnet bin/Debug/netcoreapp2.1/web.dll

由於 5000 Port 預設不對外開放，懶得開防火牆，在本機用 curl httq://localhost:5000 驗證網站運行中。

驗證程式可執行後，寫個 Dockerfile 腳本將程式封裝成 Docker Image，這部分細節可參考保哥的文章：如何將 ASP.NET Core 2.1 網站部署到 Docker 容器中。

在實務環境可以設計成全自動化測試流程，到版控抓原始碼放進內含 .NET Core SDK 的 Container 編譯，將結果包成只有 .NET Core Runtime 的 Container Image，用它建立 Container 進行 E2E 測試，一切自動化。這裡為求簡便，我選擇用只有 Runtime 的 Container Image 當成基底，將在 Host OS 編譯好的檔案複製到 Container /app 目錄，Dockerfile 內容如下：

1
2
3
4


FROM microsoft/dotnet:2.1-aspnetcore-runtime
WORKDIR /app
COPY ./bin/Debug/netcoreapp2.1 ./
ENTRYPOINT ["dotnet", "web.dll"]

做好 Dockerfile 後執行 docker build，Docker 會從 Docker Hub 下載 microsoft/dotnet:2.1-aspnetcore-runtime (microsoft/dotnet 是 Image 名稱，同一 Image 常有多種版本可選擇，:2.1-aspnetcore-runtime 是標籤可用來指定版本)，-t 參數指定 Image 名稱為 testapp。

Container Image 做好後接著用 docker run -d --rm --name myapp -p 5000:80 testapp 用剛做好的 Image 建立 Container，ASP.NET Core 專案在 Container 執行時，預設聽 80 Port，故我們用 -p 5000:80 將 Container 的 80 Port 導向 Host OS 的 5000 Port。用 curl 驗證網站運行中。

使用 docker images 及 docker ps 我們可以看到剛才建立的 Image testapp 及 Container myapp：

將 Nginx 設成 ASP.NET Core 網站的 Reverse Proxy

至此，我們做了兩個 Container，myginx 聽 Host OS 80 Port，myapp 聽 Host OS 的 5000 Port，下一步要將 Nginx 設成 ASP.NET Core 網站的 Reverse Proxy。

做法跟先前文章介紹過的概念差不多，為求簡便我們直接修改 conf.d/default.conf 將進入 80 Port 的請求導向 5000 Port。(正規做法建議一個網站開一個 conf 檔) Container 的檔案系統是隔離的，將設定檔保存在 Container 裡不是好主意 - 除非每次修改設定存檔就重新產生 Image 並要求未來一律改用新版 Image 建立 Container，否則一旦 Conatiner 被刪除，設定就會消失。同樣問題也會發生在資料庫檔、Log 檔等執行期間要動態更新的內容，這類檔案保存在 Host OS 檔案系統上比較合理，程式換版換了 Container Image 資料才不受影響。Docker 靠 Volume 解決資料保存及共用需求，docker run 有個 -v host-path:container-path 可將 Host OS 特定目錄或檔案對映到 Container，讓 Container 能讀寫 Host OS 的檔案。

對 Nginx Container 來說，Reverse Proxy 設定放在 /etc/nginx/conf.d，我選擇在 Host OS 也建立相同路徑並將 Container 的 default.conf 複製出來(指令如下)，修改後在 docker run 加上 -v /etc/nginx/conf.d:/etc/nginx/conf.d 對映回去：

1

sudo docker cp mynginx:/etc/nginx/conf.d /etc/nginx/conf.d

修改 /etc/nginx/conf.d/default.conf，目前是將進入 Nginx 80 Port 的請求導向 Host OS 5000 Port，但從 Docker Container 存取 Host OS IP 有些眉角，Mac 或 Windows Docker 18.3+ 可用 DNS 名稱 host.docker.internal 指向 Host OS IP，但 Docker for Linux 18.4+ 這招己失效。參考

省事做法是 docker run 時用 --network host 讓 Container 直接繫結本機 IP 而非 Docker 所屬的隔離網段，如此 default.conf 的 proxy_pass 指向 localhost:5000 即可。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


server {
 listen 80;
 server_name localhost;

 #charset koi8-r;
 #access_log /var/log/nginx/host.access.log main;

 location / {
 proxy_pass http://localhost:5000;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection keep-alive;
 proxy_set_header Host $host;
 proxy_cache_bypass $http_upgrade;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 }
}

完整啟動指令如下：

1

sudo docker run --name mynginx -d -v /etc/nginx/conf.d:/etc/nginx/conf.d --network host nginx

從遠端開啟 Chrome 連上 Host OS 的 80 Port，我們已被順利導向 ASP.NET Core 網站，顯示設定成功。

經過以上練習，我們體驗了從 Docker Hub 下載 Image 建立 Docker Containter 跑 Nginx、用 Dockerfile 將 ASP.NET Core 網站包成 Container、用 Port 映對 Host OS TCP Port 到 Container、使用 -v(–volume) 映對資料夾讓 Container 讀寫 Host OS 檔案。

而在實務應用上，相關的 Conatiner 需要組合在一起執行，例如一個 Container 跑網站，一個 Container 跑資料庫，此時可用 docker-compose 簡化管理；另外 Docker 也提供 Bridge 為相關 Container 建立專屬的隔離網段，防止外界接觸到不想對外公開的網路服務，也避免不相干的 Container 彼此干擾… 這些議題就留待下一篇文章討論。

Docker Compose 鏈接外部容器的幾種方式

Sun, 04 Dec 2022 00:00:00 +0000

參考網站

在 Docker 中，容器之間的鏈接是一種很常見的操作，它提供了訪問其中的某個容器的網絡服務而不需要將所需的端口暴露給 Docker Host 主機的功能。Docker Compose 中對該特性的支持同樣是很方便的。然而，如果需要鏈接的容器沒有定義在同一個 docker-compose.yml 中的時候，這個時候就稍微麻煩複雜了點。

不使用 Docker Compose

在不使用Docker Compose的時候，將兩個容器鏈接起來使用—link參數，相對來說比較簡單，以nginx鏡像為例子：

1
2


docker run --rm --name test1 -d nginx # 開啟一個實例test1 
docker run --rm --name test2 --link test1 -d nginx # 開啟一個實例test2並與test1建立鏈接

這樣，test2 與 test1 便建立了鏈接，就可以在 test2 中使用訪問 test1 中的服務了。

使用Docker Compose

如果使用 Docker Compose，那麼這個事情就更簡單了，還是以上面的 nginx 鏡像為例子，編輯 docker-compose.yml 文件為：

docker-compose.yml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


version: "3"
services:
 test2:
 image: nginx
 depends_on:
 - test1
 links:
 - test1
 test1:
 image: nginx

最終效果與使用普通的 Docker 命令 docker run xxxx 建立的鏈接並無區別。這只是一種最為理想的情況。

問題

如果容器沒有定義在同一個 docker-compose.yml 文件中，應該如何鏈接它們呢？
如果定義在 docker-compose.yml 文件中的容器需要與 docker run xxx 啟動的容器鏈接，需要如何處理？

方法一：讓需要鏈接的容器同屬一個外部網絡

我們還是使用 nginx 鏡像來模擬這樣的一個情景：假設我們需要將兩個使用 Docker Compose 管理的 nignx 容器(test1和test2)鏈接起來，使得 test2 能夠訪問 test1 中提供的服務，這裡我們以能 ping 通為準。

首先，我們定義容器 test1 的 docker-compose.yml 文件內容為：

docker-compose.yml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


version: "3"
services:
 test2:
 image: nginx
 container_name: test1
 networks:
 - default
 - app_net
networks:
 app_net:
 external: true

容器 test2 內容與 test1 基本一樣，只是多了一個 external_links。

需要特別說明的是：最近發布的 Docker 版本已經不需要使用 external_links 來鏈接容器，容器的 DNS 服務可以正確的作出判斷，因此如果你你需要兼容較老版本的 Docker 的話，那麼容器 test2 的 docker-compose.yml 文件內容為：

docker-compose.yml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


version: "3"
services:
 test2:
 image: nginx
 networks:
 - default
 - app_net
 external_links:
 - test1
 container_name: test2
networks:
 app_net:
 external: true

否則的話，test2 的 docker-compose.yml 和 test1 的定義完全一致，不需要額外多指定一個 external_links。相關的問題請參見 stackoverflow 上的相關問題：docker-compose + external container

正如你看到的那樣，這裡兩個容器的定義裡都使用了同一個外部網絡 app_net，因此，我們需要在啟動這兩個容器之前通過以下命令再創建外部網絡：

1

docker network create app_net

之後，通過 docker-compose up -d 命令啟動這兩個容器，然後執行 docker exec -it test2 ping test1，你將會看到如下的輸出：

1
2
3
4
5
6
7
8


$ docker exec -it test2 ping test1
PING test1 (172.18.0.2): 56 data bytes
64 bytes from 172.18.0.2: icmp_seq=0 ttl=64 time=0.091 ms
64 bytes from 172.18.0.2: icmp_seq=1 ttl=64 time=0.146 ms
64 bytes from 172.18.0.2: icmp_seq=2 ttl=64 time=0.150 ms
64 bytes from 172.18.0.2: icmp_seq=3 ttl=64 time=0.145 ms
64 bytes from 172.18.0.2: icmp_seq=4 ttl=64 time=0.126 ms
64 bytes from 172.18.0.2: icmp_seq=5 ttl=64 time=0.147 ms

證明這兩個容器是成功鏈接了，反過來在 test1 中 ping test2 也是能夠正常 ping 通的。

如果我們通過 docker run --rm --name test3 -d nginx 這種方式來先啟動了一個容器(test3)，並且沒有指定它所屬的外部網絡，而需要將其與 test1 或者 test2 鏈接的話，這個時候手動鏈接外部網絡即可：

1

docker network connect app_net test3

這樣，三個容器都可以相互訪問了。

方法二：更改需要鏈接的容器的網絡模式

通過更改你想要相互鏈接的容器的網絡模式為 bridge，並指定需要鏈接的外部容器(external_links)即可。

與同屬外部網絡的容器可以相互訪問的鏈接方式一不同，這種方式的訪問是單向的。

還是以 nginx 容器鏡像為例子，如果容器實例 nginx1 需要訪問容器實例 nginx2，那麼 nginx2 的 docker-compose.yml 定義為：

docker-compose.yml

1
2
3
4
5
6


version: "3"
services:
 nginx2:
 image: nginx
 container_name: nginx2
 network_mode: bridge

與其對應的，nginx1 的 docker-compose.yml 定義為：

docker-compose.yml

1
2
3
4
5
6
7
8


version: "3"
services:
 nginx1:
 image: nginx
 external_links:
 - nginx2
 container_name: nginx1
 network_mode: bridge

需要特別說明的是，這裡的 external_links 是不能省略的，而且 nginx1 的啟動必須要在 nginx2 之後，否則可能會報找不到容器 nginx2 的錯誤。

接著我們使用 ping 來測試下連通性：

1
2
3
4
5
6
7
8


$ docker exec -it nginx1 ping nginx2 # nginx1 to nginx2
PING nginx2 (172.17.0.4): 56 data bytes
64 bytes from 172.17.0.4: icmp_seq=0 ttl=64 time=0.141 ms
64 bytes from 172.17.0.4: icmp_seq=1 ttl=64 time=0.139 ms
64 bytes from 172.17.0.4: icmp_seq=2 ttl=64 time=0.145 ms

$ docker exec -it nginx2 ping nginx1 #nginx2 to nginx1
ping: unknown host

以上也能充分證明這種方式是屬於單向聯通的。

在實際應用中根據自己的需要靈活的選擇這兩種鏈接方式，如果想偷懶的話，大可選擇第二種。不過我更推薦第一種，不難看出無論是聯通性還是靈活性，較為更改網絡模式的第二種都更為友好。

10 個 Q&A 快速認識 Docker

Tue, 28 Oct 2014 00:00:00 +0000

參考網站

不論是 Google、Amazon、微軟、VMware 都紛紛擁戴，加入 Docker 和 Container 所掀起的新世代雲端虛擬化行列，這 2 項技術成為了 IT 界的新顯學。Docker 和 Container 到底是什麼？以下 10 個 Q&A 告訴你。

Q1：Container 技術和伺服器虛擬化是一樣的技術嗎？

**A：**不是。兩者雖然都屬於虛擬化的技術，目標都是為了將一套應用程式所需的執行環境打包起來，建立一個孤立環境，方便在不同的硬體中移動，但兩者的運作思維截然不同。簡單來說，常見的傳統虛擬化技術如 vSphere 或 Hyper-V 是以作業系統為中心，而 Container 技術則是一種以應用程式為中心的虛擬化技術。

傳統虛擬化技術從作業系統層下手，目標是建立一個可以用來執行整套作業系統的沙箱獨立執行環境，習慣以虛擬機器(Virtual Machine)來稱呼。而 Container 技術則是直接將一個應用程式所需的相關程式碼、函式庫、環境配置檔都打包起來建立沙箱執行環境，為了和傳統虛擬化技術產生的虛擬機器區分，Container 技術產生的環境就稱為 Container。

Q2：一般常見的虛擬機器和 Container 有何不同？

**A：**最明顯的差別是，虛擬機器需要安裝作業系統(安裝 Guest OS)才能執行應用程式，而 Container 內不需要安裝作業系統就能執行應用程式。Container 技術不是在 OS 外來建立虛擬環境，而是在 OS 內的核心系統層來打造虛擬執行環境，透過共用 Host OS 的作法，取代一個一個 Guest OS 的功用。Container 也因此被稱為是 OS 層的虛擬化技術。

Q3：為何 Container 是輕量級虛擬化技術？

**A：**因為 Container 技術採取共用 Host OS 的作法，而不需在每一個 Container 內執行 Guest OS，因此建立 Container 不需要等待作業系統開機時間，不用 1 分鐘或幾秒鐘就可以啟用，遠比需要數分鐘甚至數十分鐘才能開啟的傳統虛擬機器來的快。

Q4：Container 技術是全新的技術嗎？

**A：**不是，早在 1982 年，Unix 系統內建的 chroot 機制也是一種 Container 技術。其他如 1998 年的 FreeBSD jails、2005 年出現的 Solaris Zones 和 OpenVZ，或像是 Windows 系統 2004 年就有的 Sandboxie 機制都屬於在作業系統內建立孤立虛擬執行環境的作法，都可稱為是 Container 的技術。

直到 2013 年，dotCloud 這家 PaaS 服務公司開源釋出了一套將 Container 標準化的平臺 Docker，大受歡迎，所以，dotCloud 決定以 Docker 為名成立新公司力推。

Q5：Docker 如何實現 Container 標準化？

**A：**Docker 採用了 aufs 檔案系統來設計一個可以層層堆疊的 Container 映象檔，將 Container 內的所有程式(包括應用程式、相關函式庫、設定檔)，都打包進 Docker 映象檔，並且提供了一個 Dockerfile 設定檔來記錄建立 Container 過程的每一個步驟包括參數。只要在任何支援 Docker 平臺的環境中，就可以從這個映象檔來建立出一個一模一樣的 Container 來執行同一個應用程式。如此一來，應用程式等於是可以透過 Docker 映象檔，或甚至只需要 Dockerfile，就能將程式執行環境帶著走，移動到任何支援 Docker 的環境中。Docker 公司也釋出 API，可以用來控制所有的 Container 相關指令，任何人只要使用同一套 Docker，就等於有了同一套管理和建立 Container 的方法，也就等同於將 Container 運用標準化了。

Q6：一個 Container 映象檔內可以安裝多少應用程式？

**A：**一個 Container 的映象檔內可以安裝多支程式，例如同時安裝 Ubuntu、Apache、MySQL、Node.js、Ruby 等。不過，Docker 官方建議，一隻程式安裝在一個 Container 內，再把這些 Container 疊起來提供一個完整的服務。

Docker 稱這是一種 Microservices(微服務)的新軟體架構，將組成一個應用系統的每一個 Stack，拆解成許多小型服務，例如 Apache 服務、MySQL 服務、Node.js 服務、Ruby 服務，每一個服務都是包在 Container 裡的一隻程式，例如 MySQL 服務就是部署在 Container 內的 MySQL。

這麼做的好處是可以建立一個鬆散耦合的彈性應用程式架構，也能輕易地抽換其中一個 Container，例如要升級 MySQL，只需要重新載入新版 MySQL 的 Container 映象檔，就可以完成資料庫升級，不用將整套應用系統停機。

Q7：Container 內不是不需要 OS，為何需要 OS 的基礎映象檔？

**A：**OS 基礎映象檔的用途是讓 Container 擁有這 OS 的檔案系統，例如使用 ubuntu 基礎映象檔就可以讓 Container 建立 ubuntu 的根目錄架構，而不是用來執行一個 OS 執行實例。

Q8：Docker 對 Devops 有何幫助？

**A：**因為 Docker 透過 Dockerfile 來記錄建立 Container 映象檔的每一個步驟，可以將建立應用程式執行環境的過程和配置參數，完整地記錄下來。開發人員和維運人員之間可以利用 Dockerfile 來溝通對執行環境的討論。甚至結合版本控制服務如 GitHub，可以讓 Dockerfile 具備版本控制功能，能將基礎架構程式化(Infrastructure as code)來管理。

Q9：可以在 Windows Server 環境中執行 Docker 嗎？

**A：**還不行。目前 Docker 只能在 Linux 平臺上執行，但是微軟 10 月中剛宣布要在下一波 Windows Server 改版時內建 Docker 引擎，未來同一份 Docker 映象檔能否跨 Linux 和 Windows OS，還需待微軟揭露更多細節才能得知。

Q10：在臺灣，如何找到懂 Docker 技術的人？

**A：**目前 Docker 公司還未在臺設點，但有一個 Docker Taipei 社群，成員截至 10 月有 383 人。

Docker Taipei 也預計配合 Docker 總公司舉辦的全球 HackDay 活動，在 11 月 1 日舉辦臺北場 HackDay。參加作品將直接發布到美國和全球 Docker 開發者一起評比，獎品是明年到美國參加 Docker 技術大會的資格。

Docker on Wayne's blog | 偉恩的部落格 | 技術博客

【Docker】數據持久化與數據共享 - tmpfsMount/BindMount/Volume

前言

tmpfsMount

如何使用 tmpfsMount？

BindMount

如何使用 BindMount？

Volume

Volume 的優點

如何使用 Volumes？

Volume 的 2 種參數

-v 參數

–mount 參數

練習： 用 Docker 跑 MySQL

目標

方法一 (網路查找的標準步驟)

方法二 (自行實驗的步驟過程)

Docker Network

Docker Network 原理

Container 互相訪問

Network 映射

Docker Compose

Docker Compose 是什麼？

使用 docker-compose.yml

docker-compose.yml

Dockerfile

app.py

水平擴展和附載均衡(附載平衡)

docker-compose.yml

docker-compose.yml

【Docker】建立私有 Docker Registry

前言

開始

docker-compose.yml

ASP.NET Core Docker 筆記 4 - ASP.NET Core 網站容器化經驗分享

前言

Reverse Proxy 問題

目錄對應

時區問題

取得真實來源 IP 問題

Nginx 內容壓縮問題

ASP.NET Core Docker 筆記 3 - 共用 Nginx 容器與 Certbot 整合

前言

舉例

解決方式

staticfloat/nginx-certbot

ASP.NET Core Docker 筆記 2 - 組合容器建構系統

策略

1. 全部裝在單一 Container

2. 以個別 Container 執行，獨立控制

3. 以個別 Container 執行，但使用 Docker Compose 關聯

實例

1. 安裝成單一 Container

2. ASP.NET Core、Nginx 各自跑 Container

3. 使用 Docker Compose 串連

練習

ASP.NET Core Docker 筆記 1 - 初探

Docker 相關介紹

Container

Docker Hub

Docker Container

Windows Container

練習

執行 Nginx Container

將 ASP.NET Core 專案包進 Container

將 Nginx 設成 ASP.NET Core 網站的 Reverse Proxy

Docker Compose 鏈接外部容器的幾種方式

不使用 Docker Compose

使用Docker Compose

docker-compose.yml

問題

方法一：讓需要鏈接的容器同屬一個外部網絡

docker-compose.yml

docker-compose.yml

方法二：更改需要鏈接的容器的網絡模式

docker-compose.yml

docker-compose.yml

10 個 Q&A 快速認識 Docker

練習：用 Docker 跑 MySQL