I want to build a web application using a mixture of App Engine Standard and Flexible Environment as described in the Google docs (flexible as microservice where third party software is needed, standard for everything else).
I need the mentioned microservice to run latex, a few linux tools and python. What is the best way to go from here?
My guess is:
Build a docker container from a Linux OS and use either Google Pub/Sub, Google Task Queue or plain HTTP for communication with the Standard Env App.
But how is this custom runtime then managed by Google regarding security updates, scaling, loadbalancing and everything else promised in the docs?
Sorry for the rather generic question, the infos are thin IMHO and so I have to ask.
It would be your responsability to re-build the custom runtime images (done during every app deployment) to incorporate security updates. If your Dockerfile references other Google-supplied base images then the security updates for them will be automatically picked up in the process. But for any additional packages or customisations you added to your runtime you may need to incorporate the updates yourself.
Scaling depends on your app's configuration (your responsability), see Service scaling settings.
Google automatically load-balances traffic across your app's instances.
Related
I have an standard appengine app currently running. I am currently developing another flask app which will use flexible runtime. I am wondering is it possible for me to have both apps in same project?
Yes, it is possible, with each of your "applications" being implemented as separate services/modules in the same GAE app. Services/modules offer complete code isolation, see Comparison of service isolation and project isolation.
See also: Custom runtime for non-flexible environment app?
There is an even easier way to do this that doesn't require creating a separate service :)
Since you are only developing your second application, you do not need to set it as the default version to serve traffic to the public. You only need to access it yourself, (or perhaps whoever you give the URL to). The only drawback really is that you will not be able to access your project at the default url, usually .appspot.com
Therefore, you can simply deploy your flexible app engine project, but make sure you don't give it any traffic sharing or promote it to the main version!! You can then access your version simply by clicking on the version in the google cloud console, or by visiting http://-dot-.appspot.com/ (It was not possible to access individual versions like this for flexible for quite some time, but this has now been resolved.)
We have Java servlets up and running on GAE, using blobstore, datastore and other cloud services.
Currently, we're starting a migration process to cloud Endpoints and we've hit an issue: if we use a different GAE project, we would not be able to query regarding current datastore entities (to the best of my knowledge, Google doesn't want you to do this - see
this question
and the GAE terms of service - section 3.3d), so we need to use the same project for both.
I looked up whether it's possible to have one GAE instance running Java servlets and one instance running Endpoints, but I found no conclusive answer anywhere.
If we try to implement and something goes wrong, we're looking at a potentially major issue for our users, so we need to be sure beforehand.
Has anyone tried something similar, and can assure us that this works?
You have 2 options to run the old and the new code inside the same app (thus with no issues sharing access to the datastore) but as separate engine instances, so they can be developed/deployed/managed independently:
as different versions of the same app/module(s):
the old version remains the default, the new one can be accessed at a different URL during development (possibly via URL routing)
you can use traffic splitting to do live A/B testing on the new code and for gradual final migration until you make the new version the default
as different modules of the same app:
both can run (fully functional) side by side indefinitely, but you need to be more careful during development
traffic is routed to the modules in several possible ways
final migration is done by publishing the new URLs, eventually re-directing the old URLs and finally bringing down the old module code
The 2 approaches can even be combined, if needed, as the final solution described by the OP's in this somehow similar question (for the python environment, but java equivalents exist): Google App Engine upgrading part by part
I've been thinking lately about the pros and cons of using AppEngine.
My concern would be, when we create application for GAE, the front-end code (the UI stuff) is served from the same application instance in the GAE cloud as with the Datastore codes.
The question would be when my applications grows:
For GAE:
Do I need to create multiple instance of my application?
If so, what do I need to manually update all instances?
For Appscale:
Do I also need to create multiple instance of my application?
If so, what do I need to manually update all instances?
GAE starts new frontend instances automatically, you even can't create or update frontend instances. You just need to configure min/max latency, min/max idle instances in Application Settings. See docs for performance settings
Btw, there are also Backend Instances that can be Resident and started manually from Admin Console. But it's useful only when you need something very specific
You seem to have missed the whole point of AppEngine, which is that Google takes care of scaling your app for you automatically. You seem to be confusing 'instance' with 'version' - you have control over which version of your app is serving, but Google dynamically creates and kills instances of that app depending on load. That's the main benefit of using AppEngine in the first place.
I'm currently building a live web application based upon the PubSubHubBub protocol. However, I encountered several issues.
First, I'm in search of a hub application that I can run on my server. There are several applications, but most of them are not mature yet, or they don't support the 0.3 spec. The official google hub runs on the Google App Engine and can even be executed locally. Unfortunately, "Tasks will not run automatically. Push the 'Run' button to execute each task." This behaviour is useful for debugging and understanding the workflow, but in some live tests, it would be nice not to invoke all tasks manually. Is there a way to tweak the local app engine due automatically run tasks?
Next, I have a question concerning the spec itself. The Google reference implementation provides the initial publish method bound to the outpoint uri + /publish. But this is not reflected in the specs.
So are there any mature hubs that can be run locally for debugging? Or are there ways to configure the offical google app engine hub to run locally and to execute tasks directly?
Thanks in advance
The new 1.3.4 App Engine SDK automatically runs tasks. Just upgrade your SDK to take advantage of it.
Next, I have a question concerning the spec itself. The Google reference implementation provides the initial publish method bound to the outpoint uri + /publish. But this is not reflected in the specs.
/publish is the only endpoint provided by the hub. As per the discovery section of the spec, that is the one you advertise.
Btw, https://github.com/pubsubhubbub/PubSubHubbub/wiki/Hubs lists all currently known hubs and software.
I also made my own hub that implements the 0.4 spec; see https://github.com/cweiske/phubb
I am a fan of the extensibility of the CMSes. You can upload some code (usually PHP), authorize it from the CMS admin panel and it's running.
I wonder if it is possible in Google App Engine. I haven't checked the extensibility of existing CMSes for Google App Engine, but if there is any of them that supports plugins I would like to know how they did it, and whether they are JS plugins only, or if they support Python/Java plugins too.
Nick Johnson from Google wrote an entire blog post series on how to write a blog system for app engine. If it doesn't do what you want, I am sure that you can extend it but normally a blogging system is sufficient for a CMS for most people.
I don't have a public example to point to (sorry), but I can confirm that it is possible to create Python plugins for an App Engine project. I completed a project a few months ago that does something like this. The crux of the thing comes down to a single line of python:
exec plugincode in someDict
Above 'plugincode' is a string containing some python code to execute, and someDict is a dictionary of globals to execute it in. This is arguably cleaner than using eval(). In our case the globals dictionary contained an instance of an object that the plugincode used to communicate with the system. I can't think of any major limitations with this (or similar) approaches. e.g. plugincode could declare a class, and register an instance of that class as a callback handler etc etc.
In our case we stored the plugin code in the Data Store, and loaded it at appropriate times (e.g. when an instance of the app is started).
Actually I see no conceptual problem with supporting plugins in App Engine application. For example on Java you may fetch plugin jar to memory from data store or memcache (on application initialization phase), and then use custom class loader to load plugin classes as needed). Actually you even may load classes from request data and evaluate them on the fly if needed (how we do it in AppWrench Java console).
Regards,
Pavel.