Running Symfony apps on AWS using Idealstack

One of the big benefits of Idealstack is that it lets you build apps using popular PHP frameworks such as Symfony and run them in a fully clustered, best practice AWS hosting environment with minimal code changes.

AWS is the perfect platform on which to host laravel apps as the Symfonyframework includes built-in support for a lot of AWS services, such as SQS, SES, S3, DynamoDB and more.

By running Symfony on top of the Idealstack platform, it will automatically be cluster-enabled across multiple servers for maximum reliability and performance.  You will also benefit from unlimited autoscaling and a 'best practice' AWS architecture (it doesn't just slap your app up on a single EC2 instance like other common hosting platforms would).  And you get all this without having to become an AWS expert or make any major changes to your code.  Read more about the features of Idealstack

Symfony runs great out of the box on idealstack, but here's a few notes about how best to configure it to take advantage of all the benefits of AWS

 

Sessions

Idealstack automatically configures PHP to use DynamoDB to store sessions.  This is the best solution to allow sessions to be shared between servers, enabling the fault-tolerant clustering that Idealstack provides.

To do this you need to use PHP native sessions in Symfony.  Luckily this is the default.  Just check that the handler_id is set to null in config/packages/framework.yaml

 

    # config/packages/framework.yaml
    framework:
        session:
            # enables the support of sessions in the app
            enabled: true
            # ID of the service used for session storage.
            # NULL =  means that PHP's default session mechanism is used
            handler_id: null

 

Email

Symfony uses swiftmailer for email.   By default it is usually configured to connect to port 25 and use SMTP for mail - instead you should use Sendmail.  Idealstack automatically configures a local sendmail provider that connects to AWS SES to send mail.   To use this in symfony set the mailer url to

    MAILER_URL=sendmail://my-domain.com

 

Other AWS services

There is a lot of scope to use other AWS services in symfony.  For instance you can use Redis/Memcached for caching using an Elasticache instance, or connect to S3 to store files

If you want to connect directly to AWS services, consider using the AWS Service Provider to integrate the AWS SDK into symfony

Storing files in S3

You can store uploaded files in local files, and this will work fine.  The files will be stored on an AWS EFS filesystem and shared amongst all of your instances automatically.

However there are some benefits to using S3 for storage instead

• S3 is considerably cheaper than EFS per gigabyte of storage - approximately 1/10th the price (although S3 also has charges based on how often the data is accessed)
• You can serve up links to data stored in S3 directly, diverting requests away from your website and allowing them to be cached and served by AWS's distributed global architecture
• S3 is usually the best service if you want to later ingest the uploaded data into other AWS services

There are a few options for using S3 in symfony.  Here's a few examples from online

• Using Flysystem 
• Using Vichuploader

 

Caching using Elasticache/Redis

Symfony's caching system supports Redis, and Redis will typically perform better than a database or file caching.  In AWS redis can be run as a fully-managed service using Elasticache.  To set one up create an elasticache instance in your own VPC and then use VPC-peering to connect it to Idealstack

Queues using SQS

Often you will have some code that needs to run, but need not be run immediately.  Moving this into a backend task makes response times for your users much faster.

You can integrate SQS for queues using third party packages for symfony, eg https://packagist.org/packages/tritran/sqs-queue-bundle

Testing using AWS codebuild

Symfony has very good built-in support for testing.  We use AWS Codebuild internally to automatically run our tests every time a developer makes a commit, and we'd recomend that you do the same.  Nothing makes a bigger difference to code quality that having good tests and running them automatically.

We've written an article in our blog that talks about how to setup Codebuild to build a PHP project