argocd Config Management Plugins a Config Management Plugin CMP Argo CD s native config management tools are Helm Jsonnet and Kustomize If you want to use a different config task of building manifests to the plugin Helm OCI or git repository When a config management plugin is correctly configured the repo server may delegate the management tools or if Argo CD s native tool support does not include a feature you need you might need to turn to The Argo CD repo server component is in charge of building Kubernetes manifests based on some source files from a

Answer:
# Config Management Plugins

Argo CD's "native" config management tools are Helm, Jsonnet, and Kustomize. If you want to use a different config
management tools, or if Argo CD's native tool support does not include a feature you need, you might need to turn to
a Config Management Plugin (CMP).

The Argo CD "repo server" component is in charge of building Kubernetes manifests based on some source files from a
Helm, OCI, or git repository. When a config management plugin is correctly configured, the repo server may delegate the
task of building manifests to the plugin.

The following sections will describe how to create, install, and use plugins. Check out the
[example plugins](https://github.com/argoproj/argo-cd/tree/master/examples/plugins) for additional guidance.

!!! warning
    Plugins are granted a level of trust in the Argo CD system, so it is important to implement plugins securely. Argo
    CD administrators should only install plugins from trusted sources, and they should audit plugins to weigh their
    particular risks and benefits.

## Installing a config management plugin

### Sidecar plugin

An operator can configure a plugin tool via a sidecar to repo-server. The following changes are required to configure a new plugin:

#### Write the plugin configuration file

Plugins will be configured via a ConfigManagementPlugin manifest located inside the plugin container.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ConfigManagementPlugin
metadata:
  # The name of the plugin must be unique within a given Argo CD instance.
  name: my-plugin
spec:
  # The version of your plugin. Optional. If specified, the Application's spec.source.plugin.name field
  # must be <plugin name>-<plugin version>.
  version: v1.0
  # The init command runs in the Application source directory at the beginning of each manifest generation. The init
  # command can output anything. A non-zero status code will fail manifest generation.
  init:
    # Init always happens immediately before generate, but its output is not treated as manifests.
    # This is a good place to, for example, download chart dependencies.
    command: [sh]
    args: [-c, 'echo "Initializing..."']
  # The generate command runs in the Application source directory each time manifests are generated. Standard output
  # must be ONLY valid Kubernetes Objects in either YAML or JSON. A non-zero exit code will fail manifest generation.
  # To write log messages from the command, write them to stderr, it will always be displayed.
  # Error output will be sent to the UI, so avoid printing sensitive information (such as secrets).
  generate:
    command: [sh, -c]
    args:
      - |
        echo "{\"kind\": \"ConfigMap\", \"apiVersion\": \"v1\", \"metadata\": { \"name\": \"$ARGOCD_APP_NAME\", \"namespace\": \"$ARGOCD_APP_NAMESPACE\", \"annotations\": {\"Foo\": \"$ARGOCD_ENV_FOO\", \"KubeVersion\": \"$KUBE_VERSION\", \"KubeApiVersion\": \"$KUBE_API_VERSIONS\",\"Bar\": \"baz\"}}}"
  # The discovery config is applied to a repository. If every configured discovery tool matches, then the plugin may be
  # used to generate manifests for Applications using the repository. If the discovery config is omitted then the plugin
  # will not match any application but can still be invoked explicitly by specifying the plugin name in the app spec.
  # Only one of fileName, find.glob, or find.command should be specified. If multiple are specified then only the
  # first (in that order) is evaluated.
  discover:
    # fileName is a glob pattern (https://pkg.go.dev/path/filepath#Glob) that is applied to the Application's source
    # directory. If there is a match, this plugin may be used for the Application.
    fileName: "./subdir/s*.yaml"
    find:
      # This does the same thing as fileName, but it supports double-start (nested directory) glob patterns.
      glob: "**/Chart.yaml"
      # The find command runs in the repository's root directory. To match, it must exit with status code 0 _and_
      # produce non-empty output to standard out.
      command: [sh, -c, find . -name env.yaml]
  # The parameters config describes what parameters the UI should display for an Application. It is up to the user to
  # actually set parameters in the Application manifest (in spec.source.plugin.parameters). The announcements _only_
  # inform the "Parameters" tab in the App Details page of the UI.
  parameters:
    # Static parameter announcements are sent to the UI for _all_ Applications handled by this plugin.
    # Think of the `string`, `array`, and `map` values set here as "defaults". It is up to the plugin author to make
    # sure that these default values actually reflect the plugin's behavior if the user doesn't explicitly set different
    # values for those parameters.
    static:
      - name: string-param
        title: Description of the string param
        tooltip: Tooltip shown when the user hovers the
        # If this field is set, the UI will indicate to the user that they must set the value.
        required: false
        # itemType tells the UI how to present the parameter's value (or, for arrays and maps, values). Default is
        # "string". Examples of other types which may be supported in the future are "boolean" or "number".
        # Even if the itemType is not "string", the parameter value from the Application spec will be sent to the plugin
        # as a string. It's up to the plugin to do the appropriate conversion.
        itemType: ""
        # collectionType describes what type of value this parameter accepts (string, array, or map) and allows the UI
        # to present a form to match that type. Default is "string". This field must be present for non-string types.
        # It will not be inferred from the presence of an `array` or `map` field.
        collectionType: ""
        # This field communicates the parameter's default value to the UI. Setting this field is optional.
        string: default-string-value
      # All the fields above besides "string" apply to both the array and map type parameter announcements.
      - name: array-param
        # This field communicates the parameter's default value to the UI. Setting this field is optional.
        array: [default, items]
        collectionType: array
      - name: map-param
        # This field communicates the parameter's default value to the UI. Setting this field is optional.
        map:
          some: value
        collectionType: map
    # Dynamic parameter announcements are announcements specific to an Application handled by this plugin. For example,
    # the values for a Helm chart's values.yaml file could be sent as parameter announcements.
    dynamic:
      # The command is run in an Application's source directory. Standard output must be JSON matching the schema of the
      # static parameter announcements list.
      command: [echo, '[{"name": "example-param", "string": "default-string-value"}]']

  # If set to `true` then the plugin receives repository files with original file mode. Dangerous since the repository
  # might have executable files. Set to true only if you trust the CMP plugin authors.
  preserveFileMode: false

  # If set to `true` then the plugin can retrieve git credentials from the reposerver during generate. Plugin authors
  # should ensure these credentials are appropriately protected during execution
  provideGitCreds: false
```

!!! note
    While the ConfigManagementPlugin _looks like_ a Kubernetes object, it is not actually a custom resource.
    It only follows kubernetes-style spec conventions.

The `generate` command must print a valid Kubernetes YAML or JSON object stream to stdout. Both `init` and `generate` commands are executed inside the application source directory.

The `discover.fileName` is used as [glob](https://pkg.go.dev/path/filepath#Glob) pattern to determine whether an
application repository is supported by the plugin or not.

```yaml
  discover:
    find:
      command: [sh, -c, find . -name env.yaml]
```

If `discover.fileName` is not provided, the `discover.find.command` is executed in order to determine whether an
application repository is supported by the plugin or not. The `find` command should return a non-error exit code
and produce output to stdout when the application source type is supported.

#### Place the plugin configuration file in the sidecar

Argo CD expects the plugin configuration file to be located at `/home/argocd/cmp-server/config/plugin.yaml` in the sidecar.

If you use a custom image for the sidecar, you can add the file directly to that image.

```dockerfile
WORKDIR /home/argocd/cmp-server/config/
COPY plugin.yaml ./
```

If you use a stock image for the sidecar or would rather maintain the plugin configuration in a ConfigMap, just nest the
plugin config file in a ConfigMap under the `plugin.yaml` key and mount the ConfigMap in the sidecar (see next section).

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-plugin-config
data:
  plugin.yaml: |
    apiVersion: argoproj.io/v1alpha1
    kind: ConfigManagementPlugin
    metadata:
      name: my-plugin
    spec:
      version: v1.0
      init:
        command: [sh, -c, 'echo "Initializing..."']
      generate:
        command: [sh, -c, 'echo "{\"kind\": \"ConfigMap\", \"apiVersion\": \"v1\", \"metadata\": { \"name\": \"$ARGOCD_APP_NAME\", \"namespace\": \"$ARGOCD_APP_NAMESPACE\", \"annotations\": {\"Foo\": \"$ARGOCD_ENV_FOO\", \"KubeVersion\": \"$KUBE_VERSION\", \"KubeApiVersion\": \"$KUBE_API_VERSIONS\",\"Bar\": \"baz\"}}}"']
      discover:
        fileName: "./subdir/s*.yaml"
```

#### Register the plugin sidecar

To install a plugin, patch argocd-repo-server to run the plugin container as a sidecar, with argocd-cmp-server as its
entrypoint. You can use either off-the-shelf or custom-built plugin image as sidecar image. For example:

```yaml
containers:
- name: my-plugin
  command: [/var/run/argocd/argocd-cmp-server] # Entrypoint should be Argo CD lightweight CMP server i.e. argocd-cmp-server
  image: ubuntu # This can be off-the-shelf or custom-built image
  securityContext:
    runAsNonRoot: true
    runAsUser: 999
  volumeMounts:
    - mountPath: /var/run/argocd
      name: var-files
    - mountPath: /home/argocd/cmp-server/plugins
      name: plugins
    # Remove this volumeMount if you've chosen to bake the config file into the sidecar image.
    - mountPath: /home/argocd/cmp-server/config/plugin.yaml
      subPath: plugin.yaml
      name: my-plugin-config
    # Starting with v2.4, do NOT mount the same tmp volume as the repo-server container. The filesystem separation helps
    # mitigate path traversal attacks.
    - mountPath: /tmp
      name: cmp-tmp
volumes:
- configMap:
    name: my-plugin-config
  name: my-plugin-config
- emptyDir: {}
  name: cmp-tmp
```

!!! important "Double-check these items"
    1. Make sure to use `/var/run/argocd/argocd-cmp-server` as an entrypoint. The `argocd-cmp-server` is a lightweight GRPC service that allows Argo CD to interact with the plugin.
    2. Make sure that sidecar container is running as user 999.
    3. Make sure that plugin configuration file is present at `/home/argocd/cmp-server/config/plugin.yaml`. It can either be volume mapped via configmap or baked into image.

### Using environment variables in your plugin

Plugin commands have access to

1. The system environment variables of the sidecar
2. [Standard build environment variables](../user-guide/build-environment.md)
3. Variables in the Application spec (References to system and build variables will get interpolated in the variables' values):

        apiVersion: argoproj.io/v1alpha1
        kind: Application
        spec:
          source:
            plugin:
              env:
                - name: FOO
                  value: bar
                - name: REV
                  value: test-$ARGOCD_APP_REVISION

    Before reaching the `init.command`, `generate.command`, and `discover.find.command` commands, Argo CD prefixes all
    user-supplied environment variables (#3 above) with `ARGOCD_ENV_`. This prevents users from directly setting
    potentially-sensitive environment variables.

4. Parameters in the Application spec:

        apiVersion: argoproj.io/v1alpha1
        kind: Application
        spec:
         source:
           plugin:
             parameters:
               - name: values-files
                 array: [values-dev.yaml]
               - name: helm-parameters
                 map:
                   image.tag: v1.2.3

    The parameters are available as JSON in the `ARGOCD_APP_PARAMETERS` environment variable. The example above would
    produce this JSON:

        [{"name": "values-files", "array": ["values-dev.yaml"]}, {"name": "helm-parameters", "map": {"image.tag": "v1.2.3"}}]

    !!! note
        Parameter announcements, even if they specify defaults, are _not_ sent to the plugin in `ARGOCD_APP_PARAMETERS`.
        Only parameters explicitly set in the Application spec are sent to the plugin. It is up to the plugin to apply
        the same defaults as the ones announced to the UI.

    The same parameters are also available as individual environment variables. The names of the environment variables
    follows this convention:

           - name: some-string-param
             string: some-string-value
           # PARAM_SOME_STRING_PARAM=some-string-value

           - name: some-array-param
             value: [item1, item2]
           # PARAM_SOME_ARRAY_PARAM_0=item1
           # PARAM_SOME_ARRAY_PARAM_1=item2

           - name: some-map-param
             map:
               image.tag: v1.2.3
           # PARAM_SOME_MAP_PARAM_IMAGE_TAG=v1.2.3

!!! warning "Sanitize/escape user input"
    As part of Argo CD's manifest generation system, config management plugins are treated with a level of trust. Be
    sure to escape user input in your plugin to prevent malicious input from causing unwanted behavior.

## Using a config management plugin with an Application

You may leave the `name` field
empty in the `plugin` section for the plugin to be automatically matched with the Application based on its discovery rules. If you do mention the name make sure
it is either `<metadata.name>-<spec.version>` if version is mentioned in the `ConfigManagementPlugin` spec or else just `<metadata.name>`. When name is explicitly
specified only that particular plugin will be used iff its discovery pattern/command matches the provided application repo.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
    plugin:
      env:
        - name: FOO
          value: bar
```

If you don't need to set any environment variables, you can set an empty plugin section.

```yaml
    plugin: {}
```

!!! important
    If your CMP command runs too long, the command will be killed, and the UI will show an error. The CMP server
    respects the timeouts set by the `server.repo.server.timeout.seconds` and `controller.repo.server.timeout.seconds`
    items in `argocd-cm`. Increase their values from the default of 60s.

    Each CMP command will also independently timeout on the `ARGOCD_EXEC_TIMEOUT` set for the CMP sidecar. The default
    is 90s. So if you increase the repo server timeout greater than 90s, be sure to set `ARGOCD_EXEC_TIMEOUT` on the
    sidecar.

!!! note
    Each Application can only have one config management plugin configured at a time. If you're converting an existing
    plugin configured through the `argocd-cm` ConfigMap to a sidecar, make sure to update the plugin name to either `<metadata.name>-<spec.version>`
    if version was mentioned in the `ConfigManagementPlugin` spec or else just use `<metadata.name>`. You can also remove the name altogether
    and let the automatic discovery to identify the plugin.
!!! note
    If a CMP renders blank manfiests, and `prune` is set to `true`, Argo CD will automatically remove resources. CMP plugin authors should ensure errors are part of the exit code. Commonly something like `kustomize build . | cat` won't pass errors because of the pipe. Consider setting `set -o pipefail` so anything piped will pass errors on failure.

## Debugging a CMP

If you are actively developing a sidecar-installed CMP, keep a few things in mind:

1. If you are mounting plugin.yaml from a ConfigMap, you will have to restart the repo-server Pod so the plugin will
   pick up the changes.
2. If you have baked plugin.yaml into your image, you will have to build, push, and force a re-pull of that image on the
   repo-server Pod so the plugin will pick up the changes. If you are using `:latest`, the Pod will always pull the new
   image. If you're using a different, static tag, set `imagePullPolicy: Always` on the CMP's sidecar container.
3. CMP errors are cached by the repo-server in Redis. Restarting the repo-server Pod will not clear the cache. Always
   do a "Hard Refresh" when actively developing a CMP so you have the latest output.
4. Verify your sidecar has started properly by viewing the Pod and seeing that two containers are running `kubectl get pod -l app.kubernetes.io/component=repo-server -n argocd`
5. Write log message to stderr and set the `--loglevel=info` flag in the sidecar. This will print everything written to stderr, even on successfull command execution.

### Other Common Errors
| Error Message | Cause |
| -- | -- |
| `no matches for kind "ConfigManagementPlugin" in version "argoproj.io/v1alpha1"` | The `ConfigManagementPlugin` CRD was deprecated in Argo CD 2.4 and removed in 2.8. This error means you've tried to put the configuration for your plugin directly into Kubernetes as a CRD. Refer to this [section of documentation](#write-the-plugin-configuration-file) for how to write the plugin configuration file and place it properly in the sidecar. |

## Plugin tar stream exclusions

In order to increase the speed of manifest generation, certain files and folders can be excluded from being sent to your
plugin. We recommend excluding your `.git` folder if it isn't necessary. Use Go's
[filepatch.Match](https://pkg.go.dev/path/filepath#Match) syntax. For example, `.git/*` to exclude `.git` folder.

You can set it one of three ways:

1. The `--plugin-tar-exclude` argument on the repo server.
2. The `reposerver.plugin.tar.exclusions` key if you are using `argocd-cmd-params-cm`
3. Directly setting `ARGOCD_REPO_SERVER_PLUGIN_TAR_EXCLUSIONS` environment variable on the repo server.

For option 1, the flag can be repeated multiple times. For option 2 and 3, you can specify multiple globs by separating
them with semicolons.

## Application manifests generation using argocd.argoproj.io/manifest-generate-paths

To enhance the application manifests generation process, you can enable the use of the `argocd.argoproj.io/manifest-generate-paths` annotation. When this flag is enabled, the resources specified by this annotation will be passed to the CMP server for generating application manifests, rather than sending the entire repository. This can be particularly useful for monorepos.

You can set it one of three ways:

1. The `--plugin-use-manifest-generate-paths` argument on the repo server.
2. The `reposerver.plugin.use.manifest.generate.paths` key if you are using `argocd-cmd-params-cm`
3. Directly setting `ARGOCD_REPO_SERVER_PLUGIN_USE_MANIFEST_GENERATE_PATHS` environment variable on the repo server to `true`.

## Migrating from argocd-cm plugins

Installing plugins by modifying the argocd-cm ConfigMap is deprecated as of v2.4 and has been completely removed starting in v2.8.

CMP plugins work by adding a sidecar to `argocd-repo-server` along with a configuration in that sidecar located at `/home/argocd/cmp-server/config/plugin.yaml`. A argocd-cm plugin can be easily converted with the following steps.

### Convert the ConfigMap entry into a config file

First, copy the plugin's configuration into its own YAML file. Take for example the following ConfigMap entry:

```yaml
data:
  configManagementPlugins: |
    - name: pluginName
      init:                          # Optional command to initialize application source directory
        command: ["sample command"]
        args: ["sample args"]
      generate:                      # Command to generate Kubernetes Objects in either YAML or JSON
        command: ["sample command"]
        args: ["sample args"]
      lockRepo: true                 # Defaults to false. See below.
```

The `pluginName` item would be converted to a config file like this:

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ConfigManagementPlugin
metadata:
  name: pluginName
spec:
  init:                          # Optional command to initialize application source directory
    command: ["sample command"]
    args: ["sample args"]
  generate:                      # Command to generate Kubernetes Objects in either YAML or JSON
    command: ["sample command"]
    args: ["sample args"]
```

!!! note
    The `lockRepo` key is not relevant for sidecar plugins, because sidecar plugins do not share a single source repo
    directory when generating manifests.

Next, we need to decide how this yaml is going to be added to the sidecar. We can either bake the yaml directly into the image, or we can mount it from a ConfigMap.

If using a ConfigMap, our example would look like this:

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: pluginName
  namespace: argocd
data:
  pluginName.yaml: |
    apiVersion: argoproj.io/v1alpha1
    kind: ConfigManagementPlugin
    metadata:
      name: pluginName
    spec:
      init:                          # Optional command to initialize application source directory
        command: ["sample command"]
        args: ["sample args"]
      generate:                      # Command to generate Kubernetes Objects in either YAML or JSON
        command: ["sample command"]
        args: ["sample args"]
```

Then this would be mounted in our plugin sidecar.

### Write discovery rules for your plugin

Sidecar plugins can use either discovery rules or a plugin name to match Applications to plugins. If the discovery rule is omitted
then you have to explicitly specify the plugin by name in the app spec or else that particular plugin will not match any app.

If you want to use discovery instead of the plugin name to match applications to your plugin, write rules applicable to
your plugin [using the instructions above](#1-write-the-plugin-configuration-file) and add them to your configuration
file.

To use the name instead of discovery, update the name in your application manifest to `<metadata.name>-<spec.version>`
if version was mentioned in the `ConfigManagementPlugin` spec or else just use `<metadata.name>`. For example:

```yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
spec:
  source:
    plugin:
      name: pluginName  # Delete this for auto-discovery (and set `plugin: {}` if `name` was the only value) or use proper sidecar plugin name
```

### Make sure the plugin has access to the tools it needs

Plugins configured with argocd-cm ran on the Argo CD image. This gave it access to all the tools installed on that
image by default (see the [Dockerfile](https://github.com/argoproj/argo-cd/blob/master/Dockerfile) for base image and
installed tools).

You can either use a stock image (like ubuntu, busybox, or alpine/k8s) or design your own base image with the tools your plugin needs. For
security, avoid using images with more binaries installed than what your plugin actually needs.

### Test the plugin

After installing the plugin as a sidecar [according to the directions above](#installing-a-config-management-plugin),
test it out on a few Applications before migrating all of them to the sidecar plugin.

Once tests have checked out, remove the plugin entry from your argocd-cm ConfigMap.

### Additional Settings

#### Preserve repository files mode

By default, config management plugin receives source repository files with reset file mode. This is done for security
reasons. If you want to preserve original file mode, you can set `preserveFileMode` to `true` in the plugin spec:

!!! warning
    Make sure you trust the plugin you are using. If you set `preserveFileMode` to `true` then the plugin might receive
    files with executable permissions which can be a security risk.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ConfigManagementPlugin
metadata:
  name: pluginName
spec:
  init:
    command: ["sample command"]
    args: ["sample args"]
  generate:
    command: ["sample command"]
    args: ["sample args"]
  preserveFileMode: true
```

##### Provide Git Credentials

By default, the config management plugin is responsible for providing its own credentials to additional Git repositories
that may need to be accessed during manifest generation. The reposerver has these credentials available in its git creds
store. When credential sharing is allowed, the git credentials used by the reposerver to clone the repository contents
are shared for the lifetime of the execution of the config management plugin, utilizing git's `ASKPASS` method to make a
call from the config management sidecar container to the reposerver to retrieve the initialized git credentials.

Utilizing `ASKPASS` means that credentials are not proactively shared, but rather only provided when an operation requires
them.

To allow the plugin to access the reposerver git credentials, you can set `provideGitCreds` to `true` in the plugin spec:

!!! warning
    Make sure you trust the plugin you are using. If you set `provideGitCreds` to `true` then the plugin will receive
    credentials used to clone the source Git repository.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ConfigManagementPlugin
metadata:
  name: pluginName
spec:
  init:
    command: ["sample command"]
    args: ["sample args"]
  generate:
    command: ["sample command"]
    args: ["sample args"]
  provideGitCreds: true
```

Config Management Plugins  Argo CD s  native  config management tools are Helm  Jsonnet  and Kustomize  If you want to use a different config management tools  or if Argo CD s native tool support does not include a feature you need  you might need to turn to a Config Management Plugin  CMP    The Argo CD  repo server  component is in charge of building Kubernetes manifests based on some source files from a Helm  OCI  or git repository  When a config management plugin is correctly configured  the repo server may delegate the task of building manifests to the plugin   The following sections will describe how to create  install  and use plugins  Check out the  example plugins  https   github com argoproj argo cd tree master examples plugins  for additional guidance       warning     Plugins are granted a level of trust in the Argo CD system  so it is important to implement plugins securely  Argo     CD administrators should only install plugins from trusted sources  and they should audit plugins to weigh their     particular risks and benefits      Installing a config management plugin      Sidecar plugin  An operator can configure a plugin tool via a sidecar to repo server  The following changes are required to configure a new plugin        Write the plugin configuration file  Plugins will be configured via a ConfigManagementPlugin manifest located inside the plugin container      yaml apiVersion  argoproj io v1alpha1 kind  ConfigManagementPlugin metadata      The name of the plugin must be unique within a given Argo CD instance    name  my plugin spec      The version of your plugin  Optional  If specified  the Application s spec source plugin name field     must be  plugin name   plugin version     version  v1 0     The init command runs in the Application source directory at the beginning of each manifest generation  The init     command can output anything  A non zero status code will fail manifest generation    init        Init always happens immediately before generate  but its output is not treated as manifests        This is a good place to  for example  download chart dependencies      command   sh      args    c   echo  Initializing           The generate command runs in the Application source directory each time manifests are generated  Standard output     must be ONLY valid Kubernetes Objects in either YAML or JSON  A non zero exit code will fail manifest generation      To write log messages from the command  write them to stderr  it will always be displayed      Error output will be sent to the UI  so avoid printing sensitive information  such as secrets     generate      command   sh   c      args                    echo     kind      ConfigMap      apiVersion      v1      metadata        name       ARGOCD APP NAME      namespace       ARGOCD APP NAMESPACE      annotations       Foo       ARGOCD ENV FOO      KubeVersion       KUBE VERSION      KubeApiVersion       KUBE API VERSIONS     Bar      baz           The discovery config is applied to a repository  If every configured discovery tool matches  then the plugin may be     used to generate manifests for Applications using the repository  If the discovery config is omitted then the plugin      will not match any application but can still be invoked explicitly by specifying the plugin name in the app spec       Only one of fileName  find glob  or find command should be specified  If multiple are specified then only the      first  in that order  is evaluated    discover        fileName is a glob pattern  https   pkg go dev path filepath Glob  that is applied to the Application s source        directory  If there is a match  this plugin may be used for the Application      fileName     subdir s  yaml      find          This does the same thing as fileName  but it supports double start  nested directory  glob patterns        glob      Chart yaml          The find command runs in the repository s root directory  To match  it must exit with status code 0  and           produce non empty output to standard out        command   sh   c  find    name env yaml      The parameters config describes what parameters the UI should display for an Application  It is up to the user to     actually set parameters in the Application manifest  in spec source plugin parameters   The announcements  only      inform the  Parameters  tab in the App Details page of the UI    parameters        Static parameter announcements are sent to the UI for  all  Applications handled by this plugin        Think of the  string    array   and  map  values set here as  defaults   It is up to the plugin author to make        sure that these default values actually reflect the plugin s behavior if the user doesn t explicitly set different       values for those parameters      static          name  string param         title  Description of the string param         tooltip  Tooltip shown when the user hovers the           If this field is set  the UI will indicate to the user that they must set the value          required  false           itemType tells the UI how to present the parameter s value  or  for arrays and maps  values   Default is            string   Examples of other types which may be supported in the future are  boolean  or  number             Even if the itemType is not  string   the parameter value from the Application spec will be sent to the plugin           as a string  It s up to the plugin to do the appropriate conversion          itemType               collectionType describes what type of value this parameter accepts  string  array  or map  and allows the UI           to present a form to match that type  Default is  string   This field must be present for non string types            It will not be inferred from the presence of an  array  or  map  field          collectionType               This field communicates the parameter s default value to the UI  Setting this field is optional          string  default string value         All the fields above besides  string  apply to both the array and map type parameter announcements          name  array param           This field communicates the parameter s default value to the UI  Setting this field is optional          array   default  items          collectionType  array         name  map param           This field communicates the parameter s default value to the UI  Setting this field is optional          map            some  value         collectionType  map       Dynamic parameter announcements are announcements specific to an Application handled by this plugin  For example        the values for a Helm chart s values yaml file could be sent as parameter announcements      dynamic          The command is run in an Application s source directory  Standard output must be JSON matching the schema of the         static parameter announcements list        command   echo      name    example param    string    default string value           If set to  true  then the plugin receives repository files with original file mode  Dangerous since the repository     might have executable files  Set to true only if you trust the CMP plugin authors    preserveFileMode  false      If set to  true  then the plugin can retrieve git credentials from the reposerver during generate  Plugin authors      should ensure these credentials are appropriately protected during execution   provideGitCreds  false          note     While the ConfigManagementPlugin  looks like  a Kubernetes object  it is not actually a custom resource       It only follows kubernetes style spec conventions   The  generate  command must print a valid Kubernetes YAML or JSON object stream to stdout  Both  init  and  generate  commands are executed inside the application source directory   The  discover fileName  is used as  glob  https   pkg go dev path filepath Glob  pattern to determine whether an application repository is supported by the plugin or not       yaml   discover      find        command   sh   c  find    name env yaml       If  discover fileName  is not provided  the  discover find command  is executed in order to determine whether an application repository is supported by the plugin or not  The  find  command should return a non error exit code and produce output to stdout when the application source type is supported        Place the plugin configuration file in the sidecar  Argo CD expects the plugin configuration file to be located at   home argocd cmp server config plugin yaml  in the sidecar   If you use a custom image for the sidecar  you can add the file directly to that image      dockerfile WORKDIR  home argocd cmp server config  COPY plugin yaml         If you use a stock image for the sidecar or would rather maintain the plugin configuration in a ConfigMap  just nest the plugin config file in a ConfigMap under the  plugin yaml  key and mount the ConfigMap in the sidecar  see next section       yaml apiVersion  v1 kind  ConfigMap metadata    name  my plugin config data    plugin yaml        apiVersion  argoproj io v1alpha1     kind  ConfigManagementPlugin     metadata        name  my plugin     spec        version  v1 0       init          command   sh   c   echo  Initializing             generate          command   sh   c   echo     kind      ConfigMap      apiVersion      v1      metadata        name       ARGOCD APP NAME      namespace       ARGOCD APP NAMESPACE      annotations       Foo       ARGOCD ENV FOO      KubeVersion       KUBE VERSION      KubeApiVersion       KUBE API VERSIONS     Bar      baz               discover          fileName     subdir s  yaml            Register the plugin sidecar  To install a plugin  patch argocd repo server to run the plugin container as a sidecar  with argocd cmp server as its  entrypoint  You can use either off the shelf or custom built plugin image as sidecar image  For example      yaml containers    name  my plugin   command    var run argocd argocd cmp server    Entrypoint should be Argo CD lightweight CMP server i e  argocd cmp server   image  ubuntu   This can be off the shelf or custom built image   securityContext      runAsNonRoot  true     runAsUser  999   volumeMounts        mountPath   var run argocd       name  var files       mountPath   home argocd cmp server plugins       name  plugins       Remove this volumeMount if you ve chosen to bake the config file into the sidecar image        mountPath   home argocd cmp server config plugin yaml       subPath  plugin yaml       name  my plugin config       Starting with v2 4  do NOT mount the same tmp volume as the repo server container  The filesystem separation helps        mitigate path traversal attacks        mountPath   tmp       name  cmp tmp volumes    configMap      name  my plugin config   name  my plugin config   emptyDir       name  cmp tmp           important  Double check these items      1  Make sure to use   var run argocd argocd cmp server  as an entrypoint  The  argocd cmp server  is a lightweight GRPC service that allows Argo CD to interact with the plugin      2  Make sure that sidecar container is running as user 999      3  Make sure that plugin configuration file is present at   home argocd cmp server config plugin yaml   It can either be volume mapped via configmap or baked into image       Using environment variables in your plugin  Plugin commands have access to  1  The system environment variables of the sidecar 2   Standard build environment variables     user guide build environment md  3  Variables in the Application spec  References to system and build variables will get interpolated in the variables  values            apiVersion  argoproj io v1alpha1         kind  Application         spec            source              plugin                env                    name  FOO                   value  bar                   name  REV                   value  test  ARGOCD APP REVISION          Before reaching the  init command    generate command   and  discover find command  commands  Argo CD prefixes all      user supplied environment variables   3 above  with  ARGOCD ENV    This prevents users from directly setting      potentially sensitive environment variables   4  Parameters in the Application spec           apiVersion  argoproj io v1alpha1         kind  Application         spec           source             plugin               parameters                   name  values files                  array   values dev yaml                   name  helm parameters                  map                     image tag  v1 2 3         The parameters are available as JSON in the  ARGOCD APP PARAMETERS  environment variable  The example above would     produce this JSON                 name    values files    array     values dev yaml       name    helm parameters    map     image tag    v1 2 3                 note         Parameter announcements  even if they specify defaults  are  not  sent to the plugin in  ARGOCD APP PARAMETERS           Only parameters explicitly set in the Application spec are sent to the plugin  It is up to the plugin to apply         the same defaults as the ones announced to the UI          The same parameters are also available as individual environment variables  The names of the environment variables     follows this convention                   name  some string param              string  some string value              PARAM SOME STRING PARAM some string value                          name  some array param              value   item1  item2               PARAM SOME ARRAY PARAM 0 item1              PARAM SOME ARRAY PARAM 1 item2                          name  some map param              map                 image tag  v1 2 3              PARAM SOME MAP PARAM IMAGE TAG v1 2 3         warning  Sanitize escape user input       As part of Argo CD s manifest generation system  config management plugins are treated with a level of trust  Be     sure to escape user input in your plugin to prevent malicious input from causing unwanted behavior      Using a config management plugin with an Application  You may leave the  name  field empty in the  plugin  section for the plugin to be automatically matched with the Application based on its discovery rules  If you do mention the name make sure  it is either   metadata name   spec version   if version is mentioned in the  ConfigManagementPlugin  spec or else just   metadata name    When name is explicitly  specified only that particular plugin will be used iff its discovery pattern command matches the provided application repo      yaml apiVersion  argoproj io v1alpha1 kind  Application metadata    name  guestbook   namespace  argocd spec    project  default   source      repoURL  https   github com argoproj argocd example apps git     targetRevision  HEAD     path  guestbook     plugin        env            name  FOO           value  bar      If you don t need to set any environment variables  you can set an empty plugin section      yaml     plugin              important     If your CMP command runs too long  the command will be killed  and the UI will show an error  The CMP server     respects the timeouts set by the  server repo server timeout seconds  and  controller repo server timeout seconds       items in  argocd cm   Increase their values from the default of 60s       Each CMP command will also independently timeout on the  ARGOCD EXEC TIMEOUT  set for the CMP sidecar  The default     is 90s  So if you increase the repo server timeout greater than 90s  be sure to set  ARGOCD EXEC TIMEOUT  on the     sidecar           note     Each Application can only have one config management plugin configured at a time  If you re converting an existing     plugin configured through the  argocd cm  ConfigMap to a sidecar  make sure to update the plugin name to either   metadata name   spec version        if version was mentioned in the  ConfigManagementPlugin  spec or else just use   metadata name    You can also remove the name altogether      and let the automatic discovery to identify the plugin      note     If a CMP renders blank manfiests  and  prune  is set to  true   Argo CD will automatically remove resources  CMP plugin authors should ensure errors are part of the exit code  Commonly something like  kustomize build     cat  won t pass errors because of the pipe  Consider setting  set  o pipefail  so anything piped will pass errors on failure      Debugging a CMP  If you are actively developing a sidecar installed CMP  keep a few things in mind   1  If you are mounting plugin yaml from a ConfigMap  you will have to restart the repo server Pod so the plugin will    pick up the changes  2  If you have baked plugin yaml into your image  you will have to build  push  and force a re pull of that image on the    repo server Pod so the plugin will pick up the changes  If you are using   latest   the Pod will always pull the new    image  If you re using a different  static tag  set  imagePullPolicy  Always  on the CMP s sidecar container  3  CMP errors are cached by the repo server in Redis  Restarting the repo server Pod will not clear the cache  Always    do a  Hard Refresh  when actively developing a CMP so you have the latest output  4  Verify your sidecar has started properly by viewing the Pod and seeing that two containers are running  kubectl get pod  l app kubernetes io component repo server  n argocd  5  Write log message to stderr and set the    loglevel info  flag in the sidecar  This will print everything written to stderr  even on successfull command execution        Other Common Errors   Error Message   Cause                  no matches for kind  ConfigManagementPlugin  in version  argoproj io v1alpha1     The  ConfigManagementPlugin  CRD was deprecated in Argo CD 2 4 and removed in 2 8  This error means you ve tried to put the configuration for your plugin directly into Kubernetes as a CRD  Refer to this  section of documentation   write the plugin configuration file  for how to write the plugin configuration file and place it properly in the sidecar        Plugin tar stream exclusions  In order to increase the speed of manifest generation  certain files and folders can be excluded from being sent to your plugin  We recommend excluding your   git  folder if it isn t necessary  Use Go s  filepatch Match  https   pkg go dev path filepath Match  syntax  For example    git    to exclude   git  folder   You can set it one of three ways   1  The    plugin tar exclude  argument on the repo server  2  The  reposerver plugin tar exclusions  key if you are using  argocd cmd params cm  3  Directly setting  ARGOCD REPO SERVER PLUGIN TAR EXCLUSIONS  environment variable on the repo server   For option 1  the flag can be repeated multiple times  For option 2 and 3  you can specify multiple globs by separating them with semicolons      Application manifests generation using argocd argoproj io manifest generate paths  To enhance the application manifests generation process  you can enable the use of the  argocd argoproj io manifest generate paths  annotation  When this flag is enabled  the resources specified by this annotation will be passed to the CMP server for generating application manifests  rather than sending the entire repository  This can be particularly useful for monorepos   You can set it one of three ways   1  The    plugin use manifest generate paths  argument on the repo server  2  The  reposerver plugin use manifest generate paths  key if you are using  argocd cmd params cm  3  Directly setting  ARGOCD REPO SERVER PLUGIN USE MANIFEST GENERATE PATHS  environment variable on the repo server to  true       Migrating from argocd cm plugins  Installing plugins by modifying the argocd cm ConfigMap is deprecated as of v2 4 and has been completely removed starting in v2 8   CMP plugins work by adding a sidecar to  argocd repo server  along with a configuration in that sidecar located at   home argocd cmp server config plugin yaml   A argocd cm plugin can be easily converted with the following steps       Convert the ConfigMap entry into a config file  First  copy the plugin s configuration into its own YAML file  Take for example the following ConfigMap entry      yaml data    configManagementPlugins          name  pluginName       init                             Optional command to initialize application source directory         command    sample command           args    sample args         generate                         Command to generate Kubernetes Objects in either YAML or JSON         command    sample command           args    sample args         lockRepo  true                   Defaults to false  See below       The  pluginName  item would be converted to a config file like this      yaml apiVersion  argoproj io v1alpha1 kind  ConfigManagementPlugin metadata    name  pluginName spec    init                             Optional command to initialize application source directory     command    sample command       args    sample args     generate                         Command to generate Kubernetes Objects in either YAML or JSON     command    sample command       args    sample args            note     The  lockRepo  key is not relevant for sidecar plugins  because sidecar plugins do not share a single source repo     directory when generating manifests   Next  we need to decide how this yaml is going to be added to the sidecar  We can either bake the yaml directly into the image  or we can mount it from a ConfigMap    If using a ConfigMap  our example would look like this      yaml apiVersion  v1 kind  ConfigMap metadata    name  pluginName   namespace  argocd data    pluginName yaml        apiVersion  argoproj io v1alpha1     kind  ConfigManagementPlugin     metadata        name  pluginName     spec        init                             Optional command to initialize application source directory         command    sample command           args    sample args         generate                         Command to generate Kubernetes Objects in either YAML or JSON         command    sample command           args    sample args        Then this would be mounted in our plugin sidecar       Write discovery rules for your plugin  Sidecar plugins can use either discovery rules or a plugin name to match Applications to plugins  If the discovery rule is omitted  then you have to explicitly specify the plugin by name in the app spec or else that particular plugin will not match any app   If you want to use discovery instead of the plugin name to match applications to your plugin  write rules applicable to  your plugin  using the instructions above   1 write the plugin configuration file  and add them to your configuration  file   To use the name instead of discovery  update the name in your application manifest to   metadata name   spec version    if version was mentioned in the  ConfigManagementPlugin  spec or else just use   metadata name    For example      yaml apiVersion  argoproj io v1alpha1 kind  Application metadata    name  guestbook spec    source      plugin        name  pluginName    Delete this for auto discovery  and set  plugin      if  name  was the only value  or use proper sidecar plugin name          Make sure the plugin has access to the tools it needs  Plugins configured with argocd cm ran on the Argo CD image  This gave it access to all the tools installed on that image by default  see the  Dockerfile  https   github com argoproj argo cd blob master Dockerfile  for base image and installed tools    You can either use a stock image  like ubuntu  busybox  or alpine k8s  or design your own base image with the tools your plugin needs  For security  avoid using images with more binaries installed than what your plugin actually needs       Test the plugin  After installing the plugin as a sidecar  according to the directions above   installing a config management plugin   test it out on a few Applications before migrating all of them to the sidecar plugin   Once tests have checked out  remove the plugin entry from your argocd cm ConfigMap       Additional Settings       Preserve repository files mode  By default  config management plugin receives source repository files with reset file mode  This is done for security reasons  If you want to preserve original file mode  you can set  preserveFileMode  to  true  in the plugin spec       warning     Make sure you trust the plugin you are using  If you set  preserveFileMode  to  true  then the plugin might receive     files with executable permissions which can be a security risk      yaml apiVersion  argoproj io v1alpha1 kind  ConfigManagementPlugin metadata    name  pluginName spec    init      command    sample command       args    sample args     generate      command    sample command       args    sample args     preserveFileMode  true            Provide Git Credentials  By default  the config management plugin is responsible for providing its own credentials to additional Git repositories that may need to be accessed during manifest generation  The reposerver has these credentials available in its git creds store  When credential sharing is allowed  the git credentials used by the reposerver to clone the repository contents are shared for the lifetime of the execution of the config management plugin  utilizing git s  ASKPASS  method to make a call from the config management sidecar container to the reposerver to retrieve the initialized git credentials   Utilizing  ASKPASS  means that credentials are not proactively shared  but rather only provided when an operation requires them   To allow the plugin to access the reposerver git credentials  you can set  provideGitCreds  to  true  in the plugin spec       warning     Make sure you trust the plugin you are using  If you set  provideGitCreds  to  true  then the plugin will receive     credentials used to clone the source Git repository      yaml apiVersion  argoproj io v1alpha1 kind  ConfigManagementPlugin metadata    name  pluginName spec    init      command    sample command       args    sample args     generate      command    sample command       args    sample args     provideGitCreds  true


argocd Metrics Application Controller Metrics gauge Information about Applications It contains labels such as and that reflect the application state in Argo CD Metrics about applications Scraped at the endpoint Metric Type Description Argo CD exposes different sets of Prometheus metrics per server

Answer:
# Metrics

Argo CD exposes different sets of Prometheus metrics per server.

## Application Controller Metrics
Metrics about applications. Scraped at the `argocd-metrics:8082/metrics` endpoint.

| Metric | Type | Description |
|--------|:----:|-------------|
| `argocd_app_info` | gauge | Information about Applications. It contains labels such as `sync_status` and `health_status` that reflect the application state in Argo CD. |
| `argocd_app_condition` | gauge | Report Applications conditions. It contains the conditions currently present in the application status. |
| `argocd_app_k8s_request_total` | counter | Number of Kubernetes requests executed during application reconciliation |
| `argocd_app_labels` | gauge | Argo Application labels converted to Prometheus labels. Disabled by default. See section below about how to enable it. |
| `argocd_app_orphaned_resources_count` | gauge | Number of orphaned resources per application. |
| `argocd_app_reconcile` | histogram | Application reconciliation performance in seconds. |
| `argocd_app_sync_total` | counter | Counter for application sync history |
| `argocd_cluster_api_resource_objects` | gauge | Number of k8s resource objects in the cache. |
| `argocd_cluster_api_resources` | gauge | Number of monitored Kubernetes API resources. |
| `argocd_cluster_cache_age_seconds` | gauge | Cluster cache age in seconds. |
| `argocd_cluster_connection_status` | gauge | The k8s cluster current connection status. |
| `argocd_cluster_events_total` | counter | Number of processes k8s resource events. |
| `argocd_cluster_info` | gauge | Information about cluster. |
| `argocd_kubectl_exec_pending` | gauge | Number of pending kubectl executions |
| `argocd_kubectl_exec_total` | counter | Number of kubectl executions |
| `argocd_redis_request_duration` | histogram | Redis requests duration. |
| `argocd_redis_request_total` | counter | Number of redis requests executed during application reconciliation |

If you use Argo CD with many application and project creation and deletion,
the metrics page will keep in cache your application and project's history.
If you are having issues because of a large number of metrics cardinality due
to deleted resources, you can schedule a metrics reset to clean the
history with an application controller flag. Example:
`--metrics-cache-expiration="24h0m0s"`.

### Exposing Application labels as Prometheus metrics

There are use-cases where Argo CD Applications contain labels that are desired to be exposed as Prometheus metrics.
Some examples are:

* Having the team name as a label to allow routing alerts to specific receivers
* Creating dashboards broken down by business units

As the Application labels are specific to each company, this feature is disabled by default. To enable it, add the
`--metrics-application-labels` flag to the Argo CD application controller.

The example below will expose the Argo CD Application labels `team-name` and `business-unit` to Prometheus:

    containers:
    - command:
      - argocd-application-controller
      - --metrics-application-labels
      - team-name
      - --metrics-application-labels
      - business-unit

In this case, the metric would look like:

```
# TYPE argocd_app_labels gauge
argocd_app_labels{label_business_unit="bu-id-1",label_team_name="my-team",name="my-app-1",namespace="argocd",project="important-project"} 1
argocd_app_labels{label_business_unit="bu-id-1",label_team_name="my-team",name="my-app-2",namespace="argocd",project="important-project"} 1
argocd_app_labels{label_business_unit="bu-id-2",label_team_name="another-team",name="my-app-3",namespace="argocd",project="important-project"} 1
```

### Exposing Application conditions as Prometheus metrics

There are use-cases where Argo CD Applications contain conditions that are desired to be exposed as Prometheus metrics.
Some examples are:

* Hunting orphaned resources across all deployed applications
* Knowing which resources are excluded from ArgoCD

As the Application conditions are specific to each company, this feature is disabled by default. To enable it, add the
`--metrics-application-conditions` flag to the Argo CD application controller.

The example below will expose the Argo CD Application condition `OrphanedResourceWarning` and `ExcludedResourceWarning` to Prometheus:

```yaml
    containers:
    - command:
      - argocd-application-controller
      - --metrics-application-conditions
      - OrphanedResourceWarning
      - --metrics-application-conditions
      - ExcludedResourceWarning
```

## Application Set Controller metrics

The Application Set controller exposes the following metrics for application sets.

| Metric | Type | Description |
|--------|:----:|-------------|
| `argocd_appset_info` | gauge | Information about Application Sets. It contains labels for the name and namespace of an application set as well as `Resource_update_status`  that reflects the `ResourcesUpToDate` property |
| `argocd_appset_reconcile` | histogram | Application reconciliation performance in seconds. It contains labels for the name and namespace of an applicationset |
| `argocd_appset_labels` | gauge | Applicationset labels translated to Prometheus labels. Disabled by default |
| `argocd_appset_owned_applications` | gauge | Number of applications owned by the applicationset. It contains labels for the name and namespace of an applicationset. |

Similar to the same metric in application controller (`argocd_app_labels`) the metric `argocd_appset_labels` is disabled by default. You can enable it by providing the `–metrics-applicationset-labels` argument to the applicationset controller.

Once enabled it works exactly the same as application controller metrics (label_ appended to normalized label name).
Available labels include Name, Namespace + all labels enabled by the command line options and their value (exactly like application controller metrics described in the previous section).

## API Server Metrics
Metrics about API Server API request and response activity (request totals, response codes, etc...).
Scraped at the `argocd-server-metrics:8083/metrics` endpoint.

| Metric | Type | Description |
|--------|:----:|-------------|
| `argocd_redis_request_duration` | histogram | Redis requests duration. |
| `argocd_redis_request_total` | counter | Number of Kubernetes requests executed during application reconciliation. |
| `grpc_server_handled_total` | counter | Total number of RPCs completed on the server, regardless of success or failure. |
| `grpc_server_msg_sent_total` | counter | Total number of gRPC stream messages sent by the server. |
| `argocd_proxy_extension_request_total` | counter | Number of requests sent to the configured proxy extensions. |
| `argocd_proxy_extension_request_duration_seconds` | histogram | Request duration in seconds between the Argo CD API server and the proxy extension backend. |

## Repo Server Metrics
Metrics about the Repo Server.
Scraped at the `argocd-repo-server:8084/metrics` endpoint.

| Metric | Type | Description |
|--------|:----:|-------------|
| `argocd_git_request_duration_seconds` | histogram | Git requests duration seconds. |
| `argocd_git_request_total` | counter | Number of git requests performed by repo server |
| `argocd_git_fetch_fail_total` | counter | Number of git fetch requests failures by repo server |
| `argocd_redis_request_duration_seconds` | histogram | Redis requests duration seconds. |
| `argocd_redis_request_total` | counter | Number of Kubernetes requests executed during application reconciliation. |
| `argocd_repo_pending_request_total` | gauge | Number of pending requests requiring repository lock |

## Prometheus Operator

If using Prometheus Operator, the following ServiceMonitor example manifests can be used.
Add a namespace where Argo CD is installed and change `metadata.labels.release` to the name of label selected by your Prometheus.

```yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: argocd-metrics
  labels:
    release: prometheus-operator
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-metrics
  endpoints:
  - port: metrics
```

```yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: argocd-server-metrics
  labels:
    release: prometheus-operator
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-server-metrics
  endpoints:
  - port: metrics
```

```yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: argocd-repo-server-metrics
  labels:
    release: prometheus-operator
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-repo-server
  endpoints:
  - port: metrics
```

```yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: argocd-applicationset-controller-metrics
  labels:
    release: prometheus-operator
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-applicationset-controller
  endpoints:
  - port: metrics
```

```yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: argocd-dex-server
  labels:
    release: prometheus-operator
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-dex-server
  endpoints:
    - port: metrics
```

```yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: argocd-redis-haproxy-metrics
  labels:
    release: prometheus-operator
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-redis-ha-haproxy
  endpoints:
  - port: http-exporter-port
```

For notifications controller, you need to additionally add following:

```yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: argocd-notifications-controller
  labels:
    release: prometheus-operator
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-notifications-controller-metrics
  endpoints:
    - port: metrics
```

## Dashboards

You can find an example Grafana dashboard [here](https://github.com/argoproj/argo-cd/blob/master/examples/dashboard.json) or check demo instance
[dashboard](https://grafana.apps.argoproj.io).

![dashboard](../assets/dashboard.jpg)

Metrics  Argo CD exposes different sets of Prometheus metrics per server      Application Controller Metrics Metrics about applications  Scraped at the  argocd metrics 8082 metrics  endpoint     Metric   Type   Description                                      argocd app info    gauge   Information about Applications  It contains labels such as  sync status  and  health status  that reflect the application state in Argo CD       argocd app condition    gauge   Report Applications conditions  It contains the conditions currently present in the application status       argocd app k8s request total    counter   Number of Kubernetes requests executed during application reconciliation      argocd app labels    gauge   Argo Application labels converted to Prometheus labels  Disabled by default  See section below about how to enable it       argocd app orphaned resources count    gauge   Number of orphaned resources per application       argocd app reconcile    histogram   Application reconciliation performance in seconds       argocd app sync total    counter   Counter for application sync history      argocd cluster api resource objects    gauge   Number of k8s resource objects in the cache       argocd cluster api resources    gauge   Number of monitored Kubernetes API resources       argocd cluster cache age seconds    gauge   Cluster cache age in seconds       argocd cluster connection status    gauge   The k8s cluster current connection status       argocd cluster events total    counter   Number of processes k8s resource events       argocd cluster info    gauge   Information about cluster       argocd kubectl exec pending    gauge   Number of pending kubectl executions      argocd kubectl exec total    counter   Number of kubectl executions      argocd redis request duration    histogram   Redis requests duration       argocd redis request total    counter   Number of redis requests executed during application reconciliation    If you use Argo CD with many application and project creation and deletion  the metrics page will keep in cache your application and project s history  If you are having issues because of a large number of metrics cardinality due to deleted resources  you can schedule a metrics reset to clean the history with an application controller flag  Example     metrics cache expiration  24h0m0s           Exposing Application labels as Prometheus metrics  There are use cases where Argo CD Applications contain labels that are desired to be exposed as Prometheus metrics  Some examples are     Having the team name as a label to allow routing alerts to specific receivers   Creating dashboards broken down by business units  As the Application labels are specific to each company  this feature is disabled by default  To enable it  add the    metrics application labels  flag to the Argo CD application controller   The example below will expose the Argo CD Application labels  team name  and  business unit  to Prometheus       containers        command          argocd application controller           metrics application labels         team name           metrics application labels         business unit  In this case  the metric would look like         TYPE argocd app labels gauge argocd app labels label business unit  bu id 1  label team name  my team  name  my app 1  namespace  argocd  project  important project   1 argocd app labels label business unit  bu id 1  label team name  my team  name  my app 2  namespace  argocd  project  important project   1 argocd app labels label business unit  bu id 2  label team name  another team  name  my app 3  namespace  argocd  project  important project   1          Exposing Application conditions as Prometheus metrics  There are use cases where Argo CD Applications contain conditions that are desired to be exposed as Prometheus metrics  Some examples are     Hunting orphaned resources across all deployed applications   Knowing which resources are excluded from ArgoCD  As the Application conditions are specific to each company  this feature is disabled by default  To enable it  add the    metrics application conditions  flag to the Argo CD application controller   The example below will expose the Argo CD Application condition  OrphanedResourceWarning  and  ExcludedResourceWarning  to Prometheus      yaml     containers        command          argocd application controller           metrics application conditions         OrphanedResourceWarning           metrics application conditions         ExcludedResourceWarning         Application Set Controller metrics  The Application Set controller exposes the following metrics for application sets     Metric   Type   Description                                      argocd appset info    gauge   Information about Application Sets  It contains labels for the name and namespace of an application set as well as  Resource update status   that reflects the  ResourcesUpToDate  property      argocd appset reconcile    histogram   Application reconciliation performance in seconds  It contains labels for the name and namespace of an applicationset      argocd appset labels    gauge   Applicationset labels translated to Prometheus labels  Disabled by default      argocd appset owned applications    gauge   Number of applications owned by the applicationset  It contains labels for the name and namespace of an applicationset     Similar to the same metric in application controller   argocd app labels   the metric  argocd appset labels  is disabled by default  You can enable it by providing the   metrics applicationset labels  argument to the applicationset controller   Once enabled it works exactly the same as application controller metrics  label  appended to normalized label name   Available labels include Name  Namespace   all labels enabled by the command line options and their value  exactly like application controller metrics described in the previous section       API Server Metrics Metrics about API Server API request and response activity  request totals  response codes  etc      Scraped at the  argocd server metrics 8083 metrics  endpoint     Metric   Type   Description                                      argocd redis request duration    histogram   Redis requests duration       argocd redis request total    counter   Number of Kubernetes requests executed during application reconciliation       grpc server handled total    counter   Total number of RPCs completed on the server  regardless of success or failure       grpc server msg sent total    counter   Total number of gRPC stream messages sent by the server       argocd proxy extension request total    counter   Number of requests sent to the configured proxy extensions       argocd proxy extension request duration seconds    histogram   Request duration in seconds between the Argo CD API server and the proxy extension backend        Repo Server Metrics Metrics about the Repo Server  Scraped at the  argocd repo server 8084 metrics  endpoint     Metric   Type   Description                                      argocd git request duration seconds    histogram   Git requests duration seconds       argocd git request total    counter   Number of git requests performed by repo server      argocd git fetch fail total    counter   Number of git fetch requests failures by repo server      argocd redis request duration seconds    histogram   Redis requests duration seconds       argocd redis request total    counter   Number of Kubernetes requests executed during application reconciliation       argocd repo pending request total    gauge   Number of pending requests requiring repository lock       Prometheus Operator  If using Prometheus Operator  the following ServiceMonitor example manifests can be used  Add a namespace where Argo CD is installed and change  metadata labels release  to the name of label selected by your Prometheus      yaml apiVersion  monitoring coreos com v1 kind  ServiceMonitor metadata    name  argocd metrics   labels      release  prometheus operator spec    selector      matchLabels        app kubernetes io name  argocd metrics   endpoints      port  metrics         yaml apiVersion  monitoring coreos com v1 kind  ServiceMonitor metadata    name  argocd server metrics   labels      release  prometheus operator spec    selector      matchLabels        app kubernetes io name  argocd server metrics   endpoints      port  metrics         yaml apiVersion  monitoring coreos com v1 kind  ServiceMonitor metadata    name  argocd repo server metrics   labels      release  prometheus operator spec    selector      matchLabels        app kubernetes io name  argocd repo server   endpoints      port  metrics         yaml apiVersion  monitoring coreos com v1 kind  ServiceMonitor metadata    name  argocd applicationset controller metrics   labels      release  prometheus operator spec    selector      matchLabels        app kubernetes io name  argocd applicationset controller   endpoints      port  metrics         yaml apiVersion  monitoring coreos com v1 kind  ServiceMonitor metadata    name  argocd dex server   labels      release  prometheus operator spec    selector      matchLabels        app kubernetes io name  argocd dex server   endpoints        port  metrics         yaml apiVersion  monitoring coreos com v1 kind  ServiceMonitor metadata    name  argocd redis haproxy metrics   labels      release  prometheus operator spec    selector      matchLabels        app kubernetes io name  argocd redis ha haproxy   endpoints      port  http exporter port      For notifications controller  you need to additionally add following      yaml apiVersion  monitoring coreos com v1 kind  ServiceMonitor metadata    name  argocd notifications controller   labels      release  prometheus operator spec    selector      matchLabels        app kubernetes io name  argocd notifications controller metrics   endpoints        port  metrics          Dashboards  You can find an example Grafana dashboard  here  https   github com argoproj argo cd blob master examples dashboard json  or check demo instance  dashboard  https   grafana apps argoproj io      dashboard     assets dashboard jpg


argocd The following groups of features won t be available in this engine capable of getting the desired state from Git repositories and Introduction Argo CD Core mode With this installation you will have a fully functional GitOps applying it in Kubernetes Argo CD Core is a different installation that runs Argo CD in headless

Answer:
# Argo CD Core

## Introduction

Argo CD Core is a different installation that runs Argo CD in headless
mode. With this installation, you will have a fully functional GitOps
engine capable of getting the desired state from Git repositories and
applying it in Kubernetes.

The following groups of features won't be available in this
installation:

- Argo CD RBAC model
- Argo CD API
- Argo CD Notification Controller
- OIDC based authentication

The following features will be partially available (see the
[usage](#using) section below for more details):

- Argo CD Web UI
- Argo CD CLI
- Multi-tenancy (strictly GitOps based on git push permissions)

A few use-cases that justify running Argo CD Core are:

- As a cluster admin, I want to rely on Kubernetes RBAC only.
- As a devops engineer, I don't want to learn a new API or depend on
  another CLI to automate my deployments. I want to rely on the
  Kubernetes API only.
- As a cluster admin, I don't want to provide Argo CD UI or Argo CD
  CLI to developers.

## Architecture

Because Argo CD is designed with a component based architecture in
mind, it is possible to have a more minimalist installation. In this
case fewer components are installed and yet the main GitOps
functionality remains operational.

In the diagram below, the Core box, shows the components that will be
installed while opting for Argo CD Core:

![Argo CD Core](../assets/argocd-core-components.png)

Note that even if the Argo CD controller can run without Redis, it
isn't recommended. The Argo CD controller uses Redis as an important
caching mechanism reducing the load on Kube API and in Git. For this
reason, Redis is also included in this installation method.

## Installing

Argo CD Core can be installed by applying a single manifest file that
contains all the required resources.

Example:

```
export ARGOCD_VERSION=<desired argo cd release version (e.g. v2.7.0)>
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/$ARGOCD_VERSION/manifests/core-install.yaml
```

## Using

Once Argo CD Core is installed, users will be able to interact with it
by relying on GitOps. The available Kubernetes resources will be the
`Application` and the `ApplicationSet` CRDs. By using those resources,
users will be able to deploy and manage applications in Kubernetes.

It is still possible to use Argo CD CLI even when running Argo CD
Core. In this case, the CLI will spawn a local API server process that
will be used to handle the CLI command. Once the command is concluded,
the local API Server process will also be terminated. This happens
transparently for the user with no additional command required. Note
that Argo CD Core will rely only on Kubernetes RBAC and the user (or
the process) invoking the CLI needs to have access to the Argo CD
namespace with the proper permission in the `Application` and
`ApplicationSet` resources for executing a given command.

To use Argo CD CLI in core mode, it is required to pass the `--core`
flag with the `login` subcommand.

Example:

```bash
kubectl config set-context --current --namespace=argocd # change current kube context to argocd namespace
argocd login --core
```

Similarly, users can also run the Web UI locally if they prefer to
interact with Argo CD using this method. The Web UI can be started
locally by running the following command:

```
argocd admin dashboard -n argocd
```

Argo CD Web UI will be available at `http://localhost:8080`

Argo CD Core     Introduction  Argo CD Core is a different installation that runs Argo CD in headless mode  With this installation  you will have a fully functional GitOps engine capable of getting the desired state from Git repositories and applying it in Kubernetes   The following groups of features won t be available in this installation     Argo CD RBAC model   Argo CD API   Argo CD Notification Controller   OIDC based authentication  The following features will be partially available  see the  usage   using  section below for more details      Argo CD Web UI   Argo CD CLI   Multi tenancy  strictly GitOps based on git push permissions   A few use cases that justify running Argo CD Core are     As a cluster admin  I want to rely on Kubernetes RBAC only    As a devops engineer  I don t want to learn a new API or depend on   another CLI to automate my deployments  I want to rely on the   Kubernetes API only    As a cluster admin  I don t want to provide Argo CD UI or Argo CD   CLI to developers      Architecture  Because Argo CD is designed with a component based architecture in mind  it is possible to have a more minimalist installation  In this case fewer components are installed and yet the main GitOps functionality remains operational   In the diagram below  the Core box  shows the components that will be installed while opting for Argo CD Core     Argo CD Core     assets argocd core components png   Note that even if the Argo CD controller can run without Redis  it isn t recommended  The Argo CD controller uses Redis as an important caching mechanism reducing the load on Kube API and in Git  For this reason  Redis is also included in this installation method      Installing  Argo CD Core can be installed by applying a single manifest file that contains all the required resources   Example       export ARGOCD VERSION  desired argo cd release version  e g  v2 7 0   kubectl create namespace argocd kubectl apply  n argocd  f https   raw githubusercontent com argoproj argo cd  ARGOCD VERSION manifests core install yaml         Using  Once Argo CD Core is installed  users will be able to interact with it by relying on GitOps  The available Kubernetes resources will be the  Application  and the  ApplicationSet  CRDs  By using those resources  users will be able to deploy and manage applications in Kubernetes   It is still possible to use Argo CD CLI even when running Argo CD Core  In this case  the CLI will spawn a local API server process that will be used to handle the CLI command  Once the command is concluded  the local API Server process will also be terminated  This happens transparently for the user with no additional command required  Note that Argo CD Core will rely only on Kubernetes RBAC and the user  or the process  invoking the CLI needs to have access to the Argo CD namespace with the proper permission in the  Application  and  ApplicationSet  resources for executing a given command   To use Argo CD CLI in core mode  it is required to pass the    core  flag with the  login  subcommand   Example      bash kubectl config set context   current   namespace argocd   change current kube context to argocd namespace argocd login   core      Similarly  users can also run the Web UI locally if they prefer to interact with Argo CD using this method  The Web UI can be started locally by running the following command       argocd admin dashboard  n argocd      Argo CD Web UI will be available at  http   localhost 8080