How/where does Google App Engine cache YAML (changing `script`)? - google-app-engine

Originally I had this in my app.yaml:
runtime: python39
- url: .*
script: main.app
I changed the script filename to gae.py and so updated app.yaml to thus:
runtime: python39
- url: .*
script: gae.app
The new version no longer starts up:
ModuleNotFoundError: No module named 'main'
I have tried changing the url but it's still trying to use a now-non-existent main.py to load the WSGI application. When I view the source of the version I see the correct app.yaml and file structure; I don't see main mentioned anywhere.
Any ideas?

The problem is not caching but rather that script is no longer used (and is ignored) in the Python 3 world of Google App Engine standard:
script: Optional. Specifies that requests to the specific handler should target your app. The only accepted value for the script element is auto because all traffic is served using the entrypoint command. In order to use static handlers, at least one of your handlers must contain the line script: auto or define an entrypoint element to deploy successfully.
(https://cloud.google.com/appengine/docs/standard/python3/config/appref#handlers_element)
The fix is to override entrypoint which defaults to:
/bin/sh -c exec gunicorn main:app --workers 2 -c /config/gunicorn.py
(https://cloud.google.com/appengine/docs/standard/python3/runtime#application_startup)

Related

How to pass -ldflags to GAE build?

I have an HTTP service written in Go. Inside main.go I have a global version string.
package main
var version string
Locally, I build using -ldflags "-X main.version=$VERSION where $VERSION is determined by the shell environment, like so:
VERSION=v0.16.0 go build ./cmd/app -ldflags "-X main.version=$VERSION
I've recently decided to trial Google App Engine and started with a basic YAML file:
runtime: go111
handlers:
- url: /.*
script: auto
What can I set in the YAML file in order to instruct GAE to build with the equivalent ldflags to bake in my version string?
I should also mention I use go modules with GO111MODULE=on locally when building.
You can't do it with you app.yaml file.
However, you can use Cloud build to build and deploy your app to App Engine.
In your cloudbuild.yaml you can add a line to the build step
args: ['build', '-a', '-installsuffix', 'cgo', '-ldflags', '''-w''', '-o', 'main', './main.go']

Why cant go-app-builder find local imports?

I am currently writing an application in Go and trying to deploy multiple services. I am running the following command : gcloud app deploy dispatch.yaml app/app.yaml mod1/mod1.yaml.
The app.yaml file corresponds to the default service and is successfully deployed however the service mod1 returns this error:
ERROR: (gcloud.app.deploy) Error Response: [9] Deployment contains files that cannot be compiled: Compile failed: 2016/07/22 18:17:14 go-app-builder: build timing: 1×compile (53ms total), 0×link (0 total) 2016/07/22 18:17:14 go-app-builder: failed running compile: exit status 1
mod1.go:4: can't find import: "myapp/mod1/web_console"
My-Macbook: myapp$ gcloud app deploy dispatch.yaml app/app.yaml mod1/mod1.yaml
My file structure is as follows:
/My_Project
/src
/myapp
/app
app.go
app.yaml
/mod1
mod1.go
mod1.yaml
/web_console
web_console.go
mod1.go :
package mod1
import (
"myapp/mod1/web_console"
)
func init() {
// Initializing Web Console establishes connection
// to the database and also creates routes
var wc *web_console.WebConsole
wc = web_console.NewWebConsole(true)
wc.Configure()
}
mod1.yaml :
module: mod1
runtime: go
api_version: go1
handlers:
- url: /.*
script: _go_app
app.yaml :
module: default
runtime: go
api_version: go1
handlers:
- url: /.*
script: _go_app
Thanks for taking the time to help!
Each GAE service/module is standalone and can not access anything outside the service/module dir which:
is the directory where the .yaml file exists
is what's uploaded during deployment
is considered the "root" directory for that service/module, everything is relative to it
In your particular case you need to make sure no service/module makes references to the parent myapp dir (which is nothing but an organisational placeholder for the app stuff, relevant on your side but with no actual presence on GAE). I believe your mod1.go import should looks like this:
package mod1
import (
"web_console"
)
But take it with a grain of salt, I'm not actually familiar with go.
It seems like I was using the wrong tool to deploy. I ran the command with goapp deploy app/app.yaml mod1/mod1.yaml and was able to successfully deploy the services without issue.

How to fix "`The --custom_entrypoint flag must be set for custom runtimes`"?

I get this error on appengine when I run gcloud preview app run app.yaml:
The --custom_entrypoint flag must be set for custom runtimes
My app.yamllooks like:
version: 0-1-1
runtime: custom
vm: true
api_version: 1
manual_scaling:
instances: 1
handlers:
- url: .*
script: dynamic
My dockerfile is just:
FROM google/nodejs-runtime
I reinstalled gcloud to get the latest version, did something change in the yaml config for managed VMs? This makes it impossible for me to test my app.
There appears to be a bug or setup issue with Google Cloud SDK version 0.9.67 causing this error. As a temporary workaround, you can revert to previous SDK version, which is working, with the following commands:
gcloud config set component_manager/fixed_sdk_version 0.9.66
gcloud components update
To return to the current version of the SDK, run:
gcloud config unset component_manager/fixed_sdk_version
gcloud components update
This issue appeared a few versions ago and was addressed here:
Running node.js on google cloud, but error running with docker
You can run gcloud help preview app run to show a man page describing the run command and its parameters. --custom-entrypoint is described as:
--custom-entrypoint CUSTOM_ENTRYPOINT
Specify an entrypoint for custom runtime modules. This is required when
such modules are present. Include "{port}" in the string (without
quotes) to pass the port number in as an argument. For instance:
--custom_entrypoint="gunicorn -b localhost:{port} mymodule:application"
Note that the error message says --custom_entrypoint, with an underscore, but the parameter is --customer_entrypoint, with a dash. The correct name is --custom-entrypoint see: https://code.google.com/p/google-cloud-sdk/issues/detail?id=191
For a nodejs you should be able to use something like:
gcloud preview app run app.yaml --project=your-project-id --custom-entrypoint "node index.js {port}"
Depending on how you start your application. The port seems to also be available as the environment variable PORT so you don't need to use {port} if your app does not handle command line arguments.
I haven't been able to use npm start or other npm run <script> from the --custom-entrypoint however.
Comment lines 391 to 397 in
google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/module.py
# if (self._module_configuration.effective_runtime == 'custom' and
# os.environ.get('GAE_LOCAL_VM_RUNTIME') != '0'):
# if not self._custom_config.custom_entrypoint:
# raise ValueError('The --custom_entrypoint flag must be set for '
# 'custom runtimes')
# else:
# runtime_config.custom_config.CopyFrom(self._custom_config)

Project Directory Does Not Contain app.yaml

I'm following the instructions here https://console.developers.google.com/start/appengine
I've downloaded and unzipped the project file from that page - it's the python and flask one. When I get to the instruction dev_appserver.py appending-try-python-flask it gives the error.
google.appengine.tools.devappserver2.errors.AppConfigNotFoundError: "." is a directory but does not contain app.yaml or app.yml
It most certainly does contain an app.yaml file. It looks like this.
application: hello-flask-app-engine
version: 1
runtime: python27
api_version: 1
threadsafe: yes
handlers:
- url: .*
script: main.app
libraries:
- name: jinja2
version: "2.6"
- name: markupsafe
version: "0.15"
Unlike this post Uploading a static project to google app engines mine doesn't have any skip files lines to delete.
There is a README.md that mostly follows the Google Dev web page, except that instead of downloading the project from that page it instructs to git clone https://github.com/GoogleCloudPlatform/appengine-python-flask-skeleton.git and that doesn't exactly match the zip file I downloaded.
The requirement.txt file says Run 'pip install -r requirements.txt -t lib/' but Windows 7 says pip is not a recognized command.
Is my app.yaml not correct? Why would it say it doesn't exist?
Simply closing the command prompt window and reopening it made it work. I don't know how or why.
You may be mis-typing appengine-try-python-flask (the real name) as appending-try-python-flask (which is what you show in your question).
If that's not the case, can you please show the effects of dir appengine-try-python-flask and dir appending-try-python-flask from the directory (AKA folder) you're now trying to run dev_appserver.py from?
probably you use py-charm, you need to add to configuration in line 'Working directory' the path of project like: C:\Users\user\Desktop\projects\water
It's repose to work

Migrating GAE app from python 2.5 to 2.7

I am trying to migrate my app and everything worked fine until I changed in app.yaml
from threadsafe: false to threadsafe: true.
The error I was receiving was:
threadsafe cannot be enabled with CGI handler: a/b/xyz.app
After some googling I found:
Only scripts in the top-level directory work as handlers, so if you have any in subdirectories, they'll need to be moved, and the script reference changed accordingly:
- url: /whatever
# This doesn't work ...
# script: lib/some_library/handler.app
# ... this does work
script: handler.app
Is there any workaround for this(if above research is valid), as I don't want to change my project hirarchy?
You can have your handlers anywhere as long as it's a valid python import path.
My app.yaml is full of entries like
- url: /_ah/queue/deferred
script: google.appengine.ext.deferred.application
login: admin
The folders need __init__.py in them to make them work as modules, but you can usually replace any / with .
Alternatively do as Daniel suggest, and note that you'll probably have to mangle the sys.path first to include lib dir and then import handler.
Put a main file in the top-level directory and import all your handlers there, then reference them via that file

Resources