Docker部署服務的坑實例分析

這篇文章主要講解了“Docker部署服務的坑實例分析 ”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Docker部署服務的坑實例分析 ”吧！

本項目采用的是spring cloud+spring boot+spring gateway+mysql還用到了rabbitmq。服務器為centos7。 

采用的zuul被我換成了gateway。 zuul基于servlet 2.5（使用3.x），使用阻塞api。 它不支持任何長連接，如websockets。而gateway建立在spring framework 5，project reactor和spring boot 2之上，使用非阻塞api。 websockets得到支持，并且由于它與spring緊密集成，所以將會是一個更好的開發體驗。

docker鏡像服務使用的是阿里云的容器鏡像服務。問了一下同事，說是用的google的容器工具jib。于是cmd+shift+f全局搜了一下jib。

點擊進去可以看到

進入到阿里云找到容器鏡像服務（此處省略不知道鏡像倉庫是分區的，找不到倉庫以為是沒權限，然后厚著臉皮要來了管理員賬號修改了離職同事的員工賬號也還是沒有找到倉庫的步驟）

然后我創建了一個命名空間xxx-prod，然后在該空間下為每個服務都建好了倉庫.私有倉庫。代碼源我選擇的是本地倉庫推送到鏡像倉庫。其他的我也不太了解。

(后來發現其實不用建，jib提交會自動創建倉庫，手動創建的時候選擇) 使用jib提交上去后，可以在倉庫的版本信息里看到更新。

然后連接上服務器。在home文件夾下面創建一個docker文件夾

//在root根目錄
//~]# centos7的emmm怎么說呢，就是gitbash和os系統上面是$ windows下面cmd是>
//home下面創建一個docker文件夾
~]# mkdir /home/docker
//進入創建的docker
~]# cd /home/docker

然后開始pull我們上傳到阿里云的鏡像。其實隨便哪個目錄都可以pull（此處省略第一次pull阿里鏡像服務時，沒有看操作指南，一度懷疑自己賬號沒有權限其實是沒有login，然后一直docker login，殊不知后面應該加上阿里云的鏡像地址：registry.cn-hangzhou.aliyuncs.com） 在阿里云的鏡像服務管理控制臺，隨便點開一個鏡像倉庫——>管理，可以看到對鏡像倉庫的操作指南

鏡像拉取完畢以后輸入

~]# docker images

可以看到自己剛才pull到的鏡像。

我問同事這里怎么這么多鏡像，他跟我解釋說

emmm，行吧！總覺得有很多鏡像占內存（希望有知道的大佬不吝賜教，感謝）

啟動eureka

~]# docker run -d --name eureka -p 8761:8761 -p 15672:15672 -p 9001:9001 -v /etc/localtime:/etc/localtime registry.cn-hangzhou.aliyuncs.com/xx_xxx_prod/eureka
// -d后臺運行 -p綁定端口這里綁定了三個端口，一個是注冊中心本身的端口，一個是網關的端口，另外一個是rabbitmq的端口 
//-v打印版本信息

由于使用了rabbitmq，所以還需要再創建一個rabbitmq容器。 還是先拉取鏡像

//這里注意獲取鏡像的時候要獲取management版本的，不要獲取last版本的，management版本的才帶有管理界面。
~]# docker pull rabbitmq:management
~]# docker run -d --name rabbit -e rabbitmq_default_user=xxx -e rabbitmq_default_pass=xxx --network=container:eureka rabbitmq:management
//因為docker容器間是網絡隔斷的 --network是加入eureka一樣的網絡環境這樣才能被eureka治理下的服務訪問到。
//-e是設置默認的賬戶密碼 指令中是xxx，用到的朋友請自行調整。

然后啟動自己的服務

~]# docker run -d --name xxx -v /home/docker/web-prod/logs:/logs -v /etc/localtime:/etc/localtime --network=container:eureka registry.cn-hangzhou.aliyuncs.com/xx_xxx_prod/xxx 
//-v是將日志掛載到自己制定的目錄。 同樣--network加入eureka的網絡，這里不用綁定端口。
//啟動后可以在注冊中心的控制臺查看服務狀態。ip + eureka的端口。

這樣服務就跑起來啦。其他服務步驟類似。最后補充一些在上線是遇到的小插曲。 一開始不知道docker容器間是網絡隔斷的，一直連不上rabbitmq，因為之前一直沒有使用--network假如eureka的網絡。所以服務內localhost訪問不到rabbitmq。還有，如果服務中有用到rabbitmq延時隊列的話，還需要安裝延時隊列的插件。 插件安裝步驟

打開官網下載：http://www.rabbitmq.com/community-plugins.html
選擇相應的對應的版本“3.7.x”點擊下載。
~]# docker cp /home/docker/rabbitmq_delayed_message_exchange-20171201-3.7.x.ez rabbit:/plugins
//進入到docker內部
~]# docker exec -it rabbit /bin/bash
//開啟插件
rabbitmq-plugins enable rabbitmq_delayed_message_exchange
//查看安裝的所有插件
rabbitmq-plugins list

安裝成功，如圖：

docker rm 刪除容器時，突然就刪除不了了。docker ps -a發現該容器的狀態是dead（死亡），網上查閱了很多資料，什么強刪、查看掛載狀態、手動刪除文件夾、查看端口占用情況。幾乎都試過了，沒有效果。

最后大概經驗使然，鬼使神差的把nginx和httpd都關掉然后就可以刪除了。 不要問我為什么同一臺服務器同時裝nginx和httpd，此項目原本是php項目，由他們部署的，我接手后自己使用的nginx。

還有一個很奇怪的問題，雖然解決了但后面我還是不太明白為什么會這樣子。用戶表里面有一個last_password_reset_date,用戶登錄時會校驗這個時間字段，一直報token失效，一個個字段日志輸入后，發著這個字段比數據庫里面的時間相差10個小時，當時想過是時區問題。但是同一張表的另一個register_date字段時間是正常的，于是便沒有處理時區。排查了很久，以為是java接受的時間類型不對，或是同事對這個字段進行了處理。一直沒搞定。后面我把線上環境臉上測試庫，發現又正常。最后查看了一下測試環境數據庫的時區 ，是東八區。線上庫是默認的gtm。最后把正式庫的時間改成了東八區就好了。

還有一個就是redis，因為之前有一個公眾號服務，用到了redis，當時redis服務是在宿主機上面的。所以，想就連服務器宿主機上面算了，但是一開始連不上，后來把redis的配置文件改了一下，bind參數綁定內網ip就好了。然后程序里面使用內網ip連上redis。

感謝各位的閱讀，以上就是“Docker部署服務的坑實例分析 ”的內容了，經過本文的學習后，相信大家對Docker部署服務的坑實例分析 這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！