I am creating an offline-first app on Google App Engine, with PouchDB as my local DB, and CouchDB as my remote DB. I have enabled CouchDB on Google AppEngine, and tried to go to the following URL:
https://[my-app-id].appspot.com:5984/_utils/
When I do that, I get the following:
This site can’t be reached
The connection was reset.
Try:
Checking the connection
Checking the proxy and the firewall
Running Windows Network Diagnostics
ERR_CONNECTION_RESET
So I tried enabling https access in the firewall settings.
**Firewalls**
[ ] Allow HTTP traffic
[Y] Allow HTTPS traffic
Still getting the error above.
I searched the documentation but cannot find anything helpful about how to access Fauxton (or Futon) on Google AppEngine. (The instructions only tell you how to access Fauxton on your local machine.)
I have generated a private and public key and logged in to the server via command line.
I have also followed the instructions about configuring the firewall to allow remote access, and have given it to my PC only.
None of this has enabled me to access https://[my-app-id].appspot.com:5984/_utils/
How do I access Fauxton on the Google AppEngine platform?
Update: according to the development tools in my browser, my PouchDB application has successfully created a database to sync to, but it isn't on the server:
app.yaml file
application: [app-name]
version: 4
runtime: python27
api_version: 1
threadsafe: false
handlers:
- url: /
script: main.py
- url: /(favicon)\.ico$
static_files: \1.ico
upload: /(favicon)\.ico
application_readable: true
- url: /(package)\.json$
static_files: \1.json
upload: /(package)\.json
application_readable: true
# Serve images as static resources #
- url: /(.+\.(gif|png|jpg|json|ico))$
static_files: \1
upload: .+\.(gif|png|jpg|json|ico)$
application_readable: true
- url: /index.html
static_files: index.html
upload: index.html
- url: /licence.html
static_files: licence.html
upload: licence.html
- url: /privacy.html
static_files: privacy.html
upload: privacy.html
- url: /pouchnotes.manifest
static_files: pouchnotes.manifest
upload: pouchnotes.manifest
- url: /manifest.json
static_files: manifest.json
upload: manifest.json
# static directories #
- url: /img
static_dir: img
- url: /js
static_dir: js
- url: /css
static_dir: css
libraries:
- name: webapp2
version: "2.5.2"
EDIT: I posted this question in the Bitnami community forum (they provide CouchDB on Google App Engine)
FWIW, one of the references in your post points to Google Compute Engine (GCE), which is an IaaS, not a PaaS like Google App Engine (GAE), you might be looking at the wrong product.
The app.yaml file indicates you are using the standard environment, which doesn't offer ways to configure a listening port. And it also doesn't allow listening sockets. From Limitations and restrictions:
Although App Engine supports sockets, there are certain limitations
and behaviors you need to be aware of when using sockets :
You cannot create a listen socket; you can only create outbound sockets.
The GAE flexible environment might be an alternative as it drops many of the standard environment restrictions, but it's a significantly different solution (which I didn't use yet). The remainder of the answer assumes the flexible environment and it's based solely on the documentation.
Not 100% certain, but you might need to teach your app to listen to port 8080 instead. From Listen to port 8080:
The App Engine front end will route incoming requests to the
appropriate module on port 8080. You must be sure that your
application code is listening on 8080.
Unless you can use the forwarded ports network config (again, not 100% certain, I didn't use flex env). From Port forwarding:
Port forwarding allows for direct connections to the Docker container
on your instances. This traffic can travel over any protocol. Port
forwarding is intended to help with situations where you might need to
attach a debugger or profiler.
By default, incoming traffic from outside your network is not allowed
through the Google Cloud Platform firewalls. After you have
specified port forwarding in your app.yaml file, you must add a
firewall rule that allows traffic from the ports you want opened.
You can specify a firewall rule in the Networking Firewall Rules page
in the Google Cloud Platform Console or using gcloud
commands.
For example, if you want to forward TCP traffic from port 2222:
Modify the app.yaml to include:
entrypoint: gunicorn -b :$PORT -b :2222 main:app
In the network settings of your app.yaml, include:
network:
forwarded_ports:
- 2222/tcp
Specify a firewall rule in the Cloud Platform Console or using gcloud compute firewall-rules create to allow traffic from any
source (0.0.0.0/0) and from tcp:2222.
I'm getting some help with this from the Bitnami Community Forum.
Answers so far...
(1) set up the firewall rules - make sure you have a permanent IP address for this.
(2) set up SSH keys to access the server via command line
(3) sudo /opt/bitnami/couchdb/scripts/ctl.sh stop couchdb
(4) edit local.ini to point to 0.0.0.0 instead of 127.0.0.1 - but note that you will need to type cd /opt/bitnami/couchdb/etc/, press enter, and then sudo vi local.ini (rather than vi local.ini as the instructions suggest).
(5) Log in to the external IP address. (Log in as admin and prefix commands with sudo)
(NB: you don't need to run this in the GAE flexible environment)
Related
I have a flask web app deployed to google app engine. However, it is not forcing my link to https. However, if I refresh it, it will go to the ssl https version. But the user can still remove the s and jump back into the http version. Is there any way to completely remove the http protocol on my site and have it redirect to the ssl version. Here is the app.yaml file I'm using currently. I also tried adding in redirect_http_response_code: 301 with no luck to remove the http protocol
runtime: python
env: flex
entrypoint: gunicorn -b :$PORT main:app
runtime_config:
python_version: 3.7
# This sample incurs costs to run on the App Engine flexible environment.
# The settings below are to reduce costs during testing and are not appropriate
# for production use. For more information, see:
# https://cloud.google.com/appengine/docs/flexible/python/configuring-your-app-with-app-yaml
manual_scaling:
instances: 1
resources:
cpu: 1
memory_gb: 0.5
disk_size_gb: 10
handlers:
- url: /.*
secure: always
script: auto
I prefer not to install additional software packages for relatively simple things, so I do it myself. For GAE flex there are a few things to handle. I've added comments below to help explain.
#app.before_request
def redirect_http():
# http -> https
if (
# Flask tells us when request is http. This might not be needed for you but
# I need it because I use this code for GAE standard as well.
not request.is_secure and
# Load balancers forward https requests as http but set headers to let you
# know that original request was https
not request.headers.get('X-Forwarded-Proto') == 'https' and
# GAE cron urls must be http
not request.path.startswith("/cron")
):
return redirect("https" + request.url[4:], code=301)
# naked domain -> www
if request.url.startswith("https://example.com"):
return redirect('https://www.' + request.url[8:], code=301)
The Flask packages recommended by #tzovourn do other important things as well so you may want to consider those (I personally do all those things myself since it isn't hard to do them).
I noticed that you are using App Engine Flexible. As per documentation, setting secure: always in app.yaml doesn't work for App Engine Flexible.
Documentation recommends to secure your HTTP requests by using the Flask Talisman library.
Another way to configure your Flask application to redirect all incoming requests to HTTPS is to use the Flask-SSLify extension
We've deployed a Vue SPA to Google App Engine and it's served completely by the static handlers.
The issue that we are facing is that if a user is active on our site mid-deploy, then their old Webpack chunk manifest becomes invalid (since some chunks' hashes are overwritten). If they now try to route to a new page and that page tries to fetch a chunk that got overwritten, we get the following error:
ChunkLoadError: Loading chunk Conversations failed.
(error: https://example.com/js/Conversations.71762189.js)
Ideally, we'd like to keep N (2-3?) previous versions of the app's static files.
Is our only option to push all the assets to a Cloud Storage Bucket? If so, how would we go about pruning older versions?
Here is my app.yaml for reference:
runtime: nodejs10
instance_class: F4
automatic_scaling:
min_instances: 2
max_instances: 10
default_expiration: "30d"
error_handlers:
- file: default_error.html
handlers:
- url: /api/*
secure: always
redirect_http_response_code: 301
script: auto
- url: /js/*
secure: always
redirect_http_response_code: 301
static_dir: dist/js
- url: /css/*
secure: always
redirect_http_response_code: 301
static_dir: dist/css
- url: /img/*
secure: always
redirect_http_response_code: 301
static_dir: dist/img
- url: /(.*\.(json|js|txt))$
secure: always
redirect_http_response_code: 301
static_files: dist/\1
upload: dist/.*\.(json|js|txt)$
expiration: "10m"
- url: /.*
secure: always
redirect_http_response_code: 301
static_files: dist/index.html
upload: dist/index.html
expiration: "2m"
The issue typically happens when the deployment overwrites an existing service version which receives traffic (i.e. the service version is not changed). From Deploying an app:
Note: If you deploy a version that specifies the same version ID as a version that already exists on App Engine, the files that you
deploy will overwrite the existing version. This can be problematic if
the version is serving traffic because traffic to your application
might be disrupted. You can avoid disrupting traffic if you deploy
your new version with a different version ID and then move traffic to
that version.
As long as a service version is deployed and not deleted or overwritten its respective static assets remain accessible.
To prevent the issue always deploy using a fresh service version, then (gradually) migrate traffic to the newly deployed version. Keeping the latest N service versions around will give you those N sets of static assets you desire.
In general, this deployment practice is good/recommended for a few other reasons:
avoids potential outages, see Continuous integration/deployment/delivery on Google App Engine, too risky?
avoids potential traffic loss while GAE spins up enough new version instances to handle the traffic load, see 2nd half of GAE shutdown or restart all the active instances of a service/app
Potentially of interest: Google Frontend Retention between deployments
Deploy using the --no-promote flag, and utilize the Traffic Migration feature in the Standard Environment to gradually migrate traffic over to the new version so that all users don't experience an immediate switchover the moment the new version goes live. App Engine will host both the old and new versions (or, "blue" and "green") for a period of time until all traffic points to the new version, and then the old version will be shut down.
See also:
Testing on App Engine
Migrating and Splitting Traffic with the Admin API
Blue-Green Deployment Pattern
I am still working to get my old style appengines to work under at least go111 (go112 would not work due to dependencies on memcache). I am now stumbling over app.yaml configuration issues with my static files, I used a completely static directory layout before and just specified a few dynamic handlers in the root like this:
runtime: go111
handlers:
- url: /_ah/.*
script: auto
login: admin
secure: always
- url: /dynamic
script: auto
secure: always
- url: /admin/.*
script: auto
login: admin
secure: always
- url: (.*)/
static_files: html\1/index.html
upload: html/index.html
secure: always
- url: /(.*\.map)
mime_type: application/json
static_files: html/\1
upload: html/(.*\.map)
secure: always
- url: /
static_dir: html
secure: always
dev_appserver.py will never call my dynamic entry point. In production this does work, but I am still working on the conversion and would like to test locally. Any hints how to convince dev_appserver.py to let me do this? By the way my gcloud tools are updated as of today.
Your question is why your application works well when you deploy it to production but doesn't work when you use dev_appserver.py to run it locally, and how could you run it with dev_appserver.py. The answer to that is:
You won't be able to run it locally properly using dev_appserver.py, since it does not support runtime Go 1.11. Look at the Local Development Server Options documentation, there's only a link for "Go 1.9".
(as you can see, the links for "Go 1.11" and "Go 1.12" are disabled, which translates to: not supported.)
Documentation for Go 1.11 on App Engine Standard states that in order to test your application locally you would have to use "go run" command (notice how it doesn't mention dev_appserver.py tool). The command would be something like this:
go run [build flags] [-exec xprog] package [arguments...]
For more information about the command go here.
I'm sure you might have already read this but, to know more about the migrations process from Go1.9 to Go1.11 read this documentation.
You have stated that "go run" command wouldn't work for your case. So, a workaround for that would be to test your application directly into App Engine but without migrating the traffic.
When deploying your test version use:
gcloud app deploy --no-promote
To access to it go to:
http://VERSION_ID.default.YOUR_PROJECT_ID.appspot.com
If everything turned out great, you can migrate the traffic on the Cloud Console UI selecting the version you just deployed and clicking "Migrate traffic".
I want to access my Cloud Endpoints API hosted on my local dev machine from an Android app running on a mobile device I use for testing.
My device can access my dev machine by IP address. I passed --host=192.1.168.101 to the App Engine launcher so that my local App Engine instance binds to the IP address. Although I can access the App Engine instance from 192.168.1.101, I get a 404 when my app makes an API call.
I noticed that going to http://192.168.1.101:9080/_ah/api/explorer/ does not show my API; it redirects to https://developers.google.com/apis-explorer/#p/. If I use http://localhost:9080/_ah/api/explorer/ I'm able to see my API as intended. It seems that using an IP address as the host is not working with Cloud Endpoints.
I'd rather not root my device to change its /etc/hosts file. Changing that might not be a solution anyway, since I'm unable to bind my App Engine instance to a hostname other than localhost.
This is my app.yaml config:
application: my-server
version: 1
runtime: python27
threadsafe: true
api_version: 1
handlers:
# Endpoints handler
- url: /_ah/spi/.*
script: services.application
- url: /favicon\.ico
static_files: favicon.ico
upload: favicon\.ico
- url: .*
script: main.app
You bound to your specific IP, but as a reminder, you can also bind to 0.0.0.0 (all available IPs). This is handy if you're using the maven appengine plugin and don't want to update the pom.xml file whenever your IP changes.
Next, make sure you're on the same network and can connect between the machines. I typically use ConnectBot to test by opening a telnet session to the IP address and port you defined for running locally. This will ensure your firewall isn't causing an issue.
Finally, update your code by adjusting the root url for your API. That would look something like this if your IP address were 192.168.1.100 and port were 8080:
Helloworld.Builder helloWorld = new Helloworld.Builder(AppConstants.HTTP_TRANSPORT,
AppConstants.JSON_FACTORY, credential);
helloWorld.setRootUrl("http://192.168.1.100:8080/_ah/api/");
In your generated source code (usually the file named after your API name, such as Tictactoe.java), DEFAULT_ROOT_URL should be set to http://192.168.1.101:9080/_ah/api/. This URL isn't expected to provide anything useful if you load it in a browser. Rather, it's the base of the path to your API requests, e.g. http://192.168.1.101:9080/_ah/api/tictactoe/v1/board.
If you want to confirm your device is properly connecting to your local server (via your local network), load
http://192.168.1.101:9080/_ah/api/explorer/ from the device browser.
The problem had nothing to do with the IP address. I needed to include a path in my API method decorator:
#endpoints.method(HelloRequest, HelloResponse, name='helloworld', path='test', http_method='GET')
def helloworld(self, request):
In the answer to the question Error sending e-mail via SMTP server on App Engine development server there is a nice solution by Blixt:
"dev_appserver.py does not support TLS
which is required by Gmail. You can
enable it by adding a few lines in api/mail_stub.py:"
# After smtp.connect(self._smtp_host, self._smtp_port)
smtp.ehlo()
smtp.starttls()
smtp.ehlo()
But windows Vista would not let me change api/mail_stub.py
Is there another way to send mail from development server. Other options (Sendmail and ISP are not good for me). Thanks!
EDIT
I changed the api/mail_stub.py according to instructions here and I use the following command-line options:
dev_appserver.py
--smtp_host=smtp.gmail.com
--smtp_port=25
--smtp_user=xxxx#gmail.com
--smtp_password=gmail_pw
C:\Users\A\Desktop\repeater # path to root directory
But I get this error from Log Console:
***********************************************************
2010-11-18 10:24:37 Running command: "['C:\\Python26\\pythonw.exe',
'C:\\Program Files(x86)\\Google\\google_appengine\\dev_appserver.py',
'--admin_console_server=',
'--port=8080',
u'dev_appserver.py',
u'--smtp_host=smtp.gmail.com',
u'--smtp_port=25',
u'--smtp_user=xxxx#gmail.com',
u'--smtp_password=gmail_pw
C:\\Users\\A\\Desktop\\repeater',
'C:\\Users\\A\\Desktop\\repeater']"
Runs a development application server for an application.
dev_appserver.py [options] <application root>
Application root must be the path to the application to run in this server.
Must contain a valid app.yaml or app.yml file.
****************************************************
This is the app.yaml:
application: re-peater
version: 1
runtime: python
api_version: 1
handlers:
- url: /favicon.ico
static_files: static/images/favicon.ico
upload: static/images/favicon.ico
- url: /stylesheets
static_dir: stylesheets
- url: /.*
script: repeater.py
All this works without these command line options. Any suggestions why this is not working?
If you really, really need to send real email from the dev_appserver, you should set up your own mail relay on your machine, and point the SDK at that. I'm curious why it's so important to send real email, though - this is the development server, and you shouldn't be using it for anything other than development.
Change the file permissions so that you can change the api/mail_stub.py file.
This is no longer necessary
in /appengine/api/mail_stub.py
if self._allow_tls and smtp.has_extn ('STARTTLS'):
smtp.starttls ()
I am using appengine sdk version 1.9.15.