Argo CD Sync Policies and Options

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. It follows the GitOps pattern of using git repositories as the source of truth for defining the desired application state. Which says, we no need setup complex CI/CD pipeline with multiple tools or wring any complex scripting/coding, As Argo CD, just monitor your GIT repo directly and detect the change and then deploys directly to destination server. With that, we no need to manage any complex CI tools in our eco-system, having said, still there need more maturity required on this, but this can be a future.

So far, we have seen about Argo CD application deployment, projects and CLI tools with some strategies. In this will see another key feature on the ArgoCD nothing but sync policies and options available on it.

Sync Options

What is sync option? It’s nothing but just configuring your application follow what to do when or simplifying some risk into out own way. As we are still in earlier stage of adopting GitOps some resources we may require to track on our way, rather just apply as it is, or should have some restriction to avoid any manual changes or effects. To achieve that, ArgoCD provides two sync policies, those are Manual and Automatic sync policy.

Here the name itself tells the story, manual nothing but perform everything manually and automatic, let Argo CD takes care of it. This just simple to understand, but we are cannot let ArgoCD to allow everything, as we still need to keep some resources on control. Let’s see what are option we can enable with Automated policy. You can even watch this topic on our youtube.

Automated Sync Policy

Automated sync policy, simplifies our manual effect or developers, as they can just push the code to desired branch or folder, and then Argo CD takes care the deployment. This is so simple, but still there is some complex part has to be done, for that you may need to plan the automation very details.

Why? Let’s assume, or we should not think, just pushing the code to GIT is enough it will take care all, as it has other side of requirement or flow still, nothing but code scan or security scan. We cannot skip or avoid the security or code coverage etc. So those should be planned well for required path or folder or branch. Once all these steps done, then it has to place it one desired location and then we should handover to ArgoCD. Okay, let’s not go deep into this now, but we will be speaking about this in coming posts.

With Automatic sync, you can just perform the deployment without even login to the tools, only think we should make sure, its file should be placed on desired location. You can do this via your CI tools or developer or etc.

When you say automatic, it contains few additional options even, just assume we have just enabled to automated sync, in that case, ArgoCD just compare the desired state again live state for every 3min, and if it found any change on GIT, immediately it applies. You can enable this via declarative way or CLI or even UI.

Declarative:

  syncPolicy:
    automated:  {}

ArgoCD CLI:

--auto-sync

Automated Pruning

Default : When automated sync enabled, by default it won’t delete any resources when argocd detects the resources is no longer defined in Git.

Pruning can be enabled to delete resources automatically as part of the automated sync.

Declarative:

syncPolicy:
    automated: 
       prune: true

CLI:

# argocd app create helm-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path helm-guestbook --dest-server https://kubernetes.default.svc --dest-namespace argohelmtest  --auto-prune

Self-Healing

By default, changes that are made to the live cluster will not trigger automated sync.

Argo CD has a feature to enable self-healing when the live cluster state deviates from Git State.

Declarative:

  syncPolicy:
    automated: 
       selfHeal: true

CLI:

# argocd app create helm-guestbook --repo  https://github.com/argoproj/argocd-example-apps.git --path helm-guestbook --dest-server https://kubernetes.default.svc --dest-namespace argohelmtest  --self-heal

No Prune – Specific Resources

Let’s assume you decide not to prune some resource, even if you enabled auto-pruning. How? You can declare this directly on the resource manifest, as below in annotation.

metadata:
  annotations:
    argocd.argoproj.io/sync-options: Prune=false

When you do so, even if the file gets deleted on the GIT, that resource will be still available on the argoCd and Cluster. If you decide to delete, you may need to delete it manually in argo CD UI or cluster.

Disable Kubectl Validation

Some cases we may need to make the changes manually on some objects, and it should be synced as it, and need to maintain for some time. In that case you can disable the validation and keep it. For that you can add the annotation to resource manifest.

metadata:
  annotations:
    argocd.argoproj.io/sync-options: Validate=false

Selective Sync

Currently when syncing using auto sync ArgoCD applies every object in the application. For applications containing thousands of objects this takes quite a long time and puts undue pressure on the api server. Turning on selective sync option which will sync only out-of-sync resources. You can add this option by following ways, Add ApplyOutOfSyncOnly=true in manifest

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  syncPolicy:
    syncOptions:
    - ApplyOutOfSyncOnly=true

Prune Last

This feature is to allow the ability for resource pruning to happen as a final, implicit wave of a sync operation, after the other resources have been deployed and become healthy, and after all other deployments completed successfully.

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  syncPolicy:
    syncOptions:
    - PruneLast=true

This can also be configured at individual resource level.

metadata:
  annotations:
    argocd.argoproj.io/sync-options: PruneLast=true

Replace Resource

By default, ArgoCD executes kubectl apply operation to apply the configuration stored in Git. In some cases, kubectl apply is not suitable. For example, resource spec might be too big and won’t fit into kubectl.kubernetes.io/last-applied-configuration annotation that is added by kubectl apply. In such cases you might use Replace=true sync option:

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  syncPolicy:
    syncOptions:
    - Replace=true

If the Replace=true sync option is set the ArgoCD will use kubectl replace or kubectl create command to apply changes.

This can also be configured at individual resource level.

metadata:
  annotations:
    argocd.argoproj.io/sync-options: Replace=true

Fail the sync if a shared resource is found

By default, ArgoCD will apply all manifests found in the git path configured in the Application regardless if the resources defined in the yamls are already applied by another Application. If the FailOnSharedResource sync option is set, ArgoCD will fail the sync whenever it finds a resource in the current Application that is already applied in the cluster by another Application.

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  syncPolicy:
    syncOptions:
    - FailOnSharedResource=true

Hope this is useful, Please keep follow to get similar post.

You can follow us on social media, to get some short knowledges regularly.

• Facebook: https://www.facebook.com/foxutech/
• Instagram: https://www.instagram.com/foxutech/
• YouTube: https://www.youtube.com/c/FoxuTech/
• Twitter: https://twitter.com/foxutech
• Medium: FoxuTech – Medium