I use the version in app engine to deploy multiple versions of my services. At this moment these are dev, load and live. I develop on my dev version and when I'm done I deploy to live.
When I access my endpoints I use dev-dot-(myservice)-dot-(myapp).appspot.com. This works without problems.
Now the strange thing: After I deploy to the live version (that has been set as default in the app engine dashboard), I can access my endpoint with (myservice)-dot-(myapp).appspot.com. But I can not access it via live-dot-(myservice)-dot-(myapp).appspot.com.
Why doesn't the live version work, while if I don't specify anything it takes the default version which is live.
Related
On GCP, I run Cloud Build from one project and deploy code to App Engine in another project. It looks like the project where build runs from needs to have App Engine Admin API enabled. Is it a real request or I missed the real configurations?
App Engine Admin API is required as it is used for any App Engine-related management operations
Also, based on the link above:
The Admin API provides you with:
An integration point for your development and build tools.
Tighter control around deploying new versions, including the ability to automate traffic
migration between two versions or traffic splitting across one or more versions.
The ability to programmatically manage applications across multiple Google Cloud projects.
So yes, if you plan on deploying code to App Engine using Cloud Build, you need GAE Admin API enabled.
In the past, we can test GAE apps with dev_appserver.py [/path/to/my-project]. This was very useful because it provided helpful error messages in the terminal.
With the advent of gcloud SDK, it is suggested that we set up a virtualenv and test apps locally by running python main.py. Is this the recommended way for large apps too? Or is this just a quick-start way to demonstrate how to run App Engine locally?
What is the suggested local environment for building production-ready GAE apps?
The SDK was previously providing a local dev_appserver since the App Engine Standard 1st generation environment was integrating built-in APIs (Datastore, Memcache, etc...) that needed to be emulated locally to properly run/test your application.
The 2nd generation now deprecated these built-in APIs and rely on Cloud Client Libraries (more info on the runtime differences here). This means that you don't need anymore an emulated environment for your local testing. Your application, either large or small, should be able to run indifferently locally and when deployed.
In my previous App Engine projects I used the Cloud Datastore, and during development I could debug my app on the local server and it would use a local database, stored in a file I could wipe out if I wanted to start from scratch.
With Cloud Firestore, even when I'm running locally it's talking to my real cloud database. Is there still a local option? Note that I'm not talking about client-side persistence, I'm talking about a mock development DB.
Google recommends setting up multiple projects if you want dev/staging/production, and I'm guessing that's the answer, but I'd like to know before adjusting my workflow.
I think (now only a few months later) that this is supported. When I run my app, using dev_appserver.py, I see a message
INFO 2019-02-14 00:08:56,030 admin_server.py:150] Starting admin server at: http://localhost:8000
Going to that URL shows me all the instances I have been seeing. These seem to persist even when the dev_appserver is restarted. Reading this and other posts I was convinced that my development was using my actual cloud database, but going to https://console.firebase.google.com/project/myproject was showing completely different content.
Just to be sure (because google is google and everything is named the same) I'm using an appengine app and a gcloud project, storing things to Firestore using ndb.Models...
Oh, but careful. My app I was also using the cloudstorage (blobstore?) and even though the localhost:8000 showed these, THESE WERE THE REMOTE INSTANCES.
There is a local emulator for Firestore when using the Firebase CLI:
https://firebase.google.com/docs/rules/emulator-setup
I'm trying to run an App Engine app locally using the development server, as specified in Google's docs. I'm running into a ton of compilation errors due to the go library packaged in the SDK missing system libraries.
Looking at the SDK download page, it says:
Note: The Google App Engine Launcher does not work with Go apps.
So is there no way to launch Go apps running on App Engine locally?
The GAE Go SDK contains and uses a modified version of Go 1.6.2., and the context package was added to the standard lib in Go 1.7. The old API that comes bundled in the SDK uses the appengine.Context context.
See related question: AppEngine/Go: Using a new version of Go with the SDK
Having a tough time getting the Default Application Credentials to load in the dataflow SDK when running locally in a java app engine project developing on OS X. Runs fine when deployed.
According to this the dev app server doesn't support them, and you're meant to use the gcloud command line tool's command: gcloud preview app run - but according to the official Google Group for the SDK here that command was deprecated in Jan 2016.
So I seem to be stuck between a rock and a hard place... Does anyone know how to get the Application Default Credentials to work locally with an App Engine app?
I'm trying to use the Dataflow API and it just throws up when it starts making use of the cloud storage api which is the first thing the Pipeline does because it can't seem to load the correct credentials from the environment variables ( that are definitely set on the ENV and in the appengine-web.xml <env-variables> element ) or from the ~/.config/cloud/default_application_credentials.json file.
Cheers!
Can you try running the following command and see if it solves it?
gcloud auth application-default login
This is fully supported (but poorly documented) within the dev appserver. There is a very well answered question that gives you step by step instructions here: Unable to access BigQuery from local App Engine development server