Question of correct procedure to publish Temporal to Production Kubernetes

REF the advice given via documentation: Quick install Temporal Server for testing and local development | Temporal

There are two ways to quickly install and run the Temporal Server:

  • Docker: Using docker-compose makes it easy to develop Workflows locally.
  • Helm Charts: Deploying the Server to Kubernetes is an easy way to test the system and develop Workflows.

We do not recommend using either of these methods in a live (production) environment.

I want to confirm the correct way to publish to production via Kubernetes.

I would have thought the helm approach would have been the correct one, is this not the case, or is the documentation out of date?

What is the correct way to publish to production?

1 Like

Hi,
I have the same use case as mentioned above. I tried creating my own k8s deployment, but my temporal-web container isn’t able to resolve dns to the server. Any help here would be appreciated.

answered over here: Kubernetes deployment for production - #2 by derek

For a little more information:

If you already deploy using helm to production environments, you certainly can use our helm chart but with the very important caveat that you should disable all the additional dependencies (cassandra, es, prometheus, etc.) and only deploy temporal services and use all external dependencies. Doing this would produce a production quality deployment.

Our helm chart setup for cassandra is very much not production quality (and we feel it is not possible to offer a helm deployment of a production quality cassandra because it’s way too complex).

The database layer is especially important as it is where state is maintained. We do not recommend running stateful workloads (databases) in the kubernetes cluster with your temporal deployment. And strong care should be taken if running databases in kubernetes at all.

The situation would be more clear if we broke our helm chart up into two: one chart that only installs temporal and another chart that consumes the first as well as dependencies for dev/test. That way there would be no room for confusion. This is an eventual goal and PRs are welcome :slight_smile:

But we absolutely prefer explaining all this over having a user mistakenly depend on parts of the helm chart that are only there for dev.

2 Likes

Hi Derek,

I appreciate the extra effort you made that does help me understand the reasons the healm-chart method has some concerns.

For the record, this is the approach that we’ve taken as well.
Everything related to Elasticsearch, state DB, etc. is external.

In terms of DB however we had to move away from Cassandra unfortunately since AWS is not offering a fully compatible solution right now (or at least that was my understanding from other conversations in Slack). So we went with Postgres via AWS RDS.