Что такое провайдеры (providers) в Terraform?

Слушай, давай разберёмся с этими провайдерами в Terraform, а то у некоторых от одного слова «провайдер» уже волнение ебать начинается. Представь себе, что Terraform — это такой универсальный пульт управления, а провайдер — это переходник под конкретную розетку. Хочешь в AWS воткнуть — нужен переходник aws. Лезешь в Azure — бери переходник azure. Без этого переходника твой крутой пульт — просто кирпич, нихуя не управляет.

Вот смотри, самый простой пример, чтобы не охуеть сходу:

# Говорим Терраформу: дружок, будем работать с AWS, вот тебе регион
provider "aws" {
  region = "us-east-1"
  # Ключи доступа ему лучше через переменные окружения скормить, а не тут писать
}

# А теперь дай-ка создадим виртуалку
resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "Terraform-Example"
  }
}

Всё, вроде просто. Но тут, чувак, начинаются подводные ебушки-воробушки. Запомни несколько моментов, чтобы потом не было мучительно больно.

Во-первых, инициализация. Ты написал код, а Terraform про провайдер нихуя не знает. Нужно команду terraform init выполнить. Он тогда полезет в интернет, скачает нужный плагин в папочку .terraform и скажет «готово». Без этого шага все последующие команды — пизда рулю.

Во-вторых, и это овердохуища важно — версии. Нельзя просто написать provider "aws" и надеяться на лучшее. Завтра выйдет новая версия провайдера, в ней API поменяют, и твой красивый код накроется медным тазом. Поэтому версию надо фиксировать, как зек на зоне:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0" # Берём любую пятёрку (5.1, 5.2), но шестёрку — ни-ни!
    }
  }
}

В-третьих, доступы. Это вообще отдельная песня. Никогда, слышишь, никогда не пиши access key и secret key прямо в коде! Это уровень «распиздяй 80 lvl». Вынеси в переменные окружения, используй IAM-роли, специальные хранилища секретов — что угодно, только не хардкодь. Иначе однажды проснёшься от того, что какой-то пидарас шерстяной майнит крипту на твоём облачном счёте.

И в-четвёртых, состояние (state). Вот тут у многих терпения ноль ебать. Провайдеру нужно где-то хранить информацию о том, какой ресурс в коде соответствует какой реальной железяке в облаке. Хранит он это в state-файле. Если ты работаешь один, и файл лежит у тебя на компе — ещё ладно. Но если в команде, то вы ходите по охуенно тонкому льду. Один перезатрёт изменения другого, и будет вам хиросима и нигерсраки. Поэтому state нужно хранить удалённо (в том же S3) с блокировками. Это не обсуждается, это догма.

Короче, провайдер — это не просто строчка в коде. Это твой проводник в мир облачной инфраструктуры. Отнесись к его настройке без понтов, и тогда всё будет работать, а не гореть синим пламенем.