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 support should work using non-FP-generated images (not require entrypoint.sh) #531

Closed
gregwebs opened this Issue Jul 6, 2015 · 24 comments

Comments

Projects
None yet
4 participants
@gregwebs
Contributor

gregwebs commented Jul 6, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 6, 2015

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

This comment has been minimized.

Contributor

gregwebs commented Jul 6, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 6, 2015

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

This comment has been minimized.

Contributor

gregwebs commented Jul 7, 2015

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 borsboom self-assigned this Jul 11, 2015

@borsboom borsboom added this to the Later improvements milestone Jul 11, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Jul 11, 2015

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

This comment has been minimized.

Contributor

gregwebs commented Jul 11, 2015

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

This comment has been minimized.

Contributor

gregwebs commented Jul 13, 2015

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 borsboom changed the title from custom docker image has an entrypoint failure to Docker support should work using non-FP-generated images (not require entrypoint.sh) Jul 21, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Aug 7, 2015

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

This comment has been minimized.

Contributor

borsboom commented Sep 7, 2015

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

This comment has been minimized.

PierreR commented Sep 9, 2015

@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

This comment has been minimized.

Contributor

borsboom commented Sep 9, 2015

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 referenced this issue in archhaskell/habs Sep 9, 2015

Upgrades 2015-09-06
    cassava
    contravariant
    fclabels
    iproute
    stack
    test-framework-hunit
    yaml

Added dependencies

    ignore
    pcre-heavy
    base-compat
    pcre-light
    string-conversions

Signed-off-by: Magnus Therning <magnus@therning.org>
@PierreR

This comment has been minimized.

PierreR commented Sep 9, 2015

@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

This comment has been minimized.

Contributor

gregwebs commented Sep 9, 2015

@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

This comment has been minimized.

Contributor

borsboom commented Sep 9, 2015

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

This comment has been minimized.

PierreR commented Sep 9, 2015

@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

This comment has been minimized.

Contributor

gregwebs commented Sep 9, 2015

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

This comment has been minimized.

Contributor

borsboom commented Sep 9, 2015

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

@gregwebs

This comment has been minimized.

Contributor

gregwebs commented Sep 9, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Sep 10, 2015

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 borsboom modified the milestones: Docker, P2 Sep 12, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Oct 15, 2015

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

This comment has been minimized.

Contributor

mboes commented Nov 3, 2015

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 added a commit that referenced this issue Nov 15, 2015

borsboom added a commit that referenced this issue Nov 15, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Nov 15, 2015

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.

@borsboom borsboom closed this Nov 15, 2015

@gregwebs

This comment has been minimized.

Contributor

gregwebs commented Nov 15, 2015

Fantastic! I will try this out soon.

@gregwebs

This comment has been minimized.

Contributor

gregwebs commented Nov 16, 2015

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

borsboom added a commit that referenced this issue Nov 19, 2015

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