# Керування Cloudflare через API і Terraform без кліків

> Як налаштувати Cloudflare через REST API і Terraform: токени, provider, DNS-записи та правила кешу у вигляді коду замість кліків у Dashboard.

## Навіщо керувати 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](https://www.zevshost.net/uk/kb/cloudflare-dns-management/).

## 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 — для конфігурації, яку треба повторювати на багатьох зонах і тримати під контролем версій.

1. створити API-токен із правами лише на потрібні зони, не Account API Key
2. підключити provider cloudflare/cloudflare потрібної версії
3. перенести в код записи DNS і правила з [Cache Rules](https://www.zevshost.net/uk/kb/cloudflare-cache-rules/) і [WAF Custom Rules](https://www.zevshost.net/uk/kb/cloudflare-waf-custom-rules/)
4. налаштувати віддалений backend для state-файлу
5. перевіряти plan перед кожним apply, не застосовувати зміни наосліп

---

Джерело: https://www.zevshost.net/uk/kb/cloudflare-api-terraform/