-
Notifications
You must be signed in to change notification settings - Fork 277
FAQs
Yes. Make sure you use different app IDs for each application.
GAE version 1.8.0. Make sure your Java apps are compiled using this version. The tools will complain upon deployment. Failure to do so will result in weird null pointer exceptions.
We support datastore, cron, memcache, taskqueue (push queues only), images, channel, multi-tenancy, XMPP, mail (out bound only), OAuth (client side), URL Fetch, sockets, users, JDO/JDA for Java, remote_api, and mapreduce.
Backends are not supported (you can run arbitrary code on the VMs). We are currently working on getting the Search API (coming soon). We don't support hosting of different versions (you must upload the app with a different app ID). We do not support modules. We do not support inbound email. Capabilities API is stubbed out to always return true. We do not support the Logs API where you can programmatically download your logs (although we provide tools to easily download the logs). Cloud SQL must be manually set up (install MySQL either on the VMs or some remote location and point your app to this deployment; see below in the FAQ for more info).
Yes. Although it may require backing up your data and do "appscale down; appscale up" to get the new changes in place. New code can be pulled in by doing "git pull origin master" for both the core code and the tools. If a change has happened to the build script, it may involve updating the new technology (example: A new version of nginx or cassandra). This is approximately 2 to 5 minutes of downtime. You can also do it in place without the downtime, killing the updated modules and having monit restart them, but you better know what you're doing.
In your AppScale file you can set
n : 1
Make sure you have at least these many number of datastore nodes.
The default username and password are: appscale/appscale
It is highly recommended to change it. To change it though edit in your AppScalefile:
flower_password: "newpassword"
The default username and password are: admin/monit. To change it, edit the /etc/monitrc file.
Edit the /etc/monitrc on the head node to set your username and password.
Yes. It will scale up and down the processes on your node (only if there is CPU available). If the node does not have enough resources to spin up another process, it will vote to spin up another virtual machine. If there is a consensus on scaling up, then a new machine will be added (only in IaaS environments such as GCE and AWS). Once the load has decreased, the processes will slowly be terminated and once a node is no longer running an application, that node will be terminated.
To set this in your AppScalefile:
min: 1
max: 2
Here we will start with one node, and scale up to two nodes.
You can also manually scale up. See Adding Machines to an AppScale Deployment.
This shouldn't matter since AppScale tries to abstract away lower level details by running in virtual machines. AppScale runs on Ubuntu Precise and Debian Wheezy. It is simple to port to other debian distributions.
Yes. Set up your CNAME record pointing to the IP address of the machine. Amazon's Route 53 is a great service for doing this.
Yes. Set them up in the cloud console of your IaaS provider and then you can set them in your AppScalefile.
static_ip: '1.2.3.4'
Set login_host in your AppScalefile.
Yes. AppScale has been developed since 2008 when GAE first came out. We've had over 30 releases and have users in production throughout the world.
100 nodes. You don't need this many nodes unless you're running some ridiculously high traffic site.
Yes. Both within entity groups and cross entity group. AppScale uses ZK for locking. We have garbage collection for failed transactions.
All URL paths are set to 600 seconds (10 minutes). You can increase them or decrease them via the code (AppController/lib/nginx.rb).
Yes. You have full access to the VMs running AppScale. You can either white list the library or add your own custom GAE APIs.
You'll see a list of white listed items. You would just add in the one you want to add. Here is an example of how pyexpat was whitelisted:
appscale/AppServer/google/appengine/tools/dev_appserver_import_hook.py:801: 'pyexpat',
appscale/AppServer/google/appengine/tools/devappserver2/python/sandbox.py:787: 'pyexpat',
Optionally, you'll see the code checking a list of white listed items. You can disable this check altogether.
dev_appserver_import_hook.py:1419 and sandbox.py:821
if (file_type not in self._ENABLED_FILE_TYPES and
submodule not in self._white_list_c_modules):
White list the client library as seen above and then connect it directly to the database that you have already stood up and configured. Note: This is direct access to the database, not using the App Engine Datastore API.
We support all the GAE languages. Python, Java, PHP, and Go.
Yes. We generate statistics about namespaces and kinds once a day. Or you can start it in the AppConsole in the AppScale Dashboard.
Mostly Python. The controller is written in Ruby which we want to port to Python. There is also some Java, PHP, and Go.
In you AppScalefile put in a "scp: ~/location_to_your_appscale_dir". Now this will be rsynced to all nodes in your AppScale deployment. If you change the build script (changing underlying technologies), you can still have the nodes run custom commands on boot using "user_commands" in your AppScalefile.
Example:
scp : "~/appscale"
user_commands:
- 'apt-get install -y htop'
- 'apt-get install -y vim'
By default AppScale sets (at least the first) apps to listen on port 8080 for HTTP requests. This can be changed by running the appscale command similarly to how you started your cluster:
appscale relocate appname 80 443
The above command sets the application called "appname" to listen to HTTP on port 80 and HTTPs to port 443 (again the standardized ports for HTTP and secure HTTP via SSL respectively).
Verify that the relocation port is available (no process has already binded it) on the head node.
lsof -i:80
Overwrite the cert and private key used by AppScale in /etc/nginx/ and /etc/appscale/certs on your head node. Then do "service nginx reload".
root@appscale-image0:~# cp ~/my_own_cert.crt /etc/nginx/mycert.pem
root@appscale-image0:~# cp ~/my_own_pk.pem /etc/nginx/mykey.pem
root@appscale-image0:~# cp ~/my_own_cert.crt /etc/appscale/certs/mycert.pem
root@appscale-image0:~# cp ~/my_own_pk.pem /etc/appscale/certs/mykey.pem
root@appscale-image0:~# service nginx reload
Reloading nginx configuration: nginx.
AppScale is designed to support multiple databases, and it indeed supported multiple when it started. But regression testing on multiple database caused releases delay, so at this time AppScale come with Cassandra as default.
You need to install MySQL server and client on your AppScale instance. You can do so by running:
sudo apt-get install mysql-server mysql-client
Then you need to add data into your MySQL server, create a user (username, password) that your app will use to connect to the database and grant them privileges on the database(s) that your app will be accessing.
Do not forget to specify the database URL in the configuration file of your application.
For a Java app that works with MySQL, you need to include the following in your appengine-web.xml file:
<system-properties>
<property name="MYSQL" value="jdbc:mysql://<hostname>:<port>/<database_name>"/>
</system-properties>
Ideally, you want to have a minimum of three machines with at least 4 gigs each. Cassandra's requirements alone are listed at 4 gigs. Since hardware is dedicated to serving your application, you should disable autoscaling (within a machine, not scaling out vertically with more machines) using the "appengine" flag. Your layout on the AppScalefile should look like such:
ips_layout :
master : 192.168.1.2
zookeeper : 192.168.1.2
appengine : 192.168.1.3
database : 192.168.1.2
appengine: 8
Here we placed an "appengine" node and "database" node on their own machines, while zookeeper is sitting on the head node. If you want additional fault tolerance, you can add more database nodes, zookeeper nodes, and appengine nodes. Here is a layout with more fault tolerance:
ips_layout :
master : 192.168.1.2
zookeeper :
- 192.168.1.4
- 192.168.1.5
- 192.168.1.6
appengine :
- 192.168.1.3
- 192.168.1.7
database :
- 192.168.1.8
- 192.168.1.9
appengine: 8
n: 2
In this deployment we have 2 database nodes, with replication set to 2. Cassandra is set to be strongly consistent, so both replicas should always be identical. We have two "appengine" nodes, therefore there are a total of 16 application servers hosting your application. If you were to deploy more applications, they too will have another 16 application servers (be careful with memory hungry applications). We have 3 "zookeeper" nodes so that we can achieve a quorum between them. We still have a single point of failure at the master node, but all other services have redundancies.
Learn more at https://github.com/AppScale/appscale/wiki/Distributed-Deployment
All the meta data (ssh keys and such) are stored in ~/.appscale. Move this folder along with your AppScalefile to whichever machine you want to run the tools and you'll have access to your current AppScale deployment.
Yes. In your AppScalefile you can use the testing account by putting
test: True
Username: a@a.com Password: aaaaaa
Yes. In your AppScalefile:
test: True
admin_user: my_new_user@whatever.com
admin_pass: my_new_password
In some cases, Celery might get backed up on tasks because of testing or resource issues and there can be delays in executing a task. You can delete all enqueued tasks and start from scratch by running:
celery amqp queue.purge <app_ID>___<queue_name>
from the command line.
You may want to add this in as a cron job to clean up disk space (du -sh /opt/appscale/zookeeper). Create /root/log4j.xml file with the contents of: https://gist.github.com/nlake44/51fb56e3170908cb5cd2
On the ZooKeeper node run:
java -cp /root/:/usr/lib/zookeeper/zookeeper.jar:/usr/lib/zookeeper/lib/slf4j-api-1.6.1.jar:/usr/lib/zookeeper/lib/slf4j-log4j12-1.6.1.jar:/usr/lib/zookeeper/liblog4j-1.2.15.jar:conf:/usr/lib/zookeeper/lib/* -Dlog4j.debug org.apache.zookeeper.server.PurgeTxnLog /opt/appscale/zookeeper/ /opt/appscale/zookeeper -n 3
Check /opt/appscale/zookeeper size. It should have reduced in size a good deal.
Yes. Contact us at support@appscale.com.
Check out the Troubleshooting page.
Firstly, that's not a question. =) Secondly, We love new contributors! Help us improve the code or docs and AppScale will love you forever.
Send us a pull request! Contribute!.
Please email the mailing list at https://groups.google.com/forum/#!forum/appscale_community and we'll do our best to answer your questions.