Notice: Constant WP_DEBUG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 12

Notice: Constant WP_DEBUG_LOG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 13

Notice: Constant WP_DEBUG_DISPLAY already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 14
使用Docker Compose 组织 Ngnix 和 .NETCore 运行【zoues.com】 – zoues

LOADING

Follow me

使用Docker Compose 组织 Ngnix 和 .NETCore 运行【zoues.com】
四月 23, 2017|DockerPaaS

使用Docker Compose 组织 Ngnix 和 .NETCore 运行【zoues.com】

使用Docker Compose 组织 Ngnix 和 .NETCore 运行【zoues.com】

(点击上方蓝字,可快速关注我们)


来源:hystar

cnblogs.com/lsxqw2004/p/6709766.html

本文工具准备:

  • Docker for Windows

  • Visual Studio 2015 与 Visual Studio Tools for Docker

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

使用Docker Compose 组织 Ngnix 和 .NETCore 运行

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

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

服务器端安装Docker与Docker Compose

见此文(https://github.com/lsxqw2004/TechDoc/blob/master/Docker%E5%AE%89%E8%A3%85(CentOS).md)

DotnetCore的Dockerfile

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

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

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

使用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:testdocker 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 onSET /p app=.NETCoreWeb(d)Nginx(n)SET /p job=生成并运行(r)清理(c)SET /p mode=交互运行(i)后台运行(b)if “%app%”==”d” (SET contName=projname.core.instSET imagName=orgname/projname.core:testSET file=Dockerfile

)if “%app=%”==”n” (SET contName=projname.core.pub.instSET imagName=orgname/projname.core.pub:testSET 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)

:Builddocker 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:Cleardocker stop %contName%

docker rm -f %contName%

docker rmi %imagName%

docker ps -a

docker imagesGOTO 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.json的publishOptions中,这一步进行确认就好。

(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.json、appsettings.Staging.json及appsettings.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.yml和docker-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

这对于检查环境变量等设置是否正确很有帮助。在确认无误后再进行build或up操作。上面说得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,可参见此文(https://github.com/lsxqw2004/TechDoc/blob/master/Docker%E5%AE%89%E8%A3%85%28CentOS%29.md)

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

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

添加到镜像仓库

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

可以使用Harbor构建一个私有Docker仓库。Harbor相对于Docker官方库就像GitLab相对于GitHub。Harbor的安装和基本使用参见此文(http://www.cnblogs.com/lsxqw2004/p/6668788.html)。

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 $dockerregisterdocker 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可见此文档。

https://github.com/lsxqw2004/TechDoc/blob/master/PowerShell%E5%A4%A7%E5%85%A8.md

脚本中,首先登录镜像仓库并下载镜像,然后按照用户输入将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重写)

看完本文有收获?请转发分享给更多人

关注「DotNet」,提升.Net技能 

使用Docker Compose 组织 Ngnix 和 .NETCore 运行

no comments
Share