1) IaC „po ludzku” – o co w tym chodzi?
Infrastructure as Code (IaC) to sposób zarządzania serwerami i usługami, w którym cała konfiguracja jest zapisana w repozytorium jako kod. Zamiast klikać w panelach, uruchamiasz kod – identycznie na testach i na produkcji.
Korzyści:
- Powtarzalność i spójność – każdy serwer dostaje tę samą konfigurację.
- Kontrola zmian – commity, review, tagi, prosty rollback.
- Szybkość i bezpieczeństwo – mniej „ludzkich” błędów, łatwiejsze audyty i zgodność (np. z NIS2).
2) Jak działa Chef (w praktyce YIC)
Chef to ekosystem, którego sercem jest Chef Infra:
- Chef Server – centralny katalog cookbooków i metadanych.
- Chef Infra Client – agent na serwerze, który okresowo pobiera konfigurację z Chef Server i stosuje ją idempotentnie (zmienia tylko to, co trzeba).
- Cookbooks/Recipes – „przepisy” określające pożądany stan: pakiety, pliki, usługi, użytkownicy, crony, firewalle itd.
- Attributes, run_list, resources – dokładnie opisują „co, gdzie i jak”.
- Policyfiles – nowoczesny sposób „zamrażania” zależności i wersji (zamiast starych ról/środowisk + Berkshelf).
W YIC układ wygląda tak (skrótowo):
- GitLab → merge do main → pipeline waliduje kod i publikuje do Chef Server.
- Serwery (node’y) w określonych środowiskach (test / prod) uruchamiają
chef-clientw cronie lub jako timer i ściągają aktualny stan. - Zmiany są widoczne w logach, metrykach i raportach zgodności (InSpec).
3) Cookbook w 5 linijkach – mini-demo
Poniżej minimalny przykład ustawienia usługi i pliku konfiguracyjnego (schematycznie):
package ‘nginx’
template ‘/etc/nginx/nginx.conf’ do
source ‘nginx.conf.erb’
owner ‘root’
group ‘root’
mode ‘0644’
notifies :reload, ‘service[nginx]’, :immediately
end
service ‘nginx’ do
action [:enable, :start]
end
Chef sam rozpoznaje stan (czy pakiet jest zainstalowany, czy plik się zmienił, czy usługa działa) i wprowadza wyłącznie konieczne modyfikacje.
4) Policyfiles i wersjonowanie – koniec „dependency hell”
Zamiast składać środowiska z wielu osobnych puzzli, użyj Policyfile.rb:
- Definiujesz run_list i źródła cookbooków.
- Generujesz Policyfile.lock.json – zamrożenie wersji.
- Promujesz politykę z testów na produkcję – to przewidywalne i zgodne z audytem.
5) CI/CD dla Chef – przykład pipeline’u
Przykładowy szkic .gitlab-ci.yml (idea, bez sekretów i kluczy):
stages: [lint, unit, converge, upload]
lint:
script:
– cookstyle
unit:
script:
– chef exec rspec # jednostkowe/spec
converge:
script:
– kitchen test # Test Kitchen: uruchamia VM/LXC i sprawdza konwergencję
upload:
script:
– chef install Policyfile.rb
– chef export Policyfile.rb ./build -f
– knife upload cookbooks/my_cookbook
– knife upload policies
when: manual # promocja po zaakceptowaniu
- Cookstyle – lint wg dobrych praktyk.
- Test Kitchen – szybka weryfikacja na „żywym” systemie.
- Knife/ChefCLI – wysyłka na Chef Server.
6) Testy i zgodność: Test Kitchen + InSpec
- Test Kitchen konfiguruje krótką instancję (np. Rocky/Debian) i sprawdza konwergencję.
- InSpec (Compliance as Code) pozwala pisać czytelne testy zgodności – od uprawnień, przez konfiguracje, po hardening.
Przykład InSpec:
control ‘nginx-01’ do
impact 1.0
title ‘Nginx service is enabled and running’
describe service(‘nginx’) do
it { should be_enabled }
it { should be_running }
end
end
Efekt: wdrożenia są sprawdzalne i audytowalne (ważne pod NIS2).
7) Sekrety i bezpieczeństwo
Zasady praktyczne:
- Zero sekretów w repo – używaj Chef Vault albo integracji z zewnętrznym Secrets Managerem (np. HashiCorp Vault, AWS/GCP/KMS).
- MFA, SSH-certy, ograniczone klucze w pipeline’ach (z maksymalnym scope).
- Tryb „why-run” do bezpiecznego podglądu zmian.
- Blokady środowiskowe (manual gates) przy wrażliwych zmianach sieci, baz czy DNS.
- Telemetria i logi – Chef Client loguje każdy zasób; dołącz to do SIEM.
8) Operacje na setkach serwerów (case: YIC)
- Segmentacja ról: web/app/db/edge, atrybuty ze
Ohai(np. OS family, interfejsy, IP). - Idempotencja: po padzie/reboocie node wraca do zadanego stanu bez ręcznej interwencji.
- Środowiska test/prod: najpierw testy automatyczne + „canary”, dopiero potem rollout globalny.
- Integracje: NetBox (inwentaryzacja), Zabbix/Wazuh (monitoring/EDR), PBS/ZFS (backup/DR), Proxmox (VM-y/HA).
9) Najczęstsze pułapki i jak je ominąć
- Dryf konfiguracji poza Chef → wprowadź immutable infra lub cykliczne wymuszanie konwergencji.
- Sekrety w plikach → przenieś do Vaulta i obrotowo rotuj.
- „Zarastanie” cookbooków → refaktoryzuj na modułowe cookbooki z jasnymi interfejsami atrybutów.
- Brak testów → minimum: Cookstyle + Kitchen + InSpec smoke tests.
- Zbyt duże rollouty → fazuj, taguj, stosuj „feature flags” w atrybutach.
10) Strategia wdrożenia Chef krok po kroku (checklista)
- Repo standard: szablon cookbooka, Cookstyle, Kitchen, InSpec.
- Policyfiles: definicje + lock + promocja.
- Chef Server: kontrola dostępu, RBAC, separacja środowisk.
- CI/CD: lint → test → manualna promocja → upload.
- Sekrety: Vault + rotacja + skanowanie repo (truffleHog, ggshield).
- Monitoring i alercie: logi Chef → SIEM, metryki konwergencji.
- Runbooki i DR: procedury rollbacku, snapshoty, testy odtwarzania.
Garść ciekawostek
- Chef (kiedyś Opscode) powstał w 2008 r.; dziś to Progress Chef – oprócz Chef Infra ma też InSpec (compliance) i Habitat (automatyzacja aplikacji).
- Zasoby Chefa są idempotentne – wielokrotne uruchomienie nie „zepsuje” stanu, tylko go wyrówna.
- Test Kitchen ma wiele „driverów” (np. dokery/VM-ki/LXC), dzięki czemu testy są szybkie i tanie.
- Policyfiles mocno upraszczają dependency management – koniec z „berks update” chaos mode.
- InSpec przypomina zrozumiałe „specyfikacje wymagań” – świetne do audytów i NIS2.
Podsumowanie
Chef wprowadza porządek, przewidywalność i audytowalność w codziennym zarządzaniu serwerami. W YIC łączymy Chef z CI/CD, monitoringiem i kontrolą zgodności, żeby każda zmiana była bezpieczna, szybka i odtwarzalna. Jeśli chcesz przejść z „ręcznych” serwerów na w pełni Infrastructure as Code, zrobimy to z Tobą krok po kroku: od szablonów cookbooków po polityki, testy i produkcję.
Źródła (oficjalne dokumentacje i przewodniki)
- Progress Chef Infra Docs – architektura, cookbooks, resources, Policyfiles
- Test Kitchen Docs – testy konwergencji i drivery
- InSpec Docs – Compliance as Code, profile i kontrole
- Chef Automate – dashboard, raporty, compliance
(Linki do oficjalnych dokumentacji Progress Chef – nie odnoszą się do wersji zależnych od czasu; w razie potrzeby podam konkretne sekcje podczas implementacji.)