I have this application that will be run in a local network where a number of devices should interact with a database. I could use xampp and go for CherryPy or any other Python framework (Python is usually my choice) but it is the sum of a lot of different things: Python, Apache, MySQL... With GAE, which I have previously used in a number of applications successfully, I feel everything is neatly packed in a single box. Thay may not be true, but using the Google App Engine Launcher to create a local working copy of an app couldn't be easier.
But is it reliable? Should it be used like that? I know it's intended for development, so I'm unsure about using it as a local server in production. A few versions ago there even was this nasty bug that flushed the local datastore from time to time. But it seems that they fixed it and now data persists.
Would you recommend GAE for an application running in a local network or should I stick to LAMP (P for Python)?
Other alternative is http://code.google.com/p/appscale/.
May be you can check the the project TyphoonAE. I think it is exactly what you need.
The TyphoonAE project aims at providing a full-featured and productive
serving environment to run Google App Engine (Python) applications. It
delivers the parts for building your own scalable App Engine while
staying compatible with Google's API.
Related
I have a website on AppEngine that is 99% static. It is running on Python 2.7 runtime. Now the time has come to evolve this webapp, and since I have almost none Python code in it, I'd prefer to write it in Go instead.
Can I change runtime from Python 2.7 to Go, while keeping the project intact? Specifically, I want to keep the same app-ID, the same custom domain attached to it, the same SSL certificate, and so on.
What do I have to do in order to do that? I surely have to change runtime in the app.yaml. Is there anything else?
Bonus question: will such change happen without a downtime?
I'd be grateful for any links to documentation on exactly that (swapping runtime on a live app). I can't find any.
Specify a runtime as well as a new value for version. When deployed you'll have an older version that is Python and a newer version that is Go. There won't be any downtime (same as when deploying a newer version of Python).
Rather than trusting links/docs (that may be out of date or not 100% exactly what you're trying to do), why not create a new GAE-Std project for testing purposes and try it yourself. Having a GAE-Std test project is good for testing new function (especially by other testers who won't have access to the dev environ on your laptop).
The GAE services offer complete code isolation. So it should be possible to simply deploy a new version of the service, which can be written in a different language or even use a different GAE (standard/flex) environment. Personally I didn't go through a language change, but I did go through a split of a single-service app into a multi-service one, I see no reason for which the same principles wouldn't apply.
Maybe develop the new version as a separate app first, to be able to test it properly without risking an accidental impact on the old version and only after that bring the code as a new version in the old app. That'd be using the GAE project isolation. You can, in fact, test the entire version migration as a separate app if you so desire without even touching the existing app. I am using this technique - a separate app ID - to implement a staging environment for my app, completely isolated from my production app, see How to copy / clone entire Google App Engine Project
Make sure to not switch traffic to the new version at deployment time. This keeps the app working with the old version. Test first that the new version works as expected using Targeted routing. Then maybe use Splitting traffic across multiple versions to perform A/B testing with just a small percentage of the traffic going to the new version. Finally, when happy with the results, switch all traffic to the new version.
You need to pay special attention to the app-level configs (dispatch, cron, queue, datastore indexes), shared by all services/versions. They need to be functionally equivalent in the 2 versions. The service isolation doesn't apply to them, only project isolation can ensure no impact to the old version.
There should be no need to make any change to the app ID, custom domain mapping or SSL config. The above mentioned tests should confirm that.
A few potentially interesting posts related to re-working services/modules:
Converting App Engine frontend versions to modules
Google App Engine upgrading part by part
Migrating to app engine modules, test versions first?
Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?
It takes so long to deploy an app to App Engine by this command
gcloud app deploy
After I updated my source code, even if it's just one line of change, I had to issue this command again to upload the changes to App Engine. Again it will take a long time to deploy for just one line of code change. Is there a way to quickly update the code on App Engine instead of doing this time consuming deploy again?
I am looking for options that can speed up the code update after it's first deployment to App Engine. Since I am using flex, would using standard make it faster to update the code? Is it true that there is no way around it on App Engine and the only way to do it is to use another service such as Compute Engine?
Yes, standard env app deployment in such context is much faster, because it only involves uploading the modified files and restarting the instances.
But using standard env is often not an option for other reasons. The potential duplicate post I referenced contains itself references to both explanations and suggestions for potential speed improvements. I don't see a point in duplicating them.
The most common reasons for choosing flex env:
language support
restrictions of the standard env sandbox
See also: Google App Engine Standard or Flexible environment?
(Sep 2021): First of all, the issue you describe for App Engine (flexible) does not apply to App Engine (standard), which is almost a completely different product. (For those who are new, here is a comparison b/w both products.) This question is a few years old, and there are a few more options available to you now:
App Engine standard: If your app can run in Python 3.7+, Java 11, Go 1.12+, PHP 7, Node.js 10+, or Ruby 2.5+, then this is the obvious place to go. A deploy should take less than 1 minute.
Cloud Functions: If you don't have an entire app or your app is made up of one function/route or is otherwise short & simple, consider turning it into a microservice for Cloud Functions. Its deployment time is also less than a minute.
Cloud Run: If you're using App Engine flexible because your app is containerized, consider Cloud Run, which runs containers in a serverless way. A big bonus is that a Dockerfile is optional (due to Cloud Buildpacks). It has taken many GAE flexible use cases. Deployment is also less than a minute. If interested, I produced a pair of videos on how to migrate from App Engine standard to Cloud Run, using Docker as well as no Docker. At some point, I'll do one on transitioning from GAE flexible.
App Engine flexible: If none of the options above work, requiring you to stay on GAE flexible, then yes, you'll have to deal with its longer deployment time (due to the complexities of the system and all the resources it needs to spin-up & manage on your behalf). If you have a container and Cloud Run isn't an option, also consider GKE Autopilot or GCE MIGs (managed [VM] instance groups).
What is meant by "staging instances" of your application in this Google Cloud Debugger doc? As per this question it seems that only the default version of an application can be used with Google Cloud Debugger. Does Google simply intend that you can use this with the default version of a separate application which you dedicate to your staging environment?
Google Cloud Debugger can be used with any module or any version of your running application. The question you referred to is obsolete.
Many projects setup a module/version or simply another project to be used as their 'staging instance' to test their code before pushing to the production instance. There is no one way to implement a 'staging instance'.
The term staging in programming mostly refers to the term development.
In the app engine, you can have multiple instances of your application. One in Production environment(one instance) and other in a Staging environment(another instance).
So production means that its a version currently running or available to the public. Staging means that it is running only for testing purposes (usually new features) before its being deployed to the public
Google saying:
You can use the Cloud Debugger on both production and staging instances of your application
Simply means that you can you the Cloud Debugger on both the Production and Staging(Development) version of your application.
I am looking for a solution for a script language like lua to use with Go application running on GAE. I have found golua and luar projects and planned to use them as the solution.
However, once I ran them on GAE environment, I encountered
"o-app-builder: Failed parsing input: parser: bad import "unsafe" in
github.com/stevedonovan/luar/luar.go"
I was confused but finally found that apparently GAE trimmed unsafe package out for a reason. Since luar and golua need the package, I think I have to find a new solution for this.
Is there any way to use luar and golua on GAE? If it is not possible, are there any alternative script languages that will run on GAE environment?
The just announced Managed VMs will allow you to run App Engine applications on Compute Engine virtual machines. This allows access to the full range of libraries, filesystems and sockets. As of today (April 20th, 2014) Managed VMs are in Limited Preview, so you'll need to fill out the form here to get access.
I have created a GWT application and now want to deploy it outside GAE. The reason I wish to deploy outside the GAE is the Sandbox security feature of GAE, which disallows me from writing files to my system. I store my data in the form of an ontology (.owl file) under my '/war/WEB_INF' and I want the end user to be able to modify (write to / save) this file through the server.
I understand that GAE does not let me do this, but is there a paid Google Service (e.g. google apps) that would allow hosting a GWT application which would allow writing files to the system? For instance, like an add-on to GAE?
If not, what solution would you recommend to host a GWT application (that would let me write a file to the WEB-INF folder) on the web?
EDIT: I solved this by deploying the GWT project as a .war file and hosting in TomCat.
I'm very new to GAE, but in case you haven't looked at their experimental write/read blobstore services you can check that out here. They have a similar API for python I believe. It's ofcourse stored on the GAE blobstore and not under /war/WEB-INF/ directory but It does allow a possible solution to what you're looking for.
Also, if you're looking to run your own server (possibly on EC2 for example), then you might want to look into AppScale. But I, personally, would stay away from that as a solution because I highly doubt that AppScale performs as well as google's GAE web servers and furthermore lacks the same degree of support/development.
Have you ruled out something like creating an Owl Entity to hold your ontologies, and arranging for *.owl requests to be handled by using that as a key name to find and serve the corresponding Owl? That's really simple code.
GWT is primarily a client side technology. GAE is a server side technology. You seem to be getting GWT and GAE engine mixed up with each other. GAE can work with almost any client side technology, and GWT can connect to many different back end platforms.
Are you trying to move your back end code directly to a new platform? Are you planning on rewriting the back end for a new platform, but keep the GWT code? What is your goal for this application? To be used by you and a few friends, or by thousands of people? For free or paying customers?
If you want to move off of AppEngine, you can switch to pretty much any java hosting service that you want - anything from a tiny shared VPS up to a Amazon EC2 mini cloud of your own. I don't think google offers generic java hosting. I don't know how you have built your application's back end, but you probably used servlets, which you should be able to get working pretty much anywhere.
If you want to stay on AppEngine, you should think about whether or not you can break your owl file into smaller sections that can be stored as entities in the database.
Whichever platform you choose, if you are planning on serving more than a few people, you will need some way to prevent one giant owl file from becoming a huge bottleneck.