对.Net Core结合Docker和Jexus的实践

　　本文基于上次尝试之后的进一步尝试，加入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 : --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，接下来开始写一个Dockerfile，注意dockerfile文件的放置位置，当我们的项目发布如果就在项目所在文件夹，那么就在发布后的文件夹里协商Dockerfile即可，总之跟着发布后的文件夹跑，我尝试的时候，发布文件夹在其它目录下，然后将Dockerfile建设到项目所在文件夹，然后创建我的镜像，结果是镜像有了，容器创建成功了，也将容器中的服务跑起来了但是直接访问不行。猜想主要还是当前文件夹并非发布后的文件夹造成的。

　　编写Dockerfile：https://www.cnblogs.com/savorboard/p/dotnetcore-docker.ht

　　1、touch Dockerfile

　　2、vim Dockerfile

　　3、内容

#基于microsoft/aspnetcore镜像构建新镜像
FROM microsoft/aspnetcore

#拷贝当前文件夹内容到容器指定目录
COPY . /hdshop

#设置工作目录
WORKDIR /hdshop

#设置对外暴露端口
EXPOSE 

# 设置启动后运行指令
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,望技术有成后能回来看见自己的脚步