Trying out new flexible app engine runtime. In this case a custom Ruby on Rails runtime based on the google provided ruby runtime.
When firing of gcloud preview app deploy the whole process takes ~8 minutes, most of which is "updating service". Is this normal? And more importantly, how can I speed it up?
Regards,
Ward
Yes, that is totally normal. Most of the deployment steps happen away from your computer and are independent of your codebase size, so there's not a lot you can do to speed up the process.
Various steps that are involved in deploying an app on App Engine can be categorized as follows:
Gather info from app.yaml to understand overall deployment
Collect code and use the docker image specified in app.yaml to build a docker image with your code
Provision Compute Instances, networking/firewall rules, install docker related tools on instance, push docker image to instance and start it
Make sure all deployments were successful, start health-checks and if required, transfer/balance out the load.
The only process which takes most of time is the last part where it does all the necessary checks to make sure deployment was successful and start ingesting traffic. Depending upon your code size (uploading code to create container) and requirements for resources (provisioning custom resources), step 2 and 3 might take a bit more time.
If you do an analysis you will find that about 70% of time is consumed in last step, where we have least visibility into, yet the essential process which gives app-engine the ability to do all the heavy lifting.
Deploying to the same version got me from 6 minutes to 3 minutes in subsequent deploys.
Example:
$ gcloud app deploy app.yaml --version=test
Make sure you check what is in the zip it's uploading (it tells you the location of this on deploy), and make sure your yaml skip_files is set to include things like your .git directory if you have one, and node_modules
Note that the subsequent deploys should be much faster than 8 mins. It's usually 1 minute or less in my tests with Node.js on App Engine Flex.
As suggested above by #ludo you could use in the meantime Google App Engine Standard instead of Flex. Which, takes approximately ~30-50 seconds after the first deployment.
You can test GAE Standard by running this tutorial, which doesn't require a billing account:
https://codelabs.developers.google.com/codelabs/cloud-app-engine-springboot/index.html#0
And agreed. this doesn't address GAE Flex but gives some options to accelerate during development.
Just fire this command from root directory of app.yaml
From shell visit directory of app.yaml then run gcloud app deploy
It will be uploaded within few seconds.
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.)
I have around 10 microservices. Usually I use a script that loops through their folders (each of which contain an app.yaml for that service) and use gcloud app deploy to deploy it. However, is it possible to speed this up by using gcloud app deploy in say, 10 different terminals, one for each microservice? Will GAE processs the deploys in parallel or will this cause any issues?
Note: I am using App Engine flex, and from what I've been told, Standard environment deploys are a lot faster than deploys to Flexible environment. Regardless, switching to standard is not possible.
I tried deploying a couple of services on different tabs of the Cloud Shell Terminal and it works, so it appears to be possible but you should test that with all your microservices to see if this is not a bigger load than app engine could handle (which shoudn't be, but just in case).
However, it felt not worth the effort, since you have to lose time by opening up a new tab, waiting for it to be setup and typing the commands all over again. I did this manually, so if you are able to automate that opening of tabs into a script, it could be worth it.
Also, as you can see on this community post, another way to do a faster deploy is to deploy to another "version" of your app, then when all modules are deployed, do a very fast version switch.
NOTE: Not sure if you are doing this already, but an alternative is to stack the deployment of your services into a single command on Cloud Shell like this:
gcloud app deploy ~/my_app/app.yaml ~/my_app/another_service.yaml
Turns out it does work. I deployed 6 microservices in parallel, and it took < 10 mins for all of them to get deployed, compared to ~60 mins (average of 10 mins each for each service)!
For parallelizing it, I used Azure Devops pipelines, and since each job runs in parallel, all I had to do was create a job for each microservice, then run gcloud app deploy in each of the jobs to deploy them.
It takes so long to deploy an app to App Engine by this command
gcloud app deploy
After I updated my source code, even if it's just one line of change, I had to issue this command again to upload the changes to App Engine. Again it will take a long time to deploy for just one line of code change. Is there a way to quickly update the code on App Engine instead of doing this time consuming deploy again?
I am looking for options that can speed up the code update after it's first deployment to App Engine. Since I am using flex, would using standard make it faster to update the code? Is it true that there is no way around it on App Engine and the only way to do it is to use another service such as Compute Engine?
Yes, standard env app deployment in such context is much faster, because it only involves uploading the modified files and restarting the instances.
But using standard env is often not an option for other reasons. The potential duplicate post I referenced contains itself references to both explanations and suggestions for potential speed improvements. I don't see a point in duplicating them.
The most common reasons for choosing flex env:
language support
restrictions of the standard env sandbox
See also: Google App Engine Standard or Flexible environment?
(Sep 2021): First of all, the issue you describe for App Engine (flexible) does not apply to App Engine (standard), which is almost a completely different product. (For those who are new, here is a comparison b/w both products.) This question is a few years old, and there are a few more options available to you now:
App Engine standard: If your app can run in Python 3.7+, Java 11, Go 1.12+, PHP 7, Node.js 10+, or Ruby 2.5+, then this is the obvious place to go. A deploy should take less than 1 minute.
Cloud Functions: If you don't have an entire app or your app is made up of one function/route or is otherwise short & simple, consider turning it into a microservice for Cloud Functions. Its deployment time is also less than a minute.
Cloud Run: If you're using App Engine flexible because your app is containerized, consider Cloud Run, which runs containers in a serverless way. A big bonus is that a Dockerfile is optional (due to Cloud Buildpacks). It has taken many GAE flexible use cases. Deployment is also less than a minute. If interested, I produced a pair of videos on how to migrate from App Engine standard to Cloud Run, using Docker as well as no Docker. At some point, I'll do one on transitioning from GAE flexible.
App Engine flexible: If none of the options above work, requiring you to stay on GAE flexible, then yes, you'll have to deal with its longer deployment time (due to the complexities of the system and all the resources it needs to spin-up & manage on your behalf). If you have a container and Cloud Run isn't an option, also consider GKE Autopilot or GCE MIGs (managed [VM] instance groups).
We have a development,uat and production environment for our angular/java/mongodb app. At the moment we are moving our deploying the same build to dev and uat. The problem with that is that some things are not finished and basically not ready to be deployed to uat. What is a good way of managing/selecting which commits/changesets are to be deployed to uat/prod? If I know which commits I want is how can I accomplish this?
The use case we have is that some builds need to be tested (by other jobs) before we know if they are good enough to deploy / release.
We use the "Promoted Builds Plugin" for that. There is a manual promotion process as well.