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

Feature: Docker armhf support #1041

Merged
merged 5 commits into from Jan 4, 2018

Conversation

Projects
None yet
3 participants
@immanuelfodor

immanuelfodor commented Dec 26, 2017

Hi Everyone,

I have created platform support for the armhf architecture as there is some ARM based Linux boxes that are armv7 32bit and your Alpine and Debian Jessie docker images do not run on this.


I have an armhf box which could not run the official Shaarli docker images, the log was filled with errors:

standard_init_linux.go:178: exec user process caused "exec format error"

I tried all three variants from here, all the same: https://shaarli.readthedocs.io/en/master/docker/shaarli-images/ I have seen this type of error before when accidentally ran a wrong platform repo from https://tools.linuxserver.io/dockers

So I looked into your dockerfile, and you are using Alpine Linux (I wanted the latest or master tag to run) but the base Alpine is not supporting arm32v7 as stated here: https://hub.docker.com/_/alpine/

As linuxserver.io's letsencrypt armhf is beautifully working on my box, and it is also based on Alpine, I looked into their dockerfile and saw that they used their own Alpine nginx armhf base which I followed back to their Alpine armhf image. Then I replaced your base Alpine image with theirs, also fixed some permissions and now I have a Shaarli instance running. The armhf Shaarli image works just as in your documentation.

I pushed my modifications to Github, you can find my changes in this pull request to the docker/alpine-armhf folder. One folder up, there is the original alpine folder which I duplicated, and modified both the Dockerfile.latest and Dockerfile.master files with my changes, also added a reference in the IMAGE.md for the base Linux build.


I think the armhf support opens up Shaarli to a lot many new people, so it should deserve its own tag at dockerhub (https://hub.docker.com/r/shaarli/shaarli/tags/) with reference here as well: https://shaarli.readthedocs.io/en/master/docker/shaarli-images/ . If you merge this pull request, please consider these updates, too.

@virtualtam virtualtam added this to the 0.10.0 milestone Dec 26, 2017

@nodiscc

This comment has been minimized.

Show comment
Hide comment
@nodiscc

nodiscc Dec 26, 2017

Member

I have no experience with linuxserver.io Docker images, I trust you that they are good quality work, but this addition would make us dependent on a third party/custom image on which we have no control. Not necessarily a hug problem but this is something to consider.

On the other hand Alpine provides official arm32v6 images. See here for an explanation of why there are no arm32v7 images (naming conventions). If I understand correctly using their arm32v6 image should work on your board. Does it?

I think the armhf support opens up Shaarli to a lot many new people, so it should deserve its own tag at dockerhub

I agree that Docker ARM support would be great, I'd just like to think this through.

Member

nodiscc commented Dec 26, 2017

I have no experience with linuxserver.io Docker images, I trust you that they are good quality work, but this addition would make us dependent on a third party/custom image on which we have no control. Not necessarily a hug problem but this is something to consider.

On the other hand Alpine provides official arm32v6 images. See here for an explanation of why there are no arm32v7 images (naming conventions). If I understand correctly using their arm32v6 image should work on your board. Does it?

I think the armhf support opens up Shaarli to a lot many new people, so it should deserve its own tag at dockerhub

I agree that Docker ARM support would be great, I'd just like to think this through.

@virtualtam

This comment has been minimized.

Show comment
Hide comment
@virtualtam

virtualtam Dec 26, 2017

Member

Neat! Thanks @immanuelfodor for the PR, I'll review it when I'm back from Xmas holidays ;-)

What kind of board are you using these images on?

Member

virtualtam commented Dec 26, 2017

Neat! Thanks @immanuelfodor for the PR, I'll review it when I'm back from Xmas holidays ;-)

What kind of board are you using these images on?

@immanuelfodor

This comment has been minimized.

Show comment
Hide comment
@immanuelfodor

immanuelfodor Dec 26, 2017

@nodiscc You can see on their website how many downloads they have, and they are an active community, available on chat/forum etc. All of their armhf images depend on the base I used, so I suppose that it is surely a good and stable origin for the build. If the Alpine arm32v6 would be supported by my board then your images would definitely run for the first time, wouldn't it? But it's clearly not running and the error is only present if the build is not for the architecture. When I used the armhf version, it ran immediately (but also needed the added chmods to run). Alpine is not yet fully supporting multiplatform, so I think it is advisable to use a build specifically made for the platform for best results (and for me to be able to run it:D).

@virtualtam It's an ODroid HC-1 from Hardkernel.com, you can see the specifications on the bottom of this page:
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G150229074080
I'm running Openmediavault 3.0.93 (updated from 3.0.92) with kernel 4.9.61 from here:
https://sourceforge.net/projects/openmediavault/files/Odroid%20images/
The HC-1 is the same in every way to the XU4 but has been adapted to NAS usage (eg. no GPIO ports but built-in SATA connector, etc). I'm in love with it, I can recommend it to anyone who wants a cheap but versatile home server.

immanuelfodor commented Dec 26, 2017

@nodiscc You can see on their website how many downloads they have, and they are an active community, available on chat/forum etc. All of their armhf images depend on the base I used, so I suppose that it is surely a good and stable origin for the build. If the Alpine arm32v6 would be supported by my board then your images would definitely run for the first time, wouldn't it? But it's clearly not running and the error is only present if the build is not for the architecture. When I used the armhf version, it ran immediately (but also needed the added chmods to run). Alpine is not yet fully supporting multiplatform, so I think it is advisable to use a build specifically made for the platform for best results (and for me to be able to run it:D).

@virtualtam It's an ODroid HC-1 from Hardkernel.com, you can see the specifications on the bottom of this page:
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G150229074080
I'm running Openmediavault 3.0.93 (updated from 3.0.92) with kernel 4.9.61 from here:
https://sourceforge.net/projects/openmediavault/files/Odroid%20images/
The HC-1 is the same in every way to the XU4 but has been adapted to NAS usage (eg. no GPIO ports but built-in SATA connector, etc). I'm in love with it, I can recommend it to anyone who wants a cheap but versatile home server.

@nodiscc

This comment has been minimized.

Show comment
Hide comment
@nodiscc

nodiscc Dec 27, 2017

Member

Alpine arm32v6 [...] clearly not running
Alpine is not yet fully supporting multiplatform, so I think it is advisable to use a build specifically made for the platform for best results (and for me to be able to run it:D).

Makes sense, and it answers my question. Nice board by the way, limited base OS choices as far as I can see, but the price/perf difference with other ARM boards makes me want to look into it. Do you run all your services/applications dockerized? Is finding ARM-compatible software challenging?

I've merged #1036 (documentation update), we should also update the Installation/Docker docs for your setup:

Member

nodiscc commented Dec 27, 2017

Alpine arm32v6 [...] clearly not running
Alpine is not yet fully supporting multiplatform, so I think it is advisable to use a build specifically made for the platform for best results (and for me to be able to run it:D).

Makes sense, and it answers my question. Nice board by the way, limited base OS choices as far as I can see, but the price/perf difference with other ARM boards makes me want to look into it. Do you run all your services/applications dockerized? Is finding ARM-compatible software challenging?

I've merged #1036 (documentation update), we should also update the Installation/Docker docs for your setup:

@immanuelfodor

This comment has been minimized.

Show comment
Hide comment
@immanuelfodor

immanuelfodor Dec 27, 2017

Originally, I wanted the latest RPi but then I found the DietPi board collection here: http://dietpi.com By clicking on the board images there is a nice pro/con section and introduction to every supported model with some relative charts. Here I recognized that although the RPis have much larger user base, they have many flaws that makes them good for first time users but unprofessional choice for "production" use. For example they have USB2 ports via an USB hub while other boards support USB3 on the SOC level, or they have standard Ethernet while others offer gigabit ethernet, etc. So the best option seemed to be the ODroid family, especially the C2 (older) and the XU4 (newest). I waited so long on the buy that in the meantime they started producing the HC-1 variant that even more catched my eyes. This small piece is beefed up like the C2/XU4 but solves the heat problem of the previous two by adding that enormous heat sink that is also holding the HDD/SSD. One USB3 port of the SOC is used by the SATA connector, one is backing the gigabit ethernet connector and the single USB2 bus is unused and has a spare connector on the front. It makes software RAID1 possible or doing regular backups to another HDD. What is more, if you want to extend your setup, you can stack them on top of each other and can have them joined in an array. There is this ODroid Magazine that is published like a blog regularly, in the current and previous issue they built up a distributed replicated GlusterFS server-client storage system, even the images are speaking for themselves but also a nice read:

Oh boy, these boards are definitely under the radar currently! They even have an MC-1 (My Cluster) variant in their shop that is 4 pieces of xu4 boards tied together that has 32 cores and 8 GB of ram as a cluster. The XU4 is the base platform that can be used in many ways, hence the MC-1 and my HC-1 is present. Early next year, the HC-2 will be released which will be the same as the HC-1 but will be capable of handling a 3.5 inch HDD as the HC-1 only supports the 2.5 format. All these variants will be supported and actively developed by Hardkernel until at least 2020, so won't disappear in a couple of months.

I'm currently running linuxserver.io 's letsencrypt-armhf docker image (alpine+letsencrypt+nginx reverse proxy+fail2ban) and the provided shaarli-armhf image parallel but also planning to set up nextcloud in the near future. The ram and speed is enough for all the things I could want at home. For HC-1, the OpenMediaVault (based on Debian Jessie) OS is a good start for a headless server, the web administration is easy to use and as docker is available as a native OMV plugin, you can deploy almost anything you want. If you are minimalist, the DietPi OS seems to me the perfect choice. If you have the XU4 that has HDMI port, then the linked Ubuntu is yours. The fact that I ran into the problem of architecture here only means nobody tried to run Shaarli on such board before or haven't shared the modified docker image. I think any not-armhf images that are based on Alpine could be simply migrated by replacing the FROM part to what I used without problem, so if I run into the same error in the future this is what I'll try again.

I would ask you guys to make the mentioned docker docs and guides changes, I'm not so sure I would be the best choice for this task as you know it better than me, this is your playground here :)

immanuelfodor commented Dec 27, 2017

Originally, I wanted the latest RPi but then I found the DietPi board collection here: http://dietpi.com By clicking on the board images there is a nice pro/con section and introduction to every supported model with some relative charts. Here I recognized that although the RPis have much larger user base, they have many flaws that makes them good for first time users but unprofessional choice for "production" use. For example they have USB2 ports via an USB hub while other boards support USB3 on the SOC level, or they have standard Ethernet while others offer gigabit ethernet, etc. So the best option seemed to be the ODroid family, especially the C2 (older) and the XU4 (newest). I waited so long on the buy that in the meantime they started producing the HC-1 variant that even more catched my eyes. This small piece is beefed up like the C2/XU4 but solves the heat problem of the previous two by adding that enormous heat sink that is also holding the HDD/SSD. One USB3 port of the SOC is used by the SATA connector, one is backing the gigabit ethernet connector and the single USB2 bus is unused and has a spare connector on the front. It makes software RAID1 possible or doing regular backups to another HDD. What is more, if you want to extend your setup, you can stack them on top of each other and can have them joined in an array. There is this ODroid Magazine that is published like a blog regularly, in the current and previous issue they built up a distributed replicated GlusterFS server-client storage system, even the images are speaking for themselves but also a nice read:

Oh boy, these boards are definitely under the radar currently! They even have an MC-1 (My Cluster) variant in their shop that is 4 pieces of xu4 boards tied together that has 32 cores and 8 GB of ram as a cluster. The XU4 is the base platform that can be used in many ways, hence the MC-1 and my HC-1 is present. Early next year, the HC-2 will be released which will be the same as the HC-1 but will be capable of handling a 3.5 inch HDD as the HC-1 only supports the 2.5 format. All these variants will be supported and actively developed by Hardkernel until at least 2020, so won't disappear in a couple of months.

I'm currently running linuxserver.io 's letsencrypt-armhf docker image (alpine+letsencrypt+nginx reverse proxy+fail2ban) and the provided shaarli-armhf image parallel but also planning to set up nextcloud in the near future. The ram and speed is enough for all the things I could want at home. For HC-1, the OpenMediaVault (based on Debian Jessie) OS is a good start for a headless server, the web administration is easy to use and as docker is available as a native OMV plugin, you can deploy almost anything you want. If you are minimalist, the DietPi OS seems to me the perfect choice. If you have the XU4 that has HDMI port, then the linked Ubuntu is yours. The fact that I ran into the problem of architecture here only means nobody tried to run Shaarli on such board before or haven't shared the modified docker image. I think any not-armhf images that are based on Alpine could be simply migrated by replacing the FROM part to what I used without problem, so if I run into the same error in the future this is what I'll try again.

I would ask you guys to make the mentioned docker docs and guides changes, I'm not so sure I would be the best choice for this task as you know it better than me, this is your playground here :)

Show outdated Hide outdated docker/alpine-armhf/Dockerfile.latest
Show outdated Hide outdated docker/alpine-armhf/nginx.conf
@immanuelfodor

This comment has been minimized.

Show comment
Hide comment
@immanuelfodor

immanuelfodor Jan 4, 2018

I've just pushed the changes, the build succeeded, but I don't have the time to test it right now by creating a new container from the image, maybe this afternoon.

immanuelfodor commented Jan 4, 2018

I've just pushed the changes, the build succeeded, but I don't have the time to test it right now by creating a new container from the image, maybe this afternoon.

@immanuelfodor

Changes implemented in 6f1eed7, docker build succeeds, docker image runs in the same environment as before, Shaarli works as it should.

@virtualtam virtualtam modified the milestones: 0.10.0, 0.9.3 Jan 4, 2018

@virtualtam

This comment has been minimized.

Show comment
Hide comment
@virtualtam

virtualtam Jan 4, 2018

Member

Thanks! I'll update the Docker Store setup to build the new tags ;-)

Member

virtualtam commented Jan 4, 2018

Thanks! I'll update the Docker Store setup to build the new tags ;-)

@immanuelfodor

This comment has been minimized.

Show comment
Hide comment
@immanuelfodor

immanuelfodor commented Jan 4, 2018

Awesome! :)

@virtualtam virtualtam merged commit b6b5314 into shaarli:master Jan 4, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@virtualtam

This comment has been minimized.

Show comment
Hide comment
@virtualtam

virtualtam Jan 4, 2018

Member

New tags are:

  • shaarli/shaarli:armhf-latest
  • shaarli/shaarli:armhf-master

@nodiscc do you want to take care of updating the docs in your branch?

Member

virtualtam commented Jan 4, 2018

New tags are:

  • shaarli/shaarli:armhf-latest
  • shaarli/shaarli:armhf-master

@nodiscc do you want to take care of updating the docs in your branch?

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