GCP - App Engine - Quickstart (Java)

Introduction

This tutorial shows you how to deploy a sample Java  application to Google App Engine using the App Engine Maven plugin.
Here are the steps you will be taking.

• Build and run your "Hello, world!" app
  You will learn how to run your app using Google Cloud Shell, right in your browser. At the end you'll deploy your app to the web using the App Engine Maven plugin.
• After the app...
  Your app will be real and you'll be able to experiment with it after you deploy, or you can remove it and start fresh.

Using Google Cloud Shell

Cloud Shell is a built-in command line tool for the console. We're going to use Cloud Shell to deploy our app.

1. Open Google Cloud Shell
   Open Cloud Shell by clicking
   from the navigation bar at the top. show me how
2. Clone the sample code
   Use Cloud Shell to clone and navigate to the "Hello World" code. The sample code is cloned from your project repository to the Cloud Shell.
   In Cloud Shell enter:
   Clone a sample repository:
   

   TUTORIALDIR=src/crawler-188409/java_gae_quickstart-2017-12-21-14-03

git clone https://github.com/GoogleCloudPlatform/appengine-try-java.git $TUTORIALDIR

Switch to the tutorial directory:

cd $TUTORIALDIR

Configuring your deployment

2. 
   You are now in the main directory for the sample code. We'll look at the files that configure your application.
   

   1. Exploring the application
      Enter the following command to view your application code:
      

      cat src/main/java/myapp/DemoServlet.java

3. This servlet responds to any request by sending a response containing the message Hello, world!.
4. Exploring your configuration
   For Java, Google App Engine uses XML files to specify a deployment's configuration.
   Enter the following command to view your configuration file:
   

   cat pom.xml

The helloworld app uses Maven, which means you must specify a Project Object Model, or POM, which contains information about the project and configuration details used by Maven to build the project.

 Testing your app

1. Test your app on Cloud Shell
   Cloud Shell lets you test your app before deploying to make sure it's running as intended, just like debugging on your local machine.
   To test your app enter:
   

   mvn appengine:run

2. Preview your app with "Web preview"
   Your app is now running on Cloud Shell. You can access the app by using "Web preview" to connect to port 8080. show me how
3. Terminating the preview instance
   Terminate the instance of the application by pressing Ctrl+C in the Cloud Shell
   
   

   Create the application

   In order to deploy our app, we need to create an App Engine application. This sets up the app and selects a region.
   To create your app enter:
   

   gcloud app create

   Last steps

   1. Deploying with Cloud Shell
      You can use Cloud Shell to deploy your app. To deploy your app enter:
      

      gcloud config set project crawler-188409

   mvn appengine:deploy

   2. Visit your app
      Congratulations! Your app has been deployed. The default URL of your app is crawler-188409.appspot.com  Click the URL to visit it.
   3. View your app's status
      You can check in on your app by monitoring its status on the App Engine dashboard.
      Open the menu on the left side of the console.
      Then, select the App Engine section.
      
      

      Congratulations

      You have successfully deployed an App Engine application! Here are some next steps:
      
      1. Download the Google Cloud SDK and develop locally
      1. After it downloads, extract the file  and initialize the SDK .
         
      2. Build your next application Learn how to use App Engine with other Cloud Platform products:Learn to use Cloud Datastore Cloud Datastore is a highly-scalable NoSQL database for your applications.
         

         Learn to use Cloud Datastore

         Cloud Datastore is a highly-scalable NoSQL database for your applications. 

         Learn to use Cloud Storage

         Cloud Storage is a powerful and simple object storage service.

          

         .

Securely Connecting to VM Instances on GCE (GCP compute engine)

When developing projects on Google Compute Engine, there are a variety of scenarios in which you want to keep the instances from being reached from the public Internet:

• Web services are still under development and not ready to be exposed to external users because they are feature incomplete or have not yet been configured with HTTPS.
• Instance might be providing services designed to be only consumed by other instances in the project.
• Instances should only be reached through dedicated interconnect options from company offices or data centers.

Even when a service is intentionally Internet-facing, it is important that communication with the service be restricted to the target user groups, and occur over secure channels, such as SSH or HTTPS, to protect sensitive information.
This article demonstrates several methods for securing communications with Compute Engine instances with or without external IP addresses.

Protecting services on machines with external IP addresses

• Firewalls
• HTTPS and SSL
• Port forwarding over SSH
• SOCKS proxy over SSH

Connecting to instances without external IP addresses

• Bastion hosts and SSH-agent forwarding
• VPN
• NAT gateway for egress
• Interactive serial console access

Protecting services on machines with external IP addresses

When instances have a public IP address, it is important that only the services and traffic you intend to be exposed are reachable, and for those that are exposed, any sensitive information is secured in transit.

Firewalls

Your first line of defense is to restrict who can reach the instance using firewalls. By creating firewall rules, you can restrict all traffic to a network or target machines on a given set of ports to specific source IP addresses.
Firewalls are not a standalone solution. Restricting traffic to specific source IPs does not protect sensitive information, such as login credentials, commands that create or destroy resources or files, or logs. When running a web service on a publicly-accessible machine, such as a Google Compute Engine instance with an external IP, you need to encrypt all communication between your host and the deployed instance to ensure proper security.
In addition, firewalls aren't always the appropriate solution. For example, firewalls are not ideal for development environments that do not have static IP addresses, such as roaming laptops.

HTTPS and SSL

For production web systems, you should configure HTTPS/SSL. HTTPS/SSL can be set up either by setting up an instance to terminate HTTPS or by configuring HTTPS load balancing. HTTPS/SSL does involve some initial complexity, requiring you to perform the following tasks:

• Register a domain name
• Acquire an SSL certificate from a certificate authority
• Register the certificate with your HTTPS load balancer and its connected instances, or configure an SSL-terminated web server or proxy on one or more Compute Engine instances.

If you have set up SSL-serving domains before, it should be straightforward to do the same with Google Compute Engine. If not, you might find it easier to use a different security method, such as port forwarding or SOCKS proxy.

Port forwarding over SSH

You can use the gcloud command-line tool to start a server on a given local port that forwards all traffic to a remote host over an SSH connection.
First, take note of the instance and port that are providing the service to which you would like to establish a secure connection. Next, run the following command:

gcloud compute ssh example-instance \
    --project my-project \
    --zone us-central1-a \
    --ssh-flag="-L" \
    --ssh-flag="2222:localhost:8888"

In the above command, the parameters are defined as follows:

• example-instance is the name of the instance to which you'd like to connect.
• my-project is your Google Cloud Platform project ID.
• us-central1-a is the zone in which your instance is running.
• 2222 is the local port you're listening on.
• 8888 is the remote port you're connecting to.

With these example settings, if you open http://localhost:2222/ in your browser, the HTTP connection will go over the SSH tunnel you have just created over to your remote host and connect to the specified instance via SSH and then connect to port 8888 on the same machine, but over an encrypted, secure SSH connection.
The gcloud command creates and maintains an SSH connection, and this approach only works while the SSH session is active. As soon as you exit the SSH session that gcloud creates, port forwarding via http://localhost:2222/ will stop working.
If you want to create more than one port forwarding rule, you can specify multiple rules on a single command line by repeating the flags:

gcloud compute ssh example-instance \
    --project my-project \
    --zone us-central1-a \
    --ssh-flag="-L" \
    --ssh-flag="2222:localhost:8888" \
    --ssh-flag="-L" \
    --ssh-flag="2299:localhost:8000"

Alternatively, you can run a new gcloud command each time to create a separate tunnel. Note that you cannot add or remove port forwarding from an existing connection without exiting and re-establishing the connection from scratch.

SOCKS proxy over SSH

If you want to connect to a number of different hosts in your cloud deployment, the easiest way to do so is to change your browser to do the lookups directly from your network. This approach allows you to use the short name of the hosts instead of looking up each host's IP address, opening up ports for each service, or creating an SSH tunnel for each host/port pair.
The approach that you use here is as follows:

1. Set up a single SSH tunnel to one of the hosts on the network, and create a SOCKS proxy on that host.
2. Change the browser configuration to do all the lookups via that SOCKS proxy host.

Note that because you are tunneling all traffic via that host, you don't want to browse the web in general using that browser or that specific profile, as you will use your cloud service's bandwidth for this. In general, you might want to use a separate browser profile and switch to it when necessary.

Start the SOCKS proxy

To start your SOCKS proxy, run the following command:

gcloud compute ssh example-instance \
    --project my-project \
    --zone us-central1-a \
    --ssh-flag="-D" \
    --ssh-flag="1080" \
    --ssh-flag="-N"

In the above command, the parameters are defined as follows:

• example-instance is the name of the instance to which you would like to connect.
• my-project is your Google Cloud Platform project ID.
• us-central1-a is the zone in which your instance is running.
• 1080 is the local port you're listening on.

Note that, in this case, you don't need to specify a remote port. Because a SOCKS proxy does not bind to any specific remote port, any connection you make via the SOCKS proxy will be resolved relative to the host you connect to.
By using a SOCKS proxy, you can connect to any instance that shares a Compute Engine network with your proxy instance by using the instance's short name. In addition, you can connect to any port on a given instance.
This approach is much more flexible than the simple port-forwarding method, but will also require you to change the settings in your web browser to utilize the proxy.
Next, configure your browser to use the proxy.

Chrome setup for SOCKS proxy

Chrome uses system-wide proxy settings by default, so you need to specify a different proxy using command-line flags. Launching Chrome by default creates an instance of an already-running profile, so to enable you to run multiple copies of Chrome simultaneously, one which is using the proxy and others which are not, you need a new profile.
Launch Chrome using a new profile. It will be created automatically if it does not exist.
Linux:

/usr/bin/google-chrome \
    --user-data-dir="$HOME/chrome-proxy-profile" \
    --proxy-server="socks5://localhost:1080"

Mac OS X:

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
    --user-data-dir="$HOME/chrome-proxy-profile" \
    --proxy-server="socks5://localhost:1080"

Windows:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" ^
    --user-data-dir="%USERPROFILE%\chrome-proxy-profile" ^
    --proxy-server="socks5://localhost:1080"

Be sure to set the localhost port to the same value that you used in the gcloud command earlier (1080 in our example).

Firefox setup for SOCKS proxy

Before changing these settings, you may want to create a new Firefox profile. Otherwise, it will affect all instances of Firefox to use that host as a proxy, which is very likely not what you want.
After you have Firefox running with a separate profile, you can set up the SOCKS proxy:

1. Open Preferences.
2. Click Advanced > Networks > Settings to open the Connection Settings dialog.
3. Choose the option Manual proxy configuration
   • In the SOCKS Host section, fill in localhost as the host and the port you selected when you ran the gcloud command earlier.
   • Choose SOCKS v5.
   • Check the box Remote DNS.
   • Leave all other entries blank.
4. Click OK and close the Preferences dialog box.

Connecting to instances without external IP addresses

When instances do not have external IP addresses they can only be reached by other instances on the network, or via managed VPN gateway. You can provision instances in your network to act as trusted relays for inbound connections (bastion hosts) or network egress (NAT Gateways). For more transparent connectivity without setting up such connections, you can use a managed VPN gateway resource.

Bastion hosts

Bastion hosts provide an external facing point of entry into a network containing private network instances. This host can provide a single point of fortification or audit and can be started and stopped to enable or disable inbound SSH communication from the Internet.

By using a bastion host, you can connect to an instance that does not have an external IP address. This approach allows you to connect to a development environment or manage the database instance for your external application, for example, without configuring additional firewall rules.
A complete hardening of a bastion host is outside the scope of this article, but some initial steps taken can include:

• Limit the CIDR range of source IPs that can communicate with the bastion.
• Configure firewall rules to allow SSH traffic to private instances from only the bastion host.

By default, SSH on instances is configured to use private keys for authentication. When using a bastion host, you log into the bastion host first, and then into your target private instance. Because of this two-step login, which is why bastion hosts are sometimes called "jump servers," you should use ssh-agent forwarding instead of storing the target machine's private key on the bastion host as a way of reaching the target machine. You need to do this even if using the same key-pair for both bastion and target instances, as the bastion has direct access to only the public half of the key-pair.
To learn how to use a bastion host instance to connect to other instances on your Cloud Platform network, read Connecting to instances that do not have external IP addresses.

VPN

Cloud VPN lets you connect your existing network to your Google Cloud Platform network via an IPsec connection to a VPN gateway device. This allows direct routing of traffic from your premises to the private IP interfaces of Compute Engine instances. Traffic is encrypted as it transits over public links to Google.
For details on setting up, configuring, and using VPN with Compute Engine, see the Cloud VPN documentation.
To learn how to connect to instances on your Cloud Platform network through an existing VPN rather than through external IP addresses of instances, read Connecting to instances that do not have external IP addresses.

Traffic egress using NAT gateways

When an instance does not have an external IP address assigned it can not make direct connections to external services, including other Cloud Platform services. To allow these instances to reach services on the public Internet, you can set up and configure a NAT gateway machine, which can route traffic on behalf of any instance on the network. Be aware that a single instance should not be considered highly available, and can not support high traffic throughput for multiple instances.

Interactive serial console access

When an instance doesn't have an external IP address, you might still need to interact with the instance for troubleshooting or maintenance purposes. Setting up a Bastion host is one option but might require more setup than worthwhile for your needs. If you want to troubleshoot an instance without an external IP address, consider enabling interactive access on the serial console, which allows you to interact with an instance's serial console using SSH and run commands against the serial console.

GCP - Compute Engine - Quickstart

Build a to-do app with MEAN

15 minutes

In this quickstart, you'll use Compute Engine to create a two-tier application. The front-end VM runs a Node.js todo web app, and the back-end VM runs MongoDB.
This tutorial will walk you through:

• Creating and configuring two VMs
• Setting up firewall rules
• Using SSH to install packages on your VMs

Create a back-end VM

First, create the back-end VM that runs MongoDB. This server stores the to-do items.

1. Click the Create instance button
   Click the Create instance button.
2. Name the instance
   Enter a name (for example, "back-end") for this instance and press the Tab key to move to the next step
3. Select the machine type
   Select f1-micro . This will incur fewer charges. Learn more about pricing 
4. Select the boot disk image
   Select Ubuntu 14.04 LTS as your boot disk image for this tutorial.
5. Open HTTP firewall port
   Open HTTP firewall port
   Check Allow HTTP traffic. This is an easy way to open firewall 80 (HTTP) so the front-end and back-end VMs can communicate
6. Create the VM
   Create the VM
   Click Create to finish creating this instance
   
   

Create a front-end VM

While the back-end VM is spinning up, create the front-end VM that runs the Node.js todo application

1. Create the front-end VM
   Click Create Instance to create the front-end VM
2. Name the instance
   Enter a name (for example, "front-end") for this instance and press the Tab key to move to the next step
3. Select the machine type
   Select f1-micro . This will incur fewer charges. Learn more about pricing 
4. Select the boot disk image
   Select Ubuntu 14.04 LTS as your boot disk image for this tutorial.
5. Open HTTP firewall port
   Open HTTP firewall port
   Check Allow HTTP traffic. This is an easy way to open firewall 80 (HTTP) so the front-end and back-end VMs can communicate
6. Create the VM
   Create the VM
   Click Create to finish creating this instance

Install and run the back-end database (1)

1. SSH into the VM
   SSH into the VM
   Next to your back-end VM, click SSH to open a terminal window in your browser
2. Install and run the database
   Install and run the database
   Go to the terminal window and enter the commands to install and run MongoDB

Install and run the back-end database (terminal window)

Enter these commands to install and run MongoDB. You can use the keyboard to copy and paste each command line. Click Done when you finish entering all the commands to close the SSH window.

Update packages and install MongoDB. When asked if you want to continue, type 'Y'.

$ sudo apt-get update
$ sudo apt-get install mongodb
The MongoDB service started when you installed it. You must stop it so you can change how it runs.
$ sudo service mongodb stop


Create a directory for MongoDB and then run the MongoDB service in the background on port 80.
$ sudo mkdir $HOME/db ; sudo mongod --dbpath $HOME/db --port 80 --fork --logpath /var/tmp/mongodb
  

After you enter the final command, click Done and then confirm that you want to leave the page to close the SSH browser window.
 

Install and run the web app on your front-end VM

The MongoDB back-end server is running, so it is time to install the front-end web application

1. SSH into the VM
   SSH into the VM
   Next to your front-end VM, click SSH to open a terminal window in your browser
2. Install and run the web app on your front-end VM
   Install and run the web app on your front-end VM
   Go to the terminal window and enter the commands to install and run the sample todo app

Install and run the web app on your front-end VM (terminal window)

Enter these commands to install the todo web application. You can use the keyboard to copy and paste each command line. Click Done when you finished entering all the commands to close the SSH window.

Update packages and install git, Node.js and npm. When asked if you want to continue, type 'Y'.

$ sudo apt-get update

$ curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -

$ sudo apt-get install git nodejs

Clone the sample application and install application dependencies.
$ git clone https://github.com/GoogleCloudPlatform/todomvc-mongodb.git
$ cd todomvc-mongodb; npm install

Start the todo web application. Note: The IP addresses below are internal IPs for communication between servers. You can find these IP addresses on each server’s details page.

$ nohup nodejs server.js --be_ip 10.142.0.2 --fe_ip 10.142.0.3 &

After you enter the final command, click Done and then confirm that you want to leave the page to close the SSH browser window.

You're done

Your app is running at http://35.185.117.209:8080
The quickstart servers continue running until you remove them. This can reduce your available quotas.

Managing Google Cloud Projects

Google Cloud Platform projects form the basis for creating, enabling, and using all Cloud Platform services including managing APIs, enabling billing, adding and removing collaborators, and managing permissions for Cloud Platform resources.
This page explains how to create and manage Cloud Platform projects using the Google Cloud Resource Manager API and the Google Cloud Platform Console.

Before you begin

Read the Cloud Platform Project Overview.

Creating a project

You can create a new project using the Cloud Platform Console or the projects.create() method.

Console

API

PYTHON

To create a new project:

1. Go to the Cloud Platform Console Manage resources page.
   GO TO THE MANAGE RESOURCES PAGE
2. On the drop-down at the top of the page, select the organization in which you want to create a project.
3. Click Create Project
4. In the New Project window that appears, enter a project name and select a billing account as applicable.
5. If you want to add the project to a folder, enter the folder name in the Location box.
6. When you're finished entering new project details, click Create.

Managing project quotas

The number of projects left in your quota can be viewed when creating a new project, as in the Creating a Project steps above. When creating the project, this notification will be displayed with your number of remaining projects:

To request additional capacity for projects in your quota, see the Request Billing Quota Increase support page. More information about quotas and why they are used can be found at the Free Trial Project Quota Requests support page.

Identifying projects

To interact with Cloud Platform resources, you must provide the identifying project information for every request. A project can be identified in the following ways:

• Project ID: the customized name you chose when you created the project, or when you activated an API that required you to create a project ID. Note that you can't reuse the project ID of a deleted project.
• Project number: a number that's automatically generated by the server and assigned to your project.

To get the project ID and the project number:

1. Go to Google Cloud Platform Console.
2. Select your project.

Both the project ID and project number are displayed on the project Dashboard Project info card:

A project ID is different from a project name. The project name is a human-readable way to identify your projects, but it isn't used by any Google APIs. In the above example, the project name is project-example and the project ID is project-example-164317.
The project number and project ID are unique across Google Cloud Platform. If another user owns a project ID for their project, you won't be able to use the same project ID.
When you choose your project ID (or any resource names), don't include any sensitive information in your names.

Getting an existing project

You can get an existing project using the Cloud Platform Console or the projects.get() method.

Console

API

PYTHON

To view a project via the Cloud Platform Console:

• Go to the Google Cloud Platform Console.
• Click the projects drop-down on the top bar. (The drop-down label will be be name of your project you're currently viewing).
• Select the project you wish to view.

Listing projects

You can list all projects you own using the Cloud Platform Console or the projects.list() method.

Console

API

PYTHON

To list projects using the Cloud Platform Console:

• Go to the Google Cloud Platform Console.
• All your projects are listed in the projects drop-down on the top bar. Use the Search projects and folders textbox to filter projects.
• To list all your projects, click Manage Resources. Use the Filter by name, ID, or label textbox to filter your projects.

Updating projects

You can update projects using the Cloud Platform Console or the projects.update() method. Currently the only fields that can be updated are the project name and labels. For more information see the project API reference page.

Console

API

PYTHON

To update a project's field using the Cloud Platform Console:

• Open the Settings page in the Google Cloud Platform Console. Open the Settings page
• Click Select a project.
• To change the project name, edit Project name, then click Save.
• To change labels, click Labels on the left nav. Learn more about Using Labels.

Shutting down (deleting) projects

You can shut down projects using the Cloud Platform Console or the projects.delete() method.
Shutting down a project does not delete the project immediately; it only requests deletion of the project. The project is marked for deletion ("soft deleted"), and you will lose access to it immediately, but the project can be recovered for a 30 day period. Until actual deletion of the project, the project will count towards your quota usage.
The project owner will receive an email notification that the project has been marked for deletion. During the 30 day period, the owner can recover the project by following the steps to restore a project. After the 30 day period, the project and all the resources under it are wiped out and cannot be recovered.
To shut down a project:

• The project must not have a billing account associated with it.
• The project must have a lifecycle state of ACTIVE.

Console

API

PYTHON

To shut down a project using the Cloud Platform Console:

• Open the Settings page (found under IAM & admin) in the Google Cloud Platform Console.
  Open the Settings page
• Click Select a project.
• Select a project you wish to delete, and click Open.
• Click Shut down.
• Enter the Project ID, then click Shut down.

Quickstart for Java 8 for App Engine Standard Environment

Before you begin

Before running and deploying this sample, take the following steps:

1. Use the GCP Console to create a new GCP project, create an App Engine application:
   Go to App Engine When prompted, select the region where you want your App Engine application located.
   
2. Install the following prerequisites
   1. Download and install git.
   2. Download and install the Google Cloud SDK:
      Download the SDK
   3. After you download and install invoke the following commands:

      gcloud init
      gcloud auth application-default login

   4. Update to the latest version of Cloud SDK and all components:

       gcloud components update 

   5. This quickstart uses Apache Maven version 3.5 or greater to build, run, and deploy the sample app. For details about installing Maven, see Using Apache Maven and the App Engine Plugin.

This quickstart assumes that you have installed the Java SE 8 Development Kit (JDK).

Download the Hello World app

We've created a simple Hello World app for the Java 8 runtime so you can quickly get a feel for deploying an app to the App Engine standard environment.
Download the sample app and navigate into the app directory:

1. Clone the Hello World sample app repository to your local machine:
   

   git clone https://github.com/GoogleCloudPlatform/getting-started-java.git
   

   Alternatively, download the sample as a zip file and extract it.
   
2. Change to the directory that contains the sample code:
   

   cd getting-started-java/appengine-standard-java8/helloworld

Run Hello World on your local machine

To run the Hello World app on your local computer:

1. Start the local Jetty web server using the Jetty Maven plugin:
   

   mvn appengine:run

2. In your web browser, visit the following address:
   

   http://localhost:8080
   

3. You can see the Hello World message from the sample app displayed in the page.
   
4. In your terminal window, press Ctrl+C to exit the web server.
   

Deploy and run Hello World on App Engine

To deploy your app to the App Engine standard environment:

1. Deploy the Hello World app by running the following command from the getting-started-java/appengine-standard-java8/helloworld directory:
   

   mvn appengine:deploy

   Wait for the deployment to finish.
2. Launch your browser and view the app at http://YOUR_PROJECT_ID.appspot.com, by running the following command:
   

   gcloud app browse

This time, the page that displays the Hello World message is delivered by a web server running on an App Engine instance.
Congratulations! You've deployed your first Java 8 app to App Engine standard environment!
See the following sections for information about cleaning up as well as links to the possible next steps that you can take.

What's next

Learn the whole platform

Now that you know what it's like to develop and deploy App Engine apps, you can stretch out and see the rest of Google Cloud Platform. You already have the Google Cloud SDK installed and that gives you the tools to interact with products like Google Cloud SQL, Google Cloud Storage, Google Cloud Datastore, and more. For a guided walkthrough that teaches you how to create an application that uses the entire platform, not just App Engine, check out our quickstart on creating the Bookshelf app.

Learn about the App Engine standard environment

Here are some topics to help continue your learning about App Engine.

• An Overview of App Engine
• How Requests are Routed
• How Requests are Handled
• How Instances are Managed

Hello World code review

Hello World is the simplest possible App Engine app, as it contains only one service, has only one version, and all of the code is located within the app's root directory. This section describes each of the app files in detail.

HelloServlet.java

The HelloServlet.java file specifies a URL pattern that describes where the app will listen for requests, and responds to any requests with the 'Hello World' message.

appengine-standard-java8/helloworld/src/main/java/com/example/appengine/java8/HelloAppEngine.java

View on GitHub

import com.google.appengine.api.utils.SystemProperty;
import java.io.IOException;
import java.util.Properties;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
// With @WebServlet annotation the webapp/WEB-INF/web.xml is no longer required.
@WebServlet(name = "HelloAppEngine", value = "/hello")
public class HelloAppEngine extends HttpServlet {

  @Override
  public void doGet(HttpServletRequest request, HttpServletResponse response)
      throws IOException {
    Properties properties = System.getProperties();

    response.setContentType("text/plain");
    response.getWriter().println("Hello App Engine - Standard using "
            + SystemProperty.version.get() + " Java "
            + properties.get("java.specification.version"));
  }

  public static String getInfo() {
    return "Version: " + System.getProperty("java.version")
          + " OS: " + System.getProperty("os.name")
          + " User: " + System.getProperty("user.name");
  }
}

• For more information on how the Java 8 runtime works, see The Java 8 Runtime.

pom.xml

Hello World also includes a pom.xml file, which contains information about the project like its dependencies and the build target, including the required lines for using the Maven plugin:

appengine-standard-java8/helloworld/pom.xml

View on GitHub

<plugin>
  <groupId>com.google.cloud.tools</groupId>
  <artifactId>appengine-maven-plugin</artifactId>
  <version>1.3.1</version>
</plugin>

• For more information about pom.xml files, see the Maven documentation.

appengine-web.xml

The appengine-web.xml file contains certain required settings, such as the java8 setting for the <runtime> element that tells App Engine to run this application in the Java 8 runtime:

appengine-standard-java8/helloworld/src/main/webapp/WEB-INF/appengine-web.xml

View on GitHub

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <runtime>java8</runtime>
  <threadsafe>true</threadsafe>
</appengine-web-app>

Google App Engine (web framework and cloud computing platform)

Google App Engine (often referred to as GAE or simply App Engine) is a web framework and cloud computing platform for developing and hosting web applications in Google-managed data centers. Applications are sandboxed and run across multiple servers.^[1] App Engine offers automatic scaling for web applications—as the number of requests increases for an application, App Engine automatically allocates more resources for the web application to handle the additional demand.^[2]
Google App Engine is free up to a certain level of consumed resources. Fees are charged for additional storage, bandwidth, or instance hours required by the application.^[3] It was first released as a preview version in April 2008 and came out of preview in September 2011.

Contents

• 1 Supported features/restrictions
  • 1.1 Runtimes and framework
  • 1.2 Reliability and Support
  • 1.3 Bulk downloading
  • 1.4 Restrictions
• 2 Major differences
  • 2.1 Differences with other application hosting
  • 2.2 Differences between SQL and GQL
• 3 Portability concerns
• 4 Backends
• 5 Google Cloud SQL
• 6 Usage quotas
• 7 See also
• 8 References
• 9 Bibliography
• 10 External links

Supported features/restrictions

Runtimes and framework

Supported programming languages include Python, Ruby, Java (and, by extension, other JVM languages such as Kotlin, Groovy, JRuby, Scala, Clojure), Go, and PHP. Node.js is also available in the flexible environment. Google has said that it plans to support more languages in the future, and that the Google App Engine has been written to be language independent.^[4] C# is also supported.^[5] Arbitrary Docker containers are also supported.^[6]
Python web frameworks that run on Google App Engine include Django, CherryPy, Pyramid, Flask, web2py and webapp2,^[7] as well as a custom Google-written webapp framework and several others designed specifically for the platform that emerged since the release.^[8] Any Python framework that supports the WSGI using the CGI adapter can be used to create an application; the framework can be uploaded with the developed application. Third-party libraries written in pure Python may also be uploaded.^[9][10]
Google App Engine supports many Java standards and frameworks. Core to this is the servlet 2.5 technology using the open-source Jetty Web Server,^[11] along with accompanying technologies such as JSP. JavaServer Faces operates with some workarounds. A newer release of App Engine Standard Java in Beta supports Java8, Servlet 3.1 and Jetty9.
Though the integrated database, Google Cloud Datastore, may be unfamiliar to programmers, it is easily accessed and supported with JPA, JDO, and by the simple low-level API.^[12] There are several alternative libraries and frameworks you can use to model and map the data to the database such as Objectify,^[13] Slim3^[14] and Jello framework.^[15]
The Spring Framework works with GAE. However, the Spring Security module (if used) requires workarounds. Apache Struts 1 is supported, and Struts 2 runs with workarounds.^[16]
The Django web framework and applications running on it can be used on App Engine with modification. Django-nonrel^[17] aims to allow Django to work with non-relational databases and the project includes support for App Engine.^[18]

Reliability and Support

All billed App Engine applications have a 99.95% uptime SLA.^[19]
App Engine is designed in such a way that it can sustain multiple datacenter outages without any downtime. This resilience to downtime is shown by the statistic that the High Replication Datastore saw 0% downtime over a period of a year.^[20]
Paid support from Google engineers is offered as part of Premier Accounts.^[21] Free support is offered in the App Engine Groups, Stack Overflow, Server Fault, and GitHub. However assistance by a Google staff member is not guaranteed.^[22]

Bulk downloading

SDK version 1.2.2 adds support for bulk downloads of data using Python.^[23] The open source Python projects gaebar,^[24] approcket,^[25] and gawsh^[26] also allow users to download and back up App Engine data. No method for bulk downloading data from GAE using Java currently exists.

Restrictions

• Developers have read-only access to the filesystem on App Engine. Applications can use only virtual filesystems, like gae-filestore.^[27]
• App Engine can only execute code called from an HTTP request (scheduled background tasks allow for self calling HTTP requests).
• Users may upload arbitrary Python modules, but only if they are pure-Python; C and Pyrex modules are not supported.
• Java applications may only use a subset (The JRE Class White List) of the classes from the JRE standard edition.^[28] This restriction does not exist with the App Engine Standard Java8 runtime.
• A process started on the server to answer a request can't last more than 60 seconds (with the 1.4.0 release, this restriction does not apply to background jobs anymore).
• Does not support sticky sessions (a.k.a. session affinity), only replicated sessions are supported including limitation of the amount of data being serialized and time for session serialization.

Major differences

Differences with other application hosting

Compared to other scalable hosting services such as Amazon EC2, App Engine provides more infrastructure to make it easy to write scalable applications, but can only run a limited range of applications designed for that infrastructure.
App Engine's infrastructure removes many of the system administration and development challenges of building applications to scale to hundreds of requests per second and beyond.^[29] Google handles deploying code to a cluster, monitoring, failover, and launching application instances as necessary.
While other services let users install and configure nearly any *NIX compatible software, App Engine requires developers to use only its supported languages, APIs, and frameworks. Current APIs allow storing and retrieving data from the document-oriented Google Cloud Datastore database; making HTTP requests; sending e-mail; manipulating images; and caching. Google Cloud SQL^[30] can be used for App Engine applications requiring a relational MySQL compatible database backend.^[31]
Per-day and per-minute quotas restrict bandwidth and CPU use, number of requests served, number of concurrent requests, and calls to the various APIs, and individual requests are terminated if they take more than 60 seconds or return more than 32MB of data.

Differences between SQL and GQL

Google App Engine's integrated Google Cloud Datastore database has a SQL-like syntax called "GQL". GQL does not support the Join statement.^[32] Instead, one-to-many and many-to-many relationships can be accomplished using ReferenceProperty().^[33] This shared-nothing approach allows disks to fail without the system failing.^[34] Switching from a relational database to Cloud Datastore requires a paradigm shift for developers when modeling their data.

Portability concerns

Developers worry that the applications will not be portable from App Engine and fear being locked into the technology.^[35] In response, there are a number of projects to create open-source back-ends for the various proprietary/closed APIs of app engine, especially the datastore. AppScale, CapeDwarf and TyphoonAE^[36] are a few of the open source efforts.
AppScale automatically deploys and scales unmodified Google App Engine applications over popular public and private cloud systems and on-premises clusters.^[37] AppScale can run Python, Java, PHP, and Go applications on EC2, Google Compute Engine, Softlayer, Azure and other cloud vendors.
TyphoonAE^[36] can run Python App Engine applications on any cloud that support linux machines.
Web2py web framework offers migration between SQL Databases and Google App Engine, however it doesn't support several App Engine-specific features such as transactions and namespaces.^[38]

Backends

In Google I/O 2011, Google announced App Engine Backends, which are allowed to run continuously, and consume more memory.^[39][40] The Backend API was deprecated as of March 13, 2014 in favor of the Modules API.^[41]

Google Cloud SQL

In Oct 2011, Google previewed a zero maintenance SQL database, which supports JDBC and DB-API.^[42] This service allows to create, configure, and use relational databases with App Engine applications. Google Cloud SQL offers MySQL 5.5 and 5.6.^[43]

Usage quotas

Google App Engine requires a Google account to get started, and an account may allow the developer to register up to 25 free applications and an unlimited number of paid applications.^[44]
Google App Engine defines usage quotas for free applications. Extensions to these quotas can be requested, and application authors can pay for additional resources.^[45]

Google Compute Engine (VPS on IaaS)

Google Compute Engine (GCE) is the Infrastructure as a Service (IaaS) component of Google Cloud Platform which is built on the global infrastructure that runs Google’s search engine, Gmail, YouTube and other services. Google Compute Engine enables users to launch virtual machines (VMs) on demand. VMs can be launched from the standard images or custom images created by users. GCE users need to get authenticated based on OAuth 2.0 before launching the VMs. Google Compute Engine can be accessed via the Developer Console, RESTful API or command-line interface (CLI).

Contents

• 1 History
• 2 Google Compute Engine Unit (GCEU)
• 3 Persistent disks
• 4 Images
• 5 Machine types
• 6 Billing and discounts
• 7 Machine type comparison
• 8 Resources
  • 8.1 Image
  • 8.2 Machine type
  • 8.3 Disk
  • 8.4 Snapshot
  • 8.5 Instance
  • 8.6 Network
  • 8.7 Address
  • 8.8 Firewall
  • 8.9 Route
• 9 Regions and zones
• 10 Scope of resources
• 11 Features
  • 11.1 Billing and pricing model
  • 11.2 VM performance
  • 11.3 Disk performance
  • 11.4 Global scope for images and snapshots
  • 11.5 Transparent maintenance
• 12 References
• 13 External links

History

Google announced Compute Engine on June 28, 2012 at Google I/O 2012 in a limited preview mode. In April 2013, GCE was made available to customers with Gold Support Package. On February 25, 2013, Google announced that RightScale was their first reseller.^[1] During Google I/O 2013, many features including sub-hour billing, shared-core instance types, larger persistent disks, enhanced SDN based networking capabilities and ISO 27001 certification got announced. GCE became available to everyone on May 15, 2013. Layer 3 load balancing came to GCE on August 7, 2013. Finally, on December 2, 2013, Google announced that GCE is generally available. It also expanded the OS support, enabled live migration of VMs, 16-core instances, faster persistent disks and lowered the price of standard instances.
At the Google Cloud Platform Live event on March 25, 2014, Urs Hölzle, Senior VP of technical infrastructure announced sustained usage discounts, support for Microsoft Windows Server 2008 R2, Cloud DNS and Cloud Deployment Manager. On May 28, 2014, Google announced optimizations for LXC containers along with dynamic scheduling of Docker containers across a fleet of VM instances.^[2]

Google Compute Engine Unit (GCEU)

Google compute engine unit (GCEU), which is pronounced as GQ, is an abstraction of compute resources. According to Google, 2.75 GCEUs represent the minimum power of one logical core (a hardware hyper-thread) based on the Sandy Bridge platform.

Persistent disks

Every Google Compute Engine instance starts with a disk resource called persistent disk. Persistent disk provides the disk space for instances and contains the root filesystem from which the instance boots. Persistent disks can be used as raw block devices. By default, Google Compute Engine uses SCSI for attaching persistent disks. Persistent Disks provide straightforward, consistent and reliable storage at a consistent and reliable price, removing the need for a separate local ephemeral disk. Persistent disks need to be created before launching an instance. Once attached to an instance, they can be formatted with the native filesystem. A single persistent disk can be attached to multiple instances in read-only mode. Each persistent disk can be up to 10TB in size. Google Compute Engine encrypts the persistent disks with AES-128-CB, and this encryption is applied before the data leaves the virtual machine monitor and hits the disk. Encryption is always enabled and is transparent to Google Compute Engine users. The integrity of persistent disks is maintained via a HMAC scheme.
On June 18, 2014, Google announced support for SSD persistent disks. These disks deliver up to 30 IOPS per GB which is 20x more write IOPS and 100x more read IOPS than the standard persistent disks.

Images

An image is a persistent disk that contains the operating system and root file system that is necessary for starting an instance. An image must be selected while creating an instance or during the creation of a root persistent disk. By default, Google Compute Engine installs the root filesystem defined by the image on a root persistent disk. Google Compute Engine provides CentOS and Debian images as standard Linux images. Red Hat Enterprise Linux (RHEL) and Microsoft Windows Server 2008 R2 images are a part of the premier operating system images which are available for an additional fee. CoreOS, the lightweight Linux OS based on Chromium OS is also supported on Google Compute Engine.

Machine types

Google Compute Engine uses KVM as the hypervisor,^[3] and supports guest images running Linux and Microsoft Windows which are used to launch virtual machines based on the 64 bit x86 architecture. VMs boot from a persistent disk that has a root filesystem. The number of virtual CPUs, amount of memory supported by the VM is dependent on the machine type selected.

Billing and discounts

Once an instance is run for over 25% of a billing cycle, the price starts to drop:

• If an instance is used for 50% of the month, one will get a 10% discount over the on-demand prices
• If an instance is used for 75% of the month, one will get a 20% discount over the on-demand prices
• If an instance is used for 100% of the month, one will get a 30% discount over the on-demand prices

Machine type comparison

Google provides certain types of machine types:

• Standard machine: 3.75 GB of RAM per virtual CPU
• High memory machine: 6.5 GB of RAM per virtual CPU
• High CPU machine: 0.9 GB of RAM per virtual CPU
• Shared machine: CPU and RAM are shared between customers

The prices mentioned below^{[citation needed]} are based on running standard Debian or CentOS Linux VMs. VMs running proprietary operating systems will be charged more.

Machine type	Machine name	Virtual cores	Memory	Cost per hour (US hosted)	Cost per hour (Europe hosted)
Standard	n1-standard-1	1	3.75GB	$0.070	$0.077
Standard	n1-standard-2	2	7.5GB	$0.140	$0.154
Standard	n1-standard-4	4	15GB	$0.280	$0.308
Standard	n1-standard-8	8	30GB	$0.560	$0.616
Standard	n1-standard-16	16	60GB	$1.120	$1.232
High Memory	n1-highmem-2	2	13GB	$0.164	$0.180
High Memory	n1-highmem-4	4	26GB	$0.328	$0.360
High Memory	n1-highmem-8	8	52GB	$0.656	$0.720
High Memory	n1-highmem-16	16	104GB	$1.312	$1.440
High CPU	n1-highcpu-2	2	1.80GB	$0.088	$0.096
High CPU	n1-highcpu-4	4	3.60GB	$0.176	$0.192
High CPU	n1-highcpu-8	8	7.20GB	$0.352	$0.384
High CPU	n1-highcpu-16	16	14.40GB	$0.704	$0.768
Shared Core	f1-micro	1	0.60GB	$0.013	$0.014
Shared Core	g1-small	1	1.70GB	$0.035	$0.0385

Resources

Compute Engine connects various entities called resources that will be a part of the deployment. Each resource performs a different function. When a virtual machine instance is launched, an instance resource is created that uses other resources, such as disk resources, network resources and image resources. For example, a disk resource functions as data storage for the virtual machine, similar to a physical hard drive, and a network resource helps regulate traffic to and from the instances.

Image

An image resource contains an operating system and root file system necessary for starting the instance. Google maintains and provides images that are ready-to-use or users can customize an image and use that as an image of choice for creating instances. Depending on the needs, users can also apply an image to a persistent disk and use the persistent disk as the root file system.

Machine type

An instance's machine type determines the number of cores, the memory, and the I/O operations supported by the instance.

Disk

Persistent disks are independent of the virtual machines and outlive an instance's lifespan. All information stored on the persistent disks is encrypted before being written to physical media, and the keys are tightly controlled by Google.

Type	Price (per GB/month)
Standard provisioned space	$0.04
SSD provisioned space	$0.17
Snapshot storage	$0.026
IO operations	No additional charge

Each instance can attach only a limited amount of total persistent disk space (one can have up to 64 TB on most instances) and a limited number of individual persistent disks (one can attach up to 16 independent persistent disks to most instances).

Snapshot

Persistent disk snapshots lets the users copy data from existing persistent disk and apply them to new persistent disks. This is especially useful for creating backups of the persistent disk data in cases of unexpected failures and zone maintenance events.

Instance

A Google Compute Engine instance is a virtual machine running on a Linux or Microsoft Windows configuration. Users can choose to modify the instances including customizing the hardware, OS, disk, and other configuration options.

Network

A network defines the address range and gateway address of all instances connected to it. It defines how instances communicate with each other, with other networks, and with the outside world. Each instance belongs to a single network and any communication between instances in different networks must be through a public IP address.
Your Cloud Platform Console project can contain multiple networks, and each network can have multiple instances attached to it. A network allows you to define a gateway IP and the network range for the instances attached to that network. By default, every project is provided with a default network with preset configurations and firewall rules. You can choose to customize the default network by adding or removing rules, or you can create new networks in that project. Generally, most users only need one network, although you can have up to five networks per project by default.
A network belongs to only one project, and each instance can only belong to one network. All Compute Engine networks use the IPv4 protocol. Compute Engine currently does not support IPv6. However, Google is a major advocate of IPv6 and it is an important future direction.

Address

When an instance is created, an ephemeral external IP address is automatically assigned to the instance by default. This address is attached to the instance for the life of the instance and is released once the instance has been terminated. GCE also provides mechanism to reserve and attach static IPs to the VMs. An ephemeral IP address can be promoted to a static IP address.

Firewall

A firewall resource contains one or more rules that permit connections into instances. Every firewall resource is associated with one and only one network. It is not possible to associate one firewall with multiple networks. No communication is allowed into an instance unless a firewall resource permits the network traffic, even between instances on the same network.

Route

Google Compute Engine offers a routing table to manage how traffic destined for a certain IP range should be routed. Similar to a physical router in the local area network, all outbound traffic is compared to the routes table and forwarded appropriately if the outbound packet matches any rules in the routes table.

Regions and zones

A region refers to a geographic location of Google's infrastructure facility. Users can choose to deploy their resources in one of the available regions based on their requirement. As of June 1, 2014, Google Compute Engine is available in central US region, Western Europe and Asia East region.
A zone is an isolated location within a region. Zones have high-bandwidth, low-latency network connections to other zones in the same region. In order to deploy fault-tolerant applications that have high availability, Google recommends deploying applications across multiple zones in a region. This helps protect against unexpected failures of components, up to and including a single zone. As of August 5, 2014, there are eight zones - three each in central US region and Asia East region and two zones in Western Europe region.

Scope of resources

All resources within GCE belong to the global, regional, or zonal plane. Global resources are accessible from all the regions and zones. For example, images are a global resource so users can launch a VM in any region based on a global image. But an address is a regional resource that is available only to the instances launched in one of the zones within the same region. Instances are launched in a specific zone that requires the zone specification as a part of all requests made to that instance.
The table below summarises the scope of GCE resources:

Scope	Resource
Global	Image
Global	Snapshot
Global	Network
Global	Firewall
Global	Route
Region	Address
Zone	Instance
Zone	Machine Type
Zone	Disk

Features

Billing and pricing model

Google charges the VMs for a minimum of 10 minutes. At the end of 10th minute, instances are charged in 1-minute increments, rounded up to the nearest minute.^[4] Sustained usage based pricing will credit the discounts to the customers based on the monthly utilisation.^[5][6] Users need not pay a commitment fee upfront to get discounts on the regular, on-demand pricing.

VM performance

Compute Engine VMs boot within 30 seconds^[7] which is considered to be 4-10x faster than the competition.

Disk performance

The persistent disks of Compute Engine deliver higher IOPS consistently.^[8] With the cost of provisioned IOPS included within the cost of storage, users need not pay separately for the IOPS.^[9]

Global scope for images and snapshots

Images and disk snapshots belong to the global scope which means they are implicitly available across all the regions and zones of Google Cloud Platform.^[10] This avoids the need for exporting and importing images and snapshots between regions.

Transparent maintenance

During the scheduled maintenance of Google data center, Compute Engine can automatically migrate the VMs from one host to the other without involving any action from the users. This delivers better uptime to applications.^[11][12]