Hi i have setup an app engine account. everything works ok with standard php. i have a local install of fuelphp, this works with no issues when running the development server of google app engine. however once i move it to the production application, i get an error stating the cache directory is unwritable of non existent. i read through some articles and it mentioned the application sandbox on GAE is not writable, so i went and manually change the configurations to point to an external path for the cache, the issues is this persist. i even tried to remove the usage of cache, ( false in config ) and hardcoded remove by commenting out. this just crashed everyting.
app.yaml
env_variables:
FUEL_ENV: 'production'
handlers:
url: /(.*.(htm$|html$|css$|js$))
static_files: public/\1
upload: public/(.*.(htm$|html$|css$|js$))
application_readable: true
url: /(.*.(ico$|jpg$|png$|gif$))
static_files: public/\1
upload: public/(.*.(ico$|jpg$|png$|gif$))
application_readable: true
url: /assets
static_dir: public/assets
url: /favicon.ico
static_files: public/favicon.ico
upload: public/favicon.ico
url: /.*
script: public/index.php
Log file patch: https://github.com/isatan/FuelPHP4Gae_patch
Deploy SQL instance, load database schema and setup your production config.php to connect to in via unix socket.
Related
I created web app that consist with two separate parts: server and client. And I want to deploy it to google cloud with app engine.
I already did it, but the main problem is unworking env_variables that I need for correct work of application that I defined in .yaml files.
I don't understand why the env variables doesn't work, If I do it in accordance to docs.
I wrote .yaml file to each part. Here the file structure:
./
--client/
----source_files...
----client.yaml
--server/
----source_files...
----api.yaml
--dispatch.yaml
Here the content of each file.
client.yaml:
runtime: nodejs16
service: default
handlers:
- url: /(.*\..+)$
static_files: build/\1
upload: build/(.*\..+)$
- url: /.*
static_files: build/index.html
upload: build/index.html
env_variables:
API_LINK: "https://gcloudezample-11111.lm.r.appsport.com"
api.yaml:
runtime: nodejs16
service: api
env: standard
env_variables:
MONGO_DB_PWD: "db_password"
dispatch.yaml:
dispatch:
- url: '*/api'
service: api
Then I deployed this parts in .yaml files order above.
The result is working frontend but failed api requests, because the wrong request URL: http://localhost:3001/v1/my-route
Screenshot
It's a common misunderstanding of how a website works. Take 2 sec and think about it: What are doing your frontend part?
Let me help
handlers:
- url: /(.*\..+)$
static_files: build/\1
upload: build/(.*\..+)$
- url: /.*
static_files: build/index.html
upload: build/index.html
It serves only static files. Therefore, only static file means no processing, no instances, no variable definition in the runtime context because only static files are served.
The runtime is on the client browser that run the JS code.
Note: the counterpart great advantage, that the static page serving is free (in term of resource usage because there is no instance up and running to serve your files; the egress is billed)
So now, how to solve this?
Simply build your static files with the API_LINK value INSIDE the static code.
I am deploying a web application to Google App Engine Standard edition using Java 8.
It is a documentation web site plus servlets that includes a huge amount of static web content (built with Jekyll).
I recently started getting this error trying to deploy the app:
ERROR: (gcloud.app.deploy) INVALID_ARGUMENT: This deployment has too many files.
New versions are limited to 10000 files for this app.
- '#type': type.googleapis.com/google.rpc.BadRequest
fieldViolations:
- description: This deployment has too many files.
New versions are limited to 10000 files for this app.
field: version.deployment.files[...]
My src/main/webapp folder has 5016 files.
But after running:
mvn clean install appengine:stage
my target/appengine-staging folder has 10113 files.
I see that the files are in 2 locations, both
target/appengine-staging
and
target/appengine-staging/__static__
Why do they appear twice?
Is this normal?
Or am I doing something wrong?
How can I avoid this duplication?
Or do I have to limit my files to under 5000?
Thanks for any advice.
Note: The generated app.yaml looks like this:
runtime: java8
instance_class: F1
inbound_services:
- warmup
derived_file_type:
- java_precompiled
threadsafe: True
auto_id_policy: default
beta_settings:
'source_reference': 'https://...'
api_version: 'user_defined'
handlers:
- url: (/.*/)
static_files: __static__\1index.html
upload: __NOT_USED__
require_matching_file: True
login: optional
secure: always
- url: (/)
static_files: __static__\1index.html
upload: __NOT_USED__
require_matching_file: True
login: optional
secure: always
- url: (/.*)
static_files: __static__\1
upload: __NOT_USED__
require_matching_file: True
login: optional
secure: always
- url: /.*
script: unused
login: optional
secure: always
skip_files: app.yaml
I have a flask + react application that is deployed on Google App Engine. Recently, I discovered that each time I deployed a new version to the GAE, my site would go down for a few hours, and several web pages cannot load correctly. I checked the console, the web application is trying to get the static files from the last version, which resulted in a 404 Error. Can anyone help me to find what the problem is?
Here is my app.yaml file:
runtime: python37
env: standard
default_expiration: "5m"
entrypoint: gunicorn -b :$PORT main:app --timeout 150
instance_class: F4
automatic_scaling:
max_instances: 5
min_instances: 1
min_pending_latency: "5s"
target_cpu_utilization: 0.75
inbound_services:
- warmup
handlers:
- url: /static/js/(.*)
static_files: build/static/js/\1
upload: build/static/js/(.*)
- url: /static/css/(.*)
static_files: build/static/css/\1
upload: build/static/css/(.*)
- url: /static/media/(.*)
static_files: build/static/media/\1
upload: build/static/media/(.*)
- url: /(.*\.(json|ico))$
static_files: build/\1
upload: build/.*\.(json|ico)$
- url: /
static_files: build/index.html
upload: build/index.html
- url: /.*
script: auto
I am here to answer my own question. I seem to find the problem and how to solve it.
The main problem seems to be a caching issue. For the app.yaml settings, although the default expiration time is set to 5m, the url with path don't have the expiration set. For example, page www.example.com/about will have a different caching time than the js package. This means when a new build folder is deployed, the js packages have been changed, but the www.example.com/about page generated by your backend application is still the old version, and it will try to request the js package from the previous build foler. Thus, causing the 404 error.
The way to solve this is to set the expiration time for your response generated by your backend application. I am using the Flask environment, so the code for that is (credited to this answer)
response["Cache-Control"] = "no-cache, no-store, must-revalidate" # HTTP 1.1.
response["Pragma"] = "no-cache" # HTTP 1.0.
response["Expires"] = "0" # Proxies.
the web application is trying to get the static files from the last version
So are these files that were removed in your new version that you just deployed?
In general, it sounds like your problem has to do with stale browser caches. I wouldn't remove static assets from your deployed app right away specifically for this reason.
I see you're using ReactJS. Are you using the features that combine all the js and css into a single file whose name contains a hash? This should help with cache-busting.
The part that's confusing is that you said it would go down for a few hours. You have default_expiration: "5m" in your app.yaml so a few hours sounds a bit extreme. Are you not doing a hard reload (or even a full reload) when you are trying to check out your changes in your browser?
I have a lot of trouble finding how to map multiple domains to multiple services in the GAE. Here is the configuration :
One application is a Go API, deployed in GAE in the standard environment
The second application is an Angular application, also deployed in GAE in the standard environment but as another service.
Here are the app.yaml files :
Go application app.yaml
runtime: go
api_version: go1.9
handlers:
- url: /.*
script: _go_app
Angular application app.yaml
service: stage
runtime: python27
api_version: 1
threadsafe: true
skip_files:
- ^(?!dist) # Skip any files not in the dist folder
handlers:
# Routing for bundles to serve directly
- url: /((?:inline|main|polyfills|styles|vendor)\.[a-z0-9]+\.bundle\.js)
secure: always
redirect_http_response_code: 301
static_files: dist/\1
upload: dist/.*
# Routing for a prod styles.bundle.css to serve directly
- url: /(styles\.[a-z0-9]+\.bundle\.css)
secure: always
redirect_http_response_code: 301
static_files: dist/\1
upload: dist/.*
# Routing for typedoc, assets and favicon.ico to serve directly
- url: /((?:assets|docs)/.*|favicon\.ico)
secure: always
redirect_http_response_code: 301
static_files: dist/\1
upload: dist/.*
# Any other requests are routed to index.html for angular to handle so we don't need hash URLs
- url: /.*
secure: always
redirect_http_response_code: 301
static_files: dist/index.html
upload: dist/index\.html
http_headers:
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: DENY
I have a domain and want to bind the Go API to api.domain.com and the Angular app to domain.com.
By going to App Engine > Settings > Custom Domains I managed to add the domain for my API and it is perfectly working.
But now, I cannot find a way to map domain.com to my Angular application. Going to the same settings does not gives me an option to map a different service to my domain.
Thanks for the help and have a nice day !
To map subdomains you can use a dispatch.yaml file. An example:
dispatch:
- url: "example.com/*"
service: default
- url: "api.example.com/*"
service: otherservice
And then run $ gcloud app deploy dispatch.yaml (it can be in any directory).
Once you have example.com added under App Engine > Settings > Custom Domains for the default service, you can add the subdomain api.example.com for the other service. Later you need to add the new subdomain DNS records to you domain registrar as pointed out in the console configuration.
You want to first map your naked domain.com to your app.
Then choose to add another domain and you'll have the option to add the api (or any other) domain.com subdomain to a specific service.
Note that you have a conflicting/overlapping handler pattern in the 2 services: - url: /.*, this won't work as GAE won't know to which service to direct such requests to, they'll all end up sent to the same service. You need to partition your requests URL namespaces in a non-overlapping manner and you'll likely need a dispatch.yaml file as well. See Mapping subdomain to a service in Google App Engine project for details.
I tried to use the documented way of restricting access to urls marked as static by way of login: required rules in the app.yaml file. My intention is to have access to script urls handled by the go programming language by xmlhttprequests, but the first step of authenticating the user before she can load the file dist/index.html fails.
Surprisingly for me the user is not prompted to login, instead receives the dist/index.html file and all other files it asks for from the static folder as if no restricting rule were present.
This is my app.yaml file:
application: helloworld
version: 1
runtime: go
api_version: go1
handlers:
- url: /
static_files: dist/index.html
upload: dist/index.html
secure: always
login: required - this is what fails as far as I'm concerned
- url: /(.*\.(txt|html|json|png|js|log|md|css|ico))
static_files: dist/\1
upload: dist/(.*\.(txt|html|json|png|js|log|md|css|ico))
secure: always
login: required
- url: /.*
script: _go_app
secure: always
login: required
The folder that I uploaded to appengine looks like this:
app.yaml
index.yaml
xhr_responses.go - this is the intended future non static AJAX part
dist/
index.html
loads of other stuff that is static
The 'login:' handler options in the .yaml config files rely on Google's authentication, which can be persisted using cookies and survive a browser restart.
To properly test the authentication you need to either use a fresh incognito browser session or go to one of the Google sites and ensure you're not logged in (explicitly log out from all Google accounts if needed) before testing.
Apparently I was signed in when trying stuff on the live google app engine, which I just forgot is the way it knows not to redirect access to a new login prompt.