Docker support should work using non-FP-generated images (not require entrypoint.sh)

[gregwebs]

It looks like it is impossible to use a custom docker image right now.

➜  backend git:(master) ✗ stack build
exec: "/root/entrypoint.sh": stat /root/entrypoint.sh: no such file or directory
FATA[0000] Error response from daemon: Cannot start container 1b60244790aceffc03b3c0ab59156099e0f55b0730b085273f139a1e3a8a8655: [8] System error: exec: "/root/entrypoint.sh": stat /root/entrypoint.sh: no such file or directory 
➜  backend git:(master) ✗ stack --version
Version 0.1.2.0, Git revision 65246552936b7da4b64b38372feac903d96a8911 (dirty)

From looking at the source code, using my own image must be getting identified as an oldImage, so it then gets a --entrypoint argument.

[borsboom]

I think at this point the oldImage logic can be removed. That said, stack's docker integration isn't going to work well with an image that doesn't have a correct entrypoint that handles the user and directory mapping. If you need a custom image, I recommend deriving it from the fpco/stack-run docker image repository.

[gregwebs]

Where are the Dockerfile's for the fpco images? I cannot find any of them.
Where is the entrypoint script? I would imagine it should be easy to drop that into my images.

[borsboom]

The fpco images aren't built using Dockerfiles, and the current build tool contains some proprietary information and so we can't open source it yet.

In the images, the entrypoint is at /usr/local/sbin/docker-entrypoint, so you can get it using:

docker run -d --name=get-entrypoint fpco/stack-run && \
docker cp get-entrypoint:/usr/local/sbin/docker-entrypoint . && \
docker rm -f get-entrypoint

[gregwebs]

The fpco images aren't built using Dockerfiles, and the current build tool contains some proprietary information and so we can't open source it yet.

Unfortunately I cannot use the fpco images then. Perhaps your can make your build tool capable of generating a Dockerfile

A better way to get the file out (from my point of view at least) is

docker run --entrypoint="/bin/bash" fpco/stack-run -c 'cat /usr/local/sbin/docker-entrypoint' > entrypoint.sh

Thanks for that, I will give it a shot

[borsboom]

I've been looking at this a bit more, and I think it is likely possible to make stack work without the special entrypoint in a slightly degraded form. It would lose the user ID mapping (meaning files it writes would be owned by root) and using the package index and build plan from the image (meaning stack would have to download those).

[gregwebs]

My general workflow is to create a single user for the container and mount things into their home directory. Since I am the first user on my own computer, the uids match up (I know it is hacky, but it always works for my development flow).

For stack, I just need to mount ~/.stack and the project directory.

I think the entrypoint script could be broken up into 2 separate things:

1. a generic entrypoint script that does things such as user id mapping
2. a stack-specific entrypoint that calls the generic entrypoint

I am definitely willing to help make this happen. Let me know.

[gregwebs]

I was able to get things working with my own image by taking the output of stack -v build and modifying it and turning it into a script with "$@" at the end.

I think there is really no reason why stack should not be able to work with the official haskell image.

[borsboom]

I have an approach in mind that will also fully solve #547 (and help #260), where stack will act as its own entrypoint rather than relying on a special entrypoint in the image (which is a historical accident from the bash script we used when we first started using Docker).

[borsboom]

Copied from my own duplicate issue (#936):

Since Docker support was originally implemented in an internal build tool, much has changed in stack. Those changes mean the structure of the Docker image is much less important than it used to be, and there's no deep reason for the Docker image to need a special structure anymore. Changes required, as far as I know:

• Move the /usr/local/sbin/docker-entrypoint logic into Stack itself (and remove the entrypoint from future images, after a transition period).
• Make stack itself behave as a proper PID 1 init daemon (reap processes, etc.). That means no more need to use phusion/baseimage's my_init.

We will continue to distribute images, but just about any image should work, including the Official Haskell images. Even images that don't contain GHC should work (stack will just fall back on its usual non-Docker behaviour of installing its own GHC in ~/.stack).

[PierreR]

@borsboom I have been trying using stack-0.1.4.1 but it fails with:

stack --docker build     
/opt/host/bin/stack: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory

I am basically trying to use an image alike from haskell-stack.

[borsboom]

Images built by that haskell-stack Dockerfile are not currently supported by stack --docker, as they don't contain the correct entrypoint. Use images like https://hub.docker.com/r/fpco/stack-build/ instead.

But aside from that, stack shouldn't need libpcre. Did you build your stack binary yourself? And, if so, how? There was a brief period when the master version of stack did require it due to the ignore library using it, but now we use a newer version of ignore and set the without-pcre: true for it.

[PierreR]

@borsboom Thanks for your comment. My bad, I thought this issue was closed ... Is there a fpco image based on debian jessie ? I cannot use an image based on ubuntu:14:04 (I am trying to build language-puppet and it won't work with ruby-1.9 because of a ruby related bug on that version).

[gregwebs]

@PierreR that image is designed to be run with /bin/bash and a directory mounted to run stack.
I am transitioning to running stack this way now:

#!/bin/bash -e
INSIDE_PWD=$(echo $PWD | sed 's/\/home\/greg/\/home\/haskell/')
exec ~/bin/override/docker run --rm -i -t -v "$PWD:$INSIDE_PWD" -v /home/greg/.stack:/home/haskell/.stack -v /home/greg/.local:/home/haskell/.local -w "$INSIDE_PWD" gregweber/haskell-user /home/haskell/.local/bin/stack "$@"

where haskell-user is from here

[borsboom]

Is there a fpco image based on debian jessie ? I cannot use an image based on ubuntu:14:04 (I am trying to build language-puppet and it won't work with ruby-1.9 because of a ruby related bug on that version).

@PierreR There is not, since our images are based on phusion/baseimage which is based on ubuntu:14.04. We currently use phusion's init daemon. Resolving this issue will remove the dependency. In the meantime, you might be able to add a layer to our images that installs a different Ruby version.

[PierreR]

@borsboom I will probably wait for this issue to be solved then (there is no urgency on my side, right now I am just building everything on the host and use a docker image that uses the same distro for publishing the exec). I guess supporting the official haskell docker image makes perfect sense and it will come in time; I just need to be a bit patient. Thanks for your support. It is really appreciated.

@gregwebs Thanks for the suggestion. I might go this route if I really need to but I will probably just wait for the resolution of this issue ;-)

[gregwebs]

I would like to remove the haskell-stack Dockerfile from the repo. Any objections?
I think I would just need to update some documentation somewhere

[borsboom]

No objections, it's been a source of confusion.

[gregwebs]

#966

[borsboom]

Note: any change we make to resolve this issue needs be compatible with resolving #194. That's a bit tricky, because it means we can't count stack itself containing all the startup logic. But we could embed some shell script in stack that performs any required bootstrapping, which it would ship into the container and run, before passing control to the in-container stack executable.

[borsboom]

Note: any change we make to resolve this issue needs be compatible with resolving #194.

#194 no longer requires anything special in the entrypoint; getting the correct stack binary is handled on the host.

[mboes]

What's the status on this issue? I noticed in #531 (comment) that you mention stack requiring two things: internalizing the entrypoint logic, and acting as a proper init daemon. Any estimate on how difficult / how long it would take to add either of those?

As things stand, since the Dockerfile for the stack-build image isn't available, stack's docker support is useful, but only for people targeting the exact same base distro as the one used by the stack-build image (no CentOS / arch / different ubuntu version etc).

[borsboom]

This is now implemented in master, and Stack's Docker integration should work with any image that includes the basics for running GHC. For example, I've tested with the official Haskell image and things seem to work fine.

[gregwebs]

Fantastic! I will try this out soon.

[gregwebs]

Tried it out. Seems to be working remarkably well now :)