Forem: Gonçalo Rodrigues

Deploying a simple portable Web App in any cloud using Terraform and Multy

Gonçalo Rodrigues — Mon, 05 Sep 2022 12:03:28 +0000

Introduction

In this tutorial, we'll deploy a simple web app to the cloud of your choice - composed of a database and a virtual machine where the frontend code will run.
So that the configuration is reusable and consistent, we'll write it in Terraform.

Usually Terraform configurations are cloud-specific, and changing clouds requires a complete rewrite. In this case, so that you can reuse the same configuration across clouds, we'll be using Multy.

In-depth knowledge of Terraform and Multy is not needed to follow this tutorial. If you want to learn more about these tools, check out the Multy documentation and the Terraform documentation.

Architecture

This web app will contain the following components:

Networking - a virtual network that can be accessed from the internet with the appropriate security group
Database - a managed MySQL database where data will be stored
Virtual machine - a server configured to serve a simple notes app that stores and retrieves data from the database

Initializing Terraform

First, initialize Terraform.
Here we'll set up the Multy provider and pass along any needed credentials.
Note that a Multy API key is needed - you can get it for free at https://multy.dev/#beta.

Additionally, we'll declare 2 variables, cloud and location, that make it easy to redeploy the web app in different clouds and locations. You'll need to generate some cloud credentials if you don't have them already - check out the Getting Started guide.

To set up the providers, open a providers.tf file with the following content:

terraform {
  required_providers {
    multy = {
      source = "multycloud/multy"
    }
  }
}
provider "multy" {
  api_key = "xxx"
  aws     = {}
}
variable "cloud" {
  type    = string
  default = "aws"
}
variable "location" {
  type    = string
  default = "eu_west_1"
}

After, run the following command in the same folder:

terraform init

This command will download the Multy provider and initialize everything Terraform needs into a .terraform folder.

Configuring networking

In order for the web app to be accessible from outside the cloud, we'll need to create a virtual network with the appropriate route table.

We need:

A virtual network and a subnet
A security group that opens up port 22 (for SSH access) and port 4000 (so that the website is accessible) as well as HTTP and HTTPS access to download the code and linux packages
A route table that routes all traffic to the Internet

While this is quite different in each cloud, with Multy we can describe it in a cloud-agnostic manner:

resource "multy_virtual_network" "vn" {
  cloud      = var.cloud
  location   = var.location
  name       = "multy-vm"
  cidr_block = "10.0.0.0/16"
}
resource "multy_subnet" "subnet" {
  name               = "multy-subnet"
  cidr_block         = "10.0.10.0/24"
  virtual_network_id = multy_virtual_network.vn.id
}
resource "multy_network_security_group" "nsg" {
  cloud              = var.cloud
  location           = var.location

  name               = "multy_nsg"
  virtual_network_id = multy_virtual_network.vn.id
  rule {
    protocol   = "tcp"
    priority   = 133
    from_port  = 443
    to_port    = 443
    cidr_block = "0.0.0.0/0"
    direction  = "egress"
  }
  rule {
    protocol   = "tcp"
    priority   = 131
    from_port  = 80
    to_port    = 80
    cidr_block = "0.0.0.0/0"
    direction  = "egress"
  }
  rule {
    protocol   = "tcp"
    priority   = 132
    from_port  = 4000
    to_port    = 4000
    cidr_block = "0.0.0.0/0"
    direction  = "ingress"
  }
  rule {
    protocol   = "tcp"
    priority   = 130
    from_port  = 22
    to_port    = 22
    cidr_block = "0.0.0.0/0"
    direction  = "ingress"
  }
}
resource "multy_route_table" "rt" {
  name               = "multy-rt"
  virtual_network_id = multy_virtual_network.vn.id
  route {
    cidr_block  = "0.0.0.0/0"
    destination = "internet"
  }
}
resource "multy_route_table_association" "rta" {
  route_table_id = multy_route_table.rt.id
  subnet_id      = multy_subnet.subnet.id
}

Configuring database

Next up, we need to configure our database. We want a small MySQL database with a random password in the same location where we placed our virtual network.

resource "random_password" "password" {
  length = 16
  override_special = "!#"
  special = true
}
resource "multy_database" "db" {
  cloud          = var.cloud
  location       = var.location

  storage_gb     = 10
  name           = "multydb"
  engine         = "mysql"
  engine_version = "5.7"
  username       = "multyadmin"
  password       = random_password.password.result
  size           = "micro"
  subnet_id      = multy_subnet.subnet.id
  depends_on = [multy_route_table_association.rta]
}

Configuring a virtual machine

Finally, we need to configure the server. For this demo, we'll use the smallest server we can use. To initialize it, we'll make use of user data, a script that is executed by cloud-init when the virtual machine first boots.

resource "multy_virtual_machine" "vm" {
  cloud          = var.cloud
  location       = var.location

  name               = "web_app_vm"
  size               = "general_micro"
  image_reference    = {
    os      = "ubuntu"
    version = "18.04"
  }
  subnet_id          = multy_subnet.subnet.id
  generate_public_ip = true
  user_data_base64   = base64encode(local.init_script)
  # uncomment this line to allow ssh access
  # public_ssh_key = file("~/.ssh/id_rsa.pub")

  network_security_group_ids = [multy_network_security_group.nsg.id]
}
locals {
  init_script = <<EOT
#!/bin/bash -xe
sudo apt-get update -y && sudo apt-get -y install git npm mysql-client curl jq
curl -fsSL https://deb.nodesource.com/setup_16.x | sudo -E bash -
sudo apt-get install -y nodejs
sudo chmod a+rwx .
# putting secrets into user data is not best practice, you can use multy_vault instead
export DATABASE_HOST=${multy_database.db.hostname}
export DATABASE_USER=${multy_database.db.connection_username}
export DATABASE_PASSWORD='${multy_database.db.password}'
git clone https://github.com/FaztTech/nodejs-mysql-links.git
cd nodejs-mysql-links
mysql -h $DATABASE_HOST -P 3306 -u $DATABASE_USER --password=$DATABASE_PASSWORD -e 'source database/db.sql' || true
npm i && npm run build && npm start
EOT
}
output "endpoint" {
  value = "http://${multy_virtual_machine.vm.public_ip}:4000"
}

Deploying

After you have everything written, you can deploy the resources using Terraform. Run the following command, using the cloud and location you prefer:

terraform apply -var="cloud=aws" -var="location=eu_west_1"

After a few minutes, you should see an endpoint where you can access the example app!

Summary

Terraform is a very powerful tool that makes deployments repeatable using a single unified language (HCL) for any cloud. However, clouds are quite different from each other which means Terraform files look very different from cloud to cloud. In this tutorial we looked at an example on how to leverage Multy to make deployments portable across multiple cloud providers - by just changing a single cloud parameter. If you want to explore other examples further, take a look at Multy examples.

Using Go Generics for cleaner code

Gonçalo Rodrigues — Thu, 14 Jul 2022 11:11:00 +0000

Go has been surviving for years without generics. The latest major version update (Go 1.18) finally introduced them and I think they're amazing at making Go code look much cleaner! Here are some examples where I found it useful:

1 - Unmarshaling JSON strings

One of the examples that everyone has seen before in Go is unmarshaling a JSON string into a Go struct:

str := `{"page": 1, "fruits": ["apple", "peach"]}`
res := response{}
err := json.Unmarshal([]byte(str), &res)

What I don't like about this example is that you have to pass an output parameter as input (&res). Go supports multiple output parameters so we should never have to do this.

With generics, you can implement a function that instead initializes the right type and returns it:

func unmarshal[T any](data []byte) (*T, error) {
    out := new(T)
    if err := json.Unmarshal(data, out); err != nil {
        return nil, err
    }
    return out, nil
}
str := `{"page": 1, "fruits": ["apple", "peach"]}`
res, err := unmarshal[response]([]byte(str))

2 - Type safe containers

In go, if you want to implement a linked list without generics, it would look something like this:

type Node struct {
    prev  *Node
    next  *Node
    value interface{}
}

type List struct {
    head *Node
    tail *Node
}

It's not type safe! It uses interface{} and will require casts all over the code.
Or you can also implement a very specific LinkedList for integers, or for strings, but not one that can work for any type.

With generics, you can have an abstract LinkedList that works for any type and it's still type safe:

type Node[T any] struct {
    prev  *Node[T]
    next  *Node[T]
    value T
}

type List[T any] struct {
    head *Node[T]
    tail *Node[T]
}

3 - Slice utilities

One of the most frustrating things in Go is to iterate over a slice to perform a basic operation. For example, if you want to check if a certain string is in slice of strings, this is how you do it:

func contains(strings []string, s string) bool {
    for _, s := range strings {
    if s == string {
        return true
    }
    return false
}

exists := contains([]string{"a", "b"}, "a")

However, it only works for strings! If you want to do the same thing with integers, or structs, you have to reimplement this logic everywhere.

With generics, the standard lib introduces a much needed utility that works with any slice of comparable types:

exists := slices.Contains([]string{"a", "b"}, "a")

Conclusion

I love Go. We use it a lot at Multy. I think generics were one of the missing pieces to make it a really good language, but they are controversial in the Go community. What is your opinion on them?

AWS vs Azure vs GCP

Gonçalo Rodrigues — Tue, 12 Jul 2022 08:26:53 +0000

Nowadays all clouds have similar offerings. AWS is the more mature one - and therefore a solid choice. However, they are hard to work with in many aspects and have a lot of legacy choices - such as everything being region locked. Google cloud is often seen as the most developer friendly and a great choice if you don't want spend hours banging your head against the wall. Azure also offers great developer experience but it's less reliable in my experience.

Since we work very closely with the 3 major clouds to develop our product - Multy - I have written a blog post on what I have learned about the differences in Virtual Machines in AWS, Azure and GCP.

The blog post goes over:

Regions and availability zones
Virtual machine types and sizes
SSH access and default users
Virtual machine images
Block storage and disk

If you're interested, have a read at https://docs.multy.dev/blog/compute-aws-vs-azure-vs-gcp.

Which cloud provider do you prefer?