Infrastruktura niezmienialna (ang. immutable infrastructure) to model zarządzania serwerami, w którym raz wdrożonej instancji już nie ruszasz. Żadnych ręcznych poprawek na produkcji, żadnego logowania po SSH, żeby „szybko coś dograć”. Kiedy chcesz wprowadzić zmianę — aktualizację paczek, nową wersję aplikacji, inną konfigurację — budujesz całkiem nowy serwer z gotowego obrazu, uruchamiasz go, a stary po prostu kasujesz. Serwer traktujesz jak cattle, not pets: bydło, które się wymienia, a nie pupila, którego się latami leczy.
Jak to działa
Punktem wyjścia jest obraz (artefakt) zawierający system, zależności i aplikację — np. obraz maszyny wirtualnej albo obraz kontenera. Budujesz go raz, testujesz i wdrażasz dokładnie ten sam artefakt na każdym środowisku: dev, staging, produkcja. Skoro nikt nie modyfikuje działających instancji, znika configuration drift — czyli sytuacja, w której dwa „identyczne” serwery po pół roku ręcznych poprawek różnią się tak, że jeden działa, a drugi nie.
Korzyści są konkretne: powtarzalne wdrożenia, łatwy rollback (wracasz do poprzedniego obrazu), prostsze skalowanie (odpalasz N kopii tego samego) i mniej „działa u mnie na maszynie”. To naturalne dopełnienie podejścia Infrastructure as Code.
Przykład z praktyki
Klasyczny zestaw to Packer do budowy obrazu plus Terraform do jego wdrożenia. Packerem pieczesz obraz (np. AMI w AWS), a potem nową wersję wytaczasz, podmieniając identyfikator obrazu w Auto Scaling Group i odświeżając instancje:
packer build app.pkr.hcl— buduje obraz z aplikacjąterraform apply— uruchamia nowe instancje z nowego obrazu, stare wygasza
W świecie kontenerów masz to samo w mniejszej skali: nie wchodzisz do działającego kontenera, żeby go „naprawić” — budujesz nowy docker image, podbijasz tag i robisz rolling update w Kubernetes.
Częste błędy i mity
„Niezmienialne = bezstanowe.” Nie do końca. Sam serwer jest jednorazowy, ale dane muszą gdzieś przetrwać jego śmierć — wynieś je do zewnętrznej bazy, wolumenów albo obiektowego storage. Inaczej każdy redeploy to skasowanie produkcyjnych danych.
Drugi grzech to „tylko jeden hotfix po SSH”. W chwili, gdy ręcznie poprawiasz produkcję, model się sypie: następny redeploy z obrazu cicho wymaże twoją zmianę. Jeśli musisz coś poprawić — popraw obraz, nie instancję.
Pojęcia powiązane: Infrastructure as Code, configuration drift, blue-green deployment, konteneryzacja (Docker), Kubernetes, Packer, Terraform, golden image, pets vs cattle.