資訊專欄INFORMATION COLUMN
摘要：與分布式應用捆綁包分布式應用捆綁包，或者簡稱，是一種多服務可分發(fā)鏡像格式。而當中新推出的分布式應用捆綁包，或者簡稱，則屬于一種新的概念，其專門面向多套容器的遷移需求。利用創(chuàng)建一個分布式應用捆綁包添加了一條新的命令。
在本文中數(shù)人云將帶大家了解如何利用Docker Compose創(chuàng)建一套分布式應用捆綁包，并將其作為Docker Stack在Docker Swarm Mode中進行部署。
Docker 1.12的首套候選發(fā)行版于三周之前公布，而近期又有更多新功能計劃被添加至該版本當中。
下面首先來看各項新的功能特性：
內(nèi)置編排機制:通常來講，應用利用一個Docker Compose文件進行定義。此定義由多個被部署在不同主機上的容器共同構成。這種作法除了能夠避免單點故障（簡稱SPOF）之外，也能夠讓應用具備彈性。目前包括Docker Swarm、Kubernetes以及Mesos在內(nèi)的多種編排框架都允許大家對此類應用進行編排。不過現(xiàn)在我們又有了新的選擇——Docker Engine如今迎來了內(nèi)置編排機制。更多細節(jié)內(nèi)容將在后文中進行說明。
Service:現(xiàn)在大家可以利用docker service create 命令輕松創(chuàng)建一項復制且分布式的負載均衡服務。該應用可實現(xiàn)“理想狀態(tài)”，例如運行三套Couchbase容器，并具備自我修復能力。Docker引擎能夠確保必要容器數(shù)量始終運行于集群當中。如果某容器發(fā)生故障，那么另一容器將旋即啟動。如果某臺節(jié)點發(fā)生故障，則該節(jié)點上的容器會在另一節(jié)點上啟動。稍后我們將詳細說明其作用。
零配置安全性: Docker 1.12采用相互驗證TLS，能夠對swarm當中各節(jié)點間的通信內(nèi)容進行驗證、授權與加密。更多詳盡內(nèi)容將在后文中進行討論。
Docker Stack與分布式應用捆綁包:分布式應用捆綁包，或者簡稱DAB，是一種多服務可分發(fā)鏡像格式。在后文中我們會進一步討論。
截至目前，大家已經(jīng)可以選定一個Dockerfile，并利用docker build命令由此創(chuàng)建鏡像。使用docker run命令則可啟動容器。這條命令亦能夠輕松同時啟動多套容器。另外，大家也可以使用Docker Compose文件并利用docker-compose scale命令對容器進行規(guī)模擴展。
鏡像屬于單一容器的一種便攜式格式。而Docker 1.12當中新推出的分布式應用捆綁包，或者簡稱DAB，則屬于一種新的概念，其專門面向多套容器的遷移需求。每個捆綁包都可作為stack在運行時中進行部署。
感興趣的朋友可以前往 docker.com/dab 了解更多與DAB相關的內(nèi)容。為了簡單起見，在這里我們利用類比來進行說明：
Dockerfile -> 鏡像 -> 容器
Docker Compose -> 分布式應用捆綁包 -> Docker Stack
下面我們使用一個Docker Compose文件來創(chuàng)建DAB，并將其作為Docker Stack加以部署。
需要強調(diào)的是，這項實驗性功能僅存在于1.12-RC2版本當中。
利用Docker Compose創(chuàng)建一個分布式應用捆綁包Docker Compose CLI添加了一條新的bundle命令。下面來看其具體說明：
docker-compose bundle --help
Generate 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".
現(xiàn)在，讓我們選取一條Docker Compose定義并以此為基礎創(chuàng)建DAB。以下為我們的Docker Compose定義內(nèi)容：
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服務器中已經(jīng)預部署了一款Java EE應用，且接入Couchbase服務器并允許利用REST API執(zhí)行CRUD操作。該文件的源代碼來自：github.com/arun-gupta/oreilly-docker-book/blob/master/hello-javaee/docker-compose.yml。 利用它生成一個應用捆綁包：
docker-compose bundle WARNING: Unsupported key "depends_on" in services.web - ignoring WARNING: Unsupported key "container_name" in services.db - ignoring Wrote bundle to hellojavaee.dsb
depends_on只負責創(chuàng)建兩項服務之間的依賴性，并以特定順序對二者進行啟動。這能確保Docker容器首先啟動，而運行在其中的應用則需要更長時間才能啟動完成。因此，此屬性只在一定程度上解決了這一問題。
container_name能夠為該容器提供一個特定名稱。對特定容器名稱的依賴性為緊密耦合，且不允許我們對該容器進行規(guī)模伸縮。因此這里我們暫時忽略這兩條警告。此命令會利用Compose項目名（也就是其目錄名稱）生成一個文件。因此在本示例中，生成的文件名為hellojavaee.dsb。此文件的擴展名在RC3中則為.dab。此生成的應用捆綁包內(nèi)容如下所示：
{
"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"
}
此文件為包含在應用內(nèi)的各項服務提供完整的描述。當然，未來我們應該可以使用其它容器格式，例如Rkt或者VM等形式。不過就目前來講，其還僅支持Docker這一種格式。
在Docker中進行Swarm Mode初始化正如之前所提到，目前“理想狀態(tài)”由Docker Swarm負責保持。而其現(xiàn)在已經(jīng)被納入Docker Engine當中。在本篇文章中，我們使用新增的一條命令，即docker swarm：
docker swarm --help
Usage: docker swarm COMMAND
Manage Docker Swarm
Options:
--help Print usage
Commands:
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 Swarm
Run "docker swarm COMMAND --help" for more information on a command.
在Docker Engine中對一個Swarm節(jié)點（作為工作節(jié)點）進行初始化：
docker swarm init Swarm initialized: current node (ek9p1k8r8ox7iiua5c247skci) is now a manager.
關于該節(jié)點的更多細節(jié)信息可利用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
}
}
}
]
從輸出結果中可以看到，該節(jié)點只屬于工作節(jié)點而非管理節(jié)點。如果在單節(jié)點集群當中，這樣的設置并無不妥。不過在多節(jié)點集群當中，則應至少存在一個管理節(jié)點。
部署Docker Stack利用docker deploy命令創(chuàng)建一個stack：
docker deploy -f hellojavaee.dsb hellojavaee Loading bundle from hellojavaee.dsb Creating network hellojavaee_default Creating service hellojavaee_db Creating service hellojavaee_web
下面來看各服務列表：
docker service ls ID NAME REPLICAS IMAGE COMMAND 2g8kmrimztes 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版本，其負責為我們提供“理想狀態(tài)”，而具體實現(xiàn)則由Docker Engine負責。使用docker ps命令顯示當前正在運行的容器列表：
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 622756277f40 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.19enwdt6i5m853m5675tx3z29 abf8703ed713 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服務器但發(fā)生失敗。因此，該應用將永遠無法成功完成引導。
自我修復Docker ServiceDocker Service負責保持應用的“理想狀態(tài)”。在本示例中，我們的理想狀態(tài)是確保特定服務有且只有一套容器與之對應且持續(xù)運行。如果我們移除該容器，而非服務，則該服務會自動重啟容器。使用以下命令移除容器：
docker rm -f abf8703ed713
請注意，這里之所以要使用-f，是因為該容器已經(jīng)處于運行狀態(tài)。Docker 1.12自我修復機制會介入并自動重啟此容器?，F(xiàn)在再次打開運行容器列表：
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES db483ac27e41 arungupta/oreilly-wildfly@sha256:d567ade7bb82ba8f15a85df0c6d692d85c15ec5a78d8826dfba92756babcb914 "/opt/jboss/wildfly/b" 1 seconds ago Up Less than a second 8080/tcp hellojavaee_web.1.ddvwdmojjysf46d4n3x4g8uv4 622756277f40 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
結果顯示新容器已經(jīng)啟動完成。檢查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。
進行應用驗證下面檢查該應用是否已經(jīng)成功部署：
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}]
欲了解更多與此Java應用相關的信息，請訪問github.com/arun-gupta/oreilly-docker-book/tree/master/hello-javaee。
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://systransis.cn/yun/26665.html
摘要：利用分布式應用捆綁包簡稱部署服務相較于利用大量參數(shù)創(chuàng)建網(wǎng)絡及服務，這里我們選擇使用一個文件。 在Docker 1.12版本中，全新的Swarm捆綁包相較于原有編排及調(diào)度機制做出了巨大改進。它不再需要運行一組獨立的Swarm容器，這部分容器已經(jīng)被直接捆綁在Docker Engine當中，故障轉移策略更為可靠，服務發(fā)現(xiàn)機制實現(xiàn)內(nèi)置，新的網(wǎng)絡功能極為順暢……看起來很棒是不是？ 數(shù)人云這...
摘要：由于沒有了中心化的負載均衡器，集群不會因某臺機器異常而導致整個服務對外不可用，很好的避免了單點問題，同時也帶了可擴展性。 Mesos/Marathon 折騰久了，我們一直希望有機會深入到 Swarm 內(nèi)部一探究竟。 另外， Mesos 這一套東西雖然是久經(jīng)企業(yè)級考驗的， 但是安裝、部署和使用相對復雜，上手有門檻。同時，在今年的 DockerCon 上，內(nèi)置了Swarm 功能的 Dock...
摘要：雖然可以使用相同的方式部署應用到云端，使用外部負載均衡器，但動態(tài)添加或者減少負載均衡節(jié)點依舊是痛點。這對使用外部負載均衡器幫助巨大。 數(shù)人云今天帶來的本篇文章將分享Docker在應用程序生命周期每個階段中所扮演的角色，以及遷移到Swarm集群時需要考慮的問題。 利用Docker來開發(fā) Docker讓工作更輕松。如需要一個部署安裝MySQL數(shù)據(jù)庫，或者安裝Ghost,又或者Redis數(shù)據(jù)...
摘要：應該如何解決本文將給出若干提示，如何在生產(chǎn)環(huán)境中使用。路由匹配服務發(fā)現(xiàn)負載均衡跨容器通訊非?？煽俊Ｔ趩蝹€端口上運行一個服務，節(jié)點的任意主機都可以訪問，負載均衡完全在后臺實現(xiàn)。 上周數(shù)人云給大家分享了——《你可能需要的關于Docker Swarm的經(jīng)驗分享》今天給大家?guī)磉@位作者大大的后續(xù)文章——《Docker Swarm在生產(chǎn)環(huán)境中的進階指南》 當在本地開發(fā)環(huán)境中使用Docker，或者...
摘要：譯者按實踐中會發(fā)現(xiàn)，生產(chǎn)環(huán)境中使用單個節(jié)點是遠遠不夠的，搭建集群勢在必行。集群的網(wǎng)絡通信服務發(fā)現(xiàn)，負載均衡以及容器間通信非?？煽俊Ｘ撦d均衡也是由提供的。 譯者按: 實踐中會發(fā)現(xiàn)，生產(chǎn)環(huán)境中使用單個Docker節(jié)點是遠遠不夠的，搭建Docker集群勢在必行。然而，面對Kubernetes, Mesos以及Swarm等眾多容器集群系統(tǒng)，我們該如何選擇呢？它們之中，Swarm是Docker原...
閱讀 814·2021-11-09 09:47
閱讀 1607·2019-08-30 15:44
閱讀 1162·2019-08-26 13:46
閱讀 2134·2019-08-26 13:41
閱讀 1315·2019-08-26 13:32
閱讀 3800·2019-08-26 10:35
閱讀 3549·2019-08-23 17:16
閱讀 478·2019-08-23 17:07
