➤ 容器技術標準化大統一，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
