This commit is contained in:
decentral1se 2022-03-15 14:12:04 +01:00
commit 8bf2179f53
No known key found for this signature in database
GPG Key ID: 03789458B3D0C410
5 changed files with 110 additions and 0 deletions

.gitignore vendored Normal file
View File

@ -0,0 +1,2 @@

.terraform.lock.hcl Normal file
View File

@ -0,0 +1,24 @@
# This file is maintained automatically by "terraform init".
# Manual edits may be lost in future updates.
provider "" {
version = "1.31.1"
constraints = "1.31.1"
hashes = [

42 Normal file
View File

@ -0,0 +1,42 @@
# terraform-tester
Testing out a potential infra tooling switch. For infra circle hackers.
Terraform is really good for creating infrastructure, not configuring it.
However, it allows some hooks to run bash scripts and the like. It's wayyyy
easier to setup than Ansible.
## setup
Install Terraform:
sudo apt-get update && sudo apt-get install -y gnupg software-properties-common curl
curl -fsSL | sudo apt-key add -
sudo apt-add-repository "deb [arch=amd64] $(lsb_release -cs) main"
sudo apt-get update && sudo apt-get install terraform
## test
$ terraform init
$ terraform apply
$ terraform destroy
## files / commands
- **init**: downloads dependencies, stores them in `.terraform` (downloads hetzner plugin)
- **apply**: generates a plan of what it will do, asks, then does it (creates the hetzner server)
- **destroy**: reads the `.tfstate` files & reverses the state (destroys the hetzner server)
- ****: the file that `terraform` reads to implement stuff
- **.terraform.lock.hcl**: state file that makes us all get the same results for `terraform init`
- **user_data.yml**: a `cloud-init` script which runs when the new hetzner VPS is created, provisioning commands!
## notes
- `*.tf` files are rough equivalent of ansible roles. once you run `terraform apply` it generates a state file. the next time someone runs `terraform apply`, the state file is read, `terraform plan` then automatically knows what servers are created, destroyed, etc. instead of having an inventory listing like we have for ansible, we have the actual `.tf` files & the state files (e.g. [this](
- we can wire up minio as a "backend" (see [this]( so that `terraform apply` will store the state files it generates there.
- unsure how to test but there is [this]( i'd rather skip all the testing work, it somehow is not really worth it at our scale? i think tool usability is more important for us. can people using it understand what it is doing? then they'll probably be able to fix things.

29 Normal file
View File

@ -0,0 +1,29 @@
terraform {
required_providers {
hcloud = {
source = "hetznercloud/hcloud"
version = "1.31.1"
variable "hcloud_token" {}
provider "hcloud" {
token = var.hcloud_token
resource "hcloud_server" "web" {
name = "terraform-test"
image = "debian-10"
server_type = "cx11"
ssh_keys = [
user_data = file("user_data.yml")
output "ipv4_addresses" {
value = hcloud_server.web.ipv4_address
description = "The ipv4 address of your new Hetzner Cloud VPS"

user_data.yml Normal file
View File

@ -0,0 +1,13 @@
package_update: true
package_upgrade: true
- htop
- ctop
- ncdu
- path: /etc/docker/daemon.json
content: |
{ "log-driver": "journald" }
- curl -fsSL | bash