Are you looking for the ultimate productivity tips for ArgoCD? Check out our proven techniques to get the most out of ArgoCD.
For many ArgoCD is the definition of a modern GitOps tool. Created by Inuit a financial services company, donated to the open source community. It is extensively used across many industries, especially regulated ones. At CWISE we early majority adopters of ArgoCD, since 2019. Since then we have gained a lot of experience being effective operators. Here we will share some tips and tricks
Application Deployment Ordering using SyncWaves and InitContainers
Complexity to implement: medium
Let's assume your application consists of multiple app deployments or even multiple helm charts. In order to successfully to deploy, there is needed to orchestrate deployment order.
In these cases, there are two techniques that we at CWISE use extensively:
Using ArgoCD Syncwaves and phases, to orchestrate resource creation within the same context (such as an application)
Using initContainers, to test if desired internal Kubernetes cluster endpoints (like application for backend) or external (like database is available)
- name: wait-backend
image: busybox
command: ['sh', '-c', 'echo -e "Checking backend port availability"; while ! nc -z {{ .Values.appBackend.url }} 443; do sleep 1; printf "-"; done; echo -e " >> Backend port available";']
Linking External URLs from ArgoCD
Complexity to implement: easy
Imagine a situation when you need to do fast troubleshooting for a gone-wrong deployment. Have you counted how many unnecessary steps you need to take before an appropriate monitoring dashboard or logging data set is found?
ArgoCD provides the ability to embed external links in resources via annotation
Scenarios where we find this functionality is valuable:
Linking directly to application logging data sets;
Connecting to application monitoring dashboards and alert manager;
Links to knowledge base articles and runbooks about the application;
Links to other external systems like CI/CD systems or service mesh management like Kiali
How to use this functionality: 1. Add annotation for resource:
annotations:
link.argocd.argoproj.io/external-link: http://my-grafana.example.com/pre-generated-link
Redeploy and access link
Web-based Terminal in ArgoCD UI
Complexity to implement: easy-medium
You are a DevOps or platform engineer. Your supported development team needs access to the Kubernetes pods in the test environment. You can go the hard route by configuring Kubernetes credentials, roles, and rolebindings. Or use ArgoCD. that provides out-of-the-box with a web-based terminal available, to access the pod via UI
Scenarios where we find this functionality is valuable:
Enabling access to preview and dev environments for troubleshooting connectivity and functionality. However, we advise not to turn on this functionality in the production environment, as it can pose security risks if not locked down.
How to enable web terminal in ArgoCD:
configs:
cm:
exec.enabled: true[Optional] Prepare ArgoCD permissions for group to use terminal
p, role:myrole, exec, create, */*, allow[Optional] Assign roles to dev team
Extending ArgoCD via Custom Resource Actions and Resource Health
Complexity to implement: medium-hard
Let's say that you want to free up your time from small and safe operational tasks, but repetitive tasks, by providing self-service for your colleagues. Or improve application health checks to detect failures before it happen. ArgoCD provides an option to extend it functionality
Scenarios where we find this functionality is valuable:
Better alerting and detection via custom application health scripting.
Providing self-service options for other teams. Such as creating one-off Kubernetes jobs from a cronjob or refreshing external secrets object
Reducing exposure to low-level access to Kubernetes for standard operations tasks such as restart of deployment
How to implement custom actions and resource health:
Useful resources:
ArgoCD Infrastructure As A Code Configuration
Complexity to implement: medium
Managing one ArgoCD or one central is pretty easy, but when there are more than x instances, complexity grows rapidly. Like managing at multiple instances, backups, and change tracking.
Configuration as A Code is a first-class citizen for ArgoCD, as it was designed as a stateless system.
Scenarios where we find this functionality is valuable:
General configuration such as configuring RBAC and SSO
dex.config: |
connectors:
- type: ${platform}
id: ${platform}
name: ${platform == "github" ? "GitHub" : "bitbucket"}
config:
clientID: ${clientID}
clientSecret: ${clientSecret}
redirectURI: https://${subdomain}.${domain}/api/dex/callback
scopes:
- email
- account
orgs:
- name: ${github_org} Repository configs and all other related things (this example is done via Terraform):
resource "kubernetes_secret" "argoproj-https-creds-github-template" {
metadata {
name = "argoproj-https-creds-bitbucket-template"
namespace = var.argocd_namespace
labels = {
"argocd.argoproj.io/secret-type" = "repo-creds"
}
}
data = {
url = "https://bitbucket.org/nctek"
type = "git"
username = var.argocd_bitbucket_repo_creds_user
password = var.argocd_bitbucket_repo_creds_pass
}
}Providing backup and recovery for ArgoCD server fleets
Automatic Deployment/StatefulSet Restart Orchestration via Reloader
Complexity to implement: medium
Consider a scenario in ArgoCD where we need to restart applications deployed via DeploymentConfigs, Deployments, DaemonSets, and StatefulSets when the secret or config map is changed.
We use Reloader to provide such capabilities. Available community and enterprise version
Scenarios where we find this functionality is valuable:
Orchestrating DeploymentConfigs, Deployments, DaemonSets, and StatefulSets restarts after config map or secret changes
How to implement reloader:
Install reloader via helm chart LINK
Add annotations to objects within the deployment scope
Thank you for reading! Let us know if we can help you with your GitOps implementation