fluxcd update restructure repo

kubernetes/fluxcd/README.md

@@ -78,7 +78,7 @@ Then we can bootstrap it using the GitHub bootstrap method
 flux bootstrap github \
   --owner=marcel-dempers \
   --repository=docker-development-youtube-series \
-  --path=kubernetes/fluxcd/repositories/config/clusters/dev-cluster \
+  --path=kubernetes/fluxcd/repositories/infra-repo/clusters/dev-cluster \
   --personal \
   --branch fluxcd-2022
 
@@ -95,27 +95,42 @@ Check the source code that `flux bootstrap` created
 git pull origin <branch-name>
 ```
 
-# Repository structure 
+# Understanding GitOps Repository structures
 
-https://fluxcd.io/flux/guides/repository-structure/
+Generally, in GitOps you have a dedicated repo for infrastructure templates. </br>
+Your infrastructure will "sync" from the this repo </br>
 
-* Mono Repo
+```
+                                                    
+ developer    +-----------+     +----------+           
+              |           |     | CI       |           
+  ----------> | REPO(code)|---> | PIPELINE |           
+              +-----------+     +----------+           
+                                         |  commit     
+                                         v             
+           +----------+ sync    +----------+           
+           |  INFRA   |-------> |INFRA     |           
+           |  (k8s)   |         |REPO(yaml)|           
+           +----------+         +----------+           
+                                                            
+```
+
+Flux repository structure [documentation](https://fluxcd.io/flux/guides/repository-structure/)
+
+* Mono Repo (all k8s YAML in same "infra repo")
 * Repo per team
 * Repo per app 
 
+Take note in this guide the folders under `kubernetes/fluxcd/repositories` represent different GIT repos
+
 ```
-- apps
+- repositories
+  - infra-repo
   - example-app-1
   - example-app-2
-- infrastructure
-  - ingress-nginx
-  - monitoring
-- clusters
-  -dev-cluster
-  -prod-cluster
 ```
 
-## build our app
+## build our example apps
 
 Let's say we have a microservice called `example-app-1` and it has its own GitHub repo somewhere. </br>
 For demo, it's code is under `kubernetes/fluxcd/repositories/example-app-1/`
@@ -135,7 +150,7 @@ kind load docker-image example-app-1:0.0.1 --name fluxcd
 
 ## setup our gitops pipeline
 
-Now we will also have a "config" GitHub repo where configuration files for GitOps live.
+Now we will also have a "infra-repo" GitHub repo where infrastructure configuration files for GitOps live.
 
 ```
 cd kubernetes/fluxcd
@@ -143,8 +158,8 @@ cd kubernetes/fluxcd
 # tell flux where our Git repo is and where the YAML is
 # this is once off
 # flux will monitor the example-app-1 Git repo for when any infrastructure changes, it will sync
-kubectl -n default apply -f repositories/config/apps/example-app-1/gitrepository.yaml
+kubectl -n default apply -f repositories/infra-repo/apps/example-app-1/gitrepository.yaml
-kubectl -n default apply -f repositories/config/apps/example-app-1/kustomization.yaml
+kubectl -n default apply -f repositories/infra-repo/apps/example-app-1/kustomization.yaml
 
 # check our flux resources 
 kubectl -n default describe gitrepository example-app-1
@@ -159,7 +174,7 @@ kubectl port-forward svc/example-app-1 80:80
 
 Now we have setup CD, let's take a look at CI </br>
 
-## changes to our app
+## changes to our example apps
 
 Once we make changes to our `app.py` we can build a new image with a new tag </br>
 
@@ -175,14 +190,31 @@ kind load docker-image example-app-1:0.0.2 --name fluxcd
 
 If we wait a minute or so we can ` kubectl port-forward svc/example-app-1 80:80` again and see the changes
 
-## deploy by updating manifest 
+## automate deploy by updating manifest 
 
 So all we did to update our app is to build a new image, push it to our registry and update the image tag in our kubernetes deployment YAML file and `flux` will sync it. </br>
 This is generally the role of CI, where `flux` concern is mainly CD. </br>
 
 Here is an example on [how to automate that](https://fluxcd.io/flux/use-cases/gh-actions-manifest-generation/) 
 
-## deploy by image scanning
+## automate deploy by image scanning
+
+```                                                                                                                                               
+                                              docker push                   
+                                                                            
+        developer    +-----------+     +----------+       +-------------+   
+                     |           |     | CI       |       |IMAGE        |   
+         ----------> | REPO(code)|---> | PIPELINE | ----->|REGISTRY     |   
+                     +-----------+     +----------+       +-------------+   
+                                                           ^                
+                                                           |sync            
+                                                           |                
+                                   +----------+  commit   +----------+      
+                                   |INFRA     | <-------- |  INFRA   |      
+                                   |REPO(yaml)|           |  (k8s)   |      
+                                   +----------+           +----------+      
+                                                                         
+```
 
 An alternative method is to use your CI to build and push a newly tagged image to your registry (same as first option) and use [Flux image scanner](https://fluxcd.io/flux/guides/image-update/#configure-image-updates) to trigger the rollout instead of automating a commit to your config repo. </br>