In App Platform, does each service instance have a number, and is it possible for the application within that instance to read that number?

For instance, if there were 3 shard instances, they would be named shard-0, shard-1, and shard-2, and an application could read that name through an environment variable.

In the Insights panel, for the CPU and memory graphs, there is a legend of the format service-0, service-1, and so forth, which would seem to suggest that there is an instance number available in some part of App Platform. However, having read through the known environment variables, none of them are described as exposing the instance number.

Any help would be much appreciated.

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
1 answer

App Platform containers do not have a stable ordinal number associated with them. Each instance does however, have a longer, unique hostname. That is typically of the form component-name-XXXXXXXXX-XXXX. The format of this name is not guaranteed, but we do guarantee that it is unique against all containers running at a given time.

The ordinal values on the Insights is generated for display, but the values may be reassigned as new containers are added or removed.

One important note, the App Platform does “make before you break” style deployments to avoid downtime. This means when a new deployment is being rolled out (because of git push, settings change, or maintenance) we will create a new container instance, wait for it to become healthy, and then destroy one of the old instances. We repeat that process until no old containers remain. In practice this means if you’re configured to run 3 instances, you may momentarily see 4 instances running during the rollout. You are not billed for the extra instance. Applications which assume AT MOST ‘replica_count’ containers are running may experience issues.

Can you describe a bit more about the problem you’re trying to solve? We may be able to offer some advice.

  • I was curious whether it’s possible to host a scaled Discord bot on App Platform.

    Discord bots are scaled through what Discord terms sharding. This allows a bot to scale horizontally, with each bot client essentially declaring its shard number to the Discord API. Thus, each instance of the bot client must somehow determine its shard number.

    I recall that this is possible in Kubernetes with StatefulSets.

    • Ok that makes sense to me. We don’t currently offer an equivalent to the StatefulSet. I think the best solution would be to run three-distinct service (or worker if they don’t need ingress) components. You could customize the run command or env variables to indicate which shard the component is responsible for. From my reading of the documentation you linked, it sounds like the make-before-break update strategy should be safe with this protocol, but you should verify that.