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.
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:
|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|
|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)|
|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
|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).
|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.
|Location||North America, Asia Pacific, or Europe||North America, Asia Pacific, or Europe|
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.
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:
It is better not to opt for App Engine when:
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.
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
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.
With the above information, it is easy to understand the process of deploying an application in the App Engine, as mentioned below:
Congratulations! Your application is successfully deployed on the App Engine.