I have a Java application deployed to AppEngine Standard and connects to Cloud SQL via public IP. I was looking at VM instances dashboard and found a set of instances with the following naming pattern and these are alerting for high cpu utilization.
aet-uswest1-mysql--access-{abcd}
The description says "Anthos/GKE and Dataproc VMs are Google-managed and include built-in agents.". These are all e2-micro instances and I could not change the instance type. At first I thought these are the underlying AppEngine instances, but the AppEngine instances I use are F4 class, I think these instances are something else.
What are these instances and how are they used?
Here is the list I see under instances in VM instances dashboard. I can't ssh or manage these instances. (I have randomized the instance names and ip addresses)
Name,Agent,Active Alerts,System Events,Zone,Private IP,Size
aet-uswest1-mysql--access-abcd,Not applicable,0,0,us-west1-a,10.5.0.9,e2-micro
aet-uswest1-mysql--access-efgh,Not applicable,0,0,us-west1-a,10.5.0.12,e2-micro
aet-uswest1-mysql--access-ijkl,Not applicable,0,0,us-west1-b,10.5.0.3,e2-micro
aet-uswest1-mysql--access-mnop,Not applicable,0,0,us-west1-c,10.5.0.7,e2-micro
aet-uswest1-mysql--access-qrst,Not applicable,0,0,us-west1-b,10.5.0.5,e2-micro
aet-uswest1-mysql--access-uvwx,Not applicable,0,0,us-west1-b,10.5.0.10,e2-micro
aet-uswest1-mysql--access-yz01,Not applicable,0,0,us-west1-c,10.5.0.2,e2-micro
aet-uswest1-mysql--access-23df,Not applicable,0,0,us-west1-c,10.5.0.6,e2-micro
aet-uswest1-mysql--access-efef,Not applicable,0,0,us-west1-a,10.5.0.11,e2-micro
aet-uswest1-mysql--access-57sf,Not applicable,0,0,us-west1-b,10.5.0.13,e2-micro
My understanding that AppEngine service was connected to Mysql via public network is incorrect. I found that these instances are related to VPC connector used by AppEngine standard to access MySQL service.
I am trying to get multiple microservices to run on a single app engine of a single project. I am following this official documentation from GCP
https://cloud.google.com/appengine/docs/standard/python3/mapping-custom-domains
When I try to create a wild card mapping like this
gcloud app domain-mappings create '*.example.com'
So that GCP backend engines can match the request accordingly:
[VERSION_ID].[SERVICE_ID].example.com
I get the following error
ERROR: (gcloud.app.domain-mappings.create) INVALID_ARGUMENT: A managed certificate cannot be created on a wildcard domain mapping. Set `ssl_management_type` to `MANUAL` and retry the domain mapping creation. You can manually create an SSL certificate with `AuthorizedCertificates.CREATE` and map it to this domain mapping with `AuthorizedCertificates.UPDATE`.
Could anyone help with this?
It looks like by default the command attempts to configure managed SSL certificates, which aren't compatible with wildcard domain mappings. From Wildcard mappings:
**Note**: Wildcard mappings are not supported for managed SSL certificates.
As the error message suggests you can disable that with an option. From gcloud beta app domain-mappings create:
--certificate-management=CERTIFICATE_MANAGEMENT
Type of certificate management. 'automatic' will provision an SSL
certificate automatically while 'manual' requires the user to provide
a certificate id to provision. CERTIFICATE_MANAGEMENT must be one
of: automatic, manual.
So just try instead:
gcloud app domain-mappings create '*.example.com' --certificate-management=manual
I see a discrepancy: the error message mentions the ssl_management_type option while the doc page shows certificate-management. Try both if needed - it may be just an error or it may be a renamed option (which may or may not still be supported under the hood).
Of course, if you want SSL, you'd have to manage the SSL certificate(s) yourself (maybe using the --certificate-id option, documented on the same page?). In that case also check out the related Google App Engine custom subdomain mapping for a specific version for potential implications of variable domain nesting.
I'm doing https web requests in silverlight using "WebRequest"/"WebResponse" framework classes.
Problem is: I do a request to an url like: https://12.34.56.78
I receive back a versign signed certificate which has as subject a domain name like: www.mydomain.com.
Hence this results in a remote certificate mismatch error.
First question: Can I somehow accept the invalid certificate, and get the WebBresponse content ? (even if it involves using other libraries, I'm open to it)
Additional details: (for those interested on why I need this scenario)
I'm trying to give a client access to a silverlight app deployed on a test server.
Client accesses the silverlight app at: www.mydomain.com/app
Then I do some rest requests to: https://xx.mydomain.com
Problem is I don't want to do requests on https://xx.mydomain.com, since that is on our productive server. For this reason I use https://12.34.56.78 instead of https://xx.mydomain.com.
Client has some firewalls/proxies and if I simply change his hosts file and map https://xx.mydomain.com to 12.34.56.78, web requests don't resolve to the mapped IP.
I say this because on his network webrequests fail if I try that, on my network I can use the hosts changing without problems.
UPDATE: Fixed the problem by deploying test releases to an alternative: https://yy.domain.com and allowing the user to configure for test purposes, the base url to which I do requests to be: https://yy.domain.com.
Using an certificate that contained the IP in the subject or an alternative subject would've probably worked too, but would have cost some money to be issued by a certified provider and would not be so good because IP's might change.
After doing more research looks like Microsoft won't add this feature too soon, unless there's a scenario for non-testing/debugging uses.
See: http://connect.microsoft.com/VisualStudio/feedback/details/368047/add-system-net-servicepointmanager-servercertificatevalidationcallback-property
I'm wondering if the always on feature would be similar to having a static VIP? if so then I can directly edit zone file to go that address instead of via the ghs.google.com dns system. Hopefully this should be better in regards to filtering/censorship etc.
No. The always-on feature affects the provision of application instances on the backend; it has no effect on the routing of requests from the frontend to your app.
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