add armhf/raspberry pi example stack #64
Conversation
docker-compose.arm.yml
Outdated
| - back-tier | ||
|
|
||
| db: | ||
| image: postgres:9.5 |
There was a problem hiding this comment.
If someone cloned this from Github and ran docker-compose up this would complain about not finding the images. Maybe it could have a build parameter here instead?
There was a problem hiding this comment.
Would you prefer a build or an existing public image on the Docker Hub? I'd prefer a public image, but that's no hard preference.
What's the best way to make people like such examples? In my experience an existing image brings less risk to break over time compared to some package manager having connection issues with some repository mirror.
docker-stack.arm.yml
Outdated
|
|
||
| db: | ||
| image: gesellix/postgres:9.5-rpi | ||
| volumes: |
There was a problem hiding this comment.
We should ping @tianon to see if there is a reason why we aren't supporting postgres from the armhf repository already. We would need to have the images set to a official account to merge.
There was a problem hiding this comment.
armhf doesn't appear to be supported by upstream in their official APT repos: http://apt.postgresql.org/pub/repos/apt/pool/main/p/postgresql-9.6/
We could probably get the Alpine variants building, though.
There was a problem hiding this comment.
Sounds good. This is the Dockerfile @gesellix put together:
There was a problem hiding this comment.
I'll have to update that Dockerfile - the gosu stuff isn't actually used if I remember correctly.
There was a problem hiding this comment.
Check back with @tianon I think I saw some activity on this over on the repo he manages.
There was a problem hiding this comment.
Yeah, I tried getting postgres up and going on armhf, but as I mentioned their repos don't support Debian, so I was planning to get the Alpine variants up at least, but in the case of Alpine 3.5 on armhf, I'm running into https://bugs.alpinelinux.org/issues/6372 again (so can't even get the base image built properly). 😞
There was a problem hiding this comment.
@tianon - that bug was supposed to have been fixed and is marked as fixed - can you reopen it so we can discuss there? I don't know if it's a new problem or a regression from an old one.
worker/Dockerfile.j.builder.arm
Outdated
| @@ -0,0 +1,11 @@ | |||
| FROM armhf/maven:jdk-8 | |||
There was a problem hiding this comment.
The splitting out of the jar via the builder is neat, but I think this either needs to be applied to the x64 bit images too or reverted back to the original format.
There was a problem hiding this comment.
I see the inconsistency and would also like to have a common pattern across architectures/platforms. But which pattern is good enough to be a good example without distracting people from "just starting a stack"? I personally see the combined builder+run image as a bad example, because we then have to explain that it's not good to run such an image in production. A Makefile could help documenting the necessary steps.
There was a problem hiding this comment.
We need the consistency between the two examples, the ARM files should just be a port rather than something that needs to be maintained separately.
|
@gesellix hi, are you also planning on creating a .NET core worker image to complete the stack? |
|
@ManoMarks I'd also recommend reducing the With the initial test ( Btw.. the worker's I can test across a multi-node cluster once we've iterated on a few of the comments. |
|
We should also call these files armhf in the same way the docker/docker repo does. Someone will probably help us out with an aarch64 / arm64 version in the future. Maybe @vielmetti? :-) |
|
It strikes me that this is a good reason for Is there a query you can run on docker hub that returns only |
|
@vielmetti like mentioned in my initial thoughts (#63) and seen in the popular portainer project, I'd also wish for an easier way of producing |
|
@alexellis I'll check if the .NET worker is possible. I haven't tried, yet. I'll also check what happened to the Java worker waiting for redis. I swear it worked on my machine/cluster... but not anymore. |
|
@gesellix - I was thinking of Portainer too as a model for this as far as |
|
So where are we on this? @alexellis do we have an LGTM? |
|
@ManoMarks I'm working on some suggestions by the reviewers. |
|
@ManoMarks several comments to work through. We need to iterate on it. |
|
Update:
Not addressed/fixed, yet:
|
|
@tianon - can you open a new bug with stack trace from the core dump to replace |
|
Is there another relational database that we can use to replace PostGres on Alpine? Alternately, can we use a non-alpine version of Postgres? |
|
@ManoMarks - there is https://github.com/kiasaki/docker-alpine-postgres which is a Dockerized Alpine Postgres - you might find that useful. However, the bug 6795 reported above is now marked as fixed so this might be a sufficiently solved problem to make progress. |
|
@alexellis, @gesellix is this moving forward? |
|
@ManoMarks yes, I'm still working on it. I got a flu, though, and I also stumbled on issues like this one: rsyslog/rsyslog#35 |
|
@gesellix No worries! I hope you feel better! I just wanted to make sure this wasn't getting lost. |
Is there a postgres or mysql version in Raspbian aka (Debian) repo(s)? https://wiki.debian.org/PostgreSql I guess whichever configuration is used, it should work on armhf (RPi), arm64/v8 (Pine64/Packet) and regular x86_64 consistently with only needing to change the base image. Any further changes than that will result in maintenance headaches. Also wonder whether it's worth using local images for the stack, so that people following the labs don't have to use untrusted images. |
You mean without central registry? Would that work with multiple nodes, then? I would hope for official images to be available at some point in time. The dockersamples repo might be considered as trusted repos? |
|
Minor update: I'm struggling with the error below, leading to a 100% cpu usage of the kworker process. It seems like that error only appears after deploying the example stack (not instantly, but after a few minutes), so maybe it's a Docker on Raspberry Pi issue, or something triggered by one of the services. If some of you have an idea how to find the root cause, I'd be very glad :-) /cc @alexellis @StefanScherer @DieterReuter |
|
hmmm, looks similar: moby/moby#27833 |
|
@gesellix Regarding building multiarch images. I've created a Travis matrix build with a deploy script that waits for the other builds and drafts and pushes the multiarch image. |
|
@StefanScherer Nice, thanks for the link, I'll give it a try! |
|
After the findings in moby/moby#27833 (comment) I tried to deploy the stack on Raspbian instead of Hypriot, but now I hit this error:
Seems to be a known issue:
edit: ... and should be fixed with raspberrypi/linux#1614 |
|
Using Hypriot 1.4.0 with a recent Kernel works for @StefanScherer (moby/moby#27833 (comment)), and myself without any of the mentioned Kernel issues. 🎉 Some votes still aren't handled by the worker, as it seems. I'll try to find out what happens in such cases. I suspect this is an issue of the example stack in general, and no specific issue of the armhf stack. Multiple redis containers with only a single worker (watching a single redis instance) might be the reason... The images still need to be pushed to an official repo. I'm happy to help with that, but any pointers how to start that process would be nice. I'll have to talk to @tianon I guess? |
|
Now I got the error messages again (via dmesg): |
|
The current Raspbian (2017-03-02-raspbian-jessie-lite) works without Kernel errors. |
|
I created an issue for Hypriot: hypriot/image-builder-rpi#166 |
|
Any update on this? Should I close this PR? |
|
I'm going to close this PR. Feel free to re-open if you want to try again. |
* Fix initial state of demo - pages/launches.js contains a minimal React component - pages/index.js removes all the components that have not been implemented yet * Removed forgotten import * Scaffold React components, revert pages/index.js * Spacing adjustments
This is a working example app for the armhf platform, including
docker stacksupport for a cluster of Raspberry Pis. I tried to stick to the "official" armhf/ images on the Docker Hub.Currently, some images are pulled from my private Docker Hub repo (gesellix/sample-*) to make the docker-stack work out of the box. I guess it would be nice to provide those via the official dockersamples/ repo, but that can obviously be fixed later.
Please note: