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.
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
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.
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.
