下面首先来看各项新的功能特性：

• 内置编排机制:通常来讲，应用利用一个Docker Compose文件进行定义。此定义由多个被部署在不同主机上的容器共同构成。这种作法除了能够避免单点故障（简称SPOF）之外，也能够让应用具备弹性。目前包括Docker Swarm、Kubernetes以及Mesos在内的多种编排框架都允许大家对此类应用进行编排。不过现在我们又有了新的选择——Docker Engine如今迎来了内置编排机制。更多细节内容将在后文中进行说明。

• Service:现在大家可以利用docker service create 命令轻松创建一项复制且分布式的负载均衡服务。该应用可实现“理想状态”，例如运行三套Couchbase容器，并具备自我修复能力。Docker引擎能够确保必要容器数量始终运行于集群当中。如果某容器发生故障，那么另一容器将旋即启动。如果某台节点发生故障，则该节点上的容器会在另一节点上启动。稍后我们将详细说明其作用。

• 零配置安全性: Docker 1.12采用相互验证TLS，能够对swarm当中各节点间的通信内容进行验证、授权与加密。更多详尽内容将在后文中进行讨论。Docker Stack与分布式应用捆绑包:分布式应用捆绑包，或者简称DAB，是一种多服务可分发镜像格式。在后文中我们会进一步讨论。

截至目前，大家已经可以选定一个Dockerfile，并利用docker build命令由此创建镜像。使用docker run命令则可启动容器。这条命令亦能够轻松同时启动多套容器。另外，大家也可以使用Docker Compose文件并利用docker-compose scale命令对容器进行规模扩展。

镜像属于单一容器的一种便携式格式。而Docker 1.12当中新推出的分布式应用捆绑包，或者简称DAB，则属于一种新的概念，其专门面向多套容器的迁移需求。每个捆绑包都可作为stack在运行时中进行部署。

感兴趣的朋友可以前往 docker.com/dab 了解更多与DAB相关的内容。为了简单起见，在这里我们利用类比来进行说明：

Dockerfile -> 镜像 -> 容器Docker Compose -> 分布式应用捆绑包 -> Docker Stack

下面我们使用一个Docker Compose文件来创建DAB，并将其作为Docker Stack加以部署。

需要强调的是，这项实验性功能仅存在于1.12-RC2版本当中。

利用Docker Compose创建一个分布式应用捆绑包

Docker Compose CLI添加了一条新的bundle命令。下面来看其具体说明：

docker-compose bundle --helpGenerate a Docker bundle from the Compose file.Local images will be pushed to a Docker registry, and remote images will be pulled to fetch an image digest. Usage: bundle [options] Options: -o, --output PATH Path to write the bundle file to. Defaults to "
    
     .dsb".
    

现在，让我们选取一条Docker Compose定义并以此为基础创建DAB。以下为我们的Docker Compose定义内容：

version: "2"services: db:   container_name: "db"   image: arungupta/oreilly-couchbase:latest   ports:     -8091:8091     -8092:8092 -8093:8093 -11210:11210 web: image: arungupta/oreilly-wildfly:latest depends_on: -db environment: -COUCHBASE_URI=db ports: -8080:8080

此Compose文件会启动WildFly与Couchbase服务器。其中WildFly服务器中已经预部署了一款Java EE应用，且接入Couchbase服务器并允许利用REST API执行CRUD操作。该文件的源代码来自：github.com/arun-gupta/oreilly-docker-book/blob/master/hello-javaee/docker-compose.yml。 利用它生成一个应用捆绑包：

 

docker-compose bundleWARNING: Unsupported key 'depends_on' in services.web - ignoringWARNING: Unsupported key 'container_name' in services.db - ignoringWrote bundle to hellojavaee.dsb

depends_on只负责创建两项服务之间的依赖性，并以特定顺序对二者进行启动。这能确保Docker容器首先启动，而运行在其中的应用则需要更长时间才能启动完成。因此，此属性只在一定程度上解决了这一问题。

container_name能够为该容器提供一个特定名称。对特定容器名称的依赖性为紧密耦合，且不允许我们对该容器进行规模伸缩。因此这里我们暂时忽略这两条警告。此命令会利用Compose项目名（也就是其目录名称）生成一个文件。因此在本示例中，生成的文件名为hellojavaee.dsb。此文件的扩展名在RC3中则为.dab。此生成的应用捆绑包内容如下所示：

{ "services": {   "db": {     "Image": "arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c",      "Networks": [       "default"     ],      "Ports": [       {         "Port": 8091,          "Protocol": "tcp"       },        {         "Port": 8092,          "Protocol": "tcp"       },        {         "Port": 8093,          "Protocol": "tcp"       },        {         "Port": 11210,          "Protocol": "tcp"       }     ]   },    "web": {     "Env": [       "COUCHBASE_URI=db"     ],      "Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",      "Networks": [       "default"     ],      "Ports": [       {         "Port": 8080,          "Protocol": "tcp"       }     ]   } },  "version": "0.1"}

此文件为包含在应用内的各项服务提供完整的描述。当然，未来我们应该可以使用其它容器格式，例如Rkt或者VM等形式。不过就目前来讲，其还仅支持Docker这一种格式。

在Docker中进行Swarm Mode初始化

正如之前所提到，目前“理想状态”由Docker Swarm负责保持。而其现在已经被纳入Docker Engine当中。在本篇文章中，我们使用新增的一条命令，即docker swarm：

docker swarm --helpUsage: docker swarm COMMANDManage Docker SwarmOptions:     --help   Print usageCommands: init        Initialize a Swarm join        Join a Swarm as a node and/or manager update      Update the Swarm leave       Leave a Swarm inspect     Inspect the SwarmRun 'docker swarm COMMAND --help' for more information on a command.

在Docker Engine中对一个Swarm节点（作为工作节点）进行初始化：

docker swarm initSwarm initialized: current node (ek9p1k8r8ox7iiua5c247skci) is now a manager.

关于该节点的更多细节信息可利用docker swarm inspect命令进行查看。

docker swarm inspect[   {       "ID": "1rcvu7m9mv2c8hiaijr7an9zk",       "Version": {           "Index": 1895       },       "CreatedAt": "2016-07-01T23:52:38.074748177Z",       "UpdatedAt": "2016-07-02T04:54:32.79093117Z",       "Spec": {           "Name": "default",           "AcceptancePolicy":{               "Policies": [                   {                       "Role": "worker",                       "Autoaccept": true                   },                   {                       "Role": "manager",                       "Autoaccept":false                   }               ]           },           "Orchestration": {               "TaskHistoryRetentionLimit":10           },           "Raft": {               "SnapshotInterval": 10000,               "LogEntriesForSlowFollowers":500,               "HeartbeatTick":1,               "ElectionTick":3           },           "Dispatcher": {               "HeartbeatPeriod": 5000000000           },           "CAConfig": {               "NodeCertExpiry": 7776000000000000           }       }   }]

从输出结果中可以看到，该节点只属于工作节点而非管理节点。如果在单节点集群当中，这样的设置并无不妥。不过在多节点集群当中，则应至少存在一个管理节点。

部署Docker Stack

利用docker deploy命令创建一个stack：

docker deploy -f hellojavaee.dsb hellojavaeeLoading bundle from hellojavaee.dsbCreating network hellojavaee_defaultCreating service hellojavaee_dbCreating service hellojavaee_web

下面来看各服务列表：

docker service lsID            NAME             REPLICAS  IMAGE                 COMMAND2g8kmrimztes  hellojavaee_web  1/1       arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914    46xhlb15cc60  hellojavaee_db   1/1       arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c

在输出结果中，我们可以看到正在运行的两项服务，分别为WildFly与Couchbase。 Service概念同样新增于Docker 1.12版本，其负责为我们提供“理想状态”，而具体实现则由Docker Engine负责。使用docker ps命令显示当前正在运行的容器列表：

CONTAINER ID        IMAGE                                                                                                 COMMAND                  CREATED             STATUS              PORTS                                                        NAMES622756277f40        arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c   "/entrypoint.sh /opt/"   3 seconds ago       Up 1 seconds        8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp   hellojavaee_db.1.19enwdt6i5m853m5675tx3z29abf8703ed713        arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914     "/opt/jboss/wildfly/b"   3 seconds ago       Up 1 seconds        8080/tcp                                                     hellojavaee_web.1.70piloz6j4zt06co8htzisgyl

WildFly容器会在Couchbase容器启动并运行之前先行启动。这意味着Java EE应用会尝试接入Couchbase服务器但发生失败。因此，该应用将永远无法成功完成引导。

自我修复Docker Service

Docker Service负责保持应用的“理想状态”。在本示例中，我们的理想状态是确保特定服务有且只有一套容器与之对应且持续运行。如果我们移除该容器，而非服务，则该服务会自动重启容器。使用以下命令移除容器：

docker rm -f abf8703ed713

请注意，这里之所以要使用-f，是因为该容器已经处于运行状态。Docker 1.12自我修复机制会介入并自动重启此容器。现在再次打开运行容器列表：

CONTAINER ID        IMAGE                                                                                                 COMMAND                  CREATED             STATUS                  PORTS                                                        NAMESdb483ac27e41        arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914     "/opt/jboss/wildfly/b"   1 seconds ago       Up Less than a second   8080/tcp                                                     hellojavaee_web.1.ddvwdmojjysf46d4n3x4g8uv4622756277f40        arungupta/oreilly-couchbase@sha256:f150fcb9fca5392075c96f1baffc7f893858ba763f3c05cf0908ef2613cbf34c   "/entrypoint.sh /opt/"   26 seconds ago      Up 25 seconds           8091-8093/tcp, 11207/tcp, 11210-11211/tcp, 18091-18092/tcp   hellojavaee_db.1.19enwdt6i5m853m5675tx3z29

结果显示新容器已经启动完成。检查WildFly服务：

docker service inspect hellojavaee_web[   {       "ID": "54otfi6dc9bis7z6gc6ubynwc",       "Version": {           "Index": 328       },       "CreatedAt": "2016-07-02T01:36:35.735767569Z",       "UpdatedAt": "2016-07-02T01:36:35.739240775Z",       "Spec": {           "Name": "hellojavaee_web",           "Labels": {               "com.docker.stack.namespace": "hellojavaee"           },           "TaskTemplate": {               "ContainerSpec": {                   "Image": "arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914",                   "Env": [                       "COUCHBASE_URI=db"                   ]               }           },           "Mode": {               "Replicated": {                   "Replicas": 1               }           },           "Networks": [               {                   "Target": "epw57lz7txtfchmbf6u0cimis",                   "Aliases": [                       "web"                   ]               }           ],           "EndpointSpec": {               "Mode": "vip",               "Ports": [                   {                       "Protocol": "tcp",                       "TargetPort": 8080                   }               ]           }       },       "Endpoint": {           "Spec": {},           "Ports": [               {                   "Protocol": "tcp",                   "TargetPort": 8080,                   "PublishedPort": 30004               }           ],           "VirtualIPs": [               {                   "NetworkID": "9lpz688ir3pzexubkcb828ikg",                   "Addr": "10.255.0.5/16"               },               {                   "NetworkID": "epw57lz7txtfchmbf6u0cimis",                   "Addr": "10.0.0.4/24"               }           ]       }   }]

Swarm会将随机端口分配给该服务，我们也可以利用docker service update命令进行手动更新。在本示例中，容器的端口8080被映射至主机上的端口30004。

进行应用验证

下面检查该应用是否已经成功部署：

curl http://localhost:30004/books/resources/book[{"books":0}]

为该应用添加新的book：

再次验证该book:curl http://localhost:30004/books/resources/book    [{"books":{"name":"Minecraft Modding with Forge","cost":29.99,"id":"1","isbn":"978-1-4919-1889-0"}}, {"books":1}]