Blog JSystems - uwalniamy wiedzę!
Blog JSystems - uwalniamy wiedzę!
Codzienność DevOps-a to w dużej mierze powtarzalność: postaw maszynę, skonfiguruj sieć, wgraj pakiety, sprawdź, czy działa, a potem zrób to samo dwadzieścia razy. Zwykle klikamy w panelu albo piszemy skrypty, które z czasem rozjeżdżają się z rzeczywistością. W 2026 roku doszła trzecia droga: opisujemy cel w języku naturalnym, a agent AI tłumaczy go na realne operacje na infrastrukturze.
W tym artykule pokażemy to od początku do końca na żywej infrastrukturze. Podłączymy agenta do klastra Proxmox z ograniczonymi uprawnieniami, każemy mu wygenerować kod Terraform i postawić prawdziwy kontener, zobaczymy, jak radzi sobie z własnym błędem, jak wykrywa ręczne zmiany poza kodem, jak przepycha zmianę przez Pull Request z potokiem CI, zarządza flotą i skanuje wynik pod kątem podatności. Każdy zrzut poniżej pochodzi z realnego uruchomienia na naszym klastrze. To praktyczne wprowadzenie do tego, czego uczymy na szkoleniu AI dla DevOpsów. Jeśli dopiero zaczynasz, zajrzyj najpierw do przewodnika czym właściwie jest DevOps.
Zacznijmy od pojęcia, które bywa nadużywane. Agent AI to nie chatbot podpowiadający komendy ani skrypt z zakodowanymi na sztywno krokami. To program oparty na dużym modelu językowym, który dostaje cel w języku naturalnym, sam rozkłada go na kroki, wywołuje realne narzędzia i - co najważniejsze - czyta wynik każdego kroku i decyduje, co dalej. Gdy komenda zwróci błąd, agent to widzi i próbuje inaczej, zamiast ślepo lecieć do końca.
Ta pętla to cała różnica. Zwykły skrypt w bashu wykonuje polecenia po kolei; gdy któreś się wywali, albo się zatrzymuje, albo brnie dalej z zepsutym stanem. Agent traktuje wynik jako informację zwrotną. Zobaczymy to później na żywym przykładzie: agent poprosi o storage, którego nie ma, dostanie błąd, sam sprawdzi listę dostępnych zasobów i poprawi konfigurację. Skrypt w tym miejscu po prostu by się wywrócił.
Warto od razu ustawić oczekiwania. Agent nie zwalnia z myślenia i nie zastępuje wiedzy o infrastrukturze. Jest raczej bardzo szybkim, cierpliwym juniorem, który zna składnię wszystkich narzędzi i nie męczy się powtarzaniem. Odpowiedzialność za to, co trafia na produkcję, dalej jest po naszej stronie - dlatego zaraz pokażemy, jak zamknąć agenta w bezpiecznych ramach: ograniczonych uprawnieniach, Pull Requestach i potoku CI. Jeśli samo pojęcie agenta jest dla Ciebie nowe, mamy osobny przewodnik po agentach AI.
Model językowy sam z siebie potrafi tylko generować tekst. Żeby zrobił cokolwiek na Proxmoksie, ktoś musi dać mu narzędzia. Tu wchodzi MCP (Model Context Protocol), protokół, który w ustandaryzowany sposób łączy asystenta AI z zewnętrznymi narzędziami. Po stronie infrastruktury uruchamiamy serwer MCP, który wystawia konkretne funkcje - na przykład wylistuj maszyny, utwórz kontener, uruchom komendę - a agent woła je tak, jakby wywoływał funkcje w kodzie, zamiast klikać w panelu.
Drugie pojęcie to skille, czyli gotowe procedury wielokrotnego użytku. Raz opisana czynność, na przykład postaw kontener z Debianem, zainstaluj serwer WWW i sprawdź, czy odpowiada, staje się klockiem, który agent odtwarza na zawołanie. Budujemy w ten sposób własną bibliotekę powtarzalnych operacji - tak samo jak wcześniej budowaliśmy bibliotekę skryptów, tylko o poziom wyżej. W praktyce w roli agenta wystąpi asystent w rodzaju Claude Code, a serwer MCP dla Proxmoksa to niewielka usługa, która pod spodem woła zwykłe API Proxmoksa. Kluczowe jest to, że agent nie dostaje pełnego dostępu do klikania po omacku - dostaje wąski, nazwany zestaw operacji, które ktoś świadomie mu udostępnił.
Teoria za nami - zróbmy to na Twoim własnym Proxmoksie. Całość sprowadza się do trzech rzeczy: ograniczonego tokenu (żeby agent nie dostał roota), małego serwera MCP (który tłumaczy API Proxmoksa na narzędzia dla agenta) i jednej komendy, która wpina ten serwer w Claude Code. Zajmuje to kilka minut, a od tego momentu rozmawiasz ze swoim klastrem po polsku.
Krok 1. Ograniczony token. Na węźle klastra, jako administrator, tworzymy rolę o wąskich uprawnieniach i wystawiamy dla niej token API. Do samego odczytu stanu wystarczą uprawnienia audytu; do stawiania maszyn dokładamy operacje na maszynach, dysku i sieci. Roota nie oddajemy agentowi ani na chwilę - do znaczenia poszczególnych uprawnień wracamy w sekcji o bezpiecznym podłączeniu.
# Na wezle klastra, jako administrator (root) - jednorazowo:
pveum role add AiAgent -privs "VM.Audit Datastore.Audit VM.Allocate \
VM.Config.CPU VM.Config.Memory VM.Config.Disk VM.Config.Network \
VM.Config.Options VM.PowerMgmt Datastore.AllocateSpace SDN.Use"
pveum user add agent-ai@pve
pveum aclmod / -user agent-ai@pve -role AiAgent
pveum user token add agent-ai@pve terraform --privsep 0
# token jest pokazywany RAZ przy tworzeniu - zapisz go w bezpiecznym miejscu
Krok 2. Mały serwer MCP. To kilkadziesiąt linii w Pythonie. Serwer wystawia kilka narzędzi - tutaj wypisanie węzłów i podsumowanie klastra - a pod spodem woła zwykłe API Proxmoksa z naszym tokenem. Tyle wystarczy, żeby agent zaczął widzieć realny stan. Zapisujemy to jako proxmox_mcp/server.py:
import os, json, ssl, urllib.request # tylko biblioteka standardowa - zero zaleznosci
from mcp.server.fastmcp import FastMCP # FastMCP: gotowy szkielet serwera MCP
# Adres panelu i token czytamy ze zmiennych srodowiskowych - nie trzymamy ich w kodzie:
ENDPOINT = os.environ["PROXMOX_ENDPOINT"].rstrip("/") # np. https://192.168.1.11:8006
TOKEN = os.environ["PROXMOX_TOKEN"] # format: user@realm!tokenid=sekret
# Panel Proxmoksa ma certyfikat self-signed, wiec dla tego polaczenia wylaczamy weryfikacje TLS:
_ctx = ssl.create_default_context()
_ctx.check_hostname = False
_ctx.verify_mode = ssl.CERT_NONE
mcp = FastMCP("proxmox") # tworzymy serwer MCP o nazwie "proxmox"
def _api(path):
# Jedno miejsce, ktore puka do API Proxmoksa - token doklejamy w naglowku Authorization:
req = urllib.request.Request(ENDPOINT + "/api2/json" + path,
headers={"Authorization": "PVEAPIToken=" + TOKEN})
# Odpowiedz to JSON; wlasciwe dane siedza pod kluczem "data":
return json.load(urllib.request.urlopen(req, context=_ctx))["data"]
@mcp.tool() # @mcp.tool() udostepnia funkcje agentowi jako narzedzie
def list_nodes() -> str:
"""Wypisuje wezly klastra Proxmox wraz ze statusem.""" # docstring - opis, ktory widzi agent
# /nodes zwraca liste wezlow; skladamy z niej tekst "nazwa: status", linia po linii:
return "\n".join(f"{n['node']}: {n['status']}" for n in _api("/nodes"))
@mcp.tool()
def cluster_summary() -> str:
"""Ile wezlow online, ile maszyn dziala, czy jest kworum."""
nodes = _api("/nodes") # lista wezlow klastra
vms = _api("/cluster/resources?type=vm") # lista maszyn i kontenerow
online = sum(n["status"] == "online" for n in nodes) # ile wezlow jest online
run = sum(v["status"] == "running" for v in vms) # ile maszyn faktycznie dziala
quorum = "tak" if online > len(nodes) // 2 else "nie" # kworum = wiecej niz polowa wezlow online
return f"Wezly {online}/{len(nodes)} online, dziala {run}/{len(vms)} maszyn, kworum: {quorum}"
if __name__ == "__main__":
mcp.run() # start na transporcie stdio - Claude Code rozmawia z serwerem przez stdin/stdout
Krok 3. Wepnij serwer w Claude Code. Jedna komenda rejestruje serwer i przekazuje mu adres panelu oraz token przez zmienne środowiskowe - token nie ląduje w żadnym pliku w repozytorium. Zaraz potem sprawdzamy, że Claude Code faktycznie się z nim łączy:
claude mcp add proxmox \
--env PROXMOX_ENDPOINT=https://192.168.1.11:8006 \
--env PROXMOX_TOKEN='agent-ai@pve!terraform=********' \
-- python proxmox_mcp/server.py
claude mcp list potwierdza połączenie: proxmox - Connected. Agent ma teraz do dyspozycji narzędzia Twojego Proxmoksa.Krok 4. Pierwsze zapytanie. Zgodnie z zasadą najpierw odczyt zaczynamy od pytania, które niczego nie zmienia. Prosimy agenta o raport - a on sam wybiera, które narzędzie MCP wywołać, czyta realny wynik i składa z niego odpowiedź po polsku:
To wszystko - agent jest podłączony do Twojego klastra i widzi jego realny stan. Reszta artykułu pokazuje, co da się na tym zbudować: od generowania kodu Terraform, przez samonaprawę po błędzie, aż po GitOps i skan bezpieczeństwa.
Zanim agent cokolwiek zrobi, warto wiedzieć, czym właściwie steruje. Agent nie wymyśla nowego narzędzia - wybiera i łączy te, które w DevOps znamy od lat. Cała rodzina nazywa się Infrastructure as Code (infrastruktura jako kod): zamiast klikać, opisujemy pożądany stan w plikach.
Różnica, na którą warto zwrócić uwagę, to model deklaratywny kontra proceduralny. W podejściu proceduralnym opisujemy kroki: zainstaluj to, uruchom tamto. W deklaratywnym opisujemy stan docelowy, a narzędzie samo określa, co trzeba zrobić, żeby go osiągnąć. Terraform jest deklaratywny i to jego trzymamy się w tym artykule, bo agentowi łatwo generować opis stanu, a Terraform bierze na siebie brudną robotę policzenia różnic. W dalszej części zobaczysz, jak bardzo to upraszcza życie przy zmianach i przy wychwytywaniu ręcznych zmian poza kodem.
Najgorsze, co można zrobić, to dać agentowi hasło roota do klastra i pozwolić mu na wszystko. Rozsądny pierwszy krok jest odwrotny: tworzymy rolę o minimalnych uprawnieniach i wystawiamy agentowi token API, który pozwala tylko na to, co faktycznie potrzebne. W Proxmoksie robimy to komendą pveum. Poprosiliśmy agenta, żeby przygotował sobie taki ograniczony dostęp:
Skąd bierze się to pierwsze połączenie z Proxmoksem? Samo utworzenie roli i tokenu wymaga uprawnień administratora, więc ten jeden, wstępny krok wykonujemy my - jako administrator klastra, łącząc się z węzłem po SSH i uruchamiając polecenia pveum. To celowe: konto roota pojawia się tylko na chwilę, żeby wykuć ograniczony token. Od tej pory agent dostaje do ręki wyłącznie ten token i całą dalszą pracę - odczyt stanu, stawianie maszyn, zmiany, skany - wykonuje już bez hasła roota, przez serwer MCP i Terraform, które tym tokenem się uwierzytelniają.
To jest zasada najmniejszych uprawnień (least privilege) w praktyce. Gdyby token wyciekł albo agent zrobił coś nie tak, największa możliwa szkoda ogranicza się do maszyn wirtualnych - nie do całego węzła. Token pokazujemy tylko raz przy tworzeniu, dlatego od razu ląduje w bezpiecznym miejscu, nigdy w repozytorium. Ograniczony token to pierwsza z kilku warstw, którymi trzymamy agenta w ryzach:
Druga zasada bezpiecznego wdrażania agenta brzmi: najpierw odczyt, potem zapis. Zanim pozwolimy agentowi cokolwiek tworzyć, dajemy mu operacje odczytu i prosimy o raport. To buduje zaufanie i od razu pokazuje, czy agent dobrze rozumie nasze środowisko. Poprosiliśmy o podsumowanie stanu klastra:
Zwróć uwagę na ostatnie zdanie odpowiedzi. Agent nie tylko wypisał dane - zauważył, że węzeł proxmox4 jest wyłączony, i sam ocenił, że nie blokuje to operacji, bo klaster ma kworum (większość węzłów pozwalającą podejmować decyzje, tutaj trzy z czterech głosów). Ta warstwa interpretacji odróżnia agenta od surowego zapytania do API. Ten sam stan floty widać w panelu Proxmoksa:
Teraz sedno. Chcemy nową maszynę, ale nie postawimy jej ręcznie. Poprosimy agenta, żeby opisał ją w Terraformie - a Terraform sam doprowadzi klaster do tego stanu. Zwróć uwagę, jak konkretne jest polecenie: to nadal język naturalny, ale z parametrami, które mają znaczenie dla infrastruktury.
Agent zwrócił gotowy plik main.tf. Na górze deklarujemy providera - wtyczkę, która uczy Terraform rozmawiać z konkretną platformą, tutaj z Proxmoksem. Od razu widać dobrą praktykę: w konfiguracji providera nie ma żadnego hasła.
terraform {
required_version = ">= 1.6"
required_providers {
proxmox = {
source = "bpg/proxmox"
version = "~> 0.66"
}
}
}
# Poswiadczenia czytane ze zmiennych srodowiskowych (PROXMOX_VE_*),
# nigdy nie trzymamy hasel w repozytorium.
provider "proxmox" {
insecure = true
ssh {
agent = false
}
}
Sam kontener opisujemy jako jeden zasób. To jest cała definicja maszyny - deklaratywna, czytelna, gotowa do trzymania w repozytorium:
resource "proxmox_virtual_environment_container" "ai_demo" {
node_name = "proxmox1"
vm_id = 990
description = "Demo utworzone przez agenta AI przez Terraform"
tags = ["ai-demo", "terraform"]
unprivileged = true
started = true
initialization {
hostname = "ai-devops-demo"
ip_config {
ipv4 { address = "dhcp" }
}
}
operating_system {
template_file_id = "nfs-storage:vztmpl/debian-12-standard_12.12-1_amd64.tar.zst"
type = "debian"
}
cpu { cores = 1 }
memory { dedicated = 512 }
disk { datastore_id = "nfs-storage", size = 4 }
network_interface { name = "eth0", bridge = "vmbr0" }
}
Poświadczenia przekazujemy przez zmienne środowiskowe. Dzięki temu hasło nie ląduje w pliku ani w historii Gita - provider bpg/proxmox sam czyta zmienne z prefiksem PROXMOX_VE_. Potem trzy komendy: init pobiera providera, plan pokazuje, co powstanie (nic jeszcze nie zmieniając), a apply wykonuje zmianę.
export PROXMOX_VE_ENDPOINT="https://192.168.1.11:8006/"
export PROXMOX_VE_USERNAME="agent-ai@pve!terraform"
export PROXMOX_VE_PASSWORD="********"
terraform init # pobiera providera bpg/proxmox
terraform plan # pokazuje, co powstanie - nic jeszcze nie zmienia
terraform apply # dopiero teraz tworzy maszyne
Komenda plan jest tu cichym bohaterem. Terraform pokazuje dokładnie, co zamierza zrobić, zanim cokolwiek ruszy - to bezpieczna klamra, której brakuje ręcznym skryptom. Oto realny wynik z naszego klastra:
terraform apply na naszym klastrze. Kontener powstał w 13 sekund. Na dole Terraform zwraca zdefiniowane wcześniej wartości wyjściowe: nazwę i numer maszyny.Trzynaście sekund od komendy do działającej maszyny. Gdyby agent uruchomił apply drugi raz bez zmian w pliku, Terraform nie zrobiłby nic - stwierdziłby, że rzeczywistość już zgadza się z opisem. Ta właściwość nazywa się idempotencją (wielokrotne wykonanie daje ten sam efekt co jednokrotne) i jest fundamentem spokojnego snu w DevOps.
Jeden kontener to demonstracja. Prawdziwa siła Infrastructure as Code pojawia się, gdy z tego samego opisu chcemy postawić dziesięć maszyn różniących się kilkoma parametrami. Zamiast kopiować blok dziesięć razy, wyciągamy zmienne i używamy pętli for_each. Poprosiliśmy agenta o refaktoryzację:
variable "kontenery" {
description = "Flota kontenerow: nazwa -> parametry"
type = map(object({
vm_id = number
cores = number
memory = number
}))
default = {
"web-01" = { vm_id = 990, cores = 1, memory = 512 }
"web-02" = { vm_id = 991, cores = 2, memory = 1024 }
"web-03" = { vm_id = 992, cores = 2, memory = 2048 }
}
}
resource "proxmox_virtual_environment_container" "flota" {
for_each = var.kontenery
node_name = "proxmox1"
vm_id = each.value.vm_id
cpu { cores = each.value.cores }
memory { dedicated = each.value.memory }
# reszta definicji jak wczesniej: system, siec, dysk...
}
Teraz dodanie czwartej maszyny to dopisanie jednej linii do zmiennej. Terraform sam policzy, że trzeba dodać jeden kontener, a reszty nie ruszać. To jest ta różnica, o której mówiliśmy przy porównaniu narzędzi: opisujemy stan, nie kroki. Agent świetnie sobie radzi z takim refaktorem, bo to mechaniczna, powtarzalna zmiana - dokładnie ten rodzaj pracy, który najlepiej mu oddać.
Obiecaliśmy pokazać pętlę agenta w akcji. Oto ona. Celowo kazaliśmy agentowi użyć storage o nazwie fast-ssd, którego na naszym klastrze nie ma. Zwykły skrypt wywaliłby się i zostawił nas z błędem. Zobaczmy, co robi agent:
To jest ta różnica między agentem a skryptem, sprowadzona do jednego zrzutu. Terraform zwrócił konkretny błąd z Proxmoksa: storage fast-ssd does not exist. Agent go przeczytał, wykonał pvesm status żeby zobaczyć, jakie storage są dostępne, wybrał nfs-storage, poprawił jedną linię w konfiguracji i uruchomił apply ponownie - tym razem z sukcesem. Nikt nie musiał interweniować. Właśnie po to jest pętla obserwuj i popraw z pierwszej sekcji.
Jest jeszcze jeden problem, który Infrastructure as Code rozwiązuje po cichu, a który potrafi zatruć życie przy ręcznym zarządzaniu: stan maszyny rozjeżdża się z kodem (po angielsku nazywa się to configuration drift). Dzieje się, gdy ktoś zmieni coś na maszynie bezpośrednio, poza kodem - na przykład szybko podbije pamięć w panelu, żeby ugasić pożar, i zapomni to zapisać. Rzeczywistość rozjeżdża się z opisem. Zasymulowaliśmy to i poprosiliśmy agenta o sprawdzenie:
Terraform po cichu odświeżył stan realny, porównał go z kodem i pokazał: Objects have changed outside of Terraform, a pamięć różni się o dokładnie tę wartość, którą ktoś zmienił ręcznie. Jedno terraform apply przywraca stan zapisany w repozytorium. To jest sedno podejścia: kod jest jedynym źródłem prawdy, a wszystko, co się od niego oddaliło, da się wykryć i cofnąć. Bez tego po pół roku nikt już nie wie, dlaczego dana maszyna wygląda tak, a nie inaczej.
Skoro cała infrastruktura jest teraz kodem, traktujmy ją jak kod. Plik main.tf trafia do repozytorium Git i zaczynamy pracować w modelu GitOps: repozytorium jest jedynym źródłem prawdy o stanie infrastruktury, a każda zmiana wchodzi przez Pull Request (propozycję zmiany, którą ktoś przegląda i zatwierdza), nigdy przez ręczne dłubanie na serwerze.
Do repozytorium dokładamy potok CI (Continuous Integration - automatyczne sprawdzanie kodu przy każdej zmianie). Na start nie musi wdrażać; wystarczy, że sprawdzi formatowanie i poprawność konfiguracji Terraform. Plik dla GitHub Actions opisujemy raz:
name: IaC CI
on:
push:
branches: [main]
pull_request:
jobs:
terraform:
name: Terraform fmt + validate
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: hashicorp/setup-terraform@v3
with:
terraform_version: 1.9.8
- name: Sprawdzenie formatowania
run: terraform -chdir=infra fmt -check -diff
- name: Inicjalizacja (bez backendu)
run: terraform -chdir=infra init -backend=false
- name: Walidacja konfiguracji
run: terraform -chdir=infra validate
Teraz scenariusz z życia. Chcemy zwiększyć pamięć kontenera. Nie edytujemy niczego ręcznie na serwerze - mówimy agentowi, czego chcemy, a on przygotowuje zmianę i otwiera Pull Request:
Po otwarciu Pull Requesta GitHub Actions automatycznie uruchomił nasz potok - sprawdził formatowanie, pobrał providera, zwalidował konfigurację, wszystko na zielono, zanim człowiek w ogóle spojrzał na zmianę:
Największa wartość GitOps ujawnia się, gdy coś pójdzie źle. Skoro stan infrastruktury to historia commitów, cofnięcie awaryjnej zmiany wygląda dokładnie jak cofnięcie błędu w kodzie aplikacji:
git revert HEAD # tworzy commit odwracajacy ostatnia zmiane
git push # potok CI rusza ponownie
# po scaleniu terraform apply przywraca poprzedni, dzialajacy stan
Zamiast gorączkowego klikania po panelu w środku nocy - jeden commit i infrastruktura wraca do znanego, działającego stanu. O wpinaniu asystenta AI w takie potoki napisaliśmy szerzej w artykule o automatyzacji potoku CI/CD z AI.
Stawianie maszyn to jedno, ale codzienność DevOps to też zarządzanie tym, co już działa: zbieranie informacji z wielu hostów, instalowanie pakietów, pilnowanie konfiguracji. Klasycznie robimy to Ansiblem albo skryptami po SSH. Agent potrafi wejść w tę rolę, a instrukcje dostaje po polsku:
Zwróć uwagę na ostatnią linię. Agent nie zakończył pracy na komunikacie zainstalowano - sam wykonał zapytanie HTTP i potwierdził, że serwer zwraca HTTP 200. To znowu ta sama pętla: działanie, obserwacja, weryfikacja celu. Ansible też by to zrobił, ale musielibyśmy najpierw napisać każdy krok. Tutaj opisaliśmy cel jednym zdaniem, a agent dobrał komendy i sprawdził efekt. Narzędzia nie idą do kosza - agent najczęściej korzysta z nich pod spodem. Zmienia się warstwa, na której pracujemy: z pisania każdej komendy na opisywanie celu i pilnowanie, żeby efekt był zgodny z zamiarem.
Automatyzacja bez kontroli bezpieczeństwa to proszenie się o kłopoty. Dlatego do procesu dokładamy skanowanie. Nasz kontener dostał serwer nginx w wersji 1.22.1 - poprosiliśmy agenta, żeby sprawdził, czy obraz tej wersji nie ciągnie za sobą znanych podatności:
To realny, niewygodny wynik: 176 podatności, z czego 19 krytycznych. Nie dlatego, że nginx jest zły, tylko dlatego, że przypięliśmy starą wersję opartą na przestarzałym systemie bazowym. Wartość agenta polega tu na tym, że nie zostawia nas z suchą listą - wskazuje przyczynę i proponuje konkretny następny krok: przypiąć nowszy obraz i wpiąć skan do potoku CI, żeby taki problem został wyłapany automatycznie przy kolejnej zmianie. To ta sama piąta warstwa, którą widzieliśmy na diagramie bezpieczeństwa. Podobne podejście do przeglądów kodu opisaliśmy w artykule o wyszukiwaniu podatności aplikacji webowej.
Uczciwie: agenci w DevOps nie są odpowiedzią na wszystko. Najwięcej dają tam, gdzie zadania są powtarzalne, dobrze opisane i mają jasny sposób weryfikacji - stawianie środowisk testowych, przygotowywanie kodu IaC, refaktory takie jak przejście na for_each, zbieranie informacji z floty, rutynowe przeglądy. W takich miejscach oszczędność czasu bywa liczona w kilku godzinach dziennie, bo znika przełączanie się między narzędziami i przepisywanie tych samych komend.
Ostrożniej podchodzimy tam, gdzie błąd jest kosztowny i trudny do cofnięcia: operacje na produkcyjnych bazach, zmiany sieci odcinające dostęp, akcje bez sensownego podglądu tego, co się stanie. Tam agent może przygotować propozycję, ale ostatnie słowo należy do człowieka. Zdrowy model to nie pełna autonomia, tylko agent jako bardzo sprawny asystent działający w ramach, które sami wyznaczamy - dokładnie tych, które budowaliśmy przez cały ten artykuł.
Nie trzeba zaczynać od produkcji ani od pełnej automatyzacji. Wystarczy jedno bezpieczne środowisko - może być darmowy Proxmox na starym komputerze albo lokalny Docker - podłączony agent z ograniczonym tokenem i jedno realne zadanie do przejścia od początku do końca. Gdy zobaczysz, że agent poprawnie czyta stan i generuje sensowny kod, kolejne warstwy - Terraform, Pull Requesty, skany - dokładasz stopniowo.
Przeszliśmy pełną drogę: od zdania w języku naturalnym, przez ograniczony token i protokół MCP, wygenerowany kod Terraform, realny kontener na klastrze Proxmox, refaktor na flotę, samonaprawę po błędzie, wykrycie ręcznych zmian poza kodem, Pull Request z potokiem CI, zarządzanie flotą aż po skan bezpieczeństwa. Wszystko na żywej infrastrukturze i z prawdziwymi wynikami, łącznie z tymi niewygodnymi. Najważniejszy wniosek nie brzmi agent zastąpi DevOps-a. Brzmi: agent przenosi nas o poziom wyżej - z ręcznego wykonywania komend do opisywania celów i pilnowania, żeby to, co ląduje na infrastrukturze, było świadome, przejrzane i odwracalne.
To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.
★★★★★Średnia ocena naszych szkoleń w Google: 5/5
Komentarze (0)
Brak komentarzy...