Docker容器环境下ASP.NET Core Web API

Docker容器环境下ASP.NET Core Web API应用程序的调试

本文主要介绍通过Visual Studio 2015 Tools for Docker – Preview插件,在Docker容器环境下,对ASP.NET Core Web API应用程序进行调试。在自己做实验的过程中也碰到了一些问题,经过一些测试和搜索资料,基本解决了这些问题,本文也会对这些问题进行介绍,以免有相同需求的朋友多走弯路。

插件的下载与安装

至撰写本文为止,Visual Studio 2015 Tools for Docker插件还是处于Preview的版本(版本号:0.31.0),可以点击此处下载。要正确安装此插件并能够成功地在Visual Studio 2015中使用该插件进行调试,需要满足以下先决条件:

本文将以VS 2015 Enterprise + Windows 10 + Docker for Windows作为开发环境进行介绍。

下载插件后,即可按照正常的软件安装过程进行安装。安装过程请退出Visual Studio 2015。安装成功后,可以在Visual Studio的“扩展与更新”中找到Visual Studio 2015 Tools for Docker – Preview:

在ASP.NET Core Web API项目上启用Docker的支持

打开我们的DockerWebAPI项目,在项目上单击鼠标右键,然后选择“添加 –>  Docker Support” 菜单:

经过一段时间,VS Tools for Docker就会在项目上添加一些文件:

我们暂时先不详细介绍这些文件的具体内容和作用。基本上在Properties目录下是给Visual Studio 2015和编译环境所使用的;而docker-compose以及Dockerfile都是给Docker所使用的,需要了解详细信息的朋友,可以先上网搜索了解一下。

开始调试ASP.NET Core Web API应用程序

在开始调试以前,请首先打开Docker for Windows的设置,在Shared Drivers里,把项目所在的驱动器勾选上。如果这步没有做,那么就无法成功启动调试器。

接下来,直接按下F5快捷键,就可以开始调试了。当然,也可以按下工具栏上的“启动”按钮来启动调试,可以看到,我们的调试按钮已经默认设置为Docker了:

Visual Studio 2015启动Debugger的过程大致如下:

  • 调用PowerShell脚本DockerTask.ps1,对环境进行清理,比如停止正在运行的容器,以及将已有的Docker Image删除
  • Visual Studio对项目进行编译
  • 调用PowerShell脚本DockerTask.ps1,将项目发布到bin/Docker/Debug/app目录
  • 开始根据docker-compose.debug.yml的文件内容,生成Docker Image
  • 启动Visual Studio Debugger,通过不断地ping http://localhost/api/values 端点,确保Docker Container已经成功加载
  • 打开默认浏览器,开始调试,等待断点命中

需要注意的是,VS Tools for Docker默认使用80端口,如果系统中已经安装有使用80端口的服务,比如IIS,请要么停止占用80端口的服务,要么修改项目中的yml文件,选择使用其它的端口。否则编译过程将无法完成。另一个需要注意的地方是,由于在上一次的案例中,我们通过UseUrls API指定了我们的应用程序可以接受来自任何地址的5000端口的请求,因此,我们也需要相应地修改docker-compose.debug.yml文件,使其能够将主机的80端口映射到5000端口,如下:

成功启动调试器之后,即可设置断点,待断点命中时,可以像调试普通C#应用程序那样,使用Visual Studio提供的各种调试体验。从下图可以看出,我们的调试上下文已经是在Docker容器中了(Environment.MachineName返回了Docker Container的ID):

有关自动生成的Docker Image

在Visual Studio Tools for Docker完成项目的编译之后,会生成一个名称为“username/xxxx: Debug”的Docker Image(xxxx为项目名称):

既然是一个Docker Image,那么我们应该可以使用docker run命令,在容器中执行这个Docker Image。现在我们来尝试一下:

发现并没有执行成功,提示了一个bash的错误:integer expression expected。此时也无法从浏览器访问这个应用程序。经过一段时间的研究,发现在Dockerfile.debug文件的最后一条ENTRYPOINT指令处,将:


1

ENTRYPOINT ["/bin/bash", "-c", "if [ \"$REMOTE_DEBUGGING\" -eq 0 ]; then dotnet DockerWebAPI.dll; else sleep infinity; fi"]

改为:


1

ENTRYPOINT ["/bin/bash", "-c", "if [[ \"$REMOTE_DEBUGGING\" -eq 0 ]]; then dotnet DockerWebAPI.dll; else sleep infinity; fi"]

(if后面的子句使用两个双括号)。

此时再次编译运行,调试过程也不会有什么问题,再次通过命令行执行新生成的Docker Image,可以看到,这个错误已经修复:

其实这只是我在使用VS Tools for Docker的一个小发现,并没有太大的实际意义:

  • 在Debug模式,如果不修复这个问题,Debugger照样可以启动
  • 在Release模式,Dockerfile根本就没有这条指令(因为Release模式下只需要正常启动应用程序就可以了)

反正在此也把这个心得分享出来,或许也能帮到有着同样疑惑的朋友。

总结

本文对Visual Studio Tools for Docker进行了简单的介绍。在后续的文章中,我还会继续介绍一些Docker的使用心得,并同时介绍一些ASP.NET Core Web API的开发经验。

分类: Docker.NET Core

时间: 2024-10-19 18:40:48

Docker容器环境下ASP.NET Core Web API的相关文章

Gitlab CI 自动部署 asp.net core web api 到Docker容器

为什么要写这个? 在一个系统长大的过程中会经历不断重构升级来满足商业的需求,而一个严谨的商业系统需要高效.稳定.可扩展,有时候还不得不考虑成本的问题.我希望能找到比较完整的开源解决方案来解决持续集成.监控报警.以及扩容和高可用性的问题.是学习和探索的过程分享给大家,也欢迎同行的人交流. 先来一个三步曲,我们将完成通过GitLab CI 自动部署 net core web api 到Docker 容器的一个示例.这是第一步,通过此文您将了解如何将net core web api 运行在Docker

docker中运行ASP.NET Core Web API

在docker中运行ASP.NET Core Web API应用程序 本文是一篇指导快速演练的文章,将介绍在docker中运行一个ASP.NET Core Web API应用程序的基本步骤,在介绍的过程中,也会对docker的使用进行一些简单的描述.对于.NET Core以及docker的基本概念,网上已经有很多文章对其进行介绍了,因此本文不会再详细讲解这些内容.对.NET Core和docker不了解的朋友,建议首先查阅与这些技术相关的文档,然后再阅读本文. 先决条件 要完成本文所介绍的演练任

在docker中运行ASP.NET Core Web API应用程序

本文是一篇指导快速演练的文章,将介绍在docker中运行一个ASP.NET Core Web API应用程序的基本步骤,在介绍的过程中,也会对docker的使用进行一些简单的描述.对于.NET Core以及docker的基本概念,网上已经有很多文章对其进行介绍了,因此本文不会再详细讲解这些内容.对.NET Core和docker不了解的朋友,建议首先查阅与这些技术相关的文档,然后再阅读本文. 先决条件 要完成本文所介绍的演练任务,需要准备以下环境: Visual Studio 2015,或者Vi

Docker容器中运行ASP.NET Core

在Linux和Windows的Docker容器中运行ASP.NET Core 译者序:其实过去这周我都在研究这方面的内容,结果周末有事没有来得及总结为文章,Scott Hanselman就捷足先登了.那么我就来翻译一下这篇文章,让更多的中文读者看到.当然Scott遇到的坑我也遇到了. 不过首先,对于不熟悉的朋友我还是来解释一下Linux容器和Windows容器的概念. 由于容器成为虚拟化和应用托管的一种不可避免的选项,Windows也开始为公众提供容器功能(其实微软具备和使用容器技术很久了).这

ASP.NET Core Web API下事件驱动型架构的实现(一):一个简单的实现

很长一段时间以来,我都在思考如何在ASP.NET Core的框架下,实现一套完整的事件驱动型架构.这个问题看上去有点大,其实主要目标是为了实现一个基于ASP.NET Core的微服务,它能够非常简单地订阅来自于某个渠道的事件消息,并对接收到的消息进行处理,于此同时,它还能够向该渠道发送事件消息,以便订阅该事件消息的消费者能够对消息数据做进一步处理.让我们回顾一下微服务之间通信的几种方式,分为同步和异步两种.同步通信最常见的就是RESTful API,而且非常简单轻量,一个Request/Resp

ASP.NET Core Web API下事件驱动型架构的实现(二):事件处理器中对象生命周期的管理

在上文中,我介绍了事件驱动型架构的一种简单的实现,并演示了一个完整的事件派发.订阅和处理的流程.这种实现太简单了,百十行代码就展示了一个基本工作原理.然而,要将这样的解决方案运用到实际生产环境,还有很长的路要走.今天,我们就研究一下在事件处理器中,对象生命周期的管理问题. 事实上,不仅仅是在事件处理器中,我们需要关心对象的生命周期,在整个ASP.NET Core Web API的应用程序里,我们需要理解并仔细推敲被注册到IoC容器中的服务,它们的生命周期应该是个怎样的情形,这也是服务端应用程序设

在Mac下创建ASP.NET Core Web API

在Mac下创建ASP.NET Core Web API 在Mac下创建ASP.NET Core Web API 这系列文章是参考了.NET Core文档和源码,可能有人要问,直接看官方的英文文档不就可以了吗,为什么还要写这些文章呢? 原因如下: 官方文档涉及的内容相当全面,属于那种大而全的知识仓库,不太适合初学者,很容易让人失去重要,让人掉入到具体的细节之中. 对于大多数人来讲开发语言只是工具,程序员都有一个通病,就是死磕工具,把工具学深.我认为在工具上没有必要投入太多时间,以能高效地完成日常的

[转]ASP.NET Core Web API 最佳实践指南

原文地址: ASP.NET-Core-Web-API-Best-Practices-Guide 转自 介绍# 当我们编写一个项目的时候,我们的主要目标是使它能如期运行,并尽可能地满足所有用户需求. 但是,你难道不认为创建一个能正常工作的项目还不够吗?同时这个项目不应该也是可维护和可读的吗? 事实证明,我们需要把更多的关注点放到我们项目的可读性和可维护性上.这背后的主要原因是我们或许不是这个项目的唯一编写者.一旦我们完成后,其他人也极有可能会加入到这里面来. 因此,我们应该把关注点放到哪里呢? 在

在ASP.NET Core Web API中为RESTful服务增加对HAL的支持

HAL(Hypertext Application Language,超文本应用语言)是一种RESTful API的数据格式风格,为RESTful API的设计提供了接口规范,同时也降低了客户端与服务端接口的耦合度.很多当今流行的RESTful API开发框架,包括Spring REST,也都默认支持HAL规范,当RESTful API被调用后,服务端就会返回ContentType为application/hal+json的JSON内容,例如: { "_links": { "