各大公司使用哪些容器技術和工具？

您的組織是什麼時候開始使用容器的，他們如何改變了您的開發工作流程？
們於 2018 年初開始將 Datadog 遷移到 Kubernetes，大約六個月後，Datadog 的第一個版本在生產環境中完全執行在 Kubernetes 中。這包括無狀態 Web 應用程式和有狀態資料服務，如 Cassandra 和 Kafka。我們正在從使用 Chef 管理的 VM 中執行的應用程式遷移，因此轉換需要對我們的開發過程進行許多更改。例如，我們必須對每個應用程式進行容器化，並提供一個解決方案來部署到 Kubernetes 叢集，這最初依賴於 Spinnaker 和 Helm 圖表。遷移具有挑戰性：截止日期是雄心勃勃的，我們從一個沒有容器也沒有工具來部署它們的環境開始。但這也是有益的，因為它使我們能夠擁有統一的打包和部署解決方案，
— Laurent Bernaille，Datadog

大約兩年前，我們開始使用容器，作為我們努力成為多雲的一部分。這是經過近一年的初步探索。容器起初增加了一些複雜性，特別是在配置方面，但隨著我們構建工具，某些方面也變得更容易。例如，過去的配置來自 Chef，這需要更嚴格的更改許可權。透過將 Chef 資料包配置移至 Sops，我們為開發人員實現了更簡單的自助更改。
— 克里斯·羅格斯，佈雷茲

在 2015 年之前，我們使用基於 VM 的開發環境，然後由於本地依賴項的挑戰而切換到容器，這些依賴項在本地編譯並易於跨越升級。切換到容器解決了這個問題——我們能夠無縫遷移，而不會對我們的開發工作流程產生負面影響。它還使我們的開發環境更加現代化和生產化，並且資源密集度更低。 
— 布萊恩·希克森，BetterUp
 

您的組織是否將任何遺留應用程式遷移到容器？有哪些挑戰，你學到了什麼？ 
我們的大多數應用程式都是用 Go、Python 和 Java 編寫的，因此在容器中執行它們並不困難。當然，魔鬼在細節中，我們面臨著幾個挑戰，包括管理容器中 JVM 的記憶體佔用。大多數應用程式假設它們是唯一在 VM 上執行的應用程式，這帶來了自己的挑戰——尤其是在 IO 操作（磁碟和網路訪問）方面，因為 Kubernetes 在共享 CPU 時間和記憶體方面非常有效。使用 IO 執行此操作更為複雜，其中 Kubernetes 對如何限制和隔離資源消耗的控制較少。我們注意到，將應用程式遷移到 Kubernetes 後，我們需要兩倍數量的主機。一旦我們分析了應用程式並分析了開銷，
— Laurent Bernaille，Datadog

 我們已將幾乎所有遺留應用程式遷移到容器。對應用程式進行 Docker 化相對簡單，並且在大多數情況下使打包依賴項和部署更容易。以前，DevOps 管理 EC2 例項應用程式被複制到並透過 Chef 執行。透過將應用程式移動到容器中，應用程式工程師可以更直接地控制應用程式在哪些環境中執行、哪些工具和庫可用，以及如何分配資源。 
挑戰主要在於將部署管道的職責從 DevOps 轉移到應用程式工程團隊，以及在 Kubernetes 中除錯應用程式的知識，而不是在 EC2 例項上。然而，所有這些都具有顯著的長期好處，消除了來回更改的需要，並使程式碼與其執行的環境更緊密地耦合。
— 克里斯·羅格斯，佈雷茲

我們使用容器來試驗 ML 微服務。我們提取了主要應用程式的一小部分，並使用更適合的技術堆疊快速推出新服務。這允許快速迭代和實驗。例如，我們能夠將在 R 中使用貝葉斯方法訓練的模型無縫替換為在 Python 中使用神經網路的模型。 
我們在從單體應用中分離服務時面臨的一個挑戰是服務不再可以直接訪問實時應用程式資料。我們必須確定微服務將保留對哪些資料的訪問許可權，並瞭解到服務越接近實時，它就越需要訪問上下文資料。 
— 布萊恩·希克森，BetterUp
 

您如何部署和監控容器化應用程式？您的關鍵健康指標是什麼？
我們依靠 Datadog 進行監控。每個應用程式負責配置其監控，但一些關鍵指標無處不在：容器 CPU 和記憶體使用情況、容器狀態和重啟次數，以及底層節點的健康狀況。 我們最初使用 Spinnaker 來部署容器化應用程式，這在早期提供了強大的基礎，但隨著叢集數量的增加和工作流程變得更加複雜，我們的規模越來越大。我們目前正在為多叢集部署開發一個內部解決方案，該解決方案利用 Helm 和雲原生應用程式包，由 Temporal 提供支援。
— Laurent Bernaille，Datadog

我們主要關注記憶體和 CPU、標準 Kubernetes 監控以及特定於應用程式的指標，如內部佇列大小和錯誤率。應用程式透過 Helm 部署，使用內部工具在配置更改時透過 Jenkins 向 Helm CLI 提供部署配置（GitHub 儲存庫中的 YAML）。 
— 克里斯·羅格斯，佈雷茲

當構建透過我們的主分支時，我們使用 Heroku 來持續部署我們的應用程式。我們使用 Heroku 和日誌服務——Pingdom 和 New Relic，結合 PagerDuty 發出警報——這使我們能夠調查生產系統中的問題，並在檢測到問題時提醒我們的團隊。我們還使用合成和真實使用者監控來檢測災難性錯誤和效能問題。作為一個團隊，我們使用 KPI 來跟蹤我們基礎架構的趨勢。一項關鍵的健康指標是伺服器正常執行時間，2020 年為 99.999%。
— 布萊恩·希克森，BetterUp
 

您的組織如何進行容器測試？您如何利用自動化？
我們不對容器進行系統測試。相反，我們在 CI 中測試應用程式並在暫存和使用金絲雀中驗證新的容器版本。當我們懷疑容器化會影響容器時，我們還會對容器進行臨時測試 - 特別是無法透過程式碼庫更改來解釋的效能迴歸。
— Laurent Bernaille，Datadog

我們的許多應用程式都是透過 Docker Compose 在本地開發和測試的。我們還在執行容器化應用程式部署的開發和暫存環境中每天多次執行端到端測試。CI——我們使用 Buildkite——也在 Docker 內部執行測試，它會根據應用程式程式碼的更改自動執行。
— 克里斯·羅格斯，佈雷茲

我們的測試容器配置為與我們的生產環境相匹配。我們不直接測試容器本身，但我們的持續測試過程可確保應用程式行為在各個分支之間保持一致。
— 布萊恩·希克森，BetterUp
 

您的組織如何跟上容器生態系統的變化？您如何決定何時採用新技術或工具？
由於我們大規模使用 Kubernetes 並面臨生態系統剛剛開始解決的挑戰，因此我們傾向於在很早的時候測試並採用新技術，當測試成功時。例如，我們在獲得容器執行時介面後立即對 containerd 進行了標準化，並且出於可擴充套件性原因，當它在測試版中可用時，我們在 IPVS 模式下使用了 kube-proxy。最近，我們為 pod 網路、服務負載平衡和網路策略標準化了 Cilium。
— Laurent Bernaille，Datadog

我們的工程師關注整個行業的變化。他們經常鼓吹改變以嘗試新方法，包括在我們的內部駭客日進行概念驗證演示，以探索和衡量其他人的興趣。他們關注 AWS 公告、Kubernetes 公告和任意數量的技術新聞來源，以瞭解新選項。他們在遇到問題時尋求解決方案，並想象“更好”可能是什麼樣子。例如，我們對透過使用 Spot 例項自動配置例項來節省成本進行了大量研究。
— 克里斯·羅格斯，佈雷茲

我們依靠工程師來發現改進容器使用方式的機會，並權衡成本與潛在價值或需求。例如，最近我們的前端和全棧工程師遇到了 Docker for Mac 的檔案系統效能問題。我們的一位工程師研究了使用 Docker 改進 IO 的技術，並試驗了 Mutagen、NFS 和其他用於在本機系統和 Docker 之間共享檔案的技術。最終我們在整個團隊中採用了 Mutagen，這顯著改善了開發者體驗。前端容器的構建時間不再是個人開發人員生產力的拖累。
— 布萊恩·希克森，BetterUp
 

您的組織發現使用容器最令人驚訝的是什麼？
我們遇到了很多令人驚訝的挑戰，從控制平面可擴充套件性問題到低階執行時或網路問題。不過，總的來說，Datadog 在採用容器方面取得的巨大成功是，它允許我們使用通用抽象跨多個雲提供商進行擴充套件和部署。
— Laurent Bernaille，Datadog

為 localdev 構建的容器需要額外的除錯工具，這在生產中是不受歡迎的。生產中的除錯比本地除錯要困難得多，尤其是在託管容器的伺服器上使用細粒度訪問控制列表時。在容器中準確地在本地複製面向服務的架構可能會使膝上型電腦的 CPU 和記憶體不堪重負，這會導致仍然缺乏保真度的捷徑，例如無法執行“真正的”Kubernetes 叢集或相同的配置。CI 構建容器的方式與它們在本地構建的方式不同，並且可以輕鬆包含本地不存在的內容，這些內容可能難以除錯或識別。
— 克里斯·羅格斯，佈雷茲

容器使我們能夠在一個雲提供商上訓練新的 ML 模型，並在我們準備將它們與我們的主要應用程式整合時輕鬆遷移到另一個。我們還驚訝於我們遇到的與容器本身相關的問題如此之少。任何問題通常都處於比容器級別更高的抽象級別；例如，我們在部署應用程式的方式中發現了錯誤，但它們並非特定於我們對容器的使用。 
— 布萊恩·希克森，BetterUp