This setup assumes you have a local kind cluster ready to be used with the configuration below for the Kubernetes API endpoint.
- cluster:
insecure-skip-tls-verify: true
server: https://host.docker.internal:<API_SERVER_PORT>
name: kind-argo-local
To deploy ArgoCD with this test setup, you need to configure the correct clusters.
We try to simultate multiple clusters using different namespaces and cluster names, all present on the in-cluster
.
For the config to work both locally when debugging ArgoCD and in our remote kind cluster (on MacOS),
we use host.docker.internal
as the Kubernetes Service external name. You will need to update your local /etc/hosts
file to add
the following:
127.0.0.1 host.docker.internal
127.0.0.1 staging.argocd.svc
127.0.0.1 dev.argocd.svc
127.0.0.1 production-1.argocd.svc
127.0.0.1 production-2.argocd.svc
Once configured, you can update the cluster configuration:
-
Create the argocd-manager ServiceAccount to allow ArgoCD to manage the fake clusters:
kubectl apply -n kube-system -f bootstrap/serviceaccounts/argocd-manager.yaml
-
Get the token that was created for the ServiceAccount:
kubectl get -n kube-system secret argocd-manager-token -o jsonpath='{.data.token}' | base64 --decode
-
Make a copy of
example.yaml
at./services/argo-cd/base/clusters
and rename it toprivate.yaml
. -
Update the cluster configuration file
private.yaml
:- Replace
<TOKEN>
with the result of step 2 - Replace
<CERT_DATA>
with the certData in your~/.kube/config
- Replace
<KEY_DATA>
with the keyData in your~/.kube/config
- Replace
<API_SERVER_PORT>
with the port used to reach the API server locally.- Can be found in your
~/.kube/config
- Can be found in your
- Replace
-
Deploy argocd to your local cluster:
kubectl apply -n argocd -k ./services/argo-cd
At first, the sync-projects application must be applied manually.
Then, the bootstrap can be applied manually.
kubectl apply -n argocd -f bootstrap/sync/sync-projects.yaml
kubectl apply -n argocd -f bootstrap/sync/bootstrap.yaml