Docker build contexts

[tristanpemble]

I'm not sure what the right answer to this problem is, but here's the situation I am in. We have a Dockerized PHP application. We deploy it as pods with two containers: one running php-fpm, the other running nginx with a fastcgi_proxy. As far as I know, this is the best way to put a PHP application into Kubernetes.

An example directory structure:

myrepo.git
├── containers
│   └── proxy
│       ├── Dockerfile
│       └── nginx.conf
├── public
├── src
│       └── ...
└── Dockerfile

And the nginx proxy's Dockerfile:

# ./containers/proxy/Dockerfile
FROM nginx:1.13-alpine

COPY ./nginx.conf /etc/nginx/nginx.conf

RUN mkdir -p /srv/public
COPY ../../public /srv/public

WORKDIR /srv

The problem is that, currently, I have to build that Dockerfile with its context as the repository root (in order to copy in the ./public folder). Forge defaults the build context as ./containers/proxy, where I need it to be ./

[tristanpemble]

One simple fix for this is to search for Dockerfile.* so we could just put Dockerfile.proxy in the project root.

Otherwise, I can't think of a good way to specify the build context to Forge for a certain Dockerfile

[plombardi89]

@tristanpemble I ran into a similar issue last week while working on the backend for Kubernaut. My solution for the time being has been to produce an "uber" Docker image that wraps up all the services composing the Kubernaut backend into a single image and then use an environment variable to selectively start the right thing... this is not ideal. You might be able to get away with a similar approach temporarily.

@rhs Perhaps we need a --docker-args= meta argument that would then pass any provided args back to the Docker daemon?

[rhs]

I'm just thinking out loud here, but what about adding something like this to service.yaml that would allow both an explicit list of containers as well as customization of how they are built. All paths would be relative to the service.yaml containing the snippet below:

containers:
 - file: php/Dockerfile
   root: .
   args:                  # can pass in custom build args this way
    - blah
 - file: nginx/Dockerfile
   root: .

containers:
 - file: Dockerfile.php   # root defaults to directory containing file
 - file: Dockerfile.nginx # root defaults to directory containing file

What do you guys think? It would be pretty easy for me to add this if it seems like it would work.

[tristanpemble]

I think this is a good direction, but it'd be nice if the key naming more closely matched Docker arguments (think the docker-compose build section)

[tristanpemble]

looking at that, I think it fits naturally with what we need here:

containers:
  - ./php
  - dockerfile: ./nginx/Dockerfile
    context: ./
    args:
      foo: bar

[rhs]

Works for me.

[tristanpemble]

I'm assuming forge would continue to auto-build any Dockerfiles it runs into, and this would be sort of "progressive enhancement"?

[rhs]

Yeah, I was imagining keeping exactly the current auto-build behavior if no "containers:" is specified.

There is a choice to make if there are Dockerfiles present in the tree and "containers:" is also present and does not reference them. I could ignore those files and just do exactly what "containers:" specifies and no more, or I could build everything. Any preference? (I'm leaning towards ignoring as it is slightly simpler to explain, i.e. you get exactly what you ask for rather than having to explain how the two behaviors merge.)

[tristanpemble]

I think ignoring makes sense, just needs to be documented. Gives new users the magic experience but lets you override it if/when necessary

[rhs]

Ok, this feature should be available now as of 0.2.16. You can check out the docs here: https://forge.sh/reference/service-descriptor