Unisave worker is the process that executes game backends in Unisave cloud.
The worker process executes in production in the context of these services:
The services in the context are:
- Request Gateway: This is the entrypoint into the worker system and it forwards backend requests to proper worker instances. This is where the primary traffic comes from.
- Prometheus: It collects worker instance metrics, which are used to measure worker system traffic and monitor its health. It probes the
/metricsendpoints from theworker-instancesprometheus job. - Worker System Supervisor: The supervisor handles worker pool scaling. It probes the
/metricsendpoint to collect CPU utilization. It side-steps prometheus to remove potential points of failure, and asks the workers directly. - Kubernetes: The
/healthendpoint is probed by kubernetes to determine pod readiness and health. - Web API: In order to initialize, the worker downloads initialization recipe from the web API. The recipe URL is provided either in an environment variable or in a request header field. Recipes are currently hosted by the web API service.
- DigitalOcean Spaces: The initialization recipe lists backend files and their URLs to be downloaded during initialization. These are currently downloaded directly from DigitalOcean Spaces via signed URLs.
How exactly these services interact with the worker is described in the External APIs documentation page.
There are no external service endpoints that need to be configured explicitly for the worker to start. The initialization recipe URL is provided at runtime.
The list of environment variables for configuration has a separate documentation page.
- Configuration
- External APIs
- Development Setup
- Code Architecture
- Concurrency
- Initialization
- Unisave Environment Variables
- Custom OWIN Environment Keys
- Loading PDB files
- Graceful Shutdown
- Shared
OwinandMicrosoft.OwinDLLs - HTTP Request Cancellation
- Memory Leakage
- Metrics
Restore NuGet packages:
dotnet restoreRead the Development Setup documentation page to see how to develop and debug the worker.
The project is built with the dotnet utility. Rider uses similar commands under the hood.
# build all projects
dotnet build
# build one project
dotnet build DotnetUnisaveWorker/DotnetUnisaveWorker.csproj
# build a project for production
dotnet publish -c Release DotnetUnisaveWorker/DotnetUnisaveWorker.csproj
# can specify output folder "out" with "-o out"
# - dotnet core projects are built as standalone executables
# - old framework projects are built as .exe that should be run via monoTo start the worker after cloning the repo and test it before deployment, you can apply progressively more complex tests:
- Unit testing: From Rider, launch unit tests to verify the functionality of internal pieces.
Locust worker testing: In locust repository, there are Worker tests, that are designed to be run against a worker process running inside Rider. Start with the Worker Echo Test to see how to initialize the worker and how to send individual requests. Then use the Worker Mixed Load Test to see how the worker performs in a complex concurrent scenario.- Locust against docker: You can do the same setup, but run the tests against
make rundocker container with limited memory and CPU allocation to see how it breaks when overwhelmed. - Locust minikube: You can build the worker and run it in the minikube cluster and use Engine Evolution Test to stress the worker in the context of the whole cluster to see how it scales to multiple instances. You can then in addition start dropping in bombs (long timeout requests) to see how it handles those.