I have a Python GAE flex app, and I received an email from Google stating:
We are writing to let you know that the v0.1 and v1beta1 endpoints of
the Compute Engine Metadata Server will be shut down on January 15,
2020. From January 15, 2020, requests to the v0.1 and v1beta1 endpoints will no longer be supported, and may return HTTP 404 NOT
FOUND responses.
The email also stated that my app used these old metadata endpoints in the last 90 days.
I had never heard of the Compute Engine Metadata Server before so it is not something that I have intentionally used. I suppose it is possible that one of my dependencies (Flask etc.) but it seems unlikely.
Any idea where my GAE Flex app might be making a call to the Compute Engine Metadata Server? Is this a false alarm from Google?
No, it is not false alarm. As it writes in the public documentation:
v1beta1 server and v0.1 metadata server endpoints are deprecated and scheduled for shutdown. Ensure that you update all requests to use v1. For more information, see Transitioning to the v1 metadata server endpoint.
The metadata server is the place on where the GCE instances are storing their metadata. Your App Engine Flex app is running on compute instances. You can use the Metadata server to query information about the instance like : ip, instance id, service account info etc..
App Engine Flex uses the metadata server in the back scene, so, even though you did not use the Metadata Server explicitly, app engine does it. Although App Engine flex should do all the updates by itself and it is less probable for you to face any issues,it is recommended to migrate from v0.1 to v1 metadata server endpoint just to be sure. Here
there is a guide in the official documentation on how to achieve that.
Related
We have set up a VPC Serverless access connector, and configured app engine to use this in app.yaml. We have egress_setting: all-traffic set, as we want to access a 3rd party API from a specific IP address. We used the documentation from https://cloud.google.com/appengine/docs/standard/python3/outbound-ip-addresses#static-ip.
Part of our testing is hitting a large set of URLs on app engine and checking the HTTP status. In this testing we noticed a dramatic reduction in the rate of serving requests when using the connector. Since all egress traffic is routed via the connector, my first inclination is to think our applications usage of Google APIs (datastore, cloud storage, Cloud SQL) is being impacted.
The connector is still has the minimum number of instances as active instances, indicating we have not reached the limit of it's performance, and that this is not the bottleneck. However, retesting with the vpc_access_connector removed from app.yaml returns performance to what we previously had.
I've tried enabling Private Google Access on the subnet the connector is linked to, but this has not improved the situation.
I think we may need to add some routing rules that allow us to send the traffic for Google APIs directly to Google's services, and not through the cloud NAT, but I'm unsure as to what rules would be applicable. I see no reason why this is not possible, but I haven't found the right documentation to guide me here.
Is this possible? Is this documented somewhere?
I have a golang gorilla websocket server hosted on Google App Engine (GAE) that randomly disconnects connected clients after about an hour of being connected (without any activity).
I checked GAE logs and compared timestamps of close events (code 1006) and noticed that the time differences between opening and closing connections are all nearly the same (~60.1 minutes).
Is there a proper way to fix this issue (example: update associated nginx config) for Google App Engine?
I'm fairly certain that this an issue with GAE as I'm unable to reproduce this issue locally/in-development.
I couldn't find any other good ways of hosting an autoscaled/managed server that supports the websocket protocol.
My alternative hosting choice may be kubernetes, but the costs are much higher than GAE AFAIK and K8s is slightly more difficult to manage.
I found a few related stackoverflow links with no proper solutions (mostly migrations to other services or hacks)
example: GAE App Engine Websocket clients are disconnected after 1 hour
It's well documented on GCP docs :
WebSockets are always available to your application without any additional setup. Once a WebSockets connection is established, it will time out after one hour.
I wouldn't suggest creating a Websocket server on a serverless platform because these products tend to scale down over time when there's no requests on it so you cannot guarantee that it will continue holding the connection (also along with the hard limit mentioned).
You can host your Websocket server on Compute Engine. In fact, GAE Flex uses Compute Engine autoscaler. Here's a link if you're interested to see how it works.
I am using Google cloud to run some services. speifically, I have code running in firebase, as well as Cloud Run and Cloud SQL.
For some reason, however, I am seeing constant traffic to a compute engine API, which I have no idea why? I don't have any VM's setup (outside of what Cloud SQL is running), but I'm assuming that's a separate service.
Why would I be seeing this traffic against this API? I could "disable" it, but the warning says any resources created with it could soon be deleted and I don't want to bring down my Cloud SQL or Cloud Run instances. There's nothing I can taht would generate 418,000+ requests this month....unless this is just internal Google stuff to support my cloud SQL and Cloud run instances?
Any ideas what this could be? Should it be safe to disable this?
You will see traffic on the Compute Engine API because you are actually using the service.
CE API is not just related for GCE instances, it handles much more of that, for example: Disk, Firewall, Snapshots etc.
You can find more information about the CE API here
So I recommend not disable the CE API because it can cause errors and other problems.
My Django app is working on GAE with Cloud SQL（MySQL）.
By using New Relic Monitoring, I tracked requests done by my app to www.googleapis.com.
I don't know those requests. Can somebody explain this behavior?
(app connecting with cloud proxy)
As merely described here, there are various processes running in the instance along side (with?) your application... scaling, billing, logging, etc. Communication with other Google Cloud Services (like the ones I previously mentioned) is mainly done through Google Cloud APIs. Since App Engine is a managed Platform as a Service, this management needs to be done somehow... a myriad of REST API requests and responses do this. Partly through the www.googleapis.com endpoint.
You don't have to worry, though... your application's performance is not affected by this, nor your billing account.
I am pretty new to this whole idea of cloud and started of with Google app engine. I was able to create the basic 'hello world' program.
When i tried to understand the difference between a cloud and a server I learned that Cloud is where you have an access to virtual instance created exclusively for you and you are free to choose and install software of your choice.
But I don't see such an option with Google-cloud/app-engine. What if I have a tom-cat based application server which I would like to deploy on a cloud? Will Google app engine be of any help or should I try other cloud service providers such as Amazon EC2, hp cloud etc?
/DJ
The cloud type that you are referring to is called Infrastructure as a Service cloud.
OTOH, Google App Engine is Platform as a Service cloud.
The difference is that IaaS are a bunch of virtual machines that you need to setup yourself (OS + app stack), while PaaS typically comes with it's own API, where you write your app against the API and the rest (sw stack + scalability) is taken care of.
AppEngine comes with it's own servlet container (Tomcat is also a servlet container), so from this standpoint you could use your code on AppEngine. But the problem lies elsewhere: AppEngine imposes a set of limitation on the apps:
app must use GAE provided databases.
app can not write to filesystem
app can not have listening sockets
requests must finish in 60 seconds (e.g. no Comet or WebSockets -> no push)
You might want to review the FAQ.
To add to Peter's excellent answer, note that Google also has an IaaS service called Google Compute Engine.
Regarding other cloud query-
Before you start with cloud you might once try other options. Currently deploying application in almost all services are very easy.
few of them are-
Jelastic , Heroku , rackspace , nimbus , openshift etc.
Difference between cloud and server is very well explained already.
Since you mentioned about tomcat based application , I have worked with Jelastic for the same and found very easy to implement.
http://jelastic.com/docs/tomcat
http://jelastic.com/tomcat-hosting
Try all possible option , it will help you more .