Any change for arm port for raspi?

[ikke-t]

Hi,

I was looking for mc server for my son, and I was going to try it on RasPi3. Do you see any problems preventing of trying to build this for arm docker? Like any of the stuff you pull in here other than just the server, are there tight x86 dependencies?

I thought to build it on https://hub.docker.com/r/container4armhf/armhf-alpine/.

[itzg]

I would be fantastic if you could tackle this. The only specific, non-scripts in use are my restify and jq. The former is cross compiled for "arm"...hopefully that's the right flavor https://github.com/itzg/restify/releases

jq also seems to have an arm build.

So seems to be good to proceed.

[itzg]

I forgot to mention that I have an older raspi so I can help work on this too.

[ikke-t]

I started doing it. I need to switch to alpine linux, as that's something small for arm, and actually the only one for arm ATM in dockerhub.

That required some command changes, and I drop useless packages from container. While at it, would you know why there is imagemagick being installed? where is it needed?

[ikke-t]

I need to stop now for a while. The task is two fold: First, to get it work on alpine container, then try make it work on arm. I just got it working on alpine. Last pieces were to add bash and git, which are needed during java build time. My changes are here: https://github.com/ikke-t/dockerfiles/tree/alpine

[ikke-t]

i believe it will build it if I just go back to raspi, with couple line chages there for arm. It was just too slow to keep repeating it on raspi.

[ikke-t]

here's the arm stuff. let's see tomorrow. https://github.com/ikke-t/dockerfiles/tree/armv7hl

[itzg]

Thank you so much for your help on this. I have been working on switching my images to Alpine, so that's even better.

Imagemagik is only used for the server icon conversion, which may not even be used that much for all I know.

Sounds like a great plan of attack. Feel free to get a PR started and we can comment/collaborate.

[itzg]

@ikke-t , the changes are looking really good. It seems like there was a performance reason for setting the starting heap equal to max heap, so looking at this

https://github.com/itzg/dockerfiles/compare/master...ikke-t:alpine#diff-1053f18ff04f4774e258fa2fe19a4841R48

I'm wondering if that shouldn't just be a HEAP_SIZE variable exposed for container creation. Then it could be default'ed appropriately for pi vs non-pi.

Speaking of which, pardon the silly questions, but will the raspi image need to be based on a different base image for ARM? If so, that can be maintained in a branch off of these alpine conversions.

Self answering that question, led me to find this:

https://hub.docker.com/r/hypriot/rpi-java/

Does that seem helpful?

[ikke-t]

Hi, I'll have a look later. I went for alpine as it was found with docker search arm. Simple :). I got interested due the idea of very small footprint of it. That also lessens the need for updates if there is less to update. Anyhow, the raspi has so little memory, so the footprint looked good.

I tried to get away with installing much stuff on it, but the Java build pulls quite much dependencies. Like bash and git ~250MB, which otherwise would not be needed there. Image would be a lot smaller if those builds were done from Dockerfile, and dependencies removed at the end. Also the startup time on raspi would be lot faster.

But I understand that's not likely the goal of this project, so the debian image might be easier. Anyhow, if you want to switch to alpine, the build worked on x86_64.

Let's see if the server works at all on RasPi before doing too much with it :)

I have no opinion on Java heap, I trust your advice. I just put some number there for the min, and left something for OS.

[itzg]

Sorry, I didn't notice that this particular one of theirs is based on raspbian. No, smaller footprint is always a great goal for Docker images, so I still prefer the approach you're taking. I also agree that alpine on x86 will be a great milestone.

[ikke-t]

I made the pull request for alpine x86_64 as you mentioned.

[ikke-t]

btw, I tried the raspi version tonight. No result yet, as it keeps building the spawn area for ages. Almost 4 hours spent on 45%. It only uses 1 core for the job. So good news is, the container works, the bad news is it's dead slow. Let's see tomorrow if it will start.

[itzg]

In this article http://lemire.me/blog/2016/04/02/setting-up-a-robust-minecraft-server-on-a-raspberry-pi/ he talks about it taking forever, but 4 hours seems way too long for kids to tolerate. Perhaps double check that the Java version is not using software floating point.

[ikke-t]

By googling around it seems openjdk is much slower on arm than oracle java. Unfortunately oracle is not distributable, I assume, so nogo in premade containers? It would require adding glibc into alpine. I don't quickly find such maintained container for arm either. There are those for x86.

[ikke-t]

I tried now with just Oracle java. It starts within 4 minutes.

[itzg]

Wow, the data totally proves it then. But, like you said it's not possible to distribute Oracle's via an image, etc.

Hmm, quite a dilemma...

[ikke-t]

Now I tried both Oracle java and openjdk out of container. Running on RasPi3 Fedora 25 Linux, it takes openjdk 3.5 hours to start minecraft server, where as 4 minutes with Oracle java. Wau. Quite a difference.

[itzg]

@ikke-t I finally got an image out there that uses the Oracle JDK since that package is available from the raspbian repo: itzg/minecraft-server:raspberrypi. FYI Resin's base image filled in the other piece in the puzzle since they have provided a solution for building for ARM on x86 via QEMU.

[itzg]

I had forgotten to post an update here. There is now an image tag armv7 which performs much better on RaspberryPi 3 B+ and newer; in fact, that’s the platform I use to natively build that image tag.

The fatal flaw in my previous attempts was that the JVM used in those cases didn’t have a JIT/HotSpot compiler, so the JVM was running in fully interpreted mode.