Skip to content
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

How difficult to support ARM images? #8

Open
tenken opened this issue Sep 11, 2016 · 2 comments
Open

How difficult to support ARM images? #8

tenken opened this issue Sep 11, 2016 · 2 comments

Comments

@tenken
Copy link

tenken commented Sep 11, 2016

Hi --

Thanks for all the great work. For me, I've not run into the persistent data problems mentioned in other issues and docker-grav works great. I have a fork of your repository where I'm bumping the Grav core version and providing updated docker builds usually within a few days of Grav releases on docker hub. And for me I've been using your docker-grav in essence since I think 1.10.

I run docker-grav on a Synology NAS 415+ and it runs great there. I also use the NAS's applications such as HyperBackup to snapshot my persistent directory into Amazon Cloud Drive as a backup of my site. While the site runs great on my NAS, the nas consumes a decent amount of power so I have it on a power schedule of 5:30am - 8:30pm.

I recently bought an Odroid C2 and I've installed Armbian Ubuntu 16.04 LTS on it, and Docker.

Although; I suppose somewhere in docker-grav, or chapdev, or alpinelinux image layers docker-grav is built for x86 cpus (I'm not sure where because I see no ARCH options in any of the make files -- unless it's just the assumed global default everywhere throughout all the dockerfiles).

My question is how hard would it be to supply an aarch64 docker image? I'd love to (try) and moderate the site on my nas locally, backup and snapshot it there, and then essentially rsync my persistent directory to my Odroid and have a very light weight 24/7 powered web server essentially that doesnt suck gob of electricity haha.

The error from the x86 image in docker is as follows, as does the arch of my arm board:

dgurba@odroidc2:~$ sudo docker run -d -p 8080:8080 tenken/docker-grav:1.1.5
cf30dbcfdce99c1ab16e3ce78e5bfd2c9376ffbb0e48ea31e5329847674ba26f
docker: Error response from daemon: rpc error: code = 2 desc = "oci runtime error: exec format error".
dgurba@odroidc2:~$ uname -a
Linux odroidc2 3.14.74-odroidc2 #1 SMP PREEMPT Sun Aug 7 08:59:34 CEST 2016 aarch64 aarch64 aarch64 GNU/Linux

Thanks again. If it's too cumbersome because each layer would have to change I understand that. I'm relatively new to Docker. I appreciate any feedback regarding options (even like, use this other simpler docker grav image with linux+ngnix+grav and swap out a base linux image with an aarch64 one); as I understand it chaperone is something you created and maintain.

@tenken
Copy link
Author

tenken commented Sep 12, 2016

As a followup. I guess I see a possible alternative as using a docker image such as https://github.com/Sandlayth/docker-arm-nginx-php-fpm/blob/master/README.md to host a LEMP stack and rsyncing the hmmm /home/apps docker-grav folder to the Odroid device occasionally. Adjusting permissions/ownership as needed in a CI setup or git commit hook for example.

But I do really like how docker-grav makes Grav a turn-key solution for x86 systems using Docker.

@tenken
Copy link
Author

tenken commented Sep 12, 2016

1 more followup. So a grav:backup task creates a full grav backup in the docker-grav-storage backups directory. I can take that zip file and move it to a permanent storage location on the Odroid and start the docker-arm-php-nginx-fpm container and the site appears to come up to my homepage :D fine in my local network range as a test.

So it appears its just a simple task of making a nightly sync task on my NAS to create a backup of the site and move and extract it to my Odroid device at a specific location. So docker-grav becomes an internal publishing location and the Odroid can become the public visible webserver on 24/7.

I like this idea/approach as the container(s) become largely irrelevant and by using Docker the recipe is simply:

  • backup your persistent data
  • find a suitable image to run on your hardware (ARM or x86/64) and use it to present your persisted data as needed (Test, Stage, Prod).

Thanks I hope my issue/musings aren't annoying. If you have any other feedback I welcome it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant