Henry Lawson

Below are various notes and links that I have collected while going deep on Google Compute Engine. For an overview of all the notes and this study adventure in general, the GCP Study Plan is a good start.

1. GCE Home
2. GCE Docs
3. GCE Docs - Concepts
4. Preemptible Instance
   1. Short lived
   2. Max life 24 hours
   3. Much lower pricing
   4. Can be terminated at anytime
   5. Configure a shutdown script to gracefully handle instance termination, save state to a Cloud Storage bucket
5. Compute Instances
   1. Instance States
      1. PROVISIONING - resources being reserved for instances
      2. STAGING - resources acquired, preparing for launch
      3. RUNNING - booting up or running, can ssh now
      4. STOPPING - instance being stopped or shutdown before being TERMINATED
      5. TERMINATED - has shutdown, can be deleted or restarted
   2. Instance Scheduling Options
      1. Triggered when there is a service disruption - hardware failure or maintenance
      2. Can Live Migrate move to another VM host and restart
      3. Terminate or optionally restart it at the new location
      4. Can be configured using availability policies onHostMaintenance and automicRestart
   3. Meta-data available to instance via HTTP requests
      1. Can long poll for changes
      2. Can store small amounts of Key Value info
      3. Can be used to "self discover" information for usage by the instance
   4. Serial console can be used to debug startup or boot issues
6. Custom Machine Types
   1. Choose custom vCPU and Memory VM configurations
   2. Feature allows you to scale vertically
   3. Configure VM to match application needs, best fit VM, no waste
7. Pricing
   1. Discount based model
   2. No lock in to legacy VM types
   3. Reduced priced based on usage period, sustained usage discounts
   4. Predefined machine types, treated as inferred instances for billing, allowing you to start and stop instances
   5. Algorithm is geared in customers favour, biggest discount possible
8. Images
   1. Multiple standard images
   2. Premium images, from supported vendors - extra cost
   3. Images are customized to run on Compute Engine
      1. Use Compute Engine repositories for RPM/DEB
      2. IP/Networking configuration tweaks
      3. Other tweaks detailed in docs
   4. Can import custom images from on-prem or other clouds
      1. Images can be stored under an image family so compute instance use latest
      2. Windows custom images not supported
      3. Setup bootloader, ensure SSH works, create image file, compress image file, upload it, setup Linux Guest Environment - for GCP features, configure for optimal GCP configuration, implement security bet practices
      4. Image Management Best Practices
   5. Community images, not supported by GCP but by community
9. Accessing Instances
   1. Can manage SSH keys manually, be aware that keys will need to removed and cycled as the team members change, prefer using gcloud tool if manual keys are not needed
10. Instance Groups
    1. Managed Instance Groups scale to the number of instances defined in the group, can sit behind a load balancer, use an instance template to define what instances should look like
    2. Unmanaged Instance Groups, for legacy applications that need to sit behind a load balancer but will be scaled and provisioned manually, snowflakes behind a Load Balancer
    3. Managed instance groups can use the Instance Group Updater, using various params to control how many minimum instances are maintained and max instances updated at any given time, updates can be canaries before rolling out, can be proactive - will actively update instances or opportunistic - will wait for instances to die or be scaled up or down by an autoscaler. Instance Group Updater can also do restarts or recreations
    4. Managed instance groups can be updated via rolling updates, they can be paused, continued, rolled back or canceled
    5. Managed instance groups can have health checks applied to them
    6. Instances in a Managed instance group can be abandoned from the group to allow you to debug and tweak the services, they will also be removed from load balancers
    7. Detect and recreate unhealthy instances in the group
    8. Zonal vs. Regional, regional spans multiple zones in case of zone failure
    9. Tip, over provision regional managed instances to allow for the unavailability of one zone
    10. Tip, configure regional autoscaler to have higher max instances and lower target number to account for over provision for zone availability
    11. Managed instance groups can be used to deploy docker containers
    12. Autoscaling in a Managed Instance Group done via Autoscale Policy which can be based of Stackdriver metrics, CPU utilization, etc.
11. Storage Options
    1. Persistent disks, local SSDs, Cloud Storage Buckets, RAM disks
    2. Disks have different limits and performance characteristics
    3. Number of disks is dependent on vCPUs
12. VM IP Addresses
    1. Static external IP address - available for use by any instance in the project
    2. Ephemeral external IP addresses - assigned to an instance when started, released once it is terminated or restart
    3. Regional Static IP - can be assigned to an instance or network load balancer
    4. Global IP - used with HTTP(s) or SSL load balancing, not an instance
13. Load Balancing and Autoscaling
    1. HTTP(S) load balancing - cross region, can forward based on URL
    2. Network load balancing - single region, non-HTTP(s) services
14. Global, Regional and Zonal
    1. Assets fall into one of the above categories
    2. Zones are independent of each other, separate cooling, power, networking control panes
    3. Regions are collections of Zones
    4. Users can be restricted to certain quotes in different zones
15. Identity Access Management
    1. Can create a custom service account to assign to an instance to allow it to access GCP services
    2. Instances provisioned with a default service account that allows read only access to some basic services, this can be deleted
16. Container VMs
    1. Container VMs allow running of docker containers through a definition in a YAML file when the compute engine is created