# Управление 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/ru/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/ru/kb/cloudflare-cache-rules/) и [WAF Custom Rules](https://www.zevshost.net/ru/kb/cloudflare-waf-custom-rules/)
4. настроить удалённый backend для state-файла
5. проверять plan перед каждым apply, не применять изменения вслепую

---

Источник: https://www.zevshost.net/ru/kb/cloudflare-api-terraform/