try new argo

mitchross · mitchross · commit 929cfb7ef99e · 2025-06-21T12:12:20.000-04:00
diff --git a/README.md b/README.md
@@ -159,18 +159,24 @@ kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/downloa
 ```
 
 ### 6. Install ArgoCD
+With the CRDs in place, we can now bootstrap Argo CD. This is a two-step process.
+
+**First, we deploy Argo CD itself.** This `Application` manifest tells Argo CD how to manage its own installation and upgrades directly from this Git repository. This is the "app of apps" pattern.
+
 ```bash
-# Install ArgoCD with custom configuration
-kubectl kustomize --enable-helm infrastructure/controllers/argocd | kubectl apply -f -
+# Apply the Argo CD application. It will self-manage from this point on.
+kubectl apply -f infrastructure/argocd-app.yaml
+```
 
-# Wait for ArgoCD to be ready
-kubectl wait --for=condition=available deployment -l app.kubernetes.io/name=argocd-server -n argocd --timeout=300s
+**Second, we deploy the root ApplicationSet.** This `ApplicationSet` automatically discovers and deploys all the other ApplicationSets in this repository (for infrastructure, monitoring, etc.), creating a fully GitOps-driven deployment.
 
-# Wait for CRDs to be established
-kubectl wait --for=condition=established crd/applications.argoproj.io --timeout=60s
-kubectl wait --for=condition=established crd/appprojects.argoproj.io --timeout=60s
+```bash
+# Apply the root ApplicationSet. This will deploy everything else.
+kubectl apply -f infrastructure/root-appset.yaml
 ```
 
+From this point on, every component of your cluster is managed via Git. Any changes pushed to the `main` branch will be automatically synced by Argo CD.
+
 ### 7. Configure Secret Management
 ```bash
 # Create required namespaces
@@ -196,24 +202,6 @@ kubectl create secret generic 1passwordconnect \
   --namespace external-secrets
 ```
 
-### 8. Final Deployment
-
-Deploy the three-tier structure in order:
-
-```bash
-# 1. First apply the ArgoCD projects
-kubectl apply -f infrastructure/controllers/argocd/projects.yaml -n argocd
-
-# 2. Apply infrastructure components (sync wave -2 ensures they run first)
-kubectl apply -f infrastructure/infrastructure-components-appset.yaml -n argocd
-
-# 3. Apply monitoring components (sync wave 0)
-kubectl apply -f monitoring/monitoring-components-appset.yaml -n argocd
-
-# 4. Finally, apply user applications (sync wave 1 ensures they run last)
-kubectl apply -f my-apps/myapplications-appset.yaml -n argocd
-```
-
 ### Key Deployment Features
 - Three-tier architecture separating infrastructure, monitoring, and applications
 - Sync waves ensure proper deployment order
@@ -341,10 +329,8 @@ kubectl get applicationsets -n argocd -o name | xargs -I{} kubectl patch {} -n a
 kubectl delete applicationsets --all -n argocd
 
 # Only then apply the new structure in order
-kubectl apply -f infrastructure/controllers/argocd/projects.yaml -n argocd
-kubectl apply -f infrastructure/infrastructure-components-appset.yaml -n argocd
-kubectl apply -f monitoring/monitoring-components-appset.yaml -n argocd
-kubectl apply -f my-apps/myapplications-appset.yaml -n argocd
+kubectl apply -f infrastructure/argocd-app.yaml
+kubectl apply -f infrastructure/root-appset.yaml
 ```
 
 ## 🤝 Contributing
diff --git a/bootstrap/root-appset.yaml b/bootstrap/root-appset.yaml
@@ -0,0 +1,32 @@
+apiVersion: argoproj.io/v1alpha1
+kind: ApplicationSet
+metadata:
+  name: root-applicationset
+  namespace: argocd
+spec:
+  generators:
+    - git:
+        repoURL: https://github.com/mitch-ross/k3s-argocd-proxmox.git
+        revision: HEAD
+        # Find all ApplicationSet files in the repository.
+        files:
+          - path: "**/*appset.yaml"
+  template:
+    metadata:
+      name: '{{path.basename}}-app'
+      namespace: argocd
+    spec:
+      project: default
+      source:
+        repoURL: https://github.com/mitch-ross/k3s-argocd-proxmox.git
+        targetRevision: HEAD
+        path: '{{path}}'
+      destination:
+        server: https://kubernetes.default.svc
+        namespace: argocd
+      syncPolicy:
+        automated:
+          prune: true
+          selfHeal: true
+        syncOptions:
+          - CreateNamespace=true
diff --git a/docs/argocd.md b/docs/argocd.md
@@ -26,48 +26,54 @@ graph TD
 ```mermaid
 sequenceDiagram
     participant User
-    participant ArgoCD
     participant Cluster
-    User->>Cluster: Install Initial Components (Talos bootstrapping)
-    Note over User,Cluster: talosctl bootstrap, apply configs
-    User->>Cluster: Apply ArgoCD projects
-    Note over User,Cluster: kubectl apply -f projects.yaml
-    User->>Cluster: Apply Infrastructure ApplicationSet
-    Note over User,Cluster: kubectl apply -f infrastructure-components-appset.yaml
-    Cluster->>ArgoCD: Create Infrastructure Applications
-    ArgoCD->>Cluster: Deploy Infrastructure Components (wave -2)
-    Note over ArgoCD,Cluster: Cilium, Longhorn, Cert-Manager, etc.
-    User->>Cluster: Apply Monitoring ApplicationSet
-    Note over User,Cluster: kubectl apply -f monitoring-components-appset.yaml
-    Cluster->>ArgoCD: Create Monitoring Applications
-    ArgoCD->>Cluster: Deploy Monitoring Components (wave 0)
-    Note over ArgoCD,Cluster: Prometheus, Grafana, Loki, etc.
-    User->>Cluster: Apply Applications ApplicationSet
-    Note over User,Cluster: kubectl apply -f myapplications-appset.yaml
-    Cluster->>ArgoCD: Create User Applications
-    ArgoCD->>Cluster: Deploy User Applications (wave 1)
-    Note over ArgoCD,Cluster: Media apps, AI tools, etc.
+    participant ArgoCD
+
+    User->>Cluster: 1. Apply Self-Managed ArgoCD App
+    Note over User,Cluster: kubectl apply -f infrastructure/argocd-app.yaml
+    Cluster->>ArgoCD: Creates ArgoCD Application
+    ArgoCD->>ArgoCD: Self-manages and installs/upgrades itself
+
+    User->>Cluster: 2. Apply Root ApplicationSet
+    Note over User,Cluster: kubectl apply -f infrastructure/root-appset.yaml
+    Cluster->>ArgoCD: Creates Root ApplicationSet
+    
+    ArgoCD->>ArgoCD: Discovers all *appset.yaml files
+    ArgoCD->>Cluster: Creates Infrastructure ApplicationSet
+    ArgoCD->>Cluster: Creates Monitoring ApplicationSet
+    ArgoCD->>Cluster: Creates Applications ApplicationSet
+    
+    ArgoCD->>Cluster: Syncs all applications based on waves
 ```
 
 ## 📦 Installation Steps
 
+The entire cluster bootstrap process is now handled by a two-step apply process. These are the only manual commands needed after setting up Talos and the base kubeconfig.
+
 ### 1. Install Gateway API CRDs
+This is a prerequisite for Cilium's Gateway API integration.
 ```bash
-kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/latest/download/experimental-install.yaml
+kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml
+kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/experimental-install.yaml
 ```
 
-### 2. Apply custom ArgoCD configuration
+### 2. Bootstrap Argo CD and Deploy All Applications
+First, deploy the self-managing Argo CD `Application`. This uses the "app of apps" pattern to make Argo CD manage its own installation and upgrades.
+
 ```bash
-kubectl kustomize --enable-helm infrastructure/controllers/argocd | kubectl apply -f -
+# Apply the Argo CD application. It will self-manage from this point on.
+kubectl apply -f infrastructure/argocd-app.yaml
 ```
 
-### 3. Wait for ArgoCD to be ready
+Second, deploy the `root-appset`. This single `ApplicationSet` discovers all other `ApplicationSet` manifests in the repository and deploys them automatically, respecting their defined sync waves.
+
 ```bash
-kubectl wait --for=condition=available deployment -l app.kubernetes.io/name=argocd-server -n argocd --timeout=300s
-kubectl wait --for=condition=established crd/applications.argoproj.io --timeout=60s
-kubectl wait --for=condition=established crd/appprojects.argoproj.io --timeout=60s
+# Apply the root ApplicationSet. This will deploy everything else.
+kubectl apply -f infrastructure/root-appset.yaml
 ```
 
+After these two commands, the entire cluster state is managed via Git. No further `kubectl apply` commands are needed for deployment.
+
 ## 🔧 Project Setup
 
 ArgoCD projects define permissions and boundaries for applications. Our cluster uses four main projects:
@@ -77,9 +83,11 @@ ArgoCD projects define permissions and boundaries for applications. Our cluster
 - **applications**: User workloads (media, AI, dev, privacy, etc.)
 - **ai**: Specialized AI/ML workloads
 
+These `AppProject` resources are defined in `infrastructure/controllers/argocd/projects.yaml` and are deployed automatically as part of the main `argocd` application.
+
 ## 📱 ApplicationSet Management
 
-We use three main ApplicationSets to manage our deployments:
+We use three main ApplicationSets to manage our deployments, which are discovered and applied automatically by the `root-appset`.
 
 ### 1. Infrastructure ApplicationSet
 Located at `infrastructure/infrastructure-components-appset.yaml`, this ApplicationSet manages infrastructure components like Cilium, Longhorn, Cert-Manager, and other core services. **All storage (Longhorn, local PVs, StorageClasses) is managed declaratively here.**
@@ -90,20 +98,6 @@ Located at `monitoring/monitoring-components-appset.yaml`, this ApplicationSet m
 ### 3. Applications ApplicationSet
 Located at `my-apps/myapplications-appset.yaml`, this ApplicationSet manages user applications like media servers, AI applications, and other user-facing services.
 
-## 🔢 Deployment Order
-Apply the resources in the following order:
-
-1. Apply the projects first:
-```bash
-kubectl apply -f infrastructure/controllers/argocd/projects.yaml -n argocd
-```
-2. Apply the ApplicationSets in order:
-```bash
-kubectl apply -f infrastructure/infrastructure-components-appset.yaml -n argocd
-kubectl apply -f monitoring/monitoring-components-appset.yaml -n argocd
-kubectl apply -f my-apps/myapplications-appset.yaml -n argocd
-```
-
 ## 📂 Repository Structure
 
 The repository follows a clean three-tier structure:
diff --git a/docs/network.md b/docs/network.md
@@ -291,56 +291,8 @@ sequenceDiagram
     Pod->>External: Response (reverse path)
 ```
 
-## Setup Steps
-
-### 1. Install Cilium (Infrastructure Tier)
-
-Cilium is installed via Helm as part of the infrastructure tier:
-
-```bash
-# Installing Cilium via Helm is handled automatically by the infrastructure ApplicationSet
-# The Helm chart is located at infrastructure/networking/cilium
-# You can view the values at infrastructure/networking/cilium/values.yaml
-
-# To manually install Cilium:
-helm repo add cilium https://helm.cilium.io/
-helm install cilium cilium/cilium \
-  --namespace kube-system \
-  --set kubeProxyReplacement=strict \
-  --set gatewayAPI.enabled=true \
-  --set-string extraConfig.enable-gateway-api=true \
-  --set ipam.mode=kubernetes
-
-# Verify Cilium is running
-kubectl -n kube-system get pods -l k8s-app=cilium
-```
-
-### 2. Configure CoreDNS
-```bash
-# Apply custom CoreDNS configuration
-kubectl apply -f infrastructure/networking/coredns/coredns-custom.yaml
-
-# Restart CoreDNS to apply changes
-kubectl rollout restart -n kube-system deployment coredns
-```
-
-### 3. Setup Gateways
-```bash
-# Create gateway namespace
-kubectl create namespace gateway-system
-
-# Apply gateway configurations
-kubectl apply -f infrastructure/networking/gateway/
-```
-
-### 4. Configure Cloudflare
-```bash
-# Add tunnel secrets (see external-services.md)
-kubectl apply -f infrastructure/networking/cloudflared/secrets.yaml
-
-# Deploy cloudflared tunnel
-kubectl apply -f infrastructure/networking/cloudflared/deployment.yaml
-```
+## Declarative Setup
+All components described in this document (Cilium, CoreDNS, Gateways, Cloudflare Tunnel) are deployed declaratively as part of the `infrastructure` ApplicationSet. There are no manual `helm` or `kubectl` commands required to deploy them. Their manifests are located in `infrastructure/networking/` and are automatically synced by Argo CD.
 
 ## Validation
 
diff --git a/docs/structure.md b/docs/structure.md
@@ -3,6 +3,8 @@
 ```plaintext
 .
 ├── infrastructure/           # Infrastructure components
+│   ├── argocd-app.yaml       # ArgoCD self-management Application
+│   ├── root-appset.yaml      # Root ApplicationSet to deploy all tiers
 │   ├── controllers/          # Kubernetes controllers
 │   │   └── argocd/           # ArgoCD configuration and projects
 │   ├── networking/           # Network configurations
@@ -39,25 +41,33 @@
    - Standardized application structure in each folder
 
 3. **Simplified Management**
-   - One ApplicationSet per tier
+   - A root ApplicationSet deploys one ApplicationSet per tier
    - Clear separation of concerns
    - Controlled deployment order through sync waves
 
-## ApplicationSet Organization
+## Bootstrap and ApplicationSet Organization
 
-### `/infrastructure/infrastructure-components-appset.yaml`
+This project uses a two-file bootstrap model located in the `/infrastructure` directory, followed by a set of tier-specific ApplicationSets that are discovered automatically.
+
+### Bootstrap Files
+- **`infrastructure/argocd-app.yaml`**: This is an Argo CD `Application` that manages Argo CD itself. It points to `infrastructure/controllers/argocd` to deploy the Helm chart and all its configurations, including the `AppProject` definitions. This is the "app of apps" pattern.
+- **`infrastructure/root-appset.yaml`**: This is an `ApplicationSet` that acts as the "appset of appsets". It automatically discovers and deploys all `*appset.yaml` files within the repository, effectively deploying all three tiers of the architecture.
+
+### Tier ApplicationSets
+
+#### `/infrastructure/infrastructure-components-appset.yaml`
 - Manages all infrastructure components
 - Uses infrastructure project
 - Deploys with negative sync wave (-2) to ensure it runs first
 - Pattern: `infrastructure/*/*`
 
-### `/monitoring/monitoring-components-appset.yaml`
+#### `/monitoring/monitoring-components-appset.yaml`
 - Manages all monitoring components
 - Uses infrastructure project
 - Deploys with neutral sync wave (0)
 - Pattern: `monitoring/*/*`
 
-### `/my-apps/myapplications-appset.yaml`
+#### `/my-apps/myapplications-appset.yaml`
 - Manages all user applications
 - Uses ai project (provides necessary permissions)
 - Deploys with positive sync wave (1) to ensure it runs last
diff --git a/iac/kustomize/argo-cd/README.md b/iac/kustomize/argo-cd/README.md
@@ -0,0 +1,35 @@
+# Argo CD Upgrade to v3.0
+
+This document outlines the process for upgrading Argo CD to version 3.0, including key changes, rollback procedures, and updated configurations.
+
+## Upgrade Process
+
+The upgrade is managed through GitOps by updating the Helm chart version in `infrastructure/controllers/argocd/kustomization.yaml`.
+
+1.  **Update Helm Chart**: The `version` in `kustomization.yaml` was updated to `8.1.1`, which corresponds to Argo CD application version `v3.0.6`.
+2.  **Apply Manifests**: The changes were applied by committing the updated files to the Git repository, which Argo CD then automatically syncs.
+
+## Key Changes and Resolutions
+
+### 1. RBAC Permissions
+
+-   **Change**: Argo CD v3.0 requires more explicit RBAC permissions. The `*` wildcard is no longer sufficient for many resources.
+-   **Resolution**: The `projects.yaml` file was updated to define more granular permissions for the `infrastructure`, `monitoring`, and `my-apps` projects. Wildcards were replaced with specific resource groups and kinds where possible. A `troubleshooting` role was added to the `monitoring` and `my-apps` projects to allow `exec` into pods.
+
+### 2. Resource Tracking
+
+-   **Change**: The default resource tracking method is now `annotation`.
+-   **Resolution**: The `application.resourceTrackingMethod` in `values.yaml` is set to `annotation+label` to ensure backward compatibility with existing resources.
+
+### 3. Insecure Server
+
+-   **Change**: The `server.insecure: true` flag was previously used.
+-   **Resolution**: This was initially going to be replaced with a TLS certificate, but per your request, we are continuing to use an insecure connection for now.
+
+## Rollback Procedure
+
+To roll back the upgrade, revert the changes in the Git repository. Specifically:
+
+1.  Revert the `version` in `infrastructure/controllers/argocd/kustomization.yaml` to the previous version.
+2.  Revert the changes to `infrastructure/controllers/argocd/values.yaml` and `infrastructure/controllers/argocd/projects.yaml`.
+3.  Commit and push the changes to the Git repository. Argo CD will automatically sync and roll back to the previous version. 
diff --git a/infrastructure/argocd-app.yaml b/infrastructure/argocd-app.yaml
@@ -0,0 +1,27 @@
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: argocd
+  namespace: argocd
+  # Add a finalizer to prevent this application from being accidentally deleted.
+  finalizers:
+    - resources-finalizer.argocd.argoproj.io
+spec:
+  # The 'default' project is used for managing Argo CD itself.
+  # This project is created by default by Argo CD.
+  project: default
+  source:
+    # IMPORTANT: Please verify this is the correct URL for your Git repository.
+    repoURL: https://github.com/mitch-ross/k3s-argocd-proxmox.git
+    path: infrastructure/controllers/argocd
+    targetRevision: HEAD
+  destination:
+    # Deploy to the same cluster where Argo CD is running.
+    server: https://kubernetes.default.svc
+    namespace: argocd
+  syncPolicy:
+    automated:
+      prune: true # Delete resources that are no longer defined in Git
+      selfHeal: true # Automatically sync when the live state drifts from Git
+    syncOptions:
+      - CreateNamespace=true # Create the 'argocd' namespace if it doesn't exist 
diff --git a/infrastructure/controllers/argocd/http-route.yaml b/infrastructure/controllers/argocd/http-route.yaml
diff --git a/infrastructure/controllers/argocd/kustomization.yaml b/infrastructure/controllers/argocd/kustomization.yaml
diff --git a/infrastructure/root-appset.yaml b/infrastructure/root-appset.yaml
