The Challenge: GitOps Setup Complexity
Picture this: Your team has just been tasked with deploying a new AI/ML pipeline on your Fusion HCI cluster. You need GitOps for continuous delivery, secure secret management for API keys and credentials, and automated secret synchronization across multiple environments. Simple enough, right?
Not quite. Setting up a production-ready GitOps platform traditionally involves:
- Days of operator installations: Manually configuring GitOps, HashiCorp Vault, and External Secrets Operator
- Configuration maze: Wrestling with operator subscriptions, waiting for CRDs to become available, and debugging RBAC issues
- Storage headaches: Setting up persistent storage with appropriate performance characteristics for each component
- Integration challenges: Ensuring all components communicate securely and work together seamlessly
- Security concerns: Configuring authentication, encryption, and access control across the entire stack
- Validation uncertainty: Manually verifying that everything actually works before deploying production workloads
What if you could skip all of this complexity and deploy a complete, enterprise-grade GitOps platform with centralized secret management in the time it takes to grab a coffee?
The Solution: Fusion GitOps Quickstart
The Fusion GitOps Quickstart is a comprehensive automation toolkit designed specifically for IBM Fusion environments. It provides one-command deployment of a complete GitOps stack with production-ready defaults, eliminating weeks of configuration work and reducing the risk of misconfiguration.
Whether you're deploying AI/ML workloads, managing microservices, or orchestrating multi-cluster applications, this quickstart gets you from zero to GitOps in minutes instead of days.
What You'll Deploy
This quickstart delivers three integrated components that work seamlessly together:
🚀 GitOps (ArgoCD)
Enterprise-grade continuous delivery with declarative GitOps workflows. Deploy applications, manage configurations, and maintain consistency across environments, all from Git.
Key capabilities:
- Declarative Application Deployment: Define your entire application stack in Git and let ArgoCD handle the rest
- Automated Sync and Self-Healing: Applications automatically reconcile to match Git state
- RBAC Integration: Seamless integration with OpenShift authentication for fine-grained access control
- Multi-Environment Support: Pre-configured values files for development, staging, and production
- High Availability: Production configurations with replica sets and persistent storage
🔐 HashiCorp Vault
Industry-standard secret storage with encryption at rest and in transit. Centralize secret management across your entire infrastructure with enterprise-grade security.
Key capabilities:
- Encrypted Secret Storage: All secrets encrypted with automatic unsealing for seamless operations
- High Availability with Raft Consensus: Multi-replica deployment ensures no single point of failure
- Auto-Initialization: Automated unsealing and root token management
- Persistent Storage: Configurable storage classes for data durability
🔄 External Secrets Operator
Automatic secret synchronization from external vaults to Kubernetes secrets. Bridge the gap between centralized secret management and Kubernetes-native applications.
Key capabilities:
- Real-Time Secret Synchronization: Secrets automatically sync from Vault to Kubernetes
- GitOps-Friendly Secret References: Define ExternalSecret resources in Git without exposing sensitive data
Prerequisites
Before you begin, ensure you have:
Required
- Fusion HCI Cluster: OpenShift 4.20+ or Kubernetes 1.27+ running on Fusion HCI
- Cluster Access: Cluster admin privileges for operator installation
- CLI Tools:
oc (OpenShift CLI) or kubectl configured and authenticatedhelm 3.12+ for chart deployments
- Storage: At least one StorageClass available for persistent volumes
- Recommended:
ocs-storagecluster-ceph-rbd (OpenShift Data Foundation)
- Minimum: 10Gi available storage per component
Verify Your Environment
Run these commands to verify your environment is ready:
# Check cluster access
oc whoami
oc version
# Verify Helm installation
helm version
# List available storage classes
oc get storageclass
# Check available storage
oc get pv
Step-by-Step Deployment
Each component can be deployed independently or as part of a complete stack.
Fork and Clone the Repository
Before deploying, fork the repository at https://github.com/IBM/storage-fusion to your own GitHub account (click the Fork button on GitHub). This is essential for GitOps workflows as it allows you to customize configurations and track changes.
# Clone your fork (replace <YOUR_USERNAME> with your GitHub username)
git clone https://github.com/<YOUR_USERNAME>/storage-fusion.git
cd storage-fusion/
# Add the original repository as upstream remote
git remote add upstream https://github.com/IBM/storage-fusion.git
# Verify remotes
git remote -v
All commands should be run from the AI/quickstarts/fusion-gitops directory.
cd AI/quickstarts/fusion-gitops
Step 1: Deploy GitOps (ArgoCD)
Deploy ArgoCD as the foundation for your GitOps platform:
# Deploy with default configuration
./scripts/deploy-gitops.sh
What happens during deployment:
- Creates
openshift-gitops-operator namespace
- Installs GitOps operator
- Waits for operator to be ready
- Deploys ArgoCD instance with production-ready defaults
- Configures persistent storage for ArgoCD components
- Sets up RBAC and authentication
Monitor the Deployment
Watch the pods come up:
# Watch pod status
oc get pods -n openshift-gitops -w
Access ArgoCD UI
Get the ArgoCD server URL and admin password:
# Get ArgoCD server URL
oc get route openshift-gitops-server -n openshift-gitops -o jsonpath='{.spec.host}' && echo
# Get admin password
oc get secret openshift-gitops-cluster -n openshift-gitops \
-o jsonpath='{.data.admin\.password}' | base64 -d && echo
💡 Tip: Save these credentials securely. You'll need them to access the ArgoCD web interface.
Environment-Specific Deployments
Choose the appropriate values file for your environment:
# Development (minimal resources)
./scripts/deploy-gitops.sh -f helm/fusion-gitops/environments/dev/values.yaml
# Staging (moderate resources for pre-production testing)
./scripts/deploy-gitops.sh -f helm/fusion-gitops/environments/stage/values.yaml
# Production (HA with persistent storage)
./scripts/deploy-gitops.sh -f helm/fusion-gitops/environments/prod/values.yaml
# OpenShift Data Foundation storage
./scripts/deploy-gitops.sh -f helm/fusion-gitops/values-odf.yaml
Validate GitOps Deployment
Run the comprehensive validation script to verify your deployment:
# Run validation script
./scripts/validate-gitops.sh
Troubleshooting: If validation fails, run with verbose output:
./scripts/validate-gitops.sh --verbose
Step 2: Deploy HashiCorp Vault (Optional)
Deploy Vault for centralized secret management:
# Deploy with default configuration (3 replicas, 10Gi storage)
./scripts/deploy-secret-manager.sh
What happens during deployment:
- Creates
vault namespace
- Installs HashiCorp Vault operator
- Deploys Vault StatefulSet with Raft storage backend
- Initializes Vault and generates unseal keys
- Automatically unseals all Vault replicas
- Stores root token and unseal keys in Kubernetes secret
Monitor Vault Deployment
# Watch Vault pods
oc get pods -n vault -w
Retrieve Vault Credentials
# Get root token (store securely!)
oc get secret vault-unseal-keys -n vault \
-o jsonpath='{.data.root-token}' | base64 -d && echo
# Get unseal keys (store securely!)
oc get secret vault-unseal-keys -n vault -o yaml
⚠️ Critical Security Note: The root token and unseal keys are stored in the vault-unseal-keys secret. Back them up securely and remove from the cluster in production:
# Export unseal keys and root token
oc get secret vault-unseal-keys -n vault -o yaml > vault-keys-backup.yaml
# Store in secure location (password manager, hardware security module, etc.)
# Optional: Remove from cluster after backing up (production only)
# oc delete secret vault-unseal-keys -n vault
Environment-Specific Deployments
Choose the appropriate values file for your environment:
# Development (single replica, minimal resources, monitoring off)
./scripts/deploy-secret-manager.sh -f helm/vault-operator/environments/dev/values.yaml
# Staging (3 replicas, moderate resources, monitoring on)
./scripts/deploy-secret-manager.sh -f helm/vault-operator/environments/stage/values.yaml
# Production (3 replicas, full resources, required pod anti-affinity)
./scripts/deploy-secret-manager.sh -f helm/vault-operator/environments/prod/values.yaml
You can further override individual values on top of an environment file:
# Use a different storage class with the dev profile
./scripts/deploy-secret-manager.sh \
-f helm/vault-operator/environments/dev/values.yaml \
--storage-class ocs-storagecluster-ceph-rbd
# Use a custom storage class with the prod profile
./scripts/deploy-secret-manager.sh \
-f helm/vault-operator/environments/prod/values.yaml \
--storage-class ocs-storagecluster-ceph-rbd
Validate Vault Deployment
Run the validation script to verify Vault is operational:
# Run validation script
./scripts/validate-secret-manager.sh
Troubleshooting Multi-Replica Issues: If followers aren't joining the Raft cluster:
# Run Raft diagnostics
./scripts/diagnose-vault-raft.sh -n vault
# Run with verbose output
./scripts/diagnose-vault-raft.sh -n vault --verbose
Step 3: Deploy External Secrets Operator (Optional)
Deploy External Secrets Operator to synchronize secrets from Vault:
# Deploy operator only (no backend configuration)
./scripts/deploy-external-secrets.sh --standalone
What happens during deployment:
- Creates
external-secrets-operator namespace
- Installs External Secrets Operator
- Deploys operator, webhook, and cert-controller pods
- Installs required CRDs (ClusterSecretStore, ExternalSecret, SecretStore)
Configure Vault Backend
After deploying the operator, configure Vault as the secret backend:
# Configure Vault as secret backend (requires Vault deployed)
./scripts/deploy-external-secrets.sh --backend vault
Environment-Specific Deployments
Choose the appropriate values file for your environment. The script auto-detects the active backend from the file, or use -b to force a backend regardless of what the file says:
# Development (1 replica, reduced resources, PDB disabled)
./scripts/deploy-external-secrets.sh \
-f helm/external-secrets-operator/environments/dev/values.yaml
# Staging (2 replicas, full resources, certController HA)
./scripts/deploy-external-secrets.sh \
-f helm/external-secrets-operator/environments/stage/values.yaml
# Production (2 replicas, Manual upgrade approval)
./scripts/deploy-external-secrets.sh \
-f helm/external-secrets-operator/environments/prod/values.yaml
Force a specific backend on top of any environment file with -b:
# Vault backend with dev profile
./scripts/deploy-external-secrets.sh \
-b vault \
-f helm/external-secrets-operator/environments/dev/values.yaml
# Vault backend with prod profile
./scripts/deploy-external-secrets.sh \
-b vault \
-f helm/external-secrets-operator/environments/prod/values.yaml
Validate External Secrets Deployment
Run the validation script:
# Run validation script
./scripts/validate-external-secrets.sh
# Validate with backend connectivity check
./scripts/validate-external-secrets.sh --backend vault
Architecture Overview
The Fusion GitOps Quickstart creates a layered architecture optimized for Fusion HCI:
┌──────────────────────────────────────────────────────────┐
│ Fusion HCI Cluster │
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ GitOps (ArgoCD) │ │
│ ├────────────────────────────────────────────────────┤ │
│ │ • Continuous Delivery │ │
│ │ • Application Lifecycle Management │ │
│ └────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ HashiCorp Vault │ │
│ ├────────────────────────────────────────────────────┤ │
│ │ • Secret Storage & Encryption │ │
│ │ • High Availability (Raft) │ │
│ └────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ External Secrets Operator │ │
│ ├────────────────────────────────────────────────────┤ │
│ │ • Automatic Secret Synchronization │ │
│ └────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Application Workloads │ │
│ ├────────────────────────────────────────────────────┤ │
│ │ • AI/ML Pipelines │ │
│ │ • Microservices │ │
│ │ • Data Processing │ │
│ │ • Multi-Tenant Applications │ │
│ └────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
How It Works:
- GitOps Layer: ArgoCD monitors Git repositories and automatically deploys applications to the cluster
- Secret Management Layer: Vault stores all sensitive data with encryption and access control
- Synchronization Layer: External Secrets Operator bridges Vault and Kubernetes, automatically syncing secrets
- Application Layer: Your workloads consume secrets as native Kubernetes resources, unaware of the underlying complexity
This architecture provides separation of concerns while maintaining seamless integration. Each layer can be managed independently, yet they work together to provide a cohesive platform.
What Makes This Unique
Unlike generic GitOps tutorials or basic operator installations, the Fusion GitOps Quickstart provides:
- IBM Fusion HCI Optimization: Configurations tuned for IBM Fusion HCI's storage and networking capabilities
- End-to-End Integration: All components pre-configured to work together seamlessly
- Production-Ready Defaults: HA configurations, persistent storage, and security settings based on real-world deployments
- Comprehensive Automation: From operator installation to validation, everything is automated
- Battle-Tested: Configurations refined through actual enterprise deployments
- Extensible Foundation: Easy to customize and extend for specific requirements
Cleanup
Remove deployed components safely using the provided cleanup scripts. Always clean up in reverse order of deployment.
Cleanup Order
- External Secrets Operator (if deployed)
- Vault (if deployed)
- GitOps (if no longer needed)
# Clean up External Secrets
./scripts/cleanup-external-secrets.sh
# Clean up Vault (⚠️ Warning: This will delete all secrets!)
./scripts/cleanup-secret-manager.sh
# Clean up GitOps (⚠️ Warning: This will remove ArgoCD and all managed applications!)
./scripts/cleanup-gitops.sh
Force cleanup without prompts:
./scripts/cleanup-external-secrets.sh --force
./scripts/cleanup-secret-manager.sh --force
./scripts/cleanup-gitops.sh --force
Conclusion
The Fusion GitOps Quickstart transforms what used to be a multi-day configuration project into a quick automated deployment. By combining GitOps, HashiCorp Vault, and External Secrets Operator with production-ready defaults and comprehensive automation, it eliminates the complexity of GitOps platform setup.
What you've accomplished:
- Deployed enterprise-grade GitOps platform in minutes
- Configured centralized secret management with encryption
- Set up automatic secret synchronization
- Validated all components with comprehensive health checks
- Established a foundation for production workloads
Whether you're deploying AI/ML workloads, managing microservices, orchestrating multi-cluster applications, or building multi-tenant SaaS platforms, this quickstart provides the foundation you need, with the security, reliability, and flexibility required for production environments.
Ready to Get Started?
Quick Start Commands
cd Fusion-AI/quickstarts/fusion-gitops
# Deploy complete stack
./scripts/deploy-gitops.sh
./scripts/deploy-secret-manager.sh
./scripts/deploy-external-secrets.sh --backend vault
# Validate deployments
./scripts/validate-gitops.sh
./scripts/validate-secret-manager.sh
./scripts/validate-external-secrets.sh --backend vault
Additional Resources
Detailed Guides:
Main Documentation:
What you'll find in the guides:
- Prerequisites and environment setup
- Advanced configuration options
- Troubleshooting common issues
- Security best practices
- Multi-environment deployment strategies
- Integration with existing infrastructure
Your production-ready GitOps platform is just minutes away. Get started today!