instruction: How do you implement GitOps workflows with ArgoCD and Kustomize?
output: Best Practices - Argo CD - Declarative GitOps CD for Kubernetes Skip to content Argo CD - Declarative GitOps CD for Kubernetes Best Practices Initializing search GitHub Argo CD - Declarative GitOps CD for Kubernetes GitHub Overview Understand The Basics Core Concepts Getting Started Operator Manual Operator Manual Overview Architectural Overview Installation Feature Maturity Argo CD Core Declarative Setup Applications in any namespace Ingress Configuration High Availability High Availability Overview Dynamic Cluster Distribution User Management User Management Overview Auth0 Microsoft Okta OneLogin Keycloak OpenUnison Google Zitadel Identity Center (AWS SSO) RBAC Configuration Security Security Overview Snyk Scans Verification of Argo CD Artifacts TLS configuration Cluster Management Cluster Bootstrapping Secret Management Disaster Recovery Reconcile Optimization Git Webhook Configuration Resource Health Resource Actions Custom Tooling Custom Styles UI Customization Metrics Web-based Terminal Config Management Plugins Deep Links Notifications Notifications Overview Triggers Templates Functions Triggers and Templates Catalog Monitoring Subscriptions Troubleshooting Troubleshooting commands Troubleshooting errors Examples Notification Services Notification Services Alertmanager AWS SQS Email GitHub Google Chat Grafana Mattermost NewRelic Opsgenie Overview PagerDuty PagerDuty V2 Pushover Rocket.Chat Slack Teams Telegram Webex Teams Webhook Troubleshooting Tools ApplicationSet ApplicationSet Introduction Installations Use Cases Security How ApplicationSet controller interacts with Argo CD Generators Generators Generators List Generator Cluster Generator Git Generator Matrix Generator Merge Generator SCM Provider Generator Cluster Decision Resource Generator Pull Request Generator Post Selector all generators Plugin Generator Template fields Template fields Templates Go Template Controlling Resource Modification Application Pruning & Resource Deletion Progressive Syncs Git File Generator Globbing ApplicationSet Specification Reference ApplicationSet in any namespace Server Configuration Parameters Server Configuration Parameters argocd-server Command Reference argocd-application-controller Command Reference argocd-repo-server Command Reference argocd-dex Command Reference Additional configuration method Upgrading Upgrading Overview v2.14 to 3.0 v2.13 to 2.14 v2.12 to 2.13 v2.11 to 2.12 v2.10 to 2.11 v2.9 to 2.10 v2.8 to 2.9 v2.7 to 2.8 v2.6 to 2.7 v2.5 to 2.6 v2.4 to 2.5 v2.3 to 2.4 v2.2 to 2.3 v2.1 to 2.2 v2.0 to 2.1 v1.8 to 2.0 v1.7 to 1.8 v1.6 to 1.7 v1.5 to 1.6 v1.4 to 1.5 v1.3 to 1.4 v1.2 to 1.3 v1.1 to 1.2 v1.0 to 1.1 Project Specification Reference User Guide User Guide Overview Tools Kustomize Helm OCI Importing Argo CD go packages Jsonnet Directory Tool Detection Projects Private Repositories Plugins Multiple Sources for an Application GnuPG verification Automated Sync Policy Diffing Diffing Diff Strategies Diff Customization Orphaned Resources Monitoring Compare Options Sync Options Parameter Overrides Environment Variables Build Environment Tracking and Deployment Strategies Resource Tracking Resource hooks Selective Sync Sync Phases and Waves Sync Windows Sync Applications with Kubectl Skip Application Reconcile Generating Applications with ApplicationSet Automation from CI Pipelines App Deletion Best Practices Best Practices Table of contents Separating Config Vs. Source Code Repositories Leaving Room For Imperativeness Ensuring Manifests At Git Revisions Are Truly Immutable Status Badge Add external URL Add extra Application info Notification subscriptions Annotations and Labels used by Argo CD Command Reference Application Specification Reference Developer Guide Developer Guide Overview Development Environment Development Cycle Submit Your PR Architecture Architecture Authentication and Authorization Component Architecture Code Contribution Guide Toolchain Guide MacOS users Release Process And Cadence Running Argo CD locally Debugging a local Argo CD instance Debugging a Remote ArgoCD Environment API Docs E2E Tests Managing Dependencies Continuous Integration (CI) Releasing Documentation Site Static Code Analysis Extensions Extensions UI Extensions Proxy Extensions Contribution FAQ Tilt Development FAQ Security Considerations Support Roadmap Releases ⧉ Blog ⧉ Table of contents Separating Config Vs. Source Code Repositories Leaving Room For Imperativeness Ensuring Manifests At Git Revisions Are Truly Immutable Best Practices &para; Separating Config Vs. Source Code Repositories &para; Using a separate Git repository to hold your Kubernetes manifests, keeping the config separate from your application source code, is highly recommended for the following reasons: It provides a clean separation of application code vs. application config. There will be times when you wish to modify just the manifests without triggering an entire CI build. For example, you likely do not want to trigger a build if you simply wish to bump the number of replicas in a Deployment spec. Cleaner audit log. For auditing purposes, a repo which only holds configuration will have a much cleaner Git history of what changes were made, without the noise coming from check-ins due to normal development activity. Your application may comprise services built from multiple Git repositories, but is deployed as a single unit. Oftentimes, microservices applications comprise services with different versioning schemes, and release cycles (e.g. ELK, Kafka + ZooKeeper). It may not make sense to store the manifests in one of the source code repositories of a single component. Separation of access. The developers who are developing the application, may not necessarily be the same people who can/should push to production environments, either intentionally or unintentionally. By having separate repos, commit access can be given to the source code repo, and not the application config repo. If you are automating your CI pipeline, pushing manifest changes to the same Git repository can trigger an infinite loop of build jobs and Git commit triggers. Having a separate repo to push config changes to, prevents this from happening. Leaving Room For Imperativeness &para; It may be desired to leave room for some imperativeness/automation, and not have everything defined in your Git manifests. For example, if you want the number of your deployment's replicas to be managed by Horizontal Pod Autoscaler , then you would not want to track replicas in Git. apiVersion : apps/v1 kind : Deployment metadata : name : nginx-deployment spec : # do not include replicas in the manifests if you want replicas to be controlled by HPA # replicas: 1 template : spec : containers : - image : nginx:1.7.9 name : nginx ports : - containerPort : 80 ... Ensuring Manifests At Git Revisions Are Truly Immutable &para; When using templating tools like helm or kustomize , it is possible for manifests to change their meaning from one day to the next. This is typically caused by changes made to an upstream helm repository or kustomize base. For example, consider the following kustomization.yaml resources : - github.com/argoproj/argo-cd//manifests/cluster-install The above kustomization has a remote base to the HEAD revision of the argo-cd repo. Since this is not a stable target, the manifests for this kustomize application can suddenly change meaning, even without any changes to your own Git repository. A better version would be to use a Git tag or commit SHA. For example: bases : - github.com/argoproj/argo-cd//manifests/cluster-install?ref=v0.11.1 Previous App Deletion Next Status Badge Made with Material for MkDocs