Если вбить в поиск слово «chef», первые полсотни результатов будут про кухню. Но в мире серверов под этим же словом уже пятнадцать лет живёт совсем другая вещь: программа, которая настраивает машины вместо человека. Кухонная метафора внутри осталась, причём довольно навязчиво: файлы конфигурации там называются рецептами, наборы рецептов складывают в поваренные книги, а процесс приведения сервера в нужный вид называют готовкой.
В этой статье разобрали, что такое Chef на самом деле, из каких частей он собран, как выглядит один прогон изнутри и почему его постоянно ставят рядом с Kubernetes, хотя эти две штуки работают на разных этажах. И главное: в ноябре 2026 бесплатный Chef Infra Server официально умирает, а это меняет ответ на вопрос «стоит ли его учить».
Если про Kubernetes вы пока знаете только слово, начните с нашего разбора «Kubernetes простыми словами»: там разобрано, что такое контейнер и зачем ими вообще кто-то управляет.
Статья пригодится студентам, системным администраторам, которые смотрят в сторону автоматизации, и джунам, которым Chef достался в наследство вместе с рабочим проектом. Если вы ещё выбираете направление, посмотрите наш обзор профессии «Кто такой DevOps-инженер».
А если хочется разобраться в инфраструктуре системно, а не по обрывкам документации, у нас собрана подборка курсов по DevOps: там программы от коротких интенсивов по Linux до годовых с трудоустройством.
Что такое Chef и зачем настраивать серверы кодом

Chef — это система управления конфигурацией. Вы описываете в текстовом файле, каким должен быть сервер: какие пакеты установлены, какие сервисы запущены, какие файлы лежат по каким путям и с какими правами. Дальше Chef сам приводит машину к этому состоянию и следит, чтобы она в нём оставалась.
Звучит скучно ровно до того момента, пока серверов не станет больше десяти. Пока машина одна, её настраивают руками: зашли по SSH, поставили nginx, подправили конфиг, запустили. Когда машин пятьдесят, руками уже никак. И дело даже не в скорости. Руками настроенные серверы неизбежно расползаются. На одном стоит nginx 1.24, на другом 1.22, на третьем кто-то полгода назад поправил конфиг «на минутку» и забыл. Это называется дрейфом конфигурации, и именно из-за него бывает так, что приложение работает на четырёх серверах из пяти.
Подход, при котором состояние инфраструктуры описано текстом и хранится в системе контроля версий, называют инфраструктурой как кодом (infrastructure as code, IaC). Конфигурация лежит в Git, на неё делают code review, её откатывают на предыдущую версию, если что-то пошло не так. Chef был одним из первых инструментов, который принёс эту идею в массы: его написали в 2009 году, а в 2020-м компанию купила Progress Software, которая владеет им до сих пор.
Главное отличие от скриптов. Обычный bash-скрипт описывает, что сделать. Chef описывает, каким должен стать сервер. Разница в том, что скрипт, запущенный дважды, может всё сломать, а рецепт Chef можно гонять хоть каждые полчаса.
Из чего состоит Chef
Классическая архитектура Chef собрана из трёх участников, и путаница в них становится самой частой проблемой новичка.
Chef Workstation живёт на вашем ноутбуке. Здесь вы пишете конфигурации, тестируете их и отправляете на сервер. Тут же лежит утилита knife, консольный «нож», которым делают почти всё: загружают рецепты, смотрят список машин, назначают им задачи.
Chef Infra Server работает центральным хранилищем. Он держит все конфигурации, знает про все подключённые машины и раздаёт им указания. Сам он ничего не настраивает, он библиотека и справочная.
Нодой называют любую машину под управлением Chef: физический сервер, виртуалка, облачный инстанс. На каждой ноде стоит агент, программа chef-client, которая раз в тридцать минут сама ходит на сервер, забирает свежие инструкции и применяет их. Такая схема называется pull-моделью: инициатива у ноды, а не у центра.
Рецепт, кукбук и ран-лист
Единица работы в Chef называется рецептом (recipe). Это файл на Ruby, в котором перечислены ресурсы. Ресурсом тут зовут любую сущность в системе: пакет, файл, каталог, пользователь, служба. Выглядит рецепт так:
package 'nginx' do
action :install
end
service 'nginx' do
action [:enable, :start]
end
Читается почти как английский текст: пакет nginx поставить, службу nginx включить в автозагрузку и запустить. Никаких apt-get и systemctl в рецепте нет, и это принципиально: Chef сам подберёт нужную команду под конкретную операционную систему. Один и тот же рецепт отработает и на Ubuntu, и на CentOS.
Рецепты складывают в кукбук (cookbook), поваренную книгу. Внутри кукбука лежат рецепты, шаблоны конфигов, готовые файлы и метаданные. Кукбуками делятся: на публичном портале Chef Supermarket лежат тысячи готовых, от базового nginx до чего-нибудь экзотического.
Список того, что нода должна выполнить, называется ран-листом (run-list). Он может состоять из отдельных рецептов или из ролей, готовых наборов вроде «веб-сервер» или «сервер базы данных». Настройки, которые меняются от машины к машине (номер порта, размер пула соединений), выносят в атрибуты, а пароли и ключи прячут в зашифрованные data bag, ящики с данными.
Более современный способ собрать всё это вместе называется Policyfile: он фиксирует не только список рецептов, но и точные версии кукбуков, чтобы прогон был воспроизводимым.
Желаемое состояние и идемпотентность
Ключевое свойство Chef прячется в слове идемпотентность. Означает оно вот что: сколько раз ни примени рецепт, результат будет один и тот же. Если nginx уже установлен, Chef не станет ставить его заново. Если конфиг совпадает с шаблоном, файл не будет тронут.
Отсюда и защита от дрейфа. Агент просыпается каждые полчаса, сверяет реальное состояние машины с описанным и молча возвращает всё, что кто-то успел поменять руками. Тот самый сисадмин, который «на минутку» поправил конфиг, обнаружит через полчаса свою правку затёртой.
Почему Ruby и кого это отпугивает
Конфигурации Chef пишутся на Ruby. Формально это язык под конкретную задачу, DSL (domain-specific language): девяносто процентов рецептов выглядят как декларации из примера выше. Но потолок у языка настоящий, и в сложных кукбуках встречается обычный Ruby с циклами, условиями и собственными библиотеками.
Для команды разработчиков это плюс: любую логику можно выразить. Для команды эксплуатации, где Ruby никто не знает, это главная причина, по которой Chef проиграл Ansible. У конкурента конфигурации пишутся на YAML, простом формате «ключ: значение», который читается без подготовки. Если вы с YAML не сталкивались, у нас есть отдельный разбор: «Что такое YAML».
Как проходит один прогон Chef
Прогон агента называют converge, сходимость. Внутри он состоит из четырёх шагов.
Сначала запускается Ohai, встроенный разведчик. Он собирает про машину всё, до чего дотянется: операционную систему и её версию, объём памяти, сетевые интерфейсы, список дисков, облачного провайдера. Эти данные становятся доступны рецептам, поэтому один и тот же кукбук может вести себя по-разному на восьмиядерной машине и на однопроцессорной виртуалке.
Затем агент идёт на Chef Infra Server, представляется своим сертификатом и забирает ран-лист вместе с нужными кукбуками. Дальше он строит план: разворачивает роли в конкретные рецепты, рецепты в список ресурсов, и получает resource collection, полную последовательность того, что предстоит сделать.
И только после этого начинается собственно работа. Chef идёт по списку ресурсов, для каждого проверяет текущее состояние и меняет только то, что отличается от описанного. В конце агент отправляет на сервер отчёт: что изменилось, что осталось как было, где упало.
Полезная привычка. Прогон можно запустить в режиме
--why-run: Chef покажет, что именно он собирался изменить, ничего при этом не трогая. На незнакомом проекте со старым кодом (его называют легаси) это первое, что стоит сделать.
Как это тестируют
Вокруг Chef выросла целая обвязка для проверки конфигураций до того, как они уедут в боевую среду. Test Kitchen поднимает чистую виртуалку или контейнер, прогоняет на ней кукбук и проверяет результат. ChefSpec делает то же самое без запуска машины, на уровне модельного прогона. Berkshelf управляет зависимостями между кукбуками, примерно как npm в мире JavaScript.
Отдельно стоит InSpec, язык описания требований безопасности и соответствия стандартам. На нём пишут проверки вроде «порт 22 должен быть закрыт снаружи» или «версия OpenSSL не ниже такой-то», и прогоняют их по всему парку машин. Полноценного аналога InSpec в мире Ansible до сих пор нет, и для компаний с регуляторными требованиями это до сих пор главный аргумент за Chef. Смежная тема разобрана в статье «Кто такой DevSecOps-инженер».
Chef и Kubernetes: почему их сравнивают и в чём тут путаница

Вопрос «чем Chef отличается от Kubernetes» задают часто, и берётся он из честного непонимания. Оба инструмента про серверы, у обоих есть центральный узел и агенты на машинах, оба про автоматизацию. Кажется, что это конкуренты и надо выбрать один.
Формально у них даже разные названия задач: Chef занимается управлением конфигурацией, а Kubernetes отвечает за оркестрацию контейнеров. На практике это значит, что они работают на разных этажах одного дома. Chef настраивает операционную систему на машине. Kubernetes запускает контейнеры поверх уже настроенных машин. Между ними примерно такая же разница, как между электриком, который проводит проводку в здании, и диспетчером, который расселяет по этому зданию жильцов.
| Параметр | Chef | Kubernetes |
|---|---|---|
| Слой стека | операционная система на сервере | контейнеры поверх серверов |
| Что настраивает | пакеты, файлы, службы, пользователей | поды, сервисы, деплойменты, сеть между ними |
| Единица работы | нода (машина) | под (группа контейнеров) |
| Когда работает | раз в тридцать минут, приводит машину в порядок | непрерывно, следит за живостью приложений |
| Что будет без него | серверы расползутся по конфигурациям | приложение не переживёт падение одной машины |
| Язык описания | Ruby DSL | YAML-манифесты |
Из таблицы виден главный вывод: сам кластер Kubernetes тоже надо на чём-то развернуть. Узлы кластера — это обычные линуксовые машины, на которых должна быть настроена среда запуска контейнеров, служебный агент кластера, нужные модули ядра и сеть. И вот эту работу как раз делает система управления конфигурацией.
Поэтому в реальных компаниях они спокойно живут вместе: Chef или Ansible готовят машины, Kubernetes раскладывает по ним приложения. Прямого конфликта нет, и выбирать между ними не нужно.
Куда в эту схему встаёт Terraform
Терминологическую кашу довершает Terraform, который тоже называют инфраструктурой как кодом. Он занимает ещё один этаж, ниже всех: Terraform создаёт сами машины, сети и балансировщики в облаке. Он не заходит внутрь сервера и не знает, что там за пакеты.
Полная последовательность выглядит так. Terraform поднимает десять виртуалок в облаке. Chef или Ansible ставят на них Docker и всё остальное системное. Kubernetes принимает эти машины в кластер и раскладывает по ним контейнеры. Три инструмента, три этажа, ноль пересечений.
Chef, Ansible, Puppet и Salt: честное сравнение

Вот с этими четырьмя Chef конкурирует напрямую, потому что все они решают одну задачу.
| Параметр | Chef | Ansible | Puppet | Salt |
|---|---|---|---|---|
| Язык конфигураций | Ruby DSL | YAML | свой DSL | YAML + Jinja |
| Агент на машине | нужен | не нужен | нужен | нужен, но есть режим без него |
| Модель работы | pull | push по SSH | pull | push и pull |
| Порог входа | высокий | низкий | высокий | средний |
| Что нужно знать | Ruby | ничего сверх YAML | свой язык | Python пригодится |
| Сильная сторона | InSpec и комплаенс | скорость старта | очень крупные парки | скорость на тысячах узлов |
| Новые проекты в 2026 | почти нет | основной выбор | редко | нишево |
Картина за последние несколько лет сложилась однозначная. Подавляющее большинство новых проектов берут Ansible или связку Terraform плюс Ansible. Agentless-подход снимает целый класс проблем: ничего не нужно ставить на машины, ничего не нужно обновлять, достаточно SSH-доступа. Порог входа при этом такой, что человек без опыта программирования пишет рабочий плейбук в первый день.
Chef и Puppet остались там, где в них уже вложены годы работы: крупные банки, телеком, компании с жёсткими требованиями к аудиту. Там переписывать сотни кукбуков ради смены инструмента экономически бессмысленно, и легаси на Chef проживёт ещё долго.
Что случилось с Chef в 2026 году
Самая свежая часть истории про Chef напрямую влияет на решение «учить или не учить», поэтому разберём её отдельно.
Бесплатный Chef Infra Server прекращает существование в ноябре 2026 года. В документации это называют EOL, end of life, концом жизненного цикла. После октября в открытую версию не попадёт ни новый код, ни новые функции, ни исправления уязвимостей. Репозитории уйдут в режим только для чтения. Речь именно про серверную часть: агент Chef Infra Client, InSpec, Habitat и Workstation остаются в открытом доступе.
Progress предлагает взамен коммерческую платформу Chef 360 в двух вариантах: облачный SaaS и self-managed для установки в своём контуре. Компания обещает миграционные руководства и инструменты, но это платный продукт с подпиской.
Параллельно поменялась схема лицензирования в целом. Исходный код Chef по-прежнему открыт под Apache 2.0, но готовые сборки распространяются по отдельному лицензионному соглашению, и загрузка требует валидной лицензии. Формально «открытый» и практически «бесплатно скачал и поставил» здесь разошлись.
Свежая версия агента называется Chef Infra Client 19 и вышла 5 февраля 2026 года со статусом долгосрочной поддержки. Он целиком собран на Habitat, обычных пакетов под операционные системы для него больше не выпускают, внутри Ruby 3.4.8. Последний патч, 19.3.15, вышел 22 мая.
Cinc: свободная сборка, которая переживёт закрытие сервера
Ответ сообщества на всю эту историю называется Cinc. Это свободный дистрибутив тех же открытых исходников Chef, собранный без коммерческих ограничений и без обязательной лицензии. Функционально это тот же Chef: те же рецепты, те же кукбуки, те же команды, только имена бинарников другие.
Проект уже объявил план на осень: 15-я ветка Cinc Server пересобирается до ноября, а одновременно с закрытием оригинала выходит Cinc Server 16.0.0, независимый форк, который дальше живёт своей жизнью. Обещают режим поддержки: обновления безопасности, поддержка новых платформ, обновление зависимостей. Переход заявлен как бесшовный, без ломающих изменений в конфигурациях и командах.
Как это выглядит из России
Для российского читателя лицензионный поворот выглядит ещё жёстче. С сентября 2024 года действуют американские ограничения на поставку в Россию корпоративного управляющего софта, и легальная покупка подписки Chef 360 из РФ практически закрыта. Прибавьте к этому обязательную валидацию лицензии при скачивании сборок.
Практический вывод простой: если Chef нужен для учёбы или для поддержки существующего проекта, рабочий вариант здесь один и называется Cinc. Он бесплатен, не требует лицензии и не завязан на коммерческую инфраструктуру Progress.
Что это значит для новичка. Chef не исчез и не сломался: агент живой, релизы выходят, легаси работает. Но бесплатного «полного Chef из коробки» с осени 2026 года больше нет, и это стоит понимать до того, как вкладывать месяцы в изучение.
Стоит ли учить Chef в 2026 году

Однозначного ответа тут нет, зато есть три понятные ситуации.
Учить обязательно, если Chef уже стоит на вашем проекте. Это самый частый сценарий. Легаси-кукбуки в банках и телекоме проживут ещё лет пять. Людей, готовых в них разбираться, с каждым годом меньше. Дефицит на рынке работает в вашу пользу: специалист, который умеет поддерживать чужую поваренную книгу, стоит дорого именно потому, что таких мало.
Стоит посмотреть, если вы идёте в комплаенс и безопасность. InSpec остаётся самым проработанным способом описать требования безопасности кодом, и знание его пригодится даже там, где сам Chef не используют.
Не стоит начинать с Chef, если вы учитесь с нуля. Если вы гадаете, что выбрать для старта и с чего начать, ответ простой: берите Ansible. Он проще, его спрашивают на собеседованиях чаще, и вакансий под него в разы больше. Chef после Ansible осваивается за пару недель, потому что идеи внутри одинаковые, а обратный порядок отнимет лишний месяц на Ruby.
Что стоит вынести из Chef независимо от карьерных планов, так это сами принципы: желаемое состояние, идемпотентность, борьба с дрейфом. Они переносятся на любой инструмент, и без них вся автоматизация превращается в набор скриптов, которые страшно запускать дважды. Подробнее про весь набор навыков мы написали в статье «Как стать DevOps-инженером с нуля», а про деньги в профессии рассказали в разборе зарплат DevOps-инженеров.
Как попробовать Chef за один вечер
Самый быстрый способ пощупать инструмент, не покупая лицензий и не поднимая сервер, выглядит так.
- Поставьте на ноутбук Cinc Workstation. Внутри всё нужное: агент, knife, Test Kitchen.
- Установите Docker или любой гипервизор, чтобы было куда прогонять конфигурации. Если с контейнерами вы пока не работали, начните с курсов по Docker.
- Сгенерируйте пустой кукбук командой
chef generate cookbook my-firstи откройте файлrecipes/default.rb. - Впишите туда шесть строк из примера про nginx выше.
- Запустите
kitchen converge. Test Kitchen сам поднимет чистую машину, прогонит на ней рецепт и покажет отчёт. - Запустите ту же команду второй раз. В отчёте не будет ни одного изменения. Вот это и есть идемпотентность, о которой шла речь.
На всё уходит вечер, зато разница между декларативным подходом и обычными скриптами становится понятной на практике. Дальше логично посмотреть в сторону администрирования Linux: без уверенного владения системой любой инструмент автоматизации превращается в магию, которая иногда не срабатывает.
Где научиться инфраструктуре как коду
Chef, Ansible и Terraform по отдельности учатся по документации за пару недель. Проблема в том, что сами по себе они бесполезны: чтобы автоматизация имела смысл, нужно понимать, как устроен Linux, как работает сеть, что происходит в CI/CD-пайплайне и почему приложение падает под нагрузкой. Собрать это самостоятельно из статей можно, но уйдёт год, и половина времени потратится на выяснение, чего вы ещё не знаете.
Обучение по программе с внятной последовательностью экономит именно этот год. Ниже подборка курсов, где инфраструктура как код встроена в общий маршрут вместе с Linux, сетями и CI/CD.
| Курс | Школа | Стоимость со скидкой | В рассрочку | Длительность | Обзор курса от Checkroi |
|---|---|---|---|---|---|
| Профессия «DevOps-инженер PRO» Перейти на сайт курса | 105 000 ₽ | 5783 ₽/мес. | 12 месяцев | Обзор курса | |
| Профессия «DevOps-инженер с нуля» Перейти на сайт курса | 189 000 ₽ | 7875 ₽/мес. | 24 месяца | Обзор курса | |
| DevOps-инженер Перейти на сайт курса | 119 900 ₽ | 4995 ₽/мес. | 7 месяцев | Обзор курса | |
| Профессия DevOps-инженер с нуля + ИИ Перейти на сайт курса | 119 988 ₽ | 3333 ₽/мес. | 9 месяцев | Обзор курса | |
| Специализация «DevOps-инженер» Перейти на сайт курса | 130 200 ₽ | 5425 ₽/мес. | 12 месяцев | Обзор курса | |
| ДО Профессия DevOps-инженер 2.0 Перейти на сайт курса | 141 578 ₽ | 3933 ₽/мес. | 4 месяца | Обзор курса | |
| DevOps-инженер Перейти на сайт курса | 107 625 ₽ | 2990 ₽/мес. | 6 месяцев | Обзор курса | |
| Devops-инженер с нуля: расширенный курс Перейти на сайт курса | 122 300 ₽ | 4797 ₽/мес. | 19 месяцев | Обзор курса | |
| Devops-инженер с нуля Перейти на сайт курса | 105 400 ₽ | 4397 ₽/мес. | 14 месяцев | Обзор курса | |
| DevOps-инженер с нуля Перейти на сайт курса | 99 000 ₽ | 5334 ₽/мес. | 14 месяцев | Обзор курса |
Больше программ — в полном каталоге курсов по DevOps
Если хочется сначала понять, куда этот маршрут ведёт, посмотрите смежные роли: SRE-инженер и системный инженер. Обе выросли из той же идеи, что серверами должен управлять код.




