frodovdr/node-red
1
0
Fork 0
mirror of https://github.com/node-red/node-red.git synced 2025-03-01 10:36:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

quick edit

Browse Source
This commit is contained in:
Jordan McClintock 2022-03-18 15:58:21 -05:00
parent cadfbb0388
commit 177e9985b0
No known key found for this signature in database
GPG Key ID: 1D01FAEF2A11C46E
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
data/flows.json
View File

@ -438,7 +438,7 @@
"type": "task",
"z": "c86af370eff94afa",
"name": "Deploy podinfo as a Flux HelmRelease",
"info": "# Flux helm release reconciliation\n\"Big Bang follows a GitOps approach to configuration management, using Flux v2 to reconcile Git with the cluster. Environments (e.g. dev, prod) and packages (e.g. istio) can be fully configured to suit the deployment needs.\"\n\n## Prerequisites\n- Remove all prior content for podinfo from your cluster. \n\n## Recommended Reading\n- https://repo1.dso.mil/platform-one/big-bang/bigbang/-/blob/master/README.md\n\n## Objective\nYou will be creating a kustomize directory and applying it through `kubetcl -k` or `kustomize build ...`. This folder should not be in the bigbang charts directory or any subdirectory.\n\nThis can be accomplished without kustomize if preferred. The only requirement for how is that you do not modify the bigbang chart.\n\n### Minimum Requirements\n- kustomization\n- Namespace\n- GitRepository\n- HelmRelease\n- VirtualService\n\nThis would meet the bare minimum requirements.\n\n## Recommended Requirements\n- Setting podinfo values via kustomize\n - This can be done via `spec/valuesfrom` in `HelmRelease`\n - An example would be using a `configmap` that kustomize created with `configMapGenerator`\n\nThere is one 'issue' with the above, kustomize doesn't know about HelmRelease since it's a CRD. When kustomize creates a configmap it appends a hash to it based on the contents of the resource, so the references to the configmap need to have the hash as well. With base k8s resources kustomize will automatically change the references. With a HelmRelease though, as stated above, it won't know what to change. This is remedied by using a kustomize configuration file that includes `nameReference`. This syntax/usage is described at https://github.com/kubernetes-sigs/kustomize/blob/master/examples/transformerconfigs/README.md#name-reference-transformer.\n\n## Success Criteria\nAfter applying the resources to the cluster, podinfo should be deployed and accessible through the istio gateway via podinfo.bigbang.dev",
"info": "# Flux helm release reconciliation\n\"Big Bang follows a GitOps approach to configuration management, using Flux v2 to reconcile Git with the cluster. Environments (e.g. dev, prod) and packages (e.g. istio) can be fully configured to suit the deployment needs.\"\n\n## Prerequisites\n- Remove all prior content for podinfo from your cluster. \n\n## Recommended Reading\n- https://repo1.dso.mil/platform-one/big-bang/bigbang/-/blob/master/README.md\n\n## Objective\nYou will be creating a kustomize directory and applying it through `kubetcl -k` or `kustomize build ...`. This folder should not be in the bigbang charts directory or any subdirectory.\n\nThis can be accomplished without kustomize if preferred. The only requirement for how is that you do not modify the bigbang chart.\n\n### Minimum Requirements\n- Namespace\n- GitRepository\n- HelmRelease\n- VirtualService\n\nThis would meet the bare minimum requirements.\n\n## Recommended Requirements\n- Setting podinfo values via kustomize\n - This can be done via `spec/valuesfrom` in `HelmRelease`\n - An example would be using a `configmap` that kustomize created with `configMapGenerator`\n\nThere is one 'issue' with the above, kustomize doesn't know about HelmRelease since it's a CRD. When kustomize creates a configmap it appends a hash to it based on the contents of the resource, so the references to the configmap need to have the hash as well. With base k8s resources kustomize will automatically change the references. With a HelmRelease though, as stated above, it won't know what to change. This is remedied by using a kustomize configuration file that includes `nameReference`. This syntax/usage is described at https://github.com/kubernetes-sigs/kustomize/blob/master/examples/transformerconfigs/README.md#name-reference-transformer.\n\n## Success Criteria\nAfter applying the resources to the cluster, podinfo should be deployed and accessible through the istio gateway via podinfo.bigbang.dev",
"x": 360,
"y": 620,
"wires": [