Argo CD ApplicationSet Controller

Argo CD ApplicationSet Controller

The ApplicationSet controller is a Kubernetes controller that adds support for a new custom ApplicationSet CustomResourceDefinition (CRD). This controller/CRD enables both automation and greater flexibility when managing Argo CD Applications across a large number of clusters and within monorepos, plus it makes self-service usage possible on multitenant Kubernetes clusters.

The ApplicationSet controller provides the ability:

  • To deploy Argo CD Applications to multiple Kubernetes clusters at once
  • To deploy multiple Argo CD applications from a single monorepo
  • Allows unprivileged cluster users (those without access to the Argo CD namespace) to deploy Argo CD applications without the need to involve cluster administrators in enabling the destination clusters/namespaces
  • Best of all, all these features are controlled by only a single instance of an ApplicationSet custom resource, which means no more juggling of multiple Argo CD Application resources to target those multiple clusters/repos!

Unlike with an Argo CD Application resource, which deploys resources from a single Git repository to a single destination cluster/namespace, ApplicationSet uses templated automation to create, modify, and manage multiple Argo CD applications at once.

If you are loving Argo CD and want to use ApplicationSet's automation and templating to take your usage to the next level, give the ApplicationSet controller a shot!

Example Spec:

# This is an example of a typical ApplicationSet which uses the cluster generator.
# An ApplicationSet is comprised with two stanzas:
#  - spec.generator - producer of a list of values supplied as arguments to an app template
#  - spec.template - an application template, which has been parameterized
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
spec:
  generators:
  - clusters: {} # This is a generator, specifically, a cluster generator.
  template: 
    # This is a template Argo CD Application, but with support for parameter substitution.
    metadata:
      name: '{{name}}-guestbook'
    spec:
      project: "default"
      source:
        repoURL: https://github.com/argoproj/argocd-example-apps/
        targetRevision: HEAD
        path: guestbook
      destination:
        server: '{{server}}'
        namespace: guestbook

The Cluster generator generates parameters, which are substituted into {{parameter name}} values within the template: section of the ApplicationSet resource. In this example, the cluster generates name and server parameters (containing the name and API URL for the target cluster), which are then substituted into the template's {{name}} and {{server}} values, respectively.

The parameter generation via multiple sources (cluster, list, git repos), and the use of those values within Argo CD Application templates, is a powerful combination. Learn more about generators and template, the Cluster generator and various other ApplicationSet generators, and more, from the ApplicationSet documentation.

Documentation

Take a look at our introductory blog post, Introducing the ApplicationSet Controller for Argo CD.

Check out the complete documentation for a complete introduction, how to setup and run the ApplicationSet controller, how it interacts with Argo CD, generators, templates, use cases, and more.

Community

The ApplicationSet controller is a community-driven project. You can reach the Argo CD ApplicationSet community and developers via the following channels:

We'd love to have you join us!

Development builds

Development builds can be installed by running the following command:

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/applicationset/master/manifests/install.yaml

Commits to the master branch will automatically push new container images to the container registry used by this install, and see this link for automatically updated documentation for these builds. See Development builds for more details.

Development

Learn more about how to setup a development environment, build the ApplicationSet controller, and run the unit/E2E tests.

Our end goal is to provide a formal solution to replace the app-of-apps pattern. You can learn more about the founding principles of the ApplicationSet controller from the original design doc.

This project will initially be maintained separately from Argo CD, in order to allow quick iteration of the spec and implementation, without tying it to Argo CD releases. No promises of backwards compatibility are made, at least until merging into Argo CD proper.

Comments
  • Application Set not allowing to use jqPathExpressions

    Application Set not allowing to use jqPathExpressions

    In ApplicationSet, I am not able to use jqPathExpressions under ignoreDifferences. getting validation errors

    Argocd Version used: 2.1.1 Application Set version: 0.3.0

    apiVersion: argoproj.io/v1alpha1
    kind: ApplicationSet
    metadata:
      name: xxxsds
      namespace: argocd
    spec:
      generators:
       ...
      template:
        metadata:
          name: xyzzy
        spec:
          ignoreDifferences:
          - group: networking.istio.io
            kind: VirtualService
            jqPathExpressions:
            - .spec.http[*].route[*].weight
    
    error validating data: [ValidationError(ApplicationSet.spec.template.spec.ignoreDifferences[0]): unknown field "jqPathExpressions" in io.argoproj.v1alpha1.ApplicationSet.spec.template.spec.ignoreDifferences, ValidationError(ApplicationSet.spec.template.spec.ignoreDifferences[0]): missing required field "jsonPointers" in io.argoproj.v1alpha1.ApplicationSet.spec.template.spec.ignoreDifferences]
    
  • Application set not able to delete k8s resources of child application

    Application set not able to delete k8s resources of child application

    Hi, I, currently have a application set (parent), which creates a child argo application (child). When i delete the argo parent app or application set it does not remove the child application k8s resources at all and leave them behind.

    Argo cd details:

    argocd: v2.0.1+33eaf11.dirty BuildDate: 2021-04-21T18:44:13Z GitCommit: 33eaf11e3abd8c761c726e815cbb4b6af7dcb030 GitTreeState: dirty GoVersion: go1.16.3 Compiler: gc Platform: darwin/amd64 argocd-server: v2.0.0+f5119c0 BuildDate: 2021-04-07T06:00:33Z GitCommit: f5119c06686399134b3f296d44445bcdbc778d42 GitTreeState: clean GoVersion: go1.16 Compiler: gc Platform: linux/amd64 Ksonnet Version: v0.13.1 Kustomize Version: v3.9.4 2021-02-09T19:22:10Z Helm Version: v3.5.1+g32c2223 Kubectl Version: v0.20.4 Jsonnet Version: v0.17.0

  • Add Bitbucket cloud support to SCM generator

    Add Bitbucket cloud support to SCM generator

    Would be great to have BitBucket cloud as a provide in SCM generator: https://argocd-applicationset.readthedocs.io/en/stable/Generators-SCM-Provider/#scm-provider-generator

  • Add duck type generator support to ApplicationSets

    Add duck type generator support to ApplicationSets

    • Initial Commit
    • Adds a Duck Type Generator to ApplicationSets that allows the controller to read an external Resource Status.Decisions (array) to determine the list of Argo CD clusters to deploy to.
    • This approach uses the duck type Reference, that allows the user to define what resource will provide placement recommendations for target Argo CD clusters
    • Duck Type Status definition:
    status:
      decisions:
      - clusterName: my-cluster01
      - clusterName: my-cluster02
    
    • Duck Type Reference:
    spec:
      ducktType:
        apiVersion: my-group/v1beta1
        kind: MyKind
        name: my-resource-name
        requeueAfterSeconds: 60         # This is optional, default is 3 min
    
  • Create helm chart

    Create helm chart

    Hi all, I see that Argo provides Helm charts to install ArgoCD or other tools (see https://github.com/argoproj/argo-helm/tree/master/charts). Are you planning to add an helm chart for the ApplicationSet as well?

    I'm happy to raise a PR. Should it be in the same ArgoCD chart as an option or a separate chart?

  • feature request - combine generators

    feature request - combine generators

    Hi folks,

    first, thanks for this great project!

    Would it be possible to combine generators?

    in this example combine directory discover with clusters secret

    example:

    apiVersion: argoproj.io/v1alpha1
    kind: ApplicationSet
    metadata:
      name: cluster-addons
    spec:
      generators:
      - git:
          repoURL: https://github.com/infra-team/cluster-deployments.git
          directories:
          - path: add-ons/*
      - clusters:
         selector:
           matchLabels:
             argocd.argoproj.io/secret-type: cluster
           values:
             project: default 
      template:
        metadata:
          name: '{{name}}-{{path.basename}}'
        spec:
          project: '{{values.project}}'
          source:
            repoURL: https://github.com/infra-team/cluster-deployments.git
            targetRevision: HEAD
            path: '{{path}}'
          destination:
            server: {{server}}
            namespace: '{{path.basename}}'
    

    When I try, run into

    error converting YAML to JSON: yaml: invalid map key: map[interface {}]interface {}{"server":interface {}(nil)}
    
  • fix: return revision from getGitGeneratorInfo

    fix: return revision from getGitGeneratorInfo

    It seems that the webhook endpoint was not working completely as expected when tracking a repository branch (other than the default branch).

    It turns out that the revision that is being used to compare against the targetRevision is always empty. So the test on https://github.com/argoproj/applicationset/blob/master/pkg/utils/webhook.go#L246 would always return false.

    The revision field is already being evaluated on https://github.com/argoproj/applicationset/blob/master/pkg/utils/webhook.go#L146, but for some reason it was never included in the response.

    After this change, we verified this on our own installation and now the webhook processing does recognize the correct branches on push events from GitHub.

  • How to get an ApplicationSet to spawn Applications in Argo CD?

    How to get an ApplicationSet to spawn Applications in Argo CD?

    I've been installing the ApplicationSet together with Argo CD 2.0.0 and 2.0.1 without any success in spawning applications from a any generators. Maybe I am missing something trivial, but how do you get the ApplicationSet into Argo CD?

    I have tried adding an Application in Argo CD with a path to a folder in the git repo that contains a spec for an ApplicationSet, or several. I can see the argocd-applicationset-controller running as a replica set and stateful set.

    This is what it looks like in Argo CD... image

  • chore: fixed failing builds, updated docker login

    chore: fixed failing builds, updated docker login

    Signed-off-by: Justin Marquis [email protected]

    Fixed the image build failing for push events. Added GOLANG_VERSION as an environment variable. In PR#499 changes were made in the Makefile, they are still needed for github/workflows/ci-build.yaml left them as is.

  • Matrix generator where a generator can reference items of another one

    Matrix generator where a generator can reference items of another one

    I'm wondering if this would be possible that a generator use another's generator items.

    For instance, imagine the following manifests structure on a GitOps repository:

    - dev
        - instanceA
        - instanceB
    - prod
        - instanceA
        - instanceB
        - instanceC
        - instanceD
    

    Each instance being defined as a single Argo application. Thus 6 instances, 6 Argo applications.

    Right now, I use a List generator with 6 items corresponding to the 6 variants.

    I would like to be able to define a Matrix generator that would combine:

    • a list generator for the 1st level (dev/prod)
    • a git directory generator for the 2nd level but here the path should be able to reuse the list generator attribute

    Something like (draft):

    generators:
      - matrix: 
        - list:
            elements:
              - platform: dev
                cluster: dev
              - platform: prod
                cluster: prod
        - git:
           directories:
             - path: {{platform}}/* # <-- here reuse {{platform}} of first generator
    

    That's not possible for now, right? Or did I miss something?

  • Support log-level for controller logs

    Support log-level for controller logs

    @jgwest EDIT: Enhancement Request: Add support for configurable log levels via parameter, eg the ability to set additional log levels beyond just the --debug parameter support we have now. For example, as requested, ability to set the log level to only show error or warn.

    Original Text from @dorroddorrod Hi, Is there any way to control the log level for the application-set controller ?

  • docs: merge generator typo in example

    docs: merge generator typo in example

    I'm pretty sure the documented example for the merge generator has a slight typo/error in it. Comment in code here should be:

    For clusters with a specific label, disable Kafka.

  • using helm and git repos inside ApplicationSet

    using helm and git repos inside ApplicationSet

    Hello. Is there a possibility to configure an ApplicationSet to create Applications with helm or git sources?

    Example:

        spec:
          source:
            repoURL: "{{source.repoURL}}"
            chart:  "{{source.chart}}" # how will this key be dynamic?
            path: "{{source.path}}" # how will this key be dynamic?
            targetRevision: '{{source.targetRevision}}'
            helm:
              values:
                "{{source.helm.values}}"
    

    And parameters should look something like this (will be passed by generators):

    - appName: app1
      source:
        repoURL: my-helm-repo
        targetRevision: my-chart-version
        chart: my-chart
        helm:
          values: {}
    - appName: app2
      source:
        repoURL: my-git-repo
        targetRevision: my-git-branch
        path: my-chart
        helm:
          values: {}
    

    My use case is that I am storing helm charts inside git repos and for development purposes I point the Application to the git repo (with repoURL being a git repo and targetRevision being a git branch). After development is finished, the helm chart is published to a helm repo and I am referencing that in the Application. I want to achieve the same using ApplicationSets.

    I did some research and the only thing that might help is this feature #11213 (with variant #11183), so I can use something like this in the ApplicationSet definition

        spec:
          source: "{{source}}"
    

    Is there any way of achieving this functionality?

  • FATA[0000] rpc error: code = Unimplemented desc = unknown service applicationset.ApplicationSetService

    FATA[0000] rpc error: code = Unimplemented desc = unknown service applicationset.ApplicationSetService

    i am trying to use the latest argocd cli with appset to apply this applicationset but getting error when applying by running this command argocd appset create file.yaml

    FATA[0000] rpc error: code = Unimplemented desc = unknown service applicationset.ApplicationSetService
    

    here is the sample application set.

    apiVersion: argoproj.io/v1alpha1
    kind: ApplicationSet
    metadata:
      name: deploy-teleport-configmap
    spec:
      generators:
      - list:
          elements:
          - prefix: teleport-configmap-us-west-2
            url: eks-cluster-1
            region: us-west-2
            environment: qa
          - prefix: teleport-configmap-eu-central-1
            url: eks-cluster-2
            region: eu-central-1
            environment: qa
          - prefix: teleport-configmap-ca-central-1
            url: eks-cluster-3
            region: ca-central-1
            environment: qa
      template:
        metadata:
          name: '{{prefix}}'
        spec:
          project: teleport
          source:
            repoURL: url-repo
            targetRevision: initial-testing
            path: deploy/argocd/config/teleport/{{region}}
          destination:
            server: '{{url}}'
            namespace: teleport
          syncPolicy:
            automated:
              prune: true
              selfHeal: true
            syncOptions:
              - CreateNamespace=true
    
  • requeueAfterSeconds was incorrectly placed

    requeueAfterSeconds was incorrectly placed

    When I run the example, I get an error because requeueAfterSeconds is misplaced. When I moved like the PR then it worked, so I am assuming is not in the correct place in docs.

Related tags
Notifications for Argo CD
Notifications for Argo CD

Argo CD Notifications Argo CD Notifications continuously monitors Argo CD applications and provides a flexible way to notify users about important cha

Nov 27, 2022
Automatic container image update for Argo CD

Argo CD Image Updater Introduction Argo CD Image Updater is a tool to automatically update the container images of Kubernetes workloads which are mana

Dec 25, 2022
A Kubernetes operator for managing Argo CD clusters.

Argo CD Operator A Kubernetes operator for managing Argo CD clusters. Documentation See the documentation for installation and usage of the operator.

Dec 14, 2022
Support for extending Argo CD

Argo CD Extensions To enable Extensions for your Argo CD cluster will require just a single kubectl apply. Here we provide a way to extend Argo CD suc

Dec 20, 2022
Argo-CD Autopilot
Argo-CD Autopilot

Introduction New users to GitOps and Argo CD are not often sure how they should structure their repos, add applications, promote apps across environme

Jan 6, 2023
Hera is a Python framework for constructing and submitting Argo Workflows.

Hera is an Argo Workflows Python SDK. Hera aims to make workflow construction and submission easy and accessible to everyone! Hera abstracts away workflow setup details while still maintaining a consistent vocabulary with Argo Workflows.

Dec 31, 2022
A series of controllers for configuring namespaces to accomodate Argo

argo-controller A series of controllers for configuring namespaces to accomodate Argo. ArgoCD TBD Argo Workflows Make a service account in every names

Jan 4, 2022
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes.
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes.

What is Argo Workflows? Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Argo Workflow

Dec 10, 2021
Argo Rollout visualization in Argo CD Web UI
Argo Rollout visualization in Argo CD Web UI

Rollout Extension The project introduces the Argo Rollout dashboard into the Argo CD Web UI. Quick Start Install Argo CD and Argo CD Extensions Contro

Dec 29, 2022
Image clone controller is a kubernetes controller to safe guard against the risk of container images disappearing

Image clone controller image clone controller is a kubernetes controller to safe guard against the risk of container images disappearing from public r

Oct 10, 2021
A Controller written in kubernetes sample-controller style which watches a custom resource named Bookstore

bookstore-sample-controller A Controller written in kubernetes sample-controller style which watches a custom resource named Bookstore. A resource cre

Jan 20, 2022
Automating Kubernetes Rollouts with Argo and Prometheus. Checkout the demo URL below
Automating Kubernetes Rollouts with Argo and Prometheus. Checkout the demo URL below

observe-argo-rollout Demo for Automating and Monitoring Kubernetes Rollouts with Argo and Prometheus Performing Demo The demo can be found on Katacoda

Nov 16, 2022
A plugin for argo which behaves like I'd like

argocd-lovely-plugin An ArgoCD plugin to perform various manipulations in a sensible order to ultimately output YAML for Argo CD to put into your clus

Dec 27, 2022
Simple example using Git actions + Argo CD + K8S + Docker and GO lang

CICD-simple_example Simple example using Git actions + Argo CD + K8S + Docker and GO lang Intro Pre reqs Have an ArgoCD account and Installed. Docker

Oct 28, 2021
Notifications for Argo CD
Notifications for Argo CD

Argo CD Notifications Argo CD Notifications continuously monitors Argo CD applications and provides a flexible way to notify users about important cha

Nov 27, 2022
Automatic container image update for Argo CD

Argo CD Image Updater Introduction Argo CD Image Updater is a tool to automatically update the container images of Kubernetes workloads which are mana

Dec 25, 2022
A Kubernetes operator for managing Argo CD clusters.

Argo CD Operator A Kubernetes operator for managing Argo CD clusters. Documentation See the documentation for installation and usage of the operator.

Dec 14, 2022
Support for extending Argo CD

Argo CD Extensions To enable Extensions for your Argo CD cluster will require just a single kubectl apply. Here we provide a way to extend Argo CD suc

Dec 20, 2022
Argo-CD Autopilot
Argo-CD Autopilot

Introduction New users to GitOps and Argo CD are not often sure how they should structure their repos, add applications, promote apps across environme

Jan 6, 2023
Hera is a Python framework for constructing and submitting Argo Workflows.

Hera is an Argo Workflows Python SDK. Hera aims to make workflow construction and submission easy and accessible to everyone! Hera abstracts away workflow setup details while still maintaining a consistent vocabulary with Argo Workflows.

Dec 31, 2022