I don't care about "proper organization" as much anymore since I've learned that corporate deployment operations will always be a beautiful bespoke disaster anyway. So just do what's easiest to maintain.
NOTE: currently the most active workspace cluster is aws/us-east-2/sandbox/cf-for-k8s-demo
k8s
deployments. These are for experimentation and demonstrations of stitching together systems. Emphasis on being as declarative and git
-driven as technically possible. Emphasis on being kind
/minikube
-friendly. Emphasis on accounting for multiple environments. Trying to work out ideas of promoting from environment to environment. Conceptually this focuses on clusters as a whole; deployments might be built, configured, and applied independently, but the end-result emphasizes the cumulative result of everything happening on the cluster.
Ideally, the discrete processes of building, configuring, and applying will be self-contained as much as possible and not require significant additional steps which wouldn't be possible to re-create on an individual's workspace. Ideally, a CI/CD system (like concourse
, etc.) would really only be an orchestrator, rather than used to apply additional functions or values which aren't otherwise captured here in this repository. This makes it easier to predict and reproduce what build outputs will look like without having significant dependance on a specific system (like spinnaker
, etc.); it means that whatever system is used (like ... jenkins
? etc.?) just has to orchestrate the different "functions", like "build", "configure", "apply", etc. That makes it much easier to swap out, and reproduce what's happening locally. We'll see to what extent that's possible, but that's the ideal state.
Let's say we want to use cert-manager
to generate lets-encrypt
certificates for cf-for-k8s
as part of it's use of istio
. We need cert-manager
on the cluster. There's a dependency. Let's say we want to use harbor
for image storage for cf-for-k8s
; there's a dependency. Let's say we want to use an istio
virtual-service
for harbor
; there's a dependency. Let's say we want to use external-dns
to have all the dns used by all these components; there's a dependency. Let's say we want to use the crds
used by prometheus-operator
to monitor other components via a service-monitor
and such; there's a dependency. Let's say we want to use minibroker
on the cluster for cf-for-k8s
to provision services in the cf marketplace
; there's a dependency.
And so on and so forth.
We care about the aggregate state because it's impractical to think about everything as discretes. And that's okay. Individual systems should be discrete to allow better cross-system usage, for individual systems to be configured and upgraded on their own, for more flexibility in use-cases, and just in general for better conceptual cognitive mapping. But to think that harbor
can exist independently from cf-for-k8s
can exist independently from a credential manager (e.g. cert-manager
) is impractical.
The configuration of, and ordering of, these discrete deployments working together is important when they're aggregate together to all live together on the cluster.