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. . We’ll be doing this using Infrastructure-as-code and Configuration-as-code, for the process to be repeatable, shareable and documented. 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 A word about automating: The deeper we automate, the more standard our processes become. We will replace your stray scripts by universally understood technologies like Docker, , 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. automating is the only way we can grow your technical teams efficiently. Terraform The full source code we need to deploy Laravel on is publicly available on GitHub here: AWS _laravel-terraform - 1-click deployment of Laravel - without paying for an extra Saas_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 ├── master.tf # ├── terraform.tfvars # └── modules└── vpc # ├── vpc.tf└── outputs.tf└── ec2 ├── ec2.tf└── outputs.tf└── aurora _ # Aurora configuration_├── aurora.tf└── outputs.tf└── s3 ├── s3.tf└── outputs.tf└── cron └── artisan-schedule-run└── nginx ├── default.conf├── nginx.conf└── ssl ├── ssl.cert└── ssl.key├── php-fpm ├── Dockerfile ├── Dockerfile-nginx └── docker-compose.yml # our Terraform scripts entrypoint for Terraform (TF) TF input variables VPC configuration # EC2 configuration # S3 configuration # cron configuration for Docker # Nginx configuration # Nginx SSL certificates # PHP-FPM config # Dockerfile for Laravel containers # Dockerfile for Nginx container # 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 or present in the current directory. terraform.tfvars *.auto.tfvars 4. Build our infrastructure with Terraform Let’s check what Terraform is about to build for us in our AWS account with : terraform plan 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 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) ! 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. and make sure is enabled bucket versioning 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 . Here’s how it works: Workspaces Creating the exact same stack, in production 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 which creates using an existing VM/Host through SSH: Docker Machine Generic driver machines 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 , from which we can list running containers. eval "$(docker-machine env your_machine_name)" 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 , for artisan scheduled commands — our Laravel code in a worker container that will listen for Laravel Jobs from the Redis queue cron 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-nginx └── docker-compose.yml # Dockerfile for Laravel containers # Dockerfile for Nginx container # Docker Compose configuration … and the script to orchestrate them all is the file: docker-compose.yml Copy these files at the root of your project: mv Dockerfile Dockerfile-nginx docker-compose.yml .dockerignore .. Then create a file for our remote environment variables: docker-compose.env cp .env docker-compose.env Update the file with appropriate env vars: — with the output of — with the output of — with the output of — with the output of — , , with docker-compose.env DB_HOST terraform output aurora_endpoint DB_DATABASE terraform output aurora_db_name DB_USERNAME terraform output aurora_master_username DB_PASSWORD terraform output aurora_master_password CACHE_DRIVER SESSION_DRIVER QUEUE_DRIVER redis We’re now ready to build our images and run our containers: docker-compose up --build -d 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: Our Laravel project successfully connecting to Aurora …and that our web project is accessible on port 80: Laravel running in its Docker container on our Terraform-provisioned EC2 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 , where the Terraform state is effectively saved remotely on an S3 bucket for sharing. This is done by un-commenting the following lines in and run to migrate the state to the new backend: backend master.tf terraform init It is strongly recommended to activate versioning on your S3 bucket to be able to retrieve your Terraform state should you overwrite it accidentally! 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 so you don’t get a billing surprise at the end of the month. terraform destroy Lionel is Chief Technology Officer of London-based startup Wi5 and author of the Future-Proof Engineering Culture course . You can reach out to him on https://getlionel.com
