与旧的编排和调度相比,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
现在有了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进行零停机时间部署 。