Why is Go program hanging on gcloud app deploy?

1
votes

I am trying to setup a local version of the following repository on github, https://github.com/microsoft/mouselog, I haven't changed anything but add an app.yaml with the following content. 

runtime: go112
env: standard

service: mouselogserver

When I run gcloud app deploy with the CLI tools, it hangs at the following command for atleast 15 minutes.

DEBUG: Executing command: [u'mydir\\google_appengine\\go-app-stager.exe', u'mydir\\server\\app.yaml', u'mydir\\server', 'mydir\\local\\temp\\tmpdtk2gh\\tmpqcbdbm']

I'm assuming this isn't expected behavior? Running gcloud app deploy with nodejs takes 30 seconds max.

1
gogoogle-app-enginegcloud
Could you please confirm me you are using also mouselogserver for Node.js? As far as I can see when using mouselogserver in the backend side, Go is used. I would like to know what are you running with Node.js in order to troubleshoot further. Thank you - Christopher Rodriguez Conde
I am running the front end for the project on its own service, default, that uses nodejs. github.com/microsoft/mouselog/tree/master/web - ara6893
Was this deployment faster before? In that case, when the deployment time started to increase? - ericcco
@eespinola This is my first run with go, I was actually able to deploy. It just took 25+ mins, is that a normal deployment length? - ara6893

1 Answers

0
votes

Generally it is not expected for a deployment to take 25 minutes. I'll explain one possible cause below.

App Engine deployments interact with the bucket staging.<project-id>.appspot.com. This bucket is created by default the first time you deploy to App Engine and is used to store intermediate build outputs in order to lower the time of forthcoming deployments in a similar fashion as Docker layers. Most of the time this helps to increase the deployment speed by not requiring to "re-build" the parts that hasn't changed.

The files stored in the staging bucket are wiped out after 15 days of their insertion. However, in cases where an application is deployed a large number of times with file changes in a short period of time, a lot of temporary objects are created in the bucket and the size of it grows. This may slow down the deployment since all of them will be scanned to search for reusable intermediate builds.

If that sounds like your use case there is a workaround that consists in using the gcloud flag --bucket which allows to use a user provided bucket instead of the staging one.

gcloud app deploy --bucket <YOUR-BUCKET>

Nonetheless, if this doesn't solve the problem you would probably need to open a support ticket so that the issue could be investigated further given that here we lack the tools to do it ourselves.