New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker build contexts #33

Closed
tristanpemble opened this Issue Aug 28, 2017 · 10 comments

Comments

Projects
None yet
3 participants
@tristanpemble
Contributor

tristanpemble commented Aug 28, 2017

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

This comment has been minimized.

Contributor

tristanpemble commented Aug 28, 2017

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

This comment has been minimized.

Contributor

plombardi89 commented Aug 28, 2017

@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?

@plombardi89 plombardi89 added the Feature label Aug 28, 2017

@rhs

This comment has been minimized.

Contributor

rhs commented Aug 28, 2017

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

This comment has been minimized.

Contributor

tristanpemble commented Aug 28, 2017

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

This comment has been minimized.

Contributor

tristanpemble commented Aug 28, 2017

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

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

This comment has been minimized.

Contributor

rhs commented Aug 28, 2017

Works for me.

@tristanpemble

This comment has been minimized.

Contributor

tristanpemble commented Aug 28, 2017

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

@rhs

This comment has been minimized.

Contributor

rhs commented Aug 28, 2017

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

This comment has been minimized.

Contributor

tristanpemble commented Aug 28, 2017

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

This comment has been minimized.

Contributor

rhs commented Aug 31, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment