分布式应用程序捆绑包（Docker 1.12系列浏览）

与旧的编排和调度相比，Docker 1.12+中捆绑的新Swarm有了巨大的改进。 不再需要运行单独的Swarm容器集（它捆绑在Docker Engine中），故障转移策略更加可靠，引入了服务发现，新的网络就像一个魅力一样，依此类推。 功能和改进的清单很大。 如果您没有机会尝试一下，请阅读Docker Swarm介绍和将Proxy与Docker Swarm集成 。

在这些文章中，我们使用了命令在Swarm集群中运行Docker服务。 如果您像我一样，则可能已经习惯了Docker Compose提供的简单性。 与其尝试使用运行服务所需的所有参数来记住命令，您可能将所有内容都指定为Docker Compose文件，并使用简单的docker-compose up -d命令运行容器。 毕竟，这比docker service create无限个参数的docker service create要方便得多。 我的大脑没有能力记住所有人。

当我开始使用新的Swarm进行“演奏”时，我的第一印象是感觉很棒 ，其次我不想为所有服务记住不同的论点 。 我希望将Compose文件恢复到游戏中。

重大更改之一是容器管理已从客户端（ Docker Compose ）更改为服务器端（ Docker Service ）。 结果， Docker Compose已过时（至少在使用Docker Service部署容器时）。 它仍将是在单个服务器环境中运行容器的首选方法，但仅此而已。 那么，我们应该如何处理所有创建的docker-compose.yml文件？

好消息是我们可以使用分布式应用程序捆绑包或dab文件代替docker服务命令行参数。 坏消息是……让我们把它们保留到最后，并首先探索好的部分。

我们将从创建一个由Docker机器组成的演示Swarm集群开始。

环境设定

以下示例假定您具有包含Docker Engine v1.12 +的Docker Machine v0.8 +版本。 获得它们的最简单方法是通过Docker Toolbox 。

如果您是Windows用户，请运行Git Bash （通过Docker Toolbox安装）中的所有示例。

我不会详细介绍环境设置。 与Docker Swarm简介文章中的解释相同。 我们将设置三个节点，它们将组成Swarm集群。

docker-machine create -d virtualbox node-1

docker-machine create -d virtualbox node-2

docker-machine create -d virtualbox node-3

eval $(docker-machine env node-1)

docker swarm init \
    --advertise-addr $(docker-machine ip node-1) \
    --listen-addr $(docker-machine ip node-1):2377

TOKEN=$(docker swarm join-token -q worker)

eval $(docker-machine env node-2)

docker swarm join --token $TOKEN $(docker-machine ip node-1):2377

eval $(docker-machine env node-3)

docker swarm join --token $TOKEN $(docker-machine ip node-1):2377

具有三个节点的Docker Swarm集群

现在有了Swarm集群，我们可以使用dab文件部署服务了。

使用分布式应用程序捆绑包（DAB）部署服务

取而代之的是通过指定无数的参数来创建网络和Docker服务，我们将使用dab文件 。 将其视为与Docker Compose等效的Swarm。 Swarm是指1.12+版随附的docker docker swarm ，docker docker service和其他商品（不是旧Swarm作为单独的容器运行）。

我们将尝试从docker-compose.yml文件创建它，而不是尝试弄清楚用于指定服务的新格式的细节。

让我们从签出演示服务的代码开始。

git clone https://github.com/vfarcic/go-demo.git

cd go-demo

cat docker-compose.yml

最后一条命令输出Docker Compose项目定义。 如下。

version: '2'

services:

  app:
    image: vfarcic/go-demo
    ports:
      - 8080

  db:
    image: mongo

如您所见，这是一个非常简单的项目。 它包含两个服务。 应用程序服务是公开API的后端。 它使用第二个服务（ db ）存储和检索数据。 应用程序目标公开端口8080 ，它将用作其API的入口点。

将此Docker Compose定义转换为捆绑包是一个两步过程。 首先，我们需要提取图像。 捆绑软件的创建将对其进行评估，并与docker-compose.yml文件的内容一起输出一个dab文件。

让我们尝试一下。

eval $(docker-machine env node-1)

docker-compose pull

docker-compose bundle

现在，过程已完成，让我们看一下结果。

cat godemo.dab

输出如下。

{
  "Services": {
    "app": {
      "Image": "vfarcic/go-demo@sha256:f7436796b1cd6812ba63ea82c6523a5164ae7f8a3c05daa9e4ac4bd78341d709",
      "Networks": [
        "default"
      ],
      "Ports": [
        {
          "Port": 8080,
          "Protocol": "tcp"
        }
      ]
    },
    "db": {
      "Image": "mongo@sha256:e599c71179c2bbe0eab56a7809d4a8d42ddcb625b32a7a665dc35bf5d3b0f7c4",
      "Networks": [
        "default"
      ]
    }
  },
  "Version": "0.1"
}

我们刚刚创建的godemo.dab文件非常简单。 它包含两个与docker-compose.yml文件中的服务匹配的服务。 它们每个都指定了由我们提取的哈希定义的图像。 映像之后是默认网络，它将围绕服务和应打开的端口。

此输出至少存在两个问题。 首先，不需要打开任何端口。 相反，我们应该有一个反向代理，它将所有请求重定向到服务。 新的Docker Swarm网络使与代理的集成变得容易，我们应该加以利用。 请阅读将代理与Docker Swarm集成在一起的文章，以获取有关Swarm集群中代理角色的更多信息。

第二个问题是我们没有指定任何约束。 将不受约束的服务部署到群集可能会很快变成灾难。

可以在docker-compose-swarm.yml文件中看到一个更好但仍然非常简单的Compose定义。 其内容如下。

version: '2'

services:

  app:
    image: vfarcic/go-demo
    mem_limit: 250m

  db:
    image: mongo
    mem_limit: 500m

如您所见，我们删除了端口并添加了mem_limit约束。 仍然是一个非常简单的Compose文件。

让我们创建一个新的bundle输出。

docker-compose -f docker-compose-swarm.yml bundle

bundle命令的输出如下。

WARNING: Unsupported key 'mem_limit' in services.app - ignoring
WARNING: Unsupported key 'mem_limit' in services.db - ignoring
Wrote bundle to godemo.dab

现在我们来第一个坏消息。 当前的捆绑软件格式非常有限。 我们可以将其用于非常简单的场景。 一旦我们指定了更复杂的内容，我们将面临警告。 在这种情况下，将忽略内存限制。

让我们暂时搁置此限制，然后尝试部署新捆绑包。

docker deploy godemo

deploy命令的输出如下。

Loading bundle from godemo.dab
Creating network godemo_default
Creating service godemo_app
Creating service godemo_db

网络和服务均已创建。 我们可以通过列出所有服务来确认这一点。

docker stack ps godemo

您应该看到堆栈由两个服务组成，每个服务都部署在三个节点集群内的某个位置，并且当前状态设置为running 。 如果状态为其他状态，请稍等片刻，直到容器被拉出并重新运行命令。

但是，我们仍然面临缺少的功能。 我们的内存限制已被忽略，我们尚未创建外部网络代理并将应用程序服务附加到该代理 。

我们可以通过执行service update命令来解决这些缺陷。 例如，我们可以手动创建代理网络并将容器添加到其中。 我们还可以使用service update命令来设置内存限制。 但是，如果我们开始做所有这些事情，那么可能最好是不用捆绑软件。

现在做什么？

在您完全放弃捆绑包之前 ，请注意， 捆绑包处于实验阶段。 那只是即将发生的味道。 我们可以期待Swarm所提供的所有功能得到重大改进和全面支持。

问题是今天该怎么办。 我们可以采取几种方法。 一种是等待捆绑软件脱离实验阶段，并（希望）支持Docker Swarm提供的所有功能。 另一种方法是使用Whaleprint项目 。 它看起来像是具有其他功能（例如约束）的dab文件和Terraform使用的方法的混合。 这是一个非常有前途的项目。 但是，就像捆绑包一样 ，它仍处于起步阶段。

我希望本文能为您提供新Swarm前进方向的预览。 该捆绑包正在开发中，我们可以预期它将成为将服务部署到群集的可靠替代方案。 请不要因为它缺乏功能而灰心，而是将其视为即将推出的产品的蓝图。

现在，我建议您对分布式应用程序捆绑包保持警惕，并等待其成熟。 同时，通过命令操作Swarm集群或尝试Whaleprint项目。

下一个将致力于使用Docker Swarm进行零停机时间部署 。

翻译自: https://www.javacodegeeks.com/2016/08/distributed-application-bundles-tour-around-docker-1-12-series.html