理解docker部署springboot-為什麼要用docker（六）
阿新 • • 發佈：2019-02-05
為什麼要用docker，在最開始接觸docker的時候，我們應該都能看到下邊的這段話，下邊的摘自這裡，這可能就是當時擁抱docker的原因，寫這個的目的主要是回過頭來結合我對docker的實踐說一下對下邊這些的理解，當然我的理解和大神比起來肯定是小巫見大巫，但是有觀點還是要表達出來的，有問題繼續更新，我堅信學習就是踩著自己的坑往上爬（否定之否定，再繼續否定，就離真理不遠了）
原文：更高效的利用系統資源
原文：由於容器不需要進行硬體虛擬以及執行完整作業系統等額外開銷，Docker 對系統資源的利用率更高。無論是應用執行速度、記憶體損耗或者檔案儲存速度，都要比傳統虛擬機器技術更高效。因此，相比虛擬機器技術，一個相同配置的主機，往往可以執行更多數量的應用。
個人理解：如果把docker容器本身作為一個單位的，那確實是比整個Linux虛擬化這一套要精簡很多的，最後那就話，暫時還沒有實踐出來，過程可以看上一篇
原文：更快速的啟動時間
原文：傳統的虛擬機器技術啟動應用服務往往需要數分鐘，而 Docker 容器應用，由於直接運行於宿主核心，無需啟動完整的作業系統，因此可以做到秒級、甚至毫秒級的啟動時間。大大的節約了開發、測試、部署的時間。
個人理解：如果算上虛機的開機時間再算上專案的啟動時間確實很長啊，但是你部署專案的時候難道要重啟虛機？我實踐的結果是不管你在虛機上還是在docker映象中，springboot專案本身啟動的時間沒有發生任何變化，至於秒級、甚至毫秒級的啟動時間，沒有體會的到。
原文：一致的執行環境
原文：開發過程中一個常見的問題是環境一致性問題。由於開發環境、測試環境、生產環境不一致，導致有些 bug 並未在開發過程中被發現。而 Docker 的映象提供了除核心外完整的執行時環境，確保了應用執行環境一致性，從而不會再出現 「這段程式碼在我機器上沒問題啊」 這類問題。對開發和運維（DevOps）人員來說，最希望的就是一次建立或配置，可以在任意地方正常執行。
個人理解：這確實是一個可以保證的事情，所有的東西都打包成一個映象移動來移動去都是一樣的不會發生任何變化。
原文：使用 Docker 可以通過定製應用映象來實現持續整合、持續交付、部署。開發人員可以通過 Dockerfile 來進行映象構建，並結合持續整合(Continuous Integration) 系統進行整合測試，而運維人員則可以直接在生產環境中快速部署該映象，甚至結合持續部署(Continuous Delivery/Deployment) 系統進行自動部署。而且使用 Dockerfile 使映象構建透明化，不僅僅開發團隊可以理解應用執行環境，也方便運維團隊理解應用執行所需條件，幫助更好的生產環境中部署該映象。
個人理解：所有的東西都在Dockerfile上，所有的人員都可以通過Dockerfile檢視其中的依賴。
原文：更輕鬆的遷移
原文：由於 Docker 確保了執行環境的一致性，使得應用的遷移更加容易。Docker 可以在很多平臺上執行，無論是物理機、虛擬機器、公有云、私有云，甚至是筆記本，其執行結果是一致的。因此使用者可以很輕易的將在一個平臺上執行的應用，遷移到另一個平臺上，而不用擔心執行環境的變化導致應用無法正常執行的情況。
個人理解：一個映象搞定所有問題
原文：更輕鬆的維護和擴充套件
原文：Docker 使用的分層儲存以及映象的技術，使得應用重複部分的複用更為容易，也使得應用的維護更新更加簡單，基於基礎映象進一步擴充套件映象也變得非常簡單。此外，Docker 團隊同各個開源專案團隊一起維護了一大批高質量的官方映象，既可以直接在生產環境使用，又可以作為基礎進一步定製，大大的降低了應用服務的映象製作成本。
個人理解：在很多的開放的倉庫中都有共享的映象在裡邊，也可以自己釋出，修改拓展，總之很多東西你不需要從頭開始，站在了巨人的肩膀上了
原文：更高效的利用系統資源
原文：由於容器不需要進行硬體虛擬以及執行完整作業系統等額外開銷，Docker 對系統資源的利用率更高。無論是應用執行速度、記憶體損耗或者檔案儲存速度，都要比傳統虛擬機器技術更高效。因此，相比虛擬機器技術，一個相同配置的主機，往往可以執行更多數量的應用。
個人理解：如果把docker容器本身作為一個單位的，那確實是比整個Linux虛擬化這一套要精簡很多的，最後那就話，暫時還沒有實踐出來，過程可以看上一篇
原文：更快速的啟動時間
原文：傳統的虛擬機器技術啟動應用服務往往需要數分鐘，而 Docker 容器應用，由於直接運行於宿主核心，無需啟動完整的作業系統，因此可以做到秒級、甚至毫秒級的啟動時間。大大的節約了開發、測試、部署的時間。
個人理解：如果算上虛機的開機時間再算上專案的啟動時間確實很長啊，但是你部署專案的時候難道要重啟虛機？我實踐的結果是不管你在虛機上還是在docker映象中，springboot專案本身啟動的時間沒有發生任何變化，至於秒級、甚至毫秒級的啟動時間，沒有體會的到。
原文：一致的執行環境
原文：開發過程中一個常見的問題是環境一致性問題。由於開發環境、測試環境、生產環境不一致，導致有些 bug 並未在開發過程中被發現。而 Docker 的映象提供了除核心外完整的執行時環境，確保了應用執行環境一致性，從而不會再出現 「這段程式碼在我機器上沒問題啊」 這類問題。對開發和運維（DevOps）人員來說，最希望的就是一次建立或配置，可以在任意地方正常執行。
個人理解：這確實是一個可以保證的事情，所有的東西都打包成一個映象移動來移動去都是一樣的不會發生任何變化。
原文：使用 Docker 可以通過定製應用映象來實現持續整合、持續交付、部署。開發人員可以通過 Dockerfile 來進行映象構建，並結合持續整合(Continuous Integration) 系統進行整合測試，而運維人員則可以直接在生產環境中快速部署該映象，甚至結合持續部署(Continuous Delivery/Deployment) 系統進行自動部署。而且使用 Dockerfile 使映象構建透明化，不僅僅開發團隊可以理解應用執行環境，也方便運維團隊理解應用執行所需條件，幫助更好的生產環境中部署該映象。
個人理解：所有的東西都在Dockerfile上，所有的人員都可以通過Dockerfile檢視其中的依賴。
原文：更輕鬆的遷移
原文：由於 Docker 確保了執行環境的一致性，使得應用的遷移更加容易。Docker 可以在很多平臺上執行，無論是物理機、虛擬機器、公有云、私有云，甚至是筆記本，其執行結果是一致的。因此使用者可以很輕易的將在一個平臺上執行的應用，遷移到另一個平臺上，而不用擔心執行環境的變化導致應用無法正常執行的情況。
個人理解：一個映象搞定所有問題
原文：更輕鬆的維護和擴充套件
原文：Docker 使用的分層儲存以及映象的技術，使得應用重複部分的複用更為容易，也使得應用的維護更新更加簡單，基於基礎映象進一步擴充套件映象也變得非常簡單。此外，Docker 團隊同各個開源專案團隊一起維護了一大批高質量的官方映象，既可以直接在生產環境使用，又可以作為基礎進一步定製，大大的降低了應用服務的映象製作成本。
個人理解：在很多的開放的倉庫中都有共享的映象在裡邊，也可以自己釋出，修改拓展，總之很多東西你不需要從頭開始，站在了巨人的肩膀上了