CFEngine (Configuration Engine) — система управления конфигурацией, созданная в 1993 году Марком Бургессом (Mark Burgess) в Университете Осло. Это первый в истории инструмент Infrastructure as Code (IaC): системный администратор описывает желаемое состояние сервера, а агент CFEngine самостоятельно приводит систему к этому состоянию — независимо от текущего положения дел. Данный принцип называется конвергентностью (convergence).
Как работает
CFEngine основан на модели «политика + агент»:
- Политика (Policy) — декларативные файлы на языке CFEngine Policy Language (расширение
.cf). Описывают, каким должно быть состояние: файлы, процессы, пакеты, права доступа, пользователи. - Агент cf-agent — запускается по cron или systemd timer каждые 5 минут. Считывает политику с Policy Hub, сравнивает с текущим состоянием системы и вносит только необходимые изменения.
- Policy Hub — централизованный сервер политик. Агенты синхронизируют политику через cf-serverd по порту 5308 (TLS с взаимной аутентификацией).
Идемпотентность — ключевое свойство: запуск cf-agent 1000 раз на системе, уже находящейся в целевом состоянии, не вносит никаких изменений. Это отличает CFEngine от скриптов оболочки.
Масштаб: одна Policy Hub управляет тысячами агентов. Задокументированный рекорд — 1 миллион серверов под управлением CFEngine. LinkedIn публично сообщал об управлении ~40 000 хостов через CFEngine.
Сравнение с современными инструментами:
| Критерий | CFEngine | Ansible | Puppet |
|---|---|---|---|
| Год создания | 1993 | 2012 | 2005 |
| Агент | Да (постоянный) | Нет (agentless) | Да |
| Язык | CFEngine Policy | YAML | Puppet DSL |
| Производительность | Очень высокая | Средняя | Средняя |
| Порог входа | Высокий | Низкий | Средний |
История
CFEngine создан в 1993 году Марком Бургессом как академический проект для управления рабочими станциями физического факультета Университета Осло. В 1995 году опубликован как open source. CFEngine 2 (1997) стал производственно готовым инструментом. CFEngine 3 (2008) — полностью переработанный с новым языком политик и архитектурой. Коммерческая версия CFEngine Enterprise (с 2013) добавила репортинг, аудит и поддержку. Puppet (2005), Chef (2009), Ansible (2012) — прямые потомки идей CFEngine.
На что обращать внимание
CFEngine остаётся актуальным для экстремально больших инфраструктур (10 000+ серверов): агент работает автономно и не требует постоянного соединения с центром. В отличие от Ansible, агент обнаруживает и исправляет дрейф конфигурации (configuration drift) автоматически. Порог вхождения высок: CFEngine Policy Language нетривиален. Для новых проектов в 2024–2026 годах предпочтительны Ansible или Puppet с более широким сообществом и экосистемой.
Типичные ошибки при работе с CFEngine
- Описание политик без тестирования в dry-run режиме (
--dry-run) — нежелательные изменения на продакшне. - Слишком частый интервал проверки (по умолчанию 5 мин) на большом парке серверов нагружает VPS.
- Не настроен CFEngine Enterprise Dashboard для централизованного мониторинга состояния.
CFEngine vs Ansible vs Puppet vs Chef
| Параметр | CFEngine | Ansible | Puppet |
|---|---|---|---|
| Подход | декларативный | процедурный/декларативный | декларативный |
| Агент | обязателен (cf-agent) | не нужен (SSH) | обязателен |
| Язык | Promise Theory (CFL) | YAML | Puppet DSL |
| Масштаб | до 1 000 000 хостов | до нескольких тысяч | до 10 000+ |
| Кривая обучения | крутая | пологая | средняя |
CFEngine применяется в крупных инфраструктурах с тысячами серверов. Для типичного хостинга до 50-100 серверов предпочтительнее Ansible из-за простоты освоения и YAML-конфигурации. CFEngine 3 использует концепцию Promise Theory Марка Бёрджесса (1998) — каждый хост сам «исполняет обещания» независимо от центрального сервера.