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

本文基于上次尝试之后的进一步尝试,加入Docker容器、编写Dockerfile,并且jexus结合Docker的使用,总结下自己的个人感想。

一、环境介绍

当前的场景有两种方式将Demo实现运行,一种是我将Asp.Net Core项目通过自侦听方式启动,然后外网正常访问,第二种通过功能强大的jexus作为代理,将项目发布后部署到jexus配置下,通过修改配置文件,通过jexus进行反向代理,此时项目本身可以不需要自侦听方式。

当前的场景是直接在主机下进行的,并没有加入到Docker容器中。

二、Docker中启动网站(暂未加入Dockerfile)

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

首先,摆在面前的就有一个问题,我是直接根据镜像建立容器,然后在容器中安装Git获取项目、安装jexus部署项目、安装vim修改配置文件,还是直接获取项目后自启动侦听呢。

不得不承认这两种情形都是很糟糕的,或许来说功能实现了,但是这个实现的过程是很不值得的,恰巧,我就完完全全走了一遍。

^_^

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

通过之前的一篇文章http://www.cnblogs.com/CKExp/p/8159269.html不难将Docker环境搭建起来,此处将不再制造轮子。

一步一步分析,首先在容器中安装Git,也就意味着假如我要操作上百个容器那不是意味着我要安装上百次Git,同理jexus,也同理Vim,这是很不值得的,然后我在想,能否将这些个软件写到Dockerfile中呢,可以,但谁又会这么去做呢。

不扯远了,单讲讲网站启动,我在容器中通过将网站发布后,重新启动jexus,通过外网访问(ip:端口),可以访问的通,还是很开心的,至少没出什么问题。

<strong>dotnet publish -o /var/www/HDShop</strong><br /><strong>sh /usr/jexus/jws restart</strong>

注意,这里的端口已经有了映射关系,我在建立容器的时候就已经指定了容器对外访问端口,所以网站的默认端口已经不合适了,我直接在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 也是可以正常访问的。

通过一组实验之后,我得到了一组信息,包含了我们想要的结果:

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

2345:3456 -> 此方式为主机下项目直接共享到容器中,主机可改变,双方可见,容器改变,仅容器可见,对主机文件并无影响 。采用镜像为dotnet ,并未构造自身的镜像

总结:不采用jexus仍然能够正常运行,jexus只是加强了更多的功能。既然有无jexus对我容器内部的网站启动作用不大,那么我就可以考虑在Docker中除非有特殊情况,否则我是坚决不会将jexus加入到Docker中。当然,主机上的jexus功能还是需要留着的,只是容器中jexus存在的必要性就要考虑了。

直接通过主机上的Git获取项目

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

通过指令将项目共享到容器中,主机上的直接修改将影响中容器内部的修改,而容器中对文件的修改却是隔离主机的,不对实际的文件进行改变。

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 

# 设置启动后运行指令
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结合使用的尝试,解答了我不少之前的问题,也让我掌握更多容器适应场景。

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

慢慢地得出一点经验,虽然可能这些经验不一定是正确的,但至少是我经历过的,有过这种经历,可比看几篇文章感觉爽快的多,还是推荐大家手脑并用,只看不做实在是难以体会到其中困难。

之后,我想尝试下容器之间的互联操作,这次只是大概了解了一下,并没有过多的尝试。可以想象的到,容器互联之间肯定是有很多坑要踩的。

<strong>2018-2-13,望技术有成后能回来看见自己的脚步</strong>

相关推荐