Thunderstore
1.0.0
Thunderstore ist eine Mod-Datenbank und API zum Herunterladen von Mods.
Kopieren Sie .env.template nach .env und ändern Sie es nach Belieben. Wenn Sie Zugriff auf das Submodul python-packages haben und es geklont wird, stellen Sie sicher, dass BUILD_INSTALL_EXTRAS auf true gesetzt ist. Jeder andere Wert funktioniert nicht. Wenn Sie diese Einstellung ändern, muss die Umgebung neu erstellt werden (z. B. mit docker compose build ), damit sie wirksam wird.
Führen Sie docker compose up
Führen Sie docker compose exec django python manage.py migrate in einem anderen Terminal aus
Führen Sie docker compose exec django python manage.py shell aus und geben Sie den folgenden Code ein:
from django.contrib.sites.models import SiteSite.objects.create(domain="thunderstore.localhost", name="Thunderstore")
Stellen Sie sicher, dass Sie localhost durch das ersetzen, was Sie zum Herstellen einer Verbindung mit der Site verwenden! Im Allgemeinen sollten Sie thunderstore.localhost als Hauptdomäne verwenden, um das Authentifizierungs-Scoping korrekt durchzuführen (siehe SESSION_COOKIE_DOMAIN weiter unten).
Sie müssen außerdem zum Admin-Panel ( /djangoadmin ) navigieren und eine Zuordnung von einer Site zu einer Community konfigurieren. Sie können mit dem Django-Verwaltungsbefehl „ createsuperuser ein Superuser-Konto erstellen (ähnlich wie bei der Ausführung von „migrate“), um Zugriff auf das Admin-Panel zu erhalten.
Um eine Site mit einer Community zu verbinden, müssen Sie Folgendes tun:
Stellen Sie sicher, dass mindestens ein Community-Objekt vorhanden ist, oder erstellen Sie eines ( Risk of Rain 2 sollte automatisch erstellt werden).
Stellen Sie sicher, dass mindestens ein Site-Objekt vorhanden ist, oder erstellen Sie eines
Stellen Sie sicher, dass das domain name des Site-Objekts mit dem übereinstimmt, was Sie für die Verbindung mit Ihrer Entwicklungsumgebung verwenden
Erstellen Sie ein neues Community-Site-Objekt und verknüpfen Sie die beiden miteinander
Es gibt ein Skript zum Füllen der lokalen Datenbank mit Testdaten. Sie können es wie folgt ausführen:
Docker Compose Exec Django Python Manage.py Create_test_data
In der lokalen Entwicklung wird Minio für die S3-kompatible Dateispeicherung verwendet. Sie können über http://localhost:9000/ mit thunderstore:thunderstore Anmeldeinformationen darauf zugreifen
Die REST-API-Swagger-Dokumentation kann unter /api/docs/ eingesehen werden.
Derzeit ist die einzige relevante API /api/v1/package/ , die alle aktiven Mods in der Datenbank auflistet. Ein bestimmter Mod kann bei Bedarf auch mit dem Endpunkt /api/v1/package/{uuid4}/ abgerufen werden, wobei {uuid4} durch den uuid4-Wert des Mods ersetzt wird.
Auf die Admin-Site kann über /djangoadmin/ zugegriffen werden. Um die Admin-Site anzuzeigen, benötigen Sie ein Admin-Konto.
Vorausgesetzt, Docker wird verwendet, kann das Administratorkonto wie folgt erstellt werden:
docker compose exec django python manage.py createsuperuser
Beachten Sie, dass Sie unter Windows winpty zum Ausführen dieses Befehls verwenden müssen.
DEBUG : Sollte für die Produktion entweder auf „false“ oder überhaupt nicht gesetzt werden
SECRET_KEY : Eine lange und zufällige Zeichenfolge, die zum Hashen von Passwörtern und anderen Daten verwendet wird. Sollte geheim bleiben, wie der Name schon sagt.
ALLOWED_HOSTS : Durch Kommas getrennte Liste der Hostnamen, mit denen dieser Server verbunden werden kann. Zum Beispiel beta.thunderstore.io
PRIMARY_HOST : Der öffentliche Name des Servers, z. B. beta.thunderstore.io
PROTOCOL : Das Protokoll, das zum Erstellen von URLs zum Server verwendet werden soll. Entweder https:// oder http:// .
REPOSITORY_MAX_PACKAGE_SIZE_MB : Die maximale Einzelpaketgröße
REPOSITORY_MAX_PACKAGE_TOTAL_SIZE_GB : Die maximale Gesamtdateigröße, die von Paketen verwendet wird
GUNICORN_WORKER_COUNT : Wird verwendet, um zu steuern, wie viele Arbeiter Gunicorn spawnen
GUNICORN_LOG_LEVEL : Wird verwendet, um die Protokollierungsstufe von Gunicorn zu steuern
SESSION_COOKIE_DOMAIN : Wenn festgelegt, können Sitzungen innerhalb einer Domäne und ihren Unterdomänen gemeinsam genutzt werden. Zum Beispiel: thunderstore.io
Für lokale Tests gelten folgende empfohlene Werte:
SESSION_COOKIE_DOMAIN : thunderstore.localhost
Stellen Sie außerdem sicher, dass die Site-Objekte auf thunderstore.localhost oder einige seiner Subdomains verweisen, z. B. test.thunderstore.localhost .
SOCIAL_AUTH_SANITIZE_REDIRECTS : Auf True setzen, wenn Sie OAuth-Umleitungsdomänen einschränken möchten.
SOCIAL_AUTH_ALLOWED_REDIRECT_HOSTS : Liste zulässiger OAuth-Redirect-Domänen, verwendet, wenn SOCIAL_AUTH_SANITIZE_REDIRECTS aktiviert ist.
SOCIAL_AUTH_INIT_HOST : Der Host, der für soziale Authentifizierungsinitialisierungen und Rückrufe verwendet wird, unabhängig davon, auf welchem Host sich der Benutzer gerade befindet. Wenn nicht festgelegt, wird standardmäßig derselbe Wert wie AUTH_EXCLUSIVE_HOST verwendet. Wenn keines von beiden festgelegt ist, wird standardmäßig der Host der Anforderung verwendet.
AUTH_EXCLUSIVE_HOST : Ein Hostname/eine Domäne, die ausschließlich für die Authentifizierungslogik verwendet wird, z. B. den sozialen Authentifizierungsprozess. Wenn nicht festgelegt, wird kein Host als exklusiver Authentifizierungshost behandelt.
Für lokale Tests gelten folgende empfohlene Werte:
AUTH_EXCLUSIVE_HOST : auth.thunderstore.localhost
SOCIAL_AUTH_SANITIZE_REDIRECTS : auth.thunderstore.localhost,thunderstore.localhost
Um GitHub OAuth einzurichten, gehen Sie zu den Einstellungen auf GitHub (entweder persönliche oder Organisationseinstellungen) und wählen Sie unter Developer Settings OAuth Apps aus.
Erstellen Sie eine neue OAuth-Anwendung und verwenden Sie {AUTH_EXCLUSIVE_HOST}/auth/complete/github/ als Autorisierungs-Rückruf-URL, wobei {AUTH_EXCLUSIVE_HOST} durch den Wert ersetzt wird, der für die Einstellung AUTH_EXCLUSIVE_HOST verwendet wurde. Für eine lokale Umgebung könnten Sie beispielsweise http://auth.localhost/auth/complete/github/ verwenden, während für eine Live-Umgebung https://auth.thunderstore.dev/auth/complete/github/ verwendet werden könnte.
Nach dem Erstellen der OAuth-Anwendung müssen Sie der Anwendung außerdem die folgenden Umgebungsvariablen bereitstellen:
SOCIAL_AUTH_GITHUB_KEY : Der Client ID Wert der OAuth-Anwendung
SOCIAL_AUTH_GITHUB_SECRET Der Client Secret Wert der OAuth-Anwendung
Um ein Discord-OAuth einzurichten, gehen Sie zum Discord-Entwicklerbereich und erstellen Sie eine neue OAuth-Anwendung. Fügen Sie eine Rückruf-URL zu {AUTH_EXCLUSIVE_HOST}/auth/complete/discord/ hinzu, wobei {AUTH_EXCLUSIVE_HOST} durch den Wert ersetzt wird, der für die AUTH_EXCLUSIVE_HOST -Einstellung verwendet wurde. Für eine lokale Umgebung könnten Sie beispielsweise http://auth.localhost/auth/complete/discord/ verwenden, während für eine Live-Umgebung https://auth.thunderstore.dev/auth/complete/discord/ verwendet werden könnte.
SOCIAL_AUTH_DISCORD_KEY : Der Client ID Wert der OAuth-Anwendung
SOCIAL_AUTH_DISCORD_SECRET Der Client Secret Wert der OAuth-Anwendung
Das AWS S3/Boto3-Protokoll wird von mehreren Anbietern und Diensten unterstützt, daher kann die Implementierung je nach Anbieter variieren.
Weitere Details zur Implementierung finden Sie unter https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html. Sehen Sie sich auch Thunderstore/core/settings.py an, um zu erfahren, welche Umgebungsvariablen derzeit implementiert sind.
Legen Sie mindestens die folgenden Variablen fest:
AWS_ACCESS_KEY_ID : Authentifizierungsschlüssel-ID
AWS_SECRET_ACCESS_KEY : Geheimnis des Authentifizierungsschlüssels
AWS_S3_REGION_NAME : Speicher-Bucket-Region
AWS_S3_ENDPOINT_URL : Speicherdienst-Endpunkt
AWS_STORAGE_BUCKET_NAME : Bucket-Name
AWS_LOCATION : Speicherort innerhalb des Buckets, an den Dateien hochgeladen werden sollen
AWS_S3_SECURE_URLS : Auf „false“ setzen, um HTTPS zu deaktivieren, standardmäßig aktiviert
Die Usermedia-APIs nutzen vorsignierte S3-kompatible Speicher-URLs, um den eigentlichen Upload abzuwickeln. Daher muss das Usermedia-Backend auch ein S3-kompatibles Speicher-Backend sein. Ebenso kann das Usermedia-Speicher-Backend mit Umgebungsvariablen konfiguriert werden:
USERMEDIA_S3_ENDPOINT_URL : Intern zugänglicher Speicherdienst-Endpunkt
USERMEDIA_S3_ACCESS_KEY_ID : Authentifizierungsschlüssel-ID
USERMEDIA_S3_SECRET_ACCESS_KEY : Geheimnis des Authentifizierungsschlüssels
USERMEDIA_S3_SIGNING_ENDPOINT_URL : Öffentlich zugänglicher Speicherdienst-Endpunkt
USERMEDIA_S3_REGION_NAME : Speicher-Bucket-Region
USERMEDIA_S3_STORAGE_BUCKET_NAME : Name des Speicher-Buckets
USERMEDIA_S3_LOCATION : Speicherort innerhalb des Buckets, an den Dateien hochgeladen werden sollen
Der größte Unterschied im Vergleich zur AWS S3-Konfiguration ist das Hinzufügen einer USERMEDIA_S3_SIGNING_ENDPOINT_URL . Sofern angegeben, wird dies bei der Generierung vorsignierter URLs verwendet. Kann beispielsweise zur Umgehung der CDN-Domäne verwendet werden.
Die Datenbankkonfiguration ist ziemlich einfach, wenn eine lokale Datenbank verwendet wird, für die kein SSL erforderlich ist, aber auch Remote-Datenbanken über SSL-Verbindungen unterstützt werden.
DATABASE_URL : Die Datenbank-URL, die für eine Datenbankverbindung verwendet werden soll
DB_CLIENT_CERT : Base64-codiertes Client-Zertifikat zur Verwendung für die Datenbankverbindung. Wird in client-cert.pem abgelegt
DB_CLIENT_KEY : Base64-codierter Client-Schlüssel zur Verwendung für die Datenbankverbindung. Wird in client-key.pem platziert
DB_SERVER_CA : Base64-codierte Server-CA zur Verwendung für die Datenbankverbindung. Wird auf server-ca.pem abgelegt
Auf die in docker-compose.yml konfigurierte lokale Standarddatenbank kann zugegriffen werden:
Von der Shell: docker compose exec db psql -U django
Vom Browser aus: Navigieren Sie zu localhost:8080/?pgsql=db&username=django und verwenden Sie das Passwort django
Sie können das Caching für das Redis-Backend aktivieren, indem Sie eine Redis-URL angeben
REDIS_URL : Die Redis-Datenbank-URL, die für das Caching verwendet werden soll, z. B. redis://some-host:6379/0
Tests können mit diesem Befehl ausgeführt werden: docker compose exec django pytest Wenn Sie eine Datenbank neu erstellen müssen, verwenden Sie Folgendes: docker compose exec django pytest --create-db --migrations
Die CI-Pipeline prüft, ob neue PRs die Testabdeckung nicht verringern. Da dieser Vorgang recht langsam ist, sollten Sie die Abdeckung vor Ort überprüfen, bevor Sie eine PR einreichen.
Um die Coverage-Datei zu aktualisieren, führen Sie docker compose exec django coverage run -m pytest aus
Um den Abdeckungsbericht anzuzeigen, führen Sie docker compose exec django coverage report -m aus
Der Testlauf wird auf mehrere Worker in der CI-Pipeline aufgeteilt, und die Aufteilung zielt darauf ab, den Test auf alle verfügbaren Worker mit gleichem Zeitaufwand auszugleichen.
Um dies genau tun zu können, muss die Testdauerdatenbank auf dem neuesten Stand sein. Daher ist es eine gute Idee, die Testdauer-Datenbank von Zeit zu Zeit zu aktualisieren.
Die Testdauerdatenbank kann aktualisiert werden, indem die vollständige Testsuite mit dem Flag --store-durations ausgeführt wird. Ein vollständiges Befehlsbeispiel wäre also
Docker Compose Exec Django Pytest --store-durations
