Vereinsverwaltung als Open-Source-App für Frappe 16 (MIT) + fertiges Docker-Setup

Community German Community
1

Hallo zusammen,

bisher sind meine Frappe-Apps immer in der Schublade geblieben — gebaut für den eigenen Bedarf, nie veröffentlicht. Diese ist die erste, die rausgeht: eine Vereins- und Mitgliederverwaltung, MIT-lizenziert. Vereine haben selten Budget für Software, und das Problem ist bei allen dasselbe.

Was drin ist
Mitglieder mit Mitgliedstypen und Beitragsklassen, Sparten mit eigener Leitung und Trainingszeiten, Beiträge inklusive SEPA-Mandaten, Veranstaltungen mit Anmeldung, Fotoalben mit Berechtigungen, Abstimmungen, Versammlungsprotokolle, Mitgliedsanträge über die Website, Blog. Dazu ein Mitgliederportal als eigenständige Vue-3-Anwendung unter /verein.

Reine Framework-App
Kein ERPNext nötig — läuft auf Frappe Framework 16 allein.

Installation
Weil das erfahrungsgemäß der Punkt ist, an dem es hakt, liegt das komplette Docker-Setup in einem zweiten Repo:

git clone https://github.com/saschafo/dms_verein_docker.git
cd dms_verein_docker
cp .env.example .env      # Passwörter setzen
./build.sh
./verein.sh up

Das baut ein Image mit Frappe 16 + der App, startet MariaDB, zwei Redis-Instanzen, Gunicorn, nginx, Websocket, Scheduler und zwei Worker und legt die Site beim ersten Start selbst an. Voraussetzung ist Docker, sonst nichts. Läuft nativ auf amd64 und arm64.

Zum Ausprobieren gibt es Demo-Daten auf Knopfdruck — ein Beispielverein mit sechs Sparten, Mitgliedern, Vorstand und Terminen — und derselbe Knopf entfernt sie wieder rückstandsfrei.

Auch als Vorlage brauchbar:

Wer eine eigene Frappe-App containerisiert testen will, ändert eine Zeile in der .env (APP_REPO_URL) und hat die Umgebung. Das Setup basiert auf frappe_docker (images/custom).

Docker-Setup: https://github.com/saschafo/dms_verein_docker
App: https://github.com/saschafo/dms_verein

Über Rückmeldungen freue ich mich — besonders, wenn jemand die Installation auf einem anderen System durchspielt. Die App ist frisch veröffentlicht, da steckt sicher noch der ein oder andere Fehler drin.

2 Likes
2

Ich finde gerade den Ansatz mit dem separaten Docker-Setup ziemlich praktisch. Ich habe bei eigenen kleinen Projekten schon erlebt, dass eine App eigentlich problemlos läuft, aber die Installation auf einem zweiten Rechner plötzlich zum eigentlichen Projekt wird. Wenn sich das wirklich mit Docker so reproduzierbar aufsetzen lässt, nimmt das eine Menge Frust raus. Und dass die Demo-Daten komplett wieder entfernt werden können, ist für erste Tests ebenfalls ziemlich angenehm.

1 Like
3

Danke dir! Genau das war die Hoffnung dahinter – dass man nicht erst zwei Tage mit der Installation verbringt, bevor man überhaupt sieht, ob die App zum eigenen Verein passt.

Wenn du magst, probier’s gerne mal auf einem anderen Rechner/System durch und sag mir, wo es hakt – über echtes Feedback von “fremden” Systemen freue ich mich am meisten, das findet man als Entwickler auf der eigenen Maschine nie.

4

Ein Punkt, der mich bei solchen fertigen Docker-Setups noch interessieren würde: Wie ist der Upgrade-Pfad gedacht?

Die erste Installation ist damit angenehm einfach, aber spätestens beim nächsten Frappe-Update möchte man wissen, wie App und Datenbank sauber mitgezogen werden. Wäre vielleicht noch ein guter Abschnitt für die README.

1 Like
5

Berechtigte Frage. Stand bisher nirgends, und beim Aufschreiben hab ich gemerkt, dass es auch im Setup selbst gefehlt hat.

Kurz: Das Image ist unveränderlich, die Daten liegen in Volumes. Update heißt also immer neu bauen und Container tauschen, Volumes bleiben stehen. ./verein.sh update macht das und fährt danach automatisch bench migrate. Das läuft im create-site-Job, sobald eine Site existiert, damit ziehen Schema-Änderungen aus Frappe und aus der App zusammen nach.

Was ich jetzt geändert habe:

Der Build hat bei jedem Lauf den Tag :16 überschrieben. Klingt harmlos, heißt aber, dass du nach einem missglückten Update nicht mehr an den vorherigen Stand kommst. Jetzt setzt der Build zusätzlich einen festen Tag mit dem App-Commit, also z.B. :16-dc31481, und zurück geht’s über CUSTOM_TAG in der .env. Achtung: Das setzt nur den Code zurück. Wenn migrate schon durch ist, brauchst du auch die Sicherung.

Apropos Sicherung, die lief vorher gar nicht automatisch. bench migrate führt Patches aus, und wenn einer mittendrin abbricht, hast du eine halb migrierte DB. Wird jetzt vorher gemacht.

Der Punkt, der mich selbst am meisten gewurmt hat: FRAPPE_BRANCH=version-16 ist ein beweglicher Branch. Zwei Leute, die an verschiedenen Tagen bauen, kriegen verschiedene Frappe-Stände. Für ein Setup, das mit „reproduzierbar" wirbt, eher schwach. Wer’s planbar haben will, trägt da ein Tag ein, v16.30.0 oder was gerade aktuell ist.

Beim Durchtesten ist mir dann noch aufgefallen, dass up und update gar nicht zurückkehren. docker compose logs -f hängt weiter, auch wenn der Container längst durch ist. War mir nie aufgefallen, weil ich sonst meist docker compose direkt nutze. Auch gefixt.

6

Seit dem letzten Mal habe ich mich tiefer eingelesen und erfahren, dass die Isolierung von Containern über Docker auch versteckte Kernel-Abhängigkeitskonflikte verhindert, was eine maximale Stabilität auf lange Sicht garantiert. Das hat mich an meine Motorradtouren erinnert, bei denen man einen tadellosen technischen Schutz mit winddichten Sturmhauben und warmen Balaclavas braucht, um dem kalten Fahrtwind ohne Erkältung zu trotzen.