Thunderstore
1.0.0
Thunderstore는 모드 다운로드를 위한 모드 데이터베이스이자 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에서 SiteSite.objects.create(domain="thunderstore.localhost", name="Thunderstore") 가져오기
사이트에 연결하는 데 사용하는 호스트 localhost 대체하세요! 일반적으로 인증 범위 지정을 올바르게 처리하려면 thunderstore.localhost 기본 도메인으로 사용해야 합니다(나중에 SESSION_COOKIE_DOMAIN 참조).
또한 관리자 패널( /djangoadmin )로 이동하여 사이트에서 커뮤니티로의 매핑을 구성해야 합니다. createsuperuser Django 관리 명령(마이그레이션 실행 방법과 유사)을 사용하여 슈퍼유저 계정을 생성하여 관리자 패널에 액세스할 수 있습니다.
사이트를 커뮤니티에 연결하려면 다음을 수행해야 합니다.
최소한 하나의 커뮤니티 개체가 있는지 확인하거나 새로 만드십시오( Risk of Rain 2 자동으로 생성되어야 함).
사이트 개체가 하나 이상 존재하는지 확인하거나 새로 만드세요.
사이트 개체의 domain name 속성이 개발 환경에 연결하는 데 사용하는 것과 일치하도록 만듭니다.
두 가지를 함께 연결하는 새 커뮤니티 사이트 개체를 만듭니다.
테스트 데이터로 로컬 데이터베이스를 채우는 스크립트가 있습니다. 다음과 같이 실행할 수 있습니다.
docker compose exec django python prepare.py create_test_data
로컬 개발에서는 S3 호환 파일 저장을 위해 minio가 사용됩니다. thunderstore:thunderstore 자격 증명을 사용하여 http://localhost:9000/을 통해 액세스할 수 있습니다.
REST API Swagger 문서는 /api/docs/ 에서 볼 수 있습니다.
현재 유일한 관련 API는 데이터베이스의 모든 활성 모드를 나열하는 /api/v1/package/ 입니다. 필요한 경우 /api/v1/package/{uuid4}/ 엔드포인트를 사용하여 특정 모드를 가져올 수도 있습니다. 여기서 {uuid4} 는 모드의 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이 생성되는 작업자 수를 제어하는 데 사용됩니다.
GUNICORN_LOG_LEVEL : gunicorn의 로깅 수준을 제어하는 데 사용됩니다.
SESSION_COOKIE_DOMAIN : 설정되면 도메인 및 해당 하위 도메인 내에서 세션을 공유할 수 있습니다. 예: thunderstore.io
로컬 테스트의 경우 권장되는 값은 다음과 같습니다.
SESSION_COOKIE_DOMAIN : thunderstore.localhost
또한 사이트 개체가 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 애플리케이션을 생성하고 {AUTH_EXCLUSIVE_HOST}/auth/complete/github/ 인증 콜백 URL로 사용합니다. 여기서 {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 애플리케이션을 만드세요. {AUTH_EXCLUSIVE_HOST}/auth/complete/discord/ 에 콜백 URL을 추가합니다. 여기서 {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 : HTTPS를 비활성화하려면 false로 설정하고 기본적으로 활성화됩니다.
usermedia API는 S3 호환 저장소에 미리 서명된 URL을 활용하여 실제 업로드를 처리하는 방식으로 작동합니다. 따라서 usermedia 백엔드는 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
