基于Docker的Vue前端自動化部署
前言
Docker的誕生
毫無疑問，DocKer成了近些年來最火熱，甚至最具顛覆性的技術(shù)之一。首先，我們在傳統(tǒng)項目簡單描述一下，項目發(fā)布的基本流程。
本地開發(fā)+測試，沒有問題的話，編譯打包發(fā)布到測試環(huán)境
在測試環(huán)境中進(jìn)行測試，測試完成后，發(fā)布到生產(chǎn)環(huán)境
在生產(chǎn)環(huán)境中進(jìn)行最后的測試，如果沒有問題，那么一切就OK了
如果你是從事了一年以上開發(fā)人員，我想100%的人都親身經(jīng)歷過這樣的事情 —— 在自己本地測試都沒有問題，發(fā)布到測試環(huán)境、生產(chǎn)環(huán)境后，就出現(xiàn)問題了！搞得自己非?？鄲溃》浅＜m結(jié)！到底是哪里出了問題呢？明明代碼什么的都一樣啊~
那么在這種情況下，其實是有N種可能，但我這這里提出一個比較常見的原因，就是：
本地開發(fā)環(huán)境與測試環(huán)境、生產(chǎn)環(huán)境上的軟件環(huán)境配置，可能出現(xiàn)不一致的情況，導(dǎo)致有些時候相同的代碼在不同的環(huán)境下運(yùn)行會出現(xiàn)問題。
存在問題：不同機(jī)器上的軟件環(huán)境不一致。（比較核心的問題）
再列舉幾個實際開發(fā)中遇到的情況：
公司在阿里云買了一臺新服務(wù)器，要想能正常發(fā)布項目等，前提是需要在服務(wù)器上重新安裝一些軟件環(huán)境（比如node、mysql、nginx等），在安裝軟件環(huán)境的過程中，很大幾率會出現(xiàn)配置錯誤的情況；一些比較復(fù)雜的環(huán)境配置步驟會很多，很多人都記不清具體的步驟和命令，還得上網(wǎng)搜索......
存在問題：軟件環(huán)境的配置繁多、命令記不清楚。
像jdk、tomcat等基礎(chǔ)的環(huán)境搭建，都已經(jīng)很熟練了，每次有新機(jī)器的時候，都要重新搭建，這樣就造成了重復(fù)性工作、效率低下、配置繁瑣麻煩、易出錯等情況。
存在問題：重復(fù)性搭建軟件環(huán)境、效率低下。
當(dāng)然也會有其他的問題，這里就不多做說明了。
因此，我們在開發(fā)完畢之后，如果我們要部署10個項目，那就需要找10部虛擬機(jī)，然后再給對應(yīng)的10部虛擬機(jī)部署對應(yīng)的10個環(huán)境，重復(fù)性的工作量就算了，但部署的過程中肯定會衍生出很多的問題，上述提到的問題只是其中的一部分，這樣會導(dǎo)致項目的落地造成了極大的問題，效率上也及其的低效。因此Docker技術(shù)就幫我們解決了我上述的痛點?？梢哉f是程序員的福音。接下來，我們簡單了了解下docker的基本概念，了解下它是如何解決上述的問題和痛點的。
Docker本質(zhì)上是一個采用虛擬化技術(shù)的容器，基于Linux容器進(jìn)行再封裝，使用戶不用關(guān)心容器的管理，而簡化應(yīng)用操作。
傳統(tǒng)的虛擬化是基于硬件實現(xiàn)的，如果要部署10個應(yīng)用，則需要創(chuàng)建10個虛擬機(jī)，而Docker是基于操作系統(tǒng)做的虛擬化，也就是復(fù)用本地主機(jī)的操作系統(tǒng)，部署運(yùn)營10個應(yīng)用時只需要起10個隔離的應(yīng)用即可。
我們之前需要在每臺服務(wù)器去配置對應(yīng)的環(huán)境，但docker的出現(xiàn)，我們只需要去docker的公開社區(qū)，通過docker命令去下載鏡像環(huán)境即可。
通過啟動容器命令就可以在你的服務(wù)器中使用了對應(yīng)的環(huán)境，這就可以讓開發(fā)者在不了解對應(yīng)環(huán)境的安裝命令的同時也可以使用環(huán)境。并且占用服務(wù)器的資源也會更少。
開發(fā)者只需在項目結(jié)構(gòu)中添加對應(yīng)的Dokcerfile文件，即可在服務(wù)器中實現(xiàn)代碼和環(huán)境的容器，這樣項目的環(huán)境會根據(jù)當(dāng)前的Dockerfile配置對應(yīng)的環(huán)境，解決了因環(huán)境的不同導(dǎo)致項目無法正常運(yùn)行的問題。
當(dāng)你熟練的使用了docker命令去部署一個項目之后，現(xiàn)在問題的核心在于，如果我們每新建一個項目就要去服務(wù)器中執(zhí)行同樣的命令去啟動容器，啟動項目。這樣的操作算是一種重復(fù)的操作，例如10個項目，開發(fā)者需要在服務(wù)器中走10此同樣的命令，這樣的操作是十分致命的。
因此，接下來要做的，就是“讓重復(fù)的事情自動化”?。?！
Devops 就可以讓“讓重復(fù)的事情自動化”，它可以實現(xiàn)項目管理、自動化部署、自動化發(fā)布、自動化測試、容器云來實現(xiàn)持續(xù)集成、持續(xù)交付及持續(xù)部署。
Docker與Devops自動化部署部署實踐
Devops（Development和Operations的組合詞）是一組過程、方法與系統(tǒng)的統(tǒng)稱。
它實現(xiàn)持續(xù)集成、持續(xù)交付及持續(xù)部署。
持續(xù)集成：
在業(yè)界，我們通常將它稱之為 CI ，這是一種開發(fā)、部署的實踐。開發(fā)人員每天都將自己的更改推送到主分之中進(jìn)行集成，通常情況下，這樣的操作每天都會發(fā)生很多次。從更高的視角來看，CI 能使開發(fā)者更快的發(fā)現(xiàn)模塊或功能中的錯誤。無論提交的大小，CI 能讓整個團(tuán)隊看到每一個提交對整個項目的影響。當(dāng)流程中出現(xiàn)問題的時候，通過 CI，可以準(zhǔn)確地知道問題是由哪個提交造成的，也有可能從錯誤信息中看到是因為哪一行代碼引起的。
持續(xù)交付、持續(xù)部署：
持續(xù)交互在業(yè)界被簡稱為 CD ，是指在自動完成所有事情過后，將通過的代碼進(jìn)行直接部署。作為整個流程的最后一個步驟，設(shè)置監(jiān)控報警，來確保你所部署的服務(wù)正在順利的運(yùn)行。當(dāng)出現(xiàn)問題是要第一時間通知開發(fā)者。
了解了Devops之后，我們來看看具體的實現(xiàn)流程
Devops的具體流程
開發(fā)人員在本地完成代碼開發(fā)后，提交到本地分支，利用docker模擬生產(chǎn)環(huán)境進(jìn)行測試，測試通過后合并到遠(yuǎn)端的主分支；
2.master 主分支一旦更新后，觸發(fā)持續(xù)集成軟件進(jìn)行打包集成（常見的集成工具: gitlab-vi，travis，或Jenkins）自動完成構(gòu)建docker 鏡像并push 推到遠(yuǎn)程倉庫(docker cloud 或者企業(yè)自己的docker registry)
3.利用docker cloud等持續(xù)部署到web服務(wù)器。
4.配置發(fā)布服務(wù)器從倉庫拉取鏡像，run起來后，停止舊的版本。完成了一次自動集成部署。
接下來，通過node制作了一個npm包，結(jié)合工蜂+騰訊云容器服務(wù)CODING實現(xiàn)一個自動化部署。讓大家可以不懂任何底層原理的情況上，只需簡單通過命令行操作，就可以實現(xiàn)項目自動化部署，體驗技術(shù)的魅力。
流程圖如下
簡單的描述流程
step1 通過命令bluej initVue 項目名稱 部署域名
運(yùn)行命令后，會從git倉庫中獲取VUE模板，此時項目的根目錄文件中會多出三個文件，分別是Dockerfile.Jenkinsfile,nginx.conf三個文件，是為了后面的自動化部署作準(zhǔn)備用的。
step2 bluej run 項目名
項目進(jìn)入開發(fā)模式，即我們平時的開發(fā)模式，在這里該干什么就干什么了
step3 通過git命令將新建的項目
這些都是git的基本操作了，就不過多的論述，
當(dāng)聯(lián)系遠(yuǎn)程倉庫成功之后，進(jìn)入step4
Step4 使用騰訊云的容器服務(wù)CODING，實現(xiàn)自動化部署配置
在實現(xiàn)部署之前，需要手動的創(chuàng)建一個制品庫，制品庫中存放著項目的鏡像，并將權(quán)限設(shè)置為團(tuán)隊內(nèi)部人員均可使用。
在團(tuán)隊項目中新建一個構(gòu)建計劃。
選擇自定義構(gòu)建過程。
選擇關(guān)聯(lián)的工蜂項目并設(shè)置流水線的來源為項目本身自帶的流水線設(shè)置后，點擊確定和立即構(gòu)建。
接下來，就會按照自研流水線一步一步的執(zhí)行自動化的部署。
等待部署完成之后，即可訪問之前輸入域名地址進(jìn)行訪問。
同時，我們可以通過終端遠(yuǎn)程訪問到服務(wù)器中容器運(yùn)行情況，查看當(dāng)前項目的容器是否正在運(yùn)行,通過docker ps命令查看正在運(yùn)行容器，而其中的bluej_test即是剛剛經(jīng)過自動化部署完畢的項目。
