Big Bang Umbrella example for Zarf

[RothAndrew]

DI2E is going away, which means people are looking around for alternatives. Let's create a Zarf example that shows Big Bang's capabilities as a fully fledged software factory.

Acceptance Criteria:

1. Needs a decent set of end-user tools to stand out as something that actually looks like a software factory.
   • Proposed: GitLab, GitLab Runner, SonarQube, Mattermost
2. Needs to be able to run on a developer laptop. The Big Bang Core example runs in a VM with 6 vCPUs and 20GB of RAM. Would like to keep to that constraint. Edit: Instead of this we decided to leave everything turned on with a big note that says they should turn things off (with instructions on how to do so) if they are running on a dev laptop

Notes:

1. Doesn't need to run all of the compliance tools since it is a demo. We can turn off things like OPA Gatekeeper and maybe even the logging stack to save space. We should keep Istio on though since that's the ingress for everything. Edit: See above

EDIT:
After spending some cycles trying to create an example package that has a KeyCloak instance running inside of the same instance as everything else we ran into some technical complications because the default standard that BigBang has had around KeyCloak was to always have it running in a separate cluster. Because of that, we decided it would be best to keep the flow of development steady and merge in what we have currently working for the Umbrella/SoftwareFactory example and create a future issue on creating a more robust example including KeyCloak once we have the ability to work with multi-clusters with Zarf. One new issue tracking some of this effort is #241.

[RothAndrew]

@YrrepNoj and/or @matt-strong this would be a great one to work on that would give exposure to a ton of stuff, including how Big Bang works. Would be a great one to pick up, and it's something our customer cares about so it's decently high priority.

[jeff-mccoy]

I do think we need to have a real multi-cluster / multi-node example for this to be usable. You wouldn’t deploy all that into a single node instance. There are some things we’d have to work through from a demo perspective specifically around intra-vm comms or pushing it all down into something like kubevirt.

[RothAndrew]

I do think we need to have a real multi-cluster / multi-node example for this to be usable. You wouldn’t deploy all that into a single node instance. There are some things we’d have to work through from a demo perspective specifically around intra-vm comms or pushing it all down into something like kubevirt.

That would be great, it just means we need the k8s native apply stuff to be done first right?

[RothAndrew]

We can always start off with single node and expand once we have the capability to

[RothAndrew]

@jeff-mccoy would we need #17 to do the multi-node example as well, or will #16 be enough?

Edit: Had the numbers swapped around incorrectly

[jeff-mccoy]

Actually there isn’t a blocked for doing that now. You could spin up two single node k3s clusters for the example and have one deploy the gitops service and the other deploy flux to point to that and you’d be good. Basically it’s the current Big Bang example but not single-cluster. The challenges you’ll hit will be managing the pki trust between the clusters for flux / containerd. A further more complex example might be one zarf cluster and one eks or something like that with flux on it deployed from the zarf cluster. You wouldn’t need zarf to deploy flux, you could push the flux images to the zarf cluster and use the terraform Big Bang to deploy flux so long as we could point the images back to the zarf cluster.

[RothAndrew]

@YrrepNoj you're working this now right? If so can you assign yourself and move it to the Now column?

[YrrepNoj]

Closing as there is a version of BB-Umbrella in master and #272 captures the next step of expected work for this example package.