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

initial deployment rewrite

Browse Source
This commit is contained in:
Jordan McClintock 2022-03-18 15:40:35 -05:00
parent f978121c93
commit cadfbb0388
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\nFollowing the umbrella structure in the Big Bang chart, we can create the templates under a `podinfo` directory (under the templates dir).\n\nNote: there are many ways to accomplish this task - the podinfo directory under the templates directory most-accurately represents how the umbrella structure works.\n\n### Minimum Requirements\n- namespace resource\n- git repository resource\n- helm release resource\n- virtual service resource\n\nThis would meet the bare minimum requirements.\n\n### Additional Content\n- values file (a helper generates a secret resource from this)\n\n## Success Criteria\nIf we run the `helm upgrade` command against the modified Big Bang helm chart, it should deploy the podinfo chart (if properly enabled) with the ability to access/resolve the application through the `Ingress Gateway`.",
"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",
"x": 360,
"y": 620,
"wires": [