主持人 > 博客 > 管理 > Docker Compose：从开发到生产

Docker Compose：从开发到生产

为课程开始准备的播客转录翻译 《Linux 管理员》

Docker Compose：从开发到生产

Docker Compose 是一个令人惊叹的工具，用于创建工作
应用程序中使用的堆栈环境。 它允许您定义
应用程序的每个组件都遵循清晰简单的语法 YAML-
文件.

随着。的到来 码头工人组成v3 这些YAML文件可以在生产环境中直接使用
簇 码头工人.

但这是否意味着您可以在中使用相同的 docker-compose 文件
开发过程和生产环境？ 或者使用相同的文件
分期？ 嗯，一般来说，是的，但是对于此功能，我们需要以下内容：

  • 变量插值：使用环境变量进行某些
    每个环境都会改变的价值观。
  • 配置覆盖：能够定义第二个（或任何
    另一个后续的）docker-compose 文件将更改有关的内容
    首先，docker compose 将负责合并两个文件。

开发文件和生产文件之间的差异

在开发过程中，您很可能想要检查代码更改
即时的。 为此，通常将包含源代码的卷安装在
包含应用程序运行时的容器。 但对于生产环境
这种方法不适合。

在生产中，您有一个包含许多节点的集群，并且卷是本地的
相对于容器（或服务）运行的节点，因此您不需要
您可以挂载源代码，无需复杂的操作，包括
代码同步、信号等

相反，我们通常希望使用特定版本的代码创建图像。
习惯上用适当的标签来标记它（您可以使用语义
版本控制或其他系统由您自行决定）。

配置覆盖

鉴于差异以及您的依赖关系在场景中可能有所不同
开发和生产，很明显我们将需要不同的配置文件。

Docker compose 支持将不同的 compose 文件合并到
获得最终配置。 从示例中可以看出其工作原理：

$ cat docker-compose.yml
version: "3.2"

services:
  whale:
    image: docker/whalesay
    command: ["cowsay", "hello!"]
$ docker-compose up
Creating network "composeconfigs_default" with the default driver
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ________
whale_1  | < hello! >
whale_1  |  --------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

如前所述，docker compose 支持组合多个 compose -
文件，这允许您覆盖第二个文件中的各种参数。 例如：

$ cat docker-compose.second.yml
version: "3.2"
services:
  whale:
    command: ["cowsay", "bye!"]

$ docker-compose -f docker-compose.yml -f docker-compose.second.yml up
Creating composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

这种语法在开发过程中不太方便，当命令
需要进行多次。

幸运的是，docker compose 会自动寻找一个名为的特殊文件
docker-compose.override.yml 覆盖值 泊坞窗，compose.yml。 如果
重命名第二个文件，只需使用原始命令即可得到相同的结果：

$ mv docker-compose.second.yml docker-compose.override.yml
$ docker-compose up
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

好吧，这样更容易记住。

变量插值

配置文件支持 插值法
变量 和默认值。 也就是说，您可以执行以下操作：

services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
...

如果你这样做 docker-compose 构建（或推送） 没有环境变量
$MY_SERVICE_VERSION，该值将被使用 最新但如果你设置
构建前环境变量的值，构建或推送时将使用该值
到登记处 私有.registry.mine.

我的原则

对我有用的方法可能也对你有用。 我遵循这些
简单的规则：

  • 我所有用于生产、开发（或其他环境）的堆栈都是通过定义的
    docker-compose 文件
  • 配置文件需要尽可能覆盖我的所有环境
    避免重复。
  • 我需要一个简单的命令来在每种环境中工作。
  • 主要配置在文件中定义 泊坞窗，compose.yml.
  • 环境变量用于定义图像标签或其他
    变量可能因环境而异（暂存、集成、
    生产）。
  • 生产变量的值用作
    默认情况下，如果堆栈在生产环境中启动而无需
    设置环境变量。
  • 要在生产环境中启动服务，请使用命令 docker stack 部署 - compose-file docker-compose.yml -with-registry-auth my-stack-name.
  • 使用命令启动工作环境 码头工人组成up -d.

让我们看一个简单的例子。

# docker-compose.yml
...
services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
    environment:
      API_ENDPOINT: ${API_ENDPOINT:-https://production.my-api.com}
...

И

# docker-compose.override.yml
...
services:
  my-service:
    ports: # This is needed for development!
      - 80:80
    environment:
      API_ENDPOINT: https://devel.my-api.com
    volumes:
      - ./:/project/src
...

我可以用 docker-compose（docker-compose up）运行堆栈
源码挂载的开发模式 /项目/源代码.

我可以在生产中使用这些相同的文件！ 我绝对可以使用
相同的文件 泊坞窗，compose.yml 用于演出。 将此扩展为
生产，我只需要构建并发送带有预定义标签的图像
CI阶段：

export MY_SERVICE_VERSION=1.2.3
docker-compose -f docker-compose.yml build
docker-compose -f docker-compose.yml push

在生产中，可以使用以下命令运行：

export MY_SERVICE_VERSION=1.2.3
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

如果你想在舞台上做同样的事情，你只需要定义
在临时环境中工作所需的环境变量：

export MY_SERVICE_VERSION=1.2.3
export API_ENDPOINT=http://staging.my-api.com
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

结果，我们使用了两个不同的 docker-compose 文件，其中没有
重复配置可用于您拥有的任何环境！

了解有关课程的更多信息 《Linux 管理员》

来源： habr.com

添加评论