Microservices - Publishing
Overview
Beamable Microservices can run locally on a developer's machine, but when it comes time to publish a game, the services can be published to Beamable Cloud. Microservices running on Beamable Cloud can be viewed with the Beamable Portal.
Beamable uses the concept of Realms to separate development environments. Each realm is an isolated environment that has its own content, Microservices, and players. When Microservices are published, they are published to the currently selected Realm in the Unity editor.
Publish vs Promote
In this guide, we are talking about "Publishing" Microservices from Unity. However, once Microservices are published to a realm, they can be "Promoted" to a second realm via the Beamable Portal. Promoting a realm's Microservices does not follow all the same steps as described in this document.
After Microservices are published from Unity, Beamable will take a few moments to start the services.
How To Publish
These steps describe how to publish the Beamable Microservices. The Publish Process providers further detail.
| Step | Detail |
|---|---|
| Open Microservice Manager, and click "Publish" |  |
| For each service, decide if the service should be On, or Off. |  |
| Optional: For each service, include a comment describing the reason for the publication. |  |
| Optional: Include a comment describing the reason for the publication of all services. |  |
| Click the Publish button to start the publication |  |
The Publish Process
The publish window has 4 main elements,
| # | Name | Description |
|---|---|---|
| 1 | Realm | The realm label indicates which Beamable realm the Microservices will be published to. |
| 2 | Flow | The flow describes the current state of the publication process. |
| 3 | Service Table | The service table will list all Microservices and Microstorages. |
| 4 | Log | As the publication process happens, the log will output the build and publish log progress from each service |
Publish Flow
The publish process has a 4 staged flow. The stages are described below.
| Step | Description |
|---|---|
| Setup | First, the developer selects which services to turn On/Off, and may optionally provide any comments for individual services, or for the entire publication. |
| Build and Verify | Then, each service will go through the Build and Verify step. During the Build , the Microservice runs a Docker build to prepare the Microservice Docker image. The build happens without using Hot Module Reload, which is a feature turned on for development by default. Next, the Microservice is Verified. The built image is started as a Docker container, and the publication process waits until the local Microservice passes its internal health checks. Verification is meant to check that the Microservice can compile, start, establish type information, and create a healthy connection to the Beamable Cloud. Verification is not meant to check that a developer's custom functionality works as intended. During verification, Microservices do not run custom [InitializeServices] block segments, which means custom startup logic will not execute during Verification.Microstorage objects do not need to be built or verified, so this step will be skipped for Microstorages. |
| Upload | Next, each service is uploaded to Beamable's Docker Cloud registry. This step can take awhile, especially the first time each service is published. Subsequent publications should happen faster. Microstorage objects do not need to be uploaded, so this step will be skipped for Microstorages. |
| Manifest Upload | Finally, after all Microservices have been built, verified, and uploaded, the final step is to commit a single manifest that describes the final state of the realm's Microservices. If this step isn't executed, then no services will be started or stopped on the realm. |
Service Table
The service table contains a row for each Microservice and Microstorage. The columns are described below.
On/Off
Every time a publication is made, all Microservices and Microstorages will be published. However, a service can be published in an "off" state. When a service is published as "off", Beamable will make sure that the service is not running in the realm. When a service is published as "on", Beamable will make sure that the service is started or upgraded with the new version of the service.
You always publish all of your services, even the "Off" ones!
Remember, every time you publish services, every single service will take on the latest On/Off value in the publication. This means that services that are turned Off in the publish window will be turned off on Beamable Cloud.
Microstorages have special rules for being turned On/Off. If a Microservice is depending on a Microstorage, and the Microservice is On, then the Microstorage must also be On. The publish window will prevent Microstorages from being turned Off that are referenced on by enabled Microservices.
Name
The name of the Microservice or Microstorage. There is also an icon that describes the type of the service.
Known Location
There are two locations where a Microservice could be running; on a developer's local machine, or remotely on the realm hosted by Beamable's Cloud. Before a publication happens, it is unlikely that any Microservices are running on the given realm, and therefor, the only location of the service is "Local". However, after a publication happens, the Microservice is running on the remote realm, and therefor is known to be "Remote" as well. Additionally, it is possible for developers to access a realm with running services, but without having the source code for the relevant Microservices. In this scenario, the "Known Location" is "Remote", and only "Remote".
When a Microservice is listed as "Remote" only, it cannot Build and Verify or Upload . The developer still has the decision to control the Microservice's comment or On/Off status.
Dependencies
Microservices may depend on Microstorage objects. The "Dependencies" column in the publish window informs the developer that these dependencies exist. However, the publish window is not the time or place to change these dependencies. If a developer wants to disassociate a Microservice from a Microstorage, they should do so in the Dependencies window accessible from the Microservices Manager.
Comments
Service comments allow the developer to mark services with a version, an explanation, an author, or whatever other minor information could be useful in the developer's workflow. These comments may be read later on the Beamable Portal.
Status
As each service progresses through the Flow, the status will change to reflect the latest status.
Logging
By default, Microservices use a DEBUG log level when published. These logs can be viewed in the Portal. However, starting with Beamable 1.15.0, if you want to see even more detailed VERBOSE logs, or quiet your logs to only show WARNINGS or ERRORS, it is possible through Realm Config. In the Realm Config page of portal, create a new namespace called "service_logs". Then, create an entry in the "service_logs" namespace for each service you want to change the log level for. The entry should be the name of the Microservice. The value should be one of the following, "verbose", "debug", "info", "warn", "error", or "fatal".
If you configure the service with "fatal", then only log messages at the "fatal" level will be shown. However, if you configure the service with "debug", then all log messages with a log level of "debug" or greater will be shown, including "debug", "info", "warn", "error", and "fatal".
Updated about 1 year ago