Insights

10 ArgoCD Best Practices

If you're using ArgoCD to manage your Kubernetes deployments, here are 10 best practices to follow.

ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes. ArgoCD follows the GitOps model of using Git repositories as the source of truth for declarative infrastructure and applications. ArgoCD is designed to provide a simple and concise way to manage deployments on Kubernetes.

In this article, we will discuss 10 best practices for using ArgoCD. These best practices will help you get the most out of ArgoCD and help you avoid common pitfalls.

1. Use a single Git repository per project

When you have multiple Git repositories for a single project, it can be difficult to keep track of which changes need to be deployed to which environment. This can lead to confusion and errors when trying to deploy your code.

By using a single Git repository per project, you can easily track which changes need to be deployed to which environment. This will make your life much easier when it comes time to deploy your code.

2. Use ArgoCD to deploy your application to multiple environments

When you’re developing an application, it’s important to have a development, staging, and production environment. This allows you to test your code in a safe environment before it goes live.

ArgoCD makes it easy to deploy your code to multiple environments. Simply create a new Git branch for each environment, and ArgoCD will automatically deploy your code to that environment.

This is a great way to ensure that your code works in all environments, and it also makes it easy to rollback changes if something goes wrong.

3. Create an environment-specific configuration for each environment

When you have a single, shared configuration file for all environments, it’s very easy to accidentally make a change that gets deployed to production when you meant to deploy it to staging. This can cause major problems, and is easily avoided by using a separate configuration file for each environment.

It’s also a good idea to use ArgoCD’s “promote” command to promote changes from one environment to the next, rather than making changes directly in the target environment. This way, you can test changes in lower environments before they get deployed to production.

4. Use Helm charts with ArgoCD

Helm charts are a great way to package and deploy applications, and they work well with ArgoCD. ArgoCD can deploy Helm charts from any Git repository, and it will automatically generate the necessary manifests for the chart.

This is a great way to get started with ArgoCD, and it can save you a lot of time when deploying applications.

5. Use the same image tag across all environments

When you use the same image tag across all environments, you can be confident that the code you’re deploying to production is the same code that was tested in staging. This way, you can avoid the “but it worked on my machine” problem.

If you use different image tags for each environment, there’s a risk that the code deployed to production is not the same code that was tested in staging. This can lead to unexpected bugs and errors in production, which can be costly and time-consuming to fix.

So, to avoid this problem, always use the same image tag across all environments. This will help ensure that the code you deploy to production is the same code that was tested and approved in staging.

6. Avoid using ArgoCD’s sync policy in production

The sync policy is a powerful feature that allows you to automatically sync your local changes with the remote cluster. However, this feature is not meant to be used in production, as it can lead to data loss and other unexpected side effects.

If you need to use the sync policy in production, make sure to understand the risks involved and take appropriate precautions, such as making regular backups of your data.

7. Use Argo Rollouts instead of ArgoCD’s sync policy

ArgoCD’s sync policy is very powerful, but it can also be very dangerous. The sync policy allows you to specify that ArgoCD should automatically sync your changes to the server, without any manual intervention. This is great for making sure that your changes are always up-to-date, but it can also lead to problems if you make a mistake in your configuration.

For example, suppose you accidentally delete a critical file from your repository. If you have the sync policy enabled, ArgoCD will automatically delete the file from the server, without any warning. This can obviously lead to serious problems.

The Argo Rollouts feature is designed to prevent this type of problem. With Argo Rollouts, you can specify that ArgoCD should create a new rollout whenever you make a change to your configuration. This gives you a chance to review the changes before they are applied to the server, and it also allows you to roll back changes if something goes wrong.

Overall, we believe that the Argo Rollouts feature is a much safer way to use ArgoCD, and we recommend that you use it instead of the sync policy.

8. Don’t use ArgoCD to manage secrets

The main reason is that ArgoCD is a declarative GitOps tool, meaning that it relies on Git for its configuration management. This means that any secrets stored in the Git repository would be exposed to anyone with access to the repository.

A better way to manage secrets is to use a dedicated secrets management tool, such as Hashicorp Vault, and then integrate it with ArgoCD. This way, you can keep your secrets safe and secure while still using ArgoCD for your deployments.

9. Use Kustomize and overlays to manage environment-specific configurations

When you have multiple environments that need to share a common configuration base, it’s important to be able to manage them in a way that keeps the configurations separate and consistent. Kustomize allows you to do this by creating “overlays” for each environment that overlay the shared configuration.

This approach has several benefits. First, it ensures that all of the configurations for an environment are stored together in one place. Second, it makes it easy to see what configurations are different between environments. And finally, it makes it easy to apply changes to an entire environment by simply updating the overlay.

ArgoCD also provides a number of other features that can help with managing environment-specific configurations, including the ability to target specific namespaces and the ability to promote configurations from one environment to another.

10. Use ArgoCD’s CLI to troubleshoot issues

The ArgoCD CLI is a powerful tool that can help you quickly identify and fix problems with your deployments. By using the CLI, you can get detailed information about your deployment status, as well as access to logs and other debugging information.

This is especially useful when you’re trying to troubleshoot a problem that’s not immediately apparent. For example, if you see that a deployment is failing, but you’re not sure why, the CLI can help you investigate the issue further.

To use the CLI, simply run the argocd command with the desired subcommand. For example, to get detailed information about a deployment, you would run:

argocd deploy info

You can also use the CLI to manage your ArgoCD installation, such as creating and deleting projects, managing users, and more.

Previous

10 REST API Payload Size Best Practices

Back to Insights
Next

10 Python Config File Best Practices