進(jìn)入2016年以后，容器技術(shù)早已經(jīng)從最初的牛逼滿天飛到了腳踏實(shí)地的大規(guī)模鋪開(kāi)。很多企業(yè)都已經(jīng)在實(shí)際項(xiàng)目中或深或淺的使用著容器技術(shù)，享受到新技術(shù)帶來(lái)的簡(jiǎn)潔和高效。作為國(guó)內(nèi)最早研究和使用Docker技術(shù)的企業(yè)，ThoughtWorks在2013年底就在實(shí)際項(xiàng)目中將Docker用于測(cè)試環(huán)境的資源復(fù)用，并在之后的許多項(xiàng)目中逐漸總結(jié)出許多有用的實(shí)踐和經(jīng)驗(yàn)。在這篇文章里，我將聊聊Docker在我經(jīng)歷過(guò)項(xiàng)目中的一些比較有代表性的運(yùn)用場(chǎng)景。
現(xiàn)實(shí)中的容器技術(shù)運(yùn)用方式非常廣泛而靈活，時(shí)常讓人覺(jué)得腦洞大開(kāi)，概括來(lái)說(shuō)是『可小可大，可遠(yuǎn)可近』。下面用四個(gè)案例來(lái)闡示容器在非特定領(lǐng)域里的運(yùn)用場(chǎng)景。
容器之�。盒《赖娜萜鱀evOps架構(gòu)棧
圖1 基于容器和DevOps理念的運(yùn)維架構(gòu)
這張架構(gòu)圖來(lái)自于一個(gè)規(guī)模不到20人的小型產(chǎn)品團(tuán)隊(duì)，團(tuán)隊(duì)的結(jié)構(gòu)十分精巧，由兩名開(kāi)發(fā)人員兼任主要的運(yùn)維工作。這兩位開(kāi)發(fā)人員，花了幾周時(shí)間通過(guò)Ansible陸陸續(xù)續(xù)搭建起了這套由上百個(gè)服務(wù)器節(jié)點(diǎn)組成的集群，并由團(tuán)隊(duì)所有開(kāi)發(fā)人員共同維護(hù)。整體套集群系統(tǒng)高度自動(dòng)化，使得團(tuán)隊(duì)的每個(gè)人都能夠十分快速而安全的完成業(yè)務(wù)功能的部署、獲取線上業(yè)務(wù)的運(yùn)行狀況、以及對(duì)出現(xiàn)問(wèn)題的故障點(diǎn)進(jìn)行快速的日志錯(cuò)誤定位。
麻雀雖小，五臟俱全。這套技術(shù)方案包含了集群管理、網(wǎng)絡(luò)管理、服務(wù)發(fā)現(xiàn)、日志管理、性能監(jiān)控等許多方面的設(shè)計(jì)，從架構(gòu)的角度上看，已經(jīng)儼然是一個(gè)小型私有PaaS平臺(tái)。
Swarm作為集群的管理工具，具有與Docker原生命令良好的一致性，在學(xué)習(xí)曲線比較緩和，在DevOps文化比較好的團(tuán)隊(duì)中很容易讓開(kāi)發(fā)人員快速上手。在這個(gè)架構(gòu)方案中使用了Consul作為集群元數(shù)據(jù)存儲(chǔ)的方案，Swarm的主、從節(jié)點(diǎn)信息以及Docker的跨節(jié)點(diǎn)網(wǎng)絡(luò)劃分的信息都存放在這里。Consul除了作為集群信息的存儲(chǔ)，還可以用于應(yīng)用服務(wù)的配置存儲(chǔ)和服務(wù)發(fā)現(xiàn)，以及作為內(nèi)網(wǎng)的DNS服務(wù)使用。不過(guò)出于安全性和可維護(hù)性的考慮，應(yīng)該為應(yīng)用服務(wù)單獨(dú)搭建獨(dú)立的Consul節(jié)點(diǎn)，與存儲(chǔ)集群配置的Consul分開(kāi)，防止由于數(shù)據(jù)干擾和意外修改引起大規(guī)模系統(tǒng)故障。
使用Swarm的另一個(gè)潛在好處是它能夠充分利用Docker內(nèi)置的跨節(jié)點(diǎn)網(wǎng)絡(luò)功能，這套基于VxLAN的SDN實(shí)現(xiàn)十分簡(jiǎn)潔易用，通信效率也很不錯(cuò)。
容器集群的的性能監(jiān)控和日志管理是使得這個(gè)小團(tuán)隊(duì)得以駕馭比團(tuán)隊(duì)人數(shù)更多的服務(wù)節(jié)點(diǎn)的關(guān)鍵要素，任憑運(yùn)行的服務(wù)在機(jī)器漫漫海洋中隨意穿行，這兩件工具就是開(kāi)發(fā)人員的羅盤和風(fēng)向標(biāo)，在關(guān)鍵時(shí)候?yàn)榫�上故障的定位爭(zhēng)取寶貴時(shí)間，并能從中迅速找到每個(gè)服務(wù)當(dāng)前運(yùn)行的節(jié)點(diǎn)，從而采取必要的應(yīng)急措施。cAdvisor+Influxdb+Grafana是一套為容器集群性能監(jiān)控設(shè)計(jì)的開(kāi)源解決方案，利用cAdvisor對(duì)容器信息的良好監(jiān)控能力，Influxdb對(duì)時(shí)間序列數(shù)據(jù)的快速檢索能力，以及Grafana的強(qiáng)大圖表展示能力，形成性能數(shù)據(jù)的實(shí)時(shí)查看和歷史回溯，并反饋到開(kāi)發(fā)和運(yùn)營(yíng)的狀態(tài)報(bào)表，形成完整閉環(huán)。不過(guò)，這個(gè)開(kāi)源組合的缺陷在于缺乏現(xiàn)成的事件告警組件，在Influxdata公司的Telegraf項(xiàng)目逐漸成熟后，可以考慮使用它替代cAdvisor的功能，然后集成Kapacitor作為告警模塊，提前預(yù)知服務(wù)的不正常狀態(tài)。日志管理方面，這套系統(tǒng)使用了當(dāng)下最主流的容器日志開(kāi)源工具組合Fluentd+EslasticSearch+Kibana，在《程序員》2016年6月刊『容器的性能監(jiān)控和日志管理』一文中已經(jīng)對(duì)這個(gè)組合進(jìn)行過(guò)比較深入的探討。
這是Docker集群化實(shí)踐中運(yùn)用得比較出色的一個(gè)案例，特別是對(duì)中小型產(chǎn)品團(tuán)隊(duì)，會(huì)有不少可借鑒和啟發(fā)之處。在不用增加額外運(yùn)維人員的情況下，這套系統(tǒng)可以比較輕松的擴(kuò)容至幾百上千的規(guī)模。然而，這個(gè)架構(gòu)本身并沒(méi)有考慮譬如多數(shù)據(jù)中心、租戶隔離、訪問(wèn)授權(quán)、資源配額等復(fù)雜情景，它主要的設(shè)計(jì)初衷在于解決集群易用性的問(wèn)題。試想在過(guò)去使用虛擬機(jī)管理服務(wù)的時(shí)代，讓只有幾個(gè)人的團(tuán)隊(duì)去維護(hù)上千個(gè)計(jì)算節(jié)點(diǎn)上運(yùn)行的需要各種不同環(huán)境和配置的服務(wù)，這簡(jiǎn)直是不可完成的任務(wù)，然而通過(guò)容器化的部署、DevOps思維的團(tuán)隊(duì)、加上適當(dāng)?shù)募狠o助工具，他們做到了。
容器之大：大型任務(wù)集群的容器化調(diào)度
圖2 基于容器的多數(shù)據(jù)中心任務(wù)平臺(tái)架構(gòu)
并不是所有的團(tuán)隊(duì)都愿意從頭構(gòu)建自己的整套運(yùn)維架構(gòu)和基礎(chǔ)設(shè)施環(huán)境。在許多企業(yè)里，服務(wù)的運(yùn)維管理是有專門的組織負(fù)責(zé)的。這些組織可能叫做平臺(tái)部門、運(yùn)維部門、或者環(huán)境支持部門，不論稱呼如何，這些組織以及部門通常都需要管理數(shù)量相當(dāng)龐大的計(jì)算資源。這些資源可能是跨機(jī)房，跨城市，甚至是分布在歐洲、美洲、非洲并且相互無(wú)法直接通信的數(shù)據(jù)中心里。他們所需要調(diào)度的作業(yè)數(shù)量和種類也遠(yuǎn)遠(yuǎn)超過(guò)一個(gè)自運(yùn)維產(chǎn)品團(tuán)隊(duì)所需要考慮的規(guī)模。
為這樣的組織設(shè)計(jì)基于容器的任務(wù)調(diào)度平臺(tái)需要對(duì)企業(yè)的需求和特定業(yè)務(wù)領(lǐng)域有充分的了解，越是大型的基礎(chǔ)設(shè)施集群，所需要應(yīng)對(duì)的風(fēng)險(xiǎn)和不確定也越大，設(shè)計(jì)一個(gè)面面俱到的通用大型集群也越困難。因此針對(duì)具體業(yè)務(wù)場(chǎng)景做出一定的取舍是不得已、但又是必要的。例如為了獲得較高的響應(yīng)速度而將集群劃分為多個(gè)互不重疊的調(diào)度區(qū)域，因而限制了每個(gè)區(qū)域的容量；為了避免內(nèi)網(wǎng)數(shù)據(jù)網(wǎng)絡(luò)風(fēng)暴而將節(jié)點(diǎn)數(shù)據(jù)分層處理并逐級(jí)減少數(shù)據(jù)匯總的維度，因而增加監(jiān)控管理復(fù)雜度；或者為了增加系統(tǒng)規(guī)模而采用高度聚合而不適合多數(shù)據(jù)中心的方案。這些方案往往不需要具備普適性，而是會(huì)針對(duì)特定企業(yè)和業(yè)務(wù)場(chǎng)景進(jìn)行恰到好處的修剪和優(yōu)化。
上面圖中展示的是一個(gè)企業(yè)PaaS服務(wù)平臺(tái)的結(jié)構(gòu)，架構(gòu)基于Kubernetes集群，需要應(yīng)用在多個(gè)異地?cái)?shù)據(jù)中心，并在統(tǒng)一的部署系統(tǒng)上對(duì)服務(wù)進(jìn)行管理。由于單Kubernetes集群容量有限，這個(gè)方案實(shí)際上根據(jù)地域劃分和租戶的規(guī)模構(gòu)建了多個(gè)幾十到上千節(jié)點(diǎn)不等的子集群，集群直接互不重合，屬于同一個(gè)任務(wù)組的服務(wù)只會(huì)在特定的某個(gè)集群內(nèi)進(jìn)行部署和調(diào)度，其實(shí)就是將集群和租戶進(jìn)行了綁定。在所有集群之上，通過(guò)自研的一個(gè)任務(wù)分發(fā)服務(wù)作為所有調(diào)度任務(wù)的入口，在這里處理服務(wù)的依賴關(guān)系、所屬區(qū)域、以及其他元數(shù)據(jù)信息，然后調(diào)用Kubernetes的API完成任務(wù)的部署和調(diào)度，并通過(guò)額外的組件處理網(wǎng)絡(luò)、存儲(chǔ)等資源的配置。
在圖中省略了系統(tǒng)采用的其他自研模塊，值得一提的是這個(gè)系統(tǒng)的性能數(shù)據(jù)管理使用了開(kāi)源的Promethus軟件。Promethus是SoundCloud公司維護(hù)的一款包含信息采集、處理、分析、展示和告警的性能監(jiān)控整體解決方案，它提供了比較靈活的多數(shù)據(jù)中心級(jí)聯(lián)能力和集中式的配置管理功能，因此特別適合規(guī)模較大的計(jì)算集群。不同于前一案例中Influxdb方案每個(gè)數(shù)據(jù)采集節(jié)點(diǎn)發(fā)數(shù)據(jù)給存儲(chǔ)數(shù)據(jù)的中心節(jié)點(diǎn)的方式，Promethus的性能數(shù)據(jù)采集是由中心服務(wù)器主動(dòng)向所有節(jié)點(diǎn)定時(shí)輪詢的方式拉取的，因此所有與數(shù)據(jù)采集相關(guān)的配置全部在中心服務(wù)器上進(jìn)行修改即可。而節(jié)點(diǎn)的數(shù)量和IP地址變動(dòng)則通過(guò)服務(wù)發(fā)現(xiàn)機(jī)制來(lái)告知中心服務(wù)器，這大大簡(jiǎn)化了修改數(shù)據(jù)收集參數(shù)的流程。
這個(gè)案例是一個(gè)比較典型的大規(guī)模容器集群，在大型容器集群方面許多企業(yè)都有著自己的實(shí)踐沉淀。其中有兩個(gè)比較明顯的特點(diǎn)是從業(yè)務(wù)場(chǎng)景制定架構(gòu)和系統(tǒng)中包含許多自研的組件，因此在借鑒的時(shí)候更需要廣泛的收集信息，避免盲目照搬。
容器之遠(yuǎn)：基于容器的持續(xù)集成實(shí)踐
圖3 基于容器的持續(xù)交付流水線示意
接下來(lái)，讓我們用廣角鏡頭來(lái)審視一下軟件發(fā)布的生命周期。通過(guò)持續(xù)交付的流水線，我們能夠清晰的定義出軟件從代碼提交到上線發(fā)布之前所需要經(jīng)過(guò)的每個(gè)環(huán)節(jié)，協(xié)助開(kāi)發(fā)者發(fā)現(xiàn)工作流程中存在的瓶頸，并促使團(tuán)隊(duì)提升端到端的自動(dòng)化程度，縮短獨(dú)立功能上線的周期。
那么容器在其中能扮演什么樣的角色呢？首先是資源的隔離，為了確保每一次編譯和測(cè)試的獨(dú)立性，軟件應(yīng)該在干凈的環(huán)境中分別進(jìn)行構(gòu)建、打包、并運(yùn)行測(cè)試用例，而容器是非常合適用來(lái)提供這種虛擬環(huán)境的輕量級(jí)工具。其次是一致的軟件打包方式，Docker的封裝意味著不論運(yùn)行的服務(wù)是用Java、Python、PHP還是Scala、Golang，平臺(tái)可以用幾乎相同的方式去完成部署，而不用考慮安裝服務(wù)所需的環(huán)境，這些都在軟件開(kāi)發(fā)的時(shí)候就已經(jīng)準(zhǔn)備好了。最后是成熟的調(diào)度平臺(tái)�；谌萜饔性S多現(xiàn)成的任務(wù)調(diào)度框架，也正是由于前兩個(gè)角色，容器使得任務(wù)的分發(fā)變得容易，由于應(yīng)用不需要依賴主機(jī)的配置，這就讓任務(wù)的靈活調(diào)度成為可能。
基于容器的持續(xù)交付流水線和普通交付流水線很相似，包含構(gòu)建、打包、測(cè)試、部署等環(huán)節(jié)。同時(shí)這其中也有許多技巧和專用于容器的優(yōu)化手段。這個(gè)案例中我們選取其中兩個(gè)比較具有啟發(fā)性的來(lái)說(shuō)。
第一個(gè)例子是關(guān)于容器構(gòu)建的優(yōu)化。容器的構(gòu)建通常都是由某個(gè)基礎(chǔ)鏡像開(kāi)始，通過(guò)Dockerfile的描述自動(dòng)化逐步執(zhí)行，直至完成預(yù)期的狀態(tài)。幾乎所有項(xiàng)目的Dockerfile都不會(huì)每次從一個(gè)原始的Ubuntu或者CentOS的鏡像做為基礎(chǔ)，從頭構(gòu)建整個(gè)運(yùn)行環(huán)境，因?yàn)槟菢訒?huì)使得每次構(gòu)建花費(fèi)非常長(zhǎng)的時(shí)間。制作用于繼承的公共基礎(chǔ)鏡像是早已世人皆知的鏡像構(gòu)建提速優(yōu)化的方法，這樣可以讓費(fèi)時(shí)而又不常改變的步驟固定下來(lái)，每次構(gòu)建時(shí)候就只需要基于這個(gè)鏡像再進(jìn)行增量修改就可以了。但這種方法其實(shí)也有潛在問(wèn)題，那就是當(dāng)我們需要升級(jí)基礎(chǔ)鏡像的時(shí)候，不得不重新構(gòu)建所有基于它制作的所有服務(wù)鏡像。
這個(gè)問(wèn)題被稱為『脆弱的基礎(chǔ)鏡像』，該問(wèn)題的應(yīng)對(duì)策略有很多。例如簡(jiǎn)單的延遲子級(jí)鏡像的升級(jí)時(shí)間，直到每個(gè)子鏡像下次重新構(gòu)建發(fā)布時(shí)自然會(huì)獲得更新。又例如比較激進(jìn)的方式，通過(guò)流水線建立鏡像的依賴關(guān)系，在父級(jí)鏡像一旦更新時(shí)，自動(dòng)觸發(fā)所有子級(jí)鏡像的自動(dòng)重建，這種方式要慎重采用，因?yàn)樗芸赡軙?huì)導(dǎo)致同時(shí)產(chǎn)生大量的鏡像構(gòu)建任務(wù)，對(duì)網(wǎng)絡(luò)和磁盤造成嚴(yán)重的壓力。那么，有沒(méi)有在一種辦法既能獲得具有時(shí)效性的更新，又不會(huì)產(chǎn)生短時(shí)間內(nèi)的構(gòu)建風(fēng)暴呢？其實(shí)對(duì)于一些場(chǎng)景是可以有取巧方法的，通過(guò)Docker的外掛存儲(chǔ)能力，將經(jīng)�？赡茏兓膬�(nèi)容做成單獨(dú)的鏡像，然后利用Docker的『–volume-from』參數(shù)在服務(wù)啟動(dòng)時(shí)覆蓋掉運(yùn)行容器的特定目錄。典型的場(chǎng)景就是用于編譯其他服務(wù)的容器，這些容器中一般都會(huì)有一些編譯服務(wù)時(shí)所需的時(shí)依賴庫(kù)，這些依賴庫(kù)隨著項(xiàng)目所需依賴的變化也要跟著變，像Maven的~/.m2/repository目錄，Node的全局node_module目錄等就很適合這樣管理。當(dāng)這個(gè)目錄下面的內(nèi)容需要更新時(shí)，只需重新構(gòu)建提供目錄內(nèi)容的一個(gè)鏡像，而不會(huì)產(chǎn)生鏡像構(gòu)建的鏈?zhǔn)椒磻?yīng)，服務(wù)下次啟動(dòng)時(shí)候就會(huì)獲得新的依賴庫(kù)目錄了。
第二個(gè)例子是流水線中的測(cè)試環(huán)節(jié)。進(jìn)行自動(dòng)化測(cè)試的時(shí)候，容器的優(yōu)勢(shì)發(fā)揮尤其明顯。對(duì)于外部服務(wù)的依賴，比如與數(shù)據(jù)庫(kù)相關(guān)的測(cè)試，由于測(cè)試過(guò)程需要反復(fù)運(yùn)行，過(guò)去時(shí)候，如果測(cè)試運(yùn)行完沒(méi)有正確的清理留下的數(shù)據(jù)，特別容易影響后續(xù)測(cè)試的運(yùn)行結(jié)果。容器恰恰是提供這種即用即棄基礎(chǔ)設(shè)施最佳的方式，完全可以在測(cè)試腳本中先啟動(dòng)一個(gè)全新的MySQL服務(wù)，然后測(cè)試完就銷毀，保證了每次測(cè)試的獨(dú)立性。關(guān)于這方面的應(yīng)用在下個(gè)案例中再介紹更多細(xì)節(jié)。
類似的技巧還有很多。持續(xù)交付流水線是最能體現(xiàn)容器在軟件領(lǐng)域帶來(lái)各方面改進(jìn)的大觀園。許多現(xiàn)成的工具可以最大化的避免手工操作對(duì)流程的干擾，讓軟件發(fā)布開(kāi)上高速公路。
容器之近：容器在自動(dòng)化測(cè)試平臺(tái)的運(yùn)用
圖4 基于容器的自動(dòng)化測(cè)試平臺(tái)架構(gòu)
最后這個(gè)案例是一個(gè)針對(duì)軟件自動(dòng)化測(cè)試環(huán)節(jié)的容器化基礎(chǔ)設(shè)施設(shè)計(jì)。它是軟件持續(xù)交付流水線上的一個(gè)重要環(huán)節(jié)，讓我們帶上長(zhǎng)焦鏡，近距離審視容器在軟件測(cè)試場(chǎng)景中能解決怎樣的問(wèn)題。
容器快速啟動(dòng)、快速銷毀的特性與軟件測(cè)試時(shí)所需的每次干凈獨(dú)立的臨時(shí)運(yùn)行環(huán)境十分匹配。使得在這方面容器可以大有作為。特別是在集成測(cè)試和功能性測(cè)試的階段，被測(cè)系統(tǒng)的運(yùn)行往往會(huì)需要涉及多個(gè)要獨(dú)立運(yùn)行的子組件或子模塊。還有外部模塊的依賴，如果進(jìn)行的是界面相關(guān)的測(cè)試用例，往往還會(huì)用到Selenium和瀏覽器的組件。而運(yùn)行數(shù)據(jù)庫(kù)相關(guān)的測(cè)試則會(huì)需要MySQL、Mongodb等組件。手工為每個(gè)測(cè)試用例準(zhǔn)備并維護(hù)這些環(huán)節(jié)依賴是十分讓人抓狂的事情。過(guò)去做這類測(cè)試時(shí)候?yàn)榱私鉀Q依賴問(wèn)題，通常做法是額外部署一套專用于測(cè)試依賴的環(huán)境，所有模塊測(cè)試需要?jiǎng)e的模塊時(shí)都統(tǒng)一指向這套測(cè)試環(huán)境作為目標(biāo)。由于過(guò)于頻繁的升級(jí)這個(gè)依賴環(huán)境可能會(huì)打斷正在運(yùn)行的測(cè)試用例，因此只能對(duì)它進(jìn)行定期的更新，這種無(wú)形中限制了的時(shí)效性和可靠性。
特別是一些比較重要并且耗時(shí)較短的回歸測(cè)試和冒煙測(cè)試用例，理想情況下應(yīng)該在每次代碼提交后都全量的更新并執(zhí)行，以便第一時(shí)間發(fā)現(xiàn)一些潛在的功能缺陷。但為每次提交創(chuàng)建一套測(cè)試環(huán)境不論是手工操作還是過(guò)去基于虛擬機(jī)的自動(dòng)化方式都過(guò)于繁瑣。
案例中的測(cè)試平臺(tái)正是意圖通過(guò)容器和簡(jiǎn)單的依賴描述，來(lái)解決測(cè)試環(huán)境管理的問(wèn)題。它基于所有被測(cè)組件和所依賴的組件都使用Docker鏡像來(lái)提供的前提之上，將所有組件抽象成一致的模型寫成描述文件，描述文件的主要內(nèi)容就是整個(gè)測(cè)試環(huán)境所需的鏡像和啟動(dòng)順序。
示意圖中的『運(yùn)行調(diào)度器模塊』是接入持續(xù)交付流水線的調(diào)用入口，可以采用譬如Jenkins的形式插件實(shí)現(xiàn)，它用來(lái)創(chuàng)建和保存特定測(cè)試用例所需的環(huán)境描述文件內(nèi)容。在流水線觸發(fā)該測(cè)試環(huán)節(jié)時(shí)，這個(gè)模塊調(diào)用『測(cè)試執(zhí)行器模塊』，將描述模型用特定的結(jié)構(gòu)體傳遞給后者，后者解析這個(gè)數(shù)據(jù)模型，轉(zhuǎn)化為接近Kubernetes服務(wù)模型的形式，然后在『服務(wù)依賴管理模塊』的協(xié)助下，通過(guò)Kubernetes創(chuàng)建臨時(shí)的Namespace，并依次創(chuàng)建每個(gè)服務(wù)。當(dāng)測(cè)試環(huán)境就緒后，『測(cè)試執(zhí)行器模塊』就開(kāi)始執(zhí)行測(cè)試用例，最后又通過(guò)『服務(wù)依賴管理模塊』通知Kubernetes銷毀整套環(huán)境。
整個(gè)過(guò)程對(duì)于平臺(tái)的用戶而言，僅僅是增加了一個(gè)測(cè)試環(huán)境描述的內(nèi)容，寫在持續(xù)交付流水線測(cè)試步驟的定義(例如Jenkins插件配置)里。而這套系統(tǒng)內(nèi)部頗為復(fù)雜的執(zhí)行過(guò)程，能夠有效的利用整個(gè)集群的資源，恰到好處的為測(cè)試的過(guò)程提供支持。
總結(jié)
這四個(gè)案例由淺入深、由遠(yuǎn)及近的展現(xiàn)了容器在現(xiàn)代軟件和基礎(chǔ)設(shè)施設(shè)計(jì)中舉足輕重的作用。有些技術(shù)會(huì)直接改變?nèi)藗兊纳�，而另一些技術(shù)則會(huì)改變技術(shù)本身以及技術(shù)的發(fā)展方向，容器技術(shù)屬于后者。
隨著容器運(yùn)用的普及，當(dāng)下的主流媒體對(duì)容器周邊技術(shù)的關(guān)注還在持續(xù)升溫。不僅是《程序員》推出了本期的容器技術(shù)�？谧钚乱黄诘腡houghtWorks公開(kāi)刊物《技術(shù)雷達(dá)【1】》中，容器和Docker相關(guān)的關(guān)鍵詞同樣占據(jù)了大量版面。在越來(lái)越多的技術(shù)領(lǐng)域里，無(wú)論是移動(dòng)設(shè)備、物聯(lián)網(wǎng)、大數(shù)據(jù)，都能看到容器技術(shù)各種形式的延伸，作為現(xiàn)實(shí)容器運(yùn)用的一道縮影，此文可作為窺斑見(jiàn)豹、拋磚引玉之用。
核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/
本文標(biāo)題：現(xiàn)實(shí)中的容器技術(shù)運(yùn)用案例
本文網(wǎng)址：http://www.oesoe.com/html/support/11121819995.html
相關(guān)文章
