Laravel 部署在 CodePipeline 中的 Elastic Beanstalk 应用程序给出 500 SERVER ERROR

Question

I've created a Laravel app locally. (This is working fine)

After, deployed that app to AWS Elastic Beanstalk with a.zip file. (This is working fine)

Then, created a simple pipeline using AWS CodePipeline to grab data from a particular GitHub repo and deploy to that specific AWS Elastic Beanstalk environment. I see that any push I make to that particular repo, the CodePipeline does then deploy to that particular AWS Elastic Beanstalk environment.

The problem is that the instance now has

with the following Recent Event

Environment health has transitioned from Warning to Severe. 100.0 % of the requests are failing with HTTP 5xx. ELB processes are not healthy on all instances. Application restart completed 42 seconds ago and took 7 seconds. ELB health is failing or not available for all instances. One or more TargetGroups associated with the environment are in a reduced health state: - awseb-AWSEB-CVIEEN5EVRFC - Warning

and if I go to its URL I get a

500 | SERVER ERROR

• Deleted the.zip file from the root of the repo as that could've been causing a conflict. It didn't solve.

• Checked the Full Logs but couldn't spot anything useful.

Answer 1

Based on the comments.

The issue was caused by missing .env file in the deployment package/artifact that CodePipeline deploys. This was caused by the file not being committed into the GitHub repository.

To determine the cause, the CodePipeline's artifact was inspected. The artifact can be found in CodePipeline's bucket or in EB Application versions (in the Source column) and it is an objects a random name without an extension. In OP's case it was S40pAMw . It should be noted that this object is just a zip file without extension. To inspect it content, adding the extension to the download object allowed for straight forward opening of the zip archive.

(Please see @JackPrice-Burns answer for alternative way of dealing with env variables).

The solution was to commit the missing file into the repository. Once that was done, the CodePipeline was triggered

and once the deployment finished the Health of the Elastic Beanstalk instance changed to Ok

and the 500 | SERVER ERROR was now gone

Answer 2

This issue specifically was caused by missing environment variables.

It is BAD practice to commit.env or any files containing secrets to GitHub or any other source control system.

• First of all, if that repository is public in any way, all of the secrets are now also public, database credentials, encryption keys, AWS access credentials.
• Secondly, a common attack vector is the.git folder, and the underlying source control repository. Potentially a malicious user (if they found the source control details) could gain access to your secrets if your GitHub (or other accounts) were compromised.
• Thirdly, if you would like to setup multiple environments for your code, a production / develop / local environment for example. You now can't easily change these environment variables on a per environment basis as they're committed directly to the repository.

In the ElasticBeanstalk console you can go to Configuration -> Software and add environment variables at the bottom of the page (screen shot attached). These environment variables will be picked up by Laravel. Set all variables that are in the.env on that settings page and do not commit the.env.

Another good practice to follow is not committing your vendor folder. AWS CodePipeline allows you to create another step which can build your source code. This build step can take in your source control code, run composer install (to generate the vendor folder) and then send that to Elastic Beanstalk for deployment.

• Firstly, committing the vendor folder drastically increases the size of your repository and how long it takes to clone your repository.
• Secondly, merging code from different branches can become difficult if you're dealing with the whole vendor folder as well which can become thousands of files and millions of lines of code.
• Thirdly, if you would like to track how much work has actually been done for your repo on a per contributor basis, it becomes difficult because if someone commits a vendor folder change, they will commit whole packages which they didn't code themselves.