Przegląd najnowszych zmian w narzędziach DevOps

Terraform

Aktualna stabilna wersja: 1.14.9 (wydana 20 kwietnia 2026) | Wersja w przygotowaniu: 1.15 (RC2)

Terraform 1.14 — kluczowe nowości

Terraform 1.14 wprowadził kilka istotnych funkcjonalności skupionych na zarządzaniu istniejącą infrastrukturą i rozszerzeniu możliwości providerów.

List resources i komenda terraform query
Nowym typem zasobu są tzw. list resources, definiowane w plikach *.tfquery.hcl. Pozwalają one odpytywać i filtrować istniejącą infrastrukturę bezpośrednio z poziomu Terraform. Towarzysząca im komenda terraform query umożliwia wykonywanie tych zapytań, a opcjonalnie generuje gotową konfigurację do importu — znacznie upraszczając przejęcie istniejących zasobów pod zarządzanie Terraform.

Blok actions
Nowy blok najwyższego poziomu actions pozwala providerom definiować operacje niestandardowe, wykraczające poza standardowy cykl CRUD (np. wywołanie Lambdy lub unieważnienie cache w CloudFront). To odpowiedź na długoletnie zapotrzebowanie na obsługę operacji z efektami ubocznymi bez konieczności używania zewnętrznych skryptów.

Ulepszenia testowania
W trybie terraform test --verbose wyświetlane są teraz oczekiwane diagnostyki. Flaga prevent_destroy jest ignorowana podczas czyszczenia po testach, a CLI pokazuje podsumowanie wywołanych akcji podczas terraform apply.

Poprawki błędów
Naprawiono poprawne pobieranie zmiennych workspace podczas importu oraz poprawkę obsługi proxy dla backendu OSS.

Terraform 1.15 — co nowego w gałęzi RC (Release Candidate)

Dynamiczne źródła modułów
Terraform 1.15 przynosi bardzo oczekiwaną możliwość używania zmiennych i wartości local w atrybutach source i version bloków module. Większość komend akceptuje teraz wartości zmiennych (-var) na potrzeby tych dynamicznych referencji.

Oficjalne wsparcie dla Windows ARM64
Po raz pierwszy dostępne są oficjalne binaria dla architektury Windows ARM64, eliminując konieczność emulacji na nowszym sprzęcie.

Deprecjonowanie zmiennych i outputów
Nowy atrybut deprecated pozwala autorom modułów oznaczać przestarzałe zmienne i outputy — Terraform wyświetli czytelne ostrzeżenia przy każdym użyciu.

Ulepszony backend S3
Backend S3 obsługuje teraz uwierzytelnianie przez aws login, a zmienne środowiskowe dla FIPS/dualstack są traktowane bardziej rygorystycznie (tylko true/false).

Ulepszenia terraform test
Obsługa funkcji wewnątrz bloków mock, diagnostyki na poziomie pliku w wyjściu JUnit XML oraz brak niezerowego kodu wyjścia dla planów refresh-only bez zmian.

OpenTofu

Aktualna stabilna wersja: 1.10.7 (łatki bezpieczeństwa, kwiecień 2026) | Seria 1.11.x wspierana do 1 sierpnia 2026

OpenTofu — open-source'owy fork Terraform zarządzany przez Linux Foundation — w ciągu ostatnich miesięcy dostarczył szereg istotnych nowości.

OpenTofu 1.10 — główne funkcjonalności

Wsparcie dla rejestrów OCI
Jedną z największych zmian jest możliwość korzystania z rejestrów OCI jako źródła modułów i providerów — unifikacja z ekosystemem kontenerowym i możliwość hostowania artefaktów Terraform w tych samych rejestrach co obrazy Docker.

Natywne blokowanie stanu w S3
Blokowanie stanu dla backendu S3 jest teraz obsługiwane natywnie, bez konieczności używania dodatkowej tabeli DynamoDB.

OpenTelemetry tracing (eksperymentalny)
Możliwość instrumentowania operacji Terraform za pomocą OpenTelemetry — przydatne dla zespołów monitorujących czas wykonania planów i operacji apply.

Dostawcy kluczy szyfrowania
OpenTofu umożliwia konfigurację zewnętrznych dostawców kluczy do szyfrowania stanu i plików planów — funkcja niedostępna w upstream Terraform.

OpenTofu 1.11 — wartości efemeryczne i enabled

Wartości efemeryczne (ephemeral values)
Kluczowa nowość: wartości efemeryczne są przechowywane wyłącznie w pamięci RAM przez czas trwania jednej fazy operacji, nigdy nie trafiając do pliku stanu ani pliku planu. Można oznaczać jako efemeryczne: zmienne wejściowe, outputy, a także używać specjalnych typów zasobów efemerycznych (np. do pobierania sekretów).

Meta-argument enabled
Alternatywa dla count = 0 i for_each — przejrzysty sposób na warunkowe włączanie/wyłączanie zasobów lub modułów. Zamiast skomplikowanego count = var.enable ? 1 : 0 można napisać enabled = var.enable.

Pozycja w ekosystemie

OpenTofu dołączyło do CNCF (Cloud Native Computing Foundation) w kwietniu 2025, a projekt posiada ponad 25 000 gwiazdek na GitHubie i ponad 70 aktywnych kontrybutorów. Projekt jest zarządzany przez Technical Steering Committee reprezentujące wiele firm, a nie przez jednego dostawcę. Używa licencji MPL 2.0 — uznanej licencji open-source.

Ansible

Aktualna stabilna wersja ansible-core: 2.20.5 (kwiecień 2026) | Pakiet community: ansible 13.5.0 (marzec 2026) | W przygotowaniu: ansible-core 2.21 (beta), ansible 14.0

ansible-core 2.19

Wersja ansible-core 2.19.0 została wydana w lipcu 2025 i jest aktywnie rozwijana. To wydanie koncentruje się na ulepszeniach bezpieczeństwa, wydajności i lepszej integracji z nowoczesnymi środowiskami.

ansible-core 2.20 — przełomowe zmiany

Usunięcie transportu smart
Opcja konfiguracyjna DEFAULT_TRANSPORT nie obsługuje już wartości smart, która wybierała domyślny transport (ssh lub paramiko) na podstawie konfiguracji platformy. Należy jawnie ustawić preferowany transport.

Zmiany w obsłudze ścieżek Windows
Moduły PowerShell nie próbują już automatycznie usuwać cudzysłowów ze ścieżek podczas operacji Windows (kopiowanie, pobieranie plików). Playbooki polegające na tym zachowaniu wymagają aktualizacji.

Zmiany w failed_when
Przy użyciu failed_when do tłumienia błędów, klucz exception w wyniku jest teraz przemianowany na failed_when_suppressed_exception — co zapobiega wyświetlaniu błędu przez callbacki po jego stłumieniu.

Red Hat Ansible Automation Platform 2.6

Platforma AAP 2.6, wydana w październiku 2025, przynosi szereg ulepszeń:

• Ulepszony interfejs platformy oparty o nową bramę (Gateway)
• Wsparcie dla dynamicznych poświadczeń GCP z nowym typem workload_pool
• Aktualizacja Django do wersji 5.2 LTS w Automation Hub
• Szereg poprawek bezpieczeństwa (m.in. CVE-2025-14025 dotyczący obejścia ograniczeń tokenów PAT)

Kubernetes

Obsługiwane wersje (kwiecień 2026)

Projekt Kubernetes utrzymuje gałęzie wydań dla trzech ostatnich wersji minor: 1.35, 1.34 i 1.33.

Kubernetes 1.33 „Octarine" (kwiecień 2025)

Wydanie Kubernetes v1.33 obejmuje 64 ulepszenia: 18 uzyskało status Stable, 20 weszło do Beta, 24 do Alpha, a 2 zostały wycofane.

In-Place Pod Resize (Beta)
Długo oczekiwana funkcja przeszła do bety i jest domyślnie włączona. Pozwala na modyfikację przydziałów CPU i pamięci w działającym Podzie — bez konieczności restartu. Monitorowanie stanu odbywa się przez dwa nowe warunki Poda: PodResizePending i PodResizeInProgress.

User namespaces domyślnie włączone
Kubernetes 1.33 domyślnie włącza user namespaces, co znacząco zwiększa izolację kontenerów od systemu hosta.

Śledzenie zmian specyfikacji Poda (metadata.generation)
Nowe pole metadata.generation inkrementuje się przy każdej zmianie mutowalnego pola spec Poda — umożliwiając kontrolerom i narzędziom GitOps niezawodne wykrywanie dryftu konfiguracji.

Deprecjonowanie API v1.Endpoints
API EndpointSlices jest stabilne od v1.21 i efektywnie zastąpiło oryginalne API Endpoints. Oryginalne API Endpoints zostało oznaczone jako przestarzałe — użytkownicy powinni migrować do EndpointSlices.

Kubernetes 1.34 „Of Wind & Will" (sierpień 2025)

Kubernetes 1.34 zawiera 59 ulepszeń bez żadnych deprecjacji, co czyni tę wersję przyjazną w procesie aktualizacji.

DRA (Dynamic Resource Allocation) — status Stable
Dynamic Resource Allocation (DRA) graduating to stable transformuje sposób, w jaki Kubernetes zarządza wyspecjalizowanym sprzętem jak GPU, FPGA i niestandardowymi urządzeniami. Administratorzy mogą teraz definiować typy urządzeń centralnie, a deweloperzy deklarować tylko wymagany typ — Kubernetes automatycznie przydziela odpowiedni węzeł.

Mutujące polityki dopuszczania (Admission Policies) — Beta
Polityki oparte na CEL (Common Expression Language) do mutowania zasobów — alternatywa dla zewnętrznych webhooków, z lepszą integracją z RBAC i audytem Kubernetes.

KYAML — Alpha
Nowy format wyjściowy dla kubectl, będący bardziej rygorystycznym podzbiorem YAML. Rozwiązuje problemy z dwuznacznością typowania (np. "NO" interpretowane jako bool) i wrażliwością na białe znaki.

PodCertificateRequest (Alpha)
Pody mogą teraz uzyskiwać krótkotrwałe certyfikaty X.509 bezpośrednio z API Kubernetes, co upraszcza zarządzanie tożsamością workloadów.

Kubernetes 1.35 „Timbernetes" (grudzień 2025)

Wydanie Kubernetes 1.35 awansuje In-Place Pod Resource Adjustments do statusu Generally Available (GA), umożliwiając administratorom modyfikację przydziałów CPU i pamięci bez przestojów.

In-Place Pod Resize — GA
Po kilku latach w fazie alpha i beta, funkcja osiąga stabilność produkcyjną. Implementacja modyfikuje ustawienia cgroup bezpośrednio na działającym kontenerze. Wymaga cgroups v2 — Kubernetes 1.35 deprecjonuje wsparcie dla cgroups v1.

OCI Image Volumes — Stable
Typ wolumenu image jest dostępny w becie od v1.33 i jest domyślnie włączony w v1.35. Wymaga zgodnego runtime kontenerowego, np. containerd v2.1 lub nowszego. Umożliwia montowanie artefaktów OCI (konfiguracji, binariów, modeli ML) bezpośrednio jako wolumeny tylko do odczytu.

KYAML — Beta (domyślnie włączony)
KYAML awansuje do bety w Kubernetes v1.35 i jest domyślnie włączony. Można go wyłączyć ustawiając zmienną środowiskową KUBECTL_KYAML=false.

Deprecjacja IPVS w kube-proxy
Tryb IPVS w kube-proxy jest deprecjonowany — planowane usunięcie w Kubernetes 1.36. Użytkownicy powinni planować migrację do trybu nftables lub iptables.

Containerd 1.x — ostatnie wsparcie
Kubernetes 1.35 jest ostatnim wydaniem wspierającym containerd 1.x. Przed aktualizacją do kolejnej wersji konieczne jest przejście na containerd 2.0 lub nowszy.

Rancher

Aktualna stabilna wersja: 2.14.0 | W przygotowaniu: 2.14.1, 2.15.0-alpha

Rancher 2.13

Seria 2.13 przyniosła kilka istotnych zmian infrastrukturalnych:

Koniec RKE1
Rancher Kubernetes Engine (RKE/RKE1) osiągnął koniec życia 31 lipca 2025. Wersje Ranchera od 2.12.0 nie obsługują już provisioningu ani zarządzania klasterami RKE1. Zalecana migracja do RKE2.

Wymagana warstwa agregacji Kubernetes API
Rancher wymaga teraz włączonej warstwy agregacji API (Kubernetes API Aggregation Layer) w klastrze, na którym działa, ponieważ rozszerza Kubernetes o własne API przez rejestrację własnego serwera API rozszerzeń.

Wymagany Helm 3.18+
Do zarządzania Rancherem 2.12.x i nowszymi wymagany jest klient Helm w wersji 3.18 lub nowszej.

Rancher 2.14 — najważniejsze nowości

Wsparcie dla Kubernetes 1.35
Rancher v2.14.0 obsługuje teraz Kubernetes v1.35.

Wsparcie dla dowolnych typów zasobów Kubernetes i kwot (quotas)
Rancher obsługuje teraz użycie dowolnych referencji zasobów i ich kwot (quotas) — ważny krok w kierunku bardziej generycznego zarządzania klastrami.

Uproszczenie helm chart
Usunięto kod sprawdzający obsługę wersji cert-manager, które osiągnęły EOL — chart Ranchera wspiera teraz tylko wersje cert-manager kompatybilne ze wspieranymi wersjami Kubernetes.

Polityka wersjonowania chartów (w przygotowaniu dla 2.15)
Wprowadzono nową politykę: starsze wersje chartów (spoza okna 7 ostatnich wersji i starsze niż 2 lata) nie będą dostępne od wersji Rancher 2.15. Zmiany nie są destrukcyjne dla istniejących instalacji.

Znany problem w 2.14.0
W przypadku używania Google OAuth jako dostawcy uwierzytelniania, aktualizacja do Rancher v2.14.0 może uniemożliwić logowanie użytkowników. Poprawka planowana w Rancher v2.14.1.

Podsumowanie

Ekosystem narzędzi DevOps przeżywa intensywny rozwój. Szczególnie widoczne jest dojrzewanie funkcjonalności AI/ML w Kubernetes (DRA dla GPU, in-place resize dla zadań treningowych), rosnąca pozycja OpenTofu jako prawdziwie open-source'owej alternatywy dla Terraform, oraz stopniowe eliminowanie przestarzałych składników (RKE1, cgroups v1, containerd 1.x) na rzecz nowocześniejszych rozwiązań.