ASP.NET Core amp; Docker 实战经验分享

一.前言

最近一直在研究和实践ASP.NET Core、Docker、持续集成。在ASP.NET Core 和 Dcoker结合下遇到了一些坑，在此记录和分享，希望对大家有一些帮助。

二.中间镜像

我前面写过一个《ASP.NET Core & Docker 零基础持续集成》的教程。里面我们通过持续集成工具Jenkins构建Docker镜像并运行容器，采用的是Docker Compose来进行编排构建运行的（Visual Studio 2017添加Docker支持是采用的Docker Compose）。细心的朋友可能会发现，每次构建完毕以后通过docker images命令查询，可以发现多了许多没有名称（）的镜像。这些都是构建过程中的中间镜像，我们可以在构建完成以后进行统一删除。

删除所有无名称镜像：

docker rmi $(docker images -f "dangling=true" -q)

此命令应当加在构建的最后一步，示例：

echo ---------------Remove-Orphans------------------
docker-compose -f src/docker-compose.yml -f src/docker-compose.override.yml  -p alipaydemo down --rmi local --remove-orphansecho ---------------Publishing...------------------
docker-compose -f "src/docker-compose.yml" -f "src/docker-compose.override.yml"  -p alipaydemo up -d --buildecho ---------------Clear-Images...------------------
docker rmi $(docker images -f "dangling=true" -q)

执行之后会看到以下效果：

这是非常有必要的，因为如果每次构建都残留一些中间镜像，会额外消耗我们的磁盘空间的。

后来的我们

主演：井柏然 / 周冬雨 / 田壮壮

猫眼电影演出广告

购买

三.固定容器外部端口

这里主要讲的是在自动化构建的过程中，通过docker compose来运行容器的外部端口，而不是直接通过docker run命令来指定。

我们通过Visual Studio 2017添加Docker支持（Docker Compose），通过Docker Compose编排构建运行容器，我们会发现每次构建以后，运行的容器的外部端口都不是固定的，比如32774、32775、32776等等。这对于我们设置了Nginx反向代理和API Gateway等配置的肯定是十分不方便的，我们每次构建完毕以后还要去改这些配置，不是扯淡吗。所以我们需要固定我们容器运行的外部端口，我们可以通过改变docker compose的yml文件来固定容器的外部端口。

Visual Studio 2017 添加的Docker支持所生成的文件有如下结构：

我是用的版本为VS2017 15.6.5。如果是更早的版本添加Docker支持可能会多出一个docker-compose.ci.build.yml文件，其实这一步没必要，目前的最新的VS2017已经移除了该文件。

我们固定容器外部端口需要修改的是docker-compose.override.yml文件，我们需要修改的是ports。默认为：

ports:- "80"

这个80端口只是容器的内部端口，我们进行如下修改来知道容器运行时映射到服务器的端口也就是外部端口：

ports:- "32775:80"

通过上面的设置，我们将容器的外部端口指定为32775，这样我们在构建完成以后，容器运行以后的外部端口都将会为32775，无需再次修改Nginx反向代理等配置。

四.设置镜像版本

我们的应用程序具有不同的版本号，我们不同版本的应用程序构建出来的镜像应该也是具有不同的版本的，我们可以通过设置镜像的Tag来表示不同的版本：

我们同样可以在docker compose的yml里面进行设置，这次修改的是docker-compose.yml文件，我们直接在镜像的名称后面设置Tag，语法为：

image: <镜像名称>:<Tag>

比如我设置一个名为alipaydemo的镜像Tag为V1：

image: alipaydemo:v1

完整的配置分享：

version: '3'services:alipay.demo.pcpayment:    image: alipaydemopcpayment:v1    container_name: alipaydemocontainer    build:      context: .      dockerfile: Alipay.Demo.PCPayment/Dockerfile

五.设置容器名称

我们在通过docker compose运行的容器将会被指定一个默认的容器名称，如果是第四节的配置，那么容器的默认名称为alipaydemopcpayment.alipay.demo.pcpayment.build_1，具有非常一长串，此时我们可以自己来指定这个容器的名称，同样我们需要修改docker-compose.yml文件，设置容器名称的命令格式为：

container_name: <容器名称>

完整的配置分享：

version: '3'services:alipay.demo.pcpayment:   
 image: alipaydemopcpayment:v1   
 container_name: alipaydemocontainer  
 build:      context: .    
 dockerfile: Alipay.Demo.PCPayment/Dockerfile

通过上面的配置我们将容器名称设置为了alipaydemocontainer

六.设置容器重启策略

某一天我对服务器进行了重启，重启以后发现通过Docker运行的服务无法访问了，然后查看原因，发现Docker服务没有开机自启，启动了Docker以后发现容器又没有自动启动。

1.设置Docker开机自启

我们可以直接通过chkconfig命令来设置Docker开启自启：

chkconfig docker

执行成功如下：

2.设置容器随Docker启动

我们要让容器随Docker启动，就必须设置容器的重启策略为always，我们通过docker compose来运行容器时可以在yml里面指定。打开docker-compose.override.yml文件，添加配置：

restart: always

完整的配置示例：

version: '3'services:alipay.demo.pcpayment:    restart: always    environment:- ASPNETCORE_ENVIRONMENT=Production    ports:- "32775:80"

七.Docker的重启策略

1.设置容器重启策略

这里讲的设置容器重启策略主要是通过命令来进行交互，并非第六节讲的通过docker compose来设置重启策略，是对第六节的一个扩展阅读。

我们可以在使用docker run命令时通过--restart参数来设置重启策略：

docker run -d --restart=always alipaydemodocker run -d --restart=on-failure:10 alipaydemo

第一条命令代表容器退出时总是重启容器，第二条代表在容器非正常退出时重启容器，最多重启10次。

对于已经运行的容器可以通过docker update命令来指定：

docker update --restart=always alipaydemo

2.Docker容器的重启策略

Docker容器的重启策略是面向生产环境的一个启动策略，在开发过程中可以忽略该策略。
Docker容器的重启都是由Docker守护进程完成的，因此与守护进程息息相关。
Docker容器的重启策略如下：

no，默认策略，在容器退出时不重启容器
on-failure，在容器非正常退出时（退出状态非0），才会重启容器
on-failure:3，在容器非正常退出时重启容器，最多重启3次
always，在容器退出时总是重启容器
unless-stopped，在容器退出时总是重启容器，但是不考虑在Docker守护进程启动时就已经停止了的容器

3.Docker容器的退出状态码

docker run的退出状态码如下：

0，表示正常退出
非0，表示异常退出（退出状态码采用chroot标准）
125，Docker守护进程本身的错误
126，容器启动后，要执行的默认命令无法调用
127，容器启动后，要执行的默认命令不存在
其他命令状态码，容器启动后正常执行命令，退出命令时该命令的返回状态码作为容器的退出状态码

参考资料：https://blog.csdn.net/taiyangdao/article/details/73076019

八.设置自动交互

我们在编写Dockerfile时，可以通过RUN命令来运行一些命令，由此我们可以通过运行apt-get等命令，将一些必要的组件安装到我们的镜像之中，比如lsof等。我们有如下配置：

RUN apt-get install lsof

但是我们在安装一个组件时，非常有可能遇到交互操作，比如“Dou you want to xxx?[y/n]”等，遇到这种将会中断我们的Docker镜像构建过程，那么如何解决呢？我们可以给命令指定--assume-yes来实现自动交互：

RUN apt-get install lsof --assume-yes

持续集成自动化构建过程中，如若不设置自动交互将会被中断：

使用apt-get install命令以前，最好使用apt-get update更新一下，避免出现问题。

九.ASP.NET Core 生成图片问题

大家应该知道目前.NET Core(2.0)还是没有System.Drawing程序集，如果我们要使用Image等对象来完成生成图片验证码、图片二维码等操作只有通过第三方编写的组件，ZKWeb.System.Drawing便是其中一个，我们使用它以后，我们在windows上运行良好，无需其他额外的操作。但是我们一到Linux运行或者使用Docker（dotnet镜像使用的是ubantu环境）运行时，会发现程序无法正常生成图片，会出现异常，这是因为我们的zk在Linux/Docker下运行需要安装一个名为 libgdiplus 的组件，我们在构建Docker镜像的时候可以通过RUN命令使用apt-get命令进行安装：

RUN apt-get updateRUN apt-get install libgdiplus --assume-yesRUN cd /usr/lib
RUN ln -s libgdiplus.so gdiplus.dll

apt-get update是非常有必要的

完整的Dockerfile配置提供给大家参考：

FROM microsoft/aspnetcore:2.0 AS base
WORKDIR /app
EXPOSE 80FROM microsoft/aspnetcore-build:2.0 AS build
WORKDIR /src
COPY Alipay.Demo.PCPayment.sln ./
COPY Alipay.Demo.PCPayment/Alipay.Demo.PCPayment.csproj Alipay.Demo.PCPayment/
RUN dotnet restore -nowarn:msb3202,nu1503
COPY . .
WORKDIR /src/Alipay.Demo.PCPayment
RUN dotnet build -c Release -o /appFROM build AS publish
RUN dotnet publish -c Release -o /appFROM base AS finalWORKDIR /app
COPY --from=publish /app .RUN apt-get updateRUN apt-get install libgdiplus --assume-yesRUN cd /usr/lib
RUN ln -s libgdiplus.so gdiplus.dll
ENTRYPOINT ["dotnet", "Alipay.Demo.PCPayment.dll"]

十.写在最后

本文乃是我在实践ASP.NET Core & Docker & 持续集成过程中遇到的问题和解决之道，完完全全的实战经验、总结，希望能帮助到大家。关于实践ASP.NET Core & Docker 构建持续集成大家可以看我的这一系列文章：《ASP.NET Core & Docker 零基础持续集成》。本文所说的实战是我在实践我的开源项目：

https://github.com/dotnetcore/Alipay.AopSdk.Core

此项目及其演示项目通过持续集成自动化发布到Nuget和通过Docker运行。这个项目是一个支持.NET Core的支付宝的服务端SDK项目，不仅仅提供支付能力，还提供支付宝生活号、服务窗、行业合作等开发。觉得好的希望能给一个Star支持（手动滑稽）。

最后分享给大家一个高效写博客的方法，本文亦是用此来进行编写和发布：http://www.cnblogs.com/stulzq/p/9043632.html

原文地址：https://www.cnblogs.com/stulzq/p/9059108.html

.NET社区新闻，深度好文，欢迎访问公众号文章汇总 http://www.csharpkit.com

Reward

长按二维码向我转账