Навіщо керувати 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 без кліків