Allow specifying a different docker build context

[diasjorge]

Bug

Current Behavior

The Dockerfiles must be at the root of the project

Expected behavior

A user is able to specify a context pointing to another directory like with docker-compose

I can't change our project layout to have different structure like in your examples.

I'd like to be able to specify all garden configuration in a subdirectory like:

garden/garden.yml
garden/module1/garden.yml
garden/module2/garden.yml

And have module1 and module2 build from a parent directory.

Currently with docker-compose we specify the context like: ../../

Your environment

garden version

0.9.12

kubectl version

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-07T09:55:27Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"12+", GitVersion:"v1.12.7-gke.10", GitCommit:"8d9b8641e72cf7c96efa61421e87f96387242ba1", GitTreeState:"clean", BuildDate:"2019-04-12T22:59:24Z", GoVersion:"go1.10.8b4", Compiler:"gc", Platform:"linux/amd64"}

docker version

Client: Docker Engine - Community
Version: 18.09.2
API version: 1.39
Go version: go1.10.8
Git commit: 6247962
Built: Sun Feb 10 04:12:39 2019
OS/Arch: darwin/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.2
API version: 1.39 (minimum version 1.12)
Go version: go1.10.6
Git commit: 6247962
Built: Sun Feb 10 04:13:06 2019
OS/Arch: linux/amd64
Experimental: false

[edvald]

Hey @diasjorge! That's good feedback. We've done some work to make placement of code+configs more flexible, but we do currently assume source files for a module to be within the directory where the config is. The reason we do that is that we "stage" builds by copying source files into a temporary directory, and allowing arbitrary locations makes that quite a bit more complex to do.

We have wanted to add a buildRoot (or similar) field to the container module type, but we'd likely still need it to be within the module path.

That said, there might be a good solution for this already. Only issue would be that you wouldn't structure the configs the same way you had in mind, but rather put multiple configs into a single garden.yml in your top-level directory where the docker build context is and use the include field to pick the appropriate files for each module.

So your combined garden.yml would look something like this (I'm guessing as to how your sources are structured btw):

kind: Project
name: my-project
...
---
kind: Module
type: container
name: module1
...
---
kind: Module
type: container
name: module2
include: ["other-module-sources/**/*"]
dockerfile: other.Dockerfile
...

How exactly is your current code structured? There might be other approaches needed if I'm guessing your structure wrong.

[diasjorge]

hi @edvald thanks for such a quick reply. I'll try your proposal and report back.

[diasjorge]

@edvald I tried your approach and I was able to build the project that way. I see you're working on this issue so looking forward to the upcoming changes to facilitate this :)

[eysi09]

Closing since it's possible to workaround this by "hoisting" the module configuration to a common parent directory and using the inlcude and exclude directives.

[jmaroeder]

I'd love to re-open this issue if possible - I am working on a project whose repo has several Dockerfiles, intended to be built from their own contexts. Each of the Dockerfiles assumes the context is in the directory of the Dockerfile.

I want to use garden to build and deploy these, but I can't seem to find a good way to do that with the current expectations.

Example structure:

.
├── api
│   └── Dockerfile
├── frontend
│   └── Dockerfile
└── garden.yml

[edvald]

For this case, the advised approach is to place the garden.yml file for each Dockerfile next to the Dockerfile. So it'd be:

.
├── api
│   └── Dockerfile
│   └── garden.yml
├── frontend
│   └── Dockerfile
│   └── garden.yml
└── garden.yml

Would that cover your case?

[jmaroeder]

Sorry, I skipped a layer. The api and frontend directories are inside another repository, which I don't have direct control over.

.
├── garden.yml
└── project-repo
    ├── .git
    ├── api
    │   └── Dockerfile
    └── frontend
        └── Dockerfile

I understand that this is probably pushing the bounds of the scenario garden is intended for, but it would go a long way toward flexibility.

[edvald]

Aaah I see. That makes sense then. Sure, we can reopen.

Meanwhile, you might be able to use remote module sources for this scenario, which may be a good approach if the external code is not something you're editing much: https://docs.garden.io/guides/using-remote-sources#remote-modules

[atcastel]

I run into this same issue. Specifically, the "correct" way of building dotnetcore projects in containers must have the context of the whole repo to deal with project dependencies. Defining all of the modules in the garden project file seems very messy

[atcastel]

Here is an example dockerfile, scrubbed of personal information, that is the standard template for dotnetcore projects in a visual studio solution:

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /src
COPY ["<ProjectFolder>/<MyProject>.csproj", "<ProjectFolder>/"]
RUN dotnet restore "<ProjectFolder>/<MyProject>.csproj"
COPY . .
WORKDIR "<ProjectFolder>"
RUN dotnet build "<MyProject>.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "<MyProject>.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "<MyProject>.csproj.dll"]

[stale]

This issue has been automatically marked as stale because it hasn't had any activity in 60 days. It will be closed in 14 days if no further activity occurs (e.g. changing labels, comments, commits, etc.). Please feel free to tag a maintainer and ask them to remove the label if you think it doesn't apply. Thank you for submitting this issue and helping make Garden a better product!

[stale]

This issue has been automatically marked as stale because it hasn't had any activity in 60 days. It will be closed in 14 days if no further activity occurs (e.g. changing labels, comments, commits, etc.). Please feel free to tag a maintainer and ask them to remove the label if you think it doesn't apply. Thank you for submitting this issue and helping make Garden a better product!

[ShavaShav]

I also would like the ability to specify the build context. I have a project that looks like this:

- .project.garden.yaml
- .modules.garden.yaml
- services
  - myservice
    - src
    - Dockerfile

Where .modules.garden.yaml contains:

kind: Module
type: container
name: service-image
include: [services/myservice/**/*]
dockerfile: services/myservice/Dockerfile

But the resulting build context is not at .garden/build/myservice-image/services/myservice, its at the root (.garden/build/myservice-image), so garden fails to build the image.

I.e. garden is building the image like this:
docker build -t myservice --file project/.garden/build/myservice-image/services/myservice/Dockerfile project/.garden/build/myservice-image

But I want it to build like this:
docker build -t myservice --file project/.garden/build/myservice-image/services/myservice/Dockerfile project/.garden/build/myservice-image/services/myservice

I don't want to put a garden.yaml next to the Dockerfile in /myservice for various reasons; one being that myservice might be a git submodule that I want to build from the Dockerfile, without committing a garden.yaml in it's repo (which is specific to my project and not the myservice repo). I can't use remote module sources because I want to use dev mode (syncing changes from the submodule code to the deployment). I would also like to define all my garden configurations in one place for organization.

Is there a workaround for this?

[vvagaytsev]

The original issue has already been resolved in Bonsai (garden 0.13). Feel free to reopen if it's still an issue in Bonsai.