We would like to develop and sell custom commercial GAE applications. I would like information on the deployment of GAE applications on arbitrary Google Apps domains (i.e. not appspot).
Suppose our company is abc.com and we are selling app to def.com and xyz.com. What are the steps to deploy our app on our customer's domain?
When an app is deployed on many domains:
Is the code duplicated or shared?
Is the datastore definition duplicated or shared (or more precisly the kinds)?
Any domain attribute add to the entity?
You have three options at the moment, when it comes to a 'multi-tenant' app such as you describe:
You can have a single app that your customers add to their domains. Your app will have a single datastore, but you can use the Host header to determine which customer is accessing the app, and segregate the datastore entries based on that.
Easy to deploy and upgrade
Easy for customers to install
Users have to have Google accounts, not Apps accounts, to log in.
You can deploy a fresh app instance for each customer.
Harder to deploy and upgrade
More customer involvement required to install
Provides firm separation of data
Users can log in with their Apps credentials
You can work with Google to create a new Apps Marketplace app
All the benefits of point 1 and 2, above
Requires Google involvement
No certain release date yet
This is possible but to the best of my knowledge, def.com & xyz.com will have to sign up for Google Apps.
Once the domain is registered with Google Apps by your prospective customers, they can add not only Google Apps like Gmail & Docs to subdomains (mail.def.com & docs.def.com) but also any GAE apps (fooapp.def.com).
Is the code duplicated or shared?
Shared
Is the datastore definition duplicated or shared (or more precisly the kinds)?
While the schemas (definitions) are shared, what isn't shared is the actual datastore. i.e. each instance of your app will have separate data.
Any domain attribute add to the entity?
You can figure out which domain your app is being served under using one of the CGI/HTTP environment variables. I don't remember which variable exactly but I'll update the answer once I look at some old code of mine. Once you find out what is the current domain, you can choose what to do with that info, including saving it to an Entity or simply denying access.
Another cool feature about this is that let's say company def.com is using hosted GMail and have Google Authentication for their employees. Now if your app is using the GAE provided authentication hooks, then you can automatically authenticate just their employees without any code change on your part! At least, that's the theory since I haven't tried it out myself ;-)
Related
Google Cloud's structure related to "projects" has me really confused.
On the one hand all GCP services are encapsulated in a "project" right? So I think, OK I'll create something like "test", "stage", and "prod" projects. All my applications can be tested in "test" and eventually move to "prod" when they are ready to go live. Also, I can have SQL,bigquery,bigtable and whatever else in the test project that developers can hack on without having to worry about effecting production.
But I can only have one app engine app per project? How does that work? I can see how in app engine you have different versions so if I have one project per app engine app the test/staging mechanism is in that app's project, but what about the other GCP services?
If I have a bigtable or bigquery or something on storage multiple apps need to access what "project" do I put that stuff in?
Do I still have a "test","stage","prod" project for my services (where my DBs, storage, etc live), but then also create separate projects for each app engine app?
If multiple apps need to access something, it can live in one of the app's projects- that doesn't make sense.
Edit: google does have some good docs about how projects and services can be organized https://cloud.google.com/appengine/docs/python/creating-separate-dev-environments
While you can only have one App Engine app per project, an App Engine app can host multiple services, each of which has several versions of code deployed.
You can configure resources in one project to allow access to users/apps outside that project. See, for example Setting ACLs for how you can allow multiple projects to access a Cloud Storage bucket. Similar cross-projects access can be configured for most if not all Google Cloud resources/services/apps - but you need to check the respective docs for each of them to see the specific details each of them may have.
With this in mind it's really up to you to organize and map your apps and resources into projects.
Overview of problem. Site was running on a Free version of Google Apps for over a year as a simple web page. We started developing it we deleted the old Google Apps and and migrated it to our primary App Engine account to avoid billing issues of two+ accounts. We couldn't get App Engine to recognize the Custom Domain even though it was in the Domains tab of our Google Apps Account. In searching I found Google limits using domains on App Engine (http://support.google.com/a/bin/answer.py?hl=en&answer=182081 scroll down to App Engine) I had to recreate a separate Google Apps account to verify ownership of the domain. Site is up and operational now outside of SSL. The issue is that when I go to https://admin.google.com/CPanelHome#DomainSettings/subtab=domains and type the app id to enable SSL on the domain Apps account it routes me to create an App Engine app instead of to billing. Because the app is running on the primary App Engine account not the Domain account.
It seems someone must have ran across this and solved it. How do I enable my primary Google Apps account to verify ownership of the domains and allow App Engine to use it? I have a lot of domains that will be hosted on App Engine and a lot of integration between the sites that would really need to be all under a single account to facilitate.
I noticed in searching that Google is offering a free year of Google Apps for customers using App Engine to host a application. Is Google expecting every domain to have a full Google Apps account and host on separate App Engine accounts? If so that would really limit our ability to use App Engine.
After waiting for three days for an answer I am moving on. I believe I tried every way imaginable to accomplish getting multiple domains on a primary Google Apps account to be verified and have SSL enabled. I went so far as to try it with a domain that has never had any Google services. Just in case there were some settings that were causing issues from left over configuration.
So the resolution of this at this time is Google expects you to have a full Google Apps account per domain to enable SSL, or Google App Engine on it. I believe they will be removing the Free Google App Account in the near future. This effectively means that hosting on App Engine will get expensive as a Google App Account is $50/year, and if you use a CloudSQL instance it will be at minimum $9/mo. That is on top of the bandwidth and usage fees.
I have already deactivated billing and disabled the apps on those accounts and have moved them over to a VPS. This is the third year I have spent a lot of time trying to get basic sites using SSL established on Google. While this year it is possible to do it, in the end you pay an arm and a leg for it.
I love Google and really want App Engine to be viable. But I just don't think they will pull it together. All my friends have went with Azure, RackSpace, and the granddaddy Amazon. It really makes me sad that Google is so far from viable and even worse that Azure just works.
If anyone at Google wishes to contact me feel free to do so. If there is something I missed feel free to open this and give directions on how to host multiple domains on a single App Engine / Apps account with SSL. I would greatly appreciate it.
I am considering developing a platform in GAE.
for this to work I would like to be able to have run the same app engine instance run several 'sister' sites. This would be something similar to the way that the stack exchange sites work, so each 'sister' site would have its own users, data and theme (but may potentially be configured slightly differently - think different plugins used), but essentially would have the same function & format.
I would like to know if it would be possible to have each sister site have its own (customer defined) url, which would use the same app engine instance, and the app engine instance would be configured (by setting the site id and valid plugins for that site) depending on the url which was used to access it.
Yes, this is entirely possible. As Fox32 points out, you can use namespaces to separate different datasets. For domains, App Engine supports wildcard mappings, so you can map *.yoursite.com to your app. If you want to add custom TLDs, either you or your customers will need to create a Google Apps account for them, or add the domain as an alias on an existing Apps account, and associate it with the App Engine app - this doesn't require that they be admins of your app to do so.
You can use namespaces, to separate different websites, for many api methods. Take a look at the GAE documentation about it.
The Namespaces API is integrated with Google Apps, allowing you to use your Google Apps domain as the current namespace. Because Google Apps lets you deploy your app to any domain that you own, you can easily set unique namespaces for all domains linked to your Google Apps account.
I am interested to build a platform on Google App Engine where one Master App provides common functionality to several child Apps (Web portals).
Master App:
Offers Common Social Networking features
Common user database
Interacts using Web services API
Child Apps (Web Portals):
Connects to Master App for user database and social networking features
Uses Local business logic for local features
My Design plan is:
Master and Child Apps will be
individual Apps on GAE Appspot (for
easy management)
All will communicate via REST/JSON?
I will enable billing for all Apps so
nothing is against Google's usage
policy.
Will use SSL for login into Master App, later use a token
(cookie) for further interactions
Could anyone kindly spot risks and suggest any improvements?
Your "Master/Child" concept will be hard to maintain, introduce issues with cross-site-scripting and most importantly be completely against Google App Engine's terms of service for combining multiple apps into one.
4.4. You may not develop multiple Applications to simulate or act as a single Application or otherwise access the Service in a manner intended to avoid incurring fees.
You could use multiple app versions (defined on app.yaml) to deploy different codebases to the same appspot.com subdomain, and access them like http://app1.myapp.appspot.com, http://app2.myapp.appspot.com for "versions" app1 and app2. You could even have one version running on Java and another one on Python.
They'll all share the same datastore, although you'd be able to use namespaces to separate them if necessary.
For the distributed nature of the architecture you proposed, I'd suggest having a deep look at Facebook's graph API and Twitter's API. They both use oAuth for authentication/authorization and already have a proven implementation of what you're trying to accomplish.
Actualy, It's a couple of questions:
Is it possible to somehow avoid registering google apps if I just want to connect google app engine applications to non-naked domain (www.example.com for example:)
If described above is impossible, than do I have a right to register Google Apps Education Edition. And how can I proof that I'm non-profit if I'm not US resident?
If I need to connect a couple of domains to a couple of google app instances must I use a couple of google appss as well?
Here is a couple of answers:
No, Google App Engine uses Google Apps to manage domains. See the Deploying your Application on your Google Apps URL article.
Yes, if you are a School or University as explained here. If you aren't, why don't you just go for the Standard Edition?
Yes, for a couple of domains and a couple of GAE instances, you'll need a couple of Google Apps AFAIK. But this shouldn't be an issue as the Google Apps Standard Edition is free. No. As pointed out by Nick, you can add multiple domains to an Apps account as aliases, then map them to different App Engine apps.
Edit: The 3rd answer has been updated with the input provided by Nick Johnson in a comment.
With the the (new?) developer console it is possible add domains to apps for free without using Google Apps. But you will not be able to use HTTPS without registering the domain with Google Apps.
So the answer to the first question is "Yes" (presuming TLS is not required). The second question is not relevant. And as for the third question, multiple domains can be linked with the same application (without using Google Apps).
Select your project in the developer console (https://console.developers.google.com/project)
Navigate the side menu to access App Engine domain settings (App Engine -> Settings)
After verifying your domain (which may take some time) you can add the domain to the app.
I can't currently find Google-blessed documentation to support this. But I am currently serving an App Engine application on a domain that is not registered with Google Apps.
Another option commonly used is to use a reverse proxy to map customer domains to your AppEngine app. I'm using this because I can't add them as Google Apps domain aliases on my primary domain, since some customers run Google Apps by their own.
Details here: http://devblog.ronoaldo.net/2013/09/mapping-multiple-domains-to-google.html