Need Advice to Docker Containerize .NET Projects that exist in various subfolders
We are just starting out using Docker.
We have many .NET Projects in a folder structure that is multiple layers deep, sort of like this:
--Dev --Api --Mobile.Api.Auth --Auth --AuthBO --More folders... --Data --ClientAccess --MasterAccess --More folders... --More folders...
I want to Containerize Mobile.Api.Auth. It has a project dependency to Auth\AuthBO, which has project dependencies to Data\ClientAccess and MasterAccess.
My confusion centers around the docker build context and where to put the dockerfile.
So far, I have created another subfolder structure under Dev, like Dev\Sandbox\Auth. I then physically copied all four projects that I need, to be under that folder. I then put my Dockerfile in Dev\Sandbox\Auth and execute the docker build from there.
The reason why I do this is because from what I have read, I wouldn't want my build context to be \Dev, which from what I understand, is what it would need to be in order to access the four projects I need (since I can't do a COPY ....\Auth\AuthBO for instance).
Q. Am I correct in that? Also I've read "Do not use your root directory, /, as the PATH for your build context, as it causes the build to transfer the entire contents of your hard drive to the Docker daemon." In my case if I used \Dev, I'd be sending hundreds of projects / folders that I don't need to the Docker daemon, if I'm understanding correctly.
Q. How should I approach this? As mentioned, just for doing a proof of concept to run those 4 projects in a container on a server, I physically copied them to another folder where I could put them all at the same subfolder level. But I don't want to have to copy them every time I need to build a new image (as our code changes). I also then had to adjust the project references in each project, which I don't want to do.
Obviously our folder structure would be different if we had taken Docker into account, but the folder structure was set up years ago and we can't really change it now.
Thanks in advance.
You would typically want to place your Dockerfile at the deepest common directory shared by the content that is needed during the Docker build. In many cases, it's where your .sln file would be located. But the location of the Dockerfile is independent of the build context location. You could have your Dockerfile stored in some other far away folder and reference it using the
-fflag in your
docker buildcommand. So really what's important is what location you are specifying for your build context. In your case, it looks like it would be the
You can get around the issue of including too much other unneeded stuff by using a
.dockerignorefile. See https://docs.docker.com/engine/reference/builder/#dockerignore-file. This file would be placed next to your Dockerfile and defines file/directory names and naming patterns that are to be excluded from the build context. That way you can avoid having all those extra folders copied into your build context and hurting your overall build time. Docker provides this
.dockerignorefile example in the documentation:
# comment */temp* */*/temp* temp?