I have two projects on Google App Engine, corresponding to two environments (one is for QA, the other for Production).
Currently the same code is running on both environments.
I have a problem though, I can't send emails in production while I can in QA. I can't find the differences, I read the documentation at least three times trying to figure it out.
In production I got the following exception:
Couldn't connect to host, port: localhost, 25; timeout -1
While it is specifically written in the documentation that if I don't specify the SMTP host, it automatically uses the Mail Service API.
The mail senders are the same in both environments, with same rights (project owner).
If you have any suggestions/leads
Thank you
Related
Our AppEngine app is connecting to a remote service which requires a VPN and also required me to add entries to the hosts file on my local machine in order to connect to their endpoints.
e.g.
10.200.30.150 foo.bar.com
This is working fine when running the app locally, but I can't figure out how to set this up on Google Cloud to work once deployed.
I can't use the IP addresses directly because it errors that the IP is not on the cert's list.
How do I map the host names to the IPs in Google Cloud so that AppEngine can use them?
From the error mentioned in the comment I suspect connecting directly through the IP fails because the certificate doesn't recognize the IP to DNS mapping as valid and therefore the secure connection setup breaks. Based on the requirements of connecting to the API by VPN and tweaking the hosts mapping there are few things you may try.
The simplest approach that may work would be using a Google Compute Engine VM instance, since there you would able to manipulate the etc/hosts file and replicate the local machine setup. This VM could be used either as the main app service or as a proxy from App Engine to the 3rd party API endpoint. To go that route I would suggest taking a look at these two posts which explain how to change the etc/hosts file on GCE (Changing the file once wouldn't work as the VM periodically overrides it, see the posts for cronjob like workaround).
Separately, as your app runs in App Engine flexible environment there is the chance to provide a docker container with the app packaged. It may be possible to set the workaround above in the docker file and have it working in App Engine too.
I'm using Google App Engine Standard to write a small application, let's call it AppX.
AppX is supposed to receive a POST message from another website, let's say B, and then do some processing and show on its mainpage.
The question is:
I don't know how to use dev_app server to debug. As if I use dev_app server, the server will run locally without https, then I don't know how to send a POST message from website B.
Google cloud shell is a very limited shell too, which does have limited ports enabled for outgoing connections only.
Although there might be a way to configure it, I think the easiest way to test calls from website B to a dev_app would be configuring a GCE virtual machine with a fixed IP. There you can configure the firewall freely, and also not worry any non-interactive session to finish abruptly.
I would like to debug my Google App Engine (GAE) app locally but without using localhost. Since my application is made up of microservices, the urls in a production environment would be along the lines of:
https://my-service.myapp.appspot.com/
But code in one service can call another service and that means that the urls are hardcoded. I could of course use a mechanism in code to determine whether the app is running locally or on GAE and use urls that are different although I don't see how a local url would handle the since the only way to run an app locally is to use localhost. Hence:
http://localhost:8080/some-service
Notice that "some-service" maps to a servlet, whereas "my-service" is a name assigned to a service when the app is uploaded. These are really two different things.
The only possible solution I was able to find was to use a reverse proxy which would map one url to a different one. Still, it isn't clear whether the GAE development SDK even supports this.
Personally I chose to detect the local development vs GAE environment and build my inter-services URLs accordingly. I feel it was a well-worthy effort, I've been (re)using it a lot. No reverse proxy or any other additional ops necessary, it just works.
Granted, I'm using Python, so I'm not 100% sure a complete similar Java solution exists. But maybe it can point you in the right direction.
To build the per-service URLs I used modules.get_hostname() (the implementation is presented in Resolve Discovery path on App Engine Module). I believe the Java equivalent would be getInstanceHostname() from com.google.appengine.api.modules.
This method, when executed on the local server, automatically provides the particular port the server listens to for each service.
BTW, all my services for an app are executed by a single development server process, which listens on multiple ports (this is, I guess, how it can provide the modules.get_hostname() info). See Running multiple services using dev_appserver.py on different ports. This is part I'm unsure about: if/how the java local dev server can simultaneously run multiple services. Apparently this used to be supported some time ago (when services were still called modules):
Serving multiple GAE modules from one development server?
GAE modules on development server
This can be accomplished with the following steps:
Create an entry in the hosts file
Run the App Engine Dev server from a Terminal using certain options
Use IntelliJ with Remote debugging to attach the App Engine Dev server.
To edit the hosts file on a Mac, edit the file /etc/hosts and supply the domain that corresponds to your service:. Example:
127.0.0.1 my-service.myapp.com
After you save this, you need to restart your computer for the changes to take place.
Run the App Engine Dev server manually:
dev_appserver.sh --address=0.0.0.0 --jvm_flag=-Xdebug
--jvm_flag=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000
[path_to_exploded_war_directory]
In IntelliJ, create a debug configuration. Use the Remote template to create this configuration. Set the host to the url you set in the hosts file and set the port to 8000.
You can set a breakpoint and run the app in IntelliJ. IntelliJ will attach to the running instance of App Engine Dev server.
Because you are using a port during debugging and no port is actually used when the app is uploaded to the GAE during production, you need to add code that identifies when the app is running locally and when it's running on GAE. This can be done as follows:
private String mServiceUrl = "my-service.my-app.appspot.com";
...
if (SystemProperty.environment.value() != SystemProperty.Environment.Value.Production) {
mServiceUrl += ":8000";
}
See https://cloud.google.com/appengine/docs/standard/java/tools/using-local-server
An improved solution is to avoid including the port altogether and not having to use code to determine whether your app is running locally or on the production server. One way to do this is to use Charles (an application for monitoring and interacting with requests) and use a feature called Remote Mapping which lets you map one url to another. When enabled, you could map something like:
https://my-service.my-app.appspot.com/
to
https://localhost:8080
You would then enable the option to include the original host, so that this gets delivered to the local dev server. As far as your code is concerned it only sees:
https://my-service.my-app.appspot.com/
although the ip address will be 127.0.0.1:8080 when remote mapping is enabled. To use https on local host however does require that you enable ssl certificates for Charles.
For a complete overview on how to setup and debug microservices for a GAE Java app in IntelliJ, see:
https://github.com/JohannBlake/gae-microservices
A normal webserver in a ManagedVM can listen on 0.0.0.0:8080 and properly serve requests dispatched through the GAE URL: http://xx.appspot.com:80
Instead of a normal webserver, try serving websocket connections and things no longer work. No connection gets handled anymore when connecting on: ws://xx.appspot.com:80
This (http://stackoverflow.com/questions/27827752/websocket-support-in-managed-vm) SO topic suggests exposing port 8080 to the Internet from the GCE network settings and using the IP of the GCE instance directly. That works indeed, but is not helpful as the IP changes on every new deployment.
If this is indeed the way to go, then it's not documented anywhere.
The only clue I've seen is that a Google employee also uses IP discovery to connect to the right GCE instance that hosts a websocket server:
https://github.com/proppy/cacophon/blob/master/frontend/api/controllers/DiscoveryController.js
I'm hoping for a proper fix that doesn't require me to use introspection for gather IPs of the VM instances hosting websocket servers.
With reference to Google issue tracker,
Since this thread was opened more than two years ago, I would like to check with you that if you're still hoping for the fix/FR about WebSocket server on Flex not properly exposed through GAE ULR?
for more update you can check Google issue tracker
I'm running an app on the Google App Engine standard environment. We need to send out a lot of emails and it looks like App Engine now lets us use JavaMail to send emails using SMTP - connecting to smtp.gmail.com or smtp.sendgrid.net.
I was wondering if this counts towards the Mail API limits/quotas in App Engine. I'm guessing it shouldn't, since the email is actually sent by the respective SMTP server and it's only outbound traffic from App Engine. Is this correct?
Note: I'm not a Java user, the answer is based on documentation only.
Indeed, using 3rd party partner mail services is the Google recommendation for sending lots of emails. From Quotas and limits:
Each Mail service request counts toward the Mail API Calls quota.
There are also quotas for the number of messages you can send, the
number of Admin messages you can send, and the amount of data and
attachments you can send. For more details, see Mail quotas.
[...]
If you need to send more mail then the quota allows, you can use a
third-party mail provider, such as SendGrid or Mailgun.
And JavaMail can, indeed, use these 3rd party SMTP servers. From Sending email messages:
To send email messages, use the JavaMail classes included with the App
Engine SDK.
When you create a JavaMail Session, if you do not provide any SMTP
server configuration, App Engine uses the Mail service for sending
messages. Alternatively, add SMTP configuration for supported
third-party mail providers such as Mailgun, Mailjet, or
SendGrid.
This last quote appears (depending on how you interpret it, I guess) to support your assumption that when SMTP servers are specified the Mail service would not be used, thus those calls wouldn't be counted against the Mail API Calls quota.
Also each of the 3rd-party mail integration documentation page referenced in these quotes doesn't (or at least doesn't directly) use JavaMail, instead they require specific libraries/modules. Which might have some relationship with bypassing the GAE Mail Api quota limits. For example, from Sending Email with SendGrid:
Sending an email
It's easy to get started with the Java library for SendGrid to
send emails from your App Engine apps.
With the prerequisites complete, make sure you are set up for
Java on your local machine. The last thing you'll need before
writing code is to copy Sendgrid.java to the src directory of
your app. You'll import this class so that you can create a SendGrid
instance and send mail with simple commands.
So, to gain certainty, my suggestion is to actually put your assumption to the test: send some emails using JavaMail while specifying your SMTP server info, then check your actual usage in the developer console Quotas page for matching increases. Notes:
give some ample room for propagation delays - the usage counts might not be immediately updated
if you don't see the Mail section in the Usage table check also, towards the bottom of the page, a Show resources not in use button/link (but, if it's in there, it means the usage is zero).
You could also directly follow the recommended specific instructions for your 3rd party provider of choice and practically avoid the question altogether :)