總結對Docker這個東西的想法

版權聲明：本文為部落客原創文章，未經部落客允許不得轉載。 https://blog.csdn.net/qq1010885678/article/details/48039361

記得一開始的時候，還隻能在一些網站上看到關于Docker零星的一些消息，之後的不久，有關Docker消息就遍布網絡。

是什麼因素讓Docker火起來的？

或者說什麼原因促使大家都對Docker感興趣并且開始運用的？

本文記錄一下自己對Docker的一點見解，關于Docker是什麼以及基本的操作網絡上有大把大把的文獻，或者參考這裡：

Docker初步介紹系列文章

這裡就不再累述了。

首先需要明确的一點是，一個技術從誕生到流行，必定有其原因所在

并不是因為某種技術聽起來叼叼的樣子，或者說大家都在用我不用就跟不上時代

能被大衆所認可，并廣泛使用的，一定是解決了大部分人所煩惱的問題，或者改善了大部分人的應用現狀的

而Docker正是如此，那麼它到底解決了大家的哪些煩惱，如何讓大家在用Docker的過程中感到有質的改善呢？

舉一個簡單的例子，相信很多開發人員都遇到過這樣的問題：

要開發應用，那肯定要寫代碼的啊

要寫代碼，那肯定要配置某個語言的運作環境啊

再搞個好用的IDE，或者可以再裝幾個插件啥七七八八的

于是噼裡啪啦的好不容易裝好了，可以開始愉快地撸代碼了

也許一段時間之内并沒有什麼問題出現

但是就在某一天（也許是很久很久之後的事情了），電腦好卡啊，想重新裝個系統清靜清靜，或者來個更直接的，我要換一台更高配置的機器

那麼問題就來了

是不是還要繼續寫程式咯

那是不是還要繼續搭環境咯

那是不是還要繼續裝各種需要的軟體咯

重新裝？可以啊，下次再換系統再換電腦，每次都重新裝過咯~

雖然現在很多圖形化的工具可以幫人備份、還原、複制系統，但是這一般都是給個人PC機用的，如果是伺服器要進行遷移什麼的，怎麼破？

這是第一個問題，環境配置的重複工作和繁雜性

接下來看看第二個問題

我在伺服器上挂着一個tomcat，裡面跑着一個java web程式在讀着mysql資料庫，原本是好好的沒啥問題是吧

現在問題又來了我要對mysql更新一下，更新就更新吧，但是問題是我這個東西是已經在跑着了，有人用着呢，難道不顧使用者的死活直接就升了嗎，而且更新完敢百分百保證一點問題都沒有嗎

有人就會問了，好好的沒事更新啥啊

= =有時候偏偏就有這種需求，新版本性能更好啊，支援的功能更多啊，巴拉巴拉的。。。

這是第二個問題，局部部件更新或更改的隐患

上面兩個問題是比較切實而且确實是不好解決的

就以這兩個問題為例，開始聊聊Docker是怎麼做的

了解過Docker的人應該都知道Image和Container的概念，簡單的說可以把Image看成是一個壓縮包（生活中很常見的把，rar、zip、gz神馬的）

你要用的時候呢，就解壓縮，很簡單，然後就開始愉快的使用裡面的文檔資料啥的

可能你覺得光看很不爽，因為這個文檔寫的太糟糕，是以你就發揮才華狠狠地修改了一通，然後又壓縮變成另外一個壓縮包

so，Image就是壓縮包，Container就是解壓縮出來的文檔，修改之後還可以再次變成Image，然後Image又可以再次使用。。。此處無限循環自行腦補~

那麼第一個問題就解決了啊

啥？沒看懂？

對于第一個問題，Docker是這麼幹的：

你拉一個最基本的Image嘛，run一個Container出來，愛裝啥裝啥，跟自己的伺服器一樣操作，裝好了再儲存為一個Image不就完事了嘛

伺服器要遷移？

你把這個Image拷過去再run一個Container不就是一個一模一樣的環境了嘛

OK，搞定一個

還是看mysql更新的問題

之前我可能是這麼幹的：

搞一台Linux伺服器，搭個tomcat、裝個mysql，然後把java web程式部署到tomcat上面去，搞定走你~

再來看看Docker是怎麼做的：

還是整一台伺服器是吧，這是必須的

但是我不直接裝tomcat、mysql啥的了

我先裝Docker！

run一個Container是吧，關鍵的時刻來了，哎呀，一個Container也，那我就可以在裡面裝各種各樣的東西了，跟自己的伺服器操作一樣嘛~

真這麼幹就完了，那你還是直接裝在伺服器上面吧= =

我要run出三個Container出來！

Container1：

搭tomcat，把webapps（放網站程式的地方）挂載在伺服器上的某個路徑（放程式的地方）

為何這麼做？

首先，直接把程式放到Container中也不是不行，但是程式是會經常變化的，而Docker提供了可以直接将實體路徑映射到Container中的方法，将會變化的程式放在實體路徑上，Container再去通路豈不更好？

Container2：

安裝mysql，其他啥都不做了

Container3：

這個更徹底了，我就挂載mysql的資料庫檔案的那個路徑，啥都沒有了

Container1中的tomcat跑着java web程式

java web程式通過Container之間互相暴露的IP和端口通路Container2中的mysql

Container2中的mysql的資料庫檔案是讀Container3中的

Container3其實又是挂載着伺服器的實體路徑的（存放mysql資料庫檔案的真實路徑）

那麼看起來很複雜的一個流程，現在關鍵點來了，mysql要更新了

呵呵，我直接更新Container2中的mysql

我在run一個跟Container2一樣的Container，我對這個新的Container裡面的mysql更新！更新完連Container3中的資料庫檔案！

原來的mysql沒有受到任何影響，資料庫檔案也不會因為更新受到牽連，

更新完事之後，Container1連到新版本mysql所在的Container，萬事大吉~就算真的真的新版本出毛病了，重新切回去Container2就是了呗~

Docker就是這麼被用來解決問題的，處理方式和傳統的方式大有差別，但是确實能夠帶來友善和快捷

想想這樣一個應用場景：

一個分布式叢集不夠用了，原本我需要在搞幾台機器或者虛拟機裝啊配啊地擴充（而且就算是配置強大的機器，虛拟機起的個數也是少少的，數的過來的）

現在不用了，我刷地一下起了N個Container！

然後就沒有然後了…

再想想這樣一個應用場景：

開發的時候一個環境，如果測試的人不是你，然後測試人員又要搭一個一樣的環境來測試程式，更恐怖的是，釋出上線的時候又要保持這個環境的問題

現在也不用這麼幹了，一個Image，開發的時候run一個Container，測試的時候、釋出上線的時候…

這裡的目的也不是想一下子就成為Docker磚家啊啥的

僅僅是作為一個引子，指出Docker為什麼會被廣泛接受，其應用場景可以是哪些

至于對Docker的應用

反正大家都是是八仙過海各顯神通

能玩成什麼樣就看你想玩什麼樣~