Laravel Bref - Scheduler Lambda not using Environment Variables #1818
-
|
Hi, I have a laravel scheduler lambda and it does not seem to be picking up the environment variables that have been set. I can clearly see them in the AWS Console, and also if i make an artisan command to print all the environment variables, i can also see these outputted in the logs so i know they are set correctly When the artisan scheduler runs it does not use the environment variables set. I have a artisan cmd to dump the database to S3, but it is not using the environment variables i have set for DB_HOST etc (again i can see these set in the console, and also get the lambda to print them out with my custom artisan cmd) I have this exact same setup for another laravel project and it works absolutely fine - can anyone advise? |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 11 replies
-
|
can you drop your |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Do you see the environment variables in the "scheduler" Lambda configuration in the AWS console? |
Beta Was this translation helpful? Give feedback.
-
|
If i use the cmd to dump the databse to s3 (backup:run), it reverts to the default values in the laravel config, instead of picking up the preferred environment variables. |
Beta Was this translation helpful? Give feedback.
-
|
You're using the Spatie backup package with Laravel, right? How do you know that the Because you can log the correct environment variables via a custom command, I don't see any reason why the Bref caches your Laravel configuration. But, it doesn't handle the caching process differently for a My guess is that Lambda is using the correct environment variables. I think there are three potential issues:
Here is what I would do: 1. Disable the Bref config cacheI would add 2. Add a test commandCreate the following command at This command will log the relevant environment variables and test the connection to your database and S3. <?php
namespace App\Console\Commands;
use Illuminate\Console\Command;
use Illuminate\Support\Facades\Storage;
class TestBackup extends Command
{
/**
* The name and signature of the console command.
*
* @var string
*/
protected $signature = 'backup:test';
/**
* The console command description.
*
* @var string
*/
protected $description = 'Test connection to the database and S3 bucket';
/**
* Execute the console command.
*/
public function handle()
{
$this->showEnvironmentVariables();
$this->testDatabaseConnection();
$this->testS3BucketAccess();
}
private function showEnvironmentVariables(): void
{
$envs = [
'DB_CONNECTION' => env('DB_CONNECTION'),
'DB_HOST' => env('DB_HOST'),
'DB_PORT' => env('DB_PORT'),
'DB_DATABASE' => env('DB_DATABASE'),
'DB_USERNAME' => env('DB_USERNAME'),
'DB_PASSWORD_LENGTH' => strlen(env('DB_PASSWORD')),
'AWS_BUCKET' => env('AWS_BUCKET'),
'AWS_DEFAULT_REGION' => env('AWS_DEFAULT_REGION'),
];
$this->table(['Key', 'Value'], array_map(function ($key, $value) {
return [$key, $value];
}, array_keys($envs), $envs));
}
private function testDatabaseConnection(): void
{
try {
\DB::connection()->getPdo();
$this->info('Database connection is established successfully.');
} catch (\Exception $e) {
$this->error('Failed to connect to the database. Error: '.$e->getMessage());
}
}
private function testS3BucketAccess(): void
{
$bucket = env('AWS_BUCKET');
$file = 'test-file-'.time().'.txt';
$content = 'This is a test file for checking write permissions.';
try {
Storage::disk('s3')->put($file, $content);
$this->info('Successfully wrote to the S3 bucket: '.$bucket);
// Check if file can be read
if (Storage::disk('s3')->exists($file)) {
$this->info('Successfully read from the S3 bucket.');
Storage::disk('s3')->delete($file); // Cleanup
} else {
$this->error('Failed to read the test file from the S3 bucket.');
}
} catch (\Exception $e) {
$this->error('S3 bucket access failed. Error: '.$e->getMessage());
}
}
}3. Make three changes to your
|
Beta Was this translation helpful? Give feedback.
-
|
Hi @emaadali, thank you for coming back to me. How do you know that the backup:run command uses Laravel's default env values instead of the correct ones? Are you just assuming that because the backup doesn't succeed? I know this because in the CloudWatch logs, i can see its trying to connect to the default database name (not the environment variable), and also connecting to 127.0.0.1 (not the DB_HOST environment variable) _My guess is that Lambda is using the correct environment variables. I think there are three potential issues: The Lambda cannot connect to the database due to incorrect variables (wrong user/pass/host). I know neither of the above are correct, as i can clearly see the correct database variables (and have tested these manually), I know the security group configuration is correct and i know the IAM role of the lambda does have permission to S3 - i know this as i have the exact same setup for another laravel scheduler which works fine. Even if i open up the IAM role and SG to allow all temporarily i get the same result
I get the following output: 2024-06-12T20:28:43.631+01:00 | | Key | Value | So it correctly prints the environment variables, but completely refers to the default values when trying to connect to the database. |
Beta Was this translation helpful? Give feedback.
-
|
Can you post your entire |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Could it be that your are deploying generated config cache, or something to do with caches? |
Beta Was this translation helpful? Give feedback.
-
|
If i am deploying via pipeline, will there still be any cached config? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it is possible for your pipeline to deploy locally generated cache files, as Matthieu suggested. If your pipeline pulls your code from git, you should ensure the If your pipeline pulls your code from a source other than git, you should download the packaged A cached config file could cause this behavior, but you would also experience many other weird issues. I don't think you would be able to run the |
Beta Was this translation helpful? Give feedback.
-
|
@emaadali & @mnapoli thank you! this seems to have solved it |
Beta Was this translation helpful? Give feedback.
Yes, it is possible for your pipeline to deploy locally generated cache files, as Matthieu suggested.
If your pipeline pulls your code from git, you should ensure the
bootstrap/cachedirectory doesn't have any generated cache files in your repo. That directory should be empty or contain a.gitignoreor.gitkeepfile. If the directory isn't empty, delete the cache files and addbootstrap/cacheto your.gitignore.If your pipeline pulls your code from a source other than git, you should download the packaged
.zipthat Serverless Framework uploads to your deployment bucket to ensure thebootstrap/cachedirectory is empty. If the directory isn't empty, add!bootstrap/cache/**topackage.patterns