Starting build-demo

Part_3.md

@@ -233,22 +233,130 @@ result: <h1 style="margin:20px auto;width:800px;">Welcome to the GCP DevOps cour
 
 #### CSR Hands On - Mirror Github and Cross-Project Access
 
+- Mirror external GitHub repo to CSR
+  - One-way sync from GitHub to CSR
+  - GitHub is primary 'source of truth'. CSR is 'read-only' copy
+- Grant access to user in another project
+  - Note: Not possible in Cloud Playgrounds
+  - Note: Granting access as repo/non-project level = cannot view cross-project repo via interface
+
+- One-way sync updates are normally very quick after an update to a source repo, but the sync can be forced by clicking on the gear icon and clicking 'sync from GitHub'
+
+> Minimum scope (Source repository Writer role) to provide user permissions to clone/edit/commit a repo is by specifying the user at the repo level (clicking gear icon on repo -> Permissions). The user however cannot browse or discover the repo through the webUI, for that the user needs permissions at the project level. To discover add the user at the project level to IAM with "Source Repository Reader" role. This permissions will allow the user read permissions to every other repository within the project.
+
 #### Hands On Lab - Migration Source Code to a Google Cloud Source Repository
 
+> Completed
+
 #### Hands On Lab - Inteegrating Google Cloud Functions
 
-### Cloud Build
+> Completed
 
+### Cloud Build
 #### Importance of Automation
 
+Life of a Kubernetes Container Deployment (i.e. manual 'stuff' you must do)
+
+- Update code
+- Build a docker container ('docker build')
+- Push container to registry ('docker push')
+- In kubernetes, update deployment YAML file
+- Apply deployment YAML ('kubectl apply')
+- Make sure nothing broke and it's working correctly
+- Do it all again!
+> Google calls this..... "Infinite loop of Pain and Suffering"
+
+- More manual actions = greate chance of human error
+  - Increased toil
+  - SRE objective = reduce toil
+  - Toil = manual and repetitive work that should be automated
+  - Solution: Automate it!
+  - Google 'Cloud Build' = 'automation engine'
+
 #### Cloud Build Concepts
 
+What is the Cloud Build service?
+
+- Fully managed CI/CD engine
+  - Import source code
+  - Build in managed space
+  - Create artifacts
+    - Docker images, Java archive, Go applications, and more
+
+How it works - high level overview
+
+- Prepare source code
+- Include build config file that calls 'Cloud Builder' (cloudbuild.yaml)
+  - Submit build (manual or automatic) to the 'Cloud Build' Service
+    - Cloud Build will execute build steps as defined
+    - Example: Build Docker container, Push to Container Registry, Deploy to service
+ - Completed artifact (container image) pushed to GCP 'Container Registry'
+
+Cloud Builders?
+- Specialized Container images that run the build process
+  - Packaged with common languages and tools
+- Google-manage, community-managed, public Docker Hub images
+- Run specific commands inside builder containers
+- Can also use custom build steps
+
+Build File
+- Provides instructions for Cloud Build to perform tasks using cloud builders
+  - Tells the cloud builders what to do
+  - YAML or JSON format
+  - Named cloudbuild.yaml/json
+- Provides parameters such as builder image, arguments (steps), environment variables, and others
+- Example: use docker and gcloud cloud builders to build and push a Docker file, then deploy container to Cloud Run
+
+Building Docker files - two methods
+- Build file (cloudbuild.yaml)
+- Dockerfile directly handles build steps and pushed to Container Registry
+  - Add --tag option to build command
+
+Automate build submissions with triggers
+- Why automate?
+  - Reduce toil
+  - Reduce human error
+
+How Triggers Work:
+- Cloud Build looks for conditions, then executes build process when met
+- Common triggers:
+  - Commit to repo/subdirectory/branch
+  - Commit tags
+- Triggers sync to CSR, GitHub and BitBucket
+- Pub/Sub for further automation
+  - Cloud Build automatically creates and publishes to own Pub/Sub topic for further automation
+
+To Summarize:
+- Cloud Build uses specialized cloud builders (containers) to execute build steps that you submit in a build file (cloudbuild.yaml config file)
+- The build submission process can be done manually or automatically using <u>triggers</u>
+
+![Picture](./img/Cloud-Build-Process.png)
+
 #### Cloud Build Access Control
 
+- End user IAM roles
+  - Cloud Build Editor, Cloud Build Viewer
+  - Editor: create, delete, edit, run and view builds
+  - Viewer: view build and build history only
+- Cloud Build service account
+  - Automatically created when enabling API
+  - Executes builds on your behalf
+  - May need additional IAM roles to interact with other GCP services (App engine, GKE, etc)
+    - Scenario: Developers using Cloud Build need Cloud Build to deploy to their GKE cluster
+    - Solution: Grant the K8's Engine Developer role to the Cloud Build Service Account
+
 #### Perspective: Access Control
 
 #### Hands On - Prepare Cloud Build Environment
 
+- Setup Cloud Source Repository and Cloud Build Service
+- Explore app we will deploy
+- Manually submit build using Dockerfile
+- Deploy container to Cloud Run
+- Assign Cloud Run Admin role to Cloud Build service account
+- Manually submit build using build file to build, push, and deploy to Cloud Run
+
+
 #### Hands On - Automate Build with Triggers
 
 #### Best Practices for Build Performance