Getting Started
Use this guide to bootstrap Haven+ locally or on a cluster. Choose your GitOps engine:
- Flux
- Argo CD
The following instructions will let you spin up a local Kind cluster, install FluxCD and deploy all components of the Haven+ stack.
Clone the repository
git clone https://gitlab.com/commonground/haven/havenplus/gitops-flux.git
Ensure you are in the root of the directory:
cd gitops-flux
Install dependencies / required tools
Use asdf to ensure the correct versions of dependencies/tools.
awk '{ system("asdf plugin add " $1) }' < .tool-versions
asdf install
Kind uses Docker under the hood; we've validated running Haven+ on a local environment with Docker Desktop.
Run Locally
The startup time for the full Haven+ stack in your local environment, until all services are fully operational, can take some time. For ways to streamline this process, refer to the Technical Details section below.
Spin up a local Kind cluster, install FluxCD and deploy all Haven+ components:
task run-local
Once this command has completed successfully, you can check the status of the deployed workloads as follows.
flux get all
Verify pods in e.g. the cert-manager namespace
kubectl -n cert-manager get pods
Clean-up
To delete your local cluster, run:
task uninstall
Technical Details
To bootstrap the Haven+ stack on a local Kubernetes cluster, we use Task for orchestration. The full Taskfile configuration is available here.
Given the number of applications involved, we’ve implemented several optimizations to streamline the startup process. When you execute the task run-local command, the following steps occur:
-
Pull container images: All required container images are downloaded upfront to your local environment. This step is performed before cluster creation to avoid errors that may arise if images are pulled directly on the local Kind cluster. Ensure you have enough allocated diskspace in Docker Desktop. The total size of all images pulled will be between 15 - 20GB.
-
Create a local Kind cluster: A local Kubernetes cluster is provisioned using Kind.
-
Load container images into Kind: Kind allows preloading container images from your host system into the cluster. By doing this, pods can start immediately without needing to download images on-demand, reducing errors related to inter-service dependencies.
-
Bootstrap FluxCD: FluxCD is installed and configured in the Kind cluster using the values specified in your
.envfile. -
Boost reconciliation and monitor completion: The reconciliation process is accelerated, and the system monitors all services until they are successfully deployed and running.
Optimizing Haven+ Startup on Your Local Environment
With the following system configuration, the full Haven+ stack starts in under 10 minutes (excluding the initial image pulls):
System: Mac-mini M4
Allocated CPU's in Docker Desktop: 4
Allocated Memory in Docker Desktop: 8GB
Increasing CPU and memory allocation will further reduce startup time. Additionally, you can speed up the process by deploying only the services you need. To do this, fork the repository, edit your .env file accordingly and comment out unnecessary services in the local Kustomization file.
This guide walks you through bootstrapping Haven+ with Argo CD, both on a shared cluster and locally for development.
Prerequisites
- Kubernetes cluster and
kubectlaccess - Argo CD reachable in the cluster (via Ingress or LoadBalancer)
- Access to the Haven+
gitops-argocdrepository (read)
Optional (local dev):
- Kind, Helm, Argo CD CLI, yq, kubeconform
- cloud-provider-kind for local LoadBalancer exposure
1) Install Argo CD (cluster)
Install Argo CD using Helm:
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
helm upgrade --install --wait --wait-for-jobs --create-namespace \
-n argocd argocd argo/argo-cd
2) Repository access
If gitops-argocd is private, add credentials as a Kubernetes Secret in argocd:
apiVersion: v1
kind: Secret
metadata:
name: repo-havenplus-argocd
namespace: argocd
labels:
argocd.argoproj.io/secret-type: repository
stringData:
url: https://gitlab.com/commonground/haven/havenplus/gitops-argocd.git
username: oauth2
password: <GITLAB_PAT_OR_DEPLOY_TOKEN>
type: git
Apply:
kubectl apply -f repo-secret.yaml
3) Bootstrap environment
Create the root Application for your environment:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: platform-root
namespace: argocd
spec:
project: default
source:
repoURL: https://gitlab.com/commonground/haven/havenplus/gitops-argocd.git
targetRevision: main
path: clusters/<env> # e.g. clusters/local for local testing
destination:
server: https://kubernetes.default.svc
namespace: argocd
syncPolicy:
automated:
prune: true
selfHeal: true
Argo CD will now reconcile the root and manage the Haven+ platform services.
Note (local fork/branch) If you’re testing locally and want Argo CD to sync from your own fork/feature branch, use this instead:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: platform-root
namespace: argocd
spec:
project: default
source:
repoURL: https://gitlab.com/<your-user>/gitops-argocd.git
targetRevision: <your-feature-branch>
path: clusters/local
destination:
server: https://kubernetes.default.svc
namespace: argocd
syncPolicy:
automated:
prune: true
selfHeal: true
4) Local development (optional)
Run a local cluster with Kind and Argo CD for quick iteration:
# From the gitops-argocd repo:
task run-local
# Onboard the local root (Application + ApplicationSets)
task onboard-platform-services
# (Optional) expose Services of type LoadBalancer
task expose-lb
Platform services are reconciled by ApplicationSets that scan infrastructure/** for both Helm charts (via .argocd.yaml + values files) and Kustomize overlays (e.g., infrastructure/<svc>/overlays/<env>).
5) Validating changes (pre-PR)
From the gitops-argocd repo:
task validate # yq syntax + kubeconform schema validation
For strict validation against a live API server:
kubectl apply --server-dry-run=all -f clusters/local/root.yaml
Troubleshooting
- authentication required: configure repository access (Secret) or make the repo public
- app not syncing: verify
repoURL, branch, andpath - local LB not reachable: use
cloud-provider-kindor port-forward to services
Advanced
- Two-source values pattern for Helm: ApplicationSets use a second Git source with
ref: argoReposo HelmvalueFilescan reference$argoRepo/<path>/values*.yamlalongside the external chart. - Server-Side Apply (CRDs):
ServerSideApply=trueis enabled to avoid oversized annotation errors when applying CRDs. - Retry/backoff: ApplicationSets include a retry policy to smooth over transient fetch/apply issues.
Further reading
- Argo CD Applications: https://argo-cd.readthedocs.io/
- Argo CD ApplicationSet: https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/
- Sync options (waves, SSA, retries): https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/