Skip to content

ArgoCD

We use ArgoCD to deploy backend services to AKS. Below is a short overview.

Application Hierarchy

  • rootapp: Parent application that nests the remaining resources.

    - rootapp-applications

      - bank-accountstatements
  - bank-bitso
  - ... many more

    - rootapp-configmaps

      - bank-configuration
  - cde-configuration
  - moneyflow-configuration
  - risk-configuration

    - rootapp-networkpolicy

      - minority-networkpolicy

      - One Netpol for each non-cde backend app

  - minority-cde-network-policy
  - ... many more

Overview of a Backend Application

Manifest sources (for backend applications):

  • Latest master branch of majority-dev/be-deployments:

    - stage-values.yaml or prod-values.yaml from the app-specific folder.
    - Relevant template files from the Base-Helm-Chart/minority-app folder.

  • values.yaml from the latest master branch of the specific area, e.g majority-dev/be-sms in the charts folder.

Types of resources

  • Ingress: Handles traffic from the ingress into the services.
  • Service: An endpoint that other applications use to connect to this application. Will route to a specific pod.
  • Deploy/Deployment:

    - Pods: Instances of an application.

  • CronJob: Jobs that run on a schedule.

Useful info

  • On the Pod

    - Created at: When this pod started.
    - Image: What docker image is running.
    - Logs: Services normally log to both Elastic and the console. Note that console logs sometimes contain entries that never reached Elastic.
    - Name: Name of this pod. Note that this is also logged in Elastic/Kibana as "podName".
    - Resource limits & requests: How much CPU and memory does it use normally (requests), and what are the upper limits (limits).
    - PodIP: IP of the pod. With this you can, for example, find the pod's connection to Rabbit (which node it's connected to, etc.).

  • On CronJob

    - Schedule: When this job runs.

Common Actions

  • Deploy Restart: Restart (create new pods) a deployment (service).
  • Sync: Synchronize what is running with what the manifest says.
  • Redeploy: Redeploy a deployment. Note that if there are no changes, nothing happens.
  • Rollback to version: Change what version of a deployment is running to an earlier version. Note that syncing (manually invoking the sync or syncing from the GitHub pipeline) redeploys the latest version.
  • Create Job (CronJob): Run a job manually outside its normal schedule.

Syncing / updating

  • Configuration (bank-configuration etc): Autosync enabled. When a PR is merged to master, it will be deployed automatically. It is possible to speed up the syncing by pressing SYNC on the configuration application in Argo. Note, however, that dependent backend services are not restarted automatically. A backend service might not read/apply the new configuration until manually restarted.
  • New versions of backend services: Synced manually by the release pipeline in GitHub (the "Argo Sync" step). The order will be API, Service, Jobs.
  • Network policies: Autosync enabled. When a PR is merged to master, it will be deployed automatically.

Note that neither autosync nor pipeline sync will "Prune" existing resources, meaning you have to manually sync with the prune setting to clean up unused resources.