I have encountered a Google App Engine problem for which I can not find an answer despite a lot of searching.
I can make a minor tweak to my code - say changing a constant or something, nothing that breaks the app code - and do a deployment using appcfg.py update.
After deployment, nothing works, and I find a "This app has no instances deployed" message in the developer console. Not a single instance is running. Eventually after about ten minutes I start to see instances appearing, the app working fine.
I have maximum idle instances set to 5, I've enabled warmup, and I am well within both quota and budget. My log files don't tell me anything of use.
So this one's got me stumped. I'm not anxious to see a ten minute outage every time I update my code. What is happening here, and how can I ensure that my instances start up as they should when I deploy new code?
Related
I deployed my own personal website to Google Cloud's App Engine last week, and since then it has built up around a $12 bill. But there would be very few if any people actually visiting my site, as I'm really the only one who knows about it.
It is a basic React app that uses React Router to display three different pages. I can't imagine the code that I used in the app is so complex that it's causing the bill to stack up, because the code is very basic.
The logging shows health, liveness and readiness checks being completed on the app constantly, is this something that would add to the cost of the app?
I'm relatively new to deploying apps on the cloud, is there anything I can do to reduce the cost of having this app deployed?
Is this Flex or Standard? A Flex instance never goes down to 0 (which means you're being billed) whereas a Standard instance goes to 0 when there's no traffic (which means no billing for that period).
Do you have multiple versions of your App running? When deploying, if you do not specify a version number, gcloud will generate a version number for you. This means that multiple deployments might lead to you having multiple versions and if you do not delete them or force traffic to be migrated to the newer versions, you might end up with multiple versions running and thus increasing your bill. You should check the number of versions you have by going to your console and delete any one you don't need.
Are you using manual scaling or what type of settings do you h
Check out the following tips (short twitter threads from our account) to see if the tips will help - tip 1, tip 2
Over the past few weeks my gcloud app deploy has been failing regularly, today it fails even after attempting 10 times so far. According to the google cloud web interface, it is failing after build in the exporting phase:
7: exporter
/cnb/lifecycle/exporter asia.gcr.io/<project>/app-engine-tmp/app/ttl-2h:<uuid>
Is there anything we can do about this at all?
(The build itself takes just a few minutes, then this exporter phase runs until the 10m mark and is killed.)
Perhaps there is a way to make gcloud app deploy do the build in the asia region?
I deleted everything in the Google Cloud Console under the "Container Registry" menu option. Not sure why that helps, but builds now average 2 minutes instead of the historical 9-11 minutes for the past year or so.
(Although this technically doesn't answer why behind the question, this does solve the strange delays in building on appengine (standard). I am going to mark it as solved and leave this question here in case others encounter the error message above.)
When deploying using gcloud app deploy I get the following error:
Timed out waiting for the app infrastructure to become healthy gcp
I contacted GCP Support and they told me the same thing I had read in other threads:
the error you are referring to may be related to the Compute Engine “In-Use IP Addresses” Quota limit. You can view your current quota limit information by accessing from your GCP menu “IAM & Admin > Quotas”.
I checked the "In-Use IP Addresses" and it doesn't seem like I have a problem with quotas:
Looking for the error, I found that in the Activity tab, when deploying, I get an error. Apparently , when App Engine is trying to delete a VM, the process starts to loop trying to delete it. You can see the error:
(I intentionally covered the project ID)
Edit: It seem like the problem is only with southamerica-east1. I created a new project in southamerica-east1 but I kept getting the same error, so then I created a new project with the App Engine in us-west2 and worked like a charm (I used the same application and app.yaml). I wonder if the problem is GCP southamerica-east1 or a unknown bad configuration by my side.
This is probably related to this issue: https://issuetracker.google.com/u/2/issues/73583699. It does mentioned the "in-use IP Address" quota, but many people have posted in recent days (Nov 2018) indicating that they are seeing the error and have verified that they have not hit their quota.
Unfortunately, no solution has been posted and there hasn't been any recent comment from the devs.
First, our apologies that you’ve experienced this issue. Be assured that we are aware of the situation and the team works hard to resolve it.
Our goal is to make sure that there are available resources in all zones. This
type of issue is rare. When a situation like this occurs, or is about to
occur, our team is notified immediately and the issue is investigated.
We recommend deploying and balancing your workload across multiple zones or
regions to reduce the likelihood of an outage. Please review our documentation
which outlines how to build resilient and scalable architectures on Google
Cloud Platform.
For the time being, you can try relaxing your requirements (e.g. requesting a smaller instance or one with fewer resources) or removing the external IP requirement.
If that proves not to be enough, you can try deploying your application to another region
Again, we want to offer our sincerest apologies.
Thanks for understanding.
At the end we didn't find a real solution so we moved all our services from Brazil to US-2. I'm not sure if the Region is the problem, but there in US-2 all works like a charm
I was running two different versions of my app with the same api_version number, and I started receiving Database locked exception. I've closed both apps, removed both from the app engine launcher, and then reloaded the one i'm currently working on; and I'm still getting the same error.
I've been googling it for 30 minutes, and it doesn't seem like there is a lot of information on this topic specifically related to GAE.
I would like to know how to go about fixing the issue, but more than that, I'd like to know what's causing it in the first place.
I gave to 2 api versions different version numbers but the same api number with the hope that I'd be able to run them concurrently and have them share a datastore instance, but if its displaying this behavior locally, I'm sure its not going to work when deployed. I suppose I have less of an understanding of the versioning than I thought. If anyone has a brief explanation of that process, what causes locking and how to fix that would be great. Thanks!
EDIT:
'api_version' refers to google's api for app engine; nothing to do with one's personal application. still trying to figure out how to deal with 'version' and #endpoints.api. What's the diff?
I have a site that I deployed to Heroku. It's a low traffic site so if nobody goes to it for a couple hours and then go to it, it will take about 5-10 seconds to load. Any other requests to other pages on that site loads up fine quickly. If I exit the site entirely and check back in a few minutes later, it also comes back up quickly.
It's only if it's left idle for a couple hours that the spin up time is noticeable. Does anyone else have this issue? If so, how did you fix it.
Also while on the topic, does the same thing happen with Google App Engine? I'm currently just trying out these app hosting platforms so I don't really have any preference for technologies/languages.
Quickest way to "fix" this problem is to make sure your site is always up. Set up a pingdom account (http://www.pingdom.com/) which will ping your site every few minutes just to keep it alive.
I have a special route myapp.com/keep_alive which does nothing except hit the rails stack without caching.
Hopefully this helps!
Do you happen to be hosting it with the 'free plan', ie. only with 1 dyno?
If so, what you experience might be a Dyno Idling. You can increase the number of the dynos so that your app is 'always-on'
From what I understand Heroku makes public this behaviour.
For free site hosting, one heroku 'Dyno' is dedictaed to your site, if the dyno is inactive for a period of time then the resource will be redirected elsewhere, when you try access the site after this time the system has to go request a Dyno back.
You can prevent this by paying for extra dyno's which will stick with your site or you can visit the site on a regular basis yourself with a automated script.
The best thing you can do to decrease this time is to minimize the size of your slug. This includes steps like deleting any PSD or AI image assets, removing PDFs, and minimizing your gem set. For more information see: http://devcenter.heroku.com/articles/slug-size. As a reference, my applications can usually spin up in under around one second.
If you don't want to pay for Pingdom, you can try the open source alternative: Pinger
https://github.com/austinthecoder/pinger