容器技術標準化大統一，OCI V1.0 正式發佈！｜航海日誌 Vol.21

​

➤ 容器技術標準化大統一，OCI V1.0 正式發佈！

在過去幾年中，容器技術被你們關注，使用率也在不斷升高。幾乎全部的主要技術供應商和雲提供商都宣佈了以容器技術爲基礎的解決方案，而且在這一領域也成立了許多的新興企業。容器做爲應用程序可移植性的來源的保證也須要創建必定程度的標準，確保中立性。

因此就誕生了OCI（Open Container Initiative），其目標是圍繞容器技術制定共同的、最低限度的開放標準和規範。 我很自豪地說，在經歷了無數艱辛以後，咱們已經達到了咱們第一個關鍵的里程碑：7 月 19 日 OCI v1.0 正式發佈！

該版本將一組通用的、最小的、開放的標準和規範帶到了一個現實的容器技術中, 包含了圖像格式規範 （容器鏡像格式的規範）和運行時規範 （管理容器運行週期的規範）。規範的開放性在整個行業中造成了一套真正的共享標準, 從而減小了互操做性問題和沒必要要的資源浪費。

➤ 如何說服你的老闆或經理使用 Docker ？

我是一個 learning by example 的忠實擁護者，而不是須要「你須要將營銷方案從開發人員的滿意度轉化爲可量化的業務指標」這樣的提示的愛好者，我只是列出了一些常見的 DEV/OPS 問題， 而後列出 Docker 如何解決這兩我的羣的問題。

這樣，您可使用一組可用於一系列不一樣 Docker 的問題，您能夠根據您的老闆或經理的技術以及適用於您的方式選擇使用哪些解決方案。 隨意作本身的調整！

此外，值得一提的是，這些能夠從新設計用於幾十個用例的更改，這就是爲何我沒有列出每一個可能的問題/解決方案。

1. 如何在開發過程當中管理多個項目

技術問題：

在個人開發機器上管理多個項目真的很痛苦，由於像 rvm，virtualenv，nvm 和 phpbrew 這樣的工具使人困惑，使用起來很麻煩，特別是當我須要升級不一樣項目中的語言版本和依賴項時。

這能夠從新定位爲「創建開發環境弊端」問題。

技術方案：

使用 Docker，您能夠將這些工具丟棄。 Docker 將您的應用程序打包成一個獨立的「 Docker 映像」。您能夠爲每一個應用程序建立一個圖像，若是每一個應用程序使用不一樣的語言版本，這些都不重要。升級或更改版本是1行更改。

2. 讓新加入開發人員加快速度

技術問題：

試圖在項目上開發新的開發人員花費的時間不合理，涉及到多我的每次都要排除多個問題。不只如此，咱們正在努力使文檔保持最新。沒有人想去看一個極其複雜的操做手冊。

這能夠被從新設計爲「它適用於我！」的問題。

技術方案：

一旦你「獲得」 Docker，你會看到如何使用一個簡單的工具來運行和管理整個項目。新開發者只須要運行一個命令並放鬆，由於該命令將本身構建並啓動最複雜的應用程序。初始設置時間也是最小的。

3. QA / Production 中出現意外問題

技術問題：

當涉及部署代碼時，會出現各類平臺特定的問題和應用程序級錯誤。因爲開發和生產之間的創建過程有很大的不一樣，因此有一百萬種方法出錯。系統包和進程之間的微妙版本差別是根本緣由。

這能夠被從新設計爲「部署困難」的問題。

技術方案：

因爲 Docker 能夠輕鬆構建和分發應用程序，您能夠跨環境移動完整的工做包。這意味着在開發中運行的代碼與生產中運行的代碼相同。

不管是在 MacOS，Windows 仍是 Linux 下開發都不要緊。它將在任何操做系統上運行（即便是在您的服務器上不一樣的 Linux 發行版）。

➤ 演講推薦：Kubernetes 最佳實踐

Kubernetes 是一款強大的工具，他能夠真正簡化您的操做。可是，存在着許多很是常見的陷阱，可能能會破壞你的體驗。推薦給你一個有關「Kubernetes 最佳實踐」的演講，其中會分享一些關於構建和部署容器的最佳實踐，讓您更穩定，高效，安全地進行運行。

PPT 地址：https://speakerdeck.com/thesandlord/kubernetes-best-practices

➤ 如何監視 Mac / Windows 的 Docker

監控功能如今能夠在 Docker for Mac / Windows 中使用。 咱們再也不須要猜想咱們的開發或測試環境的性能。

有些人可能會問一個問題，咱們爲何要監控咱們的本地 Docker 環境。 對於初學者來講，監視全部事情是直觀的。 第二，爲了真正瞭解你的環境，咱們須要剖析運行中的內容以及運行方式。 最後，瞭解環境以及是否影響工做負載的性能是一個很好的作法。

監控 Mac / Windows 後臺程序的 Docker

咱們開始配置您的安裝。 如下屏幕截圖來自 Mac，但步驟應該適用於 Windows 。 咱們如今將在咱們的 Docker for Mac / Windows 上啓用 Daemon 指標，格式爲 Prometheus

1. 打開Docker for Mac / Windows Preferences菜單

2. 導航到 Daemon 程序菜單，而後單擊高級

3. 在代碼框內，咱們將添加一條額外的行來啓用指標。 在調試語句下面添加如下代碼行：「metrics-addr「：」0.0.0.0:9323「

4.點擊Àpply＆Restart，等待Docker重啓。測試出來 打開一個帶有如下URL的瀏覽器選項卡：http://127.0.0.1:9323/metrics

- 使用 Prometheus 監視

- 配置 Grafana

➤ Docker 羣模式羣集中的消費服務

本教程是 Docker Swarm 容器編排系列中的第三個。第一個教程介紹瞭如何引導 Docker Swarm Mode 羣集，第二個教程介紹瞭如何在 Swarm 羣集中調度工做負載。本教程將探討 Swarm 羣集內部和外部的服務消耗問題。

當咱們將微服務部署在諸如 Docker Swarm 羣集之類的計算集羣上的容器時，相當重要的是咱們有一個服務發現方法來調用。對咱們有效消費服務的能力相當重要。

正如咱們在本系列的前一篇文章中所學到的，咱們委託平臺的調度功能在整個集羣的節點上分發咱們的服務。若是一個服務須要消耗在集羣中運行的另外一個服務，它如何知道在哪裏找到它？服務能夠縮放，消費者服務如何知道組成提供服務的哪一個容器來解決以消費服務？若是咱們縮小了服務範圍，那麼咱們如何確保服務請求在整個服務的容器中獲得最佳的平衡？集裝箱是短暫的，來來去去。消費者服務如何跟蹤哪裏能夠解決其服務請求？

關於內部服務提供和消費的全部這些問題一樣適用於在羣集上運行的服務的外部消費者。

這些問題與服務發現技術有關，並被解決。 Docker Swarm 和 Kubernetes 等容器協調平臺爲基於容器的服務抽象提供內置服務發現。

這一期的『航海日誌』就到這裏，下期再浪～

參考連接

• https://www.opencontainers.org/blog/2017/07/19/oci-v1-0-bringing-containers-closer-to-standardization

• https://blog.docker.com/2017/07/title-moby-summit-alongside-open-source-summit-north-america/

• https://speakerdeck.com/thesandlord/kubernetes-best-practices

• https://www.brianchristner.io/how-to-monitor-docker-for-mac-windows/

• https://semaphoreci.com/community/tutorials/consuming-services-in-a-docker-swarm-mode-cluster

做者介紹

夏巖：DaoCloud 技術顧問，僞の全棧工程師 && 語言愛好者。

上期回顧：

自顧不暇的系統管理員如何面對開發人員的「Challenge」？｜航海日誌 Vol.20