Google Cloud Account for Sale: Deploy Web Applications with GCP Cloud Run 5 Minutes Serverless (Serverless)
As a developer or architect, when you finish writing an excellent Web application (whether it's Node.js, Python Flask, Go or Java Spring Boot), the most resistant thing is not to change the Bug, but to do so.
Deployment
.
The traditional deployment process is simply a time-wasting machine: you have to buy a VM virtual machine, match the operating system, install the Docker environment, and match the inbound rules of various security groups. When the traffic is large, you have to consider how to balance the load and match the cluster. When the traffic is gone, you have to watch the server idling and the card withholding money in vain. Self-built K8s cluster is certainly high, but the high operation and maintenance threshold and hardware budget can directly kill a small team.
In the ecology of Google Cloud(GCP, Google Cloud), there is a dimension reduction strike designed to liberate development productivity, called
Cloud Run
.
Its core logic is extremely pure:
Serverless (serverless) containerization
. All you need to do is package your application into a standard Docker image and throw it at it, and it will spit out a public network website with its own HTTPS certificate, its own global load balancing and its own automatic elastic scaling within 5 minutes.
The most invincible is its billing model:
Full on-demand billing, support scale to 0(Scale to Zero)
. This means that if no one visits your site, it doesn't take up any CPU or memory, and Google doesn't deduct a penny.
Today we don't back official concepts and refuse nonsense. Take your code, let's talk directly from the core architecture, and take you hand in hand to seamlessly launch your first Serverless web application within 5 minutes.
The first stage: deep dismantling, Cloud Run's "minimalist world model"
Before you start the deployment, you must clear up the underlying physical operation logic of Cloud Run in your mind, otherwise you will be blind when you enter the console to face various concurrent and memory parameters.
The underlying data flow of the entire system is seamlessly welded by three core components:
Container Image Library (Artifact Registry): Code your container terminal. This is GCP's new generation mirror warehouse, replacing the old GCR. Your application will be packaged as a Docker image and stored here.
Cloud Run Service (Service): Your Serverless scheduling brain. It's responsible for staring at the mirror image. When an HTTP request comes in from the public network, it will pull up the image into a container instance (Instance) to pick up the customer.
Auto-scaling engine: Your traffic traffic. If 10,000 people initiate a request at the same time, it will instantly pull up dozens of containers in the background to share the pressure. If no one visits for several minutes, it will physically destroy all containers,
Enter 0 cost sleep state.
The second stage: actual combat exercise -5 minutes fast on-line assembly line
Let's assume that you have written a basic Node.js or Python web application locally, and that you have installed Docker and GCP command line tools (gcloud CLI) locally.
Step 1: "Containerization" of local codes (Dockerfile)
In your project root directory, create a new standard
Dockerfile
File. Here is an example of the simplest Node.js application:
# Use the official lightweight Node image
FROM node:18-slim
# Set the working directory
WORKDIR /usr/src/app
# Copy dependency configurations and install them
COPY package*.json ./
RUN npm install --only=production
# Copy the whole package code
COPY . .
# Expose the port (Note: Cloud Run will inject an environment variable named PORT into the container by default, usually 8080)
EXPOSE 8080
# Start command, must listen to 0.0.0.0
CMD [ "node", "server.js"]
Core Pit Avoidance Guide: In your application code, the listening IP must not be written to 127.0.0.1, but must listen to 0.0.0.0. The port directly reads the environment variable process.env.PORT. For Python, the startup command is written as CMD ["gunicorn", "-- bind", "0.0.0.0:8080", "main:app"]. If the monitoring is wrong, when Cloud Run starts, it will directly report an error and downtime because it cannot get the heartbeat response of the container.
Step 2: Create a Mirror Docker in GCP (Artifact Registry)
Open your terminal and use
gcloud
command to build a Docker repository in the region closest to you. Suppose we choose the Taiwan region of China (
asia-east1
), the project ID is called
my-serverless-project
:
gcloud artifacts repositories create my-docker-repo \
--repository-format=docker \
--location=asia-east1 \
--description="My
Serverless App Repo"
Step 3: Package locally and push the stream to the cloud
Use local Docker to compile the image and include the full GCP repository path in the name.
Align the secret code (configure Docker authentication certificate):Bashgcloud the auth configure-docker asia-east1-docker.pkg.dev
Compile and package: Bashdocker build -t asia-east1-docker.pkg.dev/my-serverless-project/my-docker-repo/web-app:v1.0.
Full push: Bashdocker push asia-east1-docker.pkg.dev/my-serverless-project/my-docker-repo/web-app:v1.0
Looking at the familiar progress bar on the terminal, your container has been firmly lying in Google's distributed secure cloud.
Step 4: Best Moment-Activate Cloud Run with One Click
Return to
GCP Console
, search and enter
Cloud Run
Page.
Click the top
Create Service"
, enter the core configuration battlefield:
Deploy a revision: Click Select to select the web-app you just pushed up: v1.0 Image.
Service name: named my-web-service.
Region (Region): It is strongly recommended to keep consistent with the mirror warehouse, choose asia-east1 (Taiwan), and the domestic access network latency is extremely low.
Automatic scaling (Autoscaling): Minimum number of instances: enter 0 (turn on black technology without access and no deduction). Maximum number of instances: Enter 10 at the beginning of the test to prevent cost overruns caused by malicious brush traffic.
Authentication (Authentication): As a public-facing web application, do not hesitate to check "Allow unauthenticated calls (Allow unauthenticated invocations)". If you don't check it, people outside will be rejected by Google's return 403.
Click on the bottom
“Create”
.
The third stage: on-line verification and "cold start" real scene
After clicking create, stare at the small circle on the screen. Cloud Run will automatically configure load balancing, domain name mapping, and SSL encrypted tunnels for you in the background.
Usually only
30 seconds to 1 minute
, the top of the console will light up with a big green check mark and spit out a shape like htt for you.
ps://
my-web-service-xxxx-de.a.run.app
The official HTTPS permanent URL.
Click on this website, the web page will open in seconds! Congratulations, your Serverless web application has been completely famous.
Hardcore insider experiment: what is a "cold start"?
In order to verify the power of "shrinking to 0", please close the web page, take your hands off the keyboard, and wait quietly for 15 minutes.
At this point, go to the console monitoring indicators (Metrics) to take a look, you will find that the number of active instances in the background (Active Instances) has been completely zero. At this moment,
Since no instances are running, your bill hourglass is completely stationary.
Now, click again to open that public web site. You will find that the web page did not open in seconds as before, but was slightly stuck for about
1 to 2 seconds
Brush it out afterwards.
Tech Insider: This is the streaming and Serverless world's famous "Cold Start". Because no one visited in the first 15 minutes, Google emptied your container completely. When you click again, the system must temporarily schedule physical machine resources in the background, re-Download your Docker image, decompress, and start the main program. This delay of 1 to 2 seconds is a small price to pay for extreme savings.
Phase 4: The history of avoiding tears in the commercial-grade architecture and the tuning of large factory indicators.
This Serverless architecture is extremely easy to use, but in a true enterprise-level high-concurrency production environment, operations architects must immediately perform "fine surgery" on the default parameters, otherwise they will accidentally step into the following two bloody pits:
1. Burst the "Zombie Concurrency Wall" of the back-end database"
Many novice developers think that since Cloud Run can automatically expand indefinitely, I will set the maximum number of instances to 1000. As a result, as soon as the Black Five promotion arrived, the traffic soared, and Cloud Run was extremely dedicated to pulling up 500 containers to pick up customers in an instant.
Disaster occurs: 500 containers initiate connection requests to the Cloud SQL relational database at the back end at the same time at the moment of startup. The maximum number of connections to a traditional MySQL database may be only 200. As a result, the database is directly destroyed by sudden traffic, resulting in overall business paralysis.
Large factory standard solution: enter the "container, connection, security" advanced settings of Cloud Run: increase the "maximum concurrent number (Maximum concurrency)" from the default value (e.g. set to 80 or even 100). This means that a container instance is allowed to handle 80 concurrent HTTP requests at the same time. Only when these 80 pits are full will Google pull new containers. Cooperate to set up a connection pool in front of the back-end database (Connection
Pool), deadlocks the maximum expansion limit to protect vulnerable back-end core assets.
2. Can't stand the "cold start" of the game
If your business is an extremely core online e-commerce payment, or an API interface that is extremely sensitive to delay, users may give up payment directly if they encounter a cold start of 2 seconds during payment.
Architect tuning trick: there is no free lunch. If you want to completely eliminate cold start, go to the shrink-in setting and change the "minimum number of instances (Minimum instances)" from 0 to 1.
Cost and Benefit: After changing to 1, even if no one visits in the middle of the night, Google will keep a low-priced container for you in the computer room. Although this will result in a small fixed minimum insurance fee (about a few dollars a month), it will be exchanged for 24-hour access by users around the world, which will always be in milliseconds, completely smoothing out the experience defects caused by cold start.
Summary
Using GCP Cloud Run to play with Serverless deployment, the core industrial essence lies in 16 words:
Mirror encapsulation, expansion on demand, control scaling, stuck concurrency
.
You no longer need to waste precious time on installing operating systems, repairing firewalls and other trivial system operations. As long as your code can run locally into Docker containers, Cloud Run can provide you with an enterprise-level front-end line of defense with unlimited flexibility, automatic disaster tolerance, and extremely restrained budget. This is the most authentic and elegant development posture in the modern cloud native era.
