0% found this document useful (0 votes)
10 views8 pages

GCP App Engine Cheat Sheet

GCP App Engine Cheat Sheet

Uploaded by

Suresh Kumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views8 pages

GCP App Engine Cheat Sheet

GCP App Engine Cheat Sheet

Uploaded by

Suresh Kumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 8

GCP App Engine - GCP Certification Cheat Sheet

Let’s get a quick overview of Google Cloud App Engine from an GCP certification
perspective. We will look at important certification questions related to App Engine, how
this is different compared to other compute services, features of App Engine and how to use
AppEngine to run your compute load.
You will learn
 What is a App Engine
 Features of AppEngine
 Various concepts of AppEngine and how to use it to run the applications
 Commands Cheatsheet
App Engine
App Engine

 Simplest way to deploy and scale your applications in GCP


o Provides end-to-end application management
 Supports:
o Go, Java, .NET, Node.js, PHP, Python, Ruby using pre-configured runtimes
o Use custom run-time and write code in any language
o Connect to variety of Google Cloud storage products (Cloud SQL etc)
 No usage charges - Pay for resources provisioned
 Features:
o Automatic load balancing & Auto scaling
o Managed platform updates & Application health monitoring
o Application versioning
o Traffic splitting
Compute Engine vs App Engine

 Compute Engine
o IAAS
o MORE Flexibility
o MORE Responsibility
 Choosing Image
 Installing Software
 Choosing Hardware
 Fine grained Access/Permissions (Certificates/Firewalls)
 Availability etc
 App Engine
o PaaS
o Serverless
o LESSER Responsibility
o LOWER Flexibility
App Engine environments

 Standard: Applications run in language specific sandboxes


o Complete isolation from OS/Disk/Other Apps
o V1: Java, Python, PHP, Go (OLD Versions)
 ONLY for Python and PHP runtimes:
 Restricted network Access
 Only white-listed extensions and libraries are allowed
 No Restrictions for Java and Go runtimes
o V2: Java, Python, PHP, Node.js, Ruby, Go (NEWER Versions)
 Full Network Access and No restrictions on Language Extensions
 Flexible - Application instances run within Docker containers
o Makes use of Compute Engine virtual machines
o Support ANY runtime (with built-in support for Python, Java, Node.js, Go,
Ruby, PHP, or .NET)
o Provides access to background processes and local disks
App Engine - Application Component Hierarchy

 Application: One App per Project


 Service(s): Multiple Microservices or App components
o You can have multiple services in a single application
o Each Service can have different settings
o Earlier called Modules
 Version(s): Each version associated with code and configuration
o Each Version can run in one or more instances
o Multiple versions can co-exist
o Options to rollback and split traffic
App Engine - Comparison
Feature Standard Flexible

Pricing Factors Instance hours vCPU, Memory & Persistent


Disks

Scaling Manual, Basic, Automatic Manual, Automatic

Scaling to zero Yes No. Minimum one instance

Instance startup Seconds Minutes


time

Rapid Scaling Yes No

Max. request 1 to 10 minutes 60 minutes


timeout

Local disk Mostly(except for Python, PHP). Can Yes. Ephemeral. New Disk on
write to /tmp. startup.

SSH for debugging No Yes


App Engine - Scaling Instances

 Automatic - Automatically scale instances based on the load:


o Recommended for Continuously Running Workloads
 Auto scale based on:
 Target CPU Utilization - Configure a CPU usage threshold.
 Target Throughput Utilization - Configure a throughput
threshold
 Max Concurrent Requests - Configure max concurrent
requests an instance can receive
 Configure Max Instances and Min Instances
 Basic - Instances are created as and when requests are received:
o Recommended for Adhoc Workloads
 Instances are shutdown if ZERO requests
 Tries to keep costs low
 High latency is possible
 NOT supported by App Engine Flexible Environment
 Configure Max Instances and Idle Timeout
 Manual - Configure specific number of instances to run:
o Adjust number of instances manually over time
app.yaml Reference
runtime: python28 #The name of the runtime environment that is used by your app
api_version: 1 #RECOMMENDED - Specify here - gcloud app deploy -v [YOUR_VERSION_ID]
instance_class: F1
service: service-name
#env: flex

inbound_services:
- warmup

env_variables:
ENV_VARIABLE: "value"

handlers:
- url: /
script: home.app

automatic_scaling:
target_cpu_utilization: 0.65
min_instances: 5
max_instances: 100
max_concurrent_requests: 50
#basic_scaling:
#max_instances: 11
#idle_timeout: 10m
#manual_scaling:
#instances: 5
AppEngine - Request Routing

 You can use a combination of three approaches:


o Routing with URLs:
 https://PROJECT_ID.REGION_ID.r.appspot.com (default service called)
 https://SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com (specific
service)
 https://VERSION-dot-SERVICE-dot-
PROJECT_ID.REGION_ID.r.appspot.com (specific version of service)
 Replace -dot- with . if using custom domain
o Routing with a dispatch file:
 Configure dispatch.yaml with routes
 gcloud app deploy dispatch.yaml
o Routing with Cloud Load Balancing:
 Configure routes on Load Balancing instance
AppEngine - Deploying new versions without downtime

 How do I go from V1 to V2 without downtime?


 Option 1: I’m very confident - Deploy & shift all traffic at once:
o Deploy and shift all traffic at once from v1 to v2: gcloud app deploy
 Option 2: I want to manage the migration from v1 to v2
o STEP 1: Deploy v2 without shifting traffic (--no-promote)
 gcloud app deploy –no-promote
o STEP 2: Shift traffic to V2:
 Option 1 (All at once Migration): Migrate all at once to v2
 gcloud app services set-traffic s1 –splits V2=1
 Option 2 (Gradual Migration): Gradually shift traffic to v2. Add --
migrate option.
 Gradual migration is not supported by App Engine Flexible
Environment
 Option 3 (Splitting): Control the pace of migration
 gcloud app services set-traffic s1 –splits=v2=.5,v1=.5
 Useful to perform A/B testing
 Ensure that new instances are warmed up before they receive traffic
(app.yaml - inbound_services > warmup)
How do you split traffic between multiple versions?

 How do you decide which version receives which traffic?


o IP Splitting - Based on request IP address
 IP addresses can change causing accuracy issues! (I go from my house
to a coffee shop)
 If all requests originate from a corporate vpn with single IP, this can
cause all requests to go to the same version
o Cookie Splitting - Based on a cookie (GOOGAPPUID)
 Cookies can be controlled from your application
 Cookie splitting accurately assign users to versions
o Random - Do it randomly
 How to do it?
o Include --split-by option in gcloud app services set-traffic command
 Value must be one of: cookie, ip, random
 gcloud app services set-traffic s1 --splits=v2=.5,v1=.5 --split-by=cookie
Playing with App Engine

 gcloud app browse/create/deploy/describe/open-console


o gcloud app create –region=us-central
o gcloud app deploy app.yaml
 –image-url: Only for flexible environments. Deploy docker image.
 gcloud app deploy –image-url gcr.io/PROJECT-ID/hello-world-
rest-api:0.0.1.RELEASE
 –promote –no-promote (Should new version receive traffic?)
 –stop-previous-version –no-stop-previous-version (Should old version
be stopped after new version receives all traffic?)
 –version (Assign a version. Otherwise, a version number is generated.)
o gcloud app browse –service=”myService” –version=”v1” (open in a web
browser)
o gcloud app open-console –service=”myService” –version=”v1”
o gcloud app open-console –logs
 Other Commands
o gcloud app logs tail
o gcloud app regions list

Playing with App Engine Instances


 gcloud app instances delete/describe/list/scp/ssh
o gcloud app instances delete i1 –service=s1 –version=v1
o gcloud app instances describe –service=s1 –version=v1 i1
o gcloud app instances list
o gcloud app instances scp –service=s1 –version=v1 –recurse local_dir
i1:remote_dir (Copy files to/from App Engine Flexible instances)
o gcloud app instances ssh –service=s1 –version=v1 i1 (SSH into the VM of an
App Engine Flexible instance)
Playing with App Engine Services and Versions
 gcloud app services browse/delete/describe/list/set-traffic
o gcloud app services list
o gcloud app services browse myService –version=”v1”
o gcloud app services delete service1 service2
o gcloud app services describe service1
o gcloud app services set-traffic APP1 –splits v1=0.9,v2=0.1
 –split_by (ip, cookie, random)
 gcloud app versions browse/delete/describe/list/migrate/start/stop
o gcloud app versions list
 –hide-no-traffic (Only show versions that are receiving traffic)
o gcloud app versions browse/delete/describe v1 –service=”myService”
o gcloud app versions migrate v2 –service=”myService” (migrate all traffic to
new version)
o gcloud app versions start/stop v1
 –service=my-service Only start v1 of service my-service
App Engine - Cron Job
cron:
- description: "daily summary job"
url: /tasks/summary
schedule: every 24 hours
 Allows to run scheduled jobs at pre-defined intervals
 Use cases:
o Send a report by email every day
o Refresh cache data every 30 minutes
 Configured using cron.yaml
 Run this command - gcloud app deploy cron.yaml
o Performs a HTTP GET request to the configured URL on schedule
Others Important App Engine yaml files
 dispatch.yaml - override routing rules
dispatch:
- url: "*/mobile/*"
service: mobile-frontend
- url: "*/work/*"
service: static-backend
 queue.yaml - manage task queues
queue:
- name: fooqueue
rate: 1/s
retry_parameters:
task_retry_limit: 7
task_age_limit: 2d
App Engine - Remember
 AppEngine is Regional (services deployed across zones)
o You CANNOT change an Application’s region
 Good option for simple microservices (multiple services)
o Use Standard v2 when you are using supported languages
o Use Flexible if you are building containerized apps
 Be aware - ATLEAST one container is always running when using Flexible:
o Go for Standard if you want to be able to scale down the number of
instances to zero when there is NO load
 Use a combination of resident and dynamic instances
o Resident Instances: Run continuously
o Dynamic Instances: Added based on load
 Use all dynamic instances if you are cost sensitive
 If you are not very cost sensitive, keep a set of resident instances
running always
App Engine - Scenarios
Scenario Solution

I want to create two Google Not possible. You can only have one App Engine App per
App Engine Apps in the same project. However you can have multiple services and
project multiple version for each service.

I want to create two Google Yup. You can create multiple services under the same app.
App Engine Services inside the Each service can have multiple versions as well.
same App

I want to move my Google App App Engine App is region specific. You CANNOT move it to
Engine App to a different different region. Create a new project and create new app
region engine app in the new region.

Perform Canary deployments Deploy v2 without shifting traffic (gcloud app deploy --no-
promote)
Shift some traffic to V2 (gcloud app services set-traffic s1
--splits v1=0.9,v2=0.1)

You might also like