.NET遇上Docker - 使用Docker Compose组织Ngnix和.NETCore运行

时间:2023-03-08 16:54:38

本文工具准备:

  • Docker for Windows
  • Visual Studio 2015 与 Visual Studio Tools for Docker
  • 或 Visual Studio 2017 需要在安装时选择“容器开发支持”,如图:

.NET遇上Docker - 使用Docker Compose组织Ngnix和.NETCore运行

Docker的思想是将不同的应用放在不同的容器中分开运行,如运行.NetCore Web的典型组合Nginx+.NETCore(kestrel),我们应该使用一个容器运行Nginx,另一个容器运行.NETCore App。

之前还陷入一个误区,一直在研究如何将dotnet与Nginx配置实现到一个Dockerfile中,后来了解到Docker Compose才知道这两者应该分开到不同的容器。

服务器端安装Docker与Docker Compose

此文

DotnetCore的Dockerfile

一般来说通过Visual Studio 2015 Tools for Docker给项目添加Docker支持后,项目中就会有Dockerfile与docker-compose.xml的初始模板。只需要修改其中的内容适应我们的项目即可。

Visual Studio的2017可以在新建项目时,或建立项目以后选择添加Docker支持。

Visual Studio 2017稍有不同的是其将docker-compose.yml文件作为解决方案级文件来管理。这对于组合多个项目是很有帮助的。如图:

.NET遇上Docker - 使用Docker Compose组织Ngnix和.NETCore运行

本文最初编写时项目使用的Visual Studio 2015,所以docker-compose.yml还都是在Web项目中。但下文的设置对这两种组织方式都支持,稍微调整一下路径即可。

首先是默认Dockerfile的文件,我们将其配置为运行dotnet

FROM microsoft/aspnetcore:1.0
ENTRYPOINT ["dotnet", "orgname.projname.WebApi.dll"]
ARG source=.
WORKDIR /app
EXPOSE 5000
COPY $source /app

aspnetcore这个Iamge有1.0和1.1两个版本,根据项目所使用的.NETCore版本自行更换

单独测试下这个Dockerfile的image生成

docker rmi orgname/projname.core:test
docker build --rm -t orgname/projname.core:test -f Dockerfile .

测试下镜像作为容器运行:

docker run --name projname.core.inst -p 5000:5000 orgname/projname.core:test

测试完成后,把所有测试产物,如镜像和容器,都删除。

docker stop projname.core.inst
docker rm -f projname.core.inst
docker rmi orgname/projname.core:test

在刚开始编写Dockerfile打包镜像时,可能会反复进行生成,运行容器的步骤。为了方便测试,楼主把这些脚本整合成了一个buildtest.bat,如下。

@echo on

SET /p app=.NETCoreWeb(d)Nginx(n)
SET /p job=生成并运行(r)清理(c)
SET /p mode=交互运行(i)后台运行(b) if "%app%"=="d" (
SET contName=projname.core.inst
SET imagName=orgname/projname.core:test
SET file=Dockerfile
)
if "%app=%"=="n" (
SET contName=projname.core.pub.inst
SET imagName=orgname/projname.core.pub:test
SET file=Dockerfile-Nginx
) if "%mode%"=="i" (
SET operate=-it
)
if "%mode%"=="b" (
SET operate=-d
) if "%job%"=="r" (
GOTO Build
)
if "%job%"=="c" (
GOTO Clear
) :Build
docker stop %contName%
docker rm -f %contName%
docker rmi %imagName%
docker build --rm -t %imagName% -f %file% .
docker run %operate% --name %contName% -p 5000:5000 -e "ASPNETCORE_ENVIRONMENT=Staging" %imagName%
GOTO End :Clear
docker stop %contName%
docker rm -f %contName%
docker rmi %imagName%
docker ps -a
docker images
GOTO End :End

楼主一般用Docker for Windows做测试,自然也就写了批处理的脚本,后来(这篇文章慢慢的攒了一段时间才最终完成)为了调试方便转投PowerShell。

包括这个脚本在内的本文提供的几个脚本都非常好用,谁用谁知道。

Nginx的Dockerfile

首先是Nginx的配置文件,这是比较重要的一个配置,Nginx的Docker Image生成到时候会复制这个文件到Nginx Docker Image内。

本文介绍普通的80端口的转发,配置如下:

server {
listen 8081; location / {
proxy_pass http://core-app:5000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}

注意 配置中的转发地址,不再是localhost,而是需要根据link所指定的服务/容器的别名来确定。这个link参数,在下面有示例。

这个涉及到Docker网络,这是个非常复杂的话题。

注意nginx.conf需要ANSI编码,且换行为Linux格式,否则导入容器中可能会报错。(可以使用Notepad++编辑,使用VS编辑可能会出问题)

还可以配置Nginx使用HTTPS,或者使用Nginx配置简单的负载均衡,如果以后楼主有机会研究的话会再写文章分享。

测试下Nginx的Docker Image的生成:

docker build --rm -t orgname/projname.core.pub:test -f Dockerfile-Nginx .

启动容器来测试:

docker run --name projname.core.pub.inst -p 8081:8081 --link projname.core.inst:core-app orgname/projname.core.pub:test

注意:link即指示链接到的之前创建的运行.net core的容器,冒号后面部分是指定别名。这个别名就是前文Ngnix配置文件中,所转发的地址。

如果启动Nginx容器后,可以通过Nginx访问.NET Core Web App,说明到此为止的配置都是正确的。

可以继续配置docker compose了。

清理测试产物:

docker stop projname.core.pub.inst
docker rm -f projname.core.pub.inst
docker rmi orgname/projname.core.pub:test

将docker相关文件添加到项目发布文件

(VS2015)编辑project.json文件中publishOptions-include的数组,将Dockerfile、Dockerfile-Nginx、nginx.conf及docker-compose.yml添加到其中。

一般来说,按照之前步骤添加“Docker Support”后,插件会自动将相关文件添加到project.jsonpublishOptions中,这一步进行确认就好。

(VS2017)在解决方案资源管理器中将Dockerfile、Dockerfile-Nginx、nginx.conf及docker-compose.yml包含在项目中。“复制到输出目录”选择“如果较新则复制”。

发布项目

使用下面命令发布项目

dotnet publish --framework netcoreapp1.0 --configuration release --output publish.linux

可以将这条命令保存为一个批处理文件,如publish.linux.bat,放到项目根目录下

编辑Docker Compose配置文件

docker compose配置文件基本上就之前用到的docker build和docker run命令的另一种表述形式

version: '3'

services:
orgname.projname.webapi:
image: orgname/projname.core:${TAG}
build:
context: .
dockerfile: Dockerfile
expose:
- "5000"
container_name: projname.core.inst
environment:
- ASPNETCORE_ENVIRONMENT=Development
volumes:
- ./log:/app/log:rw
deploy:
restart_policy:
condition: always
orgname.projname.webapi.pub:
image: orgname/projname.core.pub:${TAG}
build:
context: .
dockerfile: Dockerfile-Nginx
ports:
- "8081:8081"
links:
- orgname.projname.webapi:core-app
container_name: projname.core.pub.inst volumes:
orgname.projname.webapi:

注意,服务orgname.projname.webapi中,使用expose来暴露端口,因为我们不需要将端口暴露给docker外部。另外我们也将日志输出到挂在到Docker的主机目录,这样方便查看日志。

提示 强烈推荐使用version3版本的compose文件。version3中新增deploy选项,可以实现docker run --restart选项的作用控制容器在失败等情况下自动重启,从而保证服务的无人值守运行。compose选项详见此文档

构建Image

项目发布完成后,进入发布文件夹publish,执行下面的命令生成相关镜像

docker-compose build

提示,可以在使用docker compose生成之前,分别使用docker build单独生成dotnet core和nginx的镜像进行测试,就像介绍Dockerfile那部分所述。

启动docker compose

确定compose生成好image后,就可以启动服务(容器)了:

docker-compose start

可以使用下面的命令将Build、Start一起完成。

docker-compose up

服务启动后,可以通过Nginx服务访问.NET Core App。

上面的命令会在前台运行并打印日志到控制台。

如果需要在后台运行“服务”,使用-d参数:

docker-compose up -d

docker compose启动的也是普通的容器,通过docker ps也可以看到compose启动的容器。

如果需要停止docker compose启动的服务,使用:

docker-compose down

注意:服务的容器将被删除,所有容器中的数据(非主机挂载到容器目录下)将丢失。

这一小节介绍的方式是在Docker for Windows中使用docker compose运行服务,而实际情况下我们需要在服务器去运行docker compose,具体方式后文有介绍。

其它相关命令:

查看compose相关服务运行状态:docker-compose ps

重启compose中的服务:docker-compose restart

环境

在程序开发中,在不同环境下使用不同的配置是很常见的情况。

如.NET Core就定义了三种默认的环境 - Development、Staging和Production。

体现在配置文件上,有appsettings.jsonappsettings.Staging.jsonappsettings.Production.json等文件

楼主一般将其分别用作开发、测试和生产环境的配置,相信大部分人也都是这么干的。

.NET Core Web应用会根据一个名为ASPNETCORE_ENVIRONMENT的环境变量来判断应用所处的环境。所以我们需要做的就是在生成镜像时将这个变量传入

docker compose的environment就是做这个用的,比如我们将docker-compose.yml文件中orgname.projname.webapi这个服务的定义改为:

environment:
- ASPNETCORE_ENVIRONMENT=Staging

则我们的.NETCore应用将以Staging环境运行,并使用appsettings.Staging.json这个配置文件。

然后我们利用VS Tool for Docker创建的其它两个文件(docker-compose.dev.debug.ymldocker-compose.dev.release.yml)来实现不同环境的配置分离(VS2017中这两个文件中的dev改为vs)。

其实那两个文件是用于VS集成的Docker调试和发布用的,不过我这里不打算依赖工具,而是通过命令行的形式完成工作。所以删除两个文件中原有的内容,并改为我们自己所需。

要使两个配置文件共同工作,最主要的还是靠docker compose对多配置文件的支持。其-f选项可以设置多次,docker compose会把其中的选项叠加。

如:

docker-compose.exe -f docker-compose.yml -f docker-compose.dev.debug.yml build

下面来分别看下用于不同环境的配置文件

首先是docker-compose.dev.debug.yml

version: '3'

services:
orgname.projname.webapi:
environment:
- ASPNETCORE_ENVIRONMENT=Staging
env_file:
- staging.env

其中的env_file指定的staging.env用于演示,由于我们的例子需要配置的环境变量很少,所以无需使用这个文件。文件的格式很简单,就是键值对的格式:

ENV=VAL

注意,这个文件要使用ANSI编码,不然会因为编码问题导致实际定义的变量和期望定义的变量不一致。

提示:可以使用下面的命令,确认compose执行时的配置

docker-compose.exe -f docker-compose.yml -f docker-compose.dev.debug.yml config

这对于检查环境变量等设置是否正确很有帮助。在确认无误后再进行buildup操作。上面说得env文件的编码问题,就是通过config命令查出来的。(下文的composebuild.bat集成了这个检查的功能)

然后是docker-compose.dev.release.yml,内容也差不多:

version: '3'

services:
orgname.projname.webapi:
environment:
- ASPNETCORE_ENVIRONMENT=Production

另外我们还要给测试和生产环境的image打上不同的tag。这个需要修改一下之前编辑的docker-compose.yml中服务定义中image那个配置:

image: orgname/projname.core:${TAG}

image: orgname/projname.core.pub:${TAG}

将它们的版本号都改为插值计算的方式。

docker compose可以由当前执行的环境中获取这些值的定义。比如shell中EXPORT的变量,或者cmd中SET的变量。

在Windows下,我们借助如下的批处理(composebuild.bat)来帮助定义这个变量,并执行docker compose命令:

@echo off

SET /p mode=测试(t)发布(p)
SET /p job=检查(c)生成(b)运行(u)清理(r) if "%job%"=="c" (
SET operate=config
)
if "%job%"=="b" (
SET operate=build
)
if "%job%"=="u" (
SET operate=up
) if "%mode%"=="t" (
SET TAG=test
)
if "%mode%"=="p" (
SET TAG=1.0.0
)
if "%job%"=="r" (
docker rmi orgname/projname.core.pub:%TAG%
docker rmi orgname/projname.core:%TAG%
GOTO End
) if "%mode%"=="t" (
SET fileyml=docker-compose.dev.debug.yml
GOTO Build
)
if "%mode%"=="p" (
SET fileyml=docker-compose.dev.release.yml
GOTO Build
)
:Build
docker-compose -f docker-compose.yml -f %fileyml% %operate% :End

这个脚本有一个小问题,在后续章节,会介绍将Image推送到注册中心,而推送到注册中心需要一个tag操作。而这个脚本删除这些被tag的Image,只会解除tag,而不删除Image,最终导致本地残留很多无tag的Image。可以全部工作结束后使用下面的PowerShell命令,统一删除:

Get-ContainerImage | ? {$_.RepoTags -eq $null} | foreach { Remove-ContainerImage $_.ID }

运行这个命令需要安装Docker-PowerShell,可参见此文

运行这个批处理,选一下需要运行的选项便可以通过docker compose在不同的环境下生成镜像或启动服务。

注意:所有这些文件都记得加入project.json中(VS2015),包含到项目并复制到输出目录(VS2017)

添加到镜像仓库

这是可选步骤,也可以在把Dockerfile和发布文件上传到服务器并在服务器上生成镜像。见总结。

可以使用Harbor构建一个私有Docker仓库。Harbor相对于Docker官方库就像GitLab相对于GitHub。Harbor的安装和基本使用参见此文

Docker的Image进行分层存储,所以第一次push到私有仓库的上传量比较大,之后将只是推送改变的层。数据传输量比较小。

push操作的操作的基本部分在那篇介绍Docker的文章中有介绍。这里我们只是给出脚本,可以按照提示执行即可,嗯,这是一个PowerShell脚本(ImagesPush.ps1),不再是批处理了。

$reghost="register-host"
$regport="register-port"
$dockerregister="$($reghost):$($regport)" echo "测试(t)发布(p)"
$operation=Read-Host
Switch($operation)
{
"t" {$tag="test"}
"p" {$tag="1.0.0"}
} #docker login $dockerregister docker tag orgname/projname.core:$tag $dockerregister/orgnameprojname/projname.core:$tag
docker tag orgname/projname.core.pub:$tag $dockerregister/orgnameprojname/projname.core.pub:$tag docker push $dockerregister/orgnameprojname/projname.core:$tag
docker push $dockerregister/orgnameprojname/projname.core.pub:$tag

从镜像仓库获取并启动服务

通过Docker启动服务,docker-compose.yml是必备的。(我们执行docker-compose命令的目录下必须有这个文件,不然分分钟报错。)

我们之前那个docker-compose.yml文件所创建容器的镜像是通过Build Dockerfile来得到的,这里我们要新建这样的一个docker-compose.yml,其使用一个现成的Image来启动容器。

我们新建一个名为docker-compose.server.yml的文件(不要怀疑名字错了)。

version: '3'

services:
orgname.projname.webapi:
image: {REG}/orgnameprojname/projname.core:{TAG}
expose:
- "5000"
container_name: projname.core.inst
environment:
- ASPNETCORE_ENVIRONMENT={ENV}
volumes:
- ./log:/app/log:rw
deploy:
restart_policy:
condition: always
orgname.projname.webapi.pub:
image: {REG}/orgnameprojname/projname.core.pub:{TAG}
ports:
- "8081:8081"
links:
- orgname.projname.webapi:core-app
container_name: projname.core.pub.inst volumes:
orgname.projname.webapi:

与之前文件的最大不同,这个配置没有了build这个小节。

而镜像就需要从注册中心拉取,直接上脚本(ImagesPull.ps1),然后稍作解释:

$reghost="register-host"
$regport="register-port"
$dockerregister="$($reghost):$($regport)" echo "Test(t) Publish(p)"
$operation=Read-Host
Switch($operation)
{
"t" {$tag="test";$envstr="Staging"}
"p" {$tag="1.0.0";$envstr="Production"}
}
docker login $dockerregister docker pull $dockerregister/orgnameprojname/projname.core:$tag
docker pull $dockerregister/orgnameprojname/projname.core.pub:$tag ni docker-compose.yml -ItemType File -Force
(get-content docker-compose.server.yml) -replace "{TAG}","$($tag)" -replace "{REG}","$($dockerregister)" -replace "{ENV}","$($envstr)" | set-content docker-compose.yml # remove old container
docker-compose down docker-compose up

是的,这是一个PowerShell脚本,PowerShell现在也可以用Linux,虽然还处在测试状态。在CentOS7.3中有一堆显示方面的bug,中文支持也没有(所以上面的脚本没有中文),主要功能方面还是很正常的。

Linux上安装PowerShell可见此文档

脚本中,首先登录镜像仓库并下载镜像,然后按照用户输入将docker-compose.server.yml进行插值得到需要的docker-compose.yml文件,最后启动docker compose。

网络

网络方面,Docker-Conpose为应用创建一个子网络,Docker-Compose将每个Service作为一个容器实例,并加入到这个网络中,网络中的容器可以彼此访问。

容器间以容器名称作为主机名来互相访问。

Docker网络这块水很深,楼主对这个了解几乎没有。

总结

借用此部分墙裂推荐Cmder这个神奇,虽然时不时的会有光标错位,中文重叠等问题,但绝对是取代自带控制台的必备工具。

最后总结一下,在上面的所有配置文件准备妥当后,每次修改得到新版本后只需要执行下列步骤:

方式1:

  1. 执行publish.linux.bat生成项目发布文件
  2. 运行buildtest.bat验证Dockerfile正常工作
  3. 运行composebuild.bat根据提示选择在测试环境还是发布环境下验证配置、生成镜像
  4. 使用ImagesPush.ps1将生成的镜像发布到Harbor
  5. 在服务器上使用ImagesPull.ps1拉取镜像并使用compose启动服务。(先要把docker-compose.server.yml放到与ImagesPull.ps1服务器端相同目录下)

方式2:

  1. 执行publish.linux.bat生成项目发布文件,将所有文件上传到服务器
  2. 在服务器端使用composebuild.bat来运行服务。(目前楼主没有使用这种方法,所以没有将这个脚本用shell或者powershell重写)

如果您有更好的实现方法,欢迎评论区指点一二。