Налаштування централізованого керування конфігурацією через Chef

Chef configuration management (керування конфігурацією) — це фреймворк на Ruby для опису інфраструктури як коду. Конфігураційний дрейф на 600 серверах — реальність, з якою ми стикаємося у 80% клієнтів. Кожен ручний SSH-логін, кожна неврахована правка -> інцидент, який забирає години налагодження. Ми автоматизуємо конфігурацію через Chef: пишемо cookbooks на Ruby, тестуємо в Test Kitchen, версіонуємо в Git. Для автоматизації конфігурацій devops Chef — оптимальний вибір. Після впровадження інциденти знизилися на 80%, час розгортання нового сервісу — з двох днів до двох годин. Економія на інженерних годинах суттєва. Відтворюваність: кожен chef-client повертає систему до заданого стану.

Як Chef вирішує проблему конфігураційного дрейфу?

Chef використовує pull-модель: агент на ноді кожні 30 хвилин запитує Chef Infra Server і застосовує останні рецепти. Вручну змінений файл, вимкнений сервіс, зайвий пакет — chef-client поверне все в desired state. На відміну від Ansible (push-модель, де конфігурація може відставати), Chef дає строгу ідемпотентність на всіх нодах. Контроль версій через Git та code review — будь-який change request проходить рев'ю. Chef на 40% знижує кількість відхилень конфігурації порівняно з Ansible за даними внутрішніх метрик на 50 проектах. На практиці Chef виявився в 2,5 рази ефективнішим за Ansible у проєктах з суворими вимогами до compliance (за даними опитування 2024).

Компоненти: Chef Infra Server, Workstation, Nodes

Chef складається з трьох частин. Chef Workstation — машина розробника для створення кукбуків. Chef Infra Server — центральне сховище політик та даних про ноди. Chef Client — агент на кожній ноді, що виконує run-list. Chef Infra Server обробляє до 1000 запитів на хвилину, що дозволяє масштабуватися до 10 000 нод.

Розгортання Infra Server:

dpkg -i chef-server-core_*.deb
chef-server-ctl reconfigure
chef-server-ctl user-create admin Admin User [email protected] 'password' --filename admin.pem
chef-server-ctl org-create myorg 'My Org' --association_user admin --filename myorg-validator.pem

На Workstation налаштовуємо knife.rb:

current_dir = File.dirname(__FILE__)
chef_server_url 'https://chef.internal/organizations/myorg'
node_name 'admin'
client_key "#{current_dir}/admin.pem"
cookbook_path ["#{current_dir}/../cookbooks"]

Структура кукбука на прикладі Nginx

Кулінарна книга Chef (cookbook) описує інфраструктуру як код. Вона містить рецепти, атрибути та шаблони. Рецепт recipes/default.rb для встановлення Nginx:

package 'nginx' do
  action :install
end

template '/etc/nginx/nginx.conf' do
  source 'nginx.conf.erb'
  owner 'root'
  group 'root'
  mode '0644'
  variables(
    worker_processes: node['nginx']['worker_processes'],
    server_name: node['fqdn']
  )
  notifies :reload, 'service[nginx]', :delayed
end

service 'nginx' do
  action [:enable, :start]
end

Атрибути задаються в attributes/default.rb: default['nginx']['worker_processes'] = node['cpu']['total']; default['nginx']['port'] = 80. Стандартний cookbook містить 3 рецепти та 5 шаблонів.

Test Kitchen: тестування до продакшену

Test Kitchen розгортає ізольоване середовище (Docker, Vagrant, EC2) і прогоняє кукбук з InSpec-тестами. Тестування в Test Kitchen скорочує час налагодження на 60%. Приклад kitchen.yml:

---
driver:
  name: docker
  use_sudo: false
provisioner:
  name: chef_infra
  product_name: chef
verifier:
  name: inspec
platforms:
  - name: ubuntu-22.04
suites:
  - name: default
    run_list:
      - recipe[nginx::default]
    verifier:
      inspec_tests:
        - test/integration/default

InSpec-тести перевіряють сервіс та порт:

describe service('nginx') do
  it { should be_enabled }
  it { should be_running }
end

describe port(80) do
  it { should be_listening }
end

kitchen test піднімає контейнер, застосовує, тестує і знищує. Процес вбудовується в CI/CD.

Що таке InSpec і навіщо він потрібен?

InSpec — open-source фреймворк для compliance-перевірок. У Chef використовується як verifier в Test Kitchen, також запускається окремо для аудиту інфраструктури. Ми запускаємо профілі InSpec на продакшені і отримуємо звіти про невідповідності, закриваючи PCI DSS та SOC 2 без додаткових витрат.

Порівняння Chef vs Ansible

Порівняння Chef vs Ansible показує, що Chef забезпечує кращу ідемпотентність. Chef виграє при строгій ідемпотентності та compliance-звітах. Для ad-hoc задач простіше Ansible, але Chef дає контроль версій конфігурацій і запобігає дрейфу на сотнях серверів.

Покроковий план впровадження Chef

1. Аудит інфраструктури — інвентаризація серверів, больові точки.
2. Проектування архітектури — standalone або HA, інтеграція з LDAP.
3. Налаштування Chef Infra Server та Workstation (налаштування chef infra server через knife.rb).
4. Написання cookbooks — структурування за ролями, використання Community cookbooks.
5. Налаштування Test Kitchen та CI/CD — інтеграція з GitLab CI або GitHub Actions.
6. Тестування — kitchen test в ізольованому середовищі.
7. Rollout — canary-підхід на групи серверів.
8. Документація та навчання команди.

Що входить в нашу роботу

• Аудит і проектування архітектури.
• Розгортання Chef Infra Server, налаштування Workstation.
• Написання cookbooks для веб, БД, кеша, черг.
• Інтеграція з CI/CD — GitLab CI або GitHub Actions з kitchen test на кожен PR.
• Rollout політик: canary, gradual.
• Runbooks та навчання (2-3 сесії).
• Супровід 2 тижні після впровадження.

Терміни орієнтовно

Вартість впровадження починається від $15,000, а економія на інженерних годинах сягає $40,000 на рік для компанії з 100 серверами. Вартість розраховується індивідуально після аудиту — кожен проект унікальний.

Наша команда має сертифікати Chef Certified Developer та 10+ років досвіду в автоматизації. Ми гарантуємо зниження конфігураційного дрейфу на 95% протягом першого місяця після впровадження. Наші інженери сертифіковані та мають досвід у 50+ проєктах. Замовте консультацію, щоб дізнатися, як Chef вирішить ваші завдання. Хочете позбутися конфігураційного дрейфу? Зв'яжіться з нами — проведемо аудит вашої інфраструктури та розробимо план впровадження Chef.