Learnings from Deploying API Platform to AWS using Elastic Beanstalk
Hello there 👋,
So you have your awesome Backend application built with Symfony & API Platform and you are looking to deploy it to AWS’s Elastic Beanstalk. Great, you are right where you need to be.
Just so you know, it is really straight forward. At the end of the day, what you are really doing is just deploying a Symfony PHP app. This is not a step-by-step guide, but rather just some specifics that are worth mentioning given my experiences in the past.
To begin with, you need to have your app prepared for deployment, be it a development or production environment you intend to deploy to. This will typically just entail switching .env variables or loading the correct .env file if you are taking full advantage of Symfony’s environment variable loading hierarchy. Once that is done, compress your project into a .zip file that you will later upload.
With that ready, you can then set up an RDS instance for your database and an elastic beanstalk environment to host your API source code. My general preference is to use 2 of them. One for development/UAT and the other for production (this entirely depends on you, the project, or your company though).
If you are finding difficulties with any of the above, please take a look at the resources I will drop at the end of the post. Like they say — no need to reinvent the wheel.
In doing the above, I love to keep my dev & prod environment as close as possible when it comes to configurations. But there are just some you can’t keep, like:
- Ec2 Instance size: I just feel it’s logical to use a smaller instance for dev and something more robust for prod. For example, t2 micro & t2 small.
- RDS instance size: What I said for ec2 also applies to database sizing. I also tend to add “Deletion protection” for production Databases.
- Elastic Load balancer: Here, I tend not to use one in development. In production having one is very useful, especially in conjunction with an auto-scaling group. This allows your app to dynamically manage the number of servers it runs on, based on the amount of traffic at a particular time.
If done correctly you should have your API up and running at a URL that is usually specified in the Elastic Beanstalk environment.
Points to consider
✔️The very first one is the fact that you should avoid creating your Database within your Elastic Beanstalk instance.
When setting up your Elastic Beanstalk environment, you have the possibility to set up your database at once. While this can be very tempting to go with, especially if you are a beginner, it can cost you more in the long run.
If you read on the topic, the most common reason you will find is the fact that if you delete the Elastic Beanstalk, your DB goes as well. While that’s true, there is another that is seldom spoken of. Which is …
If you create your RDS instance from elastic beanstalk, you might not be able to upgrade it in the future (I keep using that interchangeably with DB intentionally).
Nonetheless, if you do fall into the trap, there is a way out. You can still decouple your Database from Elastic Beanstalk using a Blue-Green deployment. More on that in the resources 😇
✔️The other point to consider is not really a point to consider. I will say it is more of a good-to-know. And this is the .ebextensions configuration file.
Remember, the point of using a PAAS — Platform as a service — offering is to avoid, if not eliminate the need to manage servers. As a PAAS solution, Elastic Beanstalk allows you to do some configurations on the server without having to log in to them or anything like that. To better explain I’ll give you an example.
By default, the PHP maximum upload size is 2MB. To change this, usually, you’ll need to access the php.ini file on the server. With elastic beanstalk, you can do this by just setting up an .ebextensions config file like this.
files:"/etc/php-7.2.d/project.ini" :mode: "000644"owner: rootgroup: rootcontent: |upload_max_filesize=64Mpost_max_size=64M
container_commands:01clearcache:command: "sudo php ./bin/console cache:clear"01var777:command: "sudo chmod -R 777 var"
You can do a lot of other cool stuff in there. In this sample from an API I manage, you can see that I run some commands to clear the cache and change folder permissions for the “var” folder after each deployment.
As promised - Resources
- AWS RDS MySQL Database Setup — https://www.youtube.com/watch?v=Ng_zi11N4_c
- Symfony app to Elastic Beanstalk — https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/php-symfony-tutorial.html
- Decouple RDS from Elastic Beanstalk — https://aws.amazon.com/premiumsupport/knowledge-center/decouple-rds-from-beanstalk/
- Environment customization with configuration files — https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/ebextensions.html
