Self-managed install & maintenance > Install and config > Advanced config > Networking & infrastructure > Deploy with ArgoCD

Deploy with ArgoCD¶

ArgoCD is a declarative, Kubernetes-native Continuous Delivery (CD) tool that follows the GitOps paradigm. For more info see: ArgoCD Official Documentation

概要¶

ArgoCD continuously performs a reconciliation loop:

Monitor: ArgoCD watches the defined Git repository (the Target State).
Compare: It compares the configuration in the Git repository to the actual running configuration in the Kubernetes cluster (the Live State).
Sync/Heal: If a difference (a "drift") is detected, ArgoCD either alerts the user or automatically applies the necessary changes to make the Live State match the Target State. This ensures the cluster is self-healing and always conforms to the desired configuration.

This approach is highly suitable for deploying complex, multi-component applications like DataRobot, as it automates deployment and ensures environmental consistency.

前提条件¶

Before starting, ensure the following are in place:

A running Kubernetes Cluster meeting requirements for your installation.
ArgoCD is installed and running in the cluster.
Kubectl configured to interact with the cluster.
Access to the private repository containing the official DataRobot Container Images and Helm charts.
Required configuration variables.
Prepared DataRobot platform Helm values.

ArgoCD application definition¶

Create an ArgoCD Application definition file datarobot-platform.yaml. This file defines the target cluster, the source repository, and the Helm parameters.

Here is an example datarobot-platform.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: datarobot-platform
  namespace: ARGOCD_NAMESPACE
spec:
  project: default
  destination:
    server: https://kubernetes.default.svc
    namespace: DATAROBOT_NAMESPACE
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
    ignoreDifferences:
      - group: apps
        kind: Deployment
        jsonPointers:
          - /spec/replicas
      - group: apps
        kind: StatefulSet
        jsonPointers:
          - /spec/replicas
  source:
    repoURL: registry-1.docker.io
    targetRevision: X.X.X
    chart: datarobotdev/datarobot-prime
    helm:
      valuesObject:
        ...

Make sure to populate valuesObject with the DataRobot platform values suitable for your environment.

Replace ARGOCD_NAMESPACE with your ArgoCD namespace.
Replace DATAROBOT_NAMESPACE with your DataRobot namespace.
Replace X.X.X with the latest release chart version.

Fresh installs and PostgreSQL upgrade hooks

The bundled PostgreSQL upgrade automation uses Helm pre-upgrade hooks, which ArgoCD runs during the PreSync phase of every sync—including the first sync of a fresh install. On a fresh install, this deadlocks against PostgreSQL resources that do not exist yet. For a fresh ArgoCD install, set pg-upgrade.runUpgradeHooks: false in valuesObject. Leave it at the default (true) for upgrades. See ArgoCD fresh installs for details.

Auth server system secrets

ArgoCD uses helm template to render the DataRobot Helm chart. Because helm template can't read from the cluster, the rendered manifests don't include the auth-server-system-secrets Secret. Instead, the auth server creates it the first time it starts:

The hydra-keys init container generates random secretsSystem and secretsCookie keys.
If auth-token-customization.hydra.fips.enabled is true, it also generates a secretsPagination key.
It never overwrites a key that already exists, so upgrades keep the installation's existing keys.

To manage the keys yourself instead of using DataRobot automation, use one of these options:

Create the auth-server-system-secrets Secret yourself before the first sync. This keeps the keys out of your values file.
Supply the Secret through External Secrets. When an external secret store is enabled, the DataRobot Helm chart creates an ExternalSecret named auth-server-system-secrets. That ExternalSecret reads the store key of the same name. In this setup, the auth-token-customization.hydra.secret.* keys are ignored. For details, see Auth server system secrets.
Set both keys in valuesObject. Generate each as a long random value once, and store them securely:

auth-token-customization:
  hydra:
    secret:
      secretsSystem: <randomValue>
      secretsCookie: <randomValue>

Set both keys or neither. If you set only one, the Helm render fails. If auth-token-customization.hydra.fips.enabled is true, also set auth-token-customization.hydra.secret.secretsPagination. To stop the auth server from creating the Secret in the cluster, set auth-token-customization.hydra.secret.generateInCluster to false.

When upgrading: Keep the keys the installation already uses. Setting different values replaces them, which invalidates data the auth server has already encrypted. Before you sync, annotate the existing Secret with argocd.argoproj.io/sync-options: Prune=false so that ArgoCD does not prune it. If the Secret is missing from an installation where the auth server has already run, the hydra-keys init container does not create replacement keys, and the auth server pod waits in its init phase until the Secret is restored.

An existing ArgoCD installation may still hold the shared default keys from an earlier release. To check and rotate them, see Rotate auth server system secrets.

ArgoCD self-heal¶

Certain DataRobot platform resources can be manually scaled by an administrator or an autoscaler (like the Horizontal Pod Autoscaler - HPA) after the initial deployment. If ArgoCD isn't configured to ignore these manual changes, it detects the discrepancy between the desired and the live states in the cluster and try to "self-heal" by reverting the replica counts back.

To prevent this unwanted behaviour, you must configure ArgoCD to ignore differences for specific fields, allowing operational flexibility without compromising the overall control plane.

Make sure following snipped exist in the ArgoCD Application definition for the DataRobot platform.

spec:
  syncPolicy:
    ignoreDifferences:
      - group: apps
        kind: Deployment
        jsonPointers:
          - /spec/replicas
      - group: apps
        kind: StatefulSet
        jsonPointers:
          - /spec/replicas