Autocruise

很多 Docker 子命令特別是查詢狀態類型的子命令，都有附帶 --filter 參數， 簡寫形式為 -f  ，參數後面接著條件句，根據條件句的內容來過濾輸出結果。條件句的語法是 key=value 形式組成。 在鍵(key)的部分，每個子命令可使用的並不一樣。請見下面參考資料。 當然不能忘記在 Linux 系統上，可以通過管道 ( | ) 及 grep 這種常見的組合來過濾輸出結果。而在 Windows Server 系統上，可以通過 PowerShell 命令行環境下的管道 ( | ) 及 Select-String 得到同樣結果。 然而，使用 filter 參數與通過作業系統工具程式仍然是有不一樣的場景。例如下面幾個常見且好用的 filter 參數範例。 範例一：列印 container 名字為 redis 的 container id $ docker ps --filter name=redis -q 較為複雜一點的，承上，找到 container id 之後，在此 container 裡面運行命令， $ docker container exec $(docker ps --filter name=redis -q) ls -l / 範例二：列印本機上所有未使用到(dangling)的 images $ docker image ls -f dangling=true 本機上未使用到(dangling)的 images 會呈現出來像是下面這樣，他們都是可刪除的， REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE <none>              <none>      ...

這裏介紹 5 個實用的Docker 命令，可用來清理 Docker 本機環境 (1) docker container prune  這個命令用來清理當前本機環境下不是在運行狀態下的 containers ，在一台主機下，長期使用 docker 進行開發工作，反反覆覆的建置測試，會在主機記憶體內留下很多停止狀態的 containers , 可以定期用這個命令清理。這個命令執行後會提示詢問是否要刪除： WARNING! This will remove all stopped containers. Are you sure you want to continue? [y/N] 按 y 鍵確認即可執行刪除。如果要放在 crontab 寫成腳本定期執行，則這樣寫 yes | docker container prune 或 docker container prune -f 就可以了。 (2) docker image prune  這個命令用來清理當前本機環境下沒有用到的 images (3) docker volume ls 這個命令用來清理當前本機環境下沒有用到的 volumes (4) docker network prune  這個命令用來清理當前本機環境下沒有被任何 containers 用到的 Docker 虛擬網路 (5) docker system prune     這個命令用來清理當前本機環境下沒有被用到的Docker 物件資料，包含上列的 containers, images, networks, volumes. 這個命令雖然方便，但是還是得小心，避免誤刪想要的資料。要根據自己的情況來斟酌使用。

Docker Context 補充說明 之前 提到的 docker context 與 docker build 子命令運作時會用到的 docker build context  不是同一件事情，曾經看過有其他的部落格作者把這兩名詞混淆在一起，意思上應該是指 docker  build context  文字上卻寫成 docker  context ，那不是正確的，因此再寫了這篇特別說明一下。 docker  build context  ：建置本文是位於指定本機目錄路徑或URL下的文件集合。這些文件在建置期間被發送到 Docker daemon，Docker daemon 可以在 image 文件系統中使用。 docker context ：是數種系統屬性的組合。它包含了端點配置資訊，TLS資訊，編配類型，以及 context 識別名稱。預設的Docker Context就是主機本身的 daemon。通過 docker context 的機制，可以用 Docker CLI 輕鬆地在多個容器叢集之間切換，並進行多個容器叢集的管理。

這篇文章介紹最新版本 Docker EE 3.0 的一個新功能命令：Docker Context，有了這個功能，便可以用 Docker CLI 輕鬆地在多個容器叢集之間切換，並進行多個容器叢集的管理。這裏指的容器叢集，可以是在地端也可以是在雲端的環境，可以是 Swarm 叢集也可以是 Kubernetes 叢集。 在早期的 Docker EE 版本，Docker Context 這個概念最早出現在 UCP bundle 的配置, 但那時不是很完整成熟。docker client 預設的Docker Context就是自己主機本身的 daemon。 UCP bundle 是一個包含着指向 UCP 叢集管理節點的 Docker Daemon 配置腳本集合體，可用來配置 docker client 以及 kubectl , 變更 client 端的 Docker Context 到叢集管理節點的 Docker Daemon ，利於從 CLI 方式管理叢集或是佈署應用程式到叢集上，UCP manager 會把這些配置腳本一整包做成 ZIP 壓縮包的形式提供下載。以上述舊版本而言，在切換Docker Context的時候，是以作業系統的層級，將腳本文件的變數內容進行估值，來達到環境變數變更的目的。可是這種做法，對單一叢集的切換是可以，但多個叢集的情況就不好用了；另外就是安全上可能有風險，設想如果其中一個環境變數被其他人以其他系統命令有意或無意的修改，Docker Context很容易就被破壞掉，client 端也就無法正常下命令對叢集操作。 最新版本的  Docker EE 3.0 推出 Docker Context，將相關物件進行了封裝，使得Docker Context能夠透過CLI的方式有效進行管理。 Docker Context 可以使單個 Docker CLI 輕鬆管理多個Swarm叢集或是多個 Kubernetes叢集以及多個單機版Docker節點。 單個Docker CLI可以具有多個Docker Context 。每個Docker Context都包含管理不同叢集或節點所需的所有端點和TLS安全資料。 使用 docker context 子命令可輕鬆配置這些Docker Context並在它們之間切換。 ...

有句話說的好：「工欲善其事，必先利其器」。使用 docker 或 kubectl 命令行工具的時候，往往會被很多子命令以及參數困擾。事先設定好 Completion 命令補齊完成功能，可以讓平日工作輕鬆些。 在之前幾篇文章有約略提到 Bash Completion ，但沒有詳細介紹，這篇文章專門說明在 Linux Bash Shell 環境下的設定方式。 一、關於 Docker 部分，可以進一步細分爲 docker 命令本身， docker-compose , docker-machine 三項, （1）docker 命令本身 下載內容 https://raw.githubusercontent.com/docker/cli/master/contrib/completion/bash/docker 並儲存在 /etc/bash_completion.d/docker 可用 curl 命令如下： $ sudo curl -L https://raw.githubusercontent.com/docker/cli/master/contrib/completion/bash/docker -o /etc/bash_completion.d/docker-completion 下次登入即可使用。 或是儲存在家目錄下 $HOME/bash_completion.d/docker , 然後在家目錄下的 .bashrc 文件加入下面指令後，下次登入即可使用 # $HOME/.bashrc # Docker client bash shell completion . $HOME/bash_completion.d/docker （2）docker-compose 專門針對 docker-compose 的命令補齊完成功能，是另外一段 bash 腳本， 可用 curl 命令下載： $ sudo curl -L https://raw.githubusercontent.com/docker/compose/1.18.0/contrib/completion/bash/docker-compose -o /etc/bash_completion.d/docker-compose 儲存在 /etc/...

經常有人來信提到這個問題，在這統一把這問題的解決方法做個說明。 在使用 docker pull 命令想要從 DTR (Docker Trusted Registry) 取出 image 的時候，碰到下列的錯誤訊息。 [root@dtr1]# docker pull dtr [dtr-url] Using default tag: latest Error response from daemon: Get https://registry-1.docker.io/v2/: x509: certificate has expired or is not yet valid 要讓每一個 Docker 節點，能夠順利使用 docker push / docker pull 命令存取 DTR ， 得讓那 Docker 節點能夠信任 DTR 節點的 TLS 憑證, 要取得 DTR CA 可通過 DTR API 下載下來，如以 curl 做範例： # curl -k https://[dtr-url] /ca -o [dtr-url].crt 然後把 crt 文件更新到作業系統的可信任的憑證清單內。每一作業系統更新配置憑證的方法都不一樣，將另外說明。 注意：上述提到的方法適用於 UCP 叢集內的每一個節點，不論是 manager 角色或 worker 角色。也可用在叢集外的任一 Docker 節點。 另外一種比較簡單但是不推薦的做法是修改 /etc/docker/daemon.json ，設定 DTR 的地址。 如果已經確定每一個 UCP 節點與 DTR 節點的整合已經完成，仍然有問題， 則可能是每個節點作業系統時間同步所導致。 要更新同步每個節點的時間，可以用 ntpd , 如果是比較新的版本的 RHEL / CentOS 則使用 chronyd , # chronyc sources # chronyc tracking 如果對外網際網路是連通的，或可直接在 crontab 填入 ntpdate 指令，後面加上外部上游 time server ，例如 # ntpdate time.stdtime.gov.tw 當每個節點作業系統時間正確同步之後，就可以順利使用 docker push 或 pull 命令存取 D...

預設情況下，推送到 DTR 保存的所有 images 都是在 DTR 當前主機的磁碟內。如果這個 DTR 出現任何嚴重問題無法運作，則外界無法對此 DTR 節點做存取 images。 爲了使得 DTR 在叢集中保持高可用性的狀態，必須設定更多的 DTR replicas，同時必須爲所有的 DTR 節點設定後端存儲。 我們可以利用 minio 作爲 DTR 後端存儲機制。minio 是一個分散式，容器化，同時兼容 S3 API 的資料庫。在爲 DTR 設定 minio 之前，下面先說明如何佈署 minio 在容器平台上。 建立 secrets 保存密碼存息，這是一個良好的實踐。 # 以 docker swarm 保管密碼訊息 $ echo "accesskey-example" | docker secret create access_key - $ echo "secretkey-example" | docker secret create secret_key - 編寫如下 docker-compose.yml 文件 # docker-compose.yml version: '3.3' services: minio1: image: minio/minio:edge hostname: minio1 environment: MINIO_REGION: 'my_region' deploy: restart_policy: delay: 10s max_attempts: 10 window: 60s placement: constraints: - node.labels.minio1==true volumes: - minio1-data:/export ports: - "9001:9000" networks: - minio_distributed command: server http...

docker-compose 與 docker stack deploy 兩者執行的動作都是可以讀取 docker compose yaml 純文字文件 (通常文件命名爲 docker-compose.yaml 或是 docker-compose.yml)，並且佈署應用程式到Docker平台上。 但是，兩者也有幾點差別： docker-compose 以 Python 腳本編寫， docker stack deploy 是 docker 命令的一個子命令，而 docker 主體使用 Go 語言編寫； docker-compose 是一個獨立的工具程式，常見的佈署執行命令 docker-compose pull; docker-compose up docker stack deploy 不是一個獨立的工具程式，是 命令行環境下 docker 主程式的一個子命令，常見的佈署執行命令 docker stack deploy -c docker-compose.yml stackname docker-compose 主要是在單一節點下，進行多個 container 所構成應用程式在單一主機下的佈署，無法利用到 Swarm 叢集的高可用性機制， docker stack deploy 是在多個節點構成的叢集上，進行多個 container 所構成應用程式的佈署，成功佈署上去的應用程式可以在 Swarm 叢集中充分利用高可用性機制； docker-compose 所讀取的 docker-compose.yaml 或是 docker-compose.yml 文件裏面定義的 compose 版本號，大都是 2 以下， docker stack deploy 所讀取的 docker-compose.yaml 或是 docker-compose.yml 文件裏面定義的 compose 版本號，大都是 3 以上； compose 版本號越新，可以使用的關鍵字越多越多樣化，在佈署機制上越見靈活，另外，compose 版本號在 2 以前的關鍵字，有部分在 compose 版本號 3 以後已經停用； 綜合以上所述，使用 docker stack deploy 來佈署應用程式一般來說是比較建議的。 未來，隨着 Docker EE 3.0 發展成熟，新的 ...

這篇文章說明 Linux 系統環境下 Docker client 的配置，關於 Credentials Store 的部分。Credentials Store 可用來以進階加密方式管理登入 registry 後的密碼，是一種增強 Docker client 安全性的措施。 docker login 命令用來在進行映像文件倉庫 ( image registry ) 操作 docker push/ docker pull 前的登入命令, docker login [registry-url] [registry-url] 可以是叢集內部私有的 image registry 例如像是 DTR (Docker Trusted Registry) 如果省略 [registry-url] ，那麼預設就是登入到官方 Docker Hub (https://hub.docker.com) 。 docker login 到 registry 的時候需要輸入帳號密碼。 如沒有先配置 credentials store，(預設情況是沒有配置的), 則每次 docker login 任意 registry 之後都會出現下列警告訊息， WARNING! Your password will be stored unencrypted in $HOME/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store 上述警告訊息意思時說用來登入 registry 的密碼已經被保存在家目錄下的 config.json 文件裡，但是是以非加密的形式保存。而那是不安全的。 與 docker login 命令相對的命令是 docker logout, 登出 registry ，這會移除保存在 config.json 文件內的密碼資料。 如果 docker login 但是後續沒有做 docker logout, 密碼資料就會一直保存在家目錄裏面的 config.json ，即使退出當前的 shell sessi...

如何在 Docker EE 環境下運用整合的 Kubernetes orchestration 做 HPA (Horizontal Pod Autoscaler) 功能? 以下操作皆在 LINUX 環境下運行. 現有一個已建立好的 Docker EE UCP 叢集, 並且已經將設定好帶有 administration 權限的 client bundle 下載在客戶主機並在一個已開啓的 terminal 操作. Docker EE 引擎版本是: # docker version Client: Version: 18.09.3 API version: 1.39 Go version: go1.10.6 Git commit: 142dfce Built: Thu Feb 28 06:08:17 2019 OS/Arch: linux/amd64 Experimental: true Server: Docker Enterprise 2.1 Engine: Version: 18.09.5 API version: 1.39 (minimum version 1.12) Go version: go1.10.8 Git commit: be4553c Built: Thu Apr 11 06:23:08 2019 OS/Arch: linux/amd64 Experimental: false Universal Control Plane: Version: 3.1.4 ApiVersion: 1.39 Arch: amd64 BuildTime: Wed Feb 27 22:26:43 UTC 2019 GitCommit: 29b16f9 GoVersion: go1.10.6 MinApiVersion: 1.20 Os: ...

關於 Docker 環境下的 Proxy 配置，需要先根據問題具體情況分辨配置方法，有兩種：一個是 docker daemon 的配置，這主要是為了能讓 docker host 通過 proxy server 使用 docker pull/docker run 存取遠端 registry；另一個是 docker client 為了建置 image 或運行 container 的時候所需要的網路配置。 首先快速回顧一下 Linux 作業系統中命令行環境的 proxy 配置方法，以 CentOS 系統環境為例，假設一台 HTTPS proxy server 位在 192.168.1.34 而且 port 是 3128： # environment variables for https proxy # export https_proxy="https://192.168.1.34:3128/" 如果 Proxy server 需要輸入帳號密碼，則用下面這樣的形式 # Https proxy with authentication # export https_proxy="https://username:password@192.168.1.34:3128/" 之後 ping 8.8.8.8 看看Internet是否有連通，可以的話就可在 shell 環境下使用軟體包管理器像是 yum, apt-get 等等，安裝新的軟體，但是，同樣的作業系統環境變數設定對於 Docker 引擎不起作用。 Docker 環境下的 Proxy 配置，根據問題具體情況分為 docker daemon 以及 docker client 的配置，下面分別詳細說明。以下方法可適用在 Docker CE 或 Docker EE 17.06 以上的版本。 （一）Docker daemon 的 proxy 配置 如果 Docker host 處於 air-gapped 的環境下，需要先配置 proxy 才能連到 Internet，否則直接用 docker pull 或相關的命令從遠端 registry 來存取 docker images 會遭遇失敗。 以 CentOS，RedHat, Debian, Ubun...

FaaS （Function As A Service）是允許客戶開發，運行和管理應用程序功能的一個平台，客戶無需費太多心力建置和維護與開發和啟動應用程序相關以及基礎架構相關的複雜性問題。FaaS 通常運用在微服務應用程序領域，依賴 FaaS 平台模塑建置出的應用程序是實現 serverless 微服務架構的一種方法。而 OpenFaas 是由 Alex Ellis 發起的一個開源專案，藉由 OpenFaaS ® 客戶幾乎可以封裝任何應用程序功能作為一個 serverless 微服務應用。OpenFaaS 可以部署在 Kubernetes 或是 Docker Swarm 環境中。 這篇文章介紹如何在 Docker EE UCP cluster 環境裡以 Docker Swarm 來部署建置 OpenFaas，並且進一步利用 OpenFaas 來部署 serverless 應用程式在 Docker EE UCP cluster 環境裡。 Docker EE 的環境類似之前情況，這裡不再贅述，詳情請參閱本部落格前幾篇 posts。 OpenFaaS 的 docker-compose.yml 文件可以從 Github 取得， # clone the codes of openfaas $ git clone https://github.com/openfaas/faas 喜歡使用命令行的朋友， OpenFaas CLI 可以透過下列命令取得，將會有一個 faas-cli 運行文件存放在 /usr/local/bin # download and install faas-cli $ curl -sSL https://cli.openfaas.com | sudo sh x86_64 Downloading package https://github.com/openfaas/faas-cli/releases/download/0.7.7/faas-cli as /tmp/faas-cli Download complete. Running as root - Attempting to move faas-cli to /usr/local/bin New version of faas-cli installed to /usr/lo...

Helm 是 Kubernetes 環境下的軟體包管理工具。可以這樣想像，Kubernetes 環境下的 Helm 猶如作業系統 CentOS 中的 yum. Helm使用稱為 chart 的軟體包格式，裡面包含描述 Kubernetes 應用程式資源的純文字文件，可用來部署簡單的內容例如 memcached pod，或者複雜的內容例如 HTTP server，DB，cache 等完整 Web 應用程序堆疊。Docker 容器化將單一程式封裝到單一個映像檔中，而 Helm 將整合一支應用系統所包含的多個微服務程式各自的映像檔(image)，及相關資源配置，打包到單一應用程式軟體包中封裝，且基於 chart 軟體包格式來做 Kubernetes 應用程式的分發散佈，如此更符合大型企業應用的需求。 Helm 由兩部分組成，客戶端 helm 和服務端 tiller： helm 是安裝在本地 docker host 運行的一个命令行工具； tiller 安裝運行在 Kubernetes cluster 上，管理部署在 Kubernetes cluster 的 chart 軟體包， Docker EE 2.0 cluster 支援 Kubernetes 的編配, 在 Docker EE 環境下安裝 Helm 是有可能完成的，這篇文章詳細介紹如何在 Docker EE 環境下安裝 Helm （包含以上提到的 helm 客戶端以及 tiller 服務端兩者）並進而利用 Helm 來部署 K8s 應用程式。 實驗開始前已經先建立好 Docker EE UCP cluster, (關於如何建立 Docker EE UCP cluster 請參閱其他文章), 本次所使用的 Docker EE 引擎以及 kubectl 版本如下所示： $ docker version Client: Docker Enterprise Edition (EE) 2.0 Version: 17.06.2-ee-16 API version: 1.30 Go version: go1.8.7 Git commit: 9ef4f0a Built: Thu Jul 26 16:41:28 2018 OS/Arch: linux/amd64 S...

Service Mesh 指的是在2016年由 Buoyant 公司所提出的 Linkerd 框架當中蘊含的一個核心技術概念，目的在解決微服務架構以及容器化服務所衍生出來的網路和安全問題。它在分散式系統中涵蓋了動態鏈接過程，提供安全，快速，可靠的服務間通訊。 如何設計好服務間通訊在微服務架構中是一項挑戰。分散式系統中，會有許多四處移動的跨多伺服器或主機的服務，軟體元件難免會遭遇異常情況。因為會發生部分失敗甚至導致更大範圍的中斷問題，所以設計微服務架構和服務間通訊的時候，需要將這類分散式系統的常見風險列入考量。 關於服務間通訊常見的實現方法大致會有：一個直接較容易實作的方法是以 HTTP (REST) 為基礎，但有 blocking 以及效能低的缺點；第二，採用非同步通訊協定，例如 AMQP。在應用程式代碼實作上相對比較複雜，並搭配運用 側車(sidecar)模式 以及 大使(Ambassador)模式 來處理訊息重送和熔斷訊息斷路機制；最後，運用 Service Mesh 框架。 藉由運用 Service Mesh 框架，開發人員可以專注在自己開發的應用程式碼邏輯，不需要太擔心要如何用代碼處理雲環境或是容器平台上高度複雜的服務間通訊狀況，應用程式代碼不會與通訊代碼過度耦合，而又同時能通過 Service Mesh 框架來管理雲環境或容器平台內部的服務間通訊的正確性，可靠性，以及確保一定程度的通訊效能。當前最常見的分散式系統就是微服務，簡單來說，Service Mesh 就如同是微服務的動態鏈接器（dynamic linker）。 當前常見的 Service Mesh 框架有：Google 主導的 Istio ；以及 Buoyant 公司所提出的 Linkerd ， 後來 Buoyant 公司參考 Istio 架構又另外推出一個輕量型的 Service Mesh 框架: Conduit，Conduit 後來再整合到 linnkerd, 作為 Linkerd2。Nginx 也有推出類似的方案。 這裡主要先以 linkerd 為例說明 Service Mesh 框架與 Docker EE 平台的整合。 要在 Docker EE 環境下部署 linkerd 有兩種方式: 一、以 docker run 命令運行 linkerd image, 在本...

R-Studio 是 R 語言的一個整合開發環境. 一般情況下，使用如下命令可以在Docker主機上運行一個 R-Studio container, # create and run a rstudio container $ docker run --rm --name rstudio -dit -p 8787:8787 rocker/rstudio:3.4.0 接下來，同一台主機上打開瀏覽器輸入 http://localhost:8787 可以看到類似如下登入畫面： username: rstudio password: rstudio 登入後，在主機上就可以開始通過瀏覽器來打開 R-Studio IDE 畫面進行 R 程式開發。 在個人電腦上一個人這樣使用是OK的。 曾經有人問過一個問題：可不可以在同一臺（擁有豐沛硬體資源的）主機上建立多個 R-Studio container 讓多人連線進來使用而且彼此又不會互相干擾到資料或代碼呢？ 答案是可以的, 但有一些地方需要留意. 方法如下: 先爲每一個主機上的使用者建立目錄, 記下這個使用者在系統上的的user id (可以通過主機上的 vigr 系統命令查看變更); 然後爲每一使用者指定一個遠端可存取的 HTTP port ; 接着通過下列命令建立新的 container 的同時, 綁定對應的 HTTP port 以及資料目錄, $ docker run -dit --rm \ -p {user-ports}:8787 -v {user-home-dir}/R:/home/rstudio/R -e USERID={host-user-id} \ --name rstudio-{user-name} rocker/rstudio:3.4.0 需要注意的地方是, 必須傳入一個環境變數 (USERID) 給 rstudio, 是當前這個主機的一使用者的 user id, 如前所述, 可以通過主機上的 vigr 系統命令查看. 如果不加這個環境變數即使每個container有不同的volume綁定仍是無法正常運行的! 舉個例子，假設有一個 user, 在主機上的 username 是 hans, 對應的 user id 是 1003，爲 hans 開放存取的 HT...

Play with Docker（PWD） 是由 Marcos Liljedhal 和 Jonathan Leibiusky 鑽研構思出來並由 Docker Inc. 贊助的開源專案。 PWD 提供給一般使用者一個悠遊學習Docker的操場，允許使用者敏捷的執行各種Docker命令，且可以在瀏覽器中輕易的建立和運行多個Docker容器，甚至可以在Docker Swarm模式下創建cluster. 事實上，PWD使用 Alpine Linux 為基礎的container，以Docker-in-Docker（DinD）提供使用者 貌似 有多個 VM/PC 同時在運行的體驗。Docker-in-Docker（DinD）簡單來說就是在一個 Docker container 環境內運行一個新的 Docker 實體。Play with Docker（PWD）運用了這樣的技術來模擬多個 VM 節點運行的效果。在這樣的模擬環境下，跑一些不會消耗太多資源的小應用還是可以的。真正大規模的應用程式部署運行，還是要找實際的 Data Center 來做才好。 只要能夠上網，透過Play with Docker（PWD）網站來練習Docker命令很方便。但有些時候，如果Internet網路連接有問題，或有時候正好碰到Play with Docker（PWD）網站比較多人在使用導致延遲無法順利連接，怎麼辦呢？ 可以下載源代碼，在自己的電腦上建置一個一模一樣的Play with Docker（PWD），當想要用的時候就可以建置部署，不要用的時候就撤掉不會浪費電腦資源。 經過多次實驗，下面內容是自己整理出來的可行做法。 作業系統環境： Ubuntu 16.04 Docker 引擎版本：Docker EE 17.06 安裝 go-lang $ apt update; apt install golang-go 取得 play with docker 代碼 $ git clone https://github.com/play-with-docker/play-with-docker.git 在原代碼目錄 play-with-docker 下，建立目錄 $ cd play-with-docker && mkdir -p ~/.go ~/....

這篇介紹如何在 Docker 環境下安裝 Odoo (v11) 以及後端對應的 PostgreSQL (v11). 首先，建立 Docker overlay 網路，它將用來連接Odoo以及PGSQL，網路名字叫 odoo-net $ docker network create odoo-net 建立所需的 volume, 並把資料保存於本機上目錄，方便未來移轉或備份。有下列三個： $ docker volume create pgdata # pgsql 資料庫用 $ docker volume create odoo-data # Odoo 本身配置資料 $ docker volume create odoo-addons # Odoo add-ons 資料 先啟動 PostgreSQL container $ docker run -dit --rm --name odoo-db \ -e POSTGRES_USER=odoo -e POSTGRES_PASSWORD=odoopassword \ --network=odoo-net -v pgdata:/var/lib/postgresql/data postgres:11 運行下列命令，找出運行時期 odoo-db 的 IP address, 把它記下來（這裡假設是 172.18.0.2），之後會用到： docker container inspect odoo-db 啟動 Odoo container （請自行更換下列 DB 的 IP address） # Please replace 172.18.0.2 with yours $ docker run -dit --rm --name odoo \ -p 8069:8069 -e POSTGRES_PASSWORD=odoopassword \ --network=odoo-net --add-host="db:172.18.0.2" \ -v odoo-data:/var/lib/odoo -v odoo-addons:/mnt/extra-addons odoo:11 請留意上述命令。這裡不用 --link 參數鏈接DB，在較新版本的 Docker...

Windows Server 必須是 2016 或更新的版本才可在上面安裝 Docker EE引擎。 以 Administrator 權限身份，打開 PowerShell, 輸入下列命令進行引擎安裝 $ Install-Module DockerProvider -Force $ Install-Package Docker -ProviderName DockerProvider -Force 重新啟動系統 $ Restart-Computer 啟動 Docker 命令： $ Start-Service Docker 或是在系統管理中，找到 docker 服務，並且改為開機自動啟動選項。 如果是在 air-gapped 環境下，上述做法不可行。可以先在外部工作機下載 zip 文件， https://download.docker.com/components/engine/windows-server/19.03/docker-19.03.1.zip 再拷貝到內部伺服器主機中，依序執行下列命令完成安裝。也可以先將下列命令單獨寫成 PowerShell 腳本文件，配合下載好的 Docker ZIP 文件，批次完成安裝作業。 # Extract the archive. Expand-Archive docker-19.03.1.zip -DestinationPath $Env:ProgramFiles -Force # Clean up the zip file. # Remove-Item -Force docker-19.03.1.zip # Install Docker. This requires rebooting. $null = Install-WindowsFeature containers # Add Docker to the path for the current session. $env:path += ";$env:ProgramFiles\docker" # Optionally, modify PATH to persist across sessions. $newPath = "$env:ProgramFiles\docker;...

這裡說明 Internet 是可用的情況進行 Docker EE UCP v2.x 安裝, 若是可以使用 proxy 連接，請先做作業系統關於proxy的設定。 Docker引擎版本：17.06 UCP版本：2.2.4 請先確認合適的Docker引擎已經安裝在主機上。 下載 UCP $ docker pull docker/ucp:2.2.4 確認 UCP 已經在本地主機上 $ docker image ls | grep ucp 運行如下命令開始安裝： $ docker container run --rm -it --name ucp \ -v /var/run/docker.sock:/var/run/docker.sock \ docker/ucp:2.2.4 install \ --host-address --interactive 在這裡： <host-ip-addr> 是安裝有 Docker 引擎的主機的 IP 地址 --interactive     以互動模式來進行UCP安裝 輸入上述命令之後，會開始下載UCP其他必要的元件，並且以互動模式來進行UCP安裝，過程中會要求輸入 SAN，以及UCP所需的username 以及 password. 安裝好後，開啟瀏覽器（建議用Firefox或Google Chrome）打開網址 https://<host-ip-addr> 之後登入安裝時所設定的 username 以及 password. 載入 license，即可看到UCP dashboard畫面 下面略述在安裝過程中可能遇到的幾個常見問題以及其可能的解決方法： (1) 如果看到如下 Error 訊息： FATA[0040] the following required ports are blocked on your host: 12380, 12376, 12384, 12387, 12381, 12382, 12383, 12379, 443, 2376, 12385, 12386. Check your firewall settings 可能原因與解決方法：主要可能是防火牆設定不正確，建議...

在這裡說明如何在 Ubuntu 16.04 (Xenial) 系統環境來安裝Docker CE引擎。 在 Linux 安裝 Docker CE 引擎，需確認 Linux kernel 版本必須要在 3.10 以上。 安裝之前，如果有舊的 Docker 版本必須先移除。 $ sudo apt-get remove docker.io 更新 $ sudo apt-get update 設定使用 stable 版本的軟體倉庫 $ sudo apt-get install \ apt-transport-https \ ca-certificates \ curl \ software-properties-common $ sudo apt-get update 安裝最新版本的 Docker $ apt-get install docker-ce 確認安裝結果 $ docker version 【參考資料】 https://docs.docker.com/v17.09/engine/installation/