![](https://hackernoon.com/hn-images/1*4tNhLaNF_QMO2UBg5hoBUQ.jpeg)

Poe knows a fair bit about automating

There is a plethora of products who want to help us with running our application in the cloud. Unfortunately, none of them covers the entirety of what we need. Sometimes we need to bring our own server. Or they take care of hosting but we can’t access the underlying infrastructure.

So not only we pay for them, bet on closed-source software and there are handling only a fraction of what we need.

**I’m sharing a full Terraform and Docker configuration that lets you provision AWS and deploy Laravel / Nginx / MySQL / Redis / ElasticSearch from scratch, in a few commands**. We’ll be doing this using Infrastructure-as-code and Configuration-as-code, for the process to be repeatable, shareable and documented.

> A word about automating: **automating is the only way we can grow your technical teams efficiently.** The deeper we automate, the more standard our processes become. We will replace your stray scripts by universally understood technologies like Docker, [Terraform](https://hackernoon.com/tagged/terraform), Kubernetes, Consul etc and their design patterns. We can build and handover them to a new developer quickly. We can forget about them and get back to it months later with no brain freeze.

The full source code we need to deploy Laravel on [AWS](https://hackernoon.com/tagged/aws) is publicly available on GitHub here:

[**li0nel/laravel-terraform**  
_laravel-terraform - 1-click deployment of Laravel - without paying for an extra Saas_github.com](https://github.com/li0nel/laravel-terraform "https://github.com/li0nel/laravel-terraform")[](https://github.com/li0nel/laravel-terraform)

Ready? Let’s start!

_This is a procedure I use to deploy my clients’ Laravel applications on AWS. I hope this can be helpful to deploy yours. If your use case is more complex, I provide on-going support packages ranging from mentoring your developers up to hands-on building your application on AWS. Ping me at hi@getlionel.com_

#### 1\. Clone the deployment scripts

We start by downloading the Terraform and Docker scripts we need to deploy Laravel. From our Laravel root directory:

`git clone git@github.com:li0nel/laravel-terraform deploy`

This will create a deploy directory at the root of our Laravel installation. For now, we’re going to use the Terraform scripts from that directory to create our infrastructure.

├── deploy  
  └── terraform                 _\# our Terraform scripts_  
    ├── master.tf               # _entrypoint for Terraform (TF)_  
    ├── terraform.tfvars        # _TF input variables_  
    └── modules  
      └── vpc                   # _VPC configuration_  
        ├── vpc.tf  
        └── outputs.tf  
      └── ec2                   _\# EC2 configuration_  
        ├── ec2.tf  
        └── outputs.tf  
      └── aurora      _          # Aurora configuration_  
        ├── aurora.tf  
        └── outputs.tf  
      └── s3                    _\# S3 configuration_  
        ├── s3.tf  
        └── outputs.tf  
  └── cron                      _\# cron configuration for Docker_  
    └── artisan-schedule-run  
  └── nginx                     _\# Nginx configuration_  
    ├── default.conf  
    ├── nginx.conf  
    └── ssl                     _\# Nginx SSL certificates_  
      ├── ssl.cert  
      └── ssl.key  
  ├── php-fpm                   _\# PHP-FPM config_  ├── Dockerfile                _\# Dockerfile for Laravel containers_  ├── Dockerfile-nginx          _\# Dockerfile for Nginx container_  └── docker-compose.yml        _\# Docker Compose configuration_

#### 2\. Configure our AWS command line

We start with authenticating our command line by downloading the API key and secret for a new user in the IAM section of our AWS console. This user will need to have to have permissions to create resources for all the services we will use below. Follow the prompts from:

`aws configure`

#### 3\. Update Terraform input variables

Terraform automatically loads input variables from any `terraform.tfvars` or `*.auto.tfvars` present in the current directory.

#### 4\. Build our infrastructure with Terraform

Let’s check what Terraform is about to build for us in our AWS account with `terraform plan` :

![](https://hackernoon.com/hn-images/1*LlnxHmkfGsLwhx1r-QR5eQ.png)

These are the 33 infrastructure parts needed to deploy Laravel on AWS. It would easily be ~60 of them once we include monitoring alerts, database replicas and an auto-scaling group.

Can you see how risky and painful it would be to set that up manually in the AWS console for every new project?

The command to execute the setup is `terraform apply plan.tf`

![](https://hackernoon.com/hn-images/1*uzMehecxTTTDWPwg4BbkRg.png)

Terraform created our infrastructure in less than 8 minutes

Terraform can not only make us extremely efficient, but is also a real pleasure to write infrastructure with. Look at an example of its syntax:

2 things to remember when using Terraform:  
 — We tag every resource we can with our project name, to identify them in the AWS console  
 — We will setup Terraform to store our state file on S3 (more info in step 7 below) **and make sure _bucket versioning_ is enabled**! If we don’t, and accidentally overwrite our state file, Terraform would have stopped tracking our stack and we need to go and manually delete everything in the console.

#### 4\. (Optional) Cloning our stack

A great feature of Terraform is that it can not only keep track of our infrastructure, but also different versions of it (i.e. test, staging, production).

Think of it like Git Branches. Terraform calls its versions [Workspaces](https://www.terraform.io/docs/state/workspaces.html). Here’s how it works:

![](https://hackernoon.com/hn-images/1*qBwu4-JCSJFW0H_hZI4DIQ.png)

Creating the exact same stack, in production

![](https://hackernoon.com/hn-images/1*-6DlhgOcwLcGiPJFOb2Zhg.png)

Switching back to our initial workspace

#### 5\. Install Docker on our EC2 instance using Docker Machine

Docker Machine is the single easiest way to provision a new Docker host or _machine_.

— it’s blazing fast  
 — the command line is dead simple  
 — it manages all of the SSH keys and TLS certificates even if we have dozens of servers  
 — makes our servers immediately ready for Docker deployments

Since we’ve already created an EC2 instance with Terraform, we then use the [Docker Machine Generic driver](https://docs.docker.com/machine/drivers/generic/) which creates _machines_ using an existing VM/Host through SSH:

    docker-machine create \  --driver generic \  --generic-ip-address=$(terraform output ec2_ip) \  --generic-ssh-key $(terraform output ssh_key_path) \  

Docker Machine will connect to the remote server through SSH, install the Docker daemon and generate TLS certificates to secure the Docker daemon port.  
We can then connect at any point to our machine using `eval "$(docker-machine env your_machine_name)"` , from which we can list running containers.

![](https://hackernoon.com/hn-images/1*3YJVSYjWQyS422ENpIxwcQ.png)

Provisioning our existing EC2 instance with the Docker daemon with Docker Machine

#### 6\. Build and deploy the Docker images with Docker Compose

Great, we’re half-way through! We have a fully provisioned infrastructure we can now deploy our Laravel stack on. We’ll be deploying the following Docker containers:

— our Laravel code in a PHP-FPM container  
 — Nginx as a reverse proxy to PHP-FPM  
 — (optional) Redis as a cache and queue engine to Laravel  
 — (optional) ElasticSearch for our application search engine  
 — our Laravel code in a container running _cron_, for artisan scheduled commands  
 — our Laravel code in a worker container that will listen for Laravel Jobs from the Redis queue

Just like we don’t want to manage all our infrastructure’s moving parts manually, there is NO WAY we will manage all of this configuration and orchestration manually.

Docker Compose to the rescue!

The configuration for all the above containers is committed into the _Dockerfiles:_

└── deploy  
  ├── Dockerfile                _\# Dockerfile for Laravel containers_  ├── Dockerfile-nginx          _\# Dockerfile for Nginx container_  └── docker-compose.yml        _\# Docker Compose configuration_

… and the script to orchestrate them all is the `docker-compose.yml` file:

Copy these files at the root of your project:  
`mv Dockerfile Dockerfile-nginx docker-compose.yml .dockerignore ..`

Then create a `docker-compose.env` file for our remote environment variables:  
`cp .env docker-compose.env`

Update the `docker-compose.env` file with appropriate env vars:  
 — `DB_HOST` with the output of `terraform output aurora_endpoint`   
 — `DB_DATABASE` with the output of `terraform output aurora_db_name`   
 — `DB_USERNAME` with the output of `terraform output aurora_master_username   ` — `DB_PASSWORD` with the output of `terraform output aurora_master_password   ` — `CACHE_DRIVER`, `SESSION_DRIVER`, `QUEUE_DRIVER` with `redis`

We’re now ready to build our images and run our containers:  
`docker-compose up --build -d`

![](https://hackernoon.com/hn-images/1*J_WsENJQuGwjQ1RVv94J8w.png)

Building and running all containers at once

Let’s confirm that our Laravel code is correctly configured with the right database connection details, by running the default database migrations:

![](https://hackernoon.com/hn-images/1*TWDMxi86068ctouxAO9H9Q.png)

Our Laravel project successfully connecting to Aurora

…and that our web project is accessible on port 80:

![](https://hackernoon.com/hn-images/1*Zc5qEJFN_forboqQkcMj6A.png)

Laravel running in its Docker container on our Terraform-provisioned EC2

![](https://hackernoon.com/hn-images/1*2CAx_CiSJCIkIUl3qdT9zg.png)

Each container’s log stream is centralised in our CloudWatch console

#### **7\. (Optional) Share access with teammates**

Amazing! We can now re-deploy your Laravel code at will, modify our infrastructure and configuration while keeping track of all changes in your code.

Teammates can access all the Docker configuration and the Terraform files by pulling our code from our source code repository. However, at this stage, they can not:  
 — modify the infrastructure or access Terraform outputs because they can’t access Terraform’s state file that is saved locally on our machine  
 — connect their Docker client to our EC2 instance because they haven’t installed a Docker Machine pointing to that EC2 like we have

The solution to the first point is to get Terraform to use the S3 remote _backend_, where the Terraform state is effectively saved remotely on an S3 bucket for sharing. This is done by un-commenting the following lines in `master.tf` and run `terraform init` to migrate the state to the new backend:

_It is strongly recommended to activate versioning on your S3 bucket to be able to retrieve your Terraform state should you overwrite it accidentally!_

![](https://hackernoon.com/hn-images/1*LWUsdClEEq5vjLzmxqpICw.png)

Migrating Terraform’s state to S3 for security and collaboration

Now, provided our colleagues use AWS credentials allowing access to our S3 bucket, they will connect to the same Terraform backend as we do, and we can work on the stack at the same time with no risk.

#### 8\. (Optional) Destroy and re-create your stack at will

Congrats for making it that far in this guide! Once you’re done, clean up your infrastructure using `terraform destroy` so you don’t get a billing surprise at the end of the month.

![](https://upscri.be/media/form.jpg)

_Lionel is Chief Technology Officer of London-based startup Wi5 and author of the_ [_Future-Proof Engineering Culture course_](https://hackernoon.com/why-the-platform-model-is-broken-a51478b1b4ee)_. You can reach out to him on_ [_https://getlionel.com_](https://getlionel.com)

Read My Stories

Too Long; Didn't Read

Get hands-on learning from ML experts on Coursera 

Stop manually provisioning AWS for Laravel — use Terraform instead

Too Long; Didn't Read

Company Mentioned

@getlionel

RELATED STORIES