Writing code alone is not good enough to effortlessly run and maintain an application. To ensure that the application is available to the user, many people work behind the scenes and manage different requests that come from the app, maintenance, server health checks, installing security patches, upgrading software packages, and firewalls to protect servers from hackers.
Even though all these tasks require a significant amount of energy, focus, and effort, in the era of cloud computing, some of these tasks can be automated via scripts.
This blog will talk about app configuration on Google App Engine, where we will discuss the deployment of an application in an App Engine and the underlying processes by using Node.js application as an example. App Engine is one of the Google Cloud computing services. Let’s discuss them briefly.
- Compute Engine - Infrastructure as a Service (IaaS): It is a clean virtual machine (a new and an empty server) that takes care of all configurations according to the requirement.
- App Engine - Platform as a Service (PaaS): It is a fully managed service that deploys code to make the application up and running. Tasks like maintenance, configuration, scaling, security patches, upgrades, etc. are managed by Google.
- Kubernetes Engine - Container as a Service (CaaS): It is a container management service and is widely used in microservices to make them lightweight and independent.
- Cloud Functions - Function as a service (FaaS): This fully managed service executes functions for a few minutes or seconds. It doesn’t cause any wastage of resources while executing the function; instead, these cloud functions are executed based on triggers.
An Introduction to Google App Engine
The App Engine is a fully managed platform as a service (PaaS) for building web applications where the user doesn’t need to manage the underlying operating systems, configurations, security issues, firewalls, and auto-scaling. By using this service, developers can manage the entire application just by making a configuration file called app.yaml to make the code compatible with the App Engine.
The App Engine is based on serverless architecture. It is available with two types of runtime environments:
- Standard environment: It supports only a few languages, including Python, Node.js, Go, PHP, .NET, Java. To deploy a Python application, it requires a standard environment along with a configuration file that defines our runtime environment in the file app.yaml.
- Flexible environment: It supports all kinds of applications and provides some control over the infrastructure. It uses Docker containers as a resource to run the application. Besides the supported runtimes, it can also make custom runtime using a Dockerfile.
| Feature | Standard environment | Flexible environment |
|---|---|---|
| Instance startup time | Seconds | Minutes |
| Maximum request timeout | Depends on the runtime and type of scaling. | 60 minutes |
| Background threads | Yes, with restrictions | Yes |
| Background processes | No | Yes |
| SSH debugging | No | Yes |
| Scaling | Manual, Basic, Automatic | Manual, Automatic |
| Scale to zero | Yes | No, minimum 1 instance |
| Writing to local disk | Java 8, Java 11, Node.js, Python 3.7, PHP 7.2, PHP 7.3, Ruby 2.5 (beta), Go 1.11, Go 1.12, and Go 1.13 have read and write access to the /tmp directory. Python 2.7, Go 1.9, and PHP 5.5 don't have write access to the disk. |
Yes, ephemeral (disk initialized on each VM startup) |
| Modifying the runtime | No | Yes (through Dockerfile) |
| Deployment time | Seconds | Minutes |
| Automatic in-place security patches | Yes | Yes (excludes container image runtime) |
| Access to App Engine APIs & Services such as NDB, Users API, Memcache, Images API and others. | Yes for Python 2.7, Go 1.9, PHP 5.5, and Java 8 No for Java 11, Node.js, Python 3.7, PHP 7.2, PHP 7.3, Ruby 2.5 (beta), Go 1.11, Go 1.12, and Go 1.13 |
No |
| Network access | Yes for Java 8, Java 11, Node.js, Python 3.7, PHP 7.2, PHP 7.3, Ruby 2.5 (beta), Go 1.11, Go 1.12, and Go 1.13. Python 2.7, Go 1.9, and PHP 5.5 (billing-enabled): Only via App Engine services (includes outbound sockets). |
Yes |
| Supports installing third-party binaries | Yes for Java 8, Java 11 Node.js, Python 3.7, PHP 7.2, PHP 7.3, Ruby 2.5 (beta), Go 1.11, Go 1.12, and Go 1.13. No for Python 2.7, Go 1.9, and PHP 5.5. |
Yes |
| Location | North America, Asia Pacific, or Europe | North America, Asia Pacific, or Europe |
| (Source: Cloud.google.com) | ||
Some App Engine features include zero-downtime for application deployment, scale-to-zero instances when there is no traffic, and traffic splitting between the latest and running version.
Understanding the App Engine Hierarchy
The App Engine hierarchy has four components - application, services, versions, and instances. An application that the customer needs is a combination of multiple services, where each service can have various versions that are deployed in instances.
The best use cases to use the App Engine are those where you want zero downtime and you don’t want to:
- configure and manage application infrastructure.
- control security, firewalls, and SSL certificates of an application.
- install and maintain packages required for the application.
It is better not to opt for App Engine when:
- having control over an underlying instance, configurations, and packages are required.
- you need to run the application with customized images.
Configuring an Application for the App Engine
The App Engine does not understand the source code for deployment. The source code needs to be refactored with the configuration file called app.yaml, where it’s important to mention the runtime and scale details.
Let’s discuss the information that the file app.yaml contains before taking a look at the sample file.
- Runtime environment: Mention the source-code runtime here so that the App Engine can set up an environment to support and deploy the code for public usage.
- Scaling information: Provide the information of scaling here, like what type of scaling is required to use for the application (automatic/basic/manual), how many instances will be available while scaling, and on how can it scales the application (on CPU utilization/concurrent requests/latency).
- Resources information: Mention the number of CPUs, memory_gb (RAM), and disk_size available for the application.
- Environment variables: Provide environment variables for the application, like passwords, API keys, etc., so that the application can use them securely.
It also contains information like health checks, network issues, etc. Let’s look at them directly in the sample app.yaml
service: my-service
runtime: nodejs10
instance_class: B8
automatic_scaling:
target_cpu_utilization: 0.6
min_instances: 1
max_instances: 15
cool_down_period_sec: 180
min_pending_latency: 30ms # default value
max_pending_latency: automatic
max_concurrent_requests: 50
env_variables:
BUCKET_NAME: "example-gcs-bucket"
network:
instance_tag: TAG_NAME
name: NETWORK_NAME
subnetwork_name: SUB_NETWORK_NAME
forwarded_ports:
- PORT
- HOST_PORT: CONTAINER_PORT
- PORT/tcp
- HOST_PORT: CONTAINER_PORT/udp
resources:
cpu: 2
memory_gb: 2.3
disk_size_gb: 10
volumes:
- name: ramdisk1
volumem_type: tmpfs
size_gb: 0.5
liveness_check:
path: "/liveness_check"
check_interval_sec: 30
timeout_sec: 4
failure_threshold: 2
success_threshold: 2
(Source: Cloud.google.com)
Understanding APP Engine Deployment, Versions, Migrating Traffic, and Switching Between Versions
The App Engine makes the application deployment process easy and fast. It can deploy the application by just typing "gcloud app deploy app.yaml." Also, it can have multiple versions for each service and seamlessly migrating traffic from one version to another in the App Engine using a flag called ‘migrate.’ It can deploy and route the entire traffic to the latest version of the application with zero downtime.
The command mentioned below will migrate the entire traffic to version 2:
"gcloud app services set-traffic [MY_SERVICE] --splits [MY_VERSION]=2 --migrate"
It can also easily switch between the versions whenever any function is not working or when a new version is available.
The App Engine can quickly get the logs of our application from the stack driver logger, which saves all the log files by default. These logs will be visible only when they are filtered by selecting the Google App Engine option. The App Engine enables the stack driver cloud debugging and monitoring by default.
Steps to Deploy an Application in the App Engine
With the above information, it is easy to understand the process of deploying an application in the App Engine, as mentioned below:
- Go to the Google Cloud console and create an App Engine with runtime – ‘Node.js’ and environment – ‘standard’ present under ‘compute.’
- Open cloud shell and clone the source code from the repo https://github.com/vishnu123sai/App-engine-example.git
- Configuration file app.yaml is also available in the repo. In this example, other options like scaling, resources, etc. in the configuration file are not being used for the sake of simplicity.
- Type “gcloud app deploy” to deploy your application.
- Once the application is deployed, the output on the link [PROJECT_ID].appspot.com will be visible.
For example, if the project id is vital-framing-245415, then the application URL will be https://vital-framing-245415.appspot.com/ - Test the URL on chrome
Congratulations! Your application is successfully deployed on the App Engine.
Vishnuvardhan Nayakam
Associate Software Engineer
Published Feb 05 2020
