As the title states; will google appengine remove the x.appspot.com domain if a custom one is mapped? Or will the unique x.appspot.com always work, regardless of custom domain mapping? Both in a short and long-term perspective.
x.appspot.com will always work.
The appspot domain is really important because it allows you to directly access different versions and modules. For example, if you have only a default module and multiple versions of it, you can access the versions like this:
v1.x.appspot.com
v2.x.appspot.com
The default version will be at x.appspot.com.
Related
By default, specific versions of an App Engine app are routed by URLs like https://[VERSION_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com.
Is there any way to have something similar with a custom domain?
I currently have a subdomain mapping for my app configured with a CNAME DNS record pointing to ghs.googlehosted.com (my "naked" domain is not served by App Engine). This allows serving the default version of my app from that subdomain, but I also want to be able to test new versions of the app using my domain (for various reasons such as sharing cookies, etc.)
For example, let's say my domain is typeracer.com and my custom domain mapping in App Engine is data.typeracer.com: I want to be able to access a specific version of my app at a URL like https://[VERSION_ID].data.typeracer.com. Is there any way to do this?
I've looked at the App Engine docs for adding wildcard subdomain mappings and using a dispatch.yaml. However, it looks like that would work only for routing specific services, but not specific versions of the app.
No, what you ask for exactly is not possible as the mapping is a (sub)domain per GAE service one, you cannot select a certain version of a service in the custom domain settings screen.
Sounds like may be attempting to implement different environments (say staging) based on service versions, which has some disadvantage, see Continuous integration/deployment/delivery on Google App Engine, too risky?
If so you can try to implement them using different services instead, which:
would allow you to map one (sub)domain per environment
you'd avoid all drawbacks mentioned in the above-mentioned Q&A
The domain naming scheme you mentioned suggests variable nesting levels, which in itself can be problematic, see Sub domain not listed in Google App Engine while enabling SSL for custom domains. Maybe try something like https://data-[VERSION_ID].typeracer.com instead of https://[VERSION_ID].data.typeracer.com?
If I add a custom domain like *.example.com to my app-engine project, I can then selectively add CNAMEs to that domain pointing to ghs.googlehosted.com to forward subdomains to this project, which will then identify versions in the project.
For example, if my project has a version called www and a version called contact, and I set the CNAMEs for www.example.com and contact.example.com to ghs.googlehosted.com, then www.example.com will be hosted by the www-version of my project and contact.example.com will be hosted by the contact-version of my project.
For completeness: If I don't use the *, but instead add www.example.com and contact.example.com as custom domains to my project, both will be served according to the traffic allocation to the different project versions, whatever they may be.
Now, things get interesting (and that's where my question comes in), if I add *.example.com as a custom domain to one project and dataserver.example.com to a different project. Now, Google App-Engine has to disambiguate whether dataserver.example.com refers to the dataserver version of the first project or to some version on the second project according to that project's traffic allocation.
When I set this up a few months back, it did (what I think is) the most logical thing: It picks the latter, since dataserver.example.com is more specific than *.example.com and should thus take precedence. But when I tried to set up another set of projects yesterday, it instead tried to serve me the dataserver version of the first project (which initially didn't exist, and thus I got 404s, but when I deployed a dummy one, I got that back).
Now the question is: What does App-Engine actually do? Is it random? Is it first-created, first-served? Is it by specificity, but might take a while to propagate to all servers?
Whiles playing around with GAE custom domain setup in hopes of building a multi-tenant application. I noticed that wildcard sub domains don't quit work as documented.
for example, if one configures domain *.dev.example.com *.qa.example.com you would expect dev.example.com to automatically serve default services deployed in appengine, I however noticed that recently I would have to explicitly enter default.dev.example.com. This however is not what has been documented.
Anyone understands why this is now the case? the domains are verified with DNS configuration on Google DNS service. All works as expected, meaning that I can reach all other services on domain, but default service is not automatically been served.
After various attempts, I eventually purchased some Google support time. And the solution to this is that you need to create and map both a wildcard domain and naked domain. Therefore, one will need to have both
*.dev.example.com and dev.example.com
This is of course tedious, the good news is that Google is running alpha testing on API that allows domain mapping to happen automatically, register at here
Soon multi tenancy application deployments will require no manual intervention.
Problem I want to solve
I want to be able to send different users to different versions of my Google App Engine application, on a custom domain, with SSL enabled. This needs to be done in a controlled way, i.e., even landing page should be different, and it has to work on multiple units for the user.
Solution I can't get to work
I am trying to setup a custom domain with sub-domains, and want to be able to access different versions of the application. For example, I have myapp.mydomain.com, and I want to run one version (alpha) on alpha.myapp.mydomain.com, and one version (beta) on beta.myapp.mydomain.com (where alpha is default).
I use the Google Developers Console to set up custom domains, using myapp.mydomain.com, and *.myapp.mydomain.com as custom domains.
This works perfectly as long as I don't try to add on SSL as well, i.e., beta.myapp.mydomain.com serves the version named beta. When I set up SSL I start by adding my application to Google Apps, (per https://developers.google.com/appengine/docs/ssl) and then set up my domain to point to my app. First I add myapp.mydomain.com, then alpha.myapp.mydomain.com, and last beta.myapp.mydomain.com.
When that is done beta.myapp.mydomain.com start to serve the default version instead. Except that it sometimes also serves the beta version (this happens one in every 20 tries or so, I assume it's a glitch for now).
My questions:
a) Should I set up my domains in both Google Apps and Google Developer Console? Or should I remove the setup from Google Developer Console? I tried both, seems to give the same results.
b) It seems like it is possible to get it done by using modules as indicated in
Google App Engine custom domains, subdomains and SSL and in Appengine modules dispatch.xml routing with custom domain. Is this the only way, or am I doing something wrong in my setup?
Suggestions I have received so far
One suggestion is to use traffic splitting and set a unique cookie depending on what version I want the user to end up with. I did not know about this, and it will solve some other issues I have been looking at. It does not solve my current problem though, as I need to have this set before log in. The answer is useful though.
I'll answer with what I did to make this work for me.
Instead of sending users to different versions of the app, I created a new module called alpha, and directed users using alpha.myapp.mydomain.com to that module using dispatch.xml.
<dispatch>
<url>*alpha.myapp.mydomain.com/*</url>
<module>alpha</module>
</dispatch>
I set up custom domains in the App Engine Console (https://console.developers.google.com) under Compute->App Engine->Custom Domains, for *.myapp.mydomain.com and alpha.myapp.mydomain.com. I also added the URL alpha.myapp.mydomain.com to the accepted URLs for my App Engine app on Google Apps (https://admin.google.com). This allowed me to run over SSL as well.
I intend to run the app under another domain (domain alias to my primary domain), so I tried that as well. To make this work I ONLY added the domain alias in Google Apps as www.mydomainalias.com and alpha.mydomainalias.com, because if I added it to Google App Engine custom domains I got an error message ("We are unable to process your request at this time. Please try again later. (Error #1000)"). I have no idea why it that did not work out.
The easier approach is to do traffic splitting on a cookie level compared to setting up extra subdomains AND extra SSL certificates.
The domain name to access your alpha version does not have to change using this approach.
from the docs :
The response from your app does not already contain a Set-Cookie:
GOOGAPPUID=... header. This allows your app to control which version a
user gets.
The docs say:
Note that authorization is associated
with the domain used to access the
endpoints: an access token produced
using endpoints on one domain cannot
be used to access the app using a
different domain. If the access token
came from a version-specific
appspot.com domain, it can only be
used to access that version of the
app, and only at that domain.
However, this isn't the behavior that I'm seeing. I have multiple versions of my app running against my custom domain (not appspot!), and when I switch which version is the default, all the tokens made with the version that used to be the default are no longer valid. The invalidated tokens were made on the same custom domain that is now mapped to the newly default-ed version of the app, and yet they're still invalidated. This basically destroys my ability to switch default versions, as doing so will inconvenience every single user.
Is this the expected behavior? Is there any way to get around it?
Thanks!
The docs say that it is supposed to happen; the actual version matters, Google doesn't care which version is the default.