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
node-red/data/flows.json
Rob McElvenny 209f038174 add small troubleshooting steps for newer folks!
2023-04-24 14:05:59 -04:00

1094 lines
47 KiB
JSON
Raw Blame History

[
{
"id": "5ca0ee0f1a963b2c",
"type": "tab",
"label": "(Non-Engineer) Unicorn Getting Started Guide",
"disabled": false,
"info": "",
"env": []
},
{
"id": "c86af370eff94afa",
"type": "tab",
"label": "(Engineer) Unicorn Getting Started",
"disabled": false,
"info": "Guide to an incoming Unicorn to get their technical hoofs wet. The guide takes you through familiarization with local K8s clusters, bigbang, and zarf.",
"env": []
},
{
"id": "eb7909bcf5fcaf8a",
"type": "tab",
"label": "Kubernetes to Big Bang",
"disabled": false,
"info": "",
"env": []
},
{
"id": "6a6a274a201cb47d",
"type": "tab",
"label": "Baffles",
"disabled": false,
"info": "Baffles is an integration of Kubevirt with Big Bang. Kubevirt enables the operation of virtual machines or non containerized applications on top of Kubernetes. Integrating Kubevirt with Big Bang allows leveraging the declarative, gitops baseline and its secure runtime configuration. Big Bang is a declarative, continuous delivery tool for core DoD hardened and approved packages into a Kubernetes cluster. Big Bang follows a GitOps approach to configuration management, using Flux v2 to reconcile Git with the cluster.",
"env": []
},
{
"id": "0ac7681ed1c2bc4b",
"type": "subflow",
"name": "Kubernetes",
"info": "Kubernetes is an open source container orchestration engine for automating deployment, scalling, and management of containerized applications. [source](https://kubernetes.io/docs/home/)",
"category": "",
"in": [
{
"x": 140,
"y": 40,
"wires": [
{
"id": "73521b98841c6355"
}
]
}
],
"out": [
{
"x": 550,
"y": 630,
"wires": [
{
"id": "752d2d1fc700d27e",
"port": 0
},
{
"id": "c53965f3ddc770ad",
"port": 0
},
{
"id": "e902145181ebd724",
"port": 0
},
{
"id": "418551f904d62b20",
"port": 0
}
]
}
],
"env": [],
"meta": {},
"color": "#DDAA99"
},
{
"id": "56bd5f348afad14f",
"type": "subflow",
"name": "Golang",
"info": "",
"category": "",
"in": [
{
"x": 540,
"y": 60,
"wires": [
{
"id": "10a24d4bdf2a0f02"
}
]
}
],
"out": [
{
"x": 540,
"y": 590,
"wires": [
{
"id": "50a4c6a1e304101c",
"port": 0
}
]
}
],
"env": [],
"meta": {},
"color": "#DDAA99"
},
{
"id": "13374ec618504763",
"type": "subflow",
"name": "Big Bang",
"info": "",
"category": "",
"in": [
{
"x": 50,
"y": 30,
"wires": []
}
],
"out": [
{
"x": 160,
"y": 30,
"wires": []
}
],
"env": [],
"meta": {},
"color": "#DDAA99"
},
{
"id": "73521b98841c6355",
"type": "resource",
"z": "0ac7681ed1c2bc4b",
"name": "Kubernetes",
"info": "# Description\n\n\n## Resources\n- https://kubernetes.io/docs/home/ ***\n- https://www.youtube.com/watch?v=VnvRFRk_51k \n- https://www.youtube.com/watch?v=X48VuDVv0do (long video, covers most topics in this flow)",
"x": 240,
"y": 130,
"wires": [
[
"90665185044d3fc2",
"ccf8bad6e9ebfb6a",
"4146a7d5608cc03b",
"418551f904d62b20"
]
]
},
{
"id": "90665185044d3fc2",
"type": "resource",
"z": "0ac7681ed1c2bc4b",
"name": "Kubernetes Objects",
"info": "",
"x": 700,
"y": 180,
"wires": [
[
"d810b83f64f0bc5e",
"0d309e7b063a4ce2"
]
]
},
{
"id": "ccf8bad6e9ebfb6a",
"type": "resource",
"z": "0ac7681ed1c2bc4b",
"name": "Kubernetes Networking",
"info": "",
"x": 440,
"y": 320,
"wires": [
[]
]
},
{
"id": "4146a7d5608cc03b",
"type": "resource",
"z": "0ac7681ed1c2bc4b",
"name": "Kubernetes Storage",
"info": "",
"x": 460,
"y": 220,
"wires": [
[]
]
},
{
"id": "418551f904d62b20",
"type": "resource",
"z": "0ac7681ed1c2bc4b",
"name": "Kubernetes App Manifests",
"info": "",
"x": 200,
"y": 270,
"wires": [
[]
]
},
{
"id": "0d309e7b063a4ce2",
"type": "resource",
"z": "0ac7681ed1c2bc4b",
"name": "Configurations",
"info": "",
"x": 650,
"y": 270,
"wires": [
[
"c53965f3ddc770ad",
"e902145181ebd724"
]
]
},
{
"id": "d810b83f64f0bc5e",
"type": "resource",
"z": "0ac7681ed1c2bc4b",
"name": "Deployments",
"info": "",
"x": 820,
"y": 270,
"wires": [
[
"752d2d1fc700d27e"
]
]
},
{
"id": "752d2d1fc700d27e",
"type": "resource",
"z": "0ac7681ed1c2bc4b",
"name": "Pods",
"info": "",
"x": 810,
"y": 420,
"wires": [
[]
]
},
{
"id": "c53965f3ddc770ad",
"type": "resource",
"z": "0ac7681ed1c2bc4b",
"name": "Configmaps",
"info": "",
"x": 530,
"y": 420,
"wires": [
[]
]
},
{
"id": "e902145181ebd724",
"type": "resource",
"z": "0ac7681ed1c2bc4b",
"name": "Secrets",
"info": "",
"x": 680,
"y": 420,
"wires": [
[]
]
},
{
"id": "447bce72e21d67db",
"type": "guide",
"z": "56bd5f348afad14f",
"name": "Learn Go",
"info": "Learn basic Go syntax, conventions and data types. Keep an eye out for the following concepts:\n\n- Structs\n- Pointers\n- Goroutines",
"x": 540,
"y": 250,
"wires": [
[
"bcc94caf6482eeed"
]
]
},
{
"id": "5ab88cc4881dc30e",
"type": "resource",
"z": "56bd5f348afad14f",
"name": "Learn Go With Tests",
"info": "Literally the **best** resource to learn Go: https://quii.gitbook.io/learn-go-with-tests/\n\nRecommend using this resource to learn basic Go concepts and sytnax",
"x": 290,
"y": 170,
"wires": [
[
"447bce72e21d67db"
]
]
},
{
"id": "bcc94caf6482eeed",
"type": "guide",
"z": "56bd5f348afad14f",
"name": "Build a Web App",
"info": "The goal of this section is to build a Go web app that will eventually get deployed in K8s. Recommend building at least 1 CRUD operation and adding a DB (with migrations to make life easier when spinning up DB pods down the line)",
"x": 540,
"y": 380,
"wires": [
[
"50a4c6a1e304101c"
]
]
},
{
"id": "93a8f10c220fc106",
"type": "resource",
"z": "56bd5f348afad14f",
"name": "Go Web Tutorials",
"info": "Birdpedia: https://hhwe.github.io/dev/golang/Build-a-web-application-in-Go.html\n\nTodo app: https://betterprogramming.pub/build-a-simple-todolist-app-in-golang-82297ec25c7d",
"x": 290,
"y": 290,
"wires": [
[
"bcc94caf6482eeed",
"95836a67ff9c5c4c"
]
]
},
{
"id": "95836a67ff9c5c4c",
"type": "resource",
"z": "56bd5f348afad14f",
"name": "DB Migrations",
"info": "https://github.com/golang-migrate/migrate",
"x": 290,
"y": 360,
"wires": [
[]
]
},
{
"id": "10a24d4bdf2a0f02",
"type": "comment",
"z": "56bd5f348afad14f",
"name": "Start Here!",
"info": "## Motivation\nThe purpose of this flow is to introduce Unicorns to Golang (or Go for short) with the goal of producing a small web app that can be deployed and integrated with K8s and/or Big Bang\n",
"x": 540,
"y": 150,
"wires": [
[
"447bce72e21d67db"
]
]
},
{
"id": "50a4c6a1e304101c",
"type": "guide",
"z": "56bd5f348afad14f",
"name": "Dockerize",
"info": "Create a Dockerfile for the Go web app, recommend using the the builder image pattern (utilizing multi-stage builds). \n\nYou can also try creating the image without using a builder pattern and seeing the (massive) size difference in image size.",
"x": 540,
"y": 520,
"wires": [
[]
]
},
{
"id": "a11809c78f2b406c",
"type": "resource",
"z": "56bd5f348afad14f",
"name": "Builder Pattern",
"info": "https://docs.docker.com/develop/develop-images/multistage-build/\n\nhttps://blog.alexellis.io/mutli-stage-docker-builds/",
"x": 290,
"y": 450,
"wires": [
[
"50a4c6a1e304101c"
]
]
},
{
"id": "8a7eebc511e2c773",
"type": "comment",
"z": "13374ec618504763",
"name": "Start here!",
"info": "## Motivation\nThe goal of this guide to introduce Big Bang tooling in a layered approach from the bottom up. That is, instead of installing Big Bang proper, the purpose is to learn a single tool used in Big Bang, integrate it with an application, observe the effects and then layer the next tool, etc.\n\nInspired by: https://github.com/defenseunicorns/bb-up",
"x": 270,
"y": 60,
"wires": [
[
"6018b32890e917d5"
]
]
},
{
"id": "6018b32890e917d5",
"type": "subflow:56bd5f348afad14f",
"z": "13374ec618504763",
"name": "",
"x": 270,
"y": 140,
"wires": [
[
"c3c92b9186f4ff8f"
]
]
},
{
"id": "c3c92b9186f4ff8f",
"type": "guide",
"z": "13374ec618504763",
"name": "Helmify",
"info": "## Prerequsities\n- You must have a containerized web app and database before starting this step\n\n\n## Goal\nCreate a Helm chart that describes the deployment of the containerized web app and database built in the previous step\n\n## Checklist\n- Create a Helm chart as described above\n- Use a ConfigMap / Secret for database configuration\n- Use K8s DNS resolution to point the application to the database",
"x": 270,
"y": 220,
"wires": [
[
"c0c9b74371c0c8c3"
]
]
},
{
"id": "8bf22775dd836668",
"type": "guide",
"z": "13374ec618504763",
"name": "Deploy with Flux",
"info": "## Goals\n- Install Flux on the K8s cluster\n- Deploy the Helm chart using Flux\n- Understand pros/cons of using Flux bootstrap vs other installation methods\n- Understand pros/cons of deploying with a HelmRelease vs Kustomization\n\n## Checklist\n- Install Flux on the cluster (explore [bootstrap](https://fluxcd.io/docs/cmd/flux_bootstrap/) vs non-boostrap approaches)\n- Create a [GitRepository](https://fluxcd.io/docs/components/source/gitrepositories/)\n- Deploy using a [HelmRelease](https://fluxcd.io/docs/components/helm/helmreleases/)\n- Deploy using [kustomize](https://github.com/kubernetes-sigs/kustomize) + [Kustomization](https://fluxcd.io/docs/components/kustomize/kustomization/)\n- Explore how to reconcile a HelmRelease/Kustomization/GitRepository manually vs automatically\n- Create an `install-with-flux.yaml` that applies the Flux CRDs to the cluster\n - This enables you to create the cluster, install Flux and install all applications by applying this `yaml` file (ie. simplifying the deployment process)\n- Make changes to the Helm Values file, commit and push, and ensure the changes propagate to the cluster (do this for both the Kustomization and HelmRelease methods)\n - Really practice this! Flux has a lot of nuance that is easy to gloss over, and is the cornerstone of deploying and updating BB",
"x": 270,
"y": 360,
"wires": [
[
"43dd83070be818d8"
]
]
},
{
"id": "43dd83070be818d8",
"type": "guide",
"z": "13374ec618504763",
"name": "Add Istio Service Mesh",
"info": "## Goals\n- Install Istio\n- Install an Istio Ingress Gateway\n- Securely expose the app with its own hostname\n\n## Checklist\nWIP",
"x": 270,
"y": 440,
"wires": [
[
"5ad47fc6ed33a9fd"
]
]
},
{
"id": "c0c9b74371c0c8c3",
"type": "guide",
"z": "13374ec618504763",
"name": "Create K8s Cluster",
"info": "## Goal\nBuild a new K8s cluster using whatever tooling (K3d, Kind, EKS, etc) you prefer",
"x": 270,
"y": 290,
"wires": [
[
"8bf22775dd836668"
]
]
},
{
"id": "fa0f28fa8cd90972",
"type": "comment",
"z": "13374ec618504763",
"name": "Note",
"info": "Learning Go is optional for this guide, this is just a prime opportunity to get introduced! \n\n## Goal\nThe goal of this node is to have a containerized web app with a database ready to be deployed onto K8s. (Note if you are building a custom app, it is recommended to have at least 1 CRUD operation so you can generate some traffic when the time comes).",
"x": 450,
"y": 70,
"wires": [
[
"6018b32890e917d5"
]
]
},
{
"id": "5ad47fc6ed33a9fd",
"type": "guide",
"z": "13374ec618504763",
"name": "Kiali",
"info": "WIP",
"x": 270,
"y": 520,
"wires": [
[
"06fc4e182fa3fb81"
]
]
},
{
"id": "06fc4e182fa3fb81",
"type": "guide",
"z": "13374ec618504763",
"name": "Prometheus",
"info": "WIP",
"x": 270,
"y": 600,
"wires": [
[
"2f1d37dbad9f2fb0"
]
]
},
{
"id": "2f1d37dbad9f2fb0",
"type": "guide",
"z": "13374ec618504763",
"name": "Velero",
"info": "WIP",
"x": 270,
"y": 680,
"wires": [
[
"2f38309ec3176f7c"
]
]
},
{
"id": "2f38309ec3176f7c",
"type": "guide",
"z": "13374ec618504763",
"name": "TBD!",
"info": "Other tools will be added eventually\n- Jaeger\n- SOPS\n- OPA (Gatekeeper)\n- ...",
"x": 270,
"y": 780,
"wires": [
[]
]
},
{
"id": "40bfe328130d9c41",
"type": "guide",
"z": "c86af370eff94afa",
"name": "Deploy K3d",
"info": "Throughout this guide you will be using K3d to deploy and manage kubernetes instances.\n\n## Choose your platform\nThe preferred free VM software is [VirtualBox](https://www.virtualbox.org/); however, it is not compatible with M1 chips! So, if you are using an M1 Mac, we highly recommend you go with the [Cloud](#Cloud) option below\n\n### Cloud\nRecommend using an EC2 instance with the following specs:\n- AMI: Ubuntu Server (64-bit, x86)\n- Instance Type: t3a.2xlarge\n- 100 GB EBS\n- Security group rules for allowing web traffic\n\n### Local VM\nUse [Vagrant](https://www.vagrantup.com/) to spin up a VM with at least the following specs:\n- 10GB RAM\n- 4 CPU cores\n- An IP that can be [accessed](https://www.vagrantup.com/docs/networking/private_network#static-ip) from the host machine. \n\n### Local\nAny Docker installation except a non-WSL2 Windows installation will work with K3d natively.\n\n## K3d setup\n\nSetup instructions for K3d can be found at the link below.\n\nhttps://k3d.io/v5.2.2/\n\n## Cluster creation\n\nOnce you have a host for deploying a k3d cluster - you can configure a cluster for future nodes in this training.\n\nOne possible configuration would be a 3 node cluster with 1 server and 2 agents (to get started).\n\nAnother consideration is exposing applications after the cluster is running and apps have been deployed w/ services and ingresses.\n\nDepending on RAM/CPU availability, you may want to run 2 or more K3d nodes\n\nA possible configuration might look like:\n\n`k3d cluster create -s 1 -a 2 -p \"8081:80@loadbalancer\" dev-cluster`\n\n-s 1 represents 1 server node\n-a 2 represents 2 agent nodes\n\n-p \"8081:80@loadbalancer\" represents mapping 8081 on this k3d host to ports 80 internally.",
"x": 360,
"y": 130,
"wires": [
[
"691424f6cfd58372",
"1458b18889c13942"
]
]
},
{
"id": "691424f6cfd58372",
"type": "guide",
"z": "c86af370eff94afa",
"name": "Deploy a pod info application (with Kustomize)",
"info": "# Kustomize\n\n\"Kustomize is a command-line configuration manager for Kubernetes objects. Integrated with kubectl since 1.14, it allows you to make declarative changes to your configurations without touching a template.\"\n\n## Recommended Reading\n\n`https://www.mirantis.com/blog/introduction-to-kustomize-part-1-creating-a-kubernetes-app-out-of-multiple-pieces/`\n\nThe above tutorial can be run on the k3d cluster you have created. This is a much more complex example than the podinfo example you will deploy below.\n\n## Podinfo\n\n\"Podinfo is a tiny web application made with Go that showcases best practices of running microservices in Kubernetes\"\n\n### Deployment\n\nNavigate to `https://github.com/stefanprodan/podinfo`\n\nClone the repository to your local machine\n\nFrom within the cloned directory, we can execute kustomize through the built in functionality in `kubectl`.\n\n`kubectl kustomize ./kustomize`\n\nThis will return the built manifest for the application to be deployed. You can then deploy the application to the cluster through `kubectl apply -k ./kustomize`\n\n## Success Criteria\n\n- 2 podinfo pods in the target namespace (default if not specified)\n- A podinfo service\n- A horizontal pod autoscaler\n\nWe can port-forward this applications service and visit it in browser to confirm functionality.\n\n`kubectl port-forward service/podinfo 9898:http`\n\nThis port fowards the podinfo service `http` port (as defined in the service) to the 9898 host port.",
"x": 360,
"y": 200,
"wires": [
[
"2d66fece0a8f5fdf"
]
]
},
{
"id": "2d66fece0a8f5fdf",
"type": "task",
"z": "c86af370eff94afa",
"name": "Expose podinfo with an Ingress",
"info": "# Ingress\n\nIn the previous exercise, we deployed the podinfo application and confirmed functionality by visiting it in-browser through port-forwarding with kubectl. We can instead use an ingress and the default traefik ingress-controller to handle this functionaity more natively. \n\nOfficial k3d docs: https://k3d.io/v5.0.0/usage/exposing_services/\n\n## Ingress deployment\nDue to the cluster configuration that we executed in the first node (See the -p loadbalancer parameter). we can configure an ingress to expose the application, as is one of a few standard practices for exposing internal applications to external traffic.\n\n### Ingress template\n\nIngress docs: https://kubernetes.io/docs/concepts/services-networking/ingress/\n\nGiven the template from the docs/tutorial we can write an ingress to support this traffic.\n\n## Success Criteria\n\nAfter the ingress is deployed (and given you configured your cluster as described in the first node), then you should be able to access the podinfo application without port-forwarding at `http://localhost:8081` \n\n## Cleanup\n\nThis concludes this deployment of podinfo. You'll want to cleanup the resources we have created. ",
"x": 360,
"y": 270,
"wires": [
[
"52eb692e4c51108f"
]
]
},
{
"id": "52eb692e4c51108f",
"type": "guide",
"z": "c86af370eff94afa",
"name": "Create a podinfo helm chart",
"info": "# Helm\n\"Helm is the package manager for Kubernetes\"\n\n## Recommended Reading\nhttps://helm.sh/\nhttps://helm.sh/docs/intro/\n\n## Podinfo Helm Chart from Scratch\n\nTODO - Insert content for:\n- deployment\n- service\n- ingress\n- HPA\n* All templated from scratch\n\n## Deploy the official podinfo chart from local files\n\nPreviously we cloned the podinfo repository to our/a local machine. Under the root of the project there is a `charts` directory with a `podinfo` directory that contains the podinfo chart content.\n\n## Basic deployment\n\nLet's create a testing namespace for our target\n`kubectl create ns testing`\n\nWith Helm installed and our k3d cluster still running/configured, we can install the chart in it's vanilla form (without enabling any additional content).\n\n(From the charts directory)\n`helm install podinfo-dev ./podinfo -n testing`\n\nThis will deploy the chart which results in the deployment and service creation in the target namespace.\n\n## Customizations\nWe can inject exposed customizations as outlined in the README/values.yaml for the purpose of configuring the end package being suited for our needs.\n\nWe can make an edit to the values.yaml and upgrade our application.\n\nhpa:\n enabled: true\n \n`helm upgrade podinfo-dev -n testing ./podinfo`\n\nThis should result in an HPA being deployed to our namespace for the application.\n",
"x": 330,
"y": 340,
"wires": [
[
"5361df412a99db12"
]
]
},
{
"id": "5361df412a99db12",
"type": "guide",
"z": "c86af370eff94afa",
"name": "Deploy BigBang on a new K3d cluster",
"info": "# Big Bang\n\nUsing our machine with k3d, we can instantiate a development/prototype deployment of Big Bang.\n\n## Objective\n\nFollow the quickstart here:\nhttps://repo1.dso.mil/platform-one/big-bang/bigbang/-/blob/master/docs/guides/deployment-scenarios/quickstart.md \n\n## Dev Notes\n\nAs declared in the helm install command in step 10, the ingress-certs and default `domain` variables included in the Big Bang repository are meant for development. The DNS record for `*.bigbang.dev` is set for `127.0.0.1`. This is important for any routing is configured to use the `bigbang.dev` domain.\n\nIf you are not already, it is highly recommended that you use the previously mentioned cloud instance in the `Deploy K3d` step. Running BigBang locally will require at least similar specs to the [t3a.2xlarge](https://instances.vantage.sh/aws/ec2/t3a.2xlarge).\n\nIf attempting to run this locally on an M1 Mac manual changes to references in the quickstart file are required. As references to `amd64` dependencies will not resolve without being replaced with `arm64`.\n\n## Success Criteria\n\nAs noted in step 13 - the web UI's should be resolvable and accessible. All pods should be up and healthy (running). ",
"x": 360,
"y": 410,
"wires": [
[
"67415f95eb8ab46c",
"0571474bde3a7f49"
]
]
},
{
"id": "67415f95eb8ab46c",
"type": "task",
"z": "c86af370eff94afa",
"name": "Deploy podinfo helmchart in a bigbang cluster",
"info": "# Big Bang Extensibility\n\nUp to now - we have configured and deployed k3d clusters, we've used `kustomize` and `Helm` to orchestrate deploying `podinfo` to our cluster.\n\nWe then used flux and it's controllers to deploy bigbang (which is using helm and kustomize under the hood).\n\n## Recommended Reading\n\n## Objective\nNow we will look at extending the big bang deployment to include deploying the podinfo helm chart and ensuring the deployment architecture aligns with the Big Bang \"Core\" technologies.\n\nThis is a precursory step to follow-on nodes in this flow. \n\n## Execution\n\nClone the podinfo repository if not done already.\n\nCreate a namespace with the label:\n`istio-injection: enabled`\n\nDeploy the helm chart for the podinfo applicaiton as we have done previously.\n\n## Success Criteria\nDeploy the podinfo helm chart into your cluster that already has big bang deployed.\n\nThe application should come online and be able to be reached via `kubectl port-forward`\n\nContinue to the next node for extending this with Istio",
"x": 360,
"y": 480,
"wires": [
[
"9b8fdffdc9b5cc53"
]
]
},
{
"id": "9b8fdffdc9b5cc53",
"type": "task",
"z": "c86af370eff94afa",
"name": "Add Istio Virtual Service for the podinfo deployment",
"info": "# Istio VirtualServices\n\n## Recommended Reading\n\n- https://istio.io/latest/docs/reference/config/networking/virtual-service/\n\n### Example\n- https://repo1.dso.mil/platform-one/big-bang/apps/core/kiali/-/blob/main/chart/values.yaml#:~:text=istio%3A,kiali.%7B%7B%20.Values.hostname%20%7D%7D\n- https://repo1.dso.mil/platform-one/big-bang/apps/core/kiali/-/blob/main/chart/templates/bigbang/virtualservice.yaml\n\n## Objective\nWith the podinfo helm chart deployed (in it's basic state), we will look to leverage some of th technologies that Big Bang has reconciled and configured.\n\nBig Bang exposes cluster applications to external traffic through an Istio Ingress Gateway.\n\nVirtual services are then used to link kubernetes services to traffic from the ingresss gateways.\n\n## Execution\n\n\n\n## Success Criteria\nWrite a virtual service resource definition file for the podinfo application that was deployed as part of the last node.\n\nIf you add the `podinfo.bigbang.dev` endpoint to your hosts file, then it should be resolveable from the browser.\n\n## Solution\n<details><summary>show</summary>\n<p>\n\n```\napiVersion: networking.istio.io/v1beta1\nkind: VirtualService\nmetadata:\n name: podinfo\n namespace: podinfo\nspec:\n gateways:\n - istio-system/public\n hosts:\n - podinfo.bigbang.dev\n http:\n - route:\n - destination:\n host: podinfo.podinfo.svc.cluster.local\n port:\n number: 9898\n```\n\n</p>\n</details>",
"x": 360,
"y": 550,
"wires": [
[
"339481fd79e107a6"
]
]
},
{
"id": "339481fd79e107a6",
"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- 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": [
[
"e4d3465dcafc826f"
]
]
},
{
"id": "0f9889d8e9cb7edb",
"type": "guide",
"z": "c86af370eff94afa",
"name": "Play DOOM using ZARF",
"info": "# Zarf!\n\nZarf is a Defense Unicorns developed tool - please read about it below!\n\n## Recommended Reading\n- https://github.com/defenseunicorns/zarf\n\n\n## Objective\nUsing Zarf, we will follow the guide below in order to play DOOM.\n\nhttps://github.com/defenseunicorns/zarf/tree/master/examples/game\n\n## Success Criteria\nPackaging, Deployment and execution of playing DOOM from within the browser.",
"x": 360,
"y": 760,
"wires": [
[]
]
},
{
"id": "1458b18889c13942",
"type": "guide",
"z": "c86af370eff94afa",
"name": "Deploy and Access the Kubernetes Dashboard",
"info": "# Description\n> \"Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized application, and manage the cluster resources. You can use Dashboard to get an overview of applications running on your cluster, as well as for creating or modifying individual Kubernetes resources (such as Deployments, Jobs, DaemonSets, etc). For example, you can scale a Deployment, initiate a rolling update, restart a pod or deploy new applications using a deploy wizard.\"\n\n# Recommended Reading\n- [K8s Web UI Dashboard Guide](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/)\n\n# Install and Access\n- From your terminal run `kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.6.1/aio/deploy/recommended.yaml` to deploy the dashboard.\n- Follow the [User Creation](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md) instructions to create an account to access the dashboard.\n- Once you have the bearer token run `kubectl proxy` and head to the [dashboard login screen](http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/) where you can supply the token and access the dashboard\n\n# Unicorn SME(s)\n",
"x": 740,
"y": 200,
"wires": [
[]
]
},
{
"id": "6d2d525b92151db2",
"type": "resource",
"z": "c86af370eff94afa",
"name": "Kustomize",
"info": "https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/",
"x": 90,
"y": 130,
"wires": [
[
"691424f6cfd58372"
]
]
},
{
"id": "a25127e60aa3afac",
"type": "resource",
"z": "c86af370eff94afa",
"name": "Helm",
"info": "https://helm.sh/docs/intro/quickstart/",
"x": 90,
"y": 270,
"wires": [
[
"52eb692e4c51108f"
]
]
},
{
"id": "bd30d9f248bb244a",
"type": "resource",
"z": "c86af370eff94afa",
"name": "Big Bang",
"info": "https://repo1.dso.mil/platform-one/big-bang/bigbang/-/blob/master/docs/README.md",
"x": 90,
"y": 340,
"wires": [
[
"5361df412a99db12"
]
]
},
{
"id": "f17eae05b57f6a2e",
"type": "resource",
"z": "c86af370eff94afa",
"name": "Istio",
"info": "https://istio.io/latest/docs/",
"x": 90,
"y": 480,
"wires": [
[
"9b8fdffdc9b5cc53"
]
]
},
{
"id": "3a185c296c95de08",
"type": "resource",
"z": "c86af370eff94afa",
"name": "Flux",
"info": "https://fluxcd.io/docs/",
"x": 90,
"y": 550,
"wires": [
[
"339481fd79e107a6"
]
]
},
{
"id": "14c8378318de0a59",
"type": "resource",
"z": "c86af370eff94afa",
"name": "Traefix Ingress",
"info": "https://doc.traefik.io/traefik/providers/kubernetes-ingress/",
"x": 90,
"y": 200,
"wires": [
[
"2d66fece0a8f5fdf"
]
]
},
{
"id": "3e09e4de880b9956",
"type": "comment",
"z": "c86af370eff94afa",
"name": "Sparkle Engineer Getting Started",
"info": "https://www.cometchat.com/blog/programming-memes-for-developers",
"x": 610,
"y": 40,
"wires": [
[
"40bfe328130d9c41",
"1bf6704ac725ea82"
]
]
},
{
"id": "ef3535e20ee71428",
"type": "guide",
"z": "c86af370eff94afa",
"name": "Commit Signing (M1 macOS)",
"info": "# Prerequisites\nHave the homebrew package manager installed. Go to [homebrew's website](https://brew.sh/) for instructions on installation, setup, and usage.\n\n# Installing Backing software\n```\nbrew install gnupg pinentry-mac\n```\nThis command installs all necessary packages for commit signing.\n\n# Configure gnuPG\nCreate the `.gnupg` directory in your home folder.\n```\nmkdir -m 700 ~/.gnupg\n```\n\nCreate the `gpg-agent.conf` file.\n```\ntouch ~/.gnupg/gpg-agent.conf\nchmod 600 ~/.gnupg/gpg-agent.conf\n```\n\nWrite the configuration to the `gpg-agent.conf` file.\n```\necho \"pinentry-program /opt/homebrew/bin/pinentry-mac\" > ~/.gnupg/gpg-agent.conf\n```\nRun this so gpg-agent uses the updated config file\n```\ngpgconf --kill gpg-agent\n```\n\n# Configure Shell\nBy default macOS uses zsh. This guide assumes that you have not changed this, if you have change references to `.zshrc` to your shell's equivalent.\n```\necho 'export GPG_TTY=$(tty)' >> ~/.zshrc\n```\n\n# Generate your GPG Key\n```\ngpg --full-generate-key\n```\n- `RSA` and `RSA`\n- `4096` key size\n- No expiration (unless you want one)\n- Enter real name or github username\n- Enter github email address, can be any authorized email on your account but MUST match one\n- Comment can be anything including being empty\n\n# Add GPG Key to GitHub\n```\ngpg --list-secret-keys --keyid-format LONG\n```\nThe part you want to copy is the string following `sec rsa4096/`. Copy that string into this command over the Xs.\n```\ngpg --armor --export XXXXXXXXXXXXXXXX | pbcopy\n```\nThat command will have copied your public key to your clipboard. This can be pasted into the \"Create new GPG key\" wizard on github.com.\n\n# Configure Git To Sign Commits\nThey key id used above is also used in the git config to tell git which GPG key to use for signing.\n```\ngit config --global user.signingkey XXXXXXXXXXXXXXXX\n```\nThis command is necessary so git knows which gpg binary to run.\n```\ngit config --global gpg.program=/opt/homebrew/bin/gpg\n```\nIf you always want all commits to be signed you can run this command as well\n```\ngit config --global commit.gpgsign true\n```\n\nYou may enable \"vigilant mode\" on github.com so that any unsigned commits are marked as unverified.",
"x": 1040,
"y": 270,
"wires": [
[]
]
},
{
"id": "1bf6704ac725ea82",
"type": "task",
"z": "c86af370eff94afa",
"name": "Setup GitHub Account",
"info": "An up to date GitHub account is necessary for contributing to projects on the defense unicorns repository. \n\nIf you do not already have one you can create one here: https://github.com/join\n\nThere is no rule as to whether or not you need to tie your @defenseunicorns.com email to it. You can even create the account with a personal email and add the DU email to it later.",
"x": 1040,
"y": 130,
"wires": [
[
"37842ffb402cfc62"
]
]
},
{
"id": "37842ffb402cfc62",
"type": "task",
"z": "c86af370eff94afa",
"name": "Add GitHub 2FA",
"info": "GitHub 2FA is required to be added to the DU organization. \nA guide to doing so can be found here: https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication",
"x": 1040,
"y": 200,
"wires": [
[
"ef3535e20ee71428"
]
]
},
{
"id": "e4d3465dcafc826f",
"type": "task",
"z": "c86af370eff94afa",
"name": "Deploy the podinfo BigBang Package",
"info": "## Prerequisites\n- Remove all prior content for podinfo from your cluster.\n\n## Objective\nThis exercise is very similar to the previous one except that you will be using the podinfo bigbang package instead of the upstream version. This package is located at https://repo1.dso.mil/platform-one/big-bang/apps/sandbox/podinfo.\n\nDeployment will be accomplished using the same pattern as before except the virtualservice needs to be enabled by using helm values. \n\n### Minimum Requirements\n- Namespace\n- GitRepository\n- HelmRelease\n- Helm Values\n\n## Success Criteria\nAfter deploying the podinfo packge, it should be accessible through the istio gateway via podinfo.bigbang.dev",
"x": 360,
"y": 690,
"wires": [
[
"0f9889d8e9cb7edb"
]
]
},
{
"id": "0571474bde3a7f49",
"type": "guide",
"z": "c86af370eff94afa",
"name": "Troubleshooting hints",
"info": "If you are having some issues with deploying bigbang, you should tear down the cluster created for podinfo.\n\nFollow the bigbang deployment document:\nhttps://repo1.dso.mil/big-bang/bigbang/-/blob/master/docs/guides/deployment-scenarios/quickstart.md#step-5-create-a-k3d-cluster\n\n## Neuvector\nSince we're using `k3d` the necessary container runtime needs to be enabled in the values.yaml chart in the bigbang repository with the following:\n\n```\nneuvector:\n ...\n values:\n k3s:\n enabled: true\n```\n\nwhich will allow neuvector to work with the correct runtime.\n\n### Networking\n# Accessing the UI\nIf you are using the recommended Cloud deployment method with K3d and attempting to connect to any of the UI, you must create an entry in your local machines /etc/hosts file for the IP address to the EC2 instance, and your *.bigbang.dev entry to access `bigbang.dev` through HTTPS.",
"x": 780,
"y": 460,
"wires": [
[]
]
},
{
"id": "5dfd2ba38ec5178d",
"type": "resource",
"z": "eb7909bcf5fcaf8a",
"name": "Containerization",
"info": "",
"x": 430,
"y": 50,
"wires": [
[
"ea946e25b7c2079f"
]
]
},
{
"id": "8c04bec4a15f6702",
"type": "resource",
"z": "eb7909bcf5fcaf8a",
"name": "Helm",
"info": "",
"x": 610,
"y": 200,
"wires": [
[
"803aead6445263d4"
]
]
},
{
"id": "fc01372231b580db",
"type": "resource",
"z": "eb7909bcf5fcaf8a",
"name": "Custom Resource Definitions",
"info": "",
"x": 430,
"y": 200,
"wires": [
[
"803aead6445263d4"
]
]
},
{
"id": "09d8e90d5b4ade12",
"type": "resource",
"z": "eb7909bcf5fcaf8a",
"name": "Kustomization",
"info": "",
"x": 90,
"y": 200,
"wires": [
[
"803aead6445263d4"
]
]
},
{
"id": "71a96ec4058930db",
"type": "resource",
"z": "eb7909bcf5fcaf8a",
"name": "GitOps",
"info": "",
"x": 720,
"y": 150,
"wires": [
[
"45465f711df6da7e"
]
]
},
{
"id": "98df2d11adb09046",
"type": "resource",
"z": "eb7909bcf5fcaf8a",
"name": "git",
"info": "# Description\n\n[Git](https://git-scm.com/) is a free and open source distributed version control system.\n\n## Resources\n- https://git-scm.com/docs\n\n\n## Examples\n- github.com\n- gitlab.com\n- https://gitea.com/",
"x": 720,
"y": 50,
"wires": [
[
"71a96ec4058930db"
]
]
},
{
"id": "45465f711df6da7e",
"type": "resource",
"z": "eb7909bcf5fcaf8a",
"name": "Flux",
"info": "",
"x": 720,
"y": 200,
"wires": [
[
"803aead6445263d4"
]
]
},
{
"id": "ea946e25b7c2079f",
"type": "subflow:0ac7681ed1c2bc4b",
"z": "eb7909bcf5fcaf8a",
"name": "",
"x": 430,
"y": 110,
"wires": [
[
"8c04bec4a15f6702",
"fc01372231b580db",
"09d8e90d5b4ade12",
"71a96ec4058930db",
"81348cdecdf51fd9"
]
]
},
{
"id": "81348cdecdf51fd9",
"type": "resource",
"z": "eb7909bcf5fcaf8a",
"name": "Operators",
"info": "https://www.youtube.com/watch?v=ha3LjlD6g7g",
"x": 240,
"y": 200,
"wires": [
[
"803aead6445263d4"
]
]
},
{
"id": "803aead6445263d4",
"type": "subflow:13374ec618504763",
"z": "eb7909bcf5fcaf8a",
"name": "",
"x": 420,
"y": 500,
"wires": [
[]
]
},
{
"id": "e5a5a6e4ec936973",
"type": "comment",
"z": "6a6a274a201cb47d",
"name": "Baffles",
"info": "# Description\n\nBaffles is an integration of Kubevirt with Big Bang. Kubevirt enables the operation of virtual machines or non containerized applications on top of Kubernetes. Integrating Kubevirt with Big Bang allows leveraging the declarative, gitops baseline and its secure runtime configuration. Big Bang is a declarative, continuous delivery tool for core DoD hardened and approved packages into a Kubernetes cluster. Big Bang follows a GitOps approach to configuration management, using Flux v2 to reconcile Git with the cluster.\n\n# Resources\n\n# Unicorn SME(s)\n\nAndrew Greene",
"x": 470,
"y": 60,
"wires": [
[
"e4bc242fecadfd12"
]
]
},
{
"id": "e4bc242fecadfd12",
"type": "guide",
"z": "6a6a274a201cb47d",
"name": "Virtual Machines",
"info": "[Virtual Machines explained in 15 minutes](https://www.youtube.com/watch?v=mQP0wqNT_DI) by TechWorld with Nana",
"x": 460,
"y": 160,
"wires": [
[
"c5b04d09073d58fb"
]
]
},
{
"id": "c5b04d09073d58fb",
"type": "subflow:0ac7681ed1c2bc4b",
"z": "6a6a274a201cb47d",
"name": "",
"x": 470,
"y": 280,
"wires": [
[
"996299cdf05948b7"
]
]
},
{
"id": "996299cdf05948b7",
"type": "guide",
"z": "6a6a274a201cb47d",
"name": "Virtual Machines + Kubernetes",
"info": "",
"x": 470,
"y": 420,
"wires": [
[]
]
},
{
"id": "46b80f7f0ba9ddb3",
"type": "resource",
"z": "6a6a274a201cb47d",
"name": "KubeVirt",
"info": "Introduction/Overview: https://kubevirt.io/\n\nCommunity - https://kubevirt.io/community/",
"x": 240,
"y": 340,
"wires": [
[
"996299cdf05948b7",
"131e4f8c833bfbee"
]
]
},
{
"id": "ed5fac6f95ac2076",
"type": "resource",
"z": "6a6a274a201cb47d",
"name": "Rancher Harvestor",
"info": "Suggested Research:\nhttps://rancher.com/products/harvester\n\nGood Overview: https://www.youtube.com/watch?v=tVsMen_e6OI",
"x": 750,
"y": 340,
"wires": [
[
"996299cdf05948b7"
]
]
},
{
"id": "131e4f8c833bfbee",
"type": "task",
"z": "6a6a274a201cb47d",
"name": "Use KubeVirt",
"info": "https://kubevirt.io/labs/kubernetes/lab1.html",
"x": 190,
"y": 420,
"wires": [
[
"c399cbb1c8160af7"
]
]
},
{
"id": "c399cbb1c8160af7",
"type": "task",
"z": "6a6a274a201cb47d",
"name": "Experiment with CDI",
"info": "https://kubevirt.io/labs/kubernetes/lab2.html",
"x": 180,
"y": 500,
"wires": [
[
"65aae8f158cb5c2f"
]
]
},
{
"id": "65aae8f158cb5c2f",
"type": "task",
"z": "6a6a274a201cb47d",
"name": "Live Migration",
"info": "https://kubevirt.io/labs/kubernetes/migration.html\n\nNote: \"Enable Live Migration\" is incorrect in this lab, correct answer can be found [here](https://kubevirt.io/user-guide/)... somewhere",
"x": 200,
"y": 580,
"wires": [
[]
]
}
]
Reference in New Issue View Git Blame Copy Permalink