作者 |?Micah Adams

?責(zé)編 | 徐威龍

封圖|?CSDN 下載于視覺(jué)中國(guó)

最近，我構(gòu)建了一個(gè)本地開(kāi)發(fā)環(huán)境，該環(huán)境使用 Docker 進(jìn)行一些關(guān)鍵的集成測(cè)試。 在我要完成這項(xiàng)工作時(shí)，我意識(shí)到在開(kāi)始這項(xiàng)工作之前，我沒(méi)有考慮到這么做的一些意義深遠(yuǎn)影響，如：

• 它要求開(kāi)發(fā)人員在其本地計(jì)算機(jī)上安裝 docker 和 docker-compose （命令行工具）。

• 為了讓環(huán)境可以正常使用，需要大量的配置。

• 我需要編寫(xiě) shell 腳本來(lái)“緩解”某些配置問(wèn)題。

• 我編寫(xiě)的 shell 腳本最終也有些局限ーー它在某些環(huán)境中工作得很好，但是如果你在 Windows 系統(tǒng)上工作，你就得靠自己了。

• 我一天中的大部分時(shí)間都要用來(lái)排查一些數(shù)據(jù)庫(kù)連接問(wèn)題，結(jié)果發(fā)現(xiàn)我容器的數(shù)據(jù)庫(kù)沒(méi)有配置正確。

在這方面投入了大量的時(shí)間，最終使我的團(tuán)隊(duì)受益，并最終幫助我們解決了集成測(cè)試中遇到的一些難題。但是更讓我感興趣的是它所帶來(lái)的麻煩，更不用說(shuō)在最終合并之前我提交的 pull 請(qǐng)求時(shí)引發(fā)的熱烈討論了。

此外，這種環(huán)境最終只有一個(gè)目的——提供集成測(cè)試環(huán)境，而不是像我最初希望的那樣，提供一套完整的開(kāi)發(fā)環(huán)境。最終的結(jié)果是，我們將這個(gè)環(huán)境從開(kāi)發(fā)人員的機(jī)器上移開(kāi)，并最終將其部署到云提供商的一個(gè)容器化列表中，以創(chuàng)建一個(gè)集成測(cè)試資源。

我的努力基本上是失敗的，尤其是考慮到我最初的動(dòng)機(jī)。

難道我誤入歧途了？我所有的努力工作只換來(lái)一個(gè)花哨的測(cè)試環(huán)境？?

我決定更深入地研究基于容器的開(kāi)發(fā)環(huán)境的問(wèn)題，從那以后我所學(xué)到的東西極大地改變了我將來(lái)處理這個(gè)問(wèn)題的方式。

容器的當(dāng)前狀態(tài)

?

大量的調(diào)查向我們證明，使用 Docker 的人數(shù)在持續(xù)增加，特別是隨著基礎(chǔ)設(shè)施的增長(zhǎng)和變得更加復(fù)雜之后。2018 年 6 月 來(lái)自 DataDog的一項(xiàng)調(diào)查顯示，大約25% 的公司使用 Docker 部署了某種形式的基礎(chǔ)設(shè)施。從 2017 年到 2018 年，部署的規(guī)模增加了75% 。根據(jù)這些消息來(lái)源， Docker “革命”正在全面展開(kāi)，沒(méi)有減緩或停止的跡象。(我仍然很好奇 這75% 中的大多數(shù)公司在他們的部署中使用了什么？抱歉，我跑題了。)

調(diào)查內(nèi)容：https://portworx.com/wp-content/uploads/2019/05/2019-container-adoption-survey.pdf

來(lái)自 DataDog 的調(diào)查：https://www.datadoghq.com/docker-adoption/

2018 年的 DataDog 調(diào)查也提到了使用最廣泛的 Docker 鏡像是“ Nginx，Redis 和 Postgres”。這對(duì)我來(lái)說(shuō)很有意義，因?yàn)檫\(yùn)行應(yīng)用程序依賴項(xiàng)的容器似乎是容器的第一步。Docker Compose 為多容器應(yīng)用程序提供了一個(gè)相對(duì)簡(jiǎn)單的工具; 它似乎也是一個(gè)很好的工具，允許開(kāi)發(fā)人員為自己的環(huán)境運(yùn)行特定的、底層的基礎(chǔ)設(shè)施。也就是說(shuō)，你要為你的項(xiàng)目設(shè)置了一個(gè) `docker-compose.yml` 文件即可。?

這 25% 的公司在生產(chǎn)環(huán)境中運(yùn)行 Docker，究竟有多少公司使用 Docker 作為開(kāi)發(fā)工具呢？2019 年 Stack Overflow 調(diào)查報(bào)告顯示，38.4% 的受訪者使用容器進(jìn)行開(kāi)發(fā)工作，但目前約有一半的受訪者沒(méi)有使用任何容器技術(shù)。我想知道是否有一種方法可以進(jìn)一步理解為什么開(kāi)發(fā)人員不像我最初想象的那樣經(jīng)常使用 Docker。我決定再深入挖掘一下，粗略地研究一下開(kāi)發(fā)人員對(duì) Docker 的看法。

許多開(kāi)發(fā)人員討厭自己的 Docker 環(huán)境，這是有充分理由的——引入容器似乎會(huì)減慢開(kāi)發(fā)人員與他們所構(gòu)建的環(huán)境之間的反饋周期。容器化開(kāi)發(fā)環(huán)境似乎也為操作員創(chuàng)建了一個(gè)不必要的抽象，這個(gè)操作員需要能夠直接深入到代碼、執(zhí)行期函式庫(kù)、甚至較低級(jí)別的操作系統(tǒng)ーー所有這些都是在構(gòu)建一個(gè)特性的過(guò)程中。

支持將 Docker 作為開(kāi)發(fā)工具的人聲稱，這樣做有明顯的的好處。使用容器的開(kāi)發(fā)環(huán)境也會(huì)導(dǎo)致整個(gè)開(kāi)發(fā)團(tuán)隊(duì)實(shí)現(xiàn)對(duì)等。

如果每個(gè)人都使用容器作為他們的數(shù)據(jù)庫(kù)、緩存或其他雜項(xiàng)基礎(chǔ)設(shè)施，那么設(shè)置編寫(xiě)代碼應(yīng)該和運(yùn)行 `docker-compose up` 一樣簡(jiǎn)單，你就可以擁有一個(gè)完整的開(kāi)發(fā)環(huán)境。假設(shè)你的團(tuán)隊(duì)愿意在本地運(yùn)行容器，那么你將永遠(yuǎn)不會(huì)在開(kāi)發(fā)環(huán)境和生產(chǎn)環(huán)境之間造成差異。

當(dāng)運(yùn)行 `brew upgrade`對(duì)其進(jìn)行升級(jí)時(shí)，不會(huì)有啥意外——容器將始終與你的需求保持同步。?

坦白地說(shuō)，我同情這兩個(gè)群體。作為一個(gè)開(kāi)發(fā)者，一只腳堅(jiān)定地站在房子的運(yùn)營(yíng)方面，我認(rèn)為運(yùn)行容器的好處是巨大的。然而，我并不認(rèn)為這些好處完全適用于開(kāi)發(fā)人員工作流。我相信在開(kāi)發(fā)環(huán)境中使用 Docker 的經(jīng)驗(yàn)之間存在差異，因?yàn)?Docker 不是開(kāi)發(fā)人員的工具。

然而，我不認(rèn)為這意味著開(kāi)發(fā)團(tuán)隊(duì)不應(yīng)該考慮利用一些 Docker 來(lái)滿足他們自己的需求。但是我覺(jué)得將 Docker 作為另一個(gè)操作工具來(lái)處理可以幫助減輕在本地開(kāi)發(fā)環(huán)境中運(yùn)行 Docker 的痛苦。

?

容器是開(kāi)發(fā)人員友好的抽象嗎？

?

一個(gè)容器，就 Docker ?而言:?

是一種標(biāo)準(zhǔn)的軟件單元，可以將代碼及其所有依賴關(guān)系打包，使應(yīng)用程序能夠快速可靠地從一個(gè)計(jì)算環(huán)境運(yùn)行到另一個(gè)計(jì)算環(huán)境上。

下面是一個(gè)稍微明晰一些的定義:

容器是應(yīng)用層的一個(gè)抽象，它將代碼和依賴關(guān)系打包在一起。

聽(tīng)起來(lái)不錯(cuò)，對(duì)吧？?

是的，特別是當(dāng)你試圖部署代碼的時(shí)候，你會(huì)發(fā)現(xiàn)的確如此。換句話說(shuō)，如果我主要關(guān)心的是讓我們的代碼在任何地方都能毫無(wú)意外地運(yùn)行，那么容器似乎是目前最好的抽象——我并不真的需要了解我們正在運(yùn)行的代碼，相反，我需要對(duì)我們將如何運(yùn)行它有一個(gè)可預(yù)測(cè)性。作為一個(gè)操作人員，這點(diǎn)非常棒。

但是，作為一個(gè)開(kāi)發(fā)人員，這種抽象可能會(huì)帶來(lái)一些麻煩。容器并不真正關(guān)心自己在運(yùn)行什么。操作系統(tǒng)是有目的地抽象出來(lái)的，運(yùn)行容器所必需的任何依賴項(xiàng)也是如此。應(yīng)用程序?qū)颖旧砗偷讓硬僮飨到y(tǒng)一樣短暫，訪問(wèn)這些抽象層需要了解 Docker 希望以何種方式運(yùn)行代碼。?

盡管我已經(jīng)談到了容器的預(yù)期用途，但我認(rèn)為說(shuō)容器只是團(tuán)隊(duì)運(yùn)營(yíng)的東西的說(shuō)法是錯(cuò)誤的。我認(rèn)為開(kāi)發(fā)人員可以從容器化開(kāi)發(fā)環(huán)境中受益。問(wèn)題在于構(gòu)建一個(gè)真正的開(kāi)發(fā)人員友好的、基于容器的工作流并不容易。

?

基于 docker 的開(kāi)發(fā)環(huán)境的常見(jiàn)缺陷

最后，我選擇在自己的開(kāi)發(fā)工作中多次使用 Docker。這對(duì)我來(lái)說(shuō)很有效，尤其是對(duì)于我每天所做的工作來(lái)說(shuō)。在 Test Double，更重視 Dev Ops 和 SRE，我在這里每天都和容器打交道。

當(dāng)然，這可能不適合你的團(tuán)隊(duì)。但是，如果你確實(shí)希望在開(kāi)發(fā)環(huán)境中使用 Docker 進(jìn)行，我會(huì)提醒你注意一些我親身經(jīng)歷過(guò)的常見(jiàn)陷阱。

• 假設(shè)容器化只有優(yōu)點(diǎn)?

在容器化的開(kāi)發(fā)環(huán)境中，最大的陷阱可能是假設(shè)你在部署中獲得的好處與開(kāi)發(fā)人員在本地體驗(yàn)到的好處是一樣的。

類似地，假設(shè)一個(gè)團(tuán)隊(duì)希望與 Docker 密切合作，這種假設(shè)可能不適用于你的團(tuán)隊(duì)。如果你的開(kāi)發(fā)人員與操作工作相對(duì)孤立，那么他們可能不希望每天都在本地使用容器，這可能不是一個(gè)嚴(yán)謹(jǐn)?shù)募僭O(shè)。但是，如果你處在一個(gè)開(kāi)發(fā)人員正在進(jìn)行一些操作工作的團(tuán)隊(duì)中工作，那么假設(shè)你提供了僅僅是容器化開(kāi)發(fā)環(huán)境的其他替代方案，那么這對(duì)你的團(tuán)隊(duì)有好處。

在本地運(yùn)行容器會(huì)消耗大量資源。僅在我的機(jī)器上，在一個(gè)典型的工作日，Docker 就要消耗大約 36GB 的存儲(chǔ)空間。我不會(huì)說(shuō)對(duì)于我的特定品牌和型號(hào)的工作站來(lái)說(shuō)系統(tǒng)使用量是非常大的，但是我可以很容易地看出，當(dāng)我在工作流中包含更多的容器時(shí)，系統(tǒng)使用量會(huì)大大增加。在我的活動(dòng)監(jiān)視器中，Docker 也是占用 CPU、內(nèi)存和磁盤(pán)資源最多的。?

更重要的是，盡管這可能不會(huì)給我的機(jī)器帶來(lái)沉重的負(fù)擔(dān)，但這并不意味著它與其他機(jī)器很好地匹配，而且最終決定將如此多的資源分配給 Docker 應(yīng)該取決于開(kāi)發(fā)人員自己的個(gè)人偏好。也就是說(shuō)，你的筆記本電腦不是服務(wù)器，它可能不需要根據(jù)服務(wù)器標(biāo)準(zhǔn)構(gòu)建的容器資源。

但是，即使超出了系統(tǒng)資源，開(kāi)發(fā)人員環(huán)境也不能很好地與運(yùn)行你的代碼的系統(tǒng)保持一致。在過(guò)去，這種差異是如此之大，以至于我們經(jīng)常不得不進(jìn)入一個(gè)與我們的生產(chǎn)服務(wù)器完全一樣的環(huán)境，而且我們中的一些人(不幸的是，包括我自己在內(nèi))如果出現(xiàn)嚴(yán)重錯(cuò)誤的話，甚至不得不在這些系統(tǒng)上進(jìn)行實(shí)時(shí)代碼更改！?

開(kāi)發(fā)人員需要專注于編寫(xiě)可維護(hù)、可靠和經(jīng)過(guò)良好測(cè)試的代碼。我認(rèn)為，在有限的環(huán)境中工作可以有更好的代碼實(shí)踐和決策ーー你不得不依賴于編寫(xiě)整潔的、可維護(hù)和可操作的代碼，而不是希望服務(wù)器以這種方式配置來(lái)處理性能瓶頸和低效的實(shí)現(xiàn)。?

開(kāi)發(fā)人員在工作時(shí)已經(jīng)有很多需要構(gòu)建和維護(hù)的上下文。如果你的本地 Docker 環(huán)境將這種上下文作為為判斷容器是否正在運(yùn)行，那么從長(zhǎng)遠(yuǎn)來(lái)看，只會(huì)讓你失望了。

類似地，要求開(kāi)發(fā)人員使用 `docker run` 命令啟動(dòng)容器會(huì)增加上下文切換的開(kāi)銷。在本地環(huán)境中開(kāi)發(fā)時(shí)，開(kāi)發(fā)人員已經(jīng)建立了某種模式，而使用容器不僅與這些模式背道而馳，還需要對(duì) `docker` CLI 本身有更多的掌握，這就給開(kāi)發(fā)人員實(shí)現(xiàn)目標(biāo)制造了阻力。當(dāng)我不得不使用 Docker 容器來(lái)調(diào)試某些東西時(shí)，我也不禁感到有點(diǎn)奇怪。它有點(diǎn)像我之前提到過(guò)的一個(gè)錯(cuò)誤: 進(jìn)入生產(chǎn)服務(wù)器。

這種啟發(fā)式方法與其他服務(wù)緊隨其后。如果你所在的團(tuán)隊(duì)都在使用微服務(wù)，而其他團(tuán)隊(duì)需要各種各樣的服務(wù)來(lái)構(gòu)建自己的特性，那么你應(yīng)該謹(jǐn)慎地將這些鏡像作為容器提供。在這些情況下，團(tuán)隊(duì)在自己的環(huán)境中支持服務(wù)本身實(shí)際上可能比用容器模糊服務(wù)更有益。

對(duì)于這些特定的內(nèi)部服務(wù)，可能值得對(duì)為此服務(wù)提供的文檔進(jìn)行審計(jì)，而不是對(duì)其進(jìn)行容器化。維護(hù)不良的文檔與容器結(jié)合在一起會(huì)產(chǎn)生諸多認(rèn)知失調(diào)，從而導(dǎo)致放棄 Docker 環(huán)境的挫敗感。我們所有人都應(yīng)該更仔細(xì)地查看我們的文檔，并經(jīng)常對(duì)其進(jìn)行審計(jì)，而不是構(gòu)建新的東西。?

我上面提到的調(diào)查結(jié)果顯示，Nginx、 Redis 和 Postgres 在擁抱的團(tuán)隊(duì)中非常受歡迎。很明顯，為什么這些東西如此受歡迎。除非你的團(tuán)隊(duì)從事編寫(xiě)自己的 RDBMS 或 web 服務(wù)器 / 負(fù)載平衡器的業(yè)務(wù)，否則你將通過(guò)在堆棧中利用類似這樣的開(kāi)放源碼應(yīng)用程序而獲益匪淺。

直到徹底的容器化，你的運(yùn)營(yíng)團(tuán)隊(duì)可能無(wú)法獲得與開(kāi)發(fā)團(tuán)隊(duì)在決定將其包含在技術(shù)棧中獲得的相同收益。通過(guò)容器化這些依賴關(guān)系，運(yùn)營(yíng)團(tuán)隊(duì)可以從一種類似的加速器中受益，這種加速器無(wú)需編寫(xiě)自己的 RDBMS 即可為開(kāi)發(fā)人員提供幫助。

容器化 Postgres 提供了大量用于部署，監(jiān)視和擴(kuò)展此關(guān)鍵依賴性的選項(xiàng)。它還減少了一些更新，升級(jí)和管理該系統(tǒng)的開(kāi)銷。這對(duì)運(yùn)營(yíng)團(tuán)隊(duì)來(lái)說(shuō)非常有用，但這是否符合開(kāi)發(fā)人員的需求？?

總而言之，即使簡(jiǎn)單地運(yùn)行 `docker-compose up -d` 后臺(tái)啟動(dòng)并運(yùn)行容器，它也不能很好地與絕大多數(shù)開(kāi)發(fā)人員用于本地運(yùn)行環(huán)境的心智模型協(xié)同工作。這兩種工作流程之間有著本質(zhì)的差異。

開(kāi)發(fā)人員希望能夠深入挖掘他們需要的抽象概念，而要求團(tuán)隊(duì)使用一個(gè)全新的工具，用一種完全不同的方法來(lái)運(yùn)行他們的本地環(huán)境，是一個(gè)很高的要求。具體來(lái)說(shuō)，開(kāi)發(fā)人員需要能夠運(yùn)行數(shù)據(jù)庫(kù)遷移、跳轉(zhuǎn)到數(shù)據(jù)庫(kù) CLI 并跟蹤數(shù)據(jù)庫(kù)日志。對(duì)于堆棧中的任何關(guān)鍵組件也是如此。

這并不是說(shuō)沒(méi)有開(kāi)發(fā)人員樂(lè)意在本地使用 Docker 。但是我敢打賭，使用 Docker 的開(kāi)發(fā)人員已經(jīng)知道如何讓它在他們的工作流中無(wú)縫地工作，不管他們是剛剛做了一個(gè)習(xí)慣性的改變，還是他們已經(jīng)編寫(xiě)了腳本，以便更好地與他們自己的環(huán)境一起工作。

?

圍繞容器命令編寫(xiě)新穎的腳本

?

說(shuō)到腳本，如果你正在構(gòu)建一個(gè)這樣的本地環(huán)境，并且你正在試圖減少必須由 `docker run 處各種事情的開(kāi)銷，那么你最初的沖動(dòng) (像我一樣) 可能是編寫(xiě)許多與基于容器的工作相關(guān)的死記硬背的任務(wù)。?

這種偏好并不一定是被誤導(dǎo)的。畢竟，我們被教導(dǎo)用腳本去掉冗余的任務(wù)，這樣我們就可以減少重復(fù)工作。但是要注意尤其在你的團(tuán)隊(duì)對(duì)容器了解不深的情況下，不要過(guò)多地使用腳本。?

我提到過(guò)使用 `Docker` CLI 會(huì)產(chǎn)生開(kāi)銷，但是如果有一個(gè)開(kāi)發(fā)團(tuán)隊(duì)積極地使用容器，那么為他們提供使用 Docker 自己的工具的時(shí)間和培訓(xùn)可能會(huì)更有意義，而不是潛在地模糊 Docker 本身的內(nèi)部工作。這確實(shí)是一個(gè)必須掌握的工具，但是通過(guò)避免圍繞這些命令編寫(xiě)新穎的腳本，你可以減少在故障排除和對(duì)工具本身的更廣泛理解上的認(rèn)知壓力。

為了強(qiáng)調(diào)我對(duì)定制容器包裝程序的最高的關(guān)注，圍繞容器的新穎腳本產(chǎn)生了更多的代碼，從而需要維護(hù)更多東西。我要說(shuō)的是，如果小組確定這對(duì)其工作流程是有利的，你可以繼續(xù)這么做。尤其是在新人入職過(guò)程中，希望大家可以避免編寫(xiě)那些注定被遺棄或某種場(chǎng)景定制的特定腳本，從而耗費(fèi)大把的時(shí)間。

除了 Docker 化，別無(wú)選擇

如果你對(duì)容器化的開(kāi)發(fā)環(huán)境感興趣，我認(rèn)為你應(yīng)該花很多的時(shí)間為本地運(yùn)行系統(tǒng)構(gòu)建簡(jiǎn)單的替代方案。換句話說(shuō)，不要認(rèn)為在本地環(huán)境中使用 Docker 是一個(gè)非此即彼的決定。記錄在標(biāo)準(zhǔn)本地部署中設(shè)置應(yīng)用程序的步驟，以及為那些對(duì)運(yùn)行容器感興趣的人提供替代方案。讓你的團(tuán)隊(duì)判斷這個(gè)工作流程是否適合。?

總而言之，在不進(jìn)行開(kāi)發(fā)環(huán)境的權(quán)衡的情況下全部使用容器將給你的開(kāi)發(fā)團(tuán)隊(duì)帶來(lái)負(fù)擔(dān)。

?

結(jié)束

?

沒(méi)有正確搭建開(kāi)發(fā)環(huán)境的統(tǒng)一的模式。雖然鼓勵(lì)你的團(tuán)隊(duì)擁抱容器化可能會(huì)帶來(lái)一些好處，但最終的目標(biāo)還是應(yīng)該放在改善開(kāi)發(fā)人員的工作流程。如果我們?yōu)榱思夹g(shù)抽象而犧牲了編寫(xiě)優(yōu)秀代碼的能力，那么我們就是在降低效率。

不管是選擇傳統(tǒng)的還是容器化的開(kāi)發(fā)環(huán)境，都不應(yīng)該讓個(gè)人的喜好所左右，最終應(yīng)該讓整個(gè)團(tuán)隊(duì)一起做決定。如果你能和團(tuán)隊(duì)一起找出本地開(kāi)發(fā)存在的痛點(diǎn)，就能夠幫助你準(zhǔn)確評(píng)估是采用本地開(kāi)發(fā)還是容器化。

原文：https://blog.testdouble.com/posts/2020-02-11-the-slippery-slope-of-docker-dev-environments/

本文為 CSDN 翻譯，轉(zhuǎn)載請(qǐng)聯(lián)系我們。

推薦閱讀：DevOps：從「蒸汽時(shí)代」到「高鐵時(shí)代」，SUNMI DevOps轉(zhuǎn)型之路 | 原力計(jì)劃 Hive 熱門(mén)數(shù)據(jù)分析面試題解析 2 萬(wàn)字長(zhǎng)文詳解 10 大多線程面試題｜原力計(jì)劃 深度學(xué)習(xí)“三巨頭”、圖靈獎(jiǎng)得主 Yann LeCun：我沒(méi)有天賦，所以才追隨聰明人 檢測(cè)、量化、追蹤新冠病毒，基于深度學(xué)習(xí)的自動(dòng)CT圖像分析有多靠譜？ 來(lái)，讓我們逐一澄清以太坊 2.0 五大誤解 真香，朕在看了！

總結(jié)

以上是生活随笔為你收集整理的Docker 开发环境的滑坡的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。