Setting up AWS Elastic Beanstalk with Laravel to update with GIT

Disclaimer for 2021 and Beyond

In case anyone should read this article and get the wrong idea here is my disclaimer for 2021 and beyond…

This post was written in 2019. I had a specific use case where something like CodePipeline was not necessarily required. In the original post from 2019, the summary actually explains that there are different ways to deploy to EB. One reason I tried this way was that in 2019 I was looking at different methods where I was able to use GitHub as the repo instead of AWS CodeCommit. I’d like to be absolutely clear that I would probably not choose to deploy this way in 2021.

I’m choosing to leave this post here, as opposed to deleting it. I have not written a similar post on deploying with CodePipeline, but I have set up and used a more standard CodePipeline setup more than I have used this method. I am also constantly assessing how I deploy and if better methods are available. There are many much better methods which I may well post about in the future, but have not done so yet.

2021, October 11th

Original Post from 2019…

Here’s what you do to set up an AWS Elastic Beanstalk instance and update it through GIT. So, you’ll need the correct access on your AWS account and here we’re going to use Elastic Beanstalk (EB), RDS, IAM, EB CLI, Github and GIT.

Setting up Laravel on Elastic Beanstalk

This setup is for an Ubuntu machine. Most of this comes from this url…

• Create a new private repository on Github (or wherever you want to store your GIT repo). It should be private because you will be adding your .env file.
• Clone the repo on your local machine (in this case an Ubuntu Desktop).
• In the directory, you’ve cloned the repo to you install a fresh version of Laravel. You may need to install it into another blank directory then copy the files across as the directory you want to install Laravel into isn’t empty.
• Check that Laravel is working locally.
• Once you have a working version of Laravel you can save the contents of the Laravel directory minus the vendor folder to a zip file using the command…
• zip ../laravel-default.zip -r * .[^.]* -x "vendor/*"
• Create a new EB instance and use the default application to begin with. Your EB url should now give you a holding page when you go to it in a browser.
• Now to put your Laravel project onto the EB instance you click the “Upload and Deploy” button and select the “laravel-default.zip” you made previously.
• Now, when you go to the EB url there may be an error, so instead put the “public” directory in the url, then it should work. To fix this, go to “Configuration” > “Software” and the “document root” is the first option on the form, make it “/public”.

Connecting Elastic Beanstalk to an RDS database

At this point, you should have a working version of Laravel on your EB that you have uploaded manually and that isn’t connected to a database.

• To connect to a database modify “Database” in “Configuration”. This is where you can make an RDS instance for your website.
• Once the RDS is made you’ll still need to allow access to the EB instance and your local machine. Go to the RDS instance and under the “Security” tab there should be a “VPC security groups” heading, click the url below it.
• Having clicked on the link you should now see some tabs that include “Inbound” and “Outbound”. Click inbound and add “MySQL/Aurora” for your local IP this makes a rule for port 3306.
• Also, to allow the EB instance to access the RDS DB you’ll need to add it’s security group. In the “source” field start typing “sg-” to get a list of all the available security groups and select the appropriate one then “save”.
• You can now edit the “.env” file with your RDS information and it should be able to connect locally and from your EB instance.
• Test out your new database by running the migration locally, if it works you can assume it should work from EB so update by making another zip with the updated files then “Upload and Deploy”.

Your AWS EB instance should now be able to chat with the database freely but you’re still updating with the zip files.

Deploying from GIT to your Elastic Beanstalk instance

Most of this comes from this url and this url…

• Update your .gitignore file then add everything you need from your project directory to the empty repo you set up on GitHub at the start. Once again, the vendor file should be missing along with any junk from your IDE.
• Install the latest version of Python 3.
• Run this command to make sure the default value of Python is the one you want: python3 --version . If it isn’t you’ll have to follow something like this url. NB: python and python3 are different, make sure to follow the advice from the url but use python3 instead of python.
• Once EB CLI is installed all you need to do is run eb init from your project directory to set up your GIT repo with EB. You’ll need to get an ID/secret from a user in IAM. Once you have created/clicked on the user you would go to “Security credentials” and create an access key. You’ll have to remember this info as you won’t be able to access the secret more than once.
• Next, with EB successfully initiated all there is left to do is deploy. So, commit your current working Laravel site (and push to GitHub if you like). EB will be using the current version you have committed to your current branch. To do this run the command eb deploy --staged

Believe it or not, that should have deployed to your instance. Huzzah!!

Troubleshooting

If the Ubuntu machine you are developing on is a new build or has not been used recently for development you’ll need to update and upgrade. When installing Laravel you’ll need to install all the PHP modules it needs (in my case it was “mbstring” and “dom”), you’ll also need to make sure “mysql-server” is installed locally.

Summary

This process is not too bad at all. There are different ways to update an EB instance, e.g. using AWS CodePipeline, but if you prefer Github over AWS’s CodeCommit this method is very straightforward to setup. Using this method on a Production website as I’ve described it here would mean testing locally then only deploying once the work was tested locally. You could also set up a dev server and deploy there first for further testing before deploying to the live website.