Argo CD¶

15 décembre 2025
dans Argo CD
1 min de lecture

Labels Argo CD UI

podinfo-appset.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  labels:
    app.kubernetes.io/name: podinfo
  name: podinfo
  namespace: argocd
spec:
  goTemplate: true
  generators:
  - list:
      elements:
      - name: production
        server: https://production-control-plane:6443
      - name: staging
        server: https://staging-control-plane:6443
  template:
    metadata:
      name: 'podinfo-{{.name}}'
      labels:
        environment: '{{.name}}'
        app: podinfo
      finalizers:
        - resources-finalizer.argocd.argoproj.io
    spec:
      project: default
      source:
        repoURL: https://github.com/stefanprodan/podinfo.git
        targetRevision: HEAD
        path: kustomize
      destination:
        server: '{{.server}}'
        namespace: podinfo
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
          - CreateNamespace=true

Pour filtrer dans l'UI ArgoCD, vous avez besoin des labels dans template.metadata.labels

13 décembre 2025
dans Argo CD
1 min de lecture

Brouillon

Argo CD autopilot

test

13 décembre 2025
dans Argo CD
1 min de lecture

Brouillon

Mono vs Multi Repo

test

12 décembre 2025
dans Argo CD, Helm
18 min de lecture

Brouillon

Oui, tu peux récupérer la configuration complète d’un chart Helm (comme Reloader) en utilisant Helm directement, ce qui te permet d'obtenir un fichier values.yaml complet pour personnaliser ton déploiement.

Voici comment faire pour récupérer le fichier values.yaml complet d’un chart Helm, sans avoir à visiter le dépôt GitHub.

1. Ajouter le dépôt Helm de Stakater

Si tu veux utiliser le chart Helm pour Reloader, il faut d'abord ajouter le dépôt Stakater qui contient ce chart.

helm repo add stakater https://stakater.github.io/stakater-charts
helm repo update  # Mettre à jour les informations du dépôt

2. Récupérer le fichier `values.yaml` complet

Ensuite, pour récupérer le fichier values.yaml complet du chart Reloader, tu peux utiliser la commande helm show values. Cela te permettra d'afficher les valeurs par défaut du chart.

Voici la commande pour récupérer le fichier values.yaml complet pour Reloader :

helm show values stakater/reloader > reloader-values.yaml

Cette commande fait deux choses :

Elle récupère les valeurs par défaut du chart Reloader depuis le dépôt Stakater.
Elle sauvegarde ces valeurs dans un fichier reloader-values.yaml sur ton système.

3. Vérifier le fichier `values.yaml`

Après avoir exécuté la commande ci-dessus, tu peux ouvrir le fichier reloader-values.yaml pour voir toutes les options de configuration disponibles :

cat reloader-values.yaml

Cela te donnera la configuration complète du chart, que tu peux ensuite personnaliser selon tes besoins.

4. Utiliser ce fichier dans ArgoCD

Une fois que tu as récupéré et personnalisé ton fichier values.yaml, tu peux l’utiliser dans un manifeste ArgoCD pour déployer Reloader via Helm, comme je l'ai expliqué dans les étapes précédentes.

Exemple de commande pour récupérer les valeurs d’un chart spécifique

Si tu veux simplement vérifier ou afficher les valeurs d’un chart sans les sauvegarder dans un fichier, tu peux aussi exécuter cette commande directement dans le terminal :

helm show values stakater/reloader

Cela affichera le contenu du values.yaml par défaut directement dans la sortie standard (ton terminal).

Récapitulatif :

Ajouter le dépôt Helm de Stakater : helm repo add stakater https://stakater.github.io/stakater-charts
Récupérer le fichier values.yaml complet : helm show values stakater/reloader > reloader-values.yaml
Utiliser le fichier values.yaml dans ton application ArgoCD en le référencant dans ton manifeste.

Cela te permet de récupérer toutes les configurations possibles pour Reloader et de les personnaliser à ta convenance.

Tu souhaites probablement obtenir un fichier values.yaml complet pour Reloader afin de pouvoir personnaliser complètement ton déploiement. La configuration complète du chart Helm Reloader est en fait définie dans le chart Helm lui-même.

Le chart officiel de Reloader est maintenu sur GitHub et se trouve dans le dépôt de Stakater, qui propose le chart Helm pour Reloader.

Étapes pour trouver le `values.yaml` complet

Accéder au chart Helm sur GitHub :

Le chart officiel de Reloader se trouve dans le dépôt Stakater sur GitHub.

Lien vers le dépôt GitHub du chart Helm de Reloader : https://github.com/stakater/Reloader

Dans ce dépôt, tu peux trouver la version complète du fichier values.yaml qui est utilisée pour configurer Reloader via Helm.

Explorer le fichier values.yaml complet :

Tu peux accéder au fichier values.yaml du chart Reloader directement dans le dépôt GitHub de Reloader. Voici comment trouver ce fichier complet sur GitHub.

Lien vers le fichier values.yaml du chart Helm de Reloader : https://github.com/stakater/Reloader/blob/master/charts/reloader/values.yaml

Ce fichier contient toutes les options de configuration disponibles pour le chart Reloader, y compris les configurations des composants comme :

Reloader Deployment (réplicas, ressources, labels, etc.)
Argo Rollouts (activation, options de mise à jour)
Service Account
Node selectors
Tolerations
Affinities
Helm Parameters (comme global, image, resources, etc.)
Alertmanager (si tu veux configurer des alertes)
Grafana (si tu veux intégrer un tableau de bord de monitoring)
Et bien plus !
Exemple d'un fichier values.yaml complet pour Reloader :

Voici un extrait d'un fichier values.yaml typique pour Reloader, tel qu'il pourrait être trouvé dans le chart officiel, avec des commentaires pour t'aider à comprendre chaque option :

# Default values for reloader.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

global:
  image:
    pullPolicy: IfNotPresent
    repository: stakater/reloader
    tag: latest

reloader:
  # Whether to use Argo Rollouts or not.
  isArgoRollouts: false
  reloadStrategy: annotations # Available options: annotations or labels

  # Deployment configuration
  deployment:
    replicas: 1
    nodeSelector: {}
    tolerations: []
    affinities: {}

    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 500m
        memory: 512Mi

    # Set this to false if you don't want Reloader to create its own ServiceAccount.
    createServiceAccount: true
    serviceAccountName: reloader

  # Enable or disable the reloader feature
  enableReloader: true

  # Settings related to the Kubernetes Watcher
  watchNamespace: default  # Specify the namespace to watch for changes in ConfigMap/Secret

  # Optionally, you can define a list of namespaces to be watched for changes.
  watchNamespaces:
    - default
    - kube-system

# Configuration for Argo Rollouts integration
argoRollouts:
  enabled: false
  rolloutApiVersion: v1alpha1
  namespace: argocd

# Set values for the image of Reloader.
image:
  repository: stakater/reloader
  tag: "v0.0.117"
  pullPolicy: IfNotPresent

# Resources for the Reloader container.
resources:
  requests:
    memory: 128Mi
    cpu: 100m
  limits:
    memory: 512Mi
    cpu: 500m

# Configuration for affinity and tolerations
affinity: {}
tolerations: []
nodeSelector: {}

# Configuration for alertmanager and Grafana integration
alertmanager:
  enabled: false
  namespace: monitoring

grafana:
  enabled: false
  namespace: monitoring

# Optional annotations for your deployment
annotations: {}

# Enable the Reloader service (default is disabled)
service:
  enabled: false
  type: ClusterIP
  port: 8080

Description des sections importantes :

global : Paramètres globaux comme l'image Docker utilisée pour Reloader.
reloader : Les options principales pour configurer Reloader, comme le nombre de réplicas, le nom de service, les ressources, etc.
watchNamespace et watchNamespaces : Spécifie les namespaces que Reloader doit surveiller pour détecter les changements dans les ConfigMaps et les Secrets.
argoRollouts : Permet d'intégrer Reloader avec Argo Rollouts pour des mises à jour progressives. Si ce n'est pas nécessaire, tu peux le désactiver.
resources : Définir les ressources (CPU, mémoire) pour les pods de Reloader.
affinity et tolerations : Options pour les nœuds où les pods de Reloader peuvent être déployés.
alertmanager et grafana : Options pour activer l'intégration avec Alertmanager et Grafana pour la surveillance.
service : Configuration du service associé à Reloader (s'il est activé).

4. Utiliser ce `values.yaml` dans ton déploiement avec ArgoCD

Une fois que tu as téléchargé ou copié ce fichier values.yaml, tu peux l'utiliser dans ta configuration ArgoCD, comme expliqué dans les étapes précédentes. Le fichier sera ensuite référencé dans ton manifeste ArgoCD Application, de sorte qu'ArgoCD utilise ce fichier lors du déploiement de Reloader via Helm.

Exemple d'application ArgoCD :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: reloader-prod
  namespace: argocd
spec:
  destination:
    name: k8s-production
    namespace: reloader
  project: prod
  source:
    repoURL: "https://github.com/ton-utilisateur/repository-argocd.git"
    targetRevision: HEAD
    path: "apps/services/reloader"
    helm:
      releaseName: reloader
      valueFiles:
        - "path/to/values.yaml"
  syncPolicy:
    syncOptions:
      - CreateNamespace=true
    automated:
      prune: true
      selfHeal: true

Conclusion

Tu peux trouver l'ensemble des configurations pour Reloader dans le fichier values.yaml complet sur le dépôt GitHub du chart Helm de Stakater. Il contient toutes les options disponibles pour personnaliser ton déploiement de Reloader, depuis l'intégration avec Argo Rollouts jusqu'à la configuration des ressources et des alertes.

En utilisant ce fichier, tu peux facilement ajuster Reloader à tes besoins spécifiques en modifiant les valeurs dans ton propre fichier values.yaml et en l'intégrant dans ton déploiement ArgoCD.

D'accord ! Repartons de zéro et créons un Helm wrapper pour Reloader avec un fichier values.yaml externe, sans se baser sur la configuration que tu m'as envoyée. Je vais te donner un exemple complet, étape par étape, sans faire référence à la configuration précédente.

Objectif

Nous allons créer une application ArgoCD qui déploie Reloader (un outil permettant de recharger les déploiements Kubernetes automatiquement en fonction des changements dans les ConfigMaps et les Secrets) en utilisant Helm. Nous allons stocker les configurations personnalisées dans un fichier values.yaml séparé, référencé dans l'application ArgoCD.

1. Créer le fichier `values.yaml` pour Reloader

Le fichier values.yaml contiendra toutes les valeurs personnalisées que tu souhaites pour le déploiement de Reloader. Nous allons le stocker dans un dépôt Git séparé (ou un dossier dans ton dépôt existant).

Voici un exemple basique de fichier values.yaml pour Reloader.

Exemple de `values.yaml` pour Reloader :

# values.yaml pour Reloader

reloader:
  # Paramètres pour Reloader
  isArgoRollouts: true  # Utilisation avec Argo Rollouts
  reloadStrategy: annotations  # Stratégie de rechargement : annotations ou labels
  deployment:
    nodeSelector:
      role: 'infra'  # Cible des nœuds avec un label `role: infra`
    replicas: 2  # Nombre de réplicas de Reloader
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "500m"
        memory: "512Mi"

isArgoRollouts : Cette option permet de spécifier si Reloader doit être intégré avec Argo Rollouts pour gérer des mises à jour progressives des déploiements.
reloadStrategy : Choisis la stratégie de rechargement des déploiements. Cela peut être basé sur annotations ou labels.
deployment : Configuration des ressources pour Reloader, y compris les réplicas et les ressources demandées.

2. Créer l'Application ArgoCD

Ensuite, nous allons créer un manifeste ArgoCD Application qui va déployer Reloader en utilisant le chart Helm et référencer notre fichier values.yaml.

Exemple de manifeste ArgoCD Application :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: reloader-prod  # Nom de l'application
  namespace: argocd  # Le namespace où ArgoCD est installé
  annotations:
    argocd.argoproj.io/sync-wave: "10"  # Ordre de synchronisation des applications
spec:
  destination:
    name: k8s-production  # Le cluster cible (utilise ton contexte ici)
    namespace: reloader  # Namespace où Reloader sera déployé
  project: prod  # Projet ArgoCD (peut être "default" ou un autre projet)
  source:
    repoURL: "https://github.com/ton-utilisateur/repository-argocd.git"  # Ton dépôt Git avec les manifests
    targetRevision: HEAD  # Branche ou commit à utiliser
    path: "apps/services/reloader"  # Chemin dans ton dépôt Git vers la configuration de l'application
    helm:
      releaseName: reloader  # Nom du release Helm
      valueFiles:
        - "path/to/values.yaml"  # Chemin vers le fichier values.yaml dans ton dépôt Git
  syncPolicy:
    syncOptions:
      - CreateNamespace=true  # Créer automatiquement le namespace si non existant
    automated:
      prune: true  # Supprimer les ressources non définies
      allowEmpty: true  # Permettre les applications vides
      selfHeal: true  # ArgoCD corrigera automatiquement toute dérive de l'état

Explication des sections importantes :

destination :
name : Spécifie le cluster où le déploiement sera effectué (ici, k8s-production fait référence au contexte de cluster).
namespace : Le namespace où Reloader sera déployé (ici, reloader).
source :
repoURL : L'URL de ton dépôt Git contenant les manifests Kubernetes/Helm et le fichier values.yaml.
path : Le chemin relatif dans ton dépôt Git où se trouvent la configuration de l'application.
helm.releaseName : Le nom du release Helm (ici, reloader).
valueFiles : Le chemin vers le fichier values.yaml dans ton dépôt Git. Assure-toi que ce chemin est correct.
syncPolicy :
syncOptions : L'option CreateNamespace=true permet à ArgoCD de créer automatiquement le namespace si celui-ci n'existe pas.
automated : Permet une synchronisation automatique avec des options comme selfHeal, ce qui permet à ArgoCD de restaurer l'état désiré en cas de dérive.

3. Appliquer l'Application ArgoCD

Maintenant, tu peux appliquer ce fichier YAML dans ton cluster Kubernetes en utilisant kubectl :

kubectl apply -f reloader-argocd-app.yaml

Cela va créer l'application Reloader dans ArgoCD et commencer à déployer Reloader dans le namespace reloader en utilisant le Helm chart et les valeurs spécifiées dans le fichier values.yaml.

4. Synchroniser l'Application via ArgoCD

Une fois que l'application est créée dans ArgoCD, tu peux la synchroniser via l'interface ArgoCD UI ou en utilisant ArgoCD CLI.

Via ArgoCD CLI :

argocd app sync reloader-prod

Via ArgoCD UI :

Ouvre l'interface utilisateur d'ArgoCD.
Trouve l'application Reloader.
Clique sur Sync pour lancer la synchronisation et le déploiement.

5. Vérifier le Déploiement

Après la synchronisation, tu peux vérifier si les pods de Reloader ont été déployés correctement dans le namespace reloader.

kubectl get pods -n reloader

Tu devrais voir les pods liés à Reloader fonctionner dans ce namespace.

Conclusion

Nous avons créé un Helm wrapper pour Reloader en utilisant ArgoCD et un fichier values.yaml externe pour configurer le chart Helm de manière modulaire et flexible. Cette méthode est idéale pour une gestion GitOps propre, où toutes les configurations sont versionnées et contrôlées dans un dépôt Git.

Si tu souhaites ajouter plus de configurations ou personnaliser davantage ton déploiement, tu peux simplement modifier le fichier values.yaml dans ton dépôt Git et laisser ArgoCD gérer automatiquement les mises à jour et les synchronisations.

Bien sûr ! Si tu souhaites créer un Helm wrapper pour Reloader avec la méthode des options 2 (en utilisant un fichier values.yaml externe), voici les étapes détaillées ainsi qu'un exemple de configuration.

Objectif :

Créer un Helm wrapper pour Reloader via ArgoCD, où la configuration Helm (values.yaml) est définie dans un fichier externe stocké dans un dépôt Git. Cette méthode permet de maintenir la configuration séparée et facilement réutilisable.

Étapes :

Créer le fichier values.yaml pour Reloader.
Définir l'application ArgoCD qui fait référence au dépôt Git et à ce fichier values.yaml pour configurer l'installation de Reloader via Helm.

Étape 1 : Créer le fichier `values.yaml` pour Reloader

Dans cet exemple, nous allons stocker la configuration spécifique de Reloader dans un fichier values.yaml que tu vas référencer dans ton manifeste ArgoCD.

Exemple de fichier `values.yaml` pour Reloader :

# values.yaml pour Reloader

reloader:
  isArgoRollouts: true  # Activer l'intégration avec Argo Rollouts
  reloadStrategy: annotations  # Stratégie de rechargement par annotation
  deployment:
    nodeSelector:
      infra: 'true'  # Sélection du noeud pour le déploiement

Ce fichier values.yaml peut être stocké dans ton dépôt Git où tu gères tes configurations ArgoCD.

Étape 2 : Créer l'application ArgoCD

Nous allons créer un manifeste ArgoCD Application qui déploie Reloader à l'aide du Helm chart officiel et fait référence à notre fichier values.yaml externe.

Exemple de manifeste ArgoCD Application pour Reloader :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: reloader-prod
  namespace: argocd  # Namespace où ArgoCD est installé
  annotations:
    argocd.argoproj.io/sync-wave: "10"  # Ordre de synchronisation des applications
spec:
  destination:
    name: k8s-production  # Le cluster cible (utilise le nom de ton cluster ici)
    namespace: reloader  # Le namespace où Reloader sera déployé
  project: prod  # Projet ArgoCD auquel appartient cette application
  source:
    repoURL: "https://gitlab.com/ton/utilisateur/repository-argocd.git"  # Ton dépôt Git contenant la configuration
    targetRevision: HEAD  # Branche ou commit à utiliser
    path: "apps/services/reloader/"  # Chemin vers le fichier values.yaml dans ton dépôt
    helm:
      releaseName: reloader  # Nom du release Helm
      valueFiles:
        - "path/to/values.yaml"  # Chemin vers le fichier values.yaml dans ton dépôt Git
  syncPolicy:
    syncOptions:
      - CreateNamespace=true  # Créer automatiquement le namespace si non existant
    automated:
      prune: true  # Supprimer les ressources non définies
      allowEmpty: true  # Permettre les applications vides
      selfHeal: true  # ArgoCD corrigera automatiquement toute dérive de l'état

Explication des sections importantes :

destination :
name : Spécifie le cluster où déployer. Dans ce cas, nous utilisons k8s-production comme contexte de cluster.
namespace : Le namespace où Reloader sera déployé (reloader dans cet exemple).
source :
repoURL : L'URL du dépôt Git où se trouve la configuration de l'application ArgoCD.
path : Le chemin relatif vers l'endroit où se trouve le fichier values.yaml dans ton dépôt.
helm.releaseName : Le nom du release Helm (ici, nous l'appelons reloader).
valueFiles : Spécifie le chemin vers le fichier values.yaml dans ton dépôt Git.
syncPolicy :
syncOptions : Inclut l'option CreateNamespace=true pour créer automatiquement le namespace si nécessaire.
automated : Permet une synchronisation automatique, et inclut des options comme selfHeal pour maintenir la conformité avec l'état désiré.

Étape 3 : Appliquer l'Application ArgoCD

Une fois ton fichier YAML prêt, tu peux l'appliquer à ton cluster Kubernetes via kubectl :

kubectl apply -f reloader-argocd-app.yaml

Cela créera l'application ArgoCD pour Reloader et ArgoCD se chargera de la gestion du déploiement de la Helm chart de Reloader avec la configuration définie dans ton fichier values.yaml.

Étape 4 : Synchroniser l'Application via ArgoCD

Tu peux ensuite synchroniser l'application depuis l'interface ArgoCD UI ou en utilisant ArgoCD CLI.

Via ArgoCD CLI :

argocd app sync reloader-prod

Via ArgoCD UI :

Ouvre l'interface utilisateur d'ArgoCD.
Trouve l'application Reloader.
Clique sur Sync pour lancer la synchronisation et le déploiement.

Étape 5 : Vérifier le Déploiement

Après que la synchronisation soit terminée, tu peux vérifier si Reloader a bien été déployé dans le namespace reloader :

kubectl get pods -n reloader

Conclusion

Tu as maintenant un Helm wrapper pour Reloader déployé via ArgoCD, où la configuration (values.yaml) est stockée dans un fichier externe. Cela permet de maintenir une approche GitOps où toutes les configurations sont versionnées et gérées via Git, tout en déployant de manière automatisée avec ArgoCD.

Ah, great point! I see you’re asking about the values.yaml file, which is essential for customizing your Helm chart deployments (like Prometheus) when using Helm through ArgoCD.

Where is the `values.yaml` File?

The values.yaml file is where you can override default Helm chart settings. When you use Helm in ArgoCD, you can either:

Define the values inline in the ArgoCD application YAML (as I did in the example above, under the helm.values section).
Reference a separate values.yaml file stored in your Git repository, and ArgoCD can pull that file for Helm customizations.

Let me show you both approaches more clearly:

Option 1: Inline `values.yaml` in the ArgoCD Application YAML

In this approach, you directly define Helm chart custom values inline within the ArgoCD Application YAML (as part of the helm.values section). This can be convenient for small customizations, but it can become messy for larger configurations.

Here’s how you’d define the custom values directly in your Application manifest:

Example: Inline `values.yaml` in the `Application` YAML

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: prometheus-prod
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "10"  # Optional: Sync wave priority
spec:
  destination:
    name: k8s-production  # The destination cluster (use your cluster's name here)
    namespace: monitoring  # Namespace where Prometheus will be deployed
  project: prod  # ArgoCD project
  source:
    repoURL: "https://gitlab.com/Evina2/infrastructure/argocd-production.git"  # Your Git repo for ArgoCD configurations
    targetRevision: HEAD  # Branch or commit
    path: "apps/services/prometheus/"  # Path to the Helm chart in your Git repo
    helm:
      releaseName: prometheus  # Helm release name
      values: |
        # Custom Helm values defined directly here
        alertmanager:
          enabled: true
        grafana:
          enabled: true
        prometheus:
          prometheusSpec:
            replicas: 2
            resources:
              requests:
                memory: 2Gi
                cpu: 500m
              limits:
                memory: 4Gi
                cpu: 1
        nodeExporter:
          enabled: true
        kubeStateMetrics:
          enabled: true
  syncPolicy:
    syncOptions:
      - CreateNamespace=true  # Automatically create the namespace if it doesn't exist
    automated:
      prune: true  # Automatically delete resources that are no longer part of the app definition
      allowEmpty: true  # Allow empty apps
      selfHeal: true  # Enable self-healing to fix drifted resources

In this example, I included the values section inside the ArgoCD application manifest. The custom settings for Prometheus, Alertmanager, Grafana, and nodeExporter are defined directly in the values field in YAML format.

Option 2: Use an External `values.yaml` File

This approach involves defining your custom values in a separate values.yaml file stored in your Git repository. This keeps your configurations more modular and easier to manage, especially for larger configurations.

Store the values.yaml file in your Git repository (alongside your ArgoCD manifests).
Reference this values.yaml in the ArgoCD Application so that ArgoCD can use it during the Helm chart installation.

Example: `values.yaml` File for Prometheus

Here’s an example of what the values.yaml file might look like if you store it in your Git repository:

# values.yaml for Prometheus deployment
alertmanager:
  enabled: true

grafana:
  enabled: true

prometheus:
  prometheusSpec:
    replicas: 2
    resources:
      requests:
        memory: 2Gi
        cpu: 500m
      limits:
        memory: 4Gi
        cpu: 1

nodeExporter:
  enabled: true

kubeStateMetrics:
  enabled: true

Example: ArgoCD Application YAML with `values.yaml` Reference

Once you have the values.yaml file in your Git repository, you’ll reference it from the ArgoCD Application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: prometheus-prod
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "10"  # Optional: Sync wave priority
spec:
  destination:
    name: k8s-production  # The destination cluster (use your cluster's name here)
    namespace: monitoring  # Namespace where Prometheus will be deployed
  project: prod  # ArgoCD project
  source:
    repoURL: "https://gitlab.com/Evina2/infrastructure/argocd-production.git"  # Your Git repo for ArgoCD configurations
    targetRevision: HEAD  # Branch or commit
    path: "apps/services/prometheus/"  # Path to the Helm chart in your Git repo
    helm:
      releaseName: prometheus  # Helm release name
      valueFiles:
        - "path/to/your/values.yaml"  # Path to the external values.yaml file in your Git repo
  syncPolicy:
    syncOptions:
      - CreateNamespace=true  # Automatically create the namespace if it doesn't exist
    automated:
      prune: true  # Automatically delete resources that are no longer part of the app definition
      allowEmpty: true  # Allow empty apps
      selfHeal: true  # Enable self-healing to fix drifted resources

Key Differences Between Inline and External `values.yaml`:

Inline values.yaml:
Quick and easy for smaller configurations.
Everything is in one place (inside the Application YAML).
Can become unwieldy for large configurations.
External values.yaml:
Better for larger, more complex configurations.
Keeps values.yaml separate, making it easier to manage, modify, and version-control separately from the ArgoCD application itself.
More modular: you can reuse the same values.yaml file for multiple applications or environments.

Step 4: Apply the ArgoCD Application

Once your values.yaml is defined (either inline or externally), you’ll apply the ArgoCD Application YAML to your Kubernetes cluster.

kubectl apply -f prometheus-argocd-app.yaml

ArgoCD will pick up the application and deploy Prometheus based on the values you’ve specified.

Step 5: Sync the Application

You can sync the application manually from the ArgoCD CLI or UI.

Sync via ArgoCD CLI:

argocd app sync prometheus-prod

Sync via ArgoCD UI:

Navigate to the ArgoCD UI.
Find your Prometheus application.
Click Sync to deploy the chart with the provided values.

Step 6: Monitor the Deployment

After syncing, check if Prometheus has been deployed successfully in the monitoring namespace:

kubectl get pods -n monitoring

You should see Prometheus and associated components like Grafana and Alertmanager running.

Conclusion

You can manage Prometheus deployment through ArgoCD using either an inline values.yaml or by referencing an external values.yaml file stored in your Git repository. Both approaches work well, and you can choose based on the complexity and size of your configuration.

For larger or more complex configurations, I recommend using an external values.yaml file, as it keeps your deployments modular, clean, and more maintainable in a GitOps workflow.

It looks like you're asking about creating a Helm wrapper within ArgoCD, similar to the example you’ve provided, but tailored for Prometheus. The structure you've shown is for deploying a Helm chart (Reloader in this case) using an ArgoCD application and defining its configurations.

Let me break down the steps and provide an example of how you would adapt this for Prometheus while also using a Helm wrapper inside ArgoCD. I will guide you through creating an ArgoCD Application that installs Prometheus using the Helm chart, similar to your provided structure.

Step 1: Define the Helm Chart for Prometheus

Since Prometheus uses a Helm chart (kube-prometheus-stack from the prometheus-community repository), we will define the Helm chart in the dependencies section of the Chart.yaml file, and then use ArgoCD's Application definition to deploy it.

We'll wrap the Prometheus Helm chart in a custom chart or use a directly referenced Helm chart within ArgoCD.

Step 2: Create a Custom Helm Chart for Prometheus (Optional)

If you'd like to bundle Prometheus as a Helm dependency (similar to your example with reloader), you can create a custom Helm chart that references the Prometheus Helm chart as a dependency.

Here's an example of a custom Helm chart definition for Prometheus (similar to your Reloader example):

Chart.yaml (Custom Helm Chart for Prometheus)

apiVersion: v2
name: prometheus
description: A Helm chart for Prometheus and related components
type: application
version: v0.0.1
appVersion: 2.14.0

dependencies:
  - name: kube-prometheus-stack
    version: "41.0.0"   # Change to the desired version
    repository: "https://prometheus-community.github.io/helm-charts"

prometheus:
  prometheusSpec:
    replicas: 2
    resources:
      requests:
        memory: "2Gi"
        cpu: "500m"
      limits:
        memory: "4Gi"
        cpu: "1"
    nodeSelector:
      infra: 'true'
  grafana:
    enabled: true
  alertmanager:
    enabled: true

In this Chart.yaml, we've defined a custom chart that points to the Prometheus Helm chart (kube-prometheus-stack) as a dependency.

dependencies: Specifies that this chart depends on the kube-prometheus-stack from the Prometheus community repository.
prometheusSpec: Includes custom values like setting the number of replicas, resource requests/limits, and enabling/disabling components.

Step 3: ArgoCD Application Manifest for Prometheus

Now, we'll create an ArgoCD Application that references this custom chart or directly uses the Prometheus chart. Below is an example Application YAML that uses ArgoCD to deploy Prometheus.

prometheus-argocd-app.yaml (ArgoCD Application)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: prometheus-prod
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "10"  # Optional: Define sync wave priority
spec:
  destination:
    name: k8s-production  # The destination cluster (use your cluster's name here)
    namespace: monitoring  # Namespace where Prometheus will be deployed
  project: prod  # Your ArgoCD project
  source:
    repoURL: "https://gitlab.com/Evina2/infrastructure/argocd-production.git"  # Your Git repo for ArgoCD configurations
    targetRevision: HEAD  # Branch or commit
    path: "apps/services/prometheus/"  # Path to the Helm chart in your Git repo
  syncPolicy:
    syncOptions:
      - CreateNamespace=true  # Automatically create the namespace if it doesn't exist
    automated:
      prune: true  # Automatically delete resources that are no longer defined
      allowEmpty: true  # Allow empty apps
      selfHeal: true  # Enable self-healing to fix drifted resources

Key Sections in this YAML:

destination: Specifies the Kubernetes cluster and namespace where Prometheus will be installed (k8s-production is a cluster context, and monitoring is the namespace).
repoURL: The URL of the Git repository where your ArgoCD manifests (including the Prometheus Helm chart) are stored.
path: Path inside the Git repo where the application YAML and Helm chart are located.
syncPolicy: Defines how ArgoCD will handle the synchronization of the application. Here, we specify that ArgoCD should automatically create the namespace and prune resources when they're no longer part of the app definition.

Step 4: Apply the ArgoCD Application

Once your application YAML is defined, apply it to your Kubernetes cluster using kubectl:

kubectl apply -f prometheus-argocd-app.yaml

This will tell ArgoCD to manage the Prometheus deployment. ArgoCD will automatically sync the Helm chart and deploy Prometheus in the monitoring namespace.

Step 5: Monitor and Sync the Application

After the application is created, you can monitor its status and sync it using ArgoCD UI or ArgoCD CLI.

Sync via ArgoCD CLI:

argocd app sync prometheus-prod

Sync via ArgoCD UI:

Open the ArgoCD UI.
Find the Prometheus application.
Click Sync to initiate the deployment.

Step 6: Verify Prometheus Deployment

Once the sync completes, check if the Prometheus pods are running successfully:

kubectl get pods -n monitoring

You should see Prometheus, Grafana, Alertmanager, and any other components specified in your chart running as Kubernetes pods.

Step 7: Access Prometheus and Grafana

You can access Prometheus and Grafana using port forwarding:

Access Prometheus:

kubectl port-forward svc/prometheus-kube-prometheus-prometheus 9090:9090 -n monitoring

Prometheus will be available at http://localhost:9090.

Access Grafana:

kubectl port-forward svc/prometheus-grafana 3000:80 -n monitoring

Grafana will be available at http://localhost:3000 with the default login credentials (username: admin, password: prom-operator or whatever you defined in the values.yaml).

Conclusion

By following these steps, you've created a Helm wrapper for Prometheus using ArgoCD. This setup ensures that your Prometheus deployment is fully GitOps-compliant, enabling easy version control, automation, and monitoring. You can manage Prometheus, Grafana, and Alertmanager deployments just like any other Kubernetes resource, while benefiting from ArgoCD's self-healing, synchronization, and drift prevention features.

11 décembre 2025
dans Argo CD, Prometheus
19 min de lecture

Brouillon

Installer argocd-extension-metrics

Introduction

Ce tutoriel complet vous guide pas à pas pour installer Argo CD et intégrer les métriques Prometheus dans l’interface Argo CD en utilisant une approche GitOps.

3 décembre 2025
dans Argo CD
3 min de lecture

Brouillon

ArgoCD - Installation d'Argo CD

3 décembre 2025
dans Argo CD
4 min de lecture

Comment Argo CD vérifie-t-il les changements dans mon dépôt Git ou Helm

Introduction

Par défaut, ArgoCD vérifie les changements dans le dépôt Git ou Helm toutes les 3 minutes (120 secondes + 60 secondes de jitter).

Vous pouvez ajuster cette fréquence en modifiant les paramètres timeout.reconciliation et timeout.reconciliation.jitter dans la configMap argocd-cm. Si des changements sont détectés dans le dépôt Git, Argo CD mettra à jour uniquement les applications pour lesquelles la synchronisation automatique (auto-sync) est activée.

3 décembre 2025
dans Argo CD
2 min de lecture

Brouillon

Pull vs Push

2 décembre 2025
dans Argo CD
1 min de lecture

Brouillon