微服務(wù)為什么要選擇docker？早在2013年的時候，docker就已經(jīng)發(fā)行，然而那會還是很少人了解docker。一直到2014年，Martin Fowler提出了微服務(wù)的概念，兩個不相干的技術(shù)終于走

微服務(wù)為什么要選擇docker？

早在2013年的時候，docker就已經(jīng)發(fā)行，然而那會還是很少人了解docker。一直到2014年，Martin Fowler提出了微服務(wù)的概念，兩個不相干的技術(shù)終于走在了一起，創(chuàng)造了今天的輝煌！現(xiàn)在:用上了docker容器后，將Docker可以將我們的應(yīng)用程序打包封裝到一個容器中，該容器包含了應(yīng)用程序的代碼、運行環(huán)境、依賴庫、配置文件等必需的資源。容器之間達到進程級別的隔離，在容器中的操作，不會影響道宿主機和其他容器，這樣就不會出現(xiàn)應(yīng)用之間相互影響的情形！

微服務(wù)在Docker k8s下如何部署？

正好最近在項目中用到了這些技術(shù)，我來拋磚引玉吧。

首先說結(jié)論：

1. k8s 是非常好的一項技術(shù)，很穩(wěn)定。如果發(fā)現(xiàn)正在運行的 pod 的數(shù)量不等于用戶設(shè)定的期望值， k8s 則會自動創(chuàng)建或者刪除 pod，直到兩者相等。這樣既保障了服務(wù)的不間斷運行，同時還可以動態(tài)縮放服務(wù)的規(guī)格。用戶只要調(diào)整 pod 的 replicate 的數(shù)量即可，其他的都交給 k8s 就好，非常省心。

2. 要用 jenkins 來集成命令行操作，雖然我個人非常偏愛使用命令行，但是我不得不承認用 jenkins 集成命令行操作會極大的提升工作效率。

下面說實現(xiàn)步驟：(本文以 azure 平臺為例)

1. 編寫 Dockerfile

2. 在 jenkins 創(chuàng)建任務(wù)，并執(zhí)行包含如下命令的腳本

2.1 git pull 源代碼到本地

2.2 docker build 命令生成鏡像文件

2.3 docker 定義鏡像文件版本號并上傳到 azure 平臺

2.4 kubectl 命令來創(chuàng)建 k8s 的 deployment & service.

2.5 每次版本更新可以調(diào)用 update image 來編譯新的鏡像版本并提供給 k8s 使用

注意在創(chuàng)建 k8s 的 deployment 和 service 的時候需要編寫 yaml 格式的配置文件， deployment 配置包括 名稱，鏡像文件地址， cpu 最大最小分配值，內(nèi)存最大最小分配值等。service 配置文件包括 名稱，引用的 deployment 名稱，以及是否使用 load balancer等。

更多詳細信息可以參考我的 wiki. https://github.com/FamingHou/MyWiki

為什么說docker是一種革命性的技術(shù)？

一個非常好的問題，我是工作多年的Web應(yīng)用架構(gòu)師，來回答一下這個問題。歡迎關(guān)注我，了解更多IT專業(yè)知識。

Docker稱不上革命性的技術(shù)，但可以稱得上是一個革命性的解決方案和工具。

Docker基于Linux內(nèi)核通過操作系統(tǒng)和虛擬容器調(diào)用CGroup， Namespace等系統(tǒng)接口完成資源的分配與相互隔離，依賴系統(tǒng)資源運行，使用的技術(shù)都是已有的。

Docker出現(xiàn)之前，有現(xiàn)在還在用的VMWare虛擬機，有Ghost，部分解決了服務(wù)器安裝配置的瑣碎工作，但是沒有解決運行環(huán)境的問題。比如常見的環(huán)境不一致的問題：開發(fā)環(huán)境能運行，測試生產(chǎn)環(huán)境有bug？還有就是每次新服務(wù)器、新環(huán)境搭建時無窮無盡的問題。

那么Docker出現(xiàn)后，整個環(huán)境被打包起來，也就是將所有安裝配置代碼化自動化了，結(jié)合資源編排和云服務(wù)，可以秒啟一個集群化的web服務(wù)系統(tǒng)，如果沒有容器技術(shù)是做不到的。Docker是使用最普遍的容器技術(shù)，事實上的容器技術(shù)標準。

推薦看一個Docker秒啟Web服務(wù)的視頻：https://www.toutiao.com/i6801418770997838343/