Use MinIO as a Backend for Terraform Remote State

Overview

Hello there DevOps and IaC enthusiast. In this article we will introduce MinIO, an interesting piece of software that can be self-hosted and help us solve a problem managing the Terraform remote state on the on-premises environemnts(Bare metal servers and data centers). And that’s our goal essentially - to use MinIO as a backend for Terraform remote state. My best use case for this setup is to utilizite it for hypervisor softwares(VMware, Proxmox), on prem kubernetes, docker too and so on.

Why use it?

As Terraform has evolved, its support has expanded to include on-premise hypervisors like VMware and Proxmox, making it a robust Infrastructure as Code (IaC) tool not just for cloud environments but also for data center management. While this is a significant advantage for DevOps teams working in hybrid environments, it introduces a notable challenge: remote state management.

Anyone who worked with Terraform has encountered at least once the horror of managing the state file. Especially those who work in either hybrid infrastructure environment or strictly with on-prem infrastructure. For these cases managing terraform state file is one of the biggest challenge you can get.

In cloud-based solutions, Terraform state management is often streamlined with remote state backends like AWS S3, Azure Blob Storage, or HashiCorp’s Terraform Cloud. However, for on-premises use cases where you need data locality or prefer not to use external cloud services, setting up a reliable, remote state backend becomes crucial for seamless team collaboration and consistency. This is where MinIO, an open-source object storage solution, comes into play. Not only it will manage the state files for us, it will also enable and enhance team collaboration for on-prem infrastructure.

Why MinIO for Terraform State Management?

MinIO is a lightweight, highly scalable object storage solution that can be deployed on-premise, has in built security features and is open source. It is S3-compatible, making it a great choice for teams looking to store their Terraform state files securely and collaboratively within their own infrastructure.

Advantages of Using MinIO for Terraform State Management:

• S3 Compatibility: Works seamlessly with Terraform’s S3 backend configuration.
• Scalability: Scales horizontally to meet large storage demands.
• Security: Allows you to implement your own security measures, ensuring sensitive data stays within your infrastructure.
• High Availability: Can be configured for redundancy and high availability to keep state data consistently accessible.
• Has Docker image: Apart from having available binary version for Linux, MacOS and Windows, it also has containerized version that can be deployed on Docker and Kubernetes.

Minio setup and Terraform prerequsites

Before using MinIO with Terraform, there are a couple of prerequisites to set up on:

1. Bucket for terraform state file Similary like in other Cloud platforms, we need to create the bucket where we plan to store our state file.

2. Access and secret keys The keys are needed for terraform to authenticate and to gain write and read access.

Instructions to set up MinIO for Terraform State Management

For this example, i run MinIO on Docker as a single instance(single docker container) but pretty much the process applies to other MinIO versions.

Esentially in order to make Terraform work with MinIO, we only need to focus on the terraform backend module and edit the backend module accordingly like in the example bellow. I ussually preffer to have it as a separate .tf file.

terraform {
  backend "s3" {
    bucket = "tf-remote-state"

    endpoints = {
      s3 = "http://192.168.124.209:9000"
    }

    access_key = "access-key-string-goes-here"
    secret_key = "secret-key-string-goes-here"

    key                         = "proxmox-vms/terraform-provision.tfstate"
    region                      = "main"
    skip_requesting_account_id  = true
    skip_credentials_validation = true
    skip_metadata_api_check     = true
    skip_region_validation      = true
    use_path_style              = true
  }
}

End result example once you do terraform plan and terraform apply

The key point here is to have the S3 endpoint on MinIO exposed, enable the write access via access keys and that’s pretty much it.

Let’s breakdown the S3 backend options we used here:

• bucket; the actual bucket located in the minio. The bucket must initially exist or you need to create a new bucket.
• endpoints s3; this is the actual address of MinIO, where it’s hosted. You can define the endpoint in either IP address or a domain name.
• access_key, secret_key; these are the access keys that are needed for terraform to gain permissions to write on bucket. The keys must be created in MinIO prior to this. key; the state file itself. You can add the directory if you wish for your state file(if you plan to have more). region; here MinIO is actually asking the region of one of the cloud providers in the same code format the cloud platforms are using(ie us-east1). So i opted for the alternative and parsed in the “main”; as the region and it works.
• skip_requesting_account_id, skip_credentials_validation, skip_metadata_api_check, skip_region_validation, use_path_style; MinIO also runs background checks(those are it’s native features and mechanisms) and by default those checks are unabled and for the on-prem setup the terraform won’t work with minio and for that reason those need to be disabled.

Summary

So what we learned with this? That we can use MinIO as a backend for Terraform remote state for our on-prem infrastructure and with that we have remote management of the state file. It may not look special but MinIO overall is an impressive piece of software, a great piece of tool that you can add to your toolkit that solves one of the DevOps problems. Integrating MinIO in our IaC workflow, not only we offset the management of state file, we also enable team colaboration.

I thank you for your time and attention. Take care!