-
Notifications
You must be signed in to change notification settings - Fork 277
FAQs
- Can I run multiple apps on one deployment?
- What version of the GAE API do you support?
- What APIs do you support? What APIs are not supported?
- Is it possible to update AppScale?
- How do I set the number of replicas of my data?
- How do I set my Flower TaskQueue password?
- How do I set the number of TaskQueue workers?
- What is my monit status page password and how do I change it?
- Does AppScale autoscale?
- What Linux distribution does AppScale run on?
- Can I setup a web domain pointing to my AppScale deployment?
- Can I setup a static IP for Amazon elastic IPs and GCE static IPs?
- I have a company firewall and can only come in through a certain DNS or IP. How do I set it?
- Is AppScale production ready?
- What is the largest AppScale deployment run so far?
- Does AppScale support transactions?
- What are the timeouts on requests? Can I increase/shorten them?
- What are the libraries that are white listed in AppScale?
- Can I run libraries that are restricted in App Engine?
- How can my application connect to a remote database?
- What languages do you support?
- Does AppScale generate meta data about my data?
- What is AppScale written in?
- How do I deploy updates to the AppScale core code without building a new VM?
- How do I change the port that my app responds on from the default 8080?
- Relocate does not work.
- How do I set up my own SSL cert?
- Which database does AppScale support?
- How can I deploy my app with MySQL (CloudSQL) on AppScale?
- What is a recommended production deployment?
- I want to run the AppScale tools from a different machine. How do I do so?
- Is there a way to not have the tools prompt me for my username and password every time?
- What is the testing default cloud admin username and password?
- Can I change the default testing username and password?
- TaskQueue tasks seem to not being run. What do I do?
- ZooKeeper is taking up a lot of disk space. What do I do?
- How do I enable the datastore viewer?
- Can I get commercial support?
- Something is broken. How do I fix it?
- AppScale sucks. Make it better!
- This FAQ doesn't answer my question.
Yes. Make sure you use different app IDs for each application.
GAE version 1.8.0 for Python and 1.8.4 for Java. Make sure your Java apps are compiled using this version. Failure to do so will result in unexpected behavior.
Supported APIs | Not currently supported |
---|---|
Datastore | Versions |
Memcache | Modules |
Taskqueue | Capabilities |
Images | Logs (although we provide tools to easily download the logs) |
Cron | Backends |
Channel | Endpoints |
Multi-tenancy | |
Mail (out bound only) | |
OAuth (client side) | |
URLFetch | |
Users | |
Sockets | |
JDO/JDA for Java | |
MapReduce (Python) | |
Cloud SQL | |
Remote | |
Search (experimental) | |
XMPP |
Yes. Backup your data first! Currently, the upgrade process will require some downtime.
Then you can run appscale upgrade
from AppScale Tools 2.9 onwards.
In dev environments with custom changes or to minimize downtime you might need to run the upgrade steps manually. You'd better know what you're doing. New code can be pulled in by doing "git pull origin master" for both appscale and appscale-tools repos. If a change has happened to the build script, it may involve updating the new technology (example: A new version of Nginx or Cassandra) by running the appscale_build.sh script in appscale/debian and appscale-tools/debian.
In your AppScale file you can set
replication : 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"
You can set the number of workers processing your tasks on each TaskQueue node by modifying this line of code in /root/appscale/AppTaskQueue/tq_config.py. You will then have to restart the TaskQueue service and redeploy your app to ensure your changes are applied.
The default username and password are: admin/monit. Edit the following lines in the /etc/monit/monitrc file on the head node to set your username and password:
set httpd port 2812 and
allow admin:monit # require user 'admin' with password 'monit'
Reload monit to apply your changes by running:
service monit reload
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 14.04 LTS (Trusty Tahr), Ubuntu 12.04 LTS (Precise Pangolin) 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 a 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).
PHP: https://cloud.google.com/appengine/docs/php/
Python: https://cloud.google.com/appengine/docs/python/tools/libraries27
Java: https://cloud.google.com/appengine/docs/java/jrewhitelist
Go: https://cloud.google.com/appengine/docs/go/
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 applications written in 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 AppController is written in Ruby. There is also some Java, PHP, and Go.
In your 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'
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 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 databases caused release delay, so at this time AppScale comes 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 straight 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>
For a Python app, you can use MySQLdb. You can find a sample guestbook app here.
Ideally, you want to have a minimum of three machines with at least 4GB or RAM 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.4
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:
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 can easily check out how much space zookeeper logs take up by running:
du -sh /opt/appscale/zookeeper
You may want to add the following in as a cron job to clean up disk space:
bash /root/appscale/scripts/zookeeper_cleanup.sh
Check /opt/appscale/zookeeper size. It should have reduced a good deal in size.
You can use the the /root/appscale/scripts/enable-datastore-viewer.sh
script.
Do not use this script in production because it will expose your app's data to a publicly accessible location. If you need something like this in production, you can manually add the needed changes along with additional restrictions (such as only allowing a single IP address) in /etc/nginx/sites-enabled/your-app-id_datastore_viewer.conf
.
Since the script is for testing purposes, it assumes that you are on a single-node deployment. If this is not the case, you'll need to forward the app admin port from one of the AppServers on another node to the head node. The script will give you the SSH tunneling command to run in the background for as long as you need the datastore viewer enabled. It should resemble the following:
ssh -L 3000X:localhost:3000Y your-app-engine-node -N
Yes. Contact us at support@appscale.com or visit our website.
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.