[聚合文章] 对.Net Core结合Docker和Jexus的实践

.Net 2018-02-13 1 阅读

本文基于上次尝试之后的进一步尝试,加入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,望技术有成后能回来看见自己的脚步

 

注:本文内容来自互联网,旨在为开发者提供分享、交流的平台。如有涉及文章版权等事宜,请你联系站长进行处理。