Why you are most likely using Helm wrong when using it in a #GitOps setup What I see a lot of companies who use #Helm do, is to define the version (or tag) of the #docker image in the actual helm chart. Some hardcode it in the #template file, others in the default values.yaml file. And then when they need to release their software component, they create a new release of their Helm chart before releasing their software component. This mean that you have to make a change in two repositories. You'll need a new release of your Helm chart and one of your service. This is wrong in so many ways. If you are using #Flux you produce a #HelmRelease file. This file containers a reference to whatever value file in the chart you want to use as your default values, and you can add your own values that overload the default values. Your helm chart should only have a new release if there are changes to the actual templating part. In this section you can define the image tag / version. Like this :
Henrik Høegh’s Post
More Relevant Posts
-
This repository offers an opinionated guide to building Kubernetes controllers. I'll share the best practices and design patterns I've found useful through maintaining open-source projects like: We will be using Kubebuilder to create new APIs and controllers. #devopskhan
To view or add a comment, sign in
-
Software Development Habits - 16/∞ Unlocking the 'Makefile Effect': Streamline Your Workflow! Ever found yourself copying and tweaking old configuration files just to get things working? You're not alone! This common shortcut, dubbed the "Makefile Effect", highlights a crucial point: when tools become too complex, we often resort to reusing existing setups instead of crafting new ones from scratch. While this can be a quick fix, it may also signal that our tools need to be more user-friendly. Let's aim for simplicity and clarity in our workflows to boost efficiency and understanding across the board! For a deeper dive into this concept, check out the original discussion here: https://lnkd.in/gFbGntrN #SoftwareDevelopment #BestPractices #DeveloperJourney #CareerGrowth #SoftwareEngineering #TechIndustry #SoftwareDelivery #PersonalDevelopment
To view or add a comment, sign in
-
Using loops in #Terraform makes it easy to create multiple resources without repeating code, following the DRY (Don't Repeat Yourself) code principle. Our new blog post covers for loops with "for_each" and "count," when to use them, example scenarios, and more ⬇
To view or add a comment, sign in
-
Check out the latest additions to the Grafbase CLI. You can now deploy to branches, managed environment variables and manage branches from your terminal or CI. https://lnkd.in/dnD7FSt9
To view or add a comment, sign in
-
The author debunks the myth that achieving 100% code coverage means your software is bug-free. Using a simple yet impactful example, Kapelonis demonstrates that even with perfect code coverage, bugs can still exist. The article discusses a one-line function that, despite having 100% unit test coverage, contains a divide-by-zero error, highlighting the limitations of code coverage as a metric for software quality. https://lnkd.in/dQ-_xdCR
To view or add a comment, sign in
-
Deploying Helm Charts with ArgoCD using Helmfile is not supported out of the box. In this article, I will show how to extend ArgoCD using config management plugins to support Helmfile: https://lnkd.in/d4iWK9mi #kubernetes #helmfile #argocd #helm
To view or add a comment, sign in
-
🛠️ Mastering Dockerfile Instructions for Seamless Containerization 🐳 Ever wondered how Docker simplifies software deployment? It all starts with the Dockerfile—a blueprint for creating Docker images. Here's a quick rundown of key instructions to build and customize your images: 1️⃣ FROM: Specify the base image to build upon. 2️⃣ RUN: Execute commands to install software or configure the container. 3️⃣ COPY/ADD: Transfer files into the container, with ADD offering extra functionality like extracting compressed files. 4️⃣ WORKDIR: Define the working directory inside the container. 5️⃣ ENV/ARG: Set environment or build-time variables for dynamic configurations. 6️⃣ CMD/ENTRYPOINT: Define the default command or entry point for the container. 7️⃣ EXPOSE/VOLUME: Open ports and manage persistent storage. 8️⃣ LABEL/HEALTHCHECK: Add metadata and ensure the container is healthy. #Docker #DockerFile
To view or add a comment, sign in
-
-
Versioning your container image is the best thing that you can do when working with container.
To view or add a comment, sign in
-
73% reduction in deployment failures. Not a typo. Here's our exact Docker configuration that made it happen: - Multi-stage builds to minimize image size - Health checks in every container - Proper layer caching - Volume mounting for development - Environment-specific docker-compose files The game-changer? Standardizing our development environment across the entire team. P.S. I’ve created a detailed guide to help you replicate this setup step by step. Check the carousel. Or if you want the pdf in you DM, just comment "Guide" and I'll share it with you. Let's make deployment failures a thing of the past! #DockerConfiguration #DevOpsExcellence #DeploymentSuccess
To view or add a comment, sign in
Kubernetes | GitOps | DevOps | AWS | Azure | Docker | Terraform | SRE | Linux | Git | Python | CI/CD | Ansible | Bash
10moAs a side note to this, you can use Renovate Bot to propose PRs on Flux HelmReleases. Quite useful when using Flux to deploy 3rd Party Helm charts: https://docs.renovatebot.com/modules/manager/flux/