我目前的项目包括一个mongo服务器,一个rabbitmq服务器和一个dotnet核心服务。其结构如下:
.
├── project1.docker-compose.yml #multiple docker-compose files for all projects
├── .dockerignore
├── Util/
| └── some common code across all projects
└── Project1/ #there are multiple projects at the same level with the same structure
├── .docker/
| ├── mongodb
| | └──Dockerfile
| └── rabbitmq
| └──Dockerfile
├── BusinessLogicClasses/
| └── some classes that contain my business logic
└── DotNetCoreService/
├── my service code
└── .docker
└──Dockerfile
现在我可以使用docker-compose命令成功地为mongodb,rabbitmq和dot net核心构建镜像。docker-compose.yml位于主目录级别,因为我的不同项目(在本例中为Project 1)引用了Util目录下的代码。因此,我需要能够提供一个位于两个目录之上的上下文,以便我可以在Dockerfile上使用COPY操作。
我的基本project 1.docker-compose.yml如下(我排除了不重要的部分)
version: '3'
services:
rabbitmq:
build:
context: Project1/.docker/rabbitmq/
mongodb:
build:
context: Project1/.docker/mongodb/
dotnetcoreservice:
build:
context: ./
dockerfile: Project1/DotNetCoreService/.docker/Dockerfile
可以看出,dotnetcoservice的上下文位于主目录级别。因此,我的Dockerfile需要从上下文中获取完整路径,如下所示:
#escape=`
FROM microsoft/dotnet:2.0-sdk AS build
WORKDIR /app
COPY Project1/ ./Project1/
COPY Util/ ./Util/
RUN dotnet build Project1/DotNetCoreService/
当在主目录级别通过docker-compose命令调用时,此dockerfile可以成功工作,但是当通过docker build .\Project1\DotNetCoreService\.docker\
命令调用时,它会失败,并显示以下消息:
复制失败:stat /var/lib/docker/tmp/docker-builder241915396/Project1:没有这样的文件或目录
我认为这是实际上下文的问题,因为docker build
指令会自动将上下文设置为Dockerfile所在的位置。我希望能够使用相同的目录结构来创建docker-compose build
和docker build
指令的映像。
这可能吗?
2条答案
按热度按时间lfapxunr1#
使用标志
-f
设置自定义路径示例:
docker build --rm -t my-app -f path/to/dockerfile .
kzipqqlq2#
2022年5月:新版本的Dockerfile 1.4和Buildx v0.8+具有定义多个构建上下文的能力。
这意味着您可以使用来自不同本地目录的文件作为构建的一部分。
Dockerfiles支持多构建环境
Tõnis Tiigi
多项目
对于命名上下文功能,最常见的用例可能是使用多个本地源目录。
如果您的项目包含需要一起构建的多个组件,那么使用单个构建上下文加载它们有时会很棘手,因为所有内容都需要包含在一个目录中。
有很多问题:
如果您的项目具有以下布局:
使用这个Dockerfile:
...您可以使用
docker buildx build –build-context app1=app1/src –build-context app2=app2/src
调用构建。这两个源目录都单独暴露给Dockerfile,并且可以通过它们各自的名称进行访问使用。这还允许您访问主项目源代码之外的文件。
通常,当您在
Dockerfile
内部时,出于安全原因,不允许您使用../
父选择器访问构建上下文之外的文件。但是由于所有的构建上下文都是直接从客户端传递的,所以现在可以使用
--build-context othersource=../../path/to/other/project
来避免这个限制。2023年5月:问题37129“添加对多个(命名)构建上下文的支持”报告,现在支持:
docker build (23+)
/docker buildx build