Een Helm chart voor je Magento- of Laravel-platform die je over drie jaar nog begrijpt
Een Helm chart is de bouwtekening van je applicatie op Kubernetes. Een goede chart beschrijft alle rollen van je platform, van webpods tot cron en workers, met één values-bestand per omgeving. Een slechte chart is een kopie van een voorbeeld van internet met tweehonderd opties die niemand gebruikt. Het vaste team schrijft charts op maat voor Magento en Laravel, combineert ze waar nodig met Kustomize, en houdt ze daarna bij.
- Eigen chart per platformtype, geen ongeteste community-chart
- Values per omgeving in Git, secrets via External Secrets
- Database, cache en zoekmachine bewust gekozen na de Bitnami-wijziging
Wat is een Helm chart, en wanneer kies je Kustomize?
Helm is de package manager van Kubernetes en een CNCF graduated project. Een Helm chart is een map met templates voor Kubernetes-resources, een Chart.yaml met naam en versie, en een values.yaml met standaardwaarden. Bij het installeren vult Helm de templates met jouw values en past het resultaat toe op het cluster. Dezelfde chart kan zo test, acceptatie en productie uitrollen, met elk andere aantallen, domeinen en resources.
Kustomize werkt anders. Het heeft geen templatetaal. Je schrijft gewone YAML als base, en per omgeving een overlay die daar patches overheen legt: een ander aantal replicas, een extra annotatie, een ander image. Kustomize zit ingebouwd in kubectl via kubectl apply -k, en Argo CD ondersteunt het direct.
De keuze is minder principieel dan vaak wordt gedaan. Helm is sterk als je veel varianten genereert uit één definitie: meerdere shops, optionele componenten, lussen over een lijst consumers. Kustomize is sterk als je kleine, expliciete verschillen tussen omgevingen wilt, of als je een chart van derden net iets anders wilt hebben zonder hem te forken. In de praktijk gebruiken we vaak allebei: een eigen Helm chart voor de applicatie, en Kustomize voor platformcomponenten of als laatste correctielaag.
Op deze pagina staat hoe wij charts voor Magento en Laravel opzetten, hoe we values per omgeving organiseren, hoe versiebeheer en tests werken, en wat de wijziging bij Bitnami in 2025 betekent voor de charts die je voor databases en caches gebruikt.
Helm of Kustomize: de keuze per situatie
Geen geloofsvraag. Kies per laag wat het minste onderhoud oplevert.
| Situatie | Onze keuze | Waarom |
|---|---|---|
| Eigen Magento- of Laravel-applicatie met meerdere rollen | Eigen Helm chart | Lussen over consumers en workers, optionele componenten zoals Varnish of Reverb, één values-bestand per omgeving |
| Meerdere shops of tenants op hetzelfde platform | Eén Helm chart, values per shop, gegenereerd via een Argo CD ApplicationSet | Verschillen tussen shops staan expliciet in Git, de chart blijft één bron |
| Kleine verschillen tussen test en productie | Helm values, of Kustomize-overlay als je zonder templates wilt werken | Leesbaar en zonder logica in YAML |
| Chart van derden die net niet doet wat je wilt | Kustomize over de gerenderde chart | Patchen zonder te forken, upgrades van de chart blijven mogelijk |
| Platformcomponenten zoals cert-manager of External Secrets | Officiële Helm chart van het project, values in Git | Het project onderhoudt de chart, jij alleen de values |
| Eenmalige of zeer simpele resources | Platte YAML of een Kustomize-base | Een chart voor drie resources is overhead |
Plan een vrijblijvend gesprek over je project
Een half uur via video met de mensen die het werk ook echt doen. Kies hieronder een moment dat jou past.
- Direct met het vaste team, geen tussenlagen
- Concrete feedback op je huidige situatie of plannen
- Eerlijk advies, ook als het antwoord "niet doen" is
- Indicatie van kosten en tijdlijn
Plan een gratis Tech Check
Vrijblijvend jouw uitdagingen bespreken
Of bel direct: 0591-239 299
Een eigen Helm chart voor Magento: wat erin zit
Een Magento-chart beschrijft niet één Deployment maar een handvol workloads die hetzelfde image delen. De webrol draait Nginx en PHP-FPM, als twee containers in één pod of als losse pods. Varnish krijgt een eigen Deployment met de VCL in een ConfigMap. Cron draait als Deployment met precies één replica, of als CronJob met concurrencyPolicy Forbid. Elke queue-consumer wordt een eigen Deployment, gegenereerd met een range-lus over een lijst in de values. Een nieuwe consumer toevoegen is één regel in values.yaml.
Daaromheen staan de resources die een productieplatform nodig heeft: Services, een HTTPRoute voor de Gateway API, een HorizontalPodAutoscaler of KEDA ScaledObject per rol, PodDisruptionBudgets zodat node-onderhoud niet alle webpods tegelijk stopt, NetworkPolicies, en een ServiceMonitor voor Prometheus. De setup:upgrade-Job zit erin als Helm hook of als Argo CD PreSync-hook. Argo CD vertaalt de standaard Helm hooks zoals pre-install en pre-upgrade naar zijn eigen hookfasen, zodat de chart met en zonder Argo CD werkt.
Wat er niet in zit: MySQL, OpenSearch en vaak ook Valkey. Die draaien bij voorkeur als managed dienst buiten het cluster, of via een eigen chart of operator met een eigen levenscyclus. Een applicatiechart die ook de database installeert, maakt van elke helm uninstall een risico. Zie de pagina over Magento op Kubernetes voor de volledige architectuur.
Een eigen Helm chart voor Laravel
Een Laravel-chart is eenvoudiger, maar heeft dezelfde opbouw: één image, meerdere rollen. De webrol draait php-fpm met Nginx, of Laravel Octane met FrankenPHP, Swoole of RoadRunner. Horizon of gewone queue workers krijgen een eigen Deployment, eventueel per queue, met een terminationGracePeriodSeconds die lang genoeg is om lopende jobs af te maken. De scheduler draait als Deployment met één replica en php artisan schedule:work, of als CronJob die elke minuut schedule:run start.
Optioneel komen daar Reverb voor websockets en een migratie-Job met php artisan migrate --force bij. Configuratie gaat via environment-variabelen: niet-gevoelige waarden uit een ConfigMap, gevoelige waarden uit een Secret die External Secrets Operator aanmaakt. In de chart staat dan alleen de naam van die Secret, nooit de inhoud. Storage gaat naar S3-compatibele object storage, zodat geen enkele pod iets op lokale schijf hoeft te bewaren.
Een detail dat vaak vergeten wordt: als een ConfigMap verandert, herstarten pods niet vanzelf. In Helm los je dat op met een checksum-annotatie op de pod-template, berekend over de gerenderde ConfigMap. Verandert de config, dan verandert de checksum en rolt Kubernetes nieuwe pods uit. Kustomize doet hetzelfde met de hash-suffix van configMapGenerator. De complete opzet staat in ons artikel over een Helm chart voor een Laravel-app.
Values per omgeving: wat waar staat
De chart is generiek. Alles wat per omgeving verschilt, staat in values. Alles wat geheim is, staat nergens in Git.
values.yaml in de chart
- Veilige standaardwaarden: resource requests en limits, probes, securityContext met runAsNonRoot
- Lijsten met consumers of workers, standaard uitgeschakeld waar dat kan
- Geen domeinen, geen hostnames van databases, geen imagetag behalve een placeholder
- Een values.schema.json, zodat een typfout in een values-bestand bij het renderen al faalt
values per omgeving in de deploy-repository
- Imagetag of digest, gekoppeld aan een commit in de app-repository
- Aantallen replicas, autoscaling-grenzen en resources per rol
- Hostnames, routes en TLS-instellingen
- Namen van Secrets en ExternalSecrets, niet de waarden
- Feature flags zoals Varnish aan of uit, of Reverb wel of niet
Niet in values
- Wachtwoorden, API-sleutels, de Magento crypt key en de Laravel APP_KEY
- Gegevens die per release veranderen buiten de imagetag om
- Logica: als een values-bestand voorwaarden gaat bevatten, hoort dat in de chart
- Kopieën van de standaard values; alleen de afwijkingen opnemen houdt diffs leesbaar
Kustomize-overlays: base, overlays en patches
Met Kustomize begin je met een base: de resources zoals ze in elke omgeving gelden. Daarnaast komt per omgeving een map met een kustomization.yaml die naar de base verwijst en daar wijzigingen overheen legt. Het images-veld zet de imagetag per omgeving. Een patch verhoogt replicas of resources op productie. Een namePrefix of namespace scheidt omgevingen in hetzelfde cluster. Components bundelen optionele stukken die je in sommige overlays wel en in andere niet aanzet.
Kustomize kan ook Helm charts renderen via het helmCharts-veld, mits je met --enable-helm bouwt. Daarmee neem je een chart van derden en zet je er patches overheen, zonder te forken. In Argo CD zet je dat aan via de Kustomize-buildopties. Het werkt goed, maar maakt de keten langer. We gebruiken het alleen als de chart zelf niet genoeg values biedt.
De valkuil bij Kustomize is het tegenovergestelde van Helm: geen templates betekent herhaling. Tien shops met elk een overlay worden tien mappen die bijna hetzelfde zijn. Op dat punt is een Helm chart met een ApplicationSet meestal beter onderhoudbaar.
Bitnami na 2025: waarom je databasecharts opnieuw moet kiezen
Jarenlang was een Bitnami-chart de snelste manier om MySQL, MariaDB, Redis, RabbitMQ of PostgreSQL in een cluster te zetten. Dat is veranderd. Broadcom, eigenaar van Bitnami, is op 28 augustus 2025 begonnen met het afbouwen van de gratis catalogus. De volledige historie van Debian-gebaseerde images en charts is verplaatst naar een legacy-repository, bitnamilegacy op Docker Hub, die geen updates meer krijgt. Gratis publieke images zijn beperkt tot een kleine set met alleen de latest-tag, bedoeld voor ontwikkeling. Wie versies, updates en ondersteuning wil, gaat naar het betaalde Bitnami Secure Images. De overgang moest eind september 2025 rond zijn.
Wat dit concreet betekent: een chart die nog naar docker.io/bitnami verwijst, kan bij een nieuwe installatie of na het verdwijnen van een tag falen met een ImagePullBackOff. Omzetten naar bitnamilegacy laat het weer draaien, maar dan draai je op images zonder securityfixes. Dat is een tijdelijke pleister, geen oplossing. De broncode blijft onder de Apache 2.0-licentie beschikbaar, dus zelf bouwen kan, maar dan ben je zelf verantwoordelijk voor het bijhouden.
De CNCF heeft benadrukt dat Helm zelf niet geraakt is. Het gaat om de catalogus van één leverancier. Voor ons was het een goede aanleiding om per component opnieuw te kiezen, met een voorkeur voor charts en operators die door het project zelf worden onderhouden.
Alternatieven per component
Onze volgorde van voorkeur: managed dienst buiten het cluster, dan een chart of operator van het project zelf, dan pas iets anders.
MySQL en MariaDB
Bij voorkeur managed bij je cloudprovider, met backups en point-in-time recovery. In het cluster alleen via een operator, zoals de MariaDB Operator of Percona Operator for MySQL.
Lees verder →Valkey of Redis
Het Valkey-project publiceert inmiddels een eigen Helm chart. Let op: niet in-place uitwisselbaar met de Bitnami-chart, dus plan een migratie. Managed Valkey kan ook.
Lees verder →OpenSearch
Het OpenSearch-project heeft eigen Helm charts en een Kubernetes-operator. Voor productie met veel data is een managed OpenSearch-dienst vaak minder werk.
Lees verder →RabbitMQ
De RabbitMQ Cluster Operator van het RabbitMQ-team zelf, of een managed broker. Voor Magento-consumers met AMQP en voor Laravel-queues die niet op Redis draaien.
Lees verder →PostgreSQL
Voor Laravel-apps op Postgres: CloudNativePG, een CNCF-project met backups naar object storage, of een managed Postgres-dienst.
Lees verder →Monitoring en platform
kube-prometheus-stack, Grafana, Loki, cert-manager en External Secrets hebben elk een chart van het eigen project. Daar was Bitnami nooit nodig.
Lees verder →Chartversies, Helm 4 en testen voor je uitrolt
Een chart heeft twee versies in Chart.yaml. version is de versie van de chart zelf en volgt semver: een nieuwe optionele value is een minor, een hernoemde value een major. appVersion is de versie van de applicatie die erin draait. Bij een eigen applicatiechart overschrijven we de imagetag per omgeving, dus appVersion is informatief. De chartversie verhogen we bij elke wijziging en publiceren we als OCI-artefact in dezelfde registry als de images, met helm push naar een oci://-adres.
Afhankelijkheden staan in Chart.yaml onder dependencies, met een Chart.lock die de exacte versies vastlegt. Gedeelde stukken, zoals labels, probes en securityContext, zetten we in een library chart die door de Magento- en Laravel-charts wordt gebruikt. Zo pas je een standaard één keer aan.
Helm 4 is in november 2025 verschenen, de eerste nieuwe hoofdversie in zes jaar. De belangrijkste verandering voor bestaande charts: nieuwe releases gebruiken standaard server-side apply, terwijl releases die met Helm 3 zijn gemaakt bij een upgrade op de oude methode blijven tenzij je dat expliciet wijzigt. Daarnaast zijn vlaggen hernoemd, zoals --atomic naar --rollback-on-failure, en is het pluginsysteem vernieuwd. Helm 3 krijgt volgens het Helm-project security-fixes tot 10 februari 2027. Pipelines en scripts die op Helm 3-vlaggen leunen, moeten dus voor die datum mee. Gebruik je Argo CD, dan rendert Argo CD de chart zelf en merk je minder van de CLI-wijzigingen.
Testen doen we in de pipeline, bij elke wijziging in de chart of de values: helm lint, helm template voor elke omgeving, validatie van de gerenderde YAML tegen de Kubernetes-schema's met kubeconform, en unittests met de helm-unittest-plugin voor de logica die er echt toe doet. Bijvoorbeeld: als autoscaling aan staat, mag de Deployment geen vast aantal replicas hebben. Een diff van de gerenderde manifests tegen de huidige versie hoort bij elke pull request, zodat de reviewer ziet wat er in het cluster gaat veranderen en niet alleen wat er in de template verandert.
Wanneer een eigen chart niet loont
Een eigen chart is code die onderhouden moet worden. Voor één simpele app met één omgeving is een Kustomize-base met een paar resources sneller te begrijpen en goedkoper in beheer. En draait je webshop prima op managed hosting zoals Hypernode, dan heb je geen chart nodig, omdat je geen Kubernetes nodig hebt. Dat zeggen we ook zo.
Een eigen chart loont als je meerdere omgevingen, meerdere shops of meerdere rollen per applicatie hebt, of als je verwacht dat het platform de komende jaren groeit. Dan betaalt elk uur in een goede chart zich terug in deploys die voorspelbaar zijn.
Zo bouwen we je Helm chart
Van bestaande manifests of een losse server naar een chart die elke omgeving uitrolt.
- 1
Inventarisatie van rollen
Welke processen draaien er nu: web, cron, consumers, workers, websockets. Welke configuratie verschilt per omgeving, en welke diensten draaien buiten het cluster.
- 2
Chart-opzet
Chart.yaml, library chart met gedeelde standaarden, templates per rol en een values.schema.json. Veilige defaults, zoals runAsNonRoot en resource requests.
- 3
Values per omgeving
Een values-bestand per omgeving in de deploy-repository, met alleen de afwijkingen. Secrets via External Secrets Operator.
- 4
Stateful diensten kiezen
Per database, cache en zoekmachine de keuze tussen managed dienst en operator. Bestaande Bitnami-charts in kaart brengen en vervangen.
- 5
Tests in de pipeline
Lint, template per omgeving, kubeconform, helm-unittest en een diff van de gerenderde manifests bij elke pull request.
- 6
Publiceren en uitrollen
Chart als OCI-artefact in de registry, uitgerold via Argo CD. Daarna onderhoud: Kubernetes-API-wijzigingen, nieuwe rollen en Helm-versies.
Wat je opgeleverd krijgt
- Eigen Helm chart voor je Magento- of Laravel-platform, met templates per rol
- Library chart met gedeelde standaarden voor labels, probes en security
- values.schema.json en values-bestanden per omgeving
- Kustomize-overlays waar die eenvoudiger zijn dan values
- Inventaris van gebruikte Bitnami-charts met per component een vervanger
- CI-stappen voor lint, rendering, schemavalidatie, unittests en manifest-diffs
- Chart gepubliceerd als OCI-artefact, met semver-versiebeheer
- Documentatie van alle values, met voorbeelden per omgeving
Waarom Coding.nl voor je Helm charts
Charts vanuit het platform
We weten welke processen Magento en Laravel draaien en wat er misgaat als cron dubbel loopt. Dat zit in de chart, niet in een handleiding ernaast.
De mensen die het bouwen, beheren het
Geen overdracht aan een ander team. Wie de chart schrijft, houdt hem bij en kijkt mee als een release faalt.
Bewuste keuzes na Bitnami
We kiezen per component opnieuw, met een voorkeur voor managed diensten en charts van het project zelf. Geen pleister met legacy-images.
Eerlijk over de noodzaak
Als Hypernode Silver Partner weten we wanneer managed hosting goedkoper en eenvoudiger is dan een cluster met charts.
Verder lezen
- ›Helm-chart voor je Laravel-app: structuur, values en valkuilen
- ›Magento 2 op Kubernetes: de architectuur per component
- ›Argo CD sync waves en hooks: migraties veilig uitrollen
- ›Kubernetes secrets: External Secrets Operator vs Sealed Secrets
- ›Laravel op Kubernetes: Horizon, queues en scheduler inrichten
- ›Redis vs Memcached voor Magento 2 sessions
- ›Elasticsearch vs OpenSearch voor Magento 2
- ›Magento 2 en Docker — lokale development setup die werkt
- ›Kubernetes of managed hosting voor je webshop?
Veelgestelde vragen
Een chart die je platform echt beschrijft?
Stuur ons je huidige manifests, charts of serveropzet. We laten zien welke rollen erin zitten, welke Bitnami-afhankelijkheden vervangen moeten worden, en wat een eigen Helm chart voor jouw platform oplevert.