We've build few services on Google App Engine, we've ship them into production and everything worked as expected. But now I have little issue with one of my integration service which runs on flexible environment. I've deployed serveral times new version and maybe some of deploys wasn't successfully finshed or something like that. Now I see in Stack Driver logging some error logs from running instances of some old version (by version id in "resource" property). It made me few problems with with some version "missmatch" in integration tasks. I don't see this old versions in GC CLI SDK or in web dashboard. I've tried to delete whole service and redeploy it, but after first deploy, there are still new log entries in Stack Driver. I've changed DB credentials to prevent older versions to make mess in DB ¯_(ツ)_/¯. Production environment now runs OK, but there are still some old services spamming logging with errors about DB auth. I cant find this old versioned instances anywhere except this new log entries. Is it normal behaviour? Do you have some tips?
Related
I'm running a Google App Engine production server, using basic_scaling as the scale type. Whenever I update the code and deploy it - using gcloud app deploy - the old version of the code is shutdown.
According to the documentation, that's expected:
The shutdown process might be triggered by a variety of planned and unplanned events, such as:
You manually stop an instance.
You deploy an updated version to the service.
...
I understand that it's easier for most developers that way. But in my case, I'd like to keep the old versions running until the idle_timeout limit is reached. Does anyone know if there's a way to avoid the automatic shutdown and let the old versions to shutdown by themselves?
Per Google's documentation, when you deploy your code, the default flag of --stop-previous-version is used. This forces the previous version to be stopped. If you do not want that, you should explicitly use the --no-stop-previous-version in your deploy command (we also have this as a feature on our App, a GUI for GAE; you check or uncheck a checkbox).
Unfortunately, Google does not provide a way for the service to automatically shut down later. You'll have to manually shut it down and start the other version later.
I had a very hard time trying to find solutions to this problem online, probably because I do not know how to phrase this weird problem. I also could not reach out to Heroku as their support team only serves paid customers. I would really appreciate help from anyone.
Some context:
I have recently started experimenting with Heroku and deployed my first web app (Python, Flask, SQLite3) via GitHub. It works as intended, I am even able to interact with my database (add/delete/update). However, after making an update to my code locally and pushing it to GitHub, I realised that when my web app got built again by Heroku with the updates, the changes I made to the SQLite database is reverted back the initial, local version. (aka I lost the updates I made during testing).
So here comes the first question:
How does Heroku actually interact with the database? Does it create a copy of all my code from GitHub and runs it locally on their servers? (Since no changes to the database are reflected in my GitHub Repo despite successful updates to the database values through the web app).
And if so, this is the second question:
Is there any way for me to get this "updated version" of my database from Heroku side so I can download it locally before I make and push any updates to my code, so as not to erase all the updates to the database that a user might have made through the web app?
I need to test my wordpress install which I have set up already and deployed. I have to debug, so waiting 10-15 mins for it to deploy to test one thing isn't going to work.
All they mention in their docs: https://cloud.google.com/appengine/docs/flexible/php/testing-and-deploying-your-app#running_locally
Running locally
"To test your application's functionality before deploying, run your application in your local environment with the development tools that you usually use."
That's it. How can I actually serve my wordpress application? My tools I "usually use" are xampp...very confused.
Can someone help me run my flex env locally to test it?
You may want to take a look at this for the initial tests for your PHP application. You would have to install composer on your shell for it, if you haven't done it already.
Then, for the WordPress application, follow the steps described here to test the Cloud SQL instance that is associated to the app. There is also the possibility to test all the updates you want to apply to the WordPress side. Skip the deploying part until you confirm all your changes work for you, so that you don't have to wait all that time for a deployment.
I have been tweaking my environment in Google's App Engine to have several instances of my app for testing and production. However I am uncertain if the intended use of versions applies here.
App background:
- Node.js express app configured on app engine, using Cloud sql.
- 2 modules:
- - default/main - front end code code and API
- - workers - separate app that has a variety of workers
- Redis to keep track of the queue, kue.js for implementation
I was under the impression that I could use versions here, so that I keep only 2 modules, my default one and a workers module. Each will then have 2 versions, staging and production. The commands to push each one would then be:
gcloud preview app deploy --version staging --no-promote
gcloud preview app deploy --version production --promote --no-stop-previous-version
That is all separated well, and perhaps the intended use of versions. However, what I can't achieve with this is no downtime. What seems to happen is that the old machine is tore down then the new one build up, resulting in 3-4 minutes of down time during deploys. As opposed to keeping the old until the new is finished and then just rerouting. Note, the production version in this case should always have 100% of the traffic.
What I found to work well is to keep a module for each version, so I end up with 4 modules (default, default-staging, workers, workers-staging) and no real versions specified during deploys. When deploying with this, there is no downtime, but old versions are kept running:
gcloud preview app deploy --promote
I have a helper script to delete all versions that get 0% of the traffic. Is this the correct approach for setting up separate environments? Just looking for some feedback in case I am missing something obvious.
I'm just going through the node.js tutorials with a free trial account, and i'm stuck on the second one where you add a db. I add the mongodb deployment, shows up as a VM instances, fine. And my first deploy worked, but now that i'm trying to edit stuff, my deploy's keep failing.
The error i get is that I've exceeded my CPU quota. Watching the list of VM Instances under Compute Engine, i see it keeps spawning up instances, even though the app isn't being used. Guessing it just spins up 8 instances by default?
But then i guess the build system needs its own VM's, but the CPU capacity is used up, so none available to do subsequent builds?! I feel like i'm missing something...
Also, i see i can explicitly start VM's myself, so what process is creating them form me? And can i turn it off? or set a cap on number of instances it spawns?
Can i tell my project to only use 4
Also, the deploy takes forever, is that normal? Following the tutorials, so far I've only seen this command to deploy:
gcloud preview app deploy app.yaml --set-default
Is there another command that does an incremental deploy or something?
By using gcloud preview app deploy you're actually using Managed VMs which is an App Engine runtime which in turn runs Docker containers on Google Compute Engine, which it creates on its own. In other words, you're not using Google Compute Engine directly.
To get rid of extra VMs, you need to delete old app versions: navigate to Compute > App Engine > Versions and delete the versions you don't want.
See also this answer for more details and suggestions.