aegershman / deployments Goto Github PK

more declarative config is good

wip

using local copy of chart for now #12

see: #155
see: #158

because ECS isn't playing very nice with kpack and cf-for-k8s; let's see about getting harbor setup internally

https://github.com/coreos/prometheus-operator/releases/tag/v0.40.0

rather than leveraging built-in self-deployed database; not making a judgment about what is better, just talking about demonstrating it

https://github.com/cloudfoundry/overview-broker

title

as the title implies

https://github.com/cloudfoundry-incubator/cf-operator/releases/tag/v4.4.5

let's try it out

Best way to promote from one env to the next?

title

especially in the case of harbor; any way to have that be exposed privately but still reap the benefit of shared dns? we'll see, I imagine it's a matter of networking rules

how do we consume services which are packaged ONLY in helm? which kind of sucks, but it is what it is-- can we template it, store it as _rendered, then leverage ytt and kapp to deploy it? presumably we could, since the kapp-controller can almost definitely do it; but is there a better way to do it that doesn't involve relying on a controller? e.g. doing it more locally?

go learn

https://istiobyexample.dev/ingress/

instead of having to manually check upstream artifacts, be able to automate determining if new versions are available and can be pulled

then built

then the question of how to promote them

This entirely a theory, but I'm guessing it has to do with how routecontroller creates virtualservices for app instances depending on the route names associated and the decision whether to have a gateway association of mesh to the virtualservice based on whether the route domain is listed as internal; if only the istiogateway gateway association rules are applied, and mesh is left off, then from what I understand, no amount of communication rules between a different namespace and the pods hanging out in cf-workloads will matter-- in those cases, either the requests from the other namespaces go through the istiogateway as the ingress (somehow I guess), or some sort of gateway rule set allows for communication from other namespaces. I have no idea if that's right; to be honest I'm just commenting here somewhat as a note-taking device. that's so interesting.

folder structure and such

best way to organize credentials

see:

• https://github.com/bitnami-labs/sealed-secrets
• https://github.com/k14s/ytt/blob/develop/docs/injecting-secrets.md
• https://github.com/k14s/secretgen-controller

see: #85 but it's not quite the same

service brokers on cf-for-k8s in aws

https://github.com/open-policy-agent/opa
concourse/concourse-bosh-release@644adba

make stratos happen

related to #154

why use nodeport

these pertain to templating, helm itself, and to helm charts:

• helm template doesn't pass the namespace in the same form and fashion that helm install with a namespace qualifier does

• external-dns has empty annotation keys which result in malformed yaml, e.g. annotations: as opposed to annotations: {}. Just kind of annoying

• https://github.com/helm/helm/issues/ 7774

• https://github.com/helm/helm/issues 5465

• https://github.com/helm/helm/issues/ 3553

• templating helm which has requirements, like with concourse (Error: found in Chart.yaml, but missing in charts/ directory: postgresql) -- this can be solved with vendir by leaving out the requirements.yml and lock

see: #154