Первые шаги с OpenTofu

Из-за недавней смены лицензии Terraform возникла неопределенность с его дальнейшей судьбой в коммерческих проектах. В качестве ответа был создан форк OpenTofu, который будет развиваться под эгидой Linux Foundation и я попробовал оценить готовность OpenTofu с точки зрения drop-in replacement для Terraform.

Насколько мне известно, OpenTofu был форкнут с Terraform 1.5.5 (последняя версия под лицензией MPL) и никакой разницы с Terraform 1.5.x быть не должно. Я тестировал два последних релиза OpenTofu (1.6.0-alpha2 и 1.6.0-alpha3) и на первый взгляд достаточно создать алиас terraform на tofu чтобы все просто заработало, но всплыли нюансы.

HashiCorp сменил лицензию своих продуктов с MPL на BSL

Новость про смену лицензии появилась еще на прошлой неделе, но только сегодня дошли руки разобрать ленту и расстроиться. Из важного я вижу два абзаца:

End users can continue to copy, modify, and redistribute the code for all non-commercial and commercial use, except where providing a competitive offering to HashiCorp. Partners can continue to build integrations for our joint customers. We will continue to work closely with the cloud service providers to ensure deep support for our mutual technologies. Customers of enterprise and cloud-managed HashiCorp products will see no change as well.

Vendors who provide competitive services built on our community products will no longer be able to incorporate future releases, bug fixes, or security patches contributed to our products.

Я не юрист и не разбираюсь во всех тонкостях лицензирования, но для меня это выглядит плохо. Еще хуже, чем смена лицензии на продукты Elastic или отказ от публицации всех исходников у RedHat (я почти не пользуюсь этими продуктами и не сильно расстроился). У Gruntwork есть пост по поводу смены лицензии Terraform и как это изменение повлияет на их клиентов.

Что делать дальше? Ну например зафиксировать версии продуктов HashiCorp на тех, которые еще выпущены под лицензией MPL (например Terraform 1.5.5). Но такая фиксация в будущем обернется трудностями с исправлениями уязвимостей (в первую очередь актуально сетевых сервисов вроде Vault и Consul) и возможно к созданию форков.

Terraform: could not connect to registry.terraform.io

С некоторых пор из-за санкций в Беларуси есть проблемы с доступом к зарубежным ресурсам и в частности с выкачиванием провайдеров Terraform:

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Reusing previous version of hashicorp/google from the dependency lock file
╷
│ Error: Failed to query available provider packages
│
│ Could not retrieve the list of available versions for provider hashicorp/google: could not connect to registry.terraform.io: Failed to request discovery
│ document: 403 Forbidden
╵

Заход в документацию из браузера также блокируется

Самым простым решением будет использование VPN из другого региона, но если такой вариант по каким-либо причинам не подходит, но есть SSH доступ к внешнему хосту в "правильном" регионе, то выкрутиться можно так:

Terraform провайдер libvirt в Debian Buster

Давно собирался попробовать управлять виртуалками в libvirt через Terraform. Для этого существует провайдер multain/libvirt. Для начала создам виртуальную машину с двумя дисками.

terraform {
  required_providers {
    libvirt = {
      source = "multani/libvirt"
      version = "0.6.3-1+4"
    }
  }
}

provider "libvirt" {
  uri = "qemu:///system"
}

variable "prefix" {
  description = "Resource name prefix"
  type        = string
  default     = "terraform-"
}

resource "libvirt_volume" "boot" {
  name = "${var.prefix}boot"
  size = 20*1024*1024*1024
}

resource "libvirt_volume" "data" {
  name = "${var.prefix}data"
  size = 20*1024*1024*1024
}

resource "libvirt_domain" "default" {
  name = "${var.prefix}default"
  vcpu = 1
  memory = 2048

  disk {
    file = "/var/lib/libvirt/images/debian-10.9.0-amd64-netinst.iso"
  }

  disk {
    volume_id = libvirt_volume.boot.id
  }

  disk {
    volume_id = libvirt_volume.data.id
  }

  boot_device {
    dev = [ "hd", "cdrom"]
  }

  network_interface {
    bridge = "dmz0"
  }
}

Ошибка при создании Cloud Functions через Terraform

При очередном тестировании конфигурации Terraform выдал ошибку при создании Cloud Functions в GCP: googleapi: Error 403: Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the cloudfunctions.googleapis.com. We recommend that most server applications use service accounts instead. For more information about service accounts and how to use them in your application, see https://cloud.google.com/docs/authentication/.

Для работы с Terraform я использую авторизацию приложения с правами пользователя (application default credentials). Это продиктовано требованиями безопасности, да и в целом это имеет смысл т.к. приложение выполняет изменения в GCP от моего имени. Если использовать сервис аккаунт, то все работает без проблем, но тогда либо нужно создавать по отдельному сервис аккаунту на каждого пользователя, либо смириться с проблемами аудита.

Terraform не дает использовать символ подчеркивания в имени google cloud function

Зарепортил баг в Terraform провайдере google. Если использовать символ подчеркивания в имени cloud function, то не проходит валидация конфигурации

provider "google" {
  version = "~> 2.2"
  project = "${var.gcp_project}"
  region  = "${var.gcp_region}"
}

variable "gcp_project" {}

variable "gcp_region" {}

resource "google_cloudfunctions_function" "test_function" {
  name = "test_function"
}