Docker support could allow building Dockerfiles or otherwise run extra commands to initialize a container

[radix]

As I just briefly discussed with @chreekat and @mgsloan on IRC, I have a situation where I need a derived Docker image for my project since I need some extra system dependencies installed for both building and running tests.

It seems the main benefit of using stack's docker support (instead of just rolling my own docker image and running stack inside of it) is that it Just Works without any developer setup. But as soon as I need a custom image like this, that benefit goes away, since my developers need to explicitly build the image now.

So it would be nice if I could specify a Dockerfile in the docker section of my stack.yaml, or perhaps just a small script of commands to run inside the docker environment before building (assuming the result of that script would then be cached in the docker image so it wouldn't need rerun every time I call stack build).

This is a pretty minor issue in the grand scheme of things, but it seems something that fits in with the intent of stack's docker support.

[mgsloan]

How about hosting the container for download by devs?

I can certainly see the utility of something like this, though. Thoughts, @borsboom or @dysinger ?

[radix]

Hosting would alleviate this, but it means a lot more infra work for me ;-)

[colonelpanic8]

@radix @mgsloan @chreekat @borsboom @dysinger I need something like this for taffybar, because it has several non-haskell depdencies (mostly the things that are needed to get haskell-gi working properly). I'd like to be able to take advantage of stacks integration with docker, but I have to handle everything manually in a Dockerfile right now.

I take it that no progress has been made on this, but I'm wondering if anyone has any thoughts about how this should be done. I'd be happy to do the work of adding the support myself, but I'd like some guidance on what the approach should be.

[mgsloan]

@IvanMalison Cool, sounds good! The docker support side of things is not the bits of stack I'm most familiar with. However, it seems to me like this might look like adding a dockerfile field to the docker section. This would specify a dockerfile to build.

I'm thinking that it would store in .stack-work a file that specifies the resulting image, and perhaps the modtime + hash of the dockerfile, or something like that. I'm not sure if modtime + hash is a reliable way to figure out when to rebuild the image, but seems like a good approximation.

[falsandtru]

Since we can't set EXPOSE parameter of Dockerfile, we can't make a server image from stack.yaml. Strangely, I've succeeded to access a server container built by stack without specifying EXPOSE parameter. Thanks stack.

[vilunov]

@IvanMalison Hi! I'm not sure whether you actually started implementing the feature, but if you're looking for inspiration, I suggest you to look into how docker-compose achieves this:

service:
  image: my/image:latest
  build: .

This is a service definition, and just like stack.yaml it contains the image name, but it also includes the build parameter with the path to the build context (containing the Dockerfile). If you want to specify different paths to the context and to the Dockerfile, you do this:

service:
  image: my/image:latest
  build:
    context: .
    dockerfile: alternate.Dockerfile

The resulting image's tag is my/image:latest or whatever is in image parameter. If the image parameter is not specified, the name is derived from the service's name, in stack's case we could derive it from the package's name.

There are also additional parameters, more info could be found here: https://docs.docker.com/compose/compose-file/#build