For some reason having my defined app engine service name and built URL: myapp.appspot.com redirects to [appversion]-myapp.appspot-preview.com.
Is it ok? Why is this happening? Is there something to do with it?
ADD:
app.yaml
runtime: custom
env: flex
resources:
cpu: .5
memory_gb: 1.0
disk_size_gb: 10
manual_scaling:
instances: 2
Dockerfile
FROM gcr.io/google_appengine/jetty9
ADD target.war $JETTY_BASE/webapps/root.war
You are on the new App Engine Flexible Environment beta. The previous version was configured using vm: true. Using env: flex selects the new beta version that is currently redirected to this temporary domain. From Domain update:
Traffic is now served from the appspot-preview.com domain instead of
the appspot.com domain. All traffic from the App Engine flexible
environment will be automatically redirected to the new domain. All
App Engine Standard traffic will continue to be through appspot.com.
When the App Engine flexible environment is generally available (GA),
users will be able to use the appspot.com or appspot-preview.com
domains for routing traffic.
Related
I have the following error when I try to build my app on GCP App Engine, my app environment is ideed a flexible one. But I don't know if my App Engine environment is flex or not.
If that's the case how can I set my environment to flex in GCP App Engine?
ERROR: (gcloud.app.deploy) Error Response: [7] The App Engine appspot and App Engine
flexible environment service accounts must have permissions on the image
[eu.gcr.io/["key file"]/appengine/default.20220514t124713:latest]. Please check
that the App Engine default service account has the [Storage Object Viewer] role and the
App Engine Flexible service account has the App Engine Flexible Environment Service
Agent role
I'm building on Travis CI using the right .travis format and I receive this error. I also tried to build this directly on Cloud Shell terminal in GCP, but I have the same error.
This is my app.yaml file:
env: flex
runtime: custom
service: default
manual_scaling:
instances: 1
resources:
cpu: 1
This is what I have in IAM permissions:
#DazWilkin solved it.
To solved it I needed to add to IAM the ({project-id}#appspot.gserviceaccount.com), to build the project correctly.
"You can determine its email address ({project-id}#appspot.gserviceaccount.com) and you should be able to simply re-add it to the IAM policy... Give it roles/editor. It's a Google-managed (owned) Service Account and so you can't delete the Service Account itself, just the role binding." - #DazWilkin
this troubleshooting guide
https://cloud.google.com/appengine/docs/standard/troubleshooting#service-account-permissions
should solve your issue , I had the same issue , and fixed by grant the Storage Object Viewer role to the default App Engine service account
I'm trying to configure my Google App Engine instance with Cloudflare for Saas, and more precisely Cloudflare's SSL for SaaS offering. The objective being that I can provide to my customer a "custom domain" (also known as "vanity domain"), such that they don't go to dashboard.mywebsite.com, but instead app.customerwebsite.com.
Configuration part
To make sure that my App Engine instance is correctly serving content on dashboard.mywebsite.com, I've made the following:
On Google Cloud side:
I've configured the custom domain dashboard.mywebsite.com.
I've let Google manage the SSL configuration (no custom key/certificate)
Here is my app.yaml configuration file:
runtime: nodejs14
env_variables:
NODE_ENV: 'production'
basic_scaling:
max_instances: 10
idle_timeout: 5m
On Cloudflare side:
I've updated the DNS records so that dashboard.mywebsite.com is perfectly working
I've configured the SSL on the Full mode (while I've tried with Flexible as well - both work)
I waited for a few hours and I confirm that dashboard.mywebsite.com resolves correctly and serves my content (from Google App Engine).
Next, custom domains
According to Cloudflare documentation, I had to register the fallback origin (i.e. dashboard.website.com) and then configure a custom hostname (e.g. app.customerwebsite.com). Which I did.
Now, according to Cloudflare documentation again, my customer has to create a CNAME record. Which I did with a domain of mine:
app.customerwebsite.com CNAME dashboard.mycompany.com
The issue
I waited a few hours again. Then, when I open app.customerwebsite.com in my browser, it shows a Google 404 error page instead of my dashboard. Which makes me think that Cloudflare successfully "redirects" the traffic to Google, but App Engine refuses to serve it. Probably because it doesn't know app.customerwebsite.com?
Any thoughts that would help?
As you noticed, the issue is not related to Cloudflare, but App Engine. The problem with your configuration is that, when App Engine receives a request, based on the Host header, it forwards the request to the right instance.
App Engine lets you map any custom domains that has been previously validated by Google. But in your situation, that would mean you have to register each custom domain of your customers on your App Engine instance. That's too cumbersome (if even possible).
What you need to do instead is the following:
enable a static IP address with Google Cloud
change your DNS record from dashboard CNAME ghs.googlehosted.com to dashboard A YOUR_IP_ADDRESS
configure a Google Cloud Load Balancer to map requests received on that IP address to your App Engine instance.
Google's documentation has a great guide on how to setup a load balancer with Cloud Run. By changing a few settings it works great with App Engine. As an extra help, below is the configuration details of our load balancer that allows us to provide vanity domains / custom domains to our customers through Google Cloud:
Again, the load balancer is here responsible to map all requests received by your IP address (no matter the Host header) straight to your App Engine instance.
As a best practice, it might be useful to push a dispatch.yaml file to your instance:
dispatch:
- url: '*/*'
service: default
Which tells App Engine to send all requests to the default service. It works a bit like a wildcard virtual hosts on an Apache server.
I have an API that I host through Google Cloud. The main entry point for the API is an App Engine instance (standard), which then needs to be able to call various cloud functions to execute its tasks.
To make the cloud functions secure, I want to set the ingress controls to "Allow internal only".
I've deployed the cloud functions and the App Engine in the same region (us-central1), but every time the App Engine instance tries to call a cloud function, it gets a 403 error. I've tried setting up a VPC connector for the App Engine, but that isn't helping.
Here's the app.yaml file:
service: my-test-app
runtime: nodejs10
env_variables:
STAGE: "dev"
instance_class: F1
vpc_access_connector:
name: "projects/my-test-project/locations/us-central1/connectors/test-vpc-connector"
The key cloud function configuration is the Ingress Setting. I have it set to Allow internal traffic only. If I set it to Allow all traffic, everything works (just highly insecure!)
Any suggestions on what I might be missing?
I found the solution! If I set the App Engine to a flex environment, everything works. It looks like the standard environment was the issue.
I have a static web client SPA serviced by a REST API. I'm trying to figure out the best way to host these apps on Google's Cloud Platform using App Engine to host the API, and Cloud Storage to host the static web client.
If I were doing this from scratch, a simple reverse proxy could manage routing traffic between the API and the client assets. To do the equivalent with GCP, I've looked at the following:
Google's Compute Engine supports content-based load balancing: though no equivalent for App Engine
the API on App Engine could proxy requests to Cloud Storage, though at the expense of unnecessary load on the API service
simply host the API and client on separate domains (App Engine and Cloud Storage respectively), and properly configure cross origin issues
Use Google Cloud Endpoints as a reverse proxy to route traffic appropriately between App Engine and Cloud Storage: haven't fully explored this option, though as of writing, Cloud Endpoints does not support routing to multiple hosts (which is defined only in v3 of the OpenAPI spec).
All of the above have limitations. What i'm trying to do seems fairly conventional, but I'm not sure what the path of least resistance is on GCP.
Google Cloud storage allow you to host a static website :
https://cloud.google.com/storage/docs/hosting-static-website
You don't need to use Endpoint or AppEngine as a reverse proxy
If you need to setup a load balancer based on route or if you need to setup ssl certificates you could use storage bucket as a service backend :
https://cloud.google.com/compute/docs/load-balancing/http/backend-bucket
Let's talk about serving SPA static files from Google App Engine.
The SPAs need to serve many routes to a single index.html, normally called rewrite rules.
App Engine can do that with a proper configured app.yaml handlers section.
For the real files part, you serve the real path:
- url: /assets/
static_dir: path/to/real/files
For these fake routes, serve the entrypoint index.html:
- url: /
static_file: path/to/index.html
upload: path/to/index.html
- url: /.*
static_file: path/to/index.html
upload: path/to/index.html
By this configuration, Google Frontend will serve the static files without hitting your backend.
Here's one Angular application and I deployed to App Engine, as an example:
Other stuff about securing APIs and CORS policies, you can consider using dispatch.yaml to avoid cross domain problem. Or serve from different domain with cloud endpoints (with IAP jwk configured).
As you have rightly observed, there are a number of complications that might come into play with your setup. The Google Cloud Storage is simply a Storage, which might not necessarily manage requests to GAE as well as you desire. Perhaps, using Endpoints would be a more viable solution in this case (considering your listed options), where you can use simple Javascripts to call Endpoints in your GAE applications from your Application Files in Google Cloud Storage. However, that being said, I think the better option is to move your static files into App Engine as described here. This will ease the complication of managing resources between two different technologies
How can I deploy multiple applications from same or different language/runtime originating from a single project in google cloud app engine?
Deploying Multiple Services to Google Cloud App engine.
Create the following files in the app root directory
Create app.yaml file with content:
runtime: nodejs14
service: default
Create myserviceone.yaml file with content:
runtime: nodejs14
service: myserviceone
Create myservicetwo.yaml file with content:
runtime: nodejs14
service: myservicetwo
Deploy using command
gcloud app deploy --project your_project_id app.yaml myserviceone.yaml myservicetwo.yaml
This will deploy the default service as well as my service one and my service two. Check out your cloud console.
You can access them using:
https://myserviceone-dot-yourProjectID.appspot.com/ or
http://myserviceone.yourProjectID.appspot.com/
https://myservicetwo-dot-yourProjectID.appspot.com/ or
http://myservicetwo.yourProjectID.appspot.com/
Today, App Engine has a one-to-one correspondence with a Google Cloud Console project. You cannot deploy multiple "apps" in the same project. However, you might still be able to do what you want depending on your application(s).
App Engine has the concept of "services," which are independent aspects of your application. Your App Engine app can have many services and each service can have its own language/runtime and even be on different App Engine environments.
You could have say a Python service on App Engine standard environment that is used to serve your simple Flask site, could have service that serves an API written in Java 8 on the Standard Environment, and could have yet another service in say Node.js running in the App Engine flexible environment.
Your "default" service is defined in your app.yaml file. Your other services can be defined in different folders and can have either an app.yaml with their service definitions or you could name them something else like backend.yaml. See this simple Python project for the layout of the configuration files.
For more conceptual information about services on App Engine, see Microservices Architecture on Google App Engine.