摘要:與分布式應(yīng)用捆綁包分布式應(yīng)用捆綁包,或者簡稱,是一種多服務(wù)可分發(fā)鏡像格式。而當(dāng)中新推出的分布式應(yīng)用捆綁包,或者簡稱,則屬于一種新的概念,其專門面向多套容器的遷移需求。利用創(chuàng)建一個分布式應(yīng)用捆綁包添加了一條新的命令。
在本文中數(shù)人云將帶大家了解如何利用Docker Compose創(chuàng)建一套分布式應(yīng)用捆綁包,并將其作為Docker Stack在Docker Swarm Mode中進(jìn)行部署。
Docker 1.12的首套候選發(fā)行版于三周之前公布,而近期又有更多新功能計劃被添加至該版本當(dāng)中。
下面首先來看各項(xiàng)新的功能特性:
內(nèi)置編排機(jī)制:通常來講,應(yīng)用利用一個Docker Compose文件進(jìn)行定義。此定義由多個被部署在不同主機(jī)上的容器共同構(gòu)成。這種作法除了能夠避免單點(diǎn)故障(簡稱SPOF)之外,也能夠讓應(yīng)用具備彈性。目前包括Docker Swarm、Kubernetes以及Mesos在內(nèi)的多種編排框架都允許大家對此類應(yīng)用進(jìn)行編排。不過現(xiàn)在我們又有了新的選擇——Docker Engine如今迎來了內(nèi)置編排機(jī)制。更多細(xì)節(jié)內(nèi)容將在后文中進(jìn)行說明。
Service:現(xiàn)在大家可以利用docker service create 命令輕松創(chuàng)建一項(xiàng)復(fù)制且分布式的負(fù)載均衡服務(wù)。該應(yīng)用可實(shí)現(xiàn)“理想狀態(tài)”,例如運(yùn)行三套Couchbase容器,并具備自我修復(fù)能力。Docker引擎能夠確保必要容器數(shù)量始終運(yùn)行于集群當(dāng)中。如果某容器發(fā)生故障,那么另一容器將旋即啟動。如果某臺節(jié)點(diǎn)發(fā)生故障,則該節(jié)點(diǎn)上的容器會在另一節(jié)點(diǎn)上啟動。稍后我們將詳細(xì)說明其作用。
零配置安全性: Docker 1.12采用相互驗(yàn)證TLS,能夠?qū)warm當(dāng)中各節(jié)點(diǎn)間的通信內(nèi)容進(jìn)行驗(yàn)證、授權(quán)與加密。更多詳盡內(nèi)容將在后文中進(jìn)行討論。
Docker Stack與分布式應(yīng)用捆綁包:分布式應(yīng)用捆綁包,或者簡稱DAB,是一種多服務(wù)可分發(fā)鏡像格式。在后文中我們會進(jìn)一步討論。
截至目前,大家已經(jīng)可以選定一個Dockerfile,并利用docker build命令由此創(chuàng)建鏡像。使用docker run命令則可啟動容器。這條命令亦能夠輕松同時啟動多套容器。另外,大家也可以使用Docker Compose文件并利用docker-compose scale命令對容器進(jìn)行規(guī)模擴(kuò)展。
鏡像屬于單一容器的一種便攜式格式。而Docker 1.12當(dāng)中新推出的分布式應(yīng)用捆綁包,或者簡稱DAB,則屬于一種新的概念,其專門面向多套容器的遷移需求。每個捆綁包都可作為stack在運(yùn)行時中進(jìn)行部署。
感興趣的朋友可以前往 docker.com/dab 了解更多與DAB相關(guān)的內(nèi)容。為了簡單起見,在這里我們利用類比來進(jìn)行說明:
Dockerfile -> 鏡像 -> 容器
Docker Compose -> 分布式應(yīng)用捆綁包 -> Docker Stack
下面我們使用一個Docker Compose文件來創(chuàng)建DAB,并將其作為Docker Stack加以部署。
需要強(qiáng)調(diào)的是,這項(xiàng)實(shí)驗(yàn)性功能僅存在于1.12-RC2版本當(dāng)中。
利用Docker Compose創(chuàng)建一個分布式應(yī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定義并以此為基礎(chǔ)創(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服務(wù)器。其中WildFly服務(wù)器中已經(jīng)預(yù)部署了一款Java EE應(yīng)用,且接入Couchbase服務(wù)器并允許利用REST API執(zhí)行CRUD操作。該文件的源代碼來自:github.com/arun-gupta/oreilly-docker-book/blob/master/hello-javaee/docker-compose.yml。 利用它生成一個應(yīng)用捆綁包:
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只負(fù)責(zé)創(chuàng)建兩項(xiàng)服務(wù)之間的依賴性,并以特定順序?qū)Χ哌M(jìn)行啟動。這能確保Docker容器首先啟動,而運(yùn)行在其中的應(yīng)用則需要更長時間才能啟動完成。因此,此屬性只在一定程度上解決了這一問題。
container_name能夠?yàn)樵撊萜魈峁┮粋€特定名稱。對特定容器名稱的依賴性為緊密耦合,且不允許我們對該容器進(jìn)行規(guī)模伸縮。因此這里我們暫時忽略這兩條警告。此命令會利用Compose項(xiàng)目名(也就是其目錄名稱)生成一個文件。因此在本示例中,生成的文件名為hellojavaee.dsb。此文件的擴(kuò)展名在RC3中則為.dab。此生成的應(yīng)用捆綁包內(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" }
此文件為包含在應(yīng)用內(nèi)的各項(xiàng)服務(wù)提供完整的描述。當(dāng)然,未來我們應(yīng)該可以使用其它容器格式,例如Rkt或者VM等形式。不過就目前來講,其還僅支持Docker這一種格式。
在Docker中進(jìn)行Swarm Mode初始化正如之前所提到,目前“理想狀態(tài)”由Docker Swarm負(fù)責(zé)保持。而其現(xiàn)在已經(jīng)被納入Docker Engine當(dāng)中。在本篇文章中,我們使用新增的一條命令,即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é)點(diǎn)(作為工作節(jié)點(diǎn))進(jìn)行初始化:
docker swarm init Swarm initialized: current node (ek9p1k8r8ox7iiua5c247skci) is now a manager.
關(guān)于該節(jié)點(diǎn)的更多細(xì)節(jié)信息可利用docker swarm inspect命令進(jìn)行查看。
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é)點(diǎn)只屬于工作節(jié)點(diǎn)而非管理節(jié)點(diǎn)。如果在單節(jié)點(diǎn)集群當(dāng)中,這樣的設(shè)置并無不妥。不過在多節(jié)點(diǎn)集群當(dāng)中,則應(yīng)至少存在一個管理節(jié)點(diǎn)。
部署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
下面來看各服務(wù)列表:
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
在輸出結(jié)果中,我們可以看到正在運(yùn)行的兩項(xiàng)服務(wù),分別為WildFly與Couchbase。 Service概念同樣新增于Docker 1.12版本,其負(fù)責(zé)為我們提供“理想狀態(tài)”,而具體實(shí)現(xiàn)則由Docker Engine負(fù)責(zé)。使用docker ps命令顯示當(dāng)前正在運(yùn)行的容器列表:
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容器啟動并運(yùn)行之前先行啟動。這意味著Java EE應(yīng)用會嘗試接入Couchbase服務(wù)器但發(fā)生失敗。因此,該應(yīng)用將永遠(yuǎn)無法成功完成引導(dǎo)。
自我修復(fù)Docker ServiceDocker Service負(fù)責(zé)保持應(yīng)用的“理想狀態(tài)”。在本示例中,我們的理想狀態(tài)是確保特定服務(wù)有且只有一套容器與之對應(yīng)且持續(xù)運(yùn)行。如果我們移除該容器,而非服務(wù),則該服務(wù)會自動重啟容器。使用以下命令移除容器:
docker rm -f abf8703ed713
請注意,這里之所以要使用-f,是因?yàn)樵撊萜饕呀?jīng)處于運(yùn)行狀態(tài)。Docker 1.12自我修復(fù)機(jī)制會介入并自動重啟此容器。現(xiàn)在再次打開運(yù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
結(jié)果顯示新容器已經(jīng)啟動完成。檢查WildFly服務(wù):
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會將隨機(jī)端口分配給該服務(wù),我們也可以利用docker service update命令進(jìn)行手動更新。在本示例中,容器的端口8080被映射至主機(jī)上的端口30004。
進(jìn)行應(yīng)用驗(yàn)證下面檢查該應(yīng)用是否已經(jīng)成功部署:
curl http://localhost:30004/books/resources/book [{"books":0}]
為該應(yīng)用添加新的book:
再次驗(yàn)證該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應(yīng)用相關(guān)的信息,請訪問github.com/arun-gupta/oreilly-docker-book/tree/master/hello-javaee。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/26665.html
摘要:利用分布式應(yīng)用捆綁包簡稱部署服務(wù)相較于利用大量參數(shù)創(chuàng)建網(wǎng)絡(luò)及服務(wù),這里我們選擇使用一個文件。 在Docker 1.12版本中,全新的Swarm捆綁包相較于原有編排及調(diào)度機(jī)制做出了巨大改進(jìn)。它不再需要運(yùn)行一組獨(dú)立的Swarm容器,這部分容器已經(jīng)被直接捆綁在Docker Engine當(dāng)中,故障轉(zhuǎn)移策略更為可靠,服務(wù)發(fā)現(xiàn)機(jī)制實(shí)現(xiàn)內(nèi)置,新的網(wǎng)絡(luò)功能極為順暢……看起來很棒是不是? 數(shù)人云這...
摘要:由于沒有了中心化的負(fù)載均衡器,集群不會因某臺機(jī)器異常而導(dǎo)致整個服務(wù)對外不可用,很好的避免了單點(diǎn)問題,同時也帶了可擴(kuò)展性。 Mesos/Marathon 折騰久了,我們一直希望有機(jī)會深入到 Swarm 內(nèi)部一探究竟。 另外, Mesos 這一套東西雖然是久經(jīng)企業(yè)級考驗(yàn)的, 但是安裝、部署和使用相對復(fù)雜,上手有門檻。同時,在今年的 DockerCon 上,內(nèi)置了Swarm 功能的 Dock...
摘要:雖然可以使用相同的方式部署應(yīng)用到云端,使用外部負(fù)載均衡器,但動態(tài)添加或者減少負(fù)載均衡節(jié)點(diǎn)依舊是痛點(diǎn)。這對使用外部負(fù)載均衡器幫助巨大。 數(shù)人云今天帶來的本篇文章將分享Docker在應(yīng)用程序生命周期每個階段中所扮演的角色,以及遷移到Swarm集群時需要考慮的問題。 利用Docker來開發(fā) Docker讓工作更輕松。如需要一個部署安裝MySQL數(shù)據(jù)庫,或者安裝Ghost,又或者Redis數(shù)據(jù)...
摘要:應(yīng)該如何解決本文將給出若干提示,如何在生產(chǎn)環(huán)境中使用。路由匹配服務(wù)發(fā)現(xiàn)負(fù)載均衡跨容器通訊非常可靠。在單個端口上運(yùn)行一個服務(wù),節(jié)點(diǎn)的任意主機(jī)都可以訪問,負(fù)載均衡完全在后臺實(shí)現(xiàn)。 上周數(shù)人云給大家分享了——《你可能需要的關(guān)于Docker Swarm的經(jīng)驗(yàn)分享》今天給大家?guī)磉@位作者大大的后續(xù)文章——《Docker Swarm在生產(chǎn)環(huán)境中的進(jìn)階指南》 當(dāng)在本地開發(fā)環(huán)境中使用Docker,或者...
摘要:譯者按實(shí)踐中會發(fā)現(xiàn),生產(chǎn)環(huán)境中使用單個節(jié)點(diǎn)是遠(yuǎn)遠(yuǎn)不夠的,搭建集群勢在必行。集群的網(wǎng)絡(luò)通信服務(wù)發(fā)現(xiàn),負(fù)載均衡以及容器間通信非常可靠。負(fù)載均衡也是由提供的。 譯者按: 實(shí)踐中會發(fā)現(xiàn),生產(chǎn)環(huán)境中使用單個Docker節(jié)點(diǎn)是遠(yuǎn)遠(yuǎn)不夠的,搭建Docker集群勢在必行。然而,面對Kubernetes, Mesos以及Swarm等眾多容器集群系統(tǒng),我們該如何選擇呢?它們之中,Swarm是Docker原...
閱讀 781·2021-11-09 09:47
閱讀 1568·2019-08-30 15:44
閱讀 1143·2019-08-26 13:46
閱讀 2107·2019-08-26 13:41
閱讀 1266·2019-08-26 13:32
閱讀 3772·2019-08-26 10:35
閱讀 3519·2019-08-23 17:16
閱讀 448·2019-08-23 17:07