Bitnami változások

Linux-haladó

Nem tudom, kinek ujdonsag, elv augusztusi tema, de nekem ma altak meg helm chartok ez miatt... (sajnos olyan image eket erint, amik hard codolva vannak , ezert max hotfixelni lehet a dolgot, de a chart bol nem modosithatok. pl a nalam a Semaphore mariadb image-e)

 

 

 

 

⚠️ Important Notice: Upcoming changes to the Bitnami Catalog

Beginning August 28th, 2025, Bitnami will evolve its public catalog to offer a curated set of hardened, security-focused images under the new Bitnami Secure Images initiative⁠. As part of this transition:

  • Granting community users access for the first time to security-optimized versions of popular container images.
  • Bitnami will begin deprecating support for non-hardened, Debian-based software images in its free tier and will gradually remove non-latest tags from the public catalog. As a result, community users will have access to a reduced number of hardened images. These images are published only under the “latest” tag and are intended for development purposes
  • Starting August 28th, over two weeks, all existing container images, including older or versioned tags (e.g., 2.50.0, 10.6), will be migrated from the public catalog (docker.io/bitnami) to the “Bitnami Legacy” repository (docker.io/bitnamilegacy), where they will no longer receive updates.
  • For production workloads and long-term support, users are encouraged to adopt Bitnami Secure Images, which include hardened containers, smaller attack surfaces, CVE transparency (via VEX/KEV), SBOMs, and enterprise support.

These changes aim to improve the security posture of all Bitnami users by promoting best practices for software supply chain integrity and up-to-date deployments. For more details, visit the Bitnami Secure Images announcement⁠.

  • 1131 megtekintés

ez csak felmegoldas hogy atirod a bitnami/foo -rol bitnamilegacy/foo-ra az image nevet. de ha a chart ugy van felepitve hogy az a bitnami imagehez passzolt, akkor nem tudod csak ugy kicserelni egy masik felepitesu imagehez. (pl mas volumeket kell, mashova mountolni, vagy a parameterek mas env neven futnak, stb)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ez oké, de a poszt abból indult, hogy valami megállt, és meg kell javítani. Ehhez elég gyorsan a bitnamilegacy-ra cserélni az image-et. És ahhoz van normálisan, helm value-n keresztül támogatott módszer. Nem kell belemászni az implementációba és hardcode-olt image neveket belül átírogatni.

Hosszabb távon amúgy véleményem szerint a bitnami-t el kell engedni helm chart + docker image szempontból. Vannak, akik már megtették, pl.: https://github.com/oauth2-proxy/manifests/commit/9b08b04a66b5c5dd98c121…

Hosszabb távon amúgy véleményem szerint a bitnami-t el kell engedni helm chart + docker image szempontból.

Igen, pontosan ezt a kommentet akarta a kolléga megelőzni azzal, hogy nem módosítható a helm chart a részéről, mert mindenki tisztában van ezzel - csak ez nem mindig lehetőség.

Azért a Bitnami is tehet egyből két szívességet is.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

igen, pont ezt csinaltam en is. "telepites"  utan modositottam a generalt yaml-t. Amire en gondolok, hogy nem lehet magaban a default value-ban modositani a mariadb image-t.

 

https://artifacthub.io/packages/helm/semaphoreui/semaphore?modal=values

 

tehat ha ranyomok egy frissitest, ugrik a valtozas. (nyilvan lehet trukkozni override al, de attol meg ez mokolas)

De pont azt írom, hogy ez módosítható helm value-ból, nem a már kideployolt yaml-t kell abuzálni. Főleg, mert ahogy írtad, frissítés után elveszik a módosításod.

Az általad linkelt oldalon csak direktben a semaphore chart lehetőségeit látod. A subchart MariaDB value listája az nem itt lesz, de attól még használható, annyi, hogy amilyen néven a subchart be van hivatkozva ("mariadb"), azzal prefixelni kell.

Tehát ha itt https://artifacthub.io/packages/helm/bitnami/mariadb/20.4.2?modal=values valami olyan néven van, hogy image.registry, akkor te a semaphore helm chart-ját deployolva olyan helm value-val állíthatod, hogy mariadb.image.registry

ööö nem pont ezt irtam en is? :)

(nyilvan lehet trukkozni override al, de attol meg ez mokolas)

jelenleg azert a kesz cuccot irtam at, mert 1. gyorsabb volt, 2 bizom benne, hogy a kovetkezo verzioban javitjak ezt (mar nyitottam neki issue-t)

Nyilvan ha addig nem kerul javitasra, marad az override.yaml, mint megoldas.

Nem, pont, hogy nem ezt írtad.

Ezt írtad:

ezert max hotfixelni lehet a dolgot

de a chart bol nem modosithatok. pl a nalam a Semaphore mariadb image-e

Amire en gondolok, hogy nem lehet magaban a default value-ban modositani a mariadb image-t.

tehat ha ranyomok egy frissitest, ugrik a valtozas.

Amit én írtam, az összes itt idézett problémádra megoldás.

Vagy te úgy szoktál helm chart-ot telepíteni, hogy sosem adsz meg az adott környezetre jellemző value-kat, mindig csak a chart-tal érkező default értékeket használod? Pont ez a value-k lényege, hogy megadható az értékük.

Szerintem félreérted, hogyan működik a helm subchart-ban lévő value-k kezelése. A subchart (mariadb) value-kra példa az nem lesz benne a semaphore values sample-nél. De attól, hogy ott nincs benne, attól még a mariadb subchart-ot egy konkrét verzióval hivatkozza be, ezért ez egy teljesen jól definiált és supportált dolog, hogy milyen value-val tudod megmondani, hogy mondjuk mi legyen a mariadb docker image. Ez nem számít "eltérésnek" a sample chart-tól. Az erre vonatkozó sample a mariadb chart adott verziójánál lesz.

Lásd https://helm.sh/docs/chart_template_guide/subcharts_and_globals

És ez nem okoz semmilyen gondot a későbbiekben (kivéve esetleges főverzió ugráskor, de olyankor normális, hogy akár a főchart-ban, akár a subchart-ban máshogy vannak a value-k).

Ertem amit irsz, de sztm neked nem vilagos, mi nekem ezzel a gondom.

Ha felulirok egy erteket, az ugy marad, amig kezzel ki nem veszem. Ha a fochart kesobb javitja a hibat (pl. mas repot hasznal), az en felulirasom akkor is ervenyes marad, tehat figyelnem kell, mikor toroljem.
Ez kb. olyan, mintha kezzel modositanam a "forraskodot".
Radasul ha a subchart kesobb megvaltozik (pl. mas key-neven varja az image beallitasokat), az override ervenytelenne is valhat.

Nem ugy mukodik. Egy helm override (--set key=value) csak az adott "helm install/upgrade"-re vonatkozik. Ha kesobb upgradelsz egy ujabb helm chart verziora es elhagyod az override-ot, akkor visszavalt a default (values.yaml-ben definialt) ertekre. Tehat a helm nem "cipeli" az override-okat vegtelensegig.

Akkor viszont hogyan oldja meg azt a problemat, amit a kollega emlit?

És ez nem okoz semmilyen gondot a későbbiekben (kivéve esetleges főverzió ugráskor, de olyankor normális, hogy akár a főchart-ban, akár a subchart-ban máshogy vannak a value-k).

 

Hiszen ha ugy van ,ahogy irod, akkor mar az elso verzio valtaskor ugrik a valtozas...

Illeve , ha verzio valtaskor elhagyom az override ot, akkor igazabol mind1 h ott, vagy a generalt chart ban modositok, igy is ugy is elveszik a valtozas. :) 

sztm amugy ő valami ilyesmi formatumra gondolt: helm upgrade --install semaphore semaphoreui/semaphore -f override.yaml de ez lenyegeben a --set key=value yaml formatuma. Nyilvan amig igy inditom, addig el a valtozas, de pl ezt valami manageren keresztul (pl Komodor) nehezebb kivitelezni

Hiszen ha ugy van ,ahogy irod, akkor mar az elso verzio valtaskor ugrik a valtozas...

Az nem szükségszerű, hogy az egész konfigot teljesen új alapokra helyezik. Tipikusan nem. De ha főverzió váltás van, akkor amúgy is át kell futni, hogy mi változott. Vagy te bármilyen szoftvert úgy frissítesz, hogy durr bele, aztán vagy működik vagy nem? Vagy pedig nem frissítesz soha semmit, mert félsz, hogy esetleg egy konfig értéknek más lett a neve az új verzióban?

Ez a változás nem jön "váratlanul", nem értem ezt a rettegést. Te mondod meg explicit, hogy valamikortól újabb verzióját akarod használni a semaphore helm chart-nak. És csak ilyenkor (tipikusan csak major verzió ugrás esetén) változhat az, hogy mi a konfig értékek neve, akár a fő chart-ban, akár a subchart-ban. A subchart verziója nem változhat, anélkül, hogy a fő chart verzióját változtatod.

helm upgrade --install semaphore semaphoreui/semaphore -f override.yaml de ez lenyegeben a --set key=value yaml formatuma

Mindegy, hogy adod oda a helm-nek a value-ket, egyesével, vagy egy file-ban.

valami manageren keresztul (pl Komodor) 

Mindegy, hogy egy helm chart-ot parancssorból vagy bármi más management eszközön keresztül telepítesz. Ahol megadod a helm chart nevét, verzióját, ugyanott megadhatod a value-kat is. Ezek nem "tűnnek el", nem "romlanak el". Ha ebben a management eszközben explicit változtatod a helm chart major verziót, akkor megnézed, hogy a value-k elnevezésében volt-e változás az új helm chart verzióban, és annak megfelelően cselekszel.

Ez csak akkor nehezseg, ha kezzel futtatod a "helm upgrade ..." parancsot. A gyakorlatban erdemes erre valami scriptet hasznalni (nyilvan verziokezelt modon), amiben megadod a sajat override-od (-f override.yaml) + a secreteket --set modon beadod. Ezek jobb esetben valtozatlanul maradnak minor verzio valtaskor. Persze major verzio valtaskor at kell nezni, hogy mi torik.

így van, nem túl nagy. minden helm chartot nagyjából egyszer használok. Esetleg kétszer (dev és prod).

Te mit szeretsz a helm-ben? 

Nekem egy elcseszett helm chartot megfelelően felparaméterezni nagyjából ugyanannyi idő (és sokkal több frusztráció) mint az adott környezethez megfelelő kubernetes manifesteket odaszórni és gitbe felrakni.

Egy kubernetes cluster reinstall az nekem is nagyjából két parancs.

az adott környezethez megfelelő kubernetes manifesteket odaszórni és gitbe felrakni

Tegyük fel, hogy kiraksz valami manifest-et, ami 99%-ban megegyezik dev-en és prod-on. De egy kis eltérés mindig van, pl. memory limit vagy replica szám. Hogyan tartod precízen karban, ha egyszer a 99% rész változik, meg ha máskor az 1% rész változik? Pont a kis különbség miatt nem tudod az egészet copy-paste-elni dev-ről prod-ra, vagy legalábbis könnyű benne hibázni.

Erre jó a helm, hogy a 99% közös rész is külön követhető, verziózható. Meg az 1% különbség, a környezetenként eltérő value-k is külön követhetők.

asszem, a kubi vilagban ezzel: https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/

de a helm inkabb nekem arra jo, hogy nalam okosabbak irjak meg helyettem a manifesteket, foleg ha nem csak egy deploy+service+ingress harmasrol van szo.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Hát, pont erre nem annyira jó a Helm amit írsz, erre inkább a Kustomization való.

A Helm arra lenne jó - csak persze ezt is rosszul használjuk - hogy ha van valami reusable cuccod, ami paraméterezve ugyan, de sokszor kell kiraknod (pl: mariadb, bár azt is jobb központilag üzemeltetni), akkor megkönnyíti az átállást. De két példánynál (főleg a fenti esetben említett dev-prod szituációban) gyakorlatilag nincs olyan sok különbség amit menedzselni kell, pontosabban nincs olyan sok változatosság a különbségekben. Ezt akár egy bash scriptes templatinggel (ami sed-del/envsubst-tal kicseréli azt a pár paramétert) le lehet kezelni, akár két repóban átirogatom a dolgokat. Pont a 99%-os egyezés miatt valójában nagyon könnyű copy-pastelni, csak nem szabad a copy-paste -t elfelejteni.

Ha ugyanazt a dolgot ellenben 10x, 10 nagyon különböző konfiggal kell kirakni, na akkor jön jól a Helm chart, mert ott már lehet valamennyire programozni is a templatekben, speckó intelligenciát megvalósítani.

A másik hasznos dolog a Helm Chartokban az a feature kezelés, de ez is csak akkor nyer értelmet, ha van variety abban, hogy hol milyen feature-ket használsz.

Ezen felül, a bevett (és javasolt) gyakorlat a Helm Values verziókezelése és tárolása az upgrde-k megkönnyítése érdekében. Viszont egy ilyen esetben, amikor várható, hogy a chart módosulni fog, pont nagyon szopó tud lenni, hogy a chart tud változni észrevétlen, a custom values-t gyakorlatilag nem validáljuk sehogyan sem. aztán egyszer csak széttörik az egész deployment mindenestül.

Külön vicci amikor írod, hogy upgrade-nél érdemes elolvasni a changelog-ot. Megfelelően nagy infrastruktúra és megfelelően sok chart esetében erre gyakorlatilag nem szokott lenni elég kapacitás, onnan derül ki, hogy valami nem fasza, hogy DEV-en széttörik az egész a gecibe. Mivel a values-t nem lehet megfelelően előre validáltatni, hogy megfelel-e az upgrade-lt chart követelményeinek (lényegében: a helm template-tel ugyan meg lehet ezt csinálni, azonban az, hogy a helm template check lefut zöldre, még nem jelenti azt, hogy a nap végén abból egy működő chart lesz), ezért simán lehet, hogy akár egy minor verzió change is töri az upgrade-t (pont tegnap szaladtam bele egy ilyenbe).

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

De két példánynál (főleg a fenti esetben említett dev-prod szituációban) gyakorlatilag nincs olyan sok különbség amit menedzselni kell, pontosabban nincs olyan sok változatosság a különbségekben.

A Helm előnye az, hogy sokkal egyszerűbb a template és a values behelyettesítés. A kustomize kurva komplex tud lenni egy idő után még egyszerűbb esetben is, nemhogy valami if-else szerkezet esetén.

Ezt akár egy bash scriptes templatinggel (ami sed-del/envsubst-tal kicseréli azt a pár paramétert) le lehet kezelni, akár két repóban átirogatom a dolgokat.

A megszokáson kívül miért jó egy external nem K8s-nativ template rendszer használata?

https://iotguru.cloud

A megszokáson kívül miért jó egy external nem K8s-nativ template rendszer használata?

Átfogalmazom, mert ez lehet félrement.

Ha kevés dolgot kell változtatni (ingress, DB URL) akkor a helm chart kezelése, verzió managmentje, buildje, checkje plusz felesleges effort, nem egyszerűbbé hanem komplexebbé teszi a dolgokat. 2-3 fix égetett változó behelyettesítésnél (ahol fix helyre, ifezés és bármiféle átalakítás nélkül kell berakni a változókat) lényegében nincs a Helm-nek komoly benefitje (hiszen a values-t külön nem tudja validálni, ami legalább minimális értelmet adna ebben a speciális esetben), cserébe rak egy karbatartási terhet a projektre, tekintettel arra, hogy ez egy különálló csomaggá válik amit azért legalább semver szinten verziózni illik, plusz egy csomó metaadatot, egyebet kell kitölteni és karbantartani - anélkül, hogy érdemi hasznot hozna. Magyarul kis vagy egyszerű alkalmazásokhoz nem érdemes használni.

Abban a pillanatban, hogy komplex kezd lenni a dolog, if-else szerkezetek vagy feature kapcsolók megjelennek, már van értelme a Helm-nek. 

Összefoglalva: Én csak azt mondom, hogy a Helmnek megvan az az alsó komplexitási küszöbe, ami után validálódik az alkalamzása, de nem kellene ész nélkül mindenre is Helmet használni, puszátn csak azért, mert ez ma a trendy.

(abba bele se menjünk, hogy a Helm K8s-natív-e vagy sem. Szűken értelmezve amúgy nem az, lényegében egy földbuta build eszköz: fogalma sincsen a Kubernetesről, legenerál YAML-öket a templatek alapján, aztán hozzávágja a Kubernetes API szerverhez, kezdjen vele amit tud. Ha szar, az se derül ki az ő szintjén, majd visszaköpi amit a K8s visszadobott. Lényegében a template processingen + egy nagyon alap YAML szintaxis validáláson kívül semmit nem csinál a Helm a Kubernetes szempontjából. Nem véletlen, hogy a Flux/ArgoCD azok, amik beszélgetnek is a Kubernetessel és objektumkövetést végeznek, illetve hogy a legenerált Kuberenets objektumok bármiféle validálása csak és kizárólag plugineken keresztül lehetséges).

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Ha kevés dolgot kell változtatni (ingress, DB URL) akkor a helm chart kezelése, verzió managmentje, buildje, checkje plusz felesleges effort, nem egyszerűbbé hanem komplexebbé teszi a dolgokat.

És máris kettő különböző tool van ugyanarra a feladatra a szervezetben, egy helyett. Ennek minden előnyével és hátrányával együtt.

a helm chart kezelése, verzió managmentje, buildje, checkje plusz felesleges effort

A belső fejlesztésű dolgoknál nagyon egyszerű megoldásra jutottunk: a helm chart együtt van verziózva az adott alkalmazás forráskódjával. Tehát amikor docker image készül, akkor mindig készül a helm chart-ból is egy új verzió. Méretben elhanyagolható a docker image-hez képest. És feltételezem a docker image-ek verzió management-je, build-je stb. az már amúgy is meg van oldva. És akkor azzal együtt a helm chart-nak is meg van oldva.

Abban a pillanatban, hogy komplex kezd lenni a dolog, if-else szerkezetek vagy feature kapcsolók megjelennek, már van értelme a Helm-nek. 

Ez a legalapabb alkalmazásnál is előfordul, hogy if-else logika van a template-ben.

De nemcsak a template-ezés kapcsán vannak előnyei a helm-nek, hanem pl. az sem elhanyagolható, hogyha valamit törölni kell a clusterből, akkor nem neked kell utólag kitalálni, hogy vajon minek kapcsán mit is raktál bele. Hanem pont azt fogja törölni, amit létrehozott.

nos esteben egy darab chart nicns amibe ne lenne egy valag if, söt jelemzöen ciklusok meg ezaz, de ha ezt nem veszem figyelembe, akkor is sokkal kényelmesebb hogy vfentvan a buildelt chart harborban, a deploynál onna huza minden, az alkalmazásrepokon meg csak végig van másolva környzetenként egy values fájl és felparaméterezve. A te verziodal meg huzhatnál végig egy valag yaml-t a repokon, és mindbe irhatnád át kézel 600 helyen a selectorocat, pull secretet, labeleket, stb. Ez szerintem csepet sem produktiv. ha 1-2 cuccot futatsz jelemzöen 1 környzetben, megértem ha neked ez nem annyira hiányzik, de nagyon hamar eljön az, hogy elkezdesz munkaórákat veszteni rajta ha nem használod. És egyébként helmben lehet validátorokat irni.

Többen is írtátok a kustomization-t. Annak a képességei nagyon-nagyon a helm alatt vannak, egyáltalán nem tudja kiváltani, ha már egy kicsit is bonyolultabb logika van a template-ezhetőségben.

A bash script-es templating, meg annak a futtatása az csak egy nyűg. A helm-et sem parancssorból érdemes használni, hanem valamilyen GitOps megoldással, mondjuk Flux. És akkor egyből verziókövetve is van.

Külön vicci amikor írod, hogy upgrade-nél érdemes elolvasni a changelog-ot. 

Nem tudom, ebben mi a vicc. Ezt már mások is írták, de tőled is megkérdezem, hogy úgy szoktál frissíteni, hogy nem olvasod el, hogy mire kell felkészülni? Ráadásul a helm chart upgrade tipikusan nem "váratlanul" érkezik, hanem az egy explicit döntés, hogy oké, most upgrade-elünk egy új verzióra. És ha ennek ellenére is dev-en eltörik, akkor mi történik? A dev környezetre is 99.9999% SLA-t vállaltok? Azért van a dev környezet, hogy ott még időben lehessen javítani a hibát.

Van kismillió microservicünk, ezek viszonylag jól bonthatoak müködésül tekintetében nagyobb típusokra, ezekre irtam chartokat, így gitben jelemzöen csak pár paraméterben térnek el a values.yaml fájlok. Nagyon kényelmes, fájna vissztérni kustumizationre. Egyebként a 3. Féltöl származó cuccoknál is megkönyiti az életet, pl egy minio operátor amin sokesben pár sort valtoztatsz maximum, egy-két elretentö példatol(innn  is üdvőzlöm a loki karbantartoinak felmenőit) eltekinte szokták tartani ezek a chartok a strukturajukat is, max bövülnek inkább.

Hát... Mi is használunk GitOps-ot, én kimondottan visszalépésként élném meg, ha nem helm chart-okat raknánk ki GitOps-szal, hanem csak sima manifest-eket. A belső app-ok esetében is jól jön, sokszor teljesen különböző helyekre kell kirakni őket, amik közt nincs közös git repo. Ilyenkor jól jön a köztes lépés, hogy helm chart a csomagolás alapja.

Én írok chart-ot a belső appokhoz (meg amihez nincs), mert házon belüli standard, de honestly, néha nagyon seggfájásnak élem meg. Amióta van az AI, és az egyszerűbb chartokat le tudja generálni akár egy jól felparaméterezett docker-compose -ból is, azóta kicsit kevésbé fáj ez az egész, de still sok esetben nem látom az előnyét olyan appnál, ami 1 max 2 namespace-be van kirakva. A values meg copy-paste a legtöbb alkalmazásnál, kell bele egy ingress url, egy replikaszám, meg a docker koordináta, opcionálisan egy secret név, és ennyi. Ritkább esetben kell bele egy adatbázis elérés.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Ha a fochart kesobb javitja a hibat (pl. mas repot hasznal)

Radasul ha a subchart kesobb megvaltozik (pl. mas key-neven varja az image beallitasokat)

Ezek mind olyan dolgok, hogyha valami megváltozik, hogy hogyan kell konfigurálni, akkor azt le kell követni. Mindegy, hogy a fő chart, vagy a subchart. Ilyen szempontból a subchart-ra úgy kell gondolni, mint a fő chart elválaszthatatlan része. Ez ellen a világon semmi nem véd, amióta vannak szoftverek és vannak újabb verzióik, mindig is volt olyan, hogy megváltozott a konfig file-juk formátuma. Ez nem a helm sajátossága.

Váratlanul nem jön ez a változás, mindig csak akkor, ha újabb verzióra frissítesz.

Annyi segítség szokott lenni, hogyha megnézed a helm chart-ok leírását, általában az ilyen változások tipikusan új major verzióban jönnek, helyesen alkalmazva a semver-t. És szokott lenni egy upgrade guide, hogy mi változott, hogyan változott a konfig formátuma az előző major verzióhoz képest.

( _Franko_ v | 2025. 11. 04., k – 08:46 )

A workaround az hogy bitnami/... helyett bitnamilegacy/... legyen az image, viszont ez nem frissül többé.

Amúgy tele volt a net vele júliusban már, hogy kirántják a szőnyeget azok alól, akik nem fizetnek. Több cég is elindult erre, szóval így járt a kaniko, a minio, és még egy-kettő, ami az utóbbi hónapban bezárta az ingyenes boltot, szóval érdemes figyelni a híreket.

https://iotguru.cloud

Igen, errol sajna lemaradtam... a MiniO-t azt viszont lattam, at is tertem erre a forkra (ahol kell, en foleg mc-t hasznalok): https://github.com/georgmangold/console

 

A kaniko is uj... akkor ott is szet kell neznem, mert van amim arra epul (nyilvan)

Szerk atpakoltam magam Buildah-ra. szerencsere nincs (meg) sok CI build 

Nekem a buildah nem mindig működik ott, ahol a kaniko igen, és még nem mindenütt tudtam kiváltani emiatt. Még mindig tanulom a Kubernetest, hát ezek a hibaüzenetek se könnyitik meg az üzemeltetést sokszor.

Szerencsére a régebbi kaniko image-k asszem helyben lettek hagyva, legalábbis eddig még nem tört emiatt build. 

Azt nem értem, hogy ezeket miért nem lehet békin hagyni, és miért nem az újaknak csinálnak egy mittudomén bitnami2, kaniko2 image prefixet? Iszonyú rövid idő van az átállásra, és sokszor iszonyú szopás az, hogy másutt van ugyanaz az image.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

 A kaniko nem lett fizetös, csak archiválta a projectet a google, nem jön hozzá több frissités, a a régi imagek továbbra is használhatoak modosítás nélkül. Más kérdés hogy mivel nem jön több patch szoval igyis ugyis cserélni kell. Én még nem jutottam el idáig nálunk, de szerintem mezei buildx lesz helyette.

A kaniko nem lett fizetös

A chainguard átvette a karbantartást és pénzért van az image: https://images.chainguard.dev/directory/image/kaniko/versions

Más kérdés hogy mivel nem jön több patch szoval igyis ugyis cserélni kell.

A forrás továbbra is open, aktív a projekt, szóval onnan lehet saját image-t készíteni: https://github.com/chainguard-dev/kaniko

https://iotguru.cloud

Egyelőre én nem érzek hatalmas urge-t a cseréjére. Volt ahol eltört, és cseréltük, de jelenleg a fent említett problémák miatt sok effort lenne mindenhol cserélni. Mivel ez direktben nem végez kiszolgálást, nekem nem hiányoznak a patchek, don't fix if it ain't broken.

Az újabb projekteknél már buildah-val megyünk ha lehet, mert elég jó dolgok vannak benne.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-