Skip to main content

Deploying Infrastructures Using Terraform on UpCloud

Image

Terraform is a tool to help us deploy infrastructures on any cloud provider such as AWS, GCP, DigitalOcean, and many more. Unlike Amazon CloudFormation which is specific only for AWS, Terraform supports many cloud providers found in Terraform's registry. It uses a domain-specific language built clearly for provisioning and configuring infrastructures named HCL or HashiCorp Configuration Language.

Meanwhile, UpCloud is an alternative cloud provider for SMEs. It targets a quite similar segment to DigialOcean and Linode. It provides a variety of popular solutions in the cloud such as managed Redis database, S3-compatible storage, private network, load balancer, and so on. Even though its cost is a little bit higher than DigitaOcean or others, it provides quite complete features on each service like the features of the load balancer that we will use in this post. Moreover, it actively publishes new features like the managed OpenSearch database published recently.

For instance, we will build an infrastructure to host a simple web server with an architecture like the following image. The server will be accessed by a domain name with an HTTPS connection.

Simple web server deployment on UpCloud

Several services that will be deployed include.

  • Private network and the router
  • Server to host the web service
  • Load balancer, including its backend and frontend rules
  • Dynamic certificate for HTTPS

First, we define some variables required for some resources. We store it in variable.tf. 

# basic variables

variable "upcloud_username" {
  description = "UpCloud username"
  type = string
}

variable "upcloud_password" {
  description = "UpCloud password"
  type = string
}

variable "upcloud_zone" {
  description = "UpCloud zone"
  type = string
  default = "sg-sin1"
}

# networking

variable "my_router_name" {
  description = "Basic network router name"
  type = string
  default = "basic-net-router"
}

variable "my_network_name" {
  description = "Basic private network name"
  type = string
  default = "basic-net"
}

variable "my_lb_name" {
  description = "Basic load balancer name"
  type = string
  default = "basic-lb"
}

# server

variable "server_hostname" {
  description = "Server hostname"
  type = string
  default = "terraform.lukinotes.com" # change to your domain
}

variable "server_port" {
  description = "Default web server port"
  type = number
  default = 8080
}

variable "server_private_ip" {
  description = "Manual private IP address for the server"
  type = string
  default = "10.0.0.10" # it means we will need a private network with subnet 10.0.0.0/24
}

Second, we create a configuration file, config.tf, to set up our provider which is UpCloud. 

terraform {
  required_providers {
    upcloud = {
      source  = "UpCloudLtd/upcloud"
      version = "~> 2.0"
    }
  }
}

Third, we define networking and server resources in main.tf file. We also need to prepare the public certificates of our devices because we will use public key authentication for remote accessing our server through SSH connection. Our server will be attached to a public network, private network, and utility network of our account. We enable daily backup for our server because it is free on UpCloud. 

provider "upcloud" {
  username = var.upcloud_username
  password = var.upcloud_password
}

# private network

resource "upcloud_router" "sample" {
  name = var.my_router_name
}

resource "upcloud_network" "sample" {
  name = var.my_network_name # required
  zone = var.upcloud_zone # required
  router = upcloud_router.sample.id

  ip_network { # required
    address            = "10.0.0.0/24" # required
    dhcp               = true # required
    dhcp_default_route = false # is the gateway the DHCP default route?
    family             = "IPv4" # required
    gateway            = "10.0.0.1"
  }
}

# basic server

resource "upcloud_server" "sample" {
  hostname = var.server_hostname
  zone     = var.upcloud_zone
  plan     = "1xCPU-2GB"

  template {
    storage = "Ubuntu Server 22.04 LTS (Jammy Jellyfish)"
    size    = 50
    filesystem_autoresize = true
    delete_autoresize_backup = true
  }

  simple_backup {
    plan = "daily"
    time = "1900"
  }

  network_interface {
    type = "public"
  }

  network_interface {
    type = "private"
    network = upcloud_network.sample.id
    ip_address_family = "IPv4"
    ip_address = var.server_private_ip
    source_ip_filtering = true
  }

  network_interface {
    type = "utility"
  }

  login {
    user = "root"
    create_password = false

    keys = [
      "ssh-rsa abcabc pc1",
      "ssh-rsa xyzxyz pc2"
    ]
  }

  metadata = true

  labels = {
    env    = "dev"
    owner  = "luki"
  }

  # sample provisioning
  user_data = <<-EOF 
     #!/bin/bash
     echo "Hello, World!" > index.html
     nohup busybox httpd -f -p ${var.server_port} &
     EOF
}

Next, we define the load balancer and its components including frontend, backend, and certificates. We store it in loadbalancer.tf file. 

resource "upcloud_loadbalancer" "sample" {
  configured_status = "started"
  name              = var.my_lb_name    # required
  plan              = "development"     # required
  zone              = var.upcloud_zone  # required

  # 0
  networks {
    name    = var.my_network_name # required
    type    = "private"   # required
    family  = "IPv4"      # required
    network = upcloud_network.sample.id
  }

  # 1
  networks {
    name   = "public-net"
    type   = "public"
    family = "IPv4"
  }
}

# BE

resource "upcloud_loadbalancer_backend" "sample" {
  loadbalancer = upcloud_loadbalancer.sample.id
  name         = "lb-be-sample"
}

## Attach our server as BE handler

resource "upcloud_loadbalancer_static_backend_member" "sample_1" {
  backend      = upcloud_loadbalancer_backend.sample.id
  name         = "lb-be-sample-1"
  ip           = upcloud_server.sample.network_interface[1].ip_address # private ip address
  port         = var.server_port
  weight       = 100
  max_sessions = 1000
  enabled      = true
}

# FE http

resource "upcloud_loadbalancer_frontend" "sample" {
  loadbalancer         = upcloud_loadbalancer.sample.id
  name                 = "lb-fe-sample"
  mode                 = "http"
  port                 = 80
  default_backend_name = upcloud_loadbalancer_backend.sample.name

  networks {
    name = upcloud_loadbalancer.sample.networks[1].name # public network
  }
}

## Redirect HTTP to HTTPS for default server

resource "upcloud_loadbalancer_frontend_rule" "sample_redirect_secure" {
  # required

  frontend = upcloud_loadbalancer_frontend.sample.id
  name = "redirect-https"
  priority = 60

  # optional

  actions {
    http_redirect {
      scheme = "https"
    }

    set_forwarded_headers {
      active = true
    }
  }

  matchers {
    header {
      name = "Host"
      method = "starts"
      value = var.server_hostname
      ignore_case = true
    }
  }
}

# FE https

resource "upcloud_loadbalancer_frontend" "sample_secure" {
  loadbalancer         = upcloud_loadbalancer.sample.id
  name                 = "lb-fe-sample-secure"
  mode                 = "http"
  port                 = 443
  default_backend_name = upcloud_loadbalancer_backend.sample.name

  networks {
    name = upcloud_loadbalancer.sample.networks[1].name # public network
  }
}

## Handle HTTPS request for default server

resource "upcloud_loadbalancer_frontend_rule" "sample_secure_serve" {
  # required

  frontend = upcloud_loadbalancer_frontend.sample_secure.id
  name = "serve-http-default"
  priority = 50

  # optional

  actions {
    use_backend {
      backend_name = upcloud_loadbalancer_backend.sample.name
    }

    set_forwarded_headers {
      active = true
    }
  }

  matchers {
    header {
      name = "Host"
      method = "starts"
      value = var.server_hostname
      ignore_case = true
    }
  }
}

# dynamic certs
resource "upcloud_loadbalancer_dynamic_certificate_bundle" "sample_dyn" {
  name = "sample-dyn"
  hostnames = [
    var.server_hostname
  ]
  key_type = "rsa"
}

# attach certificate
resource "upcloud_loadbalancer_frontend_tls_config" "sample_secure" {
  name               = "sample"
  frontend           = upcloud_loadbalancer_frontend.sample_secure.id
  certificate_bundle = upcloud_loadbalancer_dynamic_certificate_bundle.sample_dyn.id
}

Finally, we output some values that are necessary like the IP address and DNS name of the deployed load balancer. We need to add the load balancer address into the DNS record of our domain as a CNAME record. 

output "public_ip_address" {
  description = "Server IPv4 address"
  value = upcloud_server.sample.network_interface[0].ip_address
}

output "loadbalancer_networks" {
  description = "Public address of the load balancer"
  value = [ for item in upcloud_loadbalancer.sample.networks : { dns_name = item.dns_name, type = item.type, name = item.name } ]
}

Then, we can run the following commands. 

terraform init
terraform plan
terraform apply

Labels:

Comments

Post a Comment

Popular posts from this blog

Configuring Swap Memory on Ubuntu Using Ansible

If we maintain a Linux machine with a low memory capacity while we are required to run an application with high memory consumption, enabling swap memory is an option. Ansible can be utilized as a helper tool to automate the creation of swap memory. A swap file can be allocated in the available storage of the machine. The swap file then can be assigned as a swap memory. Firstly, we should prepare the inventory file. The following snippet is an example, you must provide your own configuration. [server] 192.168.1.2 [server:vars] ansible_user=root ansible_ssh_private_key_file=~/.ssh/id_rsa Secondly, we need to prepare the task file that contains not only the tasks but also some variables and connection information. For instance, we set /swapfile  as the name of our swap file. We also set the swap memory size to 2GB and the swappiness level to 60. - hosts: server become: true vars: swap_vars: size: 2G swappiness: 60 For simplicity, we only check the...
3 comments
Read more

Deliver SaaS According Twelve-Factor App

If you haven't heard of  the twelve-factor app , it gives us a recommendation or a methodology for developing SaaS or web apps structured into twelve items. The recommendation has some connections with microservice architecture and cloud-native environments which become more popular today. We can learn the details on its website . In this post, we will do a quick review of the twelve points. One Codebase Multiple Deployment We should maintain only one codebase for our application even though the application may be deployed into multiple environments like development, staging, and production. Having multiple codebases will lead to any kinds of complicated issues. Explicitly State Dependencies All the dependencies for running our application should be stated in the project itself. Many programming languages have a kind of file that maintains a list of the dependencies like package.json in Node.js. We should also be aware of the dependencies related to the pla...
2 comments
Read more

Rangkaian Sensor Infrared dengan Photo Dioda

Keunggulan photodioda dibandingkan LDR adalah photodioda lebih tidak rentan terhadap noise karena hanya menerima sinar infrared, sedangkan LDR menerima seluruh cahaya yang ada termasuk infrared. Rangkaian yang akan kita gunakan adalah seperti gambar di bawah ini. Pada saat intensitas Infrared yang diterima Photodiode besar maka tahanan Photodiode menjadi kecil, sedangkan jika intensitas Infrared yang diterima Photodiode kecil maka tahanan yang dimiliki photodiode besar. Jika  tahanan photodiode kecil  maka tegangan  V- akan kecil . Misal tahanan photodiode mengecil menjadi 10kOhm. Maka dengan teorema pembagi tegangan: V- = Rrx/(Rrx + R2) x Vcc V- = 10 / (10+10) x Vcc V- = (1/2) x 5 Volt V- = 2.5 Volt Sedangkan jika  tahanan photodiode besar  maka tegangan  V- akan besar  (mendekati nilai Vcc). Misal tahanan photodiode menjadi 150kOhm. Maka dengan teorema pembagi tegangan: V- = Rrx/(Rrx + R2) x Vcc V- = 150 / (1...
7 comments
Read more

API Gateway Using KrakenD

The increasing demands of users for high-quality web services create the need to integrate various technologies into our application. This will cause the code base to grow larger, making maintenance more difficult over time. A microservices approach offers a solution, where the application is built by combining multiple smaller services, each with a distinct function. For example, one service handles authentication, another manages business functions, another maintains file uploads, and so on. These services communicate and integrate through a common channel. On the client side, users don't need to understand how the application is built or how it functions internally. They simply send a request to a single endpoint, and processes like authentication, caching, or database querying happen seamlessly. This is where an API gateway is effective. It handles user requests and directs them to the appropriate handler. There are several tools available for building an API gateway, su...
Post a Comment
Read more

Deploying a Web Server on UpCloud using Terraform Modules

In my earlier post , I shared an example of deploying UpCloud infrastructure using Terraform from scratch. In this post, I want to share how to deploy the infrastructure using available Terraform modules to speed up the set-up process, especially for common use cases like preparing a web server. For instance, our need is to deploy a website with some conditions as follows. The website can be accessed through HTTPS. If the request is HTTP, it will be redirected to HTTPS. There are 2 domains, web1.yourdomain.com and web2.yourdomain.com . But, users should be redirected to "web2" if they are visiting "web1". There are 4 main modules that we need to set up the environment. Private network. It allows the load balancer to connect with the server and pass the traffic. Server. It is used to host the website. Load balancer. It includes backend and frontend configuration. Dynamic certificate. It is requ...
Post a Comment
Read more

Headless CMS for Building API Endpoints

Recently, someone introduced me to a tool called Directus, which is used for building backend systems and defining data structures. This also reminded me of a product I reviewed about two years ago, which was also built using Directus. After doing some online research, I decided to test another headless CMS solution called Strapi. When we think of CMS platforms, names like WordPress, Joomla, or Moodle might come to mind. But what does 'headless' mean in this context? A headless CMS is a type of CMS that focuses solely on the backend system, without providing the frontend interface. It can generate the API endpoints, letting developers build the frontend or client-side application separately. However, this doesn't mean headless CMS platforms lack a user interface entirely. Most, like Directus and Strapi, include a UI tool (an administrator dashboard) for designing and managing the backend system and resources. After spending some time testing and reviewing Stra...
Post a Comment
Read more