Better documentation for setup workflow

[neeraj-ec]

I feel the initial setup documentation lacking some real world scenarios for production deployment.

• Creating a store is one time job. I can not code it into my usual backend project. For example we have a NodeJs (NestJs) backend API and it is being deployed on k8s. Now if I code creating a store somewhere in API startup, each time I deploy a new version of my backend API, it will run the create store code which is not desirable.
• Similarly writing the authorization model is also one time job and I can not code it into my usual API project.

There is no documentation or discussion about how to handle it elegantly on production environments. It would be really helpful if we have some guide around it, specifically in docker enabled environments like k8s.

This is how I'm planning to do it, Since OpenFGA will be deployed inside a k8s cluster without external access.

• Create a separate NodeJs project with OpenFGA sdk implemented.
• Create a test store
• Load the authorization model from json/dsl.
• Load test tuple data
• Run assertions.
• If everything work fine,
  • Delete test store
  • Create actual store.
  • Load the authorization model in actual store.

Now this service created a store for me, I haven't found a nice solution to communicate/store storeID. Though it is onetime job, the dirty heck I used is read it from pod logs.

Am I missing something basic here? Or it has to be like this only on k8s of in fact any docker enabled environment? How Auth0 handles it internally?

Also is there any kubernetes deployment script or helm chart available somewhere in the documentation? I searched thru and haven't found anything.

[rhamzeh]

Hi @neeraj-ec

Fellow contributors will provide a more in depth answer, but to give you a quick summary.

How you are thinking about it is mostly right in terms of deploying the model and testing it in a separate process.

We generally recommend you run and test your model (preferably in a CI job separate from your backend deployment) and you only merge to main once the tests have passed.

Once merged to main, you can then update your backend with the newly generated authorization model ID through whatever configuration management system works best for you.

One thing to note is: In production, you will not be constantly creating a new store - you will create the store once and update the model for that store if you need to.

Now the flow above may not be ideal for your use-case, so we collaborate to come up with a way to make that process easier for you.

Can you walk us through how you are deploying? Do you have a configuration management solution in place?

Regarding the helm chart, we don't have an officially supported first-party one yet, however some community members have OSSed their own that you can use: https://github.com/AlexandreBrg/openfga-helm

[neeraj-ec]

Thanks @rhamzeh for quick answer. We are using Github action for CI/CD pipeline.
Github action compile the code and make the docker image and push it to our container registry.
From there the process is manual for now. We pick the latest image tag, change the kubernetes deploy definition and apply it via kubectl.

Application Configurations are managed by kubernetes configMaps.