Frsca deployments using GitOps tooling

[rigzba21]

Hi all, I'm new to the project and excited to get involved!

Is there any interest being to deploy the Frsca stack into an existing cluster via a GitOps tool like Flux or ArgoCD?

I know that considering operators for deploying Frsca was discussed in the latest community call, which would also be an excellent way to deploy Frsca!

I'm happy to help out wherever I can, and again, I'm excited to get involved in the project!

[pxp928]

Hey @rigzba21! Yes I think that would be a great addition. Currently we are using mostly the MakeFile to deploy out to the cluster. GitOps would also help with the future plans to have a running cluster with Frsca deployed where we can start building out other projects. GitOps might be a good solution for the time being while we consider more about the operators piece.

[rigzba21]

Notes from the community call (June 1, 2022)

High-Level GitOps Resource Groups

• Developers: Pipelines Deploy
• Infrastructure: Bootstrap/Initiate the build env infra

[rigzba21]

What are the thoughts on an example gitops directory for deploying the frsca components? (the flux2-kustomize-helm-example repo comes to mind) cc @trmiller

[ChrisJBurns]

I do this with an accelerator that use on projects I use Terraform to provision the clusters and then using the Helm resource i install Flux inside the clusters. The Flux agent will then start automatically installing all of our infra and tooling (istio, cert manager, tekton, vault etc etc). Works very nicely.

[ChrisJBurns]

@pxp928 I don't actually mind giving this a go? We are in the process of open-sourcing our internal accelerator and would love to contribute to this repo if possible? There really are incredibly large similarities and I somewhat wish I found out about FRSCA sooner than I did because I probably would have poured most of my effort (I'm talking over 1,000 hours) into this project instead and used it as a base internally and built further customisations on top of it that were representative of our needs.

Just to add more, our accelerator which is essentially a software factory to get people started in delivering fast, from nothing to full working environment with a test Java service (that is built using the CI tool we include in the accelerator and pushed into Harbor that is also hosted in our tooling cluster) deployed takes around 30 minutes, all you need is a Cloud account. GitOps is a huge factor of all of that automation. The second the Kubernetes clusters are active and running, Flux gets to work and installs the tooling (in order of course, Cert Manager, Istio, Istio Gateway, etc etc).
I've explored building an Operator to install tooling, however, I felt that using the Charts that each tool already has is easier and less to maintain. However the need for an Operator for us is the post-installation tasks such as initialising Vault, creating Keycloak service accounts to enable OIDC logins for the tooling (CI tool, Vault, Grafana, Harbor) etc. I wrote a CLI tool to do this that runs as a Job in the cluster after all tooling is installed and healthy, but an Operator is definitely the better way of doing this longer-term.

Where things get messier is when you want to install things on the Cloud managed Kubernetes services. I've found that as long as you create the perfect abstraction layer (with tools like Flux) you don't have to pollute your initial setup scripts with Cloud specific code.

[pxp928]

Hey @ChrisJBurns, that would be great! It would be cool to see how your accelerator and FRSCA line up