I'm looking for something that can be done like this setting in Tomcat:
<Context ... sessionCookiePath="/" > ... </Context>
You can persist session information in database like Datastore and use Memcache to get the session/user information faster. Take a look at the web application architecture - https://cloud.google.com/solutions/architecture/webapp
Related
According to [this doc][1] I should be able to reach a non-default service through URL patterns.
I am using a custom domain. (site.com) This is working to reach the default service.
I want to reach a second, non-default service called my-service.
According to the docs, it seems like this is the way to do it:
my-service.site.com
However, this isn't working. I understand I can use a dispatch.yaml file, but I would like to set it up just by the URL's if possible.
How do I set this up correctly?
Edit: The exact error (url replaced) is this:
This site can’t be reached
my-service.site.com’s server IP address could not be found.
[1]: https://cloud.google.com/appengine/docs/standard/python/how-requests-are-routed#default_routing
The URL pattern you are using is correct. This problem is a DNS issue for "site.com". It appears that while you have mapped "site.com" to App Engine, subdomains are not mapped to App Engine, thus the DNS lookup is failing.
You either need to ensure that you have a wildcard entry in place for site.com, eg:
*.site.com. 3599 IN CNAME ghs.googlehosted.com.
Or map the specific service subdomain(s) to Google.
my-service.site.com. 3599 IN CNAME ghs.googlehosted.com.
This maps requests to subdomains of "site.com" to Google's servers.
Further details are in the documentation here.
I like that I can use the Logs API (described here: https://cloud.google.com/appengine/docs/java/logs/) to programatically access and display app & request logs as I see fit--it's great.
Now that I'm using Managed VMs on AppEngine you can see on the Admin Console Logs Viewer that there are a ton of additional logs--including in my case a custom log which I found I could include in the viewer (decribed here: https://cloud.google.com/appengine/docs/managed-vms/custom-runtimes#logging).
My question is: Is there any way I can use the Logs API (or other pipelines already built?) to access these logs? My Managed VM module includes several components which could produce logs that I want to view:
App logs -- I can get these! No problem here.
Custom log files created by background processes I kick off in _ah/start (like "my_custom_1.log" in the screenshot)
STDERR & STDOUT from my background processes
Relevant Managed VM logs (e.g. for when an instance was restarted due to bad health... other system events like normal restarts?)
Basically I want "the total picture" at the instance level. Anyone tried to tame Managed VMs in this way with success? I'm not looking forward to rolling my own solution. And I wouldn't even know where to start on the problem of capturing STDERR and STDOUT. Any help appreciated.
There is a difference between App Engine logging and Google Cloud logging. Some of the Managed VM logs go to both, but much of it only goes to cloud logging.
Until recently there was not an API to read Cloud logs, only to write them. However, there is a new v2 beta API: https://cloud.google.com/logging/docs/api/introduction_v2
To do things at an instance level, entries in Cloud logging should have metadata set to denote which VM they came from. Both of these values seem to vary on logs from my VMs:
compute.googleapis.com/resource_name
compute.googleapis.com/resource_id
I am using CapeDwarf JBoss AS7 to host classic GAE+GWT application. On server side, I am logging directly to java.util.Logger framework.
The application works fine, the logs print nice to the console and files.
However, all my logs, together with some http request logs, are also stored in the datastore. Yes, every log line becomes one datastore entity. This should not surprise me, because it is stated in the docs (http://www.jboss.org/capedwarf/docs) and it is needed in order to display logs in gae-like admin console of CapeDwarf.
I was looking for a way to disable this useful but expensive feature. I cannot find any docs that would tell me what to do if I do not need/want my logs in the datastore (e.g. right now 98.3% of my datastore are __org.jboss.capedwarf.LogRequest__ and __org.jboss.capedwarf.LogLine__ entities!). Does anyone happen to know how to do it?
Already answered on our forum: https://community.jboss.org/message/810735#810735
I'm trying to use the "Copy to another app" feature of AppEngine and keep getting an error:
Fetch to http://datastore-admin.moo.appspot.com/_ah/remote_api failed with status 302
This is for a Java app but I followed the instructions on setting up a default Python runtime.
I'm 95% sure it's an authentication issue and the call to remote_api is redirecting to the Google login page. Both apps use Google Apps as the authentication mechanism. I've also tried copying to and from a third app we have which uses Google Accounts for authentication.
Notes:
The user account I log in with is an Owner on all three apps. It's a Google Apps account (if that wasn't obvious).
I have a gmail account this is an Owner on all three apps as well. When I log in to the admin console with it, I don't see the datastore admin console at all when I click it.
I'm able to use the remote_api just fine from the command-line after I enter my details
Tried with both the Python remote_api built-in and the Java one.
I've found similar questions/blog posts about this, one of which required logging in from a browser, then manually submitting the ACSID cookie you get after that's done. Can't do that here, obviously.
OK, I think I got this working.
I'll refer to the two appIDs as "source" and "dest".
To enable datastore admin (as you know) you need to upload a Python project with the app.yaml and appengine_config.py files as described in the docs.
Either I misread the docs or there is an error. The "appID" inthe .yaml should be the app ID you are uploading to to enable DS admin.
The other appID in the appengine_config file, specifically this line:
remoteapi_CUSTOM_ENVIRONMENT_AUTHENTICATION = (
'HTTP_X_APPENGINE_INBOUND_APPID', ['appID'])
Should be the appID of the "source", ID the app id of where the data is coming from in the DS copy operation.
I think this line is what allows the source appID to be authenticated as having permissions to write to the "dest" app ID.
So, I changed that .py, uploaded again to my "dest" app ID. To be sure I made this dummy python app as default and left it as that.
Then on the source app ID I tried the DS copy again, and all the copy jobs were kicked off OK - so it seems to have fixed it.
Here is what I'd like to achieve
http://foo.somedomain.com gets handled by
http://myapp.appspot.com/foo (google appengine app myapp)
and the underlying url is masked.
Note the following:
somedomain.com is a third party domain that would like to add foo.somedomain.com
mydomain.com would be CNAME'd to myapp.appspot.com
mydomain.com/foo would point to myapp.appspot.com/foo
other scenarios
can foo.mydomain.com be made to point to myapp.appsot.com/foo
can foo.somedomain.com point directly to myapp.appspot.com/foo
Added: myapp.appspot.com is developed using django w/ app-engine-patch
You can't do this in the way described. In order to do this, you need to:
CNAME foo.somedomain.com to ghs.google.com (not to myapp.appspot.com)
Set up Google Apps for your Domain on somedomain.com, if it's not already
Add the app 'myapp' to foo.somedomain.com through the Apps control panel
Once that's done, your app can check self.request.host to determine which hostname was sent, and route requests appropriately.
You can parse the sub-domain from the Host header, then call the webapp.RequestHandler appropriate for the path /[sub-domain], assuming *.yourdomain.com is directed to the Google App Engine application.
Have a look at webapp.WSGIApplication and see if there's a way to get the mapped webapp.RequestHandler for a path. Alternatively, you might be able to modify the request object to change the requested path (this I'm not sure about, however.)
This question was asked in one of the 2009 Google I/O app engine talks. Unfortunately the answer given was along the lines of not supported at this time but the possibilities of some workarounds may exist. 2009 Google I/O videos