發表文章

目前顯示的是有「docker-compose」標籤的文章

Bash Completion for Docker and Kubectl

有句話說的好:「工欲善其事,必先利其器」。使用 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/...

DTR Backend with S3-compatible Storage (Minio)

預設情況下,推送到 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 與 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 發展成熟,新的 ...

這個網誌中的熱門文章

Docker 環境下的 Proxy 配置