本文基於上次嘗試之後的進一步嘗試，加入Docker容器、編寫Dockerfile,並且jexus結合Docker的使用，總結下自己的個人感想。一、環境介紹當前的場景有兩種方式將Demo實現運行，一種是我將Asp.Net Core項目通過自偵聽方式啟動，然後外網正常訪問，第二種通過功能強大的jex ...

本文基於上次嘗試之後的進一步嘗試，加入Docker容器、編寫Dockerfile,並且jexus結合Docker的使用，總結下自己的個人感想。

一、環境介紹

　　當前的場景有兩種方式將Demo實現運行，一種是我將Asp.Net Core項目通過自偵聽方式啟動，然後外網正常訪問，第二種通過功能強大的jexus作為代理，將項目發佈後部署到jexus配置下，通過修改配置文件，通過jexus進行反向代理，此時項目本身可以不需要自偵聽方式。

　　當前的場景是直接在主機下進行的，並沒有加入到Docker容器中。

二、Docker中啟動網站（暫未加入Dockerfile）

　　首先，擺在面前的就有一個問題，我是直接根據鏡像建立容器，然後在容器中安裝Git獲取項目、安裝jexus部署項目、安裝vim修改配置文件，還是直接獲取項目後自啟動偵聽呢。

　　不得不承認這兩種情形都是很糟糕的，或許來說功能實現了，但是這個實現的過程是很不值得的，恰巧，我就完完全全走了一遍。

　　^_^

1、加入Docker容器，容器中加入jexus

　　通過之前的一篇文章http://www.cnblogs.com/CKExp/p/8159269.html不難將Docker環境搭建起來，此處將不再製造輪子。

　　一步一步分析，首先在容器中安裝Git，也就意味著假如我要操作上百個容器那不是意味著我要安裝上百次Git，同理jexus，也同理Vim，這是很不值得的，然後我在想，能否將這些個軟體寫到Dockerfile中呢，可以，但誰又會這麼去做呢。

　　不扯遠了，單講講網站啟動，我在容器中通過將網站發佈後，重新啟動jexus，通過外網訪問（ip:埠），可以訪問的通，還是很開心的，至少沒出什麼問題。

dotnet publish -o /var/www/HDShop
sh /usr/jexus/jws restart

　　註意，這裡的埠已經有了映射關係，我在建立容器的時候就已經指定了容器對外訪問埠，所以網站的預設埠已經不合適了，我直接在Programcs中加入了UseUrls("http://*:3456"),容器對外訪問埠是2345.

public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseUrls("http://*:3456")
                .UseStartup<Startup>()
                .Build();

　也可以通過curl命令（curl ip:埠）查看能否正常訪問，將返回網站頁面信息。

2、加入Docker容器，容器中網站啟動自偵聽

　Demo獲取完畢，直接通過自偵聽方式啟動網站 dotnet run 也是可以正常訪問的。

　通過一組實驗之後，我得到了一組信息，包含了我們想要的結果：

　　2345：3456 -> 此方式為主機下項目直接共用到容器中，主機可改變，雙方可見，容器改變，僅容器可見，對主機文件並無影響。採用鏡像為dotnet ,並未構造自身的鏡像

　　總結：不採用jexus仍然能夠正常運行，jexus只是加強了更多的功能。既然有無jexus對我容器內部的網站啟動作用不大，那麼我就可以考慮在Docker中除非有特殊情況，否則我是堅決不會將jexus加入到Docker中。當然，主機上的jexus功能還是需要留著的，只是容器中jexus存在的必要性就要考慮了。

直接通過主機上的Git獲取項目　　

　　通過指令將項目共用到容器中，主機上的直接修改將影響中容器內部的修改，而容器中對文件的修改卻是隔離主機的，不對實際的文件進行改變。

docker run -dit -p 2345:3456 --privileged=true -v /HDShop:/HDShop microsoft/dotnet

　　這樣一來，我在主機上獲得項目，直接在容器中進行編譯，運行，是不錯的。那麼容器中Git存在的必要性被我否決掉了。通過實際操作，這是很可行的，外網也能正常訪問。甚至是說，我接下來的所有操作，都將依賴這種形式。

　　同樣來講，我在主機上直接修改，容器中生效，那麼容器中在去安裝Vim也就不必要了，除非來說容器中的文件要相對主機上的要做一些改動，那麼便下載一個Vim把，畢竟容器中可沒有Vim。

　　敲vim命令時提示說：vim: command not found，這個時候就需要安裝vim，可是當你敲apt-get install vim命令時，提示：

Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package vim

這時候需要敲：apt-get update，這個命令的作用是：同步 /etc/apt/sources.list 和 /etc/apt/sources.list.d 中列出的源的索引，這樣才能獲取到最新的軟體包。

等更新完畢以後再敲命令：apt-get install vim命令即可。

　　在此我遇到了一些問題，不知是日誌信息過多還是軟體安裝將容器中的空間竟然占滿了，以至於我想改動配置文件但無法正常保存。看到了幾篇文章說docker容器所在目錄承載的能力有限建議切換到其他目錄下，我沒有去嘗試，有需要的朋友可以嘗試嘗試。

　　遇到的場景：http://blog.csdn.net/niu_hao/article/details/78873076

　　解決方案：https://www.cnblogs.com/HD/p/4807088.html

個人推薦方案：

　　在沒有使用dockerfile的情況下，直接通過手動部署

　　我推薦將項目直接先獲取到主機，然後通過共用到容器中，直接通過主機上的vim和git方便修改文件。容器中不再加入jexus，而是採用自偵聽的方式.

　　如果直接在容器中下載git、vim和jexus，很費時間和精力。同時浪費了容器的磁碟空間。

　　主機上的jexus可用可不用，推薦還是用上，畢竟功能很多。

三、加入Dockerfile

　　開始通過Dockerfile來構建鏡像，首先是來學習學習Dockerfile：http://blog.csdn.net/qq_29999343/article/details/78318397

　　ok，接下來開始寫一個Dockerfile

　　註意dockerfile文件的放置位置

　　當我們的項目發佈如果就在項目所在文件夾，那麼就在發佈後的文件夾里協商Dockerfile即可，總之跟著發佈後的文件夾跑

　　我嘗試的時候，發佈文件夾在其它目錄下，然後將Dockerfile建設到項目所在文件夾，然後創建我的鏡像，結果是鏡像有了，容器創建成功了，

　　也將容器中的服務跑起來了但是直接訪問不行。猜想主要還是當前文件夾並非發佈後的文件夾造成的。

　　編寫Dockerfile：https://www.cnblogs.com/savorboard/p/dotnetcore-docker.ht

　　開始編寫我的Dockerfile：

　　1、touch Dockerfile

　　2、vim Dockerfile

　　3、內容

#基於microsoft/aspnetcore鏡像構建新鏡像
FROM microsoft/aspnetcore

#拷貝當前文件夾內容到容器指定目錄
COPY . /hdshop

#設置工作目錄
WORKDIR /hdshop

#設置對外暴露埠
EXPOSE 3456

# 設置啟動後運行指令
CMD ["dotnet","hdshop.dll"]

:wq保存退出

通過指令docker build -t hdshopimage . 註意末尾的點記得加上，那是指代當前目錄

　查看當前鏡像docker images

　根據鏡像來構建新容器 docker run --name firstContainer -d -p 2345:3456 hdshopimage

　查看當前容器docker ps 或是通過訪問容器內運行著的網站，可以發現容器已經有了網站已經跑起來了。

　註意，在寫Dockerfile時，其中對外暴露的埠是容器對外暴露的埠，也就是說如果想要實現對內服務埠是80埠或者其它固定埠，那隻有我們在程式中進行設置，所以推薦採用程式中的UseUrls("http://*80")進行統一設置內部埠為80埠

　Dockerfile對於單機而言由於對外埠的唯一性，假設只在一臺伺服器上，從一個服務需要創建一個dockerfile來講，是有點繁瑣，但是考慮到時間線的延長，所有Dockerfile都已經寫好了，假設一些容器宕機了，可以很快直接利用dockerfile進行新建，那還是很不錯得。

Docker 容器之間進行互聯：

容器雖然職責是單一任務，但不可避免的會有需要與其它容器進行交互的場景，單台伺服器下我們可以通過--link實現容器之間互聯，這是通過網關的形式，直接在內網中進行調用，http://blog.csdn.net/halcyonbaby/article/details/42112325。

四、自我總結經驗

　　通過編寫Dockerfile，實現容器根據腳本自動創建，通過jexus和docker結合使用的嘗試，解答了我不少之前的問題，也讓我掌握更多容器適應場景。

　　慢慢地得出一點經驗，雖然可能這些經驗不一定是正確的，但至少是我經歷過的，有過這種經歷，可比看幾篇文章感覺爽快的多，還是推薦大家手腦並用，只看不做實在是難以體會到其中困難。

　　之後，我想嘗試下容器之間的互聯操作，這次只是大概瞭解了一下，並沒有過多的嘗試。可以想象的到，容器互聯之間肯定是有很多坑要踩的。

2018-2-13,望技術有成後能回來看見自己的腳步

對.Net Core結合Docker和Jexus的實踐