This is a how to question as not many information is available. I do, however, took the time out to investigate and tried their simple Hello World app which works great.
Now I tried to use Polymer Starter Kit git clone along with the Hello World tutorial, except for the git clone.
In my testapp folder, for the starter kit, I have added an app.yaml. Inside has the same config as the hello world:
runtime: nodejs
vm: true
api_version: 1
To deploy: gcloud preview app deploy app.yaml --set-default
After all that has completed, it gave me the url to preview the app. Note that the starter kit works on my local machine. The url gave me 503. So I waited for an hour and same 503. In my Dev Console - VM Instances, under Name, I see many instances. Is that correct? Is there a tutorial to get the starter kit on Google Cloud Platform running on nodejs?
As far as I know, the Polymer Starter Kit runs via gulp serve when in development, and that will be listening on a port like 5000 or 7000. If you read the Custom Runtimes or Managed VMs docs, you'll see that by default, requests to your app are routed to port 8080. However, you shouldn't run the development server in production. You should actually build the project and serve from the build version.
Instead of gulp serve, you should rather just run gulp to build and vulcanize the project. The dist/ folder will then contain the version of your app ready to deploy, and you'll need to look into that folder and realize that it's meant to be served as a static website. You therefore shouldn't need to use nodejs to serve it, and you'll save a ton of money from having everything in the static files network edge-cache, and not needing to use any real instance compute power.
You can find online examples of app.yaml files which can be used to deploy a static website on App Engine without the need to use any dynamic instances to serve anything.
Related
I have created sveltekit/pocketbase project that I would like to deploy to Linode to run under subdomains:
backend.mydomain.com for pocketbase
appname.mydomain.com for sveltekit
First I deployed pocketbase and I'm running it with systemd service which is working fine.
But there's problem when I want to deploy and run sveltekit app. I was following this article on how to run svelte app on linode using pm2 and caddy. But there's problem because 443 address is already in use. When I turn off the pocketbase.service I can run my svelte app.
Now I know I should probably use reverse proxy for pocketbase, but I'm new in this and a bit lost in all the information. Any tips on how could I achieve this?
I'm using GCP App Engine with auto scaling.
If I deploy a new version of the app code (Python 3 Flask app) with a simple change for control and test purposes, lets say I add a comment to one of the .js files I am not seeing that change to the file in the browser after it has been deployed.
I have 100% of traffic being served by the new version of the app. When I look at the source code for the version I can see the comment in there, but when I clear my browser cache and visit the page I only ever get the old version of the page (without the comment in the .js).
I have tried using the --promote and --no-cache values in the app deploy command, but no use. I have added:
default_expiration: "0d 0h 0m 0s"
To the app.yaml
I have also turned on object versioning of the storage account which app engine uses to try to ensure that only a single version of the file is available to be served - still no use.
The command I'm using to deploy is:
run: "gcloud app deploy app.yaml --quiet --promote --no-cache"
I can't understand why it should be so difficult to simply deploy a new version of the app and have the app engine serve the latest files; I must be doing something wrong but cannot see what.
Would appreciate any pointers.
The files are cached (even if for a short while and sometimes it takes time to clear it).
The trick is to make the urls (for the static files) unique for each deployment. This way, the browser is loading a 'distinct' url after each deployment. For example, you could append the environment variable, CURRENT_VERSION_ID to the url for all static elements. This means having something like (assuming Python/Jinja2)
src="/static/js/my_js_file.js?{{CURRENT_VERSION_ID}}"
os.environ['CURRENT_VERSION_ID'] changes for each deployment. There's a possibility this attribute is not available in newer runtimes. If so, just dump the environment variables and look for an attribute that is always present but the value changes (e.g. GAE_INSTANCE).
You could also just generate a random number each time your App is deployed and use that instead i.e.
src="/static/js/my_js_file.js?{{RANDOM_NUMBER}}"
According to the docs found here:
https://cloud.google.com/appengine/docs/standard/php7/runtime#application_startup
My app, is able to serve up index.php, without defining any handlers in my app.yaml file, which it does. Great! However, that same app.yaml file fails to serve up index in my local environment (dev_appserver.py) That seems less than ideal...
The path to the file is public/index.php
Here's the error I see in my local when I go with the very same app.yaml that works perfectly in production:
The url "/" does not match any handlers.
The dev_appserver.py only works with the first generation App Engine runtimes.
As you can see on the documentation, to test locally your PHP 7 app, you have to use the development tools that you usually use.
On this thread from the Google’s Public Issue Tracker there is a similar issue, and there is posted a solution for locally test PHP 7 apps. Basically, you have to set up a front controller on a web server locally. You can do it following this tutorial, for example.
I want to test Python 3.7 on Google App Engine Standard.
I am afraid if I upload application with python37 old application will stop working and will be no revert to previous python27.
Can you share some experience if it possible to keep both runtime versions?
It is not clear for me.
I read Python 3.7 on Google App Engine - documentation but not found information.
You have 3 main options, ranked from easier to 'harder' to do:
Just deploy this test you want to do in a new project, and you don't have to worry about your old application getting replaced.
Deploy this test to a new service. Just add the line service: whatevername to the app.yaml file of your test, and deploy it as usual with $gcloud app deploy. Voilà, you have a new service.
You can deploy this test in your default service, but to avoid stopping the previous one, add the --no-stop-previous-version flag to your $ gcloud app deploy command. After that, you can split traffic between this test and your actual app.
To be honest, I would go with options 1 or 2, as they are far more simple to deploy, and you can later on delete the test project or delete the new service if you wish to.
I have an app that uses the following command to deploy a static app generated by create-react-app:
gcloud app deploy --project MY_PROJECT -v dev
After that, my app is available on myproject.appstop.com.
But I don't figure out how to deploy this app using a diff URL for each environment. Like.: dev.myproject.appspot.com, stg.myproject.com and so on.
If you know or have other ideas about how to solve this please share your thoughts.
It depends on what you understand by environment. I would definitely recommend you to create different projects for the different environments (my-project-dev, my-project-staging, my-project-test, my-project-prod...)
If you just want to have a different url for your deployment, you are doing ok by using the -v (version parameter).
Once you've deployed again:
gcloud app deploy --project MY_PROJECT -v test
you'll have both versions accessible at:
dev.myproject.appspot.com
test.myproject.appspot.com
Also, check Dan's answer below as it contains very relevant info.
To complement #MarCialR's answer, you can use SSL as well, but with *-dot-* URLs like https://test-dot-myproject.appspot.com, see Targeted routing.
But personally I'm not a big fan of a version-based environment, it brings trouble, see Continuous integration/deployment/delivery on Google App Engine, too risky?
I chose to implement environments at app level - each environment as a different app, each with its own URL. See Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?
Since I'm using a wildcard custom-domain SSL certificate I'm simply mapping the different apps (environments) to different hosts/subdomains in my custom domain - thus ensuring everything works as expected with a custom domain at every point in the CI/CD pipeline, no surprises in production.