I have deployed a Laravel app via EBS but without the .env file.
Instead, i have entered all of the variables in the EBS configuration > Software tab.
I did a test just so I can check if they are properly read so I set APP_ENV=stage but when I ssh to the ec2 insteance created by EBS and I run the php artisan env command it shows production instead of stage which means the variables are not injected properly.
I tried rebuilding the environment several times but no clue. Anyone can help?
When you use EBS configuration > Software tab to define the environment variables, they take effect when the serve a request. they dont update the .env file.
when using CLI artisan commands, it will only follow the .env variables
Related
I'm working with a dockerized Laravel 8 website hosted on an ECS-managed EC2 instance.
Deployments are managed by AWS CodePipeline.
The code is stored in GitHub.
Production images are built by CodeBuild.
An ECS service runs a production release task to push that prod image to alternating EC2 instances.
This works well. I'm having problems, however, altering how I provision environment variables to newly released containers. During early development these were provided in a static .env file, then generated in CodeBuild during the build stage, and are now specified in the deployment task as stored AWS Systems Manager variables.
The goal is to allow the automatic provision of env variables without storing secrets in the codebase or build artifacts, or having to SSH into containers, and that's achieved.
However, I'd still like to run php artisan key:generate in the build stage to create a new app key when the production site is released, rather than storing that statically in AWS.
The problem
Whenever I specify any environment variables in the ECS deployment task, any environment variables I have provided in the site's .env file (specifically, those built in the CodeBuild build stage) are ignored.
Here's a snippet of the relevant buildspec.yml section:
build:
commands:
- echo Building front-end assets...
- npm run prod
- echo Installing composer libraries...
- composer install
- echo Creating .env file...
- touch .env
- echo Generating app key...
- php artisan key:generate
On release the site will throw a missing app key error, implying that php artisan key:generate failed - yet CodeBuild logging reports that it has succeeded. If I remove the environment variables from the ECS task then the generated app key is read correctly and the site works.
Illuminate\Encryption\MissingAppKeyException
No application encryption key has been specified.
It appears, basically, that if I want to provide some environment variables via ECS deployment task injection, I have to provide all environment variables that way, because any others will be ignored.
Any insights into why the ECS task environment variables method could result in the .env (or its contents) being ignored?
So I am trying to deploy my laravel application (v7) to was elastic beanstalk. I have seen tutorials directing uploading a zip file that contains a .env file and update config.database to use the global RDS_* environment variables.
This does not work for me because I want to use codepipline and codebuild to build my application with git hooks. I have tried to set that up but my codebuild does not build successfully because in my pubsec.yaml file I added the usual laravel setup commands like installing dependencies and migrating the application's database.
Migrating the database is where I am encountering an issue. Somehow it seems codebuild does not get the RDS_* variables for my app database. I have been stuck here for a while.
This has made me question how codebuild handles environment variables. How does it create the .env file it uses to deploy? I even added a Linux command to copy my .env.example into an new .env file but having the same issues.
Any help would be greatly appreciated. Thanks
The error on logs:
SQLSTATE[HY000] [2002] Connection refused (SQL: select * from
information_schema.tables where table_schema = forge and table_name = migrations
and table_type = 'BASE TABLE') ```
Codebuild runs on a different environment from elastic beanstalk so environment variables created in elastic beanstalk cannot be accessed in the container AWS codebuild is running.
What code build actually does is build your application and transfer it to an s3 bucket so that during deployment your app can be accessed and moved to your VPC which in my case is an ec2 instance managed by elastic beanstalk.
After deployment (ie. app moved to vpc), EB environment variables can be accessed by the application.
So if you want to run commands that require access to EB environment variables, using commands in code build is the wrong place to put them. You should make use of EB extensions. You can read about them here.
For my Laravel application, I added an init.config file in the .ebextentions directory on the root of my application and then added my migration command as a container command. This worked for my use case.
How do I create a group of environment variables that can be used both locally in development and on Heroku using Rails 6?
There are many different ways to configure environment variables, and people have many different preferences.
Personally, for my local development, I typically use the dotenv gem. I'll git-ignore .env, but I'll add a .env.example with all the vars I need stubbed out.
Then in my local checkout(s), I'll cp .env.example .env, and I will edit that .env file for all of my local configuration.
dotenv-rails includes a railtie to load environment variables from the .env file if they have not already been supplied as real env vars.
When I deploy to Heroku, I just use the Heroku console or GUI to set up my environment variables there.
Rails credentials work great and they don't require any extra gems and keep all your app secrets in one location.
EDITOR=vim rails credentials:edit
You can access any variable you set in this encrypted file by Rails.application.credentials.name_of_key. Typically, your .gitignore file will exclude the master.key file, so to make it accessible on a cloud provider, you'd provide the single key as an environment variable for decryption.
I initially deployed my Laravel app with APP_DEBUG set to true, but now we're in production I don't want it to whoops! every time there's an error.
I've changed the contents of our EB .config file so that APP_DEBUG: false and I can see the change in Elastic Beanstalk's environment properties:
But Laravel itself is still dumping everything to the screen when there's an error.
I've tried ssh-ing into our server and running php artisan config:clear to see if it was that, but it still didn't work.
I don't understand why Laravel isn't respecting the updated configuration on deployment. Can anyone explain the logic here?
Update: I updated the security settings on the instance and noticed that it was giving our custom error screen. Can anyone explain what happened? Was restarting the server after running php artisan config:clear what did it?
I had issues like this before where I changed something in the console's environment properties which did not correspont with what I got using tinker. You can find the env file on your instance here:
/opt/elasticbeanstalk/deployment/env
if you open the file you see that variables set in .env are not quoted so if you have a password with for example a hashtag or a name with spaces it can result in unintended problems.
I would suggest to stop using environment variables via .yaml config files and start deploying your .env to the elastic beanstalk S3 bucket and fetching it on deployment. This will result in you having more control over the content of the file.
Example of this can be found here:
https://github.com/rennokki/laravel-aws-eb/blob/master/.ebextensions/00_copy_env_file.config
I have a sapper project which contains various database secrets and such... So for local development I want to load a .env which contains the secrets. I am aware of dotenv. How do I use dotenv to load the .env file only on my local machine and not on my deployment in cloud run.
Add .env to your .gitignore file.
This way, it won't get deployed to the cloud when you do a git push.
Then go into your cloud provider and set your production environmental variables.
Rather than using the dotenv package you can use the dotenv-cli. You install it globally and modify the dev npm command and prefix it with dotenv. The cli will locate the .env file and then run the sapper dev command with the environment variables set.
Add another command for production without the dotenv prefix so it uses the environment variables on the machine.