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⁠.

  • 929 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…

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... 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.

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