Getting started with appengine.
My app has no front end.
Its a tcp/udp socket server.
When I try to deploy I get the error in the title.
Handler for what? Its not a webapp.
Is appengine the wrong google service for server apps?
You can always add a skeleton web handler (which may simply return a 404) to keep the deployment utility happy.
But be aware that the GAE standard environment sandbox is very restrictive for socket-based apps, see Limitations and restrictions:
Although App Engine supports sockets, there are certain limitations
and behaviors you need to be aware of when using sockets :
Sockets are available only for paid apps.
You cannot create a listen socket; you can only create outbound sockets.
FTP is not supported.
You can only use TCP or UDP; arbitrary protocols are not allowed.
You cannot bind to specific IP addresses or ports.
Port 25 (SMTP) is blocked; you can still use authenticated SMTP on the submission port 587.
Private, broadcast, multicast, and Google IP ranges (except those whitelisted below), are blocked:
Google Public DNS: 8.8.8.8, 8.8.4.4, 2001:4860:4860::8888, 2001:4860:4860::8844 port 53
Gmail SMTPS: smtp.gmail.com port 465 and 587
Gmail POP3S: pop.gmail.com port 995
Gmail IMAPS: imap.gmail.com port 993
Note: Google Compute Engine IP addresses are not considered to be in Google IP ranges. You can use sockets to connect Google App Engine
apps to Google Compute Engine instances.
Socket descriptors are associated with the App Engine app that created them and are non-transferable (cannot be used by other apps).
Sockets may be reclaimed after 2 minutes of inactivity; any socket operation keeps the socket alive for a further 2 minutes.
If your app can't abide by these restrictions you need to look at other alternatives, which would include the flexible environment GAE or Compute Engine.
Related
I have a python (flask) application running on Google App Engine (flex); the application is protected by the GAE firewall where:
Default rule is 'Deny' all ingress
There is a whitelist of IP addresses from which traffic is allowed.
I have some microservices deployed on Cloud Run (fully managed) which:
Receive requests from the GAE app (e.g. for heavy duty tasks)
Send the results of whatever they process as http requests back to handlers/endpoints in the GAE app
Thus the GAE app is the main point of interaction with clients and a dispatcher of heavy tasks, while the processing of those tasks is carried out by the microservices. I have set up a static outbound IP address of the Cloud Run hosted service which verfiedly works and traffic is routed through the NAT gateway as required in the documentation. The respective NAT IP address is on the firewall whitelist.
The problem is that the firewall still does not let in the Cloud Run >>> GAE app requests which bounce back with 403 statuses (of course, if I change the default firewall rule to 'Allow', traffic goes through). If I host the same microservice in a docker container on a GCE VM with a static IP address like this everything works flawlessly. This makes me hypothesize that albeit Cloud Run outbound traffic is indeed routed through the static IP address when traffic is towards addressees outside GCP, when I try to ping an internal (project-wise) asset it still goes though some dynamically selected IP (i.e. the static IP solution simply does not work). Unfortunately the logs don't show the 403-ed attempt so I can't see from what IP addresses those request seem to come (from a GAE standpoint).
I would be very grateful for ideas how this can be fixed as it greatly diminishes the value of the otherwise wonderful idea to have static outbound IP addresses for Cloud Run.
First, thank you both for your help and suggestions, they are very helpful. I found the solution with some kind help from Google:
When the Cloud Run microservice and the GAE app are hosted in the same project traffic is still routed through internal channels and appears to come from IP address 0.0.0.0 which can be whitelisted (so it would work) as long as one considers this address encompasses GCP assets which are parts of other projects too (to the best of my understanding)
A more robust solution seems to be setting up an externally facing load balancer as described here and putting it in front of the GAE app; in such a case, Cloud Run will indeed consistently use its static outbound IP address as described in the documentation
You are correct saying that the static IP is not honoured when packets are routed internally to GCP.
I think this is what you want. You have to allow in the firewall one of the IPs mentioned there (not sure which one right now).
Just as you and #Ema mentioned, this is an expected behavior having in mind that the traffic from Cloud Run to App Engine is intern.
When you use Cloud Nat to send all traffic there, it does happen. If you create a container and ping, let's say to www.github.com. You will find that the traffic goes through the IP you set. On the other hand, if you ping to www.google.com, given that the traffic is intern, and the site to reach out is in the same infrastructure, the request doesn't even goes through public internet.
Additionally, just to keep in mind Static outbound IP address is still in Beta and it is not recommended to use Beta features/products in production environments.
As you mentioned and as it is stated in Allowing requests from your services:
Creating a rule for IP 0.0.0.0 will apply to all Compute Engine instances with Private Google Access enabled, not only the ones you own. Similarly, allowing requests from 0.1.0.40 or 10.0.0.1 will allow any App Engine app to make URL Fetch requests to your app.
This questions might be of your interest:
What are the outbound IP ranges for GCP managed Cloud Run?
Possible to get static IP address for Google Cloud Functions?
We have 2 app engine app (flex and standard) running on separate projects and we want project A to request project B with https to xxx.appspot.com URL.
Our firewall on both projects Denies all IPs(*) and whitelisted App Engine internal addresss (10.1.0.41, 0.1.0.40, 10.0.0.1 and 0.1.0.30) as explained in the doc.
Yet we receive a "403 error forbidden access" (which disappears when disabling the firewall).
This post is similar to mine but the responses didn't help me.
Is there anything else I can do ?
Did anyone got this to work ?
Thank you in advance.
As you may already know, GCP Projects represent a trust boundary within an organization. Hence, inter-project communication between App Engine services would require Public IP communication or using Shared VPC, which allows connecting between networks from different projects. There should be no internal communication between App Engine Services over different projects. Hence, whitelisting App Engine internal IP addresses might not be useful in this situation.
About using Public App Engine IP addresses, as illustrated in this document. App Engine hosts services on a dynamic public IP address of a Google load balancer. Due to that, the IP address can be changed any time and any Static IP can not be provided. For outbound services, a large pool of IP addresses are used which you can obtain as outlined in this document
I have a Google pub/sub subscription that pushes messages for a topic to an AppEngine standard service endpoint.
I want to restrict access to the AppEngine standard service to user IPs and still allow for messages coming from Google Pub/sub.
In the AppEngine firewall, the only option is to allow certain IP ranges.
What is the IP range(s) of Google pub/sub?
I've noticed that all the IP requests from Pub/Sub push subscriptions are coming from 2002:axx:xxxx::. As per IETF RFC 3056, 2002::: is an 6to4 range. 2002:axx:xxxx::, then, is translated to 10.XXX.XXX.XXX, which is an range reserved for the internal networking in this case used by Google.
Note: that other services apart from Pub/Sub might [at some point] use range 2002:a00::/24, 10.XXX.XXX.XXX. For example App Engine Flexible. If requests from Flexible are not describable in this particular project then you will have block it and give it a higher priority.
In the end your Firewall entries:
10 Allow 2002:a00::/24 Pub/Sub
default Deny * The default action.
Also, there is an issue created about it in Google's issue-tracker.
Specifically I'm trying to access MonogoHQ, using the the Monogo Java Driver,
It's work locally but on the server I'm getting
There is some limitation,
So the MongoDb Java Driver doesn't work when I try to create connection using:
MongoClient mongoClient = new MongoClient( "mydb.mongohq.com", 10014 );
Google Appengine doesn't allow socket connections unless you've enabled billing for your app. From the Google docs:
Note: Sockets are only available for paid apps, and traffic from sockets is billed as outgoing bandwidth. Sockets are also limited by daily and per minute (burst) quotas.
From here.
I have an application that consists of a Windows Phone client sending HTTP requests to a Python server hosted in Google App Engine. In the GAE log, I see that I often receive multiple identical requests from the same client within a few milliseconds (see below). I never saw this behavior when testing the client in my development environment. Nonetheless I realize that this is probably error in my code, but my question is:
Can any part of the infrastructure (the mobile network, the internet, the google app engine itself) cause requests to be duplicated?
And if so, a follow on question is: are there best practices to minimize this?
No, HTTP requests are not be duplicated by the underlying infrastructure. At least they should not be.
What probably happened is that you see mobile app requests which are made in native cod and they do not use cookies and have same user agent string. The same IP is because mobile networks internally use NAT, hiding multiple (possibly thousands) clients behind a single IP address.
It's really not possible for the network to duplicate HTTP requests. It can duplicate IP datagrams with misconfigured routing, but the TCP layer filters duplicate IP datagrams so that the end to end connection only sees one TCP stream. App engine might reuse TCP ports without the standard time to wait for the previous TCP connection to die for performance purposes, but I still don't think duplicate packets would survive from the three-way TCP handshake used to initialize connections.