affordablemobiles / gserverlesssupportlaravel Goto Github PK

I tried to run on google cloud but it is not finding the us-central1 region that is called us14

Validate the IAP headers as required to validate it is turned on.

Can we go further and integrate it into Laravel's user system?

Hello,

In my GAE Standard + Laravel app, I'm currently running a standalone redis instance (on GCE). It sucks. The VPC connector was unreliable, so I'm having to connect to it via the public IP. It sucks.

The original package that this repo was based on actually started implementing the native memcached from GAE. Does this repo plan on doing that?

I keep thinking if we just write a simple driver for memcached it might work. Curious what your thoughts are...

Currently, we've got the gae_storage_path() function which we're using in the config files instead of storage_path().

It'll be good to swap this instead for replacing the root Application class with our own extended version like the old library, setting the storage path internally to /tmp/laravel/storage.

We should check if the directory exists and if it doesn't, scan the directory structure of the normal storage directory, then re-create it in the new /tmp location.

For the custom view service provider, we'll need a way to re-create the old storage path, to keep it as it was/is.

Investigate the possibility of having the Batch Submission Daemon from the Google Cloud library on App Engine Standard, as it is for Flex, so we don't have extra latency on the requests for log/trace submissions.

https://googlecloudplatform.github.io/google-cloud-php/#/docs/cloud-core/v1.14.0/core/batch/batchdaemon

I have reached out to Google for assistance here, will update once we hear anything.

Datastore session handler, ideally using Google's Datastore library instead of php-gds.

Hi there,
First, Thanks so much for this support.
I have made push queue task to the cloud successfully.
But when the queue handler response status 302 httpRequest, App error.

 httpRequest: {
  status:  302   
 }

I think it related this issue: https://cloud.google.com/tasks/docs/creating-appengine-handlers
But I don't know how to fix that.
Could you help me to check this issue? or example configuration about that?
Thanks!

PR #36 highlighted the presence of gae_realpath() calls in the Laravel 5.5 version.

Since this no longer runs on the PHP 5.5 runtime, this should no longer be required.

Review the usage and see if it & associated storage code can be removed.

From @flexgrip

Has anyone using this package had issues with instances running out of memory? I don't think its this package, it might be one of the dependencies. But on gae standard, I keep seeing Exceeded soft memory limit of 512 MB with 521 MB after servicing 95 requests total. Consider setting a larger instance class in app.yaml.

I tried to dig around the instances to see what was going on. So I made a little endpoint that would return the contents of the /tmp directory. Because I realized either the runtime can take up space in memory or /tmp can put files in memory there. The tmp directory wasn't taking up much disk space. But then I noticed this:

/tmp/batch-daemon-failure - 0MB
/tmp/batch-daemon-failure/. - 0MB
/tmp/batch-daemon-failure/.. - 0MB
/tmp/batch-daemon-failure/failed-items-21 - 34.3MB
/tmp/batch-daemon-failure/failed-items-22 - 57.41MB
/tmp/batch-daemon-failure/failed-items-23 - 37.12MB
/tmp/batch-daemon-failure/failed-items-24 - 44.12MB
So those batch-daemon-failure files are starting to take up quite a bit of space. I grep'd around for it and found a reference to it in the google-cloud-core php package.

Anyway, that leads me back to here. The only package I run that imports that cloud core package from google is this one :/

I don't know if this problem existed in the versions prior to L6. I dunno. I'm out of ideas. At this point, I'm trying to see if there's an env var to turn off the batch daemon thingy (I don't even really know what it does).

Any info would be appreciated. Maybe that package isn't needed or something?

I think it's likely related to either logging or OpenCensus tracing, as the batch daemon stuff was all related to using these tools in App Engine Flex.

We'll look into it and let you know.

We need some example app.yaml and .env files with documentation.

I don't think it'll be a good fit to auto-generate them from the artisan setup command if we want to easily be able to switch between Standard and Flexible, as that was more suitable as a one-time thing.

Create a samples folder with some examples?

Integrate StackDriver Trace via OpenSensus for Laravel 5.5, which supersedes #3

We'll be using the opensensus PECL extension that is included in App Engine on both Standard & Flex, which will allow trace hooks without needing to modify code to add trace points everywhere.

I used Google App Engine Flexible Environment and I get error:

PHP Notice: Exception: Unknown App Engine Region Code: europe-west2-a in 
/app/vendor/a1comms/gae-support-laravel/src/A1comms/GaeSupportLaravel/Integration/TaskQueue/Client.php:61

Great pack, but do you plan to upgrade to Laravel 6 in the nearest future?

Building on the async submit functionality for the Trace API referenced in #3, we should try to build in support for the jsonPayload style logs that Google's custom MonoLog handler supports on the Flexible Environment.

Can we build our own custom log handler and submit all logs without context via the standard syslog method, which should hopefully catch all fatal errors, while submitting logs with a jsonPayload via the Push Queue API to our async processor?

One thing we'll have to watch out for is the maximum POST size, as even on a large trace we were having to split into multiple chunks - does this mean it'd be unsuitable to save all the logs up until the end of the request and submit them then?

Handle the "artisan config:cache" command for deploying to App Engine.

Testing it locally, it puts full paths from the development/build environment into the "storage_path" locations.

We'll need to overcome this - do we:

• Add event listeners?
• Detect the execution is a config:cache and make changes?
• Have our own artisan command for this instead?

Remember the note from the documentation:

If you execute the config:cache command during your deployment process, you should be sure that you are only calling the env function from within your configuration files. Once the configuration has been cached, the .env file will not be loaded and all calls to the env function will return null.

https://laravel.com/docs/5.5/configuration#configuration-caching

Once everything else is in place, make the required changes to make sure the package works with Lumen as well as Laravel, as with the previous version.

Create an interface for IAP style Service-to-Service OAuth2 authentication.

For use when using IAP isn't an option because it can't be turned on/off seamlessly for different service/versions.

• A middleware to validate incoming requests
• A class (Guzzle middleware?) to generate JWT bearer tokens for outbound requests to other services.
  • Guzzle middleware should be re-usable to make requests via the real IAP.

Bearer token should include the Client ID as required by IAP and the middleware that verifies the auth should check this too.

https://cloud.google.com/iap/docs/authentication-howto#iap_make_request-php

Prepare command "php artisan gae:prepare flex" is outdated as laravel now uses new version of Dotenv

It would be great to have the batch daemon on the Standard Environment, as not only would it support better async submission of both logs & trace entries, it would also allow us to use Stackdriver Debugger with live breakpoints/logpoints, etc.

So far, we tested it on Flex but we've struggled to enable it on the Standard Environment.

Create some example Cloud Build push-to-deploy config, along with instructions on how to do things like encrypt secrets with KMS (for the APP_KEY, etc).

When I did composer update, I got a error message.

Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - a1comms/gae-support-laravel dev-php72-laravel55 requires tomwalder/php-gds dev-grpc -> no matching package found.
    - a1comms/gae-support-laravel dev-php72-laravel55 requires tomwalder/php-gds dev-grpc -> no matching package found.
    - Installation request for a1comms/gae-support-laravel dev-php72-laravel55 -> satisfiable by a1comms/gae-support-laravel[dev-php72-laravel55].

tomwalder/php-gds has not "dev-grpc" version now.
https://packagist.org/packages/tomwalder/php-gds

Hello again,

I was going to use your package solely so that I can get Cloud Tasks to work as a queue driver. But then I had a bunch of questions about how I might use other portions of it. So I'm going to place these below. If you have time, I'd love to know what you think. I noticed other tickets about example configurations and cloud build configs. Maybe this can help clear those up. I could even PR some to you if you think it would help.

Current setup

You should know I already have an existing Laravel 5.8 installation on GAE standard. And I would prefer not to use flex/docker. I do not use cloud build and I could not figure out how to get cloud build to compile my node assets while still using GAE Standard.

What I have working:

• Vanilla deploy without cloud-build
• Cloud SQL as DB
• Stack driver logging (but there don't seem to be many logs or maybe its not working)

What I don't have working:

• Task queues using cloud tasks
• Blade view compiler (not sure what is getting compiled, if anything)
• I have to pre-build my JS before deploying

Questions

1. How do you currently compile node/js assets for a deployment? I have to run yarn run production before deploying JS changes
2. Since I am not doing anything regarding blade view compilation, does that mean that its just running everything at runtime? Not sure how its currently working since I haven't touched the blade compiling
3. How are you running cron? I setup a cron.yaml and pointed it at an endpoint, but it doesn't really seem to do much.

Thanks!

Since App Engine is deploy once, run many times on many instances, there may be some performance benefit to ahead-of-time compilation of all of the blade views as deploy time.

This may not be standard in Laravel, as a deployment to a standard LAMP stack where the files reside on disk have the expectation that files can be changed and the framework will adapt dynamically.

We'll investigate if we can have an artisan command to do this as part of our Cloud Build push-to-deploy pipeline, creating the on-disk cache files that would then become read-only and should be valid for the lifetime of that version.

Once that's done, we should also look to see what the framework is doing to allow the files to be refreshed by invalidating the cache when the change on disk in the normal LAMP use case, as there may be some disk operations we can nullify here, hopefully reducing request latency where disk I/O latency is high on App Engine.

Google are in the process of merging a new interface to interact with Cloud Trace googleapis/google-cloud-php#456

Once their PR is merged into master, we need to introduce Trace support here.

We'll start out with the Laravel provider here: https://github.com/chingor13/php-test-apps/blob/master/laravel/blog/app/Providers/GoogleCloudProvider.php

Keep it using AsyncReporter and QpsSampler on Flexible, but modify it so it'll detect the Standard Environment and revert back to our old method of using Push Queues to do an async submit as the latency is a lot lower, plus use the AlwaysOffSampler, as we only want to sample when App Engine wants us to which it'll signal by sending o=1 in the header.

To this end, we'll need to write our own Reporter interface that'll utilise the Push Queue API.

Since using the Push Queue method will use more chargeable resource, we should publish our cost tuned Go microservice that can be deployed to do the async work from this library.

Although, should we write the URI handlers to do the same work in here for people who don't want to utilise this method? Perhaps if they are super low volume and find it easier to stay within the free tier that way?

Proper integration of StackDriver Logging with context via jsonPayload.

This supersedes #4

Call to undefined method Illuminate\Foundation\Application::share()

Trying to run this on PHP 7.4 on App Engine, pretty instantly getting SIGSEGV logged from php-fpm

Trying to debug, can re-create in a blank folder, get composer to install the latest "google/cloud" and in public/index.php:

<?php

require __DIR__.'/../vendor/autoload.php';

use Google\Cloud\Logging\LoggingClient;
use Google\Cloud\Logging\PsrLogger;

(new LoggingClient())->psrLogger('exception')->error('test',[]);
die('logged');

You'll get SIGSEGV, then if you change it to:

<?php

require __DIR__.'/../vendor/autoload.php';

use Google\Cloud\Logging\LoggingClient;
use Google\Cloud\Logging\PsrLogger;

(new LoggingClient(['transport' => 'rest']))->psrLogger('exception')->error('test',[]);
die('logged');

It works again :).

Looks like the gRPC binary module / PHP extension is broken: have raised with Google.

Simply setting the transport to 'rest' in one place isn't really a fix, as everything defaults to gRPC everywhere, it's just useful as a PoC.