Application deployment

• Create Application: Once the user chooses to create an application composition project, a git repository is created for the application to maintain the application configuration for different deployment targets as part of the composite application. The configuration of each deployment target is maintained in a seperate branch with branch name as deployment target name.

• Selecting Deployment Target: Deployment is managed individually for each deployment target. choosing deployment target results in:

  1. Creates a git branch in git repository of the application to manage all the configuration of this specific deployment target. A kustomization file is created in this git branch which maintains the resources to be deployed in that target for the application.

       apiVersion: kustomize.config.k8s.io/v1beta1
       kind: Kustomization
       resources:
         - {{resource1}}.yaml
         - {{resource2}}.yaml
       patches:
         - target:
             version: v1alpha1
             kind: Application
             labelSelector: app={{applicationAcronym}}
           patch: |-
             - op: replace
               path: /spec/source/helm/parameters/0/value
               value: {{deploymentTargetHostName}}
         - target:
             version: v1alpha1
             kind: Application
             labelSelector: app={applicationAcronym}
           patch: |-
             - op: replace
               path: /spec/source/helm/parameters/4/value
               value: 'false'
         - target:
             version: v1alpha1
             kind: Application
             labelSelector: app=abatest
           patch: |-
             - op: add
               path: /metadata/finalizers
               value: ['resources-finalizer.argocd.argoproj.io/foreground']
         - target:
             version: v1alpha1
             kind: Application
             labelSelector: app={{applicationAcronym}}
           patch: |-
             - op: add
               path: /spec/syncPolicy
               value:
                 automated:
                   selfHeal: true
                   prune: true

     • resource.yaml: these are the yaml files which contain configuration of a specific component or binding which is part of the application.

     • applicationAcronym: Acronym for the application

     • deploymentTargetHostName: target hostname of the deployment target.

     • patches: Patches are used to add or override fileds in resource configuration.

  2. Creates ArgoCd Application CRD in cluster to manage the state of application in the kubernetes cluster. This application will always sync with the git repository to look for any change in the state of the application and apply that state to the cluster.

• Deploy Components: After the deployment target is selected, you can add components to the deployment target. Each component is treated as individual resource as part of the application and has a corresponding component Yaml file in the git repository which contains the configuration of the component:

  apiVersion: argoproj.io/v1alpha1
  kind: Application
  metadata:
  name: {{componentDeploymentName}}
  namespace: argocd
  labels:
      app: {{applicationAcronym}}
      type: component
  annotations:
      description: {{application component description}}
  spec:
    destination:
        namespace: {{deploymentTarget}
        server: 'https://kubernetes.default.svc'
    project: default
    source:
      repoURL: {{helmRepoUrl}}
      chart: {{componentChartName}}
      targetRevision: {{componentChartVersion}}
      helm:
        parameters:
          - name: environment.host
          value: host
          - name: label.application
          value: {{application acronym}}
          - name: image.registryPath
          value: {{deploymnt target path}}
          - name: deployment.applicationAcronym
          value: {{application acronym}}
          - name: feature.istio
          value: {{istioFlag}}
        values: '{{customConfig}}'

  • componentDeploymentName: A unique application deployment resource name. Created with combination of {{applicationAcronym}}-{{componentName}}-{{targetDeployment}}

  • applicationAcronym: Acronym for the application

  • deploymentTarget: chosen deployment target

  • helmRepoUrl: Url of the helm oci repository where component helm chart is available

  • componentChartName: Name of the helm chart of the component, same as component name

  • componentChartVersion: Verison of the helm chart to use

  • customConfig: stringified version of custom configuration.

  Once the component is added and commited to git, argoCD application created in previous step will read this component yaml file and deploy the helm chart available in source spec of the file onto the target namespace of the kubernetest cluster. Also argoCd will apply any custom configurations specified by the user in custom configuration.

• Deploy Bindings: Each Api Binding and Topic binding is treated as a single resource for deployment to the cluster. Since Bindings might contain some sensitive data, in order to protect binding data being stored directly in the git, binding resources are created in form of external secrets where only a path for the actual binding data is stored in the git repository. When an Api or Topic Bindings required for component is configured by user. Once user commits these changes to deployment target a external secret resource yaml foor each binding is created in git:

  apiVersion: k5.config/v1
  kind: K5ExternalSecret
  metadata:
    name: {{externalSecretName}}
    namespace: {{deploymentTarget}}
  spec:
    backendType: vault
    data:
      - key: {{secretDataPath}}
        name: binding
    vaultMountPoint: kubernetes
    vaultRole: external-secrets-role

  ArgoCD application reads these external secret resource files from git, and adds the cooresponding external secrets to the kubernetes cluster. Once the external secrets are available in cluster, the external secret controller will use these external secrets to fetch the secret data from the external Provider (vault). External secret controller then uses this data to create a kubernetes secrets which can be accessed by pods of the application.

Similar to adding components and bindings, if user removes any resource from the application and commits the changes to the git, argocd application with sync up with the git repository and clean up the removed resources from cluster.