。

搜到了一篇非常适合初学者#xff0c;从dockerfile命令讲解#xff0c;到解决引用其他项目时如何docker部署的文章。

…

解决方案内部项目之间引用很正常但我docker不是很熟对一些基础命令含义还理解不深入部署引用其他项目的项目总不成功。

搜到了一篇非常适合初学者从dockerfile命令讲解到解决引用其他项目时如何docker部署的文章。

原论文链接以下为翻译。

当你了解Docker命令的基础知识时从有项目引用的dotnet解决方案创建Docker镜像很容易但是对于初学者来说编写适当的Dockerfile可能会很棘手。

大多数示例展示了如何容器化.net项目假设它没有本地依赖项。

那么让我们分析一下当我们的项目引用了解决方案中的其他项目时我们能做些什么。

我们将首先深入研究一个没有依赖项的简单示例以了解我们引入了哪些更改以及为什么要进行更改。

如果你只是想跳到解决方案并复制粘贴它当然你可以这样做但不建议这样做因为迟早你会因为不理解发生了什么而被另一个障碍所阻碍结果你会浪费更多的时间。

本文非常适合开始学习Docker指令和命令因为所有内容都用简明易懂的语言进行了解释。

我们将使用.net

core

core应用程序是可用的在GitHub上请随意使用它来满足您的需求。

官方Docker示例分析

Core应用容器化的文章向我们展示了Dockerfile位于project文件夹(.csproj文件存储的地方):

FROM

mcr.microsoft.com/dotnet/core/sdk:2.2

build-env

mcr.microsoft.com/dotnet/core/aspnet:2.2

WORKDIR

这两个命令要从Dockerfile所在的项目文件夹中运行:(编者注,docker

Dockerfile

mcr.microsoft.com/dotnet/core/sdk:2.2

build-env

runtime因为我们将在构建镜像期间在Docker中编译我们的应用程序。

所以你甚至不需要在你的主机上安装.net

core

SDK这个Dockerfile是用一种你无需自己为Docker镜像编译应用程序的方式准备的——Docker会编译它。

您可以使用在您的主机上构建的二进制文件但这并不安全——由于兼容性问题它可能无法工作。

为什么有AS

build-env

/app指令这意味着在我们的Dockerfile下面的RUN,

CMD,

COPY和ADD指令将在/app目录执行。

如果它不存在它将被创建(即使它不会被使用)。

Dockerfile

./指令这意味着Docker构建上下文中的所有csproj文件将被复制到Docker镜像中的workdir

(/app)指向Docker构建命令。

.路径指向执行命令的设置为构建上下文。

Dockerfile

restore指令它只是在我们的工作中除了我们项目的.csproj之外什么都没有因为我们在前面的步骤中只复制了它但它足以还原nuget依赖。

Copy和compile应用程序源代码

./从我们的构建上下文复制所有内容——在我们的例子中它指的是项目文件(.cs文件等)因为我们运行docker

build命令时将项目中运行dotnet

out参数。

这个dotnet命令用发布配置编译我们的应用并在out目录下发布结果(在我们的例子中是/app/out)。

我们可以编译源代码因为我们将镜像像基于开发人员的sdk。

Docker多阶段构建

我们再一次看到FROM指令它设置了我们的镜像基于哪个镜像…怎么可能再次指定它使用不同的基?这是一个非常新的Docker特性(从Docker

17.05版本开始)称为多阶段构建。

当我们再次使用FROM关键字时我们的意思是上面指定的先前镜像是临时的并且仅用于某些目的。

在我们的示例中它仅用于编译我们的应用程序—这就是为什么我们使用SDK作为基础映像。

现在我们再次指定基本镜像这次我们准备的是实际镜像——即将部署到生产环境中的镜像这个镜像不基于SDK只基于生产运行时因此会产生较小的大小。

我们将从临时镜像复制我们编译的应用程序。

所以我们再次指定工作然后复制我们的二进制文件——copy

--frombuild-env

/app/out。

这意味着从build-env镜像(这就是为什么我们在第一行给它一个名字)的/app/out/(/app)。

Dockerfile

这个Dockerfile中的最后一个指令是ENTRYPOINT它(简单地说)指定了一个在容器启动时将执行的命令。

所以在我们的例子中-

ENTRYPOINT

Docker将运行带有PROJECT_NAME.dll参数(当然应该替换为我们的项目名)的dotnet以启动我们的应用程序。

Docker

有了这样的Dockerfile我们被告知在项目将作为构建上下文传递。

因为我们被告知要在项目目录(.csproj文件存储的地方)中运行这个命令所以我们的项目文件被作为构建上下文传递。

Docker

run命令从镜像创建容器。

镜像是Docker的只读手册用于创建容器容器是我们应用程序所在的虚拟机。

我们可以这样想:镜像就像面向对象编程中的一个类容器就像从这个类创建的实例。

因此我们可以创建任意数量的容器(实例)而不会影响镜像(类)——镜像只是让Docker知道如何创建容器。

我们被告知这样运行:

docker

如果没有——detach选项(-d)我们将开始看到来自容器的应用控制台输出。

使用——publish

(-p)选项我们将容器的端口绑定到主机(默认使用TCP但您也可以指定UDP和SCTP)。

使用——name选项我们为容器指定一个名字(没有这个选项Docker会为我们选择一些有趣的名字)。

最后我们传递镜像名称Docker将读取它来创建容器。

因为我们将图像命名为aspnetapp所以这里使用这个名称。

解决方案

问题当然是我们运行Docker构建命令从项目中的文件而依赖于项目的文件当然在其他)并从那里运行docker

build。

但建议在项目)但将构建上下文路径更改为上一级(..)。

在我看来更优雅的是第三种解决方案-从解决方案目录运行docker构建通过.作为构建上下文并使用——file

docker

接下来我们需要调整Dockerfile因为官方示例假设我们用项目目录作为构建上下文。

我的版本是这样的:

FROM

mcr.microsoft.com/dotnet/core/sdk:2.2

build-env

mcr.microsoft.com/dotnet/core/aspnet:2.2

WORKDIR

我跳过了恢复nuget包作为单一步骤来简化恢复包含在dotnet发布中如果由于nuget失败而失败错误信息是清晰的。

但是如果你有很多nuget依赖你可能想要有单独的步骤因为这样Docker将其视为不同的层并在没有任何csproj文件更改的情况下重用它这样可以缩短构建时间(我在另一篇文章中描述过)。

在这个演示中恢复nugets的速度足够快可以跳过它但如果您有很长的构建时间(特别是-在…时间内完成恢复)请记住这一点。

所以我们将所有项目(因为构建上下文现在是解决方案。

接下来我们在/app

workdir中运行dotnet

-这里的PROJECT_NAME是以使构建上下文尽可能小降低缓存无效的风险这当然是合理的。

但是Docker

CLI在构建上下文的根。

但在我看来这样更好因为我们不需要为许多项目创建和维护许多.dockerignore文件我们为所有项目保留一个。

示例规则:

*/bin

core应用程序时我只是从上述文章中获取Dockerfile复制粘贴Docker命令当我遇到障碍时我试图在不分析Docker如何工作的情况下解决它。

在以这种方式浪费了一些时间之后我又浪费了时间——试图从网上复制粘贴解决方案——同样没有分析我做了什么也没有成功。

然后我又一次明白了(在我的生命中……)匆匆忙忙并不会节省时间反而会适得其反——浪费时间。

因为我没有找到合适的文章或教程所以我从官方文档和手册开始这些文档和手册写得很好但对于初学者来说有太多的细节。

本文展示了分析的要点并用通俗易懂的语言解释了基础知识。

我希望这样可以很好地开始编写适当的Dockerfile而不会遇到像这里所呈现的情况那样的麻烦-

dotnet项目从解决方案中引用其他项目也不会遇到任何其他障碍。