本文基于上次尝试之后的进一步尝试, 加入 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, 而是采用自侦听的方式.
如果直接在容器中下载 gitvim 和 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:
- touch Dockerfile
- 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 结合使用的尝试, 解答了我不少之前的问题, 也让我掌握更多容器适应场景
慢慢地得出一点经验, 虽然可能这些经验不一定是正确的, 但至少是我经历过的, 有过这种经历, 可比看几篇文章感觉爽快的多, 还是推荐大家手脑并用, 只看不做实在是难以体会到其中困难
之后, 我想尝试下容器之间的互联操作, 这次只是大概了解了一下, 并没有过多的尝试可以想象的到, 容器互联之间肯定是有很多坑要踩的
来源: https://www.cnblogs.com/CKExp/p/8445836.html