Skip to content

Latest commit

 

History

History
117 lines (80 loc) · 5.03 KB

README.md

File metadata and controls

117 lines (80 loc) · 5.03 KB

Terraform

Serverless booking software

Cloud-Native Serverless application developed with Hashicorp Terraform and Serverless Framework.

Introduction

The main purpose of this small event-driven project is to show how to use Terraform to provision immutable Cloud-Native infrastructure, along with the Serverless Framework.

Infrastructure as Code (IaC) 👷🏻

Terraform is an open-source Infrastructure as Code tool to manage cloud resources. It was mainly used to provision the core infrastructure at AWS, which was the chosen cloud provider.

Resources

These are the main infrastructure resources provisioned by Terraform to create a fully event-driven serverless architecture:

  • DynamoDB
    • Tables
    • Indexes
    • Streams
  • IAM
    • Roles
    • Policies
  • SNS topics
  • SQS
    • Queues
    • DQLs
  • Systems Manager
    • Parameter Store: this service is the key-point to make it possible to Serverless and Terraform communicate to each other. All the resources names and ARNs (IAM roles, policies, queues, tables, etc.) are exported to the Parameter Store as key-values by Terraform. Then, it is possible to access these keys via Serverless Framework and referecence IAM role statements or create environment variables for each Lambda function.

Serverless ☁️

It is also possible to provision the resources mentioned previously with the Serverless Framework, however, in this project, I chose to separate responsabilities and only Terraform is used to manage infrastructure.

Therefore, the main usage of Serverless in this project is to create the API gateway endpoints and Lambda functions triggered by API Gateway's events.

Endpoints

The API is really simple and has only four endpoints:

  • POST/users: register a new user.
  • POST/login: user authentication (returns a JWT token).
  • POST/bookings: register a new booking.
  • GET/bookings: list all the bookings (restricted to ADMIN users).

Click on the button below and import the Insomnia workspace to do the API requests after the deployment step:

Run in Insomnia}

Deploy

Prerequisites

First of all, you need an AWS account and create a user with programmatic admin access. Then, configure the AWS CLI on your workstation.

Once you're done, clone this repository and move yourself to the root directory.

Environment variables

The API depends on two external services to send e-mails and SMSs when a new booking is registed in the DynamoDB table. Create accounts on each of them:


The last thing before the deployment is to define your environment variables of the dev stage.

# Move to the Terraform development directory
cd terraform/environments/dev

# Open the file that contains the environment variables and update the values
nano secrets.auto.tfvars

In order to keep things simple, I recommend only changing the following keys:

  • email_from: use the e-mail you created at Zoho (the one containing the domain @zohomail.com)
  • email_from_password: your password from Zoho
  • email_to: create a temporary e-mail box at TempMail (leave the window opened while you're testing)
  • message_bird_api_key: your test API Key from Messagebird (No SMSs will be sent with this key. Use the production one if you want to receive them.)
  • sms_phone_from: your cellphone number (e.g: "+55119...")
  • sms_phone_to: your cellphone number (e.g: "+55119...")

Deploy

Luckly, now you just need to run a single command and Terraform will do the magic for you 😛

# Run the command bellow to avoid lack of permission to run the deploy shell script
chmod u=rwx,g=r,o=r deploy.sh

# Deploy everything to a development stage at AWS
./deploy.sh dev

You're supposed to see 53 resources created by Terraform, that is, all the resources I mentioned in previous sections (IAM roles, tables, queues, etc).


In the other hand, the Serverless Framework will create the dev-api and 8 Lambda functions.

Destroy

Now that you've tested everything, feel free to delete all the resources at AWS. It's as simple as the deployment script:

# Run the command bellow to avoid lack of permission to run the destroy shell script
chmod u=rwx,g=r,o=r deploy.sh

# Remove everything from the development stage at AWS
./destroy.sh dev