一千萬個為什麽

搜索


我最近和一位同事進行了一次有趣的討論。我們對開發Docker容器需要什麽有不同的觀點。我不會說誰相信什麽,以免妨礙反應。這裏有兩個相互競爭的斷言:

Assertion 1:
It is not necessary to install Docker on development workstations. Container build is a CI task that can be performed by a CI tool, then containers can be troubleshot/debugged in a DEV environent.

Assertion 2
It is critical for developers to run Docker locally so they can smoke test and execute containerized processes before they are committed to SCM or CI. Containerization is a core developer skill, which is specialized by development platform.

在開發容器化工作負載的開發人員工作站上安裝Docker是關鍵,有用還是沒有必要?

轉載註明原文: Docker開發工作站

一共有 4 個回答:

有人對每個問題都說,總是有三個答案。所以這是你的第三個答案。

在dev機器上安裝docker,並用它構建圖像。

可是:

圖像應該包含您在通常的編輯 - 構建 - 測試 - 運行周期中更改的源代碼或任何。圖像只需要包含 構建/測試/運行部件的基本內容。

也就是說,如果您要開發Maven應用程序,那麽您的圖像/容器將包含 mvn 命令及其所有的depdendencies。第二個圖像/容器將包含您的 wildfly 或您用作應用程序服務器的任何內容。

如果您是在rails上開發ruby,那麽您將擁有一個包含所有能夠運行的圖像/容器 bundle exec rake cucumber ,另一個包含所有可運行的圖像/容器< code> rails s 或 rails c

例如,如果您想要升級應用程序服務器,那麽很少會重新創建映像,並且dev每次運行時它們肯定不會是 docker build '。這兩個圖像都不會包含屬於您的應用程序的任何內容。沒有源代碼,沒有 .war 文件,沒有針對ruby應用程序的預編譯資產或特定於應用程序的gem。這些將在啟動容器時作為卷裝入,並直接指向dev當前正在處理的任何本地目錄。

這樣,可以保證你的開發者使用與你的CI或產品完全相同的基礎環境。新的開發人員可以立即開始構建/測試/運行,並且不需要在主機上安裝任何東西。他們可以使用他們選擇的編輯器(如果他們希望使用像Eclipse這樣有很多魔力的東西並且想要編譯這些東西,那麽他們當然可以自由地這樣做 - 只要他們至少做一個粗略的檢查在推送之前,是否所有東西在碼頭變體中仍然有效)。

如果您希望將應用程序部署為完全自包含的Docker映像,那麽您可以自由地這樣做。您的CI服務器可以構建這些圖像。它應該使用您的開發人員使用的較小圖像作為基本圖像,顯然。

這給你一個很好的中等基礎,應該涵蓋一切。

斷言1:

  • Pro:保證構建環境符合預期
  • 缺點:它減慢了補丁驗證的速度。

斷言2: 恰恰相反的正反兩方面。

我主張讓開發人員在他們的系統上使用docker快速叠代修補或升級,並在CI管道中保留回歸和集成測試。這不是必需的,每個開發人員都應該能夠選擇是否只編寫代碼,從不在本地運行任何東西,或者如果他們想在工作站上運行整個測試套件。

所以這兩個斷言都是有效的,我認為沒有正當理由強制執行其中一個

作為 Twelve-Factor應用的粉絲,我建議在每個工作站上安裝Docker,遵循規則 X。 “開發/產品平價:保持開發,分期和生產盡可能相似”。

我鼓勵每個開發人員都負責生產可用於生產的軟件,因此在推送之前需要在本地進行測試。 CI是為了整合顧名思義,不是為了檢查任何個人貢獻,而是為了檢查幾個開發者貢獻之間的沖突。

恕我直言,它至少是一個很好的,如果不是至關重要的。但如果至關重要的話,這並不是出於第2號斷言所述的原因。

從CI完全復制容器化構建的能力對於重現和調試CI驗證中發現的一些問題,然後為它們開發和測試修復至關重要。

在提交潛在高風險更改的代碼之前,此類能力對於可選地運行部分或整個CI驗證也很有用。

而且,通常,開發工作站上的docker可以全面地減少開發和QA /登臺/生產環境之間的差異。

但是,在提交之前運行CI級驗證也可以在共享資源或臨時從CI系統借用的資源上完成,不一定在開發人員的工作站上,這在某些情況下甚至可能是令人望而卻步的 - 某些CI構建可能需要更多資源比那些典型的開發人員工作站上可用的那些。

但是,如果擁有這樣的能力,實際上開發人員可以很有誘惑力地執行這樣的驗證,試圖完全消除真正的CI執行中的回歸,我相信這在第二種斷言中是隱含的。但是,這將恕我直言,是次優 - 這種驗證仍然是孤立的,因此不能完全消除CI失敗(見

如果需要消除真正的CI執行過程中的回歸,那麽預先提交的驗證必須進行協調,理想的是集中化,自動化並且緊接著是自動提交。