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.
Related
I am writing a web application using Google App Engine, and to promote it (and give more information about it), I will also have a web site. For ease of deployments, it makes sense to have the web site separate from the application itself. I would like to be able to make changes to the web site independent of the application. I would think that making a change to the web site would NOT mean a re-deployment of the application.
I would like to have a domain, and for the purpose of this question, let's call it www.example.com.
App Engine allows for multi-tenancy, and it makes sense to use sub-domains. For this question, let's assume www.org1.example.com / www.org2.example.com, etc.
Given this scenario, how is this done in the enterprise world on GAE? Do companies:
have the web site and application all as one?
use their hosting provider to redirect sub-domain requests to their application?
have completely separate domains for the web site and application?
something else?
Thanks in advance,
If you want to be able to independently deploy the web app and the web site they need to be at least in separate GAE services/modules, which offer complete code isolation.
Yes, it's not a problem to have the separate services mapped under different subdomains of the same domain. I'm not very sure if it'd work with the sub-domain split you proposed and with wildcard SSL certificates. From App Engine support for SSL certificates:
Wildcard certificates only support one level of subdomain.
So I didn't even try such subdomains. But I am using a wildcard certificate like *.example.com with subdomains like these, each mapped to a different service:
www-org1.example.com
www-org2.example.com
I'm also using a dispatch.yaml file to route each domain to the respective service.
Now about the multi-tenancy, I'm unsure if it's what you actually need, because it's offering just data isolation, not code isolation. You still need to address code isolation if you want to deploy them independently. From About multitenancy:
Multitenancy is the name given to a software architecture in which one instance of an application, running on a remote server, serves
many client organizations (also known as tenants).
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.
I'm trying to use a subdomain to serve a matching version id with Google App Engine and Google Apps. I've gone through the documentation but it's still unclear to me.
On this page regarding custom domains, it says I'm in a special case for using Google Apps. test.example.com -> to load "test" version of the application.
https://cloud.google.com/appengine/docs/domain -
Note that the instructions on this page are for App Engine apps that use an ordinary HTTP connection and are not served through Google Apps. Here are some related procedures that require different instructions:
This leads me to here https://support.google.com/a/answer/91080
It looks like the only way to add this subdomain in Google Apps is the Sites URL field.
Will the Sites URL correspond to the App Engine version ID?
You only need to use Google Apps to map an appengine app to a domain if you need https. Right now, Google Apps is the only way you can upload an SSL cert - hence this restriction.
If you do map your appengine app to a domain through google apps, you can do what you want by using wildcard subdomain mapping. Read more here..
The whole process is tedious, slow, and painful, and thats only when its not confusing, so put aside a good few hours to make all the changes and wait for DNS to propagate.
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
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 ;-)