Thunderstore
1.0.0
Thunderstore は、MOD をダウンロードするための MOD データベースおよび API です。
.env.template .envにコピーし、必要に応じて変更します。 python-packagesサブモジュールにアクセスでき、それが複製されている場合は、 BUILD_INSTALL_EXTRAS trueに設定してください。他の値は機能しません。この設定を変更するには、それを有効にするために環境を再構築する必要があります ( docker compose buildなど)。
docker compose up実行する
別のターミナルでdocker compose exec django python manage.py migrateを実行します
docker compose exec django python manage.py shell実行し、次のコードを入力します。
django.contrib.sites.models から import SiteSite.objects.create(domain="thunderstore.localhost", name="Thunderstore")
localhostサイトへの接続に使用するものに置き換えてください。一般に、認証スコープを正しく処理するには、 thunderstore.localhostメイン ドメインとして使用する必要があります (後述のSESSION_COOKIE_DOMAINを参照)。
また、管理パネル ( /djangoadmin ) に移動し、サイトからコミュニティへのマッピングを構成する必要があります。 createsuperuser Django 管理コマンド (移行の実行方法と同様) を使用してスーパーユーザー アカウントを作成し、管理パネルにアクセスできます。
サイトをコミュニティに接続するには、次のことを行う必要があります。
少なくとも 1 つのコミュニティ オブジェクトが存在することを確認するか、コミュニティ オブジェクトを作成してください ( Risk of Rain 2は自動的に作成されるはずです)
少なくとも 1 つの Site オブジェクトが存在することを確認するか、サイト オブジェクトを作成してください
サイト オブジェクトのdomain name属性を、開発環境への接続に使用するものと一致させます。
新しいコミュニティ サイト オブジェクトを作成し、2 つをリンクします
ローカル データベースにテスト データを入力するためのスクリプトがあります。次のように実行できます。
docker compose exec django python manage.py create_test_data
ローカル開発では、S3 互換のファイル ストレージとして minio が使用されます。 http://localhost:9000/ 経由で、 thunderstore:thunderstore認証情報を使用してアクセスできます。
REST API Swagger ドキュメントは/api/docs/から参照できます。
現時点では、関連する API は/api/v1/package/のみで、これにはデータベース内のすべてのアクティブな MOD がリストされます。必要に応じて、 /api/v1/package/{uuid4}/エンドポイントを使用して特定の MOD をフェッチすることもできます。ここで、 {uuid4}は MOD の uuid4 値に置き換えられます。
管理サイトには/djangoadmin/からアクセスできます。管理者サイトを表示するには、管理者アカウントが必要です。
docker が使用されていると仮定すると、管理者アカウントは次のように作成できます。
docker compose exec django python manage.py createsuperuser
Windows で実行している場合は、そのコマンドを実行するために winpty を使用する必要があることに注意してください。
DEBUG : 運用環境では false に設定するか、まったく設定しない必要があります。
SECRET_KEY : パスワードやその他のデータをハッシュするために使用される、長くてランダムな文字列。名前が示すように、秘密にしておく必要があります。
ALLOWED_HOSTS : このサーバーに接続できるホスト名のカンマ区切りのリスト。たとえば、 beta.thunderstore.io
PRIMARY_HOST : サーバーのパブリック名beta.thunderstore.ioなど)
PROTOCOL : サーバーへの URL を構築するために使用するプロトコル。 https://またはhttp://のいずれか。
REPOSITORY_MAX_PACKAGE_SIZE_MB : 単一パッケージの最大サイズ
REPOSITORY_MAX_PACKAGE_TOTAL_SIZE_GB : パッケージで使用される最大合計ファイル サイズ
GUNICORN_WORKER_COUNT : ガニコーンがスポーンするワーカーの数を制御するために使用されます
GUNICORN_LOG_LEVEL : GUNICORN のログレベルを制御するために使用されます
SESSION_COOKIE_DOMAIN : 設定すると、ドメインとそのサブドメイン内でセッションを共有できるようになります。例: thunderstore.io
ローカル テストの場合、推奨値は次のとおりです。
SESSION_COOKIE_DOMAIN : thunderstore.localhost
また、Site オブジェクトがthunderstore.localhostまたはそのサブドメインの一部 ( test.thunderstore.localhostなど) を指すようにしてください。
SOCIAL_AUTH_SANITIZE_REDIRECTS : OAuth リダイレクト ドメインを制限する場合は、 Trueに設定します。
SOCIAL_AUTH_ALLOWED_REDIRECT_HOSTS : SOCIAL_AUTH_SANITIZE_REDIRECTSが有効な場合に使用される、許可された OAuth リダイレクト ドメインをリストします。
SOCIAL_AUTH_INIT_HOST : ユーザーが現在どのホストを使用しているかに関係なく、ソーシャル認証の初期化とコールバックに使用されるホスト。設定されていない場合、デフォルトはAUTH_EXCLUSIVE_HOSTと同じ値になります。どちらも設定されていない場合は、デフォルトでリクエストのホストが使用されます。
AUTH_EXCLUSIVE_HOST : ソーシャル認証プロセスなどの認証関連ロジックに排他的に使用されるホスト名/ドメイン。設定しない場合、ホストは排他認証ホストとして扱われません。
ローカル テストの場合、推奨値は次のとおりです。
AUTH_EXCLUSIVE_HOST : auth.thunderstore.localhost
SOCIAL_AUTH_SANITIZE_REDIRECTS : auth.thunderstore.localhost,thunderstore.localhost
GitHub OAuth を設定するには、GitHub の設定 (個人設定または組織設定) に移動し、 Developer Settingsの下からOAuth Appsを選択します。
新しい OAuth アプリケーションを作成し、認可コールバック URL として{AUTH_EXCLUSIVE_HOST}/auth/complete/github/を使用します。ここで、 {AUTH_EXCLUSIVE_HOST}は、 AUTH_EXCLUSIVE_HOST設定に使用された値に置き換えられます。たとえば、ローカルの場合はhttp://auth.localhost/auth/complete/github/を使用できますが、ライブ環境の場合はhttps://auth.thunderstore.dev/auth/complete/github/
OAuth アプリケーションを作成した後、次の環境変数をアプリケーションに提供する必要もあります。
SOCIAL_AUTH_GITHUB_KEY : OAuth アプリケーションのClient ID値
SOCIAL_AUTH_GITHUB_SECRET OAuth アプリケーションのClient Secret値
Discord OAuth を設定するには、Discord 開発者パネルに移動し、新しい OAuth アプリケーションを作成します。コールバック URL を{AUTH_EXCLUSIVE_HOST}/auth/complete/discord/に追加します。ここで、 {AUTH_EXCLUSIVE_HOST}は、 AUTH_EXCLUSIVE_HOST設定に使用された値に置き換えられます。たとえば、ローカルの場合はhttp://auth.localhost/auth/complete/discord/を使用できますが、ライブ環境の場合はhttps://auth.thunderstore.dev/auth/complete/discord/
SOCIAL_AUTH_DISCORD_KEY : OAuth アプリケーションのClient ID値
SOCIAL_AUTH_DISCORD_SECRET OAuth アプリケーションのClient Secret値
AWS S3 / Boto3 プロトコルは複数のベンダーおよびサービスによってサポートされており、その実装はプロバイダーによって異なる場合があります。
実装の詳細については、https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html を参照してください。現在実装されている環境変数については、thunderstore/core/settings.py も参照してください。
少なくとも次の変数を設定します。
AWS_ACCESS_KEY_ID : 認証キーID
AWS_SECRET_ACCESS_KEY : 認証キーのシークレット
AWS_S3_REGION_NAME : ストレージバケットリージョン
AWS_S3_ENDPOINT_URL : ストレージ サービス エンドポイント
AWS_STORAGE_BUCKET_NAME : バケット名
AWS_LOCATION : ファイルをアップロードするバケット内の場所
AWS_S3_SECURE_URLS : false に設定すると HTTPS が無効になり、デフォルトで有効になります
usermedia API は、S3 互換ストレージの署名付き URL を利用して実際のアップロードを処理することで機能します。そのため、ユーザーメディア バックエンドも S3 互換ストレージ バックエンドである必要があります。同様に、usermedia ストレージ バックエンドは環境変数を使用して構成できます。
USERMEDIA_S3_ENDPOINT_URL : 内部的にアクセス可能なストレージ サービス エンドポイント
USERMEDIA_S3_ACCESS_KEY_ID : 認証キーID
USERMEDIA_S3_SECRET_ACCESS_KEY : 認証キーのシークレット
USERMEDIA_S3_SIGNING_ENDPOINT_URL : パブリックにアクセス可能なストレージ サービス エンドポイント
USERMEDIA_S3_REGION_NAME : ストレージ バケット リージョン
USERMEDIA_S3_STORAGE_BUCKET_NAME : ストレージ バケット名
USERMEDIA_S3_LOCATION : ファイルをアップロードするバケット内の場所
AWS S3 構成と比較した最大の違いはUSERMEDIA_S3_SIGNING_ENDPOINT_URLの追加です。指定した場合、これは署名済み URL を生成するときに使用されます。たとえば、CDN ドメインをバイパスするために使用できます。
SSL が不要なローカル データベースを使用する場合、データベースの構成は非常に簡単ですが、SSL 接続を介したリモート データベースもサポートされています。
DATABASE_URL : データベース接続に使用するデータベース URL
DB_CLIENT_CERT : データベース接続に使用する Base64 エンコードされたクライアント証明書。 client-cert.pemに配置されます
DB_CLIENT_KEY : データベース接続に使用する Base64 でエンコードされたクライアント キー。 client-key.pemに配置されます
DB_SERVER_CA : データベース接続に使用する Base64 エンコードされたサーバー CA。 server-ca.pemに配置されます
docker-compose.ymlで構成されたデフォルトのローカル データベースにアクセスできます。
シェルから: docker compose exec db psql -U django
ブラウザから: localhost:8080/?pgsql=db&username=djangoに移動し、パスワードdjangoを使用します。
Redis URL を指定することで、Redis バックエンドへのキャッシュを有効にできます。
REDIS_URL : キャッシュに使用する Redis データベース URL (例: redis://some-host:6379/0
テストは次のコマンドで実行できます: docker compose exec django pytestデータベースを再作成する必要がある場合は、次のコマンドを使用します: docker compose exec django pytest --create-db --migrations
CI パイプラインは、新しい PR によってテスト カバレッジが低下していないかどうかをチェックします。このプロセスはかなり時間がかかるため、PR を送信する前に対象範囲をローカルで確認することをお勧めします。
カバレッジ ファイルを更新するには、 docker compose exec django coverage run -m pytestを実行します。
カバレッジ レポートを表示するには、 docker compose exec django coverage report -mを実行します。
テストの実行は CI パイプライン上の複数のワーカーに分割され、分割の目的は、使用可能なすべてのワーカー間で同じ時間消費でテストのバランスを取ることです。
これを正確に行うには、テスト期間データベースが最新である必要があります。したがって、テスト期間データベースを時々更新することをお勧めします。
テスト期間データベースは、 --store-durationsフラグを指定して完全なテスト スイートを実行することで更新できます。したがって、完全なコマンドの例は次のようになります
docker compose exec django pytest --store-durations
