Contents

Reference

Application deployment model

Contents

Applications and Versions

A single installation of Scalable Pixel Streaming can be used to deploy multiple Pixel Streaming applications on the same Kubernetes cluster. The canary deployment feature also makes it possible to track multiple versions of a single application and switch between them as needed. To distinguish between separate applications and their different versions, Scalable Pixel Streaming stores information using a conceptual model composed of two entities:

  • An application is the high-level configuration that governs how your UE project is streamed and accessed. The application is not directly linked to a specific build of your UE project, but the configuration selected at this step will apply to all deployed versions of your UE project. At the application level, you can customise the cloud resources associated with a deployment (e.g. RAM / GPU / CPU), the connection options, and optional components such as a custom domain.

  • A version is the direct translation of your UE project. Versions are created either from a container image or uploaded from a compressed .zip UE project. You can deploy multiple versions under the same application, however, only one can be Active at a given time, e.g. you could deploy a new version to reflect an updated build of your UE project. At the version level, you can customise the resolution of your stream, the frontend it uses, etc.

The relationship between the application and version entities is depicted in the diagram below:

Relationship between the Application and Version entities in the conceptual model used by Scalable Pixel Streaming to represent application deployments.
Relationship between the Application and Version entities in the conceptual model used by Scalable Pixel Streaming to represent application deployments.

In the example above there are three Applications:

  • The Application “application A” has two versions, “v1.0.0” and “v1.0.1”. The current active version is “v1.0.1”, which means this version of the application is deployed and can be accessed by users. The previous version, “v1.0.0”, still exists and can be switched back on demand, for example, if v1.0.1 is still being verified or tested.

  • The Application “application B” has only one version, “v2.8.1” and this is the current active version.

  • The Application “application C” does not have any versions. It is a new application that has just been created, and its first version has not been uploaded yet.

Deployment process

Let’s see how the entities change and interact during the lifecycle of a Pixel Streaming application deployment, from deploying a new Pixel Streaming application to assigning it a new version using a simplified canary deployment strategy:

  1. First, an application is created:

    A single application entity with no associated version entities yet

  2. An initial version is created from a UE project and the data for this version of the application is uploaded to the Kubernetes cluster. The version is not yet active and the application is not yet deployed:

    A single application entity with one associated version entity

  3. The new version is to be active. This triggers the deployment of this version of the application by Scalable Pixel Streaming, and the application is now ready to accept connections from users:

    A single application entity with one associated Version entity, which is marked as active

  4. When a new version of the UE project is ready for release, a new version is created to represent it and its data is uploaded to the Kubernetes cluster:

    A single application entity with two associated version entities, the first of which is marked as active

  5. The newly uploaded version can now be set to active, which will deploy it and make it available to users. Note that this will terminate all existing connections of the application:

    A single application entity with two associated Version entities, the second of which is marked as active

  6. The administrator of the cluster or an automated system now monitors the behaviour of the new version to ensure it is stable. If the new version is deemed unstable, then the administrator can simply revert to version 1.0.0, otherwise, the active version can be left as-is and the old version can be safely deleted.

    A single Application entity with one associated Version entity, which is marked as active

  7. This cycle is repeated whenever any new versions of the UE project become ready to go live.

Version build process

When a new version entity is created and its data is uploaded to the Kubernetes cluster, Scalable Pixel Streaming performs a “build process” to transform the input data into a suitable form that can be used to deploy that version of the Pixel Streaming application.

The build process currently supports the following types of input data:

  • Existing image: an existing image that has already been built from the packaged files for the Pixel Streaming application and pushed to a remote container registry. The input data consists of the container image tag and the authentication credentials required to access the container registry. This can be a Linux container or a Windows VM image on supported cloud platforms.

The build process currently supports the following output formats:

  • Reference to existing Linux container image: creates a reference to an existing Linux container hosted in a remote container registry, without copying its data. The output data is simply a copy of the input data.