Зачем управлять Cloudflare через API и Terraform

Пока в аккаунте один сайт, настройки Cloudflare удобно менять руками в Dashboard. Как только доменов становится десять и больше, а правила кэша и firewall нужно повторить на каждом, ручные клики превращаются в источник расхождений между зонами.

API и Terraform решают это через код: одна и та же DNS-запись или правило описываются один раз и применяются к нужным зонам командой, а не серией кликов по вкладкам. Изменения видны в git-истории, а не только в логе аудита Cloudflare.

Когда хватит обычного API, а когда нужен Terraform

Выбор зависит от того, разовая это задача или повторяемая конфигурация, которую нужно держать в актуальном состоянии.

Задача	REST API	Terraform
Разовое изменение записи	Один запрос curl, проще всего	Избыточно для одной правки
Одинаковая настройка на 20 зонах	Нужен свой скрипт с циклом	Один модуль на все зоны
Отслеживание изменений	Только через Audit Log в Dashboard	Diff в git перед каждым apply

Первый запрос к API: токен и проверка

Токен создаётся в Dashboard в разделе My Profile → API Tokens с правами Zone:Edit на конкретную зону, а не глобальный Account API Key. Проверить токен можно одним запросом:

curl -X GET "https://api.cloudflare.com/client/v4/user/tokens/verify" \
  -H "Authorization: Bearer $CF_API_TOKEN"

Ответ со статусом active подтверждает, что токен рабочий и можно переходить к изменению записей DNS или правил кэша, описанных в статье про DNS-записи и режим Proxy.

Provider Terraform для Cloudflare: базовая настройка

Официальный provider подключается тремя строками в конфигурации, после чего Terraform умеет создавать и обновлять ресурсы Cloudflare тем же способом, что и ресурсы облачного провайдера.

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.0"
    }
  }
}

provider "cloudflare" {
  api_token = var.cf_api_token
}

Пример: DNS-запись и правило кэша в виде кода

Ресурс cloudflare_record описывает DNS-запись, а cloudflare_ruleset — правило кэша или firewall тем же синтаксисом, что и остальную инфраструктуру:

resource "cloudflare_record" "app" {
  zone_id = var.zone_id
  name    = "app"
  type    = "A"
  content = "203.0.113.10"
  proxied = true
}

После правки файла достаточно команды terraform plan, чтобы увидеть, какие записи изменятся, и terraform apply — чтобы применить их сразу на всех перечисленных зонах.

State-файл и типичные ошибки

Главный источник проблем — не сам provider, а обращение с файлом состояния и правами токена:

state-файл хранит значения ресурсов в открытом виде — его нельзя коммитить в публичный репозиторий
для команды state лучше держать в удалённом backend, а не на одном ноутбуке
токен с правом Zone:Edit на все зоны аккаунта опаснее токена на одну зону
ручная правка в Dashboard после apply создаёт расхождение — Terraform откатит её при следующем apply

Итог: с чего начать автоматизацию

API подходит для разовых скриптов и интеграций, Terraform — для конфигурации, которую нужно повторять на многих зонах и держать под контролем версий.

создать API-токен с правами только на нужные зоны, не Account API Key
подключить provider cloudflare/cloudflare нужной версии
перенести в код записи DNS и правила из Cache Rules и WAF Custom Rules
настроить удалённый backend для state-файла
проверять plan перед каждым apply, не применять изменения вслепую

Управление Cloudflare через API и Terraform без кликов