贏得Docker挑戰最佳實踐
現代IT問題
許多企業IT團隊解決這兩個問題：
首先，開發者和運維者在優先順序上並不能總是達成一致。企業必須應對的挑戰將來自開發人員的程式碼和運維團隊的程式碼切換。這兩個團隊之間的關係很難和諧相處。
第二，將程式碼從一個地方遷移到另一個可以是很困難的。因為你沒有簡單的方法打包應用程式程式碼，包括你的系統依賴性。你在不同的作業系統，不同的虛擬機器或不同的IaaS上處理程式碼。
Docker最激動人心之處就是可以解決企業的這兩個問題。第一個問題似乎是確定的，因為開發人員和運維人員之間有著清楚的界限。開發人員考慮Docker容器內部發生的一切，運維人員思考容器外面發生了什麼。Docker讓這一切變得更加簡單和方便，這是一個非常行動式的解決方案。
至於第二個問題，Docker通過使你在單個應用程式程序打包一切與你相關的應用程式。但這只是部分解決了這些問題。
Docker缺少什麼Docker可以形象化的比喻為像可疊起堆放的樂高積木。每個容器是一個樂高。樂高玩具的美麗之處是可以組裝的磚塊和建立各種各樣的奇妙的東西。同樣的概念也適用於Docker的容器中。利用Docker，諸如編排、監控、日誌記錄和擴充套件可能成為企業關注的問題。Docker容器可以為企業執行幾個容器，但如果你執行成百上千的呢?這些都是需要考慮的一些問題，它們超出了Docker容器本身可以提供的範圍，為什麼PaaS平臺是對Docker的補充。
1. 裝載容器
應用程式開發人員如何讓一款應用進入容器?對於開發者來說構建Docker image也有一些負擔，誰需要關注程式碼，不依賴於不同的系統的作業系統。這個問題的解決方案被稱為buildpacks——對於PaaS是最好和最便攜的選擇。大多數PaaS生態系統正在讓其標準化。Buildpacks允許你建立你的棧，包括在容器內部的所有系統依賴關係，以及配置應用程式的環境。開發人員只需要考慮他們的應用程式程式碼。他們不需要擔心什麼。Buildpacks配置你的應用程式。
2. 編排運輸過程假設開發人員建立大量的Docker的容器。然後他們與運維團隊通訊：“Ship these. Deploy these to production”。IT運維人員如何傳輸這些容器並且以系統的方法來管理這些容器效能、安全性和遵從性?容器有很多樂高積木。他們如何管理?
這個問題的答案是Docker Schedulers。如今在市場上有大量的排程器，它們為你編排和執行的容器並且跨叢集分發它們——而不用考慮你的雲端計算叢集是什麼。排程器是有彈性的，所以如果一個容器或機器或應用程式宕機，它會重新分配這些容器。從使用者的角度來看，根本感覺沒有停機時間。雖然這些排程器解決一部分運輸問題是有幫助的，但是還有另一個重要的問題，企業仍然面臨一個排程器不能解決的問題。
3. 開發自助服務
企業文化當中對於自助服務似乎有著天然的缺陷。開發人員和IT運維之間也存在的天然的鴻溝。在某些方面，你可以說他們之間存在著一堵牆。經常發生的是，開發人員將構建一個應用程式，然後把它扔在牆那邊給運維人員，並且希望應用能夠一切執行正常。因此，將應用程式部署到生產需要數週或數月。所以聽到開發者抱怨他們需要多長多長時間在生產環境中部署應用就不難理解了。
這種文化上的差異遭遇到破舊的基礎設施時，後果就會更嚴重，因為一些企業仍使用過時的票務系統獲取虛擬機器，計算週期可能需要數週時間。
開發人員可以解決這個分歧，但他們需要特殊的工具。他們需要一種自助的方式為企業工作。給開發人員自由的部署在他們的應用，但是這些工具也必須滿足安全性和遵企業的需求，包括多租戶管理。開發人員可以專注於他或她的應用程式，但是企業需要考慮所有由不同的開發人員提交的應用程式。怎麼處理這個?如何打破這堵存在與開發者和運維者之間的牆?
PaaS平臺也有閃光的地方，它提供了一個介於你的應用程式和基礎設施之間的平臺。這個平臺是一樣的，從開發到生產，提供一個無縫應用交付體驗。
一個新的開發方法Docker的承諾是真正偉大的，幫助開發人員解決構建新應用時的重大問題。它將改變應用程式開發過程，但某些挑戰必須克服從而使得企業獲得最大好處。PaaS平臺將促進Docker的發展，並且幫助其履行自己的承諾。