一千萬個為什麽

搜索

為什麽開發人員應該關心Docker?



通常,開發人員會關心滿足業務需求。他/她可能擁有特定堆棧或框架的專業知識。但是,他/她應該努力學習docker,它的各種部署方法(swarm,kube,mesos等)?

簡單地說,開發人員為什麽應該關心docker?

PS : The parent question to this post is Implication of introducing docker to the development team

轉載註明原文: 為什麽開發人員應該關心Docker?

一共有 7 個回答:

可能不是你正在尋找的答案,但答案仍然:)

通過將Docker及其部署方法與代碼語言,版本控制系統,編譯器,測試基礎架構等結合起來,將其作為項目或團隊開發環境的一部分,可以將它們包含在業務需求中,該團隊或該項目需要了解並使用所有這些項目,不能“自帶”(在大多數情況下)。

如果你是一個開發者,你實際上是指大多數甚至整個開發團隊,事情會變得更加復雜。在開發環境中推出一個工具,但實際上沒有任何開發人員支持它,這將非常困難。花時間從團隊的技術領導中首先創建一個這樣的支持者。

註意:團隊中的每位開發人員都可能不需要成為碼頭專家。預先制定的使用方法包裝在簡單的,可作弊的命令中,通常允許開發人員使用基於docker的解決方案,而無需真正了解其內部運作情況,這可能是相當可接受的,特別是在大型團隊中。就像能夠在不知道有關最終產品如何構建的所有細節的情況下提供代碼一樣。

我會給你我的觀點。開發人員應該關心碼頭工人,因為有其他開發人員願意使用碼頭工具,並且已經在其中建立了專業知識。他們願意擔任DevOps工程師並擔任開發人員。所以DevOps的Ops部分就是他們現在正在建立的專業知識。

現在,你會發現越來越多的人可以開發,編排,自動化測試,自動化作業和構建工具來監控和單獨完成這個完整的軟件包。這些人是在開發人員社區中推動docker和其他工具的人。

另外,市場的趨勢是虛擬化,自動擴展,自動化,機器學習和碼頭工具適合所有這些。使用docker變得非常必要。企業願意為一個承擔所有這些責任的單身人士支付2倍的費用,當有這種人需求時,供應也將開始。這是從雇員雇主的角度來看的。

從技術上講,在我工作的組織中,雖然他們非常密切地進行交付,但還是有獨立的開發和DevOps團隊。 DevOps的工程師和開發人員在這裏分享絕大多數的技能,因此有時會進行職責談判。

開發人員可以做的最低限度是分享他的二進制文件,但他需要了解二進制文件將用於在碼頭集裝箱內運行,並且他需要了解碼頭工作的方式。對於kubes,swarms,mesos等,開發人員甚至可能不在意使用什麽,但開發人員應該很好地理解docker的基本知識,並且從一開始就應該有一種思維模式來構建松散耦合的應用程序,以便重用微服務。如果應用程序是從該思維模式構建的(這需要Docker的基礎知識),那麽DevOps工程師可以從那裏開始自動擴展,協調,測試,部署和監視。

此外,大部分時間都沒有適合所有類型的東西。開發人員並不清楚如何構建一個適合Docker的應用程序,DevOps工程師完全不知道應用程序構建過程的內部結構。因此,大多數時候,組織都喜歡將這兩項任務交給同一個人來加速。如果存在單獨的事情,那麽DevOps團隊需要持續的反饋機制,以使開發團隊為應用程序提供更多未來和Docker /雲/擴展的準備。

這不是關於Docker或任何其他集裝箱技術。

Docker,rkt等容器只是以類似於靜態二進制的方式提供應用程序的方式。您正在構建您的部署,其中包含它所需的所有內容,並且最終用戶不需要運行時以外的任何內容。

These solutions are similar to fat JARs in Java, where everything you (in theory) need is just runtime (JRE) preinstalled and everything Just Works™.


開發人員需要理解的原因(他們不需要學習如何操作這種工具,只需要這種工具)編排工具的原因是,這使得您可以比“傳統”部署有一些優勢。

牛,不是寵物

EngineYard have written good article about that. Whole point of that is that when your server dies, then you shrug and wait as new will appear. You treat them as cattle, you have tens, hundreds, thousands of them running and when one goes down neither you or your clients should be ever aware of that.

編排工具通過監視群集中所有應用程序(pods/jobs,無論)的狀態,以及當它看到其中一臺服務器停止響應(停止)時,它自動將所有在該服務器上運行的應用程序移動到別處。

更好的資源利用

感謝編排,您可以在一臺服務器上運行多個應用程序,編排器將為您追蹤資源。它會在需要時重新安排應用程序。

不變的基礎設施

由於協調器中的自動故障轉移處理,您可以按原樣在雲中運行自定義映像。當您需要更新時,您只需構建新映像,將您的啟動配置設置為現在即可使用,然後滾動。一切都會為你處理:

  1. 使用新配置創建新服務器。
  2. 殺死一臺正在運行的服務器。
  3. 您的orchestrator會將所有內容移至其他機器(包括新機器)。
  4. 如果還有舊的服務器,請轉到1。

更簡單的操作

  • 資源不足?將新機器添加到群集。
  • 需要更多應用程序實例嗎?增加數量並繼續。
  • 監測?完成。
  • 日誌管理?完成。
  • 秘密?猜猜看。

TL;DR Whole point isn't about Docker but about orchestration. Docker is just a extended version of tarball/fat JARs that is required for proper orchestration.

如果您正在Docker容器中運行您的產品,那麽這些容器由構建應用程序的相同開發人員制作是至關重要的。 還有誰是更好的地方知道需要什麽樣的外部依賴,等等......?

此外,在CD期間,流水線可能會在任何步驟失敗,特別是當它是docker映像構建步驟時,有時它會丟失文件或需要lib。

在工作中,我們向Docker介紹了所有開發人員,向他們解釋構建dockerfile的基礎知識以便為其應用程序提供服務,同時我們也簡化了管道,因此只能添加一個名稱和一個dockerfile,並且其應用程序將自動構建接下來不管運行它的技術如何。

在devOps團隊指導開發者選擇發行版之後(他們中的很多人不知道諸如 alpine 之類的東西)之後,Docker quickstart真的是一個很好的介紹。

我們的工作是為他們提供一種方便的工具訪問方式,他們會做好其他工作,以便在出現問題時能夠解決問題。 Docker實際上是開發過程的一部分,devOps團隊為他們提供了符合我們需求的泊塢窗圖像,而且這些圖像非常簡單,因此只需幾分鐘即可創建新應用程序並在無需幫助的情況下進行部署。

Docker獲得了大量的新聞和博客文章,從而導致開發人員對其使用感興趣。對於一些人來說,玩新技術或理解事物如何運作是有興趣的。對於其他人而言,希望將關鍵字添加到他們的簡歷中。無論哪種方式,越多的開發人員知道事情的工作方式以及他們如何部署,他們以後會越少感到驚訝。從我所看到的情況來看,在這方面存在著相當多的預先存在的興趣,所以不應該那麽難以進一步鼓勵它。

例如,這裏有一些來自2014年發布的博客帖子的一些論點,其標題與您的回答非常相似:

  • Much more flexible injection of new technologies into the environment
  • there is still a massive pain point between committing the final tested code and then getting it running on the final production servers. Docker vastly simplifies this final step
  • Docker makes it trivial to keep legacy OS, no matter what flavor of Linux you are running

From: https://thenewstack.io/why-you-should-care-about-docker/

那麽,如果你曾經使用虛擬機進行測試,你可能想嘗試使用容器,而docker實際上是一個很好的測試工具,而且它更簡單,而不是使用LXC :)