Nemrég zártuk le az előző évet és máris itt egy újabb év, túl vagyunk a pezsgő pukkanásán és a karácsonyi hangulaton. Bár még csak január van, már most rengeteg ötletem van 2026-ra, amelyekből szeretnék néhányat megosztani veletek. Nem nagy bejelentések ezek, inkább olyan döntések és változások, amelyek csendben, de határozottan formálják majd az előttünk álló hónapokat.
Tervek
Idén is foglalkozom azokkal a technológiai területekkel, amelyek az elmúlt években is meghatározták a munkámat. Felhő, DevOps, automatizálás, Kubernetes, AI – ezek nem elszigetelt témák, hanem egymásra épülő rendszerek és gondolkodásmódok. 2026-ban sem az a célom, hogy minden újdonságot azonnal feldolgozzak, sokkal inkább az, hogy értelmezhetővé tegyem őket. Érdekel, hogyan kapcsolódnak össze, mit jelentenek a gyakorlatban, és milyen következményeik vannak egy valós környezetben.
Blog
Ezzel párhuzamosan a blog maga is változik. Az oldal struktúrája átalakul, letisztultabb lesz, és a cikkek egyértelműen a blog menüpont alá kerülnek. Ez nem látványos redesign, inkább egy tudatos egyszerűsítés. Szeretném, ha az írások könnyebben megtalálhatók lennének, ha az oldal logikája magától értetődőbb lenne, és nem kellene azon gondolkodni, hol érdemes keresni egy korábbi cikket. Kevesebb kerülőút, tisztább felépítés, jobb áttekinthetőség – számomra ez most fontosabb, mint bármilyen extra funkció.
LinkedIn
A cikkek elérésében is lesz változás. Az új írások a könnyebb követhetőség miatt az én LinkedIn-profilomon is megjelennek majd. Így ott is olvashatók lesznek, ahol sokan amúgy is napi szinten jelen vagytok, és ahol gyorsabban elindulhat egy-egy szakmai gondolatmenet vagy beszélgetés. Fontos viszont, hogy a korábban megjelent cikkek továbbra is elérhetők maradnak a Cloud Mentor LinkedIn-oldalon, tehát a régi anyagok nem tűnnek el, csak bővül a hozzáférésük.
Evolvia
Evolvia is újabb fejlődési szakaszba lép 2026-ban. A rendszer új architektúrára kerül, mert a jelenlegi megoldás már nem szolgálja ki megfelelően azt az igényt, amely a megnövekedett használattal együtt jelent meg. Ez nem pusztán technikai frissítés: a cél egy stabilabb, skálázhatóbb alap, amely hosszú távon is elbírja a terhelést.
Emellett bővítem a gyakorló környezetek számát is, hogy többféle technológiát, többféle helyzetet lehessen valós környezetben kipróbálni. Ez számomra is fontos, mert a tanulás és a megértés kulcsfontosságú a technológiák elsajátításában.
Várom ezt az évet, hogy megmutathassam az ötleteimet. Remélem, legalább akkora örömmel fogadjátok majd őket, amekkora kedvvel és odafigyeléssel készülök rájuk.
Itt az évvége, amikor meg kell állnunk egy kicsit, hogy visszatekintsünk, mi is történt idén. Nem egy hosszas elemzést végzünk, csupán megnézzük, mit értünk el, és hogyan szeretnénk átlépni a következő évbe.
Én is így teszek most, ebben a cikkben. Ez nekem minden évben fontos, hogy lássam, hová jutottam el a tavalyi cikkemtől. Ami teljesen bizonyos, hogy teljesen más irányt vett az életem, mint ahogy azt előre vártam. Egy olyan irányba fordultam, amit régen érzek magamban, de nem tudtam, beérik-e valaha, de ne szaladjunk ennyire előre.
Tavaly az alábbi sorokkal búcsúztattam az évet:
2025-ben is folytatom az utamat a technológia és a tanulás világában, és bízom benne, hogy velem tartotok ezen az izgalmas utazáson. Terveim szerint rengeteg új témával, praktikus példákkal és inspiráló tartalmakkal készülök nektek.
Nézzük mi is történt, hogyan fejlődtem, milyen megéléseim voltak.
Köszönöm
Először is szeretném megköszönni a Feleségemnek a sok-sok támogatást, amit mindig és folyamatosan kapok Tőle. Ő az, aki mindig inspirál és átsegít a nehéz pillanatokon.
Kiemelt köszönet azoknak, akik követik munkásságomat és támogatnak a mindennapokban, azzal hogy olvassák cikkeimet vagy tanácsot kérnek a szakmai fejlődésükhöz.
Hálás vagyok a Mentor Klubnak is, hogy már több mint 3 éve egy inspiráló, baráti és motiváló együttműködés keretében tesszük jobbá a világot azzal, hogy a fejlődni és váltani vágyóknak biztosítjuk a lehetőséget a tanulásra.
Összességében szeretném megköszönni a sok kedves visszajelzést és energiát, amit rendszeresen kapok. Ez motivál arra, hogy a következő időszakban is tovább folytassam az utam és rendszeres megújulásokon keresztül még jobb és praktikus témákat hozzak nektek.
Oktatás és mentorálás
Ebben az évben a Mentor Klubon belül kicsit bővítettük azt a palettát, amit nyújtok a fejlődni vágyóknak. Már nem csupán szakmai képzéseken (Azure, AWS) találkozhattatok velem, hanem volt egy nagyon jó hangulatú karrier-tanácsadás is.
Egy olyan élő lehetőség, ahol bárki kérdezhetett tőlem a karriercéljai és esetleges nehézségei kapcsán. Ezen az eredetileg 2 órásra tervezett (végül 2,5 órás) interaktív beszélgetésen több mint 190 ember vett részt és ennek többszöröse az, aki utólag nézte vissza a felvételt. Ez fantasztikus és felemelő volt egyszerre.
És ez csak egy kis szelete annak a több mint 1000 hallgatónak, akik résztvettek idén a képzéseimen vagy online, vagy offline módon. Hihetetlenül sok energiát kapok ezeken keresztül is.
Hiszen felhő képzéseimen is megnőtt az érdeklődők száma, ami jól mutatja, hogy a felhő egy fontos összetevője a jelenlegi informatika világának. Ráadásul a mesterséges intelligencia térhódításával, talán még fontosabb lett, mint korábban.
Az év negyedik negyedévében lett két mentoráltam is, akikkel 2 hetente még mélyebbre ássuk magunkat a felhő és a modern karrierváltás világába. Rajtuk keresztül még jobban látom, mennyit ér a kitartó és kemény munka, ha valaki szeretné megvalósítani az álmait.
2025-ben indítottam útjára az ingyenes karrier-tanácsadási kérdőívemet, a Felhő Iránytűt, amit február vége és november vége között húszan töltöttétek ki. Nekik személyre szabott felhő karrier tanácsokat adtam, amit a visszajelzések alapján mindenki kiemelten hasznosnak tartott.
Evolvia – a büszkeségem
Az Evolvia számomra különösen fontos. Ez egy olyan felhőalapú gyakorló platform, amelyet teljes egészében egyedül építettem fel. Az volt a célom, hogy ne csak beszéljünk a technológiáról, hanem valódi, gyakorlati környezetben lehessen kipróbálni, megtapasztalni és megtanulni.
Az Evolvia pontosan azt a hiányt tölti ki, amit én is sokszor éreztem korábban: az elmélet és a gyakorlat közötti szakadékot. A fejlesztését 2026-ban is folytatom, hogy még több ember számára legyen elérhető, használható és értékes tanulási lehetőség.
Az Evolvián jelenleg olyan gyakorlati képzések érhetők el, amelyek az Azure alapjaitól indulnak, és fokozatosan vezetnek el az összetettebb, valós életből vett megoldásokig. A cél végig ugyanaz: ne csak értsük, miről szól egy szolgáltatás, hanem saját kézzel hozzuk létre, konfiguráljuk és működtessük.
A tananyagok lefedik az Azure Portál használatát, a virtuális gépek és hálózatok létrehozását, a terheléselosztást és a skálázhatóság alapjait, valamint a CloudShell és az Azure CLI gyakorlati alkalmazását. Ezekre épülnek a modernebb irányok is, mint az App Service alapú webalkalmazások, a DevOps folyamatok automatizálása, a Docker-alapú telepítések, vagy akár az AI-hoz kapcsolódó megoldások, például az OpenAI és RAG-alapú alkalmazások Azure környezetben.
Alkotás és kódolás
Ezen a területen is sokat tevékenykedtem idén. 2025-ben ezzel a cikkel együtt 88 alkalommal osztottam meg veletek valamilyen tudást vagy információt. Remélem, hogy hasznos számotokra és jövőre is velem tartotok.
Munkám során és a hobbi projektjeim keretein belül több mint 33 075 kódsort írtam több mint 18 GitHub repository-ba, amelyekkel valamilyen Cloud, AI valamint DevOps projektet keltettem életre vagy járultam hozzá annak hatékonyabb működéséhez.
Az alkotás itt nem állt meg. Az általam tartott képzésekhez idén 542 db prezentációs diát készítettem, amelyeket az élő- és videós képzésekhez készítettem nektek.
Ebben az évben 3 új – általam készített – videós képzéssel is megajándékozott Titeket a Mentor Klub. Ezek széles spektrumon mozognak: DevOps & SRE, AI, NoCode-LowCode. Igazán izgalmas volt ezeket elkészíteni, mert tudtam, hogy hasznos és használható tudást adhatok nektek ezzel.
Tanulás
Ahogy előrevetítettem, idén is rengeteget tanultam. Évelején elkezdtem a felkészülést a Certified Kubernetes Administrator (CKA) vizsgára, amely kapcsán volt néhány negatív megélésem. Rájöttem, hogy nem egy újabb technológiai vizsga az az út vagy irány ami a jövőm.
Ez a megélés meghatározta az év nagy részét, így egy valódi hullámvasút érzést adott. Izgalmas volt, de nyár végére rájöttem egy új, nagyobb cél, amit nekem szánt a sors.
Emiatt tanulásomat 2025-ben a vezetői soft skill képzések tették ki, ezen belül is az új irány a Leadership, azaz a menedzsment irány. Lehetőségem volt a Harvard ManageMentor keretében több mint 25 tanúsítványt szereznem. Izgalmas és új utazás volt, ahol azt tanulhattam és tanúsíthattam, hogyan tudok embereket vezetni.
Olyan képességeimet tudtam fejleszteni mint a delegálás, coaching, mentoring, visszajelzések kezelése, emberek vezetése, AI alkalmazása a vezetésben, és még sok-sok hasonló. Érdekes hónapok voltak ezek is.
2025-ben bennem is – ahogy már utaltam rá – sok minden átrendeződött. Nem egyik napról a másikra, inkább lassan, szinte észrevétlenül. Ebben új munkahelyem is segített. Egyre világosabb lett, hogy már nem az hajt igazán, hogy minél több dolgot csináljak, hanem az, hogy amit csinálok, annak valódi súlya és értelme legyen.
Megváltozott a fókuszom. Tudatosabban választok témákat, embereket, irányokat. Sokkal fontosabb lett számomra a mélység, mint a mennyiség, és az, hogy ne csak technológiai problémákat oldjak meg, hanem embereknek segítsek eligazodni, dönteni, fejlődni.
Ami viszont igazán világossá vált 2025-ben, az egy régi belső gondolat megerősödése volt: régóta éreztem magamban a vezetői irányt. Idén ez letisztult, kimondhatóvá vált, és ennek megfelelően kezdtem el tudatosan rendezni az életemet – szakmailag és emberileg egyaránt.
A karrieremben is ebbe az irányba haladok tovább, amit már nyíltan vállalok. Ennek a változásnak része az is, hogy a szakmai jelenlétemben – például a LinkedIn profilomon – már DevOps leaderként határozom meg magam.
Ez nem egy hirtelen váltás, hanem egy irány, amely mostanra érett meg bennem igazán.
A következő lépés
A következő időszak számomra egyértelműen a vezetői karrier tudatos építéséről szól. Ez már nem kérdés, hanem irány. Úgy érzem, ebben a szerepben tudok igazán többet adni: tapasztalatot, rálátást, iránymutatást.
A technológiát természetesen nem engedem el. A Cloud és az AI továbbra is központi része marad annak, amivel foglalkozom. Vannak technológiai terveim és törekvéseim is a következő évre, de ezekről egyelőre még nem szeretnék részletekbe menni.
2026-ban is folytatom az oktatást és a mentoringot, sőt, még több energiát szeretnék ebbe az irányba tenni. Akár képzésekről, akár személyes mentorprogramról vagy vizsgafelkészítésről van szó, továbbra is az a célom, hogy valódi segítséget adjak azoknak, akik fejlődni vagy váltani szeretnének.
Köszönöm, hogy idén is velem tartottatok. Jövőre is várlak benneteket a Mentor Klub képzésein, egy személyes mentorprogramban vagy egy vizsgafelkészítőn.
Kellemes ünnepeket kívánok, és találkozunk 2026-ban!
Több tucat cikket olvashattatok tőlem a felhőszolgáltatások alapfogalmairól, és arról is, hogyan kommunikálnak egymással a különböző rendszerek. Ebben a cikkben egy olyan területet hozok közelebb, amely látszólag egyszerűnek tűnik, mégis meglepően sok félreértés forrása.
Egy saját történettel kezdem: amikor először készítettem több rétegű felhős alkalmazást, órákon át kerestem, miért nem érhető el a szolgáltatásom. A hiba mindössze annyi volt, hogy egy helytelenül megadott URL miatt teljesen más címre irányítottam a kéréseket. Ez volt az első alkalom, amikor igazán megértettem, mennyire fontos a pontos URL-használat.
A felhőben dolgozó szakemberek nap mint nap találkoznak API-végpontokkal, szolgáltatási URL-ekkel, konténerek belső hivatkozásaival és különböző load balancer címsémákkal. Ezek mind egy közös alapelvre épülnek: az URL szerkezetére. Ahhoz, hogy valaki magabiztosan mozogjon bármelyik felhős platformon, elengedhetetlen, hogy pontosan értse, mit is jelent egy URL, és hogyan működik.
Mi az az URL és miért létezik?
Az URL (Uniform Resource Locator) egy szabványos formátum, amely meghatározza, hogy az interneten vagy egy privát hálózaton belül hol található egy erőforrás, és milyen protokollon keresztül lehet elérni. A weboldalak címe, egy API végpontja, egy belső szolgáltatás címe: mind URL.
Példa: https://api.evolvia.hu/gyakorlat/42
Ez nem egy véletlenszerű karakterhalmaz, hanem precízen meghatározott elemekből áll.
Egy URL szerkezete
Egy tipikus URL több kötelező és opcionális részből épül fel:
https://cloudmentor.hu:443/eleresi/ut/?lekerdezes=ertek#szekcio
└───┬──┘└─────┬──────┘└─┬─┘└────┬────┘└───────┬───────┘└──┬───┘
Protokoll Domain Port Útvonal Query Fragment
Az egyes részek szerepe:
Protokoll Meghatározza, milyen szabályrendszerrel történik a kommunikáció. Leggyakoribb: http, https
Domain vagy IP-cím A cím, amelyhez a kérés érkezik. Példák: example.com 192.168.1.10 localhost – saját gépre mutat
Port A szerveren futó adott szolgáltatás eléréséhez szükséges. HTTP: 80 HTTPS: 443 API-k esetén gyakran egyedi, például: http://localhost:8080
Útvonal (Path) Az erőforrás helye a szerveren belül. Példa: /api/v1/orders
Query paraméterek Opcionális adatok a kéréshez kapcsolódóan. Példa: ?sort=asc&page=2
Fragment Oldalon belüli hivatkozás, például egy szakaszra ugráshoz.
Gyakori URL-típusok és példák
1. Helyi fejlesztés: localhost http://localhost:3000/api/test Ez a saját gépre mutat, amit fejlesztők naponta használnak alkalmazások és API-k tesztelésére.
2. IP-cím alapú elérés http://10.0.0.5:8080/health Jellemző konténerek, virtuális gépek vagy belső hálózati szolgáltatások esetén.
3. Felhős API-végpontok https://myapp.azurewebsites.net/api/login https://abc123.execute-api.eu-west-1.amazonaws.com/prod/items Ezek minden felhőszolgáltató esetén hasonló logikát követnek.
4. Belső szolgáltatás hivatkozása Kubernetesben http://redis-master.default.svc.cluster.local:6379 Ez jól mutatja, hogy az URL nem csak internetes cím lehet, hanem klaszteren belüli erőforrás is.
Miért fontos ez a felhőben dolgozó szakemberek számára?
Egy felhőmérnök, DevOps vagy SRE munkája szinte minden nap érinti az URL-eket. API-k hívása, szolgáltatások összekapcsolása, webhookok beállítása, konténerek közötti kommunikáció, gateway routerek konfigurálása: mind olyan feladat, ahol egy hibás karakter is működésképtelenné tehet rendszereket.
Pontosan értve az URL szerkezetét:
gyorsabban lehet hibát keresni
megbízhatóbban lehet szolgáltatásokat összekötni
tisztábban értelmezhetők logok és monitoring adatok
könnyebbé válik a skálázható rendszertervezés
A felhőben minden kommunikáció URL-ekre épül. Aki érti az alapokat, stabil alapot kap a magasabb szintű architektúrákhoz.
Leggyakoribb hibák kezdők körében
Rosszul megadott protokoll: http helyett https
Port kihagyása olyan szolgáltatásnál, ahol nem alapértelmezett (alapértelmezett portok például: 80 – HTTP, 443 – HTTPS)
Query paraméterek helytelen formázása
Localhost és külső elérési címek összekeverése
Privát IP és publikus IP nem megfelelő használata
Ezek mind egyszerű hibák, mégis órákat vehetnek el a hibakeresésből.
HTTP és HTTPS közötti különbség
A webes kommunikáció két leggyakrabban használt protokollja a HTTP és a HTTPS. Bár a két rövidítés csak egyetlen betűben tér el, a mögöttük lévő technológiai különbség alapvetően meghatározza a biztonságot, a hitelesítést és az adatok védelmét. Felhőben dolgozó szakembereknek ez kiemelten fontos, hiszen az alkalmazások, API-k és háttérszolgáltatások nagy része érzékeny adatokat kezel.
HTTP – titkosítás nélküli kommunikáció
A HTTP (Hypertext Transfer Protocol) az alapvető webes protokoll, amely szabályozza, hogyan kommunikál a kliens és a szerver. A HTTP-ben az adatok titkosítatlan formában utaznak, vagyis bárki, aki valamilyen módon hozzáfér a hálózati forgalomhoz, elméletben képes lehet kiolvasni a küldött vagy fogadott tartalmakat. Ez ma már csak fejlesztési, belső hálózati vagy nagyon specifikus esetekben elfogadható.
HTTPS – titkosított és hitelesített kapcsolat
A HTTPS (HTTP Secure) ugyanezt a kommunikációs modellt használja, de kiegészül TLS-alapú titkosítással. A TLS (Transport Layer Security) gondoskodik arról, hogy a kliens és a szerver között áthaladó adatok ne legyenek olvashatók harmadik fél számára. Emellett a szerver hitelesítése is megtörténik tanúsítványok segítségével.
Ez azt jelenti, hogy:
a forgalom titkosított
a kliens meggyőződik arról, hogy valóban a megfelelő szerverhez csatlakozik
az adatok nem módosíthatók észrevétlenül útközben
Miért számít ez a felhőben?
A modern felhőalapú rendszerekben elképzelhetetlen HTTPS nélkül dolgozni. API-k, belső menedzsment felületek, mikroszolgáltatások közötti kommunikáció: mind olyan elemek, ahol a biztonság és az integritás prioritás.
A HTTPS használata azért kritikus:
védi a hitelesítési adatokat
megakadályozza az adatok lehallgatását
biztosítja, hogy a kliens valós szolgáltatással kommunikál
megfelel biztonsági előírásoknak és iparági szabványoknak
Gyakorlati különbségek a fejlesztő szemszögéből
A HTTPS URL-ek https:// előtaggal kezdődnek, a HTTP pedig http:// formát használ
A HTTPS alapértelmezett portja 443, míg a HTTP-é 80
HTTPS esetén szükség van tanúsítványra, amely lehet publikusan hitelesített vagy saját aláírású
Összefoglalás
Az URL nem pusztán egy webcím. Ez a modern internet egyik legfontosabb építőköve. A felhőben dolgozó szakemberek számára pedig különösen lényeges alapelem, hiszen minden szolgáltatás, API, konténer és infrastruktúra modul ezen keresztül kommunikál. Aki tisztában van az URL felépítésével és működésével, sokkal tudatosabban és gyorsabban fogja megérteni a felhős rendszerek belső működését.
Aki régóta dolgozik AWS-el, mint én is, jól ismeri azokat az értesítéseket, amelyekben a szolgáltató biztonsági vagy karbantartási okokból módosításokat kér az infrastruktúrán. Október végén ismét érkezett egy ilyen e-mail, ezúttal az Amazon Bedrock felhasználóinak címezve. A levélben az Anthropic Claude 3.7 Sonnetmodell kivezetéséről (deprecation) értesítik az ügyfeleket.
A Claude 3.7 Sonnet modellt az AWS Bedrockon keresztül sok fejlesztő és szervezet használta az elmúlt hónapokban különféle természetes nyelvi feldolgozási (NLP) és generatív AI feladatokra. Az Anthropic most hivatalosan megkezdte ennek a modellnek a kivezetését, amely több lépcsőben történik.
A legfontosabb dátumok
2026. január 27. – a modell az úgynevezettExtended Accessállapotba kerül. Ez a szakasz már nem tartalmaz új kvótanöveléseket, és a támogatás is korlátozott lesz.
2026. április 28. – a modell End-of-Life (EOL) státuszba kerül, vagyis végleg elérhetetlenné válik. Ezt követően minden, a Claude 3.7 Sonnet modell ID-jére küldött kérés automatikusan hibát fog adni.
Érintett régiók
A változás az összes fő Bedrock-régiót érinti, többek között az európai adatközpontokat is (pl. eu-central-1, eu-north-1, eu-west-1, eu-west-3).
US-EAST-1
US-EAST-2
US-WEST-2
AP-NORTHEAST-1
AP-NORTHEAST-2
AP-NORTHEAST-3
AP-SOUTH-1
AP-SOUTH-2
AP-SOUTHEAST-1
AP-SOUTHEAST-2
EU-CENTRAL-1
EU-NORTH-1
EU-WEST-1
EU-WEST-3
Mit kell tenni?
Az AWS azt javasolja, hogy a felhasználók mielőbb váltsanak az Anthropic Claude Sonnet 4.5 modellre. Ez az új verzió fejlettebb teljesítményt és jobb biztonsági támogatást kínál.
Frissítés lépései az AWS Bedrock konzolon:
Lépj be az Amazon Bedrock konzolra.
A bal oldali menüben válaszd a Model catalog menüpontot.
Keresd meg a Claude 3.7 Sonnet modellt, és jegyezd fel a modellazonosítót (Model ID).
Ezután válaszd ki az új Claude 4.5 Sonnet modellt a listából (Model ID).
A fejlesztői környezetedben (például Python SDK-ban vagy API hívásban) cseréld le a régi modellazonosítót az újra.
A dokumentációkban pontos példák is találhatók, hogyan frissíthető a modell az API-hívásokban vagy SDK-ban. Ezek a Bedrock Model IDs és a Bedrock API Reference oldalon érhetők el.
Összefoglalva
A Claude 3.7 Sonnet kivezetése egy tervezett, fokozatos folyamat, amely 2026 tavaszára zárul le. Akik jelenleg is használják a modellt, érdemes minél előbb átállni a Claude Sonnet 4.5 verzióra, hogy az alkalmazások működése zavartalan maradjon.
Aki régen dolgozik Azure-ban, mint én is, rendszeresen kap értesítő e-maileket, amelyekben biztonsági okokból kérik a felhasználót az infrastruktúra módosítására. Most is jött egy ilyen, október elején: a Microsoft arra figyelmeztet, hogy az Azure Tárfiókoknál 2026. február 3. után már csak a TLS 1.2 vagy újabb verzió lesz támogatott.
Ez az értesítés elsősorban azokat érinti, akiknek a Tárfiókjai még TLS 1.0 vagy 1.1 protokollt is elfogadnak. Ezek a régebbi titkosítási eljárások ma már elavultnak számítanak, és nem támogatják a modern kriptográfiai algoritmusokat, ezért a Microsoft fokozatosan megszünteti a használatukat.
Mi az a TLS és miért fontos?
A TLS (Transport Layer Security) egy biztonsági protokoll, amely az internetes adatátvitel védelmét szolgálja. A korábbi verziók (1.0 és 1.1) több mint 20 évesek, és ma már nem felelnek meg a biztonsági követelményeknek. A TLS 1.2 gyorsabb és biztonságosabb kommunikációt biztosít, amely jobban védi az adatokat a lehallgatás és a manipuláció ellen.
Mi a teendő?
Ha az Azure Tárfiókod TLS 1.0 vagy 1.1 protokollt is enged, akkor 2026. február 3-ig frissítened kell a beállításokat, különben az alkalmazásaid nem fognak tudni biztonságosan csatlakozni a szolgáltatáshoz.
A Microsoft ajánlása egyértelmű:
Állítsd be a Minimális TLS-verziót 1.2-re (vagy újabbra).
Ellenőrizd, hogy az alkalmazásaid és SDK-jaid is támogatják a TLS 1.2-t.
Hogyan lehet beállítani a TLS 1.2-t az Azure portálon?
A beállítás módosítása néhány kattintás az Azure portálon:
Lépj be az Azure Portalba.
Keresd meg a módosítani kívánt Tárfiókot.
A bal oldali menüben válaszd a Beállítások > Konfiguráció (Settings > Configuration) menüpontot.
A Minimális TLS-verzió (Minimum TLS version) beállításnál válaszd ki a TLS 1.2 opciót.
Mentsd el a módosítást (Mentés / Save).
Ha több Tárfiókod van, érdemes Azure Policy-t is használni, hogy központilag kikényszerítsd a TLS 1.2 beállítást minden fiókra.
Meddig van időm ezt elvégezni?
A határidő 2026. február 3., eddig kell minden Tárfiókon elvégezni a frissítést. Ezt követően a TLS 1.0 és 1.1 kapcsolatokat az Azure Tárfiók már nem fogadja el.
Aki addig nem módosítja a beállításokat, annak az alkalmazásai hibát fognak adni, amikor megpróbálnak kapcsolódni a Tárfiókhoz.
Összefoglalás
A változás célja, hogy az Azure-felhasználók biztonságosabb és korszerűbb titkosítási eljárásokat használjanak. A frissítés mindössze néhány percet vesz igénybe, de elengedhetetlen a jövőbeni hibamentes működéshez.
A felhőben a rendelkezésre állás és a hibatűrés kulcsfontosságú, hiszen a legtöbb vállalat napi működése az ilyen szolgáltatásokra épül. Az Amazon Web Services (AWS) például 99,99%-os SLA-t (Service Level Agreement) vállal a legtöbb szolgáltatására, ami éves szinten mindössze egy órányi megengedett leállást jelent. Ennek ellenére időnként előfordulhatnak átmeneti fennakadások – ilyen volt a 2025. október 20-i esemény is, amely jól demonstrálta, mennyire gyorsan képes reagálni az AWS egy globális szintű problémára.
A hiba gyökere az US-East-1 (Észak-Virginia) régióban jelentkezett, és több mint 140 AWS-szolgáltatás működésére is kihatott – különösen azokra, amelyek DNS-feloldásra vagy központi vezérlősíkra (control plane) támaszkodnak.
Bár az európai (Frankfurt, EU-Central-1) régió nem volt közvetlenül az esemény központja, számos szolgáltatás itt is tapasztalt átmeneti hibákat. Ennek oka, hogy több globális AWS-komponens – például az IAM/SAML bejelentkezés, az ECR image-tárolás vagy a globális API-végpontok – részben az US-East-1-hez kapcsolódik.
Hivatalos idővonal (CEST)
09:11 – AWS vizsgálja a megnövekedett hibaarányokat és késéseket több szolgáltatásban (US-EAST-1).
09:51 – A hibák megerősítést nyernek, az AWS Support API és konzol is érintett.
10:26 – A DynamoDB végpontoknál jelentős hibák lépnek fel, további szolgáltatások is érintettek.
11:01 – Az AWS azonosítja a probléma lehetséges okát: DNS-feloldási hiba a DynamoDB végpontnál.
11:22 – Kezdeti helyreállítási jelek tapasztalhatók néhány szolgáltatásnál.
11:27 – Jelentős javulás, a legtöbb kérés már sikeresen teljesül.
12:03 – A globális szolgáltatások (IAM, DynamoDB Global Tables) is helyreállnak.
12:35 – A DNS-hiba teljesen elhárítva, a legtöbb művelet ismét normálisan működik.
13:08 – 14:10 – Az EC2 indítási hibák és a Lambda polling-késések fokozatosan javulnak.
14:48 – 15:48 – Az EC2 indítási korlátozások enyhülnek, a legtöbb Availability Zone újra működik.
16:42 – 18:43 – A hálózati terheléselosztó (Network Load Balancer) egészség-ellenőrző alrendszer hibát okoz több szolgáltatásban (Lambda, CloudWatch, DynamoDB).
18:43 – 20:13 – További mitigációk, a hálózati problémák fokozatosan megszűnnek.
20:22 – 21:15 – Szinte minden AWS szolgáltatás helyreállt, csak néhány EC2-indítás és Lambda maradt részben érintett.
22:03 – 23:52 – Teljes szolgáltatás-visszaállás az US-EAST-1 régióban.
00:01 (október 21.) – Az AWS hivatalosan is normál működést jelent.
Hatások és tapasztalatok
A kiesés során világszerte számos ismert platform – többek között a Snapchat, a Fortnite, a Reddit és a Venmo – részleges vagy teljes leállást tapasztalt. A felhőszolgáltatások közötti erős függőségek miatt a hiba nem csupán az AWS-t érintette, hanem több külső rendszer és alkalmazás működésében is zavart okozott.
A vizsgálat szerint a probléma nem biztonsági incidens vagy kibertámadás következménye volt, hanem egy belső DNS-feloldási hiba, amely a DynamoDB szolgáltatás elérhetetlenségéhez vezetett, majd tovagyűrűzött az azt használó szolgáltatásokon keresztül.
Tanulságok
Az AWS kiesése emlékeztetett arra, hogy még a legnagyobb globális felhőszolgáltatók esetében is előfordulhatnak ritka, rövid ideig tartó fennakadások. Fontos azonban kiemelni, hogy az ilyen események rendkívül ritkák, és az AWS gyors helyreállítási folyamatai miatt a szolgáltatások általában néhány órán belül normalizálódnak.
Ez az eset is jól mutatta az AWS infrastruktúra érettségét és reakcióképességét – a hibát hamar azonosították, a helyreállítás fokozatosan zajlott, és az ügyfelek többsége számára a szolgáltatások néhány órán belül elérhetővé vált. Az esemény így inkább megerősítette, mintsem gyengítette a felhőszolgáltatásokba vetett bizalmat: az AWS ökoszisztéma bizonyította, hogy képes gyorsan és hatékonyan kezelni váratlan globális problémákat.
Az elmúlt időszak eseményei olyanok, mint egy mese, ami váratlanul rémálommá vált. Képzeld el, hogy van egy kis kikötő, ahol a hajók évek óta ugyanazt a megbízható szállítótól kapják az alkatrészeket, ráadásul ingyen. A kapitányok megszokták, hogy mindig időben érkezik az utánpótlás, és minden zökkenőmentesen működik. Egy nap azonban a kikötőt átveszi egy új tulajdonos, aki közli: a régi, készleten lévő alkatrészek ugyan még elérhetők, de újak már nem lesznek, legalábbis nem ingyen.
A kapitányok előtt három út marad: átállnak az új, drágább rendszerre, saját megoldást keresnek, vagy alternatív kikötőt választanak.
Technológiailag ez a helyzet tükrözi, amit néhány napja a Bitnami Docker image-k kapcsán bejelentettek. Sok fejlesztői közösség számára hirtelen egy új realitással kell szembenézni – és most megnézzük együtt, mit is jelent ez a változás, és milyen lehetőségeink vannak.
Mi az a Bitnami?
A Bitnami egy régóta ismert projekt, amely célul tűzte ki, hogy nyílt forrású szoftvereket (pl. adatbázisokat, webkiszolgálókat, cache-rendszereket) „do‐it‐yourself” egyszerűségű csomagként kínáljon: konténerképek, Helm chartok, könnyű telepíthetőség. Évtizedeken át sok Kubernetes-projekt, fejlesztő és üzemeltető használta ki előre konfigurált Bitnami image-eket és chartokat, mivel ezek stabilan, dokumentáltan és viszonylag kevés törés mellett működtek.
A Bitnami projekt most a Broadcom portfóliójába tartozik (Broadcom a VMware-t vásárolta fel), és ennek kapcsán stratégiai átalakítást hajt végre a konténerkép-disztribúciójában.
Miért fontos ez a változás?
A Bitnami eddig szerepelt sok Kubernetes infrastruktúra alapvető építőköveként: telepíthető komponensek, megbízható konténerképek, és helm chartok, amelyek akadálymentesítették az alkalmazások bevezetését. Amikor ez a támogatás visszavonul, többféle technikai és gyakorlati kockázat jelenik meg:
A docker.io/bitnami publikus regisztrációs hely (ahonnan sok image eddig szabadon letölthető volt) a változások hatására mérséklődik, és sok verziós címke eltűnik.
Az eddigi képek átkerültek egy Bitnami Legacy (bitnamilegacy) regiszterbe, ahol nem kapnak több kiadást, frissítést, biztonsági javítást.
Egy új, Bitnami Secure Images (bitnamisecure) hivatalosan nem „közösségi” szolgáltatás, hanem vállalati előfizetéshez kötött, fizetős kínálat.
A publikus Helm chartok (az OCI manifestjeik) frissítése is szünetel: a forráskód továbbra is elérhető marad GitHub-on, de az automatikus képek, verziófrissítések nem mindig jönnek majd.
A végleges “központi” publikus Bitnami regiszter törlése 2025. szeptember 29-én volt.
A Bitnami Secure Images vállalati előfizetésként érhető el, ára a források szerint több ezer dollár havonta, jellemzően 6 000 USD/hó körüli szinten indul.
Mindez azt jelenti, hogy ha nem léptünk időben, a Kubernetes klaszterekben, CI/CD folyamatokban, frissítési és automatikus skálázási műveletek során hirtelen hibaüzenetekkel (például ImagePullBackOff, ErrImagePull) találkozhatunk, amikor a rendszer nem tudja letölteni a szükséges képeket.
Mit okozhat a Kubernetes alapú rendszerekben?
Ha nem készültünk fel:
Új podok nem indulnak el – amikor a fürt új csomópontot indít vagy új replika szükséges, a rendszer letöltené a Bitnami image-t, de ha az már nem elérhető, hibát kapunk: ErrImagePull vagy ImagePullBackOff.
Frissítés vagy skálázás meghiúsul – ha egy alkalmazást új verzióra frissítenénk, de a chartban vagy a konfigurációban Bitnami image hivatkozás van, akkor az update művelet elbukhat.
Biztonsági elmaradások halmozódnak – a bitnamilegacy képek fagyottak: nem kapnak további biztonsági frissítést, így elavult, sérülékeny komponensek maradhatnak használatban.
Rejtett függőségek okozta meglepetések – nemcsak közvetlen alkalmazásaink használhatják Bitnami képeket, hanem alcsomagok, segédkonténerek, init container-ek is, amelyek rejtetten hivatkozhatnak a bitnami regiszterre.
CI/CD pipeline-ok hibái – ha build vagy teszt folyamat során Bitnami képet húzunk be (pl. adatbázis konténer, migrációs konténer), akkor az egész pipeline leállhat.
Összességében tehát egy jól működő rendszerben sok esetben „hallgatólagos” függőségek fognak megbukni, és váratlan leállások vagy hibák léphetnek fel.
Milyen lehetőségeink vannak a problémák megoldására?
Ahogy a halász a történetben új kikötőt vagy hajót választhat, nekünk is több stratégiánk van:
1. Átirányítás a Bitnami Legacy Registry (bitnamilegacy)
Ez a legegyszerűbb ideiglenes megoldás: módosítjuk a konfigurációkat (helm values, deployment spec) úgy, hogy a repository: bitnamilegacy/… formát használjuk, és tartsuk meg a jelenlegi címkéket, amíg át tudunk térni.
Előny: viszonylag kevés munkával elérhető átmeneti működés. Hátrány: ezek az image-ek nem kapnak új frissítéseket vagy biztonsági javításokat — idővel elavultak lesznek.
Ha ezt választjuk, erősen ajánlott saját privát regiszterbe tükrözni (mirror), hogy legalább ne függjünk harmadik féltől.
2. Használjuk a Bitnami Secure Images (BSI) szolgáltatást
A Bitnami bejelentette, hogy új, „secure”, hardened képek és Helm chartok szolgáltatása indul, amely verziókezelést, SBOM-ot, CVE-transzparenciát, és egyéb vállalati tulajdonságokat ad. Ez a megoldás azonban jellemzően fizetős, és inkább vállalati környezetekben lesz értelmes választás. Ha előfizetünk, akkor a képek és chartok publikusan már nem a bitnami regiszteren lesznek, hanem automatikus privát vagy dedikált OCI regisztereken. A Bitnami beígérte, hogy a Secure Images kínálat kisebb, de biztonságosabb verziókat fog tartalmazni (distroless képek, kisebb támadási felület).
3. Teljes elszakadás a Bitnami képektől – alternatívák és saját build
Ez a leginkább javasolt hosszú távon: magunknak választunk más képeket (például hivatalos Docker képeket, más közösségi projektek képeit), vagy akár a Bitnami számára elérhető open source konténerforrásokból saját képeket építünk és menedzselünk.
A Bitnami-forráskódok (Dockerfile-ok, Helm chartok) továbbra is elérhetők GitHubon Apache 2 licenccel — tehát jogilag megengedett saját építésre.
Kiválaszthatunk megbízható, aktív közösségű alternatívákat (pl. hivatalos image-ek, distro-specifikus build-ek).
Szükség lehet az értékek és beállítások átalakítására, mert nem minden image viselkedik ugyanúgy, mint a korábbi Bitnami verziók.
Célszerű bevezetni folyamatos integrációs (CI) pipeline-ban a képek tesztelését, vulnerability scan-t, hogy újabb függőségi hibák ne csússzanak be.
Lépésként részleges migráció is szóba jöhet: először a kritikus komponenseket „lecsupaszított”, alternatív képekkel cserélni, majd haladni tovább.
4. Audit és függőségek feltérképezése
Mielőtt döntenénk, célszerű átfogó auditot végezni:
Kikeresni az összes konténerkép-hivatkozást (pl. grep bitnami a manifestekben).
Megszámolni azokat a fürtön belüli podokat, amelyek Bitnami képet használnak (pl. kubectl get pods -A -o json | jq … | grep bitnami)
Felmérni, mely komponensek kritikusak, melyek kevésbé veszélyeztetettek, hogy prioritásokat állíthassunk.
Tesztelni a migrált konfigurációkat staging környezetben, hogy ne érjen minket meglepetés élesben.
5. Fokozatos átállás, párhuzamos környezetek
Nem feltétlenül kell mindent egyszerre lecserélni. Lehet fokozatosan:
Kritikus komponensek migrálása
Tesztkörnyezetek kipróbálása
Monitorozás, visszajelzések gyűjtése
Végleges átállás
Ez csökkentheti a kockázatot, és lehetőséget ad arra, hogy közbe avatkozzunk, ha valami nem működik.
Összegzés
Ez jelentős változás a konténeres és Kubernetes-alapú rendszerek világában. Ha nem készültünk fel, akkor ImagePull hibák, skálázási problémák és biztonsági elmaradások várnak ránk.
A legbiztosabb megoldás hosszú távon az, ha függetlenedünk a Bitnami-tól: alternatív képeket használunk, saját építésű konténereket alkalmazunk, és megfelelő folyamatokat építünk be (audit, tesztelés, scanning). Addig is átmeneti megoldásként a Bitnami Legacy regiszter használata segíthet.
A digitális szuverenitás fogalma az utóbbi években egyre hangsúlyosabban van jelen az európai technológiai diskurzusban. A Microsoft új bejelentése, a Sovereign Cloud kezdeményezés kibővítése, pontosan erre a növekvő igényre reagál: olyan felhőmegoldást kínál európai kormányzati és szabályozott iparági szereplők számára, amely nem csupán technológiai, hanem működési és jogi szinten is garantálja az adatok feletti kontrollt.
A digitális szuverenitás azt jelenti, hogy egy ország, intézmény vagy szervezet maga dönthet arról, hol és hogyan tárolja, dolgozza fel és védi meg a digitális adatait – anélkül, hogy külső szolgáltatók vagy más országok beleszólnának ebbe. Ez különösen fontossá vált az Európai Unióban, ahol a szabályozások egyre inkább előírják, hogy az adatkezelés az EU határain belül, helyi ellenőrzés alatt történjen.
Ez a megközelítés új mércét állíthat az adatbiztonság, a megfelelőség és a digitális függetlenség terén, különösen az Európai Unión belül. De mit is jelent ez a gyakorlatban? Miben más, mint az eddigi Azure-szolgáltatások? És miért éri meg ezzel foglalkozni cégeknek vagy állami intézményeknek?
Mi az a Microsoft Sovereign Cloud?
A Microsoft Sovereign Cloud olyan felhőszolgáltatások összessége, amelyeket kifejezetten a digitális szuverenitást komolyan vevő országok és szervezetek igényeire szabtak. Ezek a szolgáltatások lehetővé teszik, hogy az ügyfelek – jellemzően állami szervek, egészségügyi szolgáltatók, pénzintézetek és kritikus infrastruktúra üzemeltetők – teljes kontrollt gyakoroljanak adataik felett.
Ez nem csupán földrajzi lokalizációt jelent, hanem három fontos területre terjed ki:
Technológiai szuverenitás – Az adatok fizikailag az adott országban vagy régióban maradnak, és a feldolgozásuk is ott történik.
Operatív szuverenitás – Az ügyfelek, vagy azok helyi partnerei döntenek arról, ki férhet hozzá a rendszerekhez, akár a Microsoft hozzáférését is korlátozva.
Jogszabályi szuverenitás – A felhőszolgáltatások teljes mértékben megfelelnek az adott ország vagy régió adatvédelmi és iparági szabályozásainak.
A Microsoft az Európai Unióra különösen nagy hangsúlyt fektet: az új kezdeményezés célja, hogy segítsék az európai szervezeteket megfelelni az olyan komplex szabályozásoknak, mint a GDPR, a DORA (Digitális Reziliencia Szabályozás), a NIS2 (hálózatbiztonsági irányelv) és az EU Cloud Code of Conduct.
Alapelvek és működés
A Microsoft Sovereign Cloud nem önálló termék, hanem egy architektúra és szolgáltatási keretrendszer, amely a meglévő Microsoft Azure, Microsoft 365 és Dynamics 365 szolgáltatásokra épül, de kibővített kontroll- és biztonsági képességekkel.
Fő pillérei:
Adatszuverenitás és lokalizáció: Az adatok tárolása és feldolgozása kizárólag adott országban vagy régióban történik.
Hozzáférés-felügyelet: Az ügyfelek szabályozhatják, hogy a Microsoft rendszergazdái hozzáférhetnek-e az adatokhoz vagy sem.
Teljeskörű auditálhatóság: A felhasználók részletes naplózási és ellenőrzési eszközöket kapnak.
Szabályozási megfelelés támogatása: Az architektúra előre validált sablonokat és beállításokat tartalmaz az adott iparági előírásokhoz.
A Microsoft kiemeli, hogy nem egyedül nyújtja ezeket a megoldásokat: helyi partnerekkel – például kormányzati szervekkel, informatikai szolgáltatókkal – együttműködve hozza létre és működteti ezeket a rendszereket.
Miben különbözik az Azure-tól vagy más hagyományos felhőktől?
A Microsoft Azure alapvetően egy globális nyilvános felhő, amely regionálisan elérhető adatközpontokkal működik. Bár kínál lehetőséget az adatok lokalizációjára (pl. európai régió választása), a szolgáltatás alaplogikája szerint a Microsoft infrastruktúráján, az ő irányítása alatt történik minden.
A Sovereign Cloud ezzel szemben:
Szigorúan korlátozza az adatáramlást a megadott földrajzi határokon belül
Teljes ügyfélkontrollt biztosít a hozzáférések felett (még a Microsoft saját adminjai felett is)
Lokális partneri működtetést tesz lehetővé, például állami informatikai ügynökséggel együtt
Dedikált megfelelőségi sablonokat és auditálási lehetőségeket kínál, különösen az állami, egészségügyi vagy pénzügyi szektor számára
Egy másik fontos különbség, hogy az Azure hagyományosan a skálázhatóságot és globális elérhetőséget helyezi előtérbe, míg a Sovereign Cloud a szabályozási és működési megfelelést maximalizálja – még akkor is, ha ez a globális rugalmasság csökkenésével jár.
Erősségek: miért előnyös ez a megoldás?
Teljes kontroll az adatok felett: a felhasználó dönt, hogy ki, mikor, hogyan férhet hozzá
Szabályozásnak való megfelelés egyszerűbbé válik, akár komplex ágazati előírások esetén is
Transzparencia és auditálhatóság: világosan nyomon követhető minden tevékenység
Helyi partnerekkel működik együtt, ami növeli az elfogadottságot és a nemzeti kontrollt
Rugalmas modell: lehetőség van önálló vagy együttműködésen alapuló működésre is
Lehetőségek: kinek ajánlott?
A Microsoft Sovereign Cloud elsősorban azoknak a szervezeteknek készült, amelyek érzékeny adatokkal dolgoznak, és:
Jogszabály kötelezi őket a szuverén működésre (pl. kormányzati intézmények)
Kritikus infrastruktúrát kezelnek (pl. közművek, közlekedés)
Pénzügyi, egészségügyi vagy védelmi ágazatban működnek, ahol a digitális függetlenség elsődleges fontosságú
A magánszektorban is egyre több szervezet vizsgálja ennek lehetőségét, főleg ha nemzetbiztonsági vagy reputációs kockázatot jelenthet az adatkezelés kiszervezése.
Korlátok és kihívások
Magasabb üzemeltetési költség: a lokalizált működés és a megnövekedett kontroll többletkiadással járhat
Kisebb rugalmasság és globális elérhetőség, mivel az adatok szigorúan izolált környezetben maradnak
Technikai összetettség: nem minden szervezet rendelkezik az ehhez szükséges tudással és kapacitással
A megosztott felelősség modell továbbra is érvényes: a Microsoft csak a szolgáltatást biztosítja, az adatbiztonság egy része a felhasználó felelőssége marad
Mit jelent ez nekünk, felhasználóknak és cégeknek?
Felhasználóként egyre több olyan digitális szolgáltatást használunk, ahol személyes vagy érzékeny adatokat adunk meg – legyen szó állami ügyintézésről, egészségügyi nyilvántartásról vagy pénzügyi tranzakciókról. A Sovereign Cloud modell garantálja, hogy ezek az adatok nem kerülnek ki az ország vagy az EU határain kívülre, és azok felett kizárólag az általunk felhatalmazott szervezetek gyakorolhatnak kontrollt.
Céges oldalon ez versenyelőnyt is jelenthet: egy olyan szolgáltatóval dolgozni, amely képes a legszigorúbb adatvédelmi előírásoknak is megfelelni, bizalmat épít az ügyfelekben, partnerekben, hatóságokban.
És mi a helyzet az AWS-el?
Nem csak a Microsoft ismerte fel a digitális szuverenitás növekvő jelentőségét. Az Amazon Web Services is dolgozik saját szuverén felhőmegoldásán, különösen Sovereign-by-Design szemlélettel. Az AWS célja hasonló: lehetőséget biztosítani a kormányzati és szabályozott szektor szereplőinek arra, hogy adataikat teljes mértékben földrajzilag és működésileg is kontroll alatt tarthassák, akár a szolgáltató beavatkozása nélkül is.
A tervek szerint az AWS Európában is olyan felhőkörnyezeteket épít, amelyekben:
Az adatok tárolása és feldolgozása kizárólag uniós területen történik
A hozzáférési jogokat kizárólag az ügyfelek (vagy az általuk kijelölt partnerek) szabályozzák
A szolgáltatások megfelelnek az olyan szabályozásoknak, mint a GDPR, NIS2, DORA
Bár az AWS még nem indította el széles körben a szuverén felhőszolgáltatását, a bejelentett tervek jól mutatják, hogy a „szuverén felhő” nem egy gyártói hóbort, hanem az egész iparág új irányvonala. Ez hosszú távon a felhasználóknak kedvez: versenyhelyzetet teremt, ahol a nagy szolgáltatók egyre biztonságosabb, átláthatóbb és szabályozásbarátabb megoldásokat kínálnak.
Összegzés
A Microsoft Sovereign Cloud nem csupán technológiai újítás, hanem stratégiai válasz Európa digitális szuverenitási törekvéseire. A felhőszolgáltatások következő generációját képviseli, ahol nem csupán a skálázhatóság és rugalmasság számít, hanem a kontroll, a megfelelőség és a biztonság is.
Azoknak a szervezeteknek, akik nem engedhetnek meg maguknak kompromisszumot az adatok feletti uralom terén, ez a megközelítés nem lehetőség, hanem szükségszerűség.
Habár csak néhány napja jelentették be, nekem már volt alkalmam kipróbálni a GitHub CoPilot új Agent funkcióját a Visual Studio Code-ban, és őszintén szólva lenyűgözött, amit tapasztaltam. Korábban is használtam a CoPilotot, de az Agent mód teljesen új szintre emelte az eddig is igen jó fejlesztői élményt.
Bizonyára eddig is sokan kipróbáltátok már a CoPilot-ot, hiszen van belőle ingyenes változat is, így felelőtlenség lenne kihagyni ezt a lehetőséget. Az ingyenes változat kiváló választás azoknak, akik nem folyamatosan használják ezt az eszközt.
Az új funkció lényege, hogy már nem csak sorokat egészít ki, hanem képes folyamatos párbeszédben segíteni a munkámat. Olyan, mintha egy valódi technikai asszisztens ülne mellettem, akivel beszélgetve együtt haladunk előre. Megkérhetem például, hogy magyarázza el egy kódrészlet működését, javítson ki hibákat, vagy írjon nekem egy új funkciót egy meglévő projektbe.
A CoPilot Agent mostantól minden Visual Studio Code felhasználó számára elérhető, külön beállítás nélkül, tehát az ingyenes változatot alapból megkapjuk. A bal oldali menüből egyszerűen elindítható a CoPilot Agent felület, ahol természetes nyelven – akár magyarul is – megfogalmazhatom a kérdéseimet vagy feladataimat. Az élmény sokkal személyesebb, mint a hagyományos kódkiegészítés, mert tényleg beszélgetni tudok a rendszerrel.
Ami különösen izgalmas, hogy megjelent a multi-command plan (MCP) támogatás is, amely lehetővé teszi, hogy a CoPilot több lépéses, komplexebb feladatokat is átlásson és megoldjon. Például ha szeretnék létrehozni egy új REST API-t, akkor először kérdéseket tesz fel az igényeimről, majd ezek alapján generálja a megfelelő fájlokat, „endpoint”-okat és struktúrákat.
Kezdőként ez hatalmas segítséget jelenthet. Emlékszem, korábban én is mennyi időt töltöttem azzal a tanulás elején, hogy rájöjjek, hogyan kezdjek bele egy-egy új projektbe, hogyan építsem fel a fájlstruktúrát vagy írjak teszteket. A CoPilot Agent képes konkrét példákon keresztül megmutatni ezeket, ráadásul valós idejű visszajelzést is ad. Olyan, mintha egy türelmes mentor állna mellettem, akit bármikor kérdezhetek.
Fontos azonban megemlíteni, hogy a CoPilot – még az Agent módban is – nem tévedhetetlen. Az általa generált kódokat minden esetben felelősséggel kell kezelni. Én mindig átnézem, tesztelem, és ahol kell, javítom a javaslatait. Különösen biztonsági, adatkezelési vagy éles környezetbe szánt kódok esetén nem szabad vakon megbízni benne.
Összességében úgy érzem, a GitHub CoPilot Agent módja egy új korszak kezdete lehet a fejlesztésben és a tanulásban. Nemcsak a hatékonyságot növeli, hanem valódi tanulási lehetőséget is kínál – főleg azoknak, akik most vágnának bele a programozás világába. Ha eddig csak próbálgattad a CoPilotot, most érdemes visszatérni hozzá: az Agent mód valóban megváltoztatja, hogyan gondolkodunk a kódolásról.
Van olyan ötlet, aminek a megvalósítását eddig elnapoltad, mert nem volt aki segített volna? Ugye? Most már nincs több kifogás. 🙂
Elérkeztünk 2024 végéhez, ami számomra különösen emlékezetes év volt, hiszen augusztusban elindítottam új, magyar nyelvű technológiai blogomat. Ezt azzal céllal tettem, hogy egy közösséget építsek, ahol mindenki talál érdekes és hasznos témákat a felhő és AI modern világából. Hogy aki szeretne fejlődni és tanulni, az megtalálja a helyét. Bárki kérdezhessen nyitottan, és hogy sikereket érjen el ezen témák megismerésével.
Köszönet
Hatalmas köszönet mindenkinek, aki követi, olvassa, vagy bármilyen módon támogatja a munkámat. Külön szeretném megköszönni Feleségemnek a sok bíztatást, szeretetet és kitartást, hogy támogatja minden erőfeszítésemet és segít megvalósítani az álmaimat. ❤️
Blog
A blog indítása nemcsak egy szakmai vállalkozás volt, hanem egy személyes kihívás is. A technológia világa rendkívül gyorsan változik, és az információ megosztása által igyekeztem hozzájárulni ahhoz, hogy ti is részesei lehessetek ezeknek az új lehetőségeknek. Legyen szó Azure megoldásokról, AWS technológiákról vagy a mesterséges intelligencia legfrissebb fejlesztéseiről, a cikkek célja mindig az volt, hogy kézzel fogható, gyakorlatias információkat nyújtsanak.
Mentor világ
Mentor Klub trénereként szeretnék köszönetet mondani minden tanítványomnak és a Mentor Klub dolgozóinak is az idei évért. A közös munka, a képzések és a tanulás élménye mindannyiunkat előreléptetett. Sok energiát kapok és kaptam minden képzés alkalmával, ami mindig feltöltött, akkor is ha előtte egy nehéz munkanapon voltam túl. Az együtt töltött idő alatt nemcsak szakmai, hanem személyes fejlődésen is keresztülmentem, amit a veletek való együttműködésnek köszönhetek. ✨
Fejlődés és tanulás
Az idén több képzést és tanúsítványt is sikeresen teljesítettem, amelyek lehetővé tették, hogy tovább fejlesszem tudásomat, és ezek közvetve a blog tartalmaiban is visszaköszönhettek:
Microsoft Certified: Azure Solutions Architect Expert (megújítás)
DevOps Deployment Automation with Terraform, AWS and Docker képzés
Vector Databases in Practice: Deep Dive képzés
Hands-On Generative AI: Getting Started with Vector Search képzés
Software Architecture: From Developer to Architect képzés
Ezek a képzések nemcsak technikai ismeretekkel gazdagítottak, hanem segítettek abban is, hogy még jobban megértsem a technológia és az emberek kapcsolatát. Az újonnan szerzett tudásomat igyekszem megosztani veletek a blogon és a képzéseken keresztül, hogy ti is profitálhassatok ezekből az ismeretekből.
Sikeres év
Az év mérlege – ha fogalmazhatok így – rendkívül pozitív számomra. A blog indítása után örömmel láttam, hogy egyre több ember találja hasznosnak a tartalmakat, és hogy kialakult egy olyan közösség, amelyben megoszthatjuk tapasztalatainkat és ötleteinket. Ez a közösség inspirált arra is, hogy még több energiát fektessek a tartalomkészítésbe, és hogy a jövőben is készítsek ilyen és ehhez hasonló tartalmakat.
Jövőre…
2025-ben is folytatom az utamat a technológia és a tanulás világában, és bízom benne, hogy velem tartotok ezen az izgalmas utazáson. Terveim szerint rengeteg új témával, praktikus példákkal és inspiráló tartalmakkal készülök nektek.
Békés, boldog, sikeres új évet kívánok mindenkinek, és köszönöm, hogy részesei vagytok ennek az utazásnak! 🍾 🎊
