This advanced example demonstrates how to build a logbook app that uses node.js for its frontend and MySQL for its backend. The template also creates and connects an HTTP load balancer that load balances across two zones, and an autoscaler to automatically scale the app.
This example assumes you are familiar with Docker containers, as well as Compute Engine resources, particularly HTTP load balancing, autoscaling, managed instance groups, and instance templates.
For more introductory tutorials, refer to the Getting started guide or the Step-by-step guide .
Before you begin
- If you want to use the command-line examples in this guide, install the `gcloud` command-line tool .
- If you want to use the API examples in this guide, set up API access .
- Familiar with Compute Engine HTTP load balancing .
- Familiar with Docker containers .
Creating your templates
This example launches a deployment with several types of resources. To start, you will create reusable templates that define these resources separately. Later on, you will use these templates in your final configuration.
At the end of this example, you will have a deployment that contains these resources:
- A single Compute Engine instance for the backend MySQL virtual machine.
- An instance template that uses a Docker image.
- Two autoscaled managed instance groups in two different zones, running the frontend node.js service.
- Another two autoscaled managed instance group serving static data.
- A health check and a HTTP load balancer to distributed traffic across the respective managed instance groups.
Creating the backend templates
The backend of this app is a single Compute Engine instance running a MySQL
Docker container. Create a template that defines a Compute Engine instance
that uses a container-optimized image. Name the file container_vm.[py|jinja]
:
Jinja
Python
The template defines a number of variables, such as the containerImage
and the manifest
, which will be filled in when you define your configuration
. This template alone just creates a
single virtual machine (VM) instance.
When you use container images on Compute Engine instances, you also need to
provide a manifest file (different from a Deployment Manager manifest) to
describe to Compute Engine which container image to use. Create a helper
method called container_helper.[py|jinja]
to dynamically define the container
manifest:
Jinja
Python
Creating the frontend templates
The frontend of this app runs Node.js and allow users to post messages to the web page. There will be two managed instance groups that contain two instances each: a primary managed instance group, and a secondary managed instance group for load balancing.
To create these frontend templates, use the following instructions.
-
Create an instance template.
You need an Instance Template resource to create a managed instance group, which is a group of identical VM instances that are centrally managed. This example creates a managed instance group for the frontend node.js instances, but first, you must create the Instance Template.
Define a file named
container_instance_template.[py|jinja]:Jinja
Python
-
Create an autoscaled managed instance group.
Now that you have an instance template, you can define a template that uses the instance template to create an autoscaled managed instance group. Create a new file named
autoscaled_group.[py|jinja]with the following contents:Jinja
Python
Create the corresponding schema file:
Jinja
Python
-
Create resources using these templates.
Up to this point, you defined base templates that determine the properties of your resources. Using these templates, define the setup of your frontend. Create a new file named
service.[py|jinja]with the following contents:Jinja
Python
Create the corresponding schema file:
Jinja
Python
Let's break down what this template is creating:
-
Two managed instance groups, one primary and one secondary.
The template uses the
autoscaled_group.[py|jinja]template to create a primary and secondary autoscaled managed instance group. -
Next, the template creates a backend service and health checker. A backend service is required for HTTP load balancing, and it defines the serving capacity of the instance groups in that backend service. In this case, the primary and secondary managed instance groups are part of this backend, and the default properties of the backend service apply.
By default, a backend service performs load balancing based on CPU utilization of the associated instance groups, but you can also load balance based on requests per second (RPS).
Note:A health check is always required when creating a backend service.
-
Creating a unifying template
Lastly, create a unifying template that combines both the backend and frontend
templates. Create a new file named application.[py|jinja]
:
Jinja
Python
Create a corresponding schema file:
Jinja
Python
In addition to the frontend and backend, the template also defines some additional resources:
-
A static service with primary and secondary managed instance groups. This static service serves a webpage located at the
/staticpath in your app. -
A URL Map resource. HTTP load balancing requires a URL map to map the different URLs to correct paths. In this case, the default path, indicated by the
defaultServiceproperty, is the backend service that you created earlier. If a user navigates to/static, the URL map will map that path to the static service, as defined in thepathMatcherssection. -
A global forwarding rule and target HTTP proxy. Since the app is being load balanced across two separate zones, you will need a global forwarding rule that serves a single external IP address. In addition, a target HTTP proxy is required for the HTTP load balancing setup.
-
A firewall rule that allows traffic through port 8080.
Creating your configuration
Now that you have your templates and related schemas ready, you can create a
configuration that deploys these resources. Create a configuration file named application.yaml
with the following contents, and replace ZONE_TO_RUN
and SECONDARY_ZONE_TO_RUN
with the primary and secondary zones of your choice.
Jinja
Python
Deploying your configuration
Now, let's deploy your resources. Using the Google Cloud CLI, run the
following command, optionally choosing to replace advanced-configuration-l7
with a deployment name of your choice. Keep in mind that your deployment name
will automatically be used to name the resources.
In this example, the deployment name is advanced-configuration-l7
. If you opt
to change the deployment name, make sure to use that deployment name in all
of the following examples.
gcloud deployment-manager deployments create advanced-configuration-l7 --config application.yaml
The response should look similar to the following resources:
Waiting for create operation-1469468950934-5387966d431f0-49b11bc4-1421b2f0...done. Create operation operation-1469468950934-5387966d431f0-49b11bc4-1421b2f0 completed successfully. NAME TYPE STATE ERRORS advanced-configuration-l7-application-fw compute.v1.firewall COMPLETED [] advanced-configuration-l7-application-l7lb compute.v1.globalForwardingRule COMPLETED [] advanced-configuration-l7-application-targetproxy compute.v1.targetHttpProxy COMPLETED [] advanced-configuration-l7-application-urlmap compute.v1.urlMap COMPLETED [] advanced-configuration-l7-backend compute.v1.instance COMPLETED [] advanced-configuration-l7-frontend-bes compute.v1.backendService COMPLETED [] advanced-configuration-l7-frontend-hc compute.v1.httpHealthCheck COMPLETED [] advanced-configuration-l7-frontend-it compute.v1.instanceTemplate COMPLETED [] advanced-configuration-l7-frontend-pri-as compute.v1.autoscaler COMPLETED [] advanced-configuration-l7-frontend-pri-igm compute.v1.instanceGroupManager COMPLETED [] advanced-configuration-l7-frontend-sec-as compute.v1.autoscaler COMPLETED [] advanced-configuration-l7-frontend-sec-igm compute.v1.instanceGroupManager COMPLETED [] advanced-configuration-l7-static-service-bes compute.v1.backendService COMPLETED [] advanced-configuration-l7-static-service-hc compute.v1.httpHealthCheck COMPLETED [] advanced-configuration-l7-static-service-it compute.v1.instanceTemplate COMPLETED [] advanced-configuration-l7-static-service-pri-as compute.v1.autoscaler COMPLETED [] advanced-configuration-l7-static-service-pri-igm compute.v1.instanceGroupManager COMPLETED [] advanced-configuration-l7-static-service-sec-as compute.v1.autoscaler COMPLETED [] advanced-configuration-l7-static-service-sec-igm compute.v1.instanceGroupManager COMPLETED []
Adding service labels
Next, specify the appropriate service labels for your managed instance groups. Service labels are metadata used by the load balancing service to group resources.
To add service labels, run the following commands, matching the primary and secondary zones to the zones you selected in your deployment configuration file:
gcloud
compute
instance
-
groups
unmanaged
set
-
named
-
ports
advanced
-
configuration
-
l7
-
frontend
-
pri
-
igm
\
--named-ports http:8080,httpstatic:8080 \
--zone [PRIMARY_ZONE]
gcloud
compute
instance
-
groups
unmanaged
set
-
named
-
ports
advanced
-
configuration
-
l7
-
frontend
-
sec
-
igm
\
--named-ports http:8080,httpstatic:8080 \
--zone [SECONDARY_ZONE]
Testing your configuration
To test your configuration, get the external IP address that is serving traffic by querying the forwarding rule:
gcloud compute forwarding-rules list | grep advanced-configuration-l7-l7lb advanced-configuration-l7-l7lb 107.178.249.126 TCP advanced-configuration-l7-targetproxy
In this case, the external IP is 107.178.249.126
.
In a browser, visit the external IP address at port 8080. For example,
if your external IP is 107.178.249.126
, the URL would be:
http://107.178.249.126:8080
You should see a blank page, which is expected. Next, post a message to the page. Go to the following URL:
http://107.178.249.126:8080?msg=hello_world!
You will see confirmation that your message was added. Navigate back to the main URL and now the page should have the message:
hello_world!
You can also visit the static page you created, or check the health of your app, by visiting the following URLs:
#
Static web page
http://107.178.249.126:8080/static #
Health check
http://107.178.249.126:8080/_ah/health
Congratulations, you've deployed your configuration successfully.
(Optional) Creating Docker images
Docker allows you to automate and run software inside containers. Containers allow you to isolate different services within containers that can all run on a single Linux instance.
This example used some existing Docker images, but you can also create your own versions of these Docker images. You can find the instructions for creating the MySQL backend images and the Node.js frontend images in the Creating your resource templates section.
To create the Docker image that serves the static webpage:
-
Create a new VM instance with a container-optimized image:
gcloud compute instances create docker - playground \ -- image - family container - vm \ -- image - project google - containers \ -- zone us - central1 - a \ -- machine - type f1 - micro -
Connect to the instance:
gcloud compute ssh --zone us-central1-a docker-playground -
Create a file named
Dockerfilewith the following contents:FROM node : latest RUN mkdir / var / www / ADD service . js / var / www / service . js WORKDIR / var / www / RUN npm install mysql CMD [ "node" , "service.js" ] -
Create a file named
service.jswith the following contents:var http = require ( 'http' ); var url = require ( 'url' ); console . log ( 'Started static node server' ) http . createServer ( function ( req , res ) { reqUrl = url . parse ( req . url , true ); res . useChunkedEncodingByDefault = false ; res . writeHead ( 200 , { 'Content-Type' : 'text/html' }); if ( reqUrl . pathname == '/_ah/health' ) { res . end ( 'ok' ); } else if ( reqUrl . pathname == '/exit' ) { process . exit ( - 1 ) } else { res . end ( 'static server' ); } }) . listen ( 8080 , '0.0.0.0' ); console . log ( 'Static server running at http://127.0.0.1:8080/' ); -
Build the Docker image, replacing
usernamewith your Docker Hub username. If you do not have a Docker Hub username, create one first before building the Docker image.sudo docker build --no-cache -t username/nodejsservicestatic . -
Push the images to the Docker repository:
sudo docker push username/nodejsservicestatic
Now you have the Docker images to run Node.js and MySQL. You can actually see
these images on the repository
by searching
for the image names. To try the images out, you can replace all instances of gcr.io/deployment-manager-examples/mysql
and gcr.io/deployment-manager-examples/nodejsservice
with your respective images.
Next steps
Once you've completed this sample, you can:
- Continue to build off of this example by creating a more robust webpage, or adding more services to the web server.
- Read more about configurations or deployments .
- Try creating your own configurations.
