Deploying Applications Using AppScale

AppScale Systems
AppScale
Published in
6 min readJun 8, 2018

In our previous post, Getting Started with Google App Engine, we showed how to deploy Java, PHP, and Python applications using Google App Engine. While App Engine is a great platform for quickly building scalable apps, it comes with a limitation: apps developed for App Engine must run in Google’s cloud environment, which can pose problems if you want to run your app in mainland China, in another public cloud, or on premises.

This is where AppScale comes in. AppScale is an open source serverless platform for running applications on any infrastructure. Like App Engine, AppScale lets you deploy and manage applications without having to worry about the underlying stack. And since AppScale is the open source implementation of App Engine, you can typically migrate apps designed for App Engine with no modifications.

We will start by showing you how to set up AppScale, then show how to deploy App Engine apps using AppScale.

Setting Up an AppScale Environment

The AppScale environment consists of one or more nodes, which can be virtual machines, containers, or bare metal servers. Each node is assigned one or more roles, which the master node (called the controller) uses to delegate tasks. One node can perform multiple roles, and multiple nodes can perform the same role for load balancing and redundancy.

In this example, we will set up a single node using VirtualBox and Vagrant. We will use Vagrant to provision a VM with AppScale already installed.

Before you begin, install VirtualBox and Vagrant on your workstation.

Step 1: Install AppScale Using Vagrant

After installing VirtualBox and Vagrant, download the AppScale Vagrantfile to a new directory. This Vagrantfile provisions a virtual machine with the AppScale service and command-line application already installed and configured. It also mounts the current directory to the /vagrant directory in the virtual machine so you can deploy projects from your workstation’s file system.

Next, download and provision the VM:

Then, connect to the new machine using the password “vagrant”:

Step 2: Set Up AppScale

The next step is to configure AppScale. Normally, you would generate a blank configuration file by running:

appscale init cluster

or for cloud computing platforms:

appscale init cloud

However, AppScale comes with a script that generates a single-node environment based on the machine running the command. This lets you get up and running with AppScale quickly. Keep in mind that you can change these settings later when you’re ready to add other nodes to the deployment.

After connecting to the VM, switch to the root user account using the following command:

$ sudo -i

Next, run the fast-start script. This script automatically configures AppScale on the VM:

You can verify the state of the AppScale service by running:

appscale status

Any applications you deploy to AppScale will also be listed here. At the moment, only the appscaledashboard project is running. Opening the URL displayed at the bottom of the terminal shows the AppScale Dashboard, which you can use to monitor and manage your AppScale environment.

Log in with the default username:

a@a.com

and the default password:

aaaaaa

Now that AppScale is ready, we will create and deploy a new Java app.

Deploying Applications to AppScale

Deploying a Java App

As in our last post, we will deploy a basic Java app created in Eclipse. Since AppScale runs apps created for App Engine, we can create the app as an App Engine project and deploy it using AppScale instead of the Google Cloud Tools plugin. Before continuing, follow steps 2 and 3 from the previous post.

Specifying an Application ID

Before deploying your app, you will need to specify an application ID. The application ID uniquely identifies the project when using the AppScale Dashboard or appscale appscale command

Note: The application ID should be in all lower-case.

Open the appengine-web.xml file located in your project’s WEB-INFfolder and add a new attribute named application. Enter a name that uniquely identifies the project in your AppScale deployment. For example, the following project appears in the AppScale Dashboard with the ID eclipse-gcptest:

Now you can deploy your app. From the VM’s command line, run appscale deployon the directory containing the appengine-web.xml file, such as the WAR directory.

Once the project deploys, AppScale provides a URL where you can access the hosted application. You can also view the status of your app from the AppScale dashboard.

Deploying a Python App

Deploying a Python application to AppScale is slightly different than deploying a Java application. App Engine uses a YAML configuration file for Python rather than an XML configuration file. This file — named app.yaml — sits in the project’s root directory. In addition to defining project properties such as the language and runtime version, it also defines routing information for mapping URL paths to script files and Python modules.

For example, in the AppScale Guestbook sample app, AppScale forwards requests to the guestbook.py script and the script itself handles routing.

Deploy your Python application using appscale deploy on the directory containing the app.yaml file:

For more information on the syntax of app.yaml, see the App Engine reference documentation.

Deploying a PHP App

Deploying a PHP application is similar to deploying a Python application. Both languages use an app.yaml file, and both languages require you to route URLs to scripts. You can find examples of AppScale-ready PHP applications in AppScale’s GitHub repository.

As with Python, deploy your PHP application using appscale deployon the directory containing the app.yaml file:

To learn more about configuring PHP applications, see the App Engine documentation.

Deploying Applications to AWS, Azure, and Other Platforms

At the moment, your app is only running on a local virtual machine. To deploy to other machines and platforms, you will need to modify your AppScalefile. That file describes your AppScale deployment, from the individual nodes and their roles to resource allocation limits and replication details. To learn more about the configuration options available in the AppScalefile, generate a new AppScalefile by running:

appscale init cluster

or

appscale init cloud

What Advantages Does AppScale Offer Over App Engine?

The most unique advantage AppScale offers is the ability to bring your App Engine projects outside of the App Engine environment, even if you just want to migrate to Google Compute Engine (GCE). You can also run your serverless apps on Microsoft Azure, Amazon Web Services, OpenStack, Eucalyptus, and on-premises. Your apps can run in any location, including mainland China, where it has been difficult for Google workloads to run. Deploy your apps to AppScale as if you were deploying them to App Engine, and AppScale handles the deployment details.

AppScale may require additional setup and configuration over App Engine, but this does give you the ability to customize and fine-tune your infrastructure. For on-site hosting, you’ll need to have machines already provisioned, accessible over SSH, have the AppScale service already installed, and provide root user access to the main AppScale node (called the controller). AppScale will automatically scale applications as long as there are resources available. However, when used on Azure, GCE, AWS, and Alibaba, AppScale can scale automatically by provisioning new resources on demand.

Next Steps

AppScale is a powerful and flexible tool that provides you with the portability to move your apps beyond App Engine. To learn more about the benefits for developers, operations, and your overall business, visit Why AppScale. To understand AppScale’s architectural overview, visit our How It Works. Finally, to learn how we may be able to help your organization with your specific needs, contact us.

Originally published at blog.appscale.com on June 8, 2018.

--

--

AppScale Systems
AppScale

AWS-compatible hybrid cloud software that can be deployed in many environments (on-premises, in a co-lo, at a service provider, at a BMaaS provider).