這種技術叫做captive portal，大都基於iptables實現，有現成的openwrt平臺的軟體可以實現：比如nocatsplash或者wifidog。安裝後，根據跳轉介面編寫相應的服務端程式（可以用php伺服器）。

docker 可以說是一大神器。從15年開始工作，就可以接觸 docker ，到現在已歷時5年，從最開始的原生部署，docker run 啟動，到 jekenis 自動化部署，到如今公司的自研自動部署平臺，作為研發，實際接觸 docker 的機會越來越少，但間接接觸 docker的幾乎每時每刻。申請測試環境，運維側會給你一個docker容器，線上部署應用，還是 n 多的 docker ，申請彈性資料庫，還是一組 docker 叢集。docker基本上已融入網際網路公司的角角落落。那我簡單來說說為什麼使用 docker 。

其一，環境部署更快捷。搭建一個 java web執行的環境，需要安裝 jdk ，安裝 tomcat，有時還需要安裝 nginx，而使用docker，直接從docker倉庫【https://www.docker.com/】中拉取一個包含 jdk+tomcat+nginx的基礎映象，把我們的應用程式碼打入，就可以啟動，其速度更快捷。

其二，更輕鬆的遷移。我們在測試環境中部署了我們的應用，測試透過，可以很輕鬆的把我們的應用映象移植到線上環境中，而不用考慮環境不一致的問題。

其三，使用 docker 可以透過定製應用映象來實現持續整合、持續交付、部署。所有的東西都在Dockerfile上，所有的人員都可以透過Dockerfile檢視其中的依賴。

除上述的原因外，docker 高效的利用系統資源、快速的啟動時間以及輕鬆的維護和擴充套件等特性也是讚譽一片。比如docker 使用的分層儲存以及映象的技術，使得應用重複部分的複用更為容易，也使得應用的維護更新更加簡單，基於基礎映象進一步擴充套件映象也變得非常簡單。

而隨著docker容器化的發展，叢集化、基礎化的特點突出，一個微服務叢集，成百上千的docker，大公司一般都是透過開源或者自研的方案解決其自動化部署和容器管理的問題，研發接觸docker的機會也越來越少，但是其中的技術原理應該瞭解，並能夠自己構建映象並部署容器，這對個人的發展有一定的好處。

為什麼用docker，在我的角度，是因為他可以避免因為環境變化造成的各種不可預知的問題，省得你還需要寫部署文件，我需要什麼外部環境，版本多少，docker直接都給你封在裡面了，只要對方有docker，直接執行就可以了，省心，省事。

docker在開發和運維中被廣泛使用是有其原因的。

在沒有docker之前，我們經常使用虛擬機器進行環境模擬。虛擬機器幾乎可以完整模擬目標系統，但是它太笨重，需要強大的硬體支援，當時大多使用高效能的pc server進行構建。其實我們使用虛擬機器也只是模擬一個程式執行環境如java、php等。docker可以看成虛擬機器的輕量化實現。從使用者角度看docker可以替換虛擬機器，同時又無需佔用很大的硬體開銷。同樣的虛擬機器資源可以部署更多的docker，何樂而不為呢。

docker架構

作為程式設計師經常碰到在測試和生產環境上線過程中因為環境配置不一致造成的各種問題，嚴重的可以造成上線不成功。針對這個問題，如果在開發、測試、生產過程中全部使用docker部署就會最大程度避免環境不一致的情況出現。並且docker的映象檔案可以直接作為提交檔案提供給測試和運維。

以前作為單體應用開發的系統在擴充套件性上有其侷限性，基本上都是功能調整過大就重新開發。對於擴充套件性要求不是很強烈。隨著網際網路業務變化性要求的增加，以及微服務、微應用的出現，對於程式擴充套件性的要求越來越高。docker的出現使得系統可以針對薄弱環節短時間擴展出大量的服務，大幅度降低系統的響應時間。啟動docker的時間都在秒級，而之前的虛擬機器啟動時間需要以分鐘計。

以前運維在部署多個伺服器的應用時都需全神貫注，否則可能會出現災難性的後果。隨著k8s的出現，完全降低了風險，同時把運維從繁重的體力勞動中解脫出來，使得部署、擴充套件、監控等工作“程式化”起來。docker叢集的管理工作量化，系統執行情況可見。

docker與k8s

會點程式碼的大叔

專案為什麼要用 docker，需要了解 docker 的優勢，結合專案的實際情況來決定是否需要使用 docker，千萬不能“為了使用而使用”或者“跟風使用 docker”。

使用 docker 是為了快速交付

和傳統的虛擬機器相比，docker 具有所用的資源更少、效能更高、隔離級別更高、安全性方面也更強等特點，讓我們看看下面幾個場景，估計你會有更深的體會。

01. 移植性更強

相信開發人員都會遇到這樣的問題：程式碼在本地跑的好好的，但是一發布到測試環境怎麼就有問題了呢？

通常我們的的程式碼包需要依賴於環境中的很多因素，比如配置檔案、依賴庫、中介軟體的配置等等，其中一項有問題可能都會導致我們程式碼出現問題；對於開發人員來說，最希望的就是我們的程式碼能夠一次建立，在任意地方都能執行。

而使用 docker 之後，可以實現開發、測試、運維環境的標準化，映象檔案直接做為交付物，避免了因為環境不同導致的各種問題。

02. 更容易擴充套件

docker 容器可以在任意平臺執行，不管是物理機還是虛擬機器，不管是公有云還是私有云，甚至是個人電腦，所以我們的專案容易做遷移和擴充套件。

比如我們應用部署了兩臺機器，當我們想再擴充套件第三臺機器的時候，我們需要先搭建好程式碼執行所需的環境，儘管虛擬機器也有一些快速 copy 的技術，但是這個過程依然是很慢的，而且有些環境配置還容易出錯，而有了 docker，只需要構建映象然後執行即可，非常方便快速。

因為 docker 快速的構建方式，也讓我們的專案可以實現自動且快速的擴容和縮容。

03. 更加輕量

在 docker 出現之前，通常會採用物理機上部署多臺虛擬機器，每個應用都部署在一個虛擬機器中；但是虛擬機器非常的重，虛擬機器的構建速度通常都是按照分鐘計算，佔用的資源比較多。

而 docker 的速度很快，秒級，並且使用的資源更少，效能更高；同樣一個物理機器，docker 執行的映象數量遠多於虛擬機器的數量。

使用 docker 只是快速交付的一部分

docker 的優點這麼多，那是不是用了 docker 之後，我們的交付速度更快了呢？

我見過一個專案，他們號稱已經微服務化了，當然他們確實也做到了：把一個專案拆成了數個服務，每個服務在生產環境上部署了多套，算下來就是 N * M 個應用包（七八十個），都做了容器化...

但是他們依然是人肉運維，也是就是他們每次提測和上線需要手動部署，沒有自動化測試和釋出；

生產環境發生問題的時候，需要手動去拿日誌跟蹤問題，開發和運維依然是兩個團隊，甚至是所屬兩個不同的部門，溝通的成本很高；

他們雖然實現了容器化，但其實並沒有實現快速交付，甚至比傳統的方式更慢了。

所以，不要為了 docker 而 docker；如果你們的專案環境配置複雜，每來一個新人配置環境都需要一兩天；每次提測和上線，經常問題都是執行環境的問題；開發人員的開發環境不統一；開發能力強，運維能力弱的時候，甚至公司比較窮，想實現資源使用的最大化，都可以考慮使用 docker，不過像要做微服務化+容器化，當容器叢集規模比較大的時候，還需要工具做容器的自動化管理和編排，自動化測試及部署等等。

會點程式碼的大叔

2.6萬粉絲 · 2.7萬贊

搜尋

docker封裝windows應用

徹底解除安裝docker

linuxip配置

docker自動部署程式

常用docker命令

為什麼要使用docker

引言

早在2013年的時候，docker就已經發行，然而那會還是很少人瞭解docker。一直到2014年，Martin Fowler提出了微服務的概念，兩個不相干的技術終於走在了一起，創造了今天的輝煌！

近幾年來，很多網際網路關係開始跟風，構建docker+微服務的架構體系。

然而，根據筆者觀察發現，有些童鞋在使用過程中，只是會用，而根本不瞭解為什麼使用docker，反正對他們來說，公司讓用就用！

而某些公司呢，雖然用上了docker，然而運維方式並沒有發生改變，白白浪費了docker的大好效能！

正文

這裡必須要先說明物理機、虛擬機器、容器三者的優缺點。

這裡借用一下這位大神的三張圖，他的回答就三張圖！

所謂的物理機就是下面這樣的別墅

那麼虛擬機器機就是下面這樣的套房

最後就是我們的容器，就是下面這樣的膠囊公寓

那麼，專業的說法就是，容器是一種輕量級、可移植、自包含的軟體打包技術，使應用程式可以在幾乎任何地方以相同的方式執行。

容器之間是共享同一套作業系統資源的，由於容器是共享主作業系統的核心，因此就無法在伺服器上執行與主伺服器不同的作業系統，也就是說不能再Linux的伺服器上執行Windows。

就如上面哪個圖一樣，每個膠囊容器是公用一個廁所，廚房，每個膠囊內無法再構建出自己的廁所和廚房！

過去：曾記得12年那會，部門要上一個專案。那會，我是這麼幹的。

直接去線上伺服器，複製一個tomcat，然後改埠號，然後部署應用到webapps資料夾下，重啟就好。而且我可以摸著良心說，現在還有很多傳統企業是這麼做的。

那麼這麼做的缺點？

很明顯，應用之間相互影響。一個應用出現問題，CPU100%了，這個伺服器上的其他應用一起涼涼。

一個大型應用拆分為幾十個微服務，分別交由不同的團隊開發，不同團隊之間水平參差不齊。

如果還採用這種部署方式，你的應用和某個坑爹團隊的應用部署在了同一臺伺服器上，至於結果，我相信你懂的。

現在：用上了docker容器後，將Docker可以將我們的應用程式打包封裝到一個容器中。

該容器包含了應用程式的程式碼、執行環境、依賴庫、配置檔案等必需的資源。

容器之間達到程序級別的隔離，在容器中的操作，不會影響道宿主機和其他容器，這樣就不會出現應用之間相互影響的情形！

過去:曾幾何時我們和測試MM之間聊天內容是這樣的

開發:"你去測試環境上，按照開發環境一樣，再去搭三套一樣的測試環境！" 測試:"我….." 幾個小時過去了… 測試:"你幫我看看，為什麼啟動報錯，是不是漏配了什麼引數?" 開發:"我…."

於是接下來幾個小時就這麼愉快的和測試mm一起聊天中過去了！！嗯，我相信有些公司是為了解決開發的單身問題，才不使用docker,用心良苦!

然而，和運維GG之間聊天一般是這樣的

運維:"開發這群腦殘，釋出的新war包，又把生產搞掛了！" 開發:"這幫運維傻叉麼，我本地好好的，怎麼一上生產就不行了！" …

於是接下來的幾個小時，就在和運維之間的撕逼中過去了!嗯，最終苦的是使用者啊！

現在:自從用上docker容器後，可以實現開發、測試和生產環境的統一化和標準化。

映象作為標準的交付件，可在開發、測試和生產環境上以容器來執行，最終實現三套環境上的應用以及執行所依賴內容的完全一致。

在現在微服務的架構中，一個應用拆成幾十個微服務，每個微服務都對應有開發、測試、生產三套環境需要搭建。

自己算算，如果採用傳統的部署方式，有多少環境需要部署。曾聽聞某公司在新建一個專案的時候，要花整整一個禮拜來搭建環境，簡直是慘不忍睹!

什麼，你和我說，你們用上了docker，卻還存在這些問題？

筆者曾見過某些公司是這麼用docker的。確實虛擬化出容器了，然後在容器上建立ssh server。

接下來就厲害了，部署方式完全沒變，直接連上容器，一切部署照舊！對此，我也是一言難盡啊！你們這是給領導搭的docker麼？

過去:在2016年的時候，那會在另一家大廠工作。這家稍微規範一點了，一個應用部署在一個虛擬機器上！

當時最大的體會就是一個，虛擬機器非常重，構建速度慢，且佔用資源多，一臺物理機上只能起十來個虛擬機器！

現在:和虛擬機器相比，容器僅需要封裝應用和應用需要的依賴檔案，實現輕量的應用執行環境，且擁有比虛擬機器更高的硬體資源利用率。

在微服務架構中，有些服務負載壓力大，需要以叢集部署，可能要部署幾十臺機器上，對於某些中小型公司來說，使用虛擬機器，代價太大。

如果用容器，同樣的物理機則能支援上千個容器，對中小型公司來說，省錢！

筆者注：筆者一直覺得這個特性只是一個障眼法。

比如，你說容器啟動速度快？難道你工作中吃飽了撐著沒事幹，一直重啟虛擬機器麼？

你說虛擬機器消耗資源多？絕大部分公司的伺服器資源利用率應該都不到 50%，大量的CPU、記憶體、本地磁碟都是常年浪費的，所以 VM 的額外開銷不過是浪費了原本就在浪費的資源罷了。

所以筆者認為，對於傳統應用來說，使用和不使用Docker可能並不能直接給企業帶來好處，相反使用中遇到了問題肯定會給企業帶來麻煩，對於傳統企業來說，不要盲目跟風，VM虛擬機器其實夠用了！。

總結

在技術演進中，docker只是趨勢，並不是結果。相信在未來，一定有更高大上的部署架構出現!