Interest in docker images for arm/Raspberry Pi

[step21]

Hi,

I just started to build docker images for jupyter based on this repository that are compatible with the Raspbbery Pi and other arm devices. I followed the steps of these dockerfiles (so far only base-notebook is done) but used pip instead of conda, as there is no official version of conda for arm and at the time i thought it was closed source. Now that I saw it would be possible to self-compile conda or maybe use berryconda (though that requires debian jessie) I might redo it with those. As baseimage I used balenalib-debian:python3.7-stretch - balena formerly resin) is a special debian distribution optimized for small devices. And f.e. already includes qemu to allow cross compiling on x86 to arm.

Generally, I just wanted to ask if there is any interest in including the resulting files and images in this repository? As the install method will have to differ a bit, at least for the base image, I am not sure if it makes sense to make a combined docker file that can do both or if they should stay seperate files. Any thoughts?

[parente]

@step21 It's great to hear you're interested in working on rpi/arm compatible images. Based on what I know (which is little) about how ARM support would require a different base image, Python build, conda build, etc. I think it would be best to maintain those images in a separate repo that we link from the community stacks documentation page. There was an effort long ago to add support for ppc architecture images to the repo here, but building, testing, and maintaining them properly alongside the more rapidly changing x86 images never panned out.

[step21]

First two images (based on berryconda) are functional now. https://github.com/step21/raspi-jupyter-docker-stacks
Currently only base-notebook and minimal-notebook.

[jiwidi]

Hi! I've been referred to this issue as I was working towards a contribution for rpi jupyter images. I have a working image for jupyter lab atm. I think we could join forces into a single PR and standardize jupyter images for arm. What do you think @step21 ? 😊

My current lab image https://github.com/jiwidi/jupyter-lab-docker-rpi

[step21]

Hi, thanks for commenting and your work. Please take a look at my images. You will see that they mirror the official ones as close as possible. I also first just used a general one like you or that someone else made, but abandoned it. As I see it, just running basic jupyterhub/lab is not a problem most of the time. More problematic is getting a full installation with everything built in and different kernels. For that docker is great and it's important to have multiple images building on top of each other.
This is also why conda is used, as it can provide different kernels, compilers, whatever, which would be difficult or might have to be compiled from scratch otherwise.
The biggest issue with that right now is that the maintainer of berryconda is not maintaining it anymore. I would like to either create my own repo/channel supplying conda packages for rpi or ideally take over his repo. Which I suggested but he didn't reply to that yet. jjhelmus/berryconda#79

[mathematicalmichael]

@step21 thank you for your work on this!
I really needed it. Got jupyterlab auto-launching now via docker restart policy whenever my pi4 gets power. Will eventually work on upgrading the images to jlab > 1.0 and take a stab at compiling the scipy image, though I have minimal prior experience on the ARM architecture.

[step21]

@mathematicalmichael thanks! The scipy image is planned, I just want to resolve the fate of berryconda and rpi channel on conda first, as some stuff esp for scipy really needs a version upgrade but I want to make it using (berry)conda and rpi channel and not reinvent or selfcompile everything. See here jjhelmus/berryconda#79 (comment)

[mathematicalmichael]

@mathematicalmichael thanks! The scipy image is planned, I just want to resolve the fate of berryconda and rpi channel on conda first, as some stuff esp for scipy really needs a version upgrade but I want to make it using (berry)conda and rpi channel and not reinvent or selfcompile everything. See here jjhelmus/berryconda#79 (comment)

... I ended up running into that problem maybe 2 hours after commenting. I'm sure you saw that as I found myself in the berryconda issues.

building for ARM is way more of a challenge than I expected.

[querafael]

Hey @step21 thanks a lot for the effort to have it available for rpi! Could you also update the images on docker hub? I see that the last update over there is abou 8 months old. I would be highly appreciated

[step21]

Hey @step21 thanks a lot for the effort to have it available for rpi! Could you also update the images on docker hub? I see that the last update over there is abou 8 months old. I would be highly appreciated

Thanks. This should be the latest. https://hub.docker.com/repository/docker/step21/rpi-base-notebook
Will check and and make sure all are uploaded tomorrow.

[step21]

Will check and and make sure all are uploaded tomorrow.
Somehow I get an error when uploading.
error creating overlay mount to /var/lib/docker/overlay2/145199a435e49caf855babdb27a3c2c9465bfe69a845b42d9022b3e8359a7cfa/merged: device or resource busy Not sure why... supposedly some issue with overlayfs2 between kernel and docker. Anyone know how to resolve this?

[step21]

Hey @step21 thanks a lot for the effort to have it available for rpi! Could you also update the images on docker hub? I see that the last update over there is abou 8 months old. I would be highly appreciated

The newest versions are now here https://hub.docker.com/repository/docker/step21/jupyter-base-notebook and here https://hub.docker.com/repository/docker/step21/jupyter-minimal-notebook

[AvverbioPronome]

I tought about this some more, have we considered ditching conda/berryconda and going for pip only using piwheels? (It has one limitation, support for python 3.7 only)

I have an image running this way and it works, but it's not a notebook server (pandas, matplotlib, and flask).

[step21]

I tought about this some more, have we considered ditching conda/berryconda and going for pip only using piwheels? (It has one limitation, support for python 3.7 only)

For simple python-only images this can work. I had this too, that's not an issue.
Most importantly, conda can provide R and other compilers etc to jupyterlabs as well. This is of course possible without, but not with pip, then using other package managers or compiling from source. My goal is/was to stick as close as possible to official jupyter docker images. This means using conda and installing as much as possible with it ;)

[AvverbioPronome]

My goal is/was to stick as close as possible to official jupyter docker images. This means using conda and installing as much as possible with it

It makes sense, but with berryconda not being maintained anymore maybe we should think of rebasing on python:3.7 and pip (python:3.7 is a debian:buster with python installed from source) and add what's not available in pip gets installed via apt or manually (being careful not to install another python copy).

This might be an idea for the official images too, maybe.

[step21]

My goal is/was to stick as close as possible to official jupyter docker images. This means using conda and installing as much as possible with it

It makes sense, but with berryconda not being maintained anymore maybe we should think of rebasing on python:3.7 and pip (python:3.7 is a debian:buster with python installed from source) and add what's not available in pip gets installed via apt or manually (being careful not to install another python copy).

This might be an idea for the official images too, maybe.
@AvverbioPronome

I think no one wants to install via apt, because often it is way too old. That said, I also want to ask my question that I asked over at berryconda github - what is you reason to use 32bit based distro?
Since I discovered that conda-forge has support for aarch64, it works well and it is growing continuously, I would rather spend my time on this than setting up a whole new infrastructure for berryconda or image where I pull in everything by hand / by apt. (and frequently by hand or random ppas because apt original will be too old)
aarch64 images are here under tag arm64 https://hub.docker.com/repository/docker/step21/jupyter-minimal-notebook (scipy image coming soon, once scikit-image is merged)

[AvverbioPronome]

what is you reason to use 32bit based distro?

The most stable (and actually working) distribution on a raspberry pi is the official 32 bit raspiOS. This might change once raspiOS 64 bit gets released as stable.

I tried doing the same things with ubuntu aarch64 but it wasn't as stable.

[mathematicalmichael]

what is you reason to use 32bit based distro?

The most stable (and actually working) distribution on a raspberry pi is the official 32 bit raspiOS. This might change once raspiOS 64 bit gets released as stable.

I tried doing the same things with ubuntu aarch64 but it wasn't as stable.

Heads up: I got 64-bit raspbian running on my 4b+, came out last week, still experimental but working smoothly so far (I'm using the desktop mode)

[step21]

Heads up: I got 64-bit raspbian running on my 4b+, came out last week, still experimental but working smoothly so far (I'm using the desktop mode)

Cool.

I tried doing the same things with ubuntu aarch64 but it wasn't as stable.

What wasn't stable? I am running some stuff on ubuntu aarch64 since a month and it really great so far. Really trying to understand.

I have some images ofr aarch64 here https://hub.docker.com/repository/docker/step21/jupyter-minimal-notebook - I think I decided that unless there is more effort to bring armv7l to conda-forge, I will focus on aarch64 and contribute to getting that on as many packages as possible on conda-forge.

[AvverbioPronome]

What wasn't stable? I am running some stuff on ubuntu aarch64 since a month and it really great so far. Really trying to understand.

It just failed randomly, but I was really demanding, running 12 other containers (multiple nginx, postgres, php-fpm, gunicorn...). And I was using a Pi 3.

[masip85]

at unless there is more effort to bring armv7l to conda-forge, I will focus on aarch64 and contribute to getting that on as many packages as possible on conda-forge.

I've seen that your docker image hasn't a Dockerfile uploaded, and this
is for armv7l. So I don't know what are you using, are you using normal conda? And soon sci-kit learn,isn't it? What about numpy? Could you share those dockerfiles?

[step21]

@masip85 the dockerfile is there on aarch64 branch https://github.com/step21/raspi-jupyter-docker-stacks/tree/aarch64
Same for the docker image, it is in the same repo, but aarch64 is under arm64 tag. I thought that would make sense, but maybe it is too confusing?
It uses miniconda.

[masip85]

@step21 , I am sorry,I didn't see the branches! Now I see it uses miniforge, not exactly the same that miniconda. I think it just uses conda-forge, but as a restriction or default? I wanted to add something like:

Install conda4aarch64. This will create a minimal conda environment.

Add the c4aarch64 and conda-forge channels to your conda configuration:

$ conda config --add channels c4aarch64
$ conda config --add channels conda-forge

Then you can install Numba from the numba channel:

$ conda install -c numba numba

[step21]

Yeah sorry I meant miniforge. Miniconda dropped arm support, so miniforge is the best option.
conda4aarch64 was just an experiment by jjhelmus and miniforge is now where that work continues. conda4aarch64 is not maintained, so I would not use that anymore. You can always add your own channels of course. It is just easier to maintain if not mix and matching channels. That is why I chose to contribute to conda-forge, and as soon as llvmlite is availabe, numba etc can be added, and then there will be a scipy-image.
You can track that progress here https://github.com/conda-forge/llvmlite-feedstock/pulls

[masip85]

Well,but I mean,can I go whereas building a beta with numpy,scipy,:

and numba (from other channels), isn't it?

[step21]

sure you can. To make it easier, I added the work in progress version of scipy-notebook. You will have to edit it for it to work. https://github.com/step21/raspi-jupyter-docker-stacks/tree/aarch64/scipy-notebook

[masip85]

Do you use last DockerFile with rpi4 Ubuntu 64bits?
I execute it and I got errors:
First,for numba,numba channel must be specified. And jumping numba,I get,

ValueError: Please install Node.js and npm before continuing installation. You may be able to install Node.js from your package manager, from conda, or directly from the Node.js website (https://nodejs.org).

[step21]

As I said, it is not working yet. I just uploaded if for you as a courtesy, so you can use that as basis if you want. Yesterday, llvmlite was merged to conda-forge, which will enable numba and then I will fix it.

[masip85]

Yes, the issue is that I thought it was a functional Dockerfile. I just did an small numba change:

conda config --add channels c4aarch64
conda install -c numba numba

And as you said, soon,numba in conda-forge.

And jupyter extensions building will be possible?

[masip85]

@step21 , numba is working from conda-forge:

This step is used at the end of your repo raspi-docker-stacks:

Step 8/12 : RUN conda install numba     &&     conda clean --all -f -y &&     rm -rf $CONDA_DIR/share/jupyter/lab/staging &&     fix-permissions $CONDA_DIR &&     fix-permissions /home/$NB_USER
 ---> Running in 1f90b9ff7ed9
Collecting package metadata (current_repodata.json): ...working... done
Solving environment: ...working... done

## Package Plan ##

  environment location: /opt/conda

  added / updated specs:
    - numba


The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    libllvm10-10.0.1           |       h6bb024c_0        25.9 MB  conda-forge
    llvmlite-0.34.0            |   py37h5202443_0         320 KB  conda-forge
    numba-0.51.0               |   py37h9fdb41a_0         3.6 MB  conda-forge
    ------------------------------------------------------------
                                           Total:        29.8 MB

The following NEW packages will be INSTALLED:

  libllvm10          conda-forge/linux-aarch64::libllvm10-10.0.1-h6bb024c_0
  llvmlite           conda-forge/linux-aarch64::llvmlite-0.34.0-py37h5202443_0
  numba              conda-forge/linux-aarch64::numba-0.51.0-py37h9fdb41a_0


Proceed ([y]/n)? 

Downloading and Extracting Packages
libllvm10-10.0.1     | 25.9 MB   | ########## | 100% 
llvmlite-0.34.0      | 320 KB    | ########## | 100% 
numba-0.51.0         | 3.6 MB    | ########## | 100% 
Preparing transaction: ...working... done
Verifying transaction: ...working... done
Executing transaction: ...working... done

Which functionalities left? Many things of course, but should arm be in a separated repo? Which should be next steps?

Can things like jupyter lab extensions work in rpi?

[step21]

@step21 , numba is working from conda-forge:

Thanks, yeah I worked on that one :)

Which functionalities left? Many things of course, but should arm be in a separated repo? Which should be next steps?

Next thing would be some R packages, which require pandoc which requires Haskell which is not on conda for aarch64 yet. For now it has to be in a seperate repo, though I am also working on integrating qemu so that docker hub will build aarch64 for me as well.

Can things like jupyter lab extensions work in rpi?

Most jupyter lab extensions are just javascript, so they should definitely work.

[mathematicalmichael]

Next thing would be some R packages, which require pandoc which requires Haskell which is not on conda for aarch64 yet.

every time I'm reminded of R's dependencies I want to cry. Thanks for putting in the work on this stuff!

[step21]

Thanks. On another packages, I could sidestep haskell/pandoc as it was only used for documentation. But not sure if that is also true for R.