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

Does mybinder.org respect the custom CMD in my Dockerfile? #87

Open
vaibhavsagar opened this Issue Mar 30, 2018 · 24 comments

Comments

Projects
None yet
6 participants
@vaibhavsagar
Contributor

vaibhavsagar commented Mar 30, 2018

Tangentially related to #85, I tried to accomplish the same goal with a different packaging ecosystem here which requires a custom CMD.

The command from my previous attempt was just jupyter notebook --ip 0.0.0.0 which matches the default command in repo2docker and that Dockerfile works, but my new one with a custom command result/bin/ihaskell-notebook --ip 0.0.0.0 does not.

I see that dockerspawner has logic to handle this but I'm wondering if that's being overridden somewhere else?

It would also be really useful to see the console output of the Launching server... stage so I can troubleshoot without opening issues each time a Dockerfile builds but does not launch 😄.

@vaibhavsagar

This comment has been minimized.

Contributor

vaibhavsagar commented Apr 2, 2018

I thought I'd test this by making a small shim that passes any arguments to my custom entrypoint, but that didn't seem to work either: https://mybinder.org/v2/gh/vaibhavsagar/ihaskell-mybinder-nix/jupyter-shim. The branch is at https://github.com/vaibhavsagar/ihaskell-mybinder-nix/tree/jupyter-shim.

@betatim

This comment has been minimized.

Member

betatim commented Apr 2, 2018

Trying to track this down as I don't know the answer.

The spawner used by binderhub is configured here:
https://github.com/jupyterhub/binderhub/blob/4a7c7ea9033a5c1c700f7cdb00392ffaacfccc25/helm-chart/binderhub/values.yaml#L106-L128

No command is set in that config and the default command is None which means CMD should be used (see here). Using CMD would mean that any arguments set by the spawner are also ignored. This is at odds with explicitly setting the arguments.

So far from reading the code I'd conclude that setting CMD in your Dockerfile should work, but you said it doesn't. More code reading will be needed :-/

@yuvipanda

This comment has been minimized.

Member

yuvipanda commented Apr 2, 2018

@vaibhavsagar

This comment has been minimized.

Contributor

vaibhavsagar commented Apr 2, 2018

I think the CMD might be a red herring because my attempt with the shim doesn't work either. Do you have access to the logs when launching a built image?

@vaibhavsagar

This comment has been minimized.

Contributor

vaibhavsagar commented Apr 21, 2018

I was advised to try reproducing this locally with repo2docker, and the following command works and gives me a usable Jupyter notebook setup:

$ repo2docker --ref 5f43ae2a094edce19a6eceef8868976dac64295a https://github.com/vaibhavsagar/ihaskell-mybinder-nix
@vaibhavsagar

This comment has been minimized.

Contributor

vaibhavsagar commented Apr 21, 2018

The exact same ref doesn't seem to work with mybinder.org though.

@choldgraf

This comment has been minimized.

Member

choldgraf commented Apr 23, 2018

Hmmm, so I just tried launching this on binder and ran into the same problem you describe.

@minrk what is the best way to grab the logs for a hanging launch like this? I tried looking at the hub logs, but they're a bit difficult to sift through in a productive fashion.

@vaibhavsagar , one thing I noticed is that there's another IHaskell repo floating around out there that already seems to work with Binder (https://github.com/gibiansky/IHaskell). Have you looked into this as well? Not sure if what you're trying to do is substantively different from that one, but wanted to call your attention to it.

@yuvipanda

This comment has been minimized.

Member

yuvipanda commented Apr 23, 2018

@choldgraf

This comment has been minimized.

Member

choldgraf commented Apr 23, 2018

so it sounds like the path forward for @vaibhavsagar is to try achieving the same result without needing to override CMD yeah?

@choldgraf

This comment has been minimized.

Member

choldgraf commented Apr 23, 2018

@yuvipanda in point 5 of this section we tell people the following re: putting CMD in your Dockerfile

It must specify a default command.
This is the command that is executed on startup.

# Specify the default command to run
CMD ["jupyter", "notebook", "--ip", "0.0.0.0"]

should we modify this to remove any reference to adding your own CMD line, and then specifically say "this is the CMD that will be run by BinderHub, so make sure your Dockerfile works with this."

WDYT?

@vaibhavsagar

This comment has been minimized.

Contributor

vaibhavsagar commented Apr 24, 2018

@choldgraf the interesting thing about the commit I'm using is that it uses the default CMD so any overriding should be irrelevant. I'm also the author of the IHaskell mybinder integration and the reason I want to get this alternative method working is that it is easier to configure, quicker to build, and leads to smaller Docker images which I think would be better for everyone.

@choldgraf

This comment has been minimized.

Member

choldgraf commented Apr 25, 2018

huh, that is interesting...I agree that's a different problem than the one we thought we had :-)

So to be clear, you're using the same CMD that's recommended in the docs, and it still isn't working. The only other difference I see is that you don't have a RUN pip install notebook line in there. Have you tried adding this?

@vaibhavsagar

This comment has been minimized.

Contributor

vaibhavsagar commented Apr 26, 2018

Why would that make any difference? Are you specifically scanning for that line in the Dockerfile?

@choldgraf

This comment has been minimized.

Member

choldgraf commented Apr 26, 2018

I'm pretty sure that the docker image has to be running the same version of the notebook that is installed in the jupyterhub docker image on Binder. That's why the first section of the Dockerfile instructions say to install the notebook.

@vaibhavsagar

This comment has been minimized.

Contributor

vaibhavsagar commented Apr 26, 2018

That makes sense, but it's not what this implies:

It must install a recent version of Jupyter Notebook.

If it has to be exactly the same, can that be documented somewhere?

I will update my repo to use a more recent version of Jupyter and see if that makes a difference.

@choldgraf

This comment has been minimized.

Member

choldgraf commented Apr 26, 2018

well it doesn't quite have to be the exact same, just the same major version (5.*) That said, I agree with you that our language should be more precise! Lemme know if this fixes the problem

@vaibhavsagar

This comment has been minimized.

Contributor

vaibhavsagar commented Apr 26, 2018

@choldgraf

This comment has been minimized.

Member

choldgraf commented Apr 27, 2018

are you sure? I just forked your repo and added RUN jupyter notebook --version and it said it wasn't found:

https://github.com/choldgraf/ihaskell-mybinder-nix/blob/jupyter-shim/Dockerfile

https://mybinder.org/v2/gh/choldgraf/ihaskell-mybinder-nix/jupyter-shim

@vaibhavsagar

This comment has been minimized.

Contributor

vaibhavsagar commented Apr 27, 2018

You need to put that line at the bottom after nix-build for it to work.

@vaibhavsagar

This comment has been minimized.

Contributor

vaibhavsagar commented Apr 27, 2018

I see that you're trying pip install in the Dockerfile. That won't work and is unnecessary. Here's a Dockerfile that will work and print out 5.4.0 as the version. I've tested this by building it locally, and it's building on mybinder.org right now: https://mybinder.org/v2/gh/vaibhavsagar/ihaskell-mybinder-nix/b29903cd019b4d7816ffda8006c87ef7e2dd1ec2

@choldgraf

This comment has been minimized.

Member

choldgraf commented Apr 29, 2018

hmmm, that's frustrating :-/ it's a bit hard for me to debug since there seems to be a lot of magic going on under the hood in the nix image/install script

@vaibhavsagar

This comment has been minimized.

Contributor

vaibhavsagar commented Apr 30, 2018

I wouldn't consider it 'magic' but it's definitely unusual, especially if you haven't seen it before.

The nix-shell line near the beginning downloads and temporarily makes available all dependencies to set up $NB_USER with $NB_UID and then immediately removes them. I think that is pretty straightforward to follow.

The complexity is concentrated in the nix-build line, which pulls all the dependencies in and sets up an isolated environment with all dependencies including Jupyter and IHaskell, and then symlinks that environment to result. This is why I need the jupyter script whose sole purpose is to redirect all command-line arguments to result/bin/ihaskell-notebook, which is another script that in turn runs jupyter notebook.

If you're running a Linux distro, you can install Nix and run the same command locally to poke around, which I find much more conducive to troubleshooting than waiting for a Docker container to build.

@choldgraf

This comment has been minimized.

Member

choldgraf commented Apr 30, 2018

sorry if my "magic" line came across as dismissive, I should have worded that better! Hmm I am at a bit of a loss - perhaps somebody that knows more about the notebook server could have insight (cc @minrk ?)

@jzf2101 jzf2101 added the question label May 28, 2018

@minrk

This comment has been minimized.

Member

minrk commented Jun 14, 2018

I think we do need to override CMD (aka args), but I think we don't need to override ENTRYPOINT (aka command). It may make sense for us to leave that alone so that images can specify entrypoint behavior (such as shell initialization). This would technically open the door to images creating an entrypoint that doesn't work (i.e. one that doesn't allow arbitrary commands to come from CMD), but I don't think that's a real problem.

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