生产环境运行Docker的9个关键决策
生活随笔
收集整理的這篇文章主要介紹了
生产环境运行Docker的9个关键决策
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
本文講的是生產(chǎn)環(huán)境運(yùn)行Docker的9個關(guān)鍵決策,【編者的話】生產(chǎn)環(huán)境運(yùn)行Docker并沒有想象的那么簡單,如何實(shí)現(xiàn)穩(wěn)定安全的部署和擴(kuò)容? 又有哪些需要考慮的關(guān)鍵決策? 本文就此做了一些分析和闡述,趕緊來看看吧!
也許你已經(jīng)構(gòu)建好了你的Rails或者基于Rack的Ruby應(yīng)用。它甚至在你筆記本上的Docker容器里運(yùn)行著并且團(tuán)隊(duì)里的其他開發(fā)者也是這樣將它跑起來的。一切看上去棒極了,那么或許是時候裝載它了。
不過,等一下!別急!將應(yīng)用切換到生產(chǎn)環(huán)境中的Docker運(yùn)行并沒有聽上去那么簡單。這里面要做的可不僅僅只是將你本地構(gòu)建的容器鏡像裝載到生產(chǎn)環(huán)境而已。
讓我們一起來看看,在你可以安全地將容器化的Rails以及基于Rack的Ruby應(yīng)用部署到生產(chǎn)環(huán)境之前你將可能面臨的9個最主要的關(guān)鍵決策。
除非你打算將你的Docker鏡像對外公開,否則的話你可能還需要一個私有的Docker鏡像倉庫。雖然Docker官方提供了一個私有鏡像倉庫允許你自己來部署和管理鏡像,然而,你可能并不愿意采用它,畢竟如果它發(fā)生故障的話會打斷你的發(fā)布流程。你將需要選擇一款方案來加固私有Docker鏡像,同時還得保證在構(gòu)建和部署過程中可以訪問到它們。
請注意,如果容器的部署過程橫跨多個云服務(wù)提供商的話,這可能會造成將來變更云服務(wù)提供商變得更加困難。如果你希望使用多個云服務(wù)提供商或者想防止被圈死的話,你將需要做的是建立對多重云服務(wù)提供商的支持(或者找到一個支持這樣做的解決方案)。
在開發(fā)期間為了便于排障,開發(fā)環(huán)境的配置一般是相對開放的。而在生產(chǎn)環(huán)境里,網(wǎng)絡(luò)的配置則需要考慮更多方面。公網(wǎng)流量不應(yīng)該有訪問某些容器的權(quán)限,而應(yīng)該只有內(nèi)網(wǎng)的其他容器才可以訪問它們。通過對網(wǎng)絡(luò)流量的監(jiān)控,暴力登陸攻擊,以及其他的攻擊載體必須被識別出來然后妥當(dāng)?shù)靥幚淼簟?/span>
此外,你還得在安全補(bǔ)丁發(fā)布后及時跟進(jìn),然后判斷你的宿主機(jī)和容器是否依然都是安全地還是需要將補(bǔ)丁打上去。
將你的容器挪到生產(chǎn)環(huán)境的話需要考慮網(wǎng)絡(luò)訪問以及如何保證容器和Docker宿主機(jī)能及時地打上安全補(bǔ)丁等問題。對于生產(chǎn)環(huán)境而言千萬不要忽視這一關(guān)鍵步驟。
需要注意的是,除非你打算在更新后將現(xiàn)有的部署下線,否則你將不得不支持應(yīng)用服務(wù)同一時間多個版本同時運(yùn)行的情況。你的負(fù)載均衡策略需要將這個計(jì)算在內(nèi),以防止用戶連接的丟失又或者是將流量路由到錯誤的版本。
想了解更多關(guān)于如何選擇負(fù)載均衡策略的信息的話,歡迎閱讀我們在服務(wù)器擴(kuò)容技術(shù)方面的文章。
協(xié)調(diào)不同環(huán)境配置之間的差異也需要相當(dāng)大的腳本化的努力。這可不會像它在開發(fā)環(huán)境里docker-compose up那么簡單。你需要留出足夠的時間來解決這些細(xì)節(jié)問題,因?yàn)槟阋讶粡囊粋€簡單的,單個容器應(yīng)用轉(zhuǎn)變?yōu)橐唤M復(fù)雜的容器鏡像,每個對應(yīng)多個實(shí)例,并且它們需要被布設(shè)到負(fù)載均衡器后面以分發(fā)處理工作負(fù)載。隨著你的應(yīng)用不斷地更迭以及流量的提升,還將采用滾動升級(rolling upgrades)或者藍(lán)-綠部署(blue-green deployment)等策略以防止站點(diǎn)故障。
不太了解有哪些有效的部署策略?可以查看云原生應(yīng)用的發(fā)布策略這篇文章來了解更多。
無論你選擇的是哪款方案,都得確保你的服務(wù)注冊和你的容器實(shí)例同步,并且在容器擴(kuò)展到多臺Docker宿主機(jī)的時候在負(fù)載均衡策略方面有所響應(yīng)。這樣做將可以保證你的應(yīng)用可以編碼成一個通用的服務(wù)名稱(例如myservice.mycluster.local),它可以用來將請求路由到特定的容器實(shí)例服務(wù)。
分布式日志策略使得服務(wù)器可以從一個或多個的日志服務(wù)器上采集和聚合日志記錄。生產(chǎn)環(huán)境的基礎(chǔ)設(shè)施也將需要支持跨越容器的日志聚合。你還得考慮該如何規(guī)劃查詢和搜索這些日志來配合排障等因素。
不知道你需要什么樣的監(jiān)控策略?我們有一份監(jiān)控策略指南也許可以幫到你。
你可以閱讀我們關(guān)于擴(kuò)展生產(chǎn)環(huán)境數(shù)據(jù)庫的文章來了解更多內(nèi)容。
開發(fā)人員需要記住的是Docker是一款工具,而不是一個全面的云原生應(yīng)用架構(gòu)的解決方案。它提供了一些精彩的功能特性,并且我很高興能夠?qū)ocker作為我的基礎(chǔ)架構(gòu)的一部分。但是,它同其他基于云的解決方案一樣需要付出同等的努力(甚至大概還會多一些)來維護(hù)一個生產(chǎn)環(huán)境的Docker部署。
使用Cloud66在生產(chǎn)環(huán)境里管理容器的話則無需再有這些方方面面的無窮顧慮。通過自定義一些配置文件,我可以將我的環(huán)境從開發(fā)遷移到生產(chǎn)并且獲得他們平臺提供的所有好處:內(nèi)置的日志,安全的網(wǎng)絡(luò)訪問管理,監(jiān)控,持續(xù)交付,補(bǔ)丁管理,以及他們按需提供的數(shù)據(jù)庫即服務(wù)(Database-as-a-Service)。
親自去嘗試一下吧,看看部署及管理自己的Docker生產(chǎn)環(huán)境究竟能變得多簡單輕松!
原文鏈接:9-crtitical-decisions-needed-to-run-docker-in-production?(翻譯:吳佳興)
原文發(fā)布時間為:2016-05-12 本文作者:colstuwjx 本文來自云棲社區(qū)合作伙伴DockerOne,了解相關(guān)信息可以關(guān)注DockerOne。 原文標(biāo)題:生產(chǎn)環(huán)境運(yùn)行Docker的9個關(guān)鍵決策
也許你已經(jīng)構(gòu)建好了你的Rails或者基于Rack的Ruby應(yīng)用。它甚至在你筆記本上的Docker容器里運(yùn)行著并且團(tuán)隊(duì)里的其他開發(fā)者也是這樣將它跑起來的。一切看上去棒極了,那么或許是時候裝載它了。
不過,等一下!別急!將應(yīng)用切換到生產(chǎn)環(huán)境中的Docker運(yùn)行并沒有聽上去那么簡單。這里面要做的可不僅僅只是將你本地構(gòu)建的容器鏡像裝載到生產(chǎn)環(huán)境而已。
讓我們一起來看看,在你可以安全地將容器化的Rails以及基于Rack的Ruby應(yīng)用部署到生產(chǎn)環(huán)境之前你將可能面臨的9個最主要的關(guān)鍵決策。
關(guān)鍵決策 #1:鏡像管理
在開發(fā)環(huán)境里為構(gòu)建鏡像而設(shè)置一個Dockerfile及docker-compose.yml是相當(dāng)簡單的,因此在生產(chǎn)環(huán)境里你也應(yīng)當(dāng)創(chuàng)建一個一致的流程來構(gòu)建Docker鏡像文件。這將可以消除對本地環(huán)境的任何顧慮,避免了依賴于開發(fā)環(huán)境筆記本來作為你構(gòu)建新鏡像的唯一手段。它還使得你可以創(chuàng)建一個不用開發(fā)團(tuán)隊(duì)手工干涉的從代碼提交到Docker鏡像的持續(xù)部署管道。除非你打算將你的Docker鏡像對外公開,否則的話你可能還需要一個私有的Docker鏡像倉庫。雖然Docker官方提供了一個私有鏡像倉庫允許你自己來部署和管理鏡像,然而,你可能并不愿意采用它,畢竟如果它發(fā)生故障的話會打斷你的發(fā)布流程。你將需要選擇一款方案來加固私有Docker鏡像,同時還得保證在構(gòu)建和部署過程中可以訪問到它們。
關(guān)鍵決策 #2:選擇一個云服務(wù)提供商
一旦你已經(jīng)擁有了一個Docker的鏡像,你需要做的便是將它部署到一臺Docker宿主機(jī)上。許多云服務(wù)提供商如今已經(jīng)加入了對Docker容器部署的支持。由于這里面大多數(shù)是根據(jù)所使用的資源而不是容器實(shí)例來收費(fèi),怎樣核查定價細(xì)節(jié)以避免天價賬單就顯得至關(guān)重要了。請注意,如果容器的部署過程橫跨多個云服務(wù)提供商的話,這可能會造成將來變更云服務(wù)提供商變得更加困難。如果你希望使用多個云服務(wù)提供商或者想防止被圈死的話,你將需要做的是建立對多重云服務(wù)提供商的支持(或者找到一個支持這樣做的解決方案)。
關(guān)鍵決策 #3:網(wǎng)絡(luò)訪問和安全補(bǔ)丁
在本地開發(fā)環(huán)境里運(yùn)行的容器不會有嚴(yán)重的安全風(fēng)險。所有進(jìn)程都運(yùn)行在單臺主機(jī)上,生產(chǎn)服務(wù)器上常見的網(wǎng)絡(luò)入侵風(fēng)險以及各式各樣的攻擊載體均被隔離開來。在開發(fā)期間為了便于排障,開發(fā)環(huán)境的配置一般是相對開放的。而在生產(chǎn)環(huán)境里,網(wǎng)絡(luò)的配置則需要考慮更多方面。公網(wǎng)流量不應(yīng)該有訪問某些容器的權(quán)限,而應(yīng)該只有內(nèi)網(wǎng)的其他容器才可以訪問它們。通過對網(wǎng)絡(luò)流量的監(jiān)控,暴力登陸攻擊,以及其他的攻擊載體必須被識別出來然后妥當(dāng)?shù)靥幚淼簟?/span>
此外,你還得在安全補(bǔ)丁發(fā)布后及時跟進(jìn),然后判斷你的宿主機(jī)和容器是否依然都是安全地還是需要將補(bǔ)丁打上去。
將你的容器挪到生產(chǎn)環(huán)境的話需要考慮網(wǎng)絡(luò)訪問以及如何保證容器和Docker宿主機(jī)能及時地打上安全補(bǔ)丁等問題。對于生產(chǎn)環(huán)境而言千萬不要忽視這一關(guān)鍵步驟。
關(guān)鍵決策 #4:容器和宿主機(jī)之間的負(fù)載均衡
一旦從單個的容器服務(wù)轉(zhuǎn)到跨越一個或多個宿主機(jī)的多個容器,我們便將需要對應(yīng)的負(fù)載均衡器來分發(fā)傳入的請求。常見的做法是使用像nginx或HAProxy這樣的工具來實(shí)現(xiàn)。難點(diǎn)主要在于需要保證當(dāng)容器創(chuàng)建或銷毀時它們的配置能夠及時更新,為擴(kuò)容而添加到生產(chǎn)的新Docker宿主機(jī)也是如此。你可以及時通過工具或腳本來滿足這類需求。需要注意的是,除非你打算在更新后將現(xiàn)有的部署下線,否則你將不得不支持應(yīng)用服務(wù)同一時間多個版本同時運(yùn)行的情況。你的負(fù)載均衡策略需要將這個計(jì)算在內(nèi),以防止用戶連接的丟失又或者是將流量路由到錯誤的版本。
想了解更多關(guān)于如何選擇負(fù)載均衡策略的信息的話,歡迎閱讀我們在服務(wù)器擴(kuò)容技術(shù)方面的文章。
關(guān)鍵決策 #5:部署過程
許多開發(fā)者認(rèn)為那些他們在開發(fā)環(huán)境里用到的工具也將在生產(chǎn)環(huán)境里工作。不是這樣的。Docker Compose的配置從開發(fā)到生產(chǎn)將會有很大的不同。從卷的設(shè)置到端口的綁定以及網(wǎng)絡(luò)的配置,布設(shè)容器的方式會發(fā)生變化。由于挪到了多宿主機(jī)的環(huán)境復(fù)雜度也會相應(yīng)提高。你可能還需要一些在開發(fā)環(huán)境不常見的額外容器,例如日志聚合器,外部數(shù)據(jù)庫,以及高可用的消息代理(僅僅列舉幾個)。協(xié)調(diào)不同環(huán)境配置之間的差異也需要相當(dāng)大的腳本化的努力。這可不會像它在開發(fā)環(huán)境里docker-compose up那么簡單。你需要留出足夠的時間來解決這些細(xì)節(jié)問題,因?yàn)槟阋讶粡囊粋€簡單的,單個容器應(yīng)用轉(zhuǎn)變?yōu)橐唤M復(fù)雜的容器鏡像,每個對應(yīng)多個實(shí)例,并且它們需要被布設(shè)到負(fù)載均衡器后面以分發(fā)處理工作負(fù)載。隨著你的應(yīng)用不斷地更迭以及流量的提升,還將采用滾動升級(rolling upgrades)或者藍(lán)-綠部署(blue-green deployment)等策略以防止站點(diǎn)故障。
不太了解有哪些有效的部署策略?可以查看云原生應(yīng)用的發(fā)布策略這篇文章來了解更多。
關(guān)鍵決策 #6:服務(wù)發(fā)現(xiàn)
隨著容器數(shù)量的不斷增長,也就自然帶來了額外地管理他們的注冊以供應(yīng)用消費(fèi)的開銷。業(yè)界有多種工具可以用來管理這個流程,大多數(shù)需要集成和配置到你的Docker生產(chǎn)環(huán)境里。與此不同的是,Cloud 66找到了一個更為簡單的管理服務(wù)注冊中心的方式,那便是利用內(nèi)部的DNS服務(wù)器來實(shí)現(xiàn)。無論你選擇的是哪款方案,都得確保你的服務(wù)注冊和你的容器實(shí)例同步,并且在容器擴(kuò)展到多臺Docker宿主機(jī)的時候在負(fù)載均衡策略方面有所響應(yīng)。這樣做將可以保證你的應(yīng)用可以編碼成一個通用的服務(wù)名稱(例如myservice.mycluster.local),它可以用來將請求路由到特定的容器實(shí)例服務(wù)。
關(guān)鍵決策 #7:日志管理
在開發(fā)環(huán)境里使用Docker Compose的話可以看到詳細(xì)的日志輸出并且可以快速的排障。而切換到跨越任意數(shù)量的宿主機(jī)的多個容器實(shí)例的場景時,這便會變得更難去排查宕機(jī)問題。分布式日志策略使得服務(wù)器可以從一個或多個的日志服務(wù)器上采集和聚合日志記錄。生產(chǎn)環(huán)境的基礎(chǔ)設(shè)施也將需要支持跨越容器的日志聚合。你還得考慮該如何規(guī)劃查詢和搜索這些日志來配合排障等因素。
關(guān)鍵決策 #8:監(jiān)控容器
在生產(chǎn)環(huán)境里對容器的監(jiān)控是必不可少的。從Docker宿主機(jī)到容器,你需要知道每個服務(wù)及整體系統(tǒng)的健康性。選擇正確的工具和監(jiān)控策略可以確保你盡可能地減少中斷的影響并且最大限度地提高主機(jī)資源利用率,從而改善用戶的體驗(yàn)。不知道你需要什么樣的監(jiān)控策略?我們有一份監(jiān)控策略指南也許可以幫到你。
關(guān)鍵決策 #9:數(shù)據(jù)庫管理
在開發(fā)環(huán)境,數(shù)據(jù)庫可以托管在容器里而無需擔(dān)心I/O性能方面的問題。生產(chǎn)環(huán)境則無法容忍糟糕的性能,尤其是當(dāng)我們想交付的是絕佳的用戶體驗(yàn)的時候。根據(jù)需求擴(kuò)展數(shù)據(jù)庫以處理日益增長的I/O,配套高可用和可靠的備份/還原策略是成功運(yùn)行一個現(xiàn)代Web應(yīng)用或者移動端API的關(guān)鍵所在。生產(chǎn)環(huán)境所選擇的策略將會對你的用戶產(chǎn)生積極或消極的影響。你可以閱讀我們關(guān)于擴(kuò)展生產(chǎn)環(huán)境數(shù)據(jù)庫的文章來了解更多內(nèi)容。
我真的需要馬上做出這些決策嗎?
是的,很有可能。除非你正要部署的是一個只有小流量訪問的簡單應(yīng)用或者API,否則的話這里面的每個決策都將會是影響產(chǎn)品成功的關(guān)鍵。看上去有一點(diǎn)擔(dān)子,不是嗎?開發(fā)人員需要記住的是Docker是一款工具,而不是一個全面的云原生應(yīng)用架構(gòu)的解決方案。它提供了一些精彩的功能特性,并且我很高興能夠?qū)ocker作為我的基礎(chǔ)架構(gòu)的一部分。但是,它同其他基于云的解決方案一樣需要付出同等的努力(甚至大概還會多一些)來維護(hù)一個生產(chǎn)環(huán)境的Docker部署。
使用Cloud66在生產(chǎn)環(huán)境里管理容器的話則無需再有這些方方面面的無窮顧慮。通過自定義一些配置文件,我可以將我的環(huán)境從開發(fā)遷移到生產(chǎn)并且獲得他們平臺提供的所有好處:內(nèi)置的日志,安全的網(wǎng)絡(luò)訪問管理,監(jiān)控,持續(xù)交付,補(bǔ)丁管理,以及他們按需提供的數(shù)據(jù)庫即服務(wù)(Database-as-a-Service)。
親自去嘗試一下吧,看看部署及管理自己的Docker生產(chǎn)環(huán)境究竟能變得多簡單輕松!
原文鏈接:9-crtitical-decisions-needed-to-run-docker-in-production?(翻譯:吳佳興)
原文發(fā)布時間為:2016-05-12 本文作者:colstuwjx 本文來自云棲社區(qū)合作伙伴DockerOne,了解相關(guān)信息可以關(guān)注DockerOne。 原文標(biāo)題:生產(chǎn)環(huán)境運(yùn)行Docker的9個關(guān)鍵決策
總結(jié)
以上是生活随笔為你收集整理的生产环境运行Docker的9个关键决策的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: extJs相关名字解释
- 下一篇: 006-Python迭代器