0

I'm using GAE for a Laravel PHP site and using flex instances. I've always had no problem doing a "gcloud app deploy" to get my app deployed. However, for the last 24 hours or so when I attempt to deploy I get the following error:

Step #1: Package manifest generated successfully.
Step #1: > chmod -R 755 bootstrap/cache
Step #1: > php artisan cache:clear
Step #1: 
Step #1: In AbstractConnection.php line 155:
Step #1:                                               
Step #1:   Connection timed out [tcp://1.2.3.4:6379]  
Step #1:                                               
Step #1: 
Step #1: Script php artisan cache:clear handling the post-install-cmd event returned with error code 1
Step #1: The command '/bin/sh -c /build-scripts/composer.sh' returned a non-zero code: 1
Finished Step #1
ERROR
ERROR: build step 1 "gcr.io/cloud-builders/docker@sha256:12345" failed: exit status 1
Step #1: 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ERROR: (gcloud.app.deploy) Cloud build failed. Check logs at https://console.cloud.google.com/gcr/builds/12345?project=1234 Failure status: UNKNOWN: Error Response: [2] Build failed; check build logs for details

I have a Memorystore (redis) instance I use since GAE memcache isn't available on flex instances yet. My app uses redis as a cache, so as you can see above, once the new code is deployed composer is configured to clear the cache, which is where it's timing out and failing.

If I SSH into an existing instance, I can run php artisan cache:clear no problem. However, it's failing on deploy. It's a pretty simple code change that's only UI tweaks (html/javascript) so none of the redis or connection code has changed.

Any ideas?

Brad
  • 386
  • 4
  • 15
  • Looks like something has changed on GAE's end as I have tried checking out an old commit that was the last known commit to successfully deploy, and it's running into the same issue. – Brad Nov 04 '18 at 01:11
  • Looks like an underlying service problem: `Connection timed out [tcp://1.2.3.4:6379]`. I'm guessing redis-related, since it hits the `php artisan cache:clear` execution – Dan Cornilescu Nov 04 '18 at 03:06
  • @DanCornilescu Yes, but I don't fully understand because my current deployment is accessing memorystore (redis) no problem. It's only when I attempt to deploy the new code that it's having issues. – Brad Nov 04 '18 at 05:34
  • ONe way to confirm that's the problem: comment out cache clearing and retry deployment. If it works then it's confirmed. Then it's just a matter of figuring out what's different when running at deployment vs manual. One usual suspect is credentials:when running manually you may already have cached user credentials, when running via a script they need to be explicitly loaded. – Dan Cornilescu Nov 04 '18 at 13:44
  • Yes commenting it out in the deploy allows it to deploy no problem. It's trying to hit memorystore (redis) during the deployment that's timing out. app.yaml has all the correct credentials in my env. It's not returning an invalid anything either, it's saying it's timing out. – Brad Nov 04 '18 at 17:38
  • Try the manual command with wrong/missing credentials, see if it behaves the same way. – Dan Cornilescu Nov 05 '18 at 02:49
  • @DanCornilescu There are no credentials since it's a private redis instance – Brad Nov 05 '18 at 17:43
  • Well, you need to figure out what's different in the 2 invocations: environment, interactive vs non-interactive shell, etc. – Dan Cornilescu Nov 05 '18 at 18:39
  • The issue is that nothing has changed on my end and yet the deployment stopped working. – Brad Nov 05 '18 at 21:31
  • But that's only because you configured the deployment to include `php artisan cache:clear`, which seems to no longer work as it used to. Not GAE-related. – Dan Cornilescu Nov 06 '18 at 02:37
  • @DanCornilescu The deployment always had `php artisan cache:clear` in it, and it always deployed fine. Deploying the _exact same_ code that worked a week or so ago no longer deploys today. I would say that makes it seem like something has changed with GAE, maybe Memorystore is no longer available at that point of the deployment process for some reason? I can't find any changes or release notes to support that though. – Brad Nov 06 '18 at 20:29
  • @Brad I'm having exactly the same issue 8 months later. Were you able to figure this out? – Rich Jun 26 '19 at 01:26
  • @Rich I loved away from GAE a while back since it never really worked great. However; I -think- I solved this issue in particular by changing my memory store instance to be a single instance instead of having a backup as well? Hope that makes sense. It doesn’t really solve the problem as much as settled on a less desirable alternative that worked. – Brad Jun 27 '19 at 07:03
  • @Brad Thank you for your response. Removing the command from the composer is the only thing which has worked for me. I'm curious, what route did you move away to? – Rich Jun 27 '19 at 11:22
  • 1
    @Rich oh sorry I remember now; the connection to memory store wasn’t available yet during the deployment process so I had to remove the command from my deployment and I added a button in the admin section of my UI to clear cache all the caches. – Brad Jun 28 '19 at 13:55
  • @Rich I moved the app to Digital Ocean and use Laravel Envoyer for deployments. It doesn’t auto scale but that wasn’t a hard requirement for me. They have load balancer, managed databases and everything else I needed. It’s been working great so far. – Brad Jun 28 '19 at 14:00

0 Answers0