Skip to content
Eddy

Quickstart (kind)

This runs the hub, an agent, Flux and a demo app on one local kind cluster, in about five minutes. Nothing leaves your machine.

Full reference: docs/install.md, quickstart in the repository.

Before you start

You need docker, kind, kubectl, helm and openssl. The Task runner is optional, and so is the flux CLI (the script falls back to the Flux install manifest).

Steps

  1. Clone the repository and start the cluster. The script builds the images from source, so run it from a checkout.
    $ git clone https://github.com/idestis/eddy && cd eddy$ task kind:up
    Without Task, run the script that task kind:up calls. It is safe to re-run:
    $ ./deploy/kind/up.sh
  2. Wait for it to finish. The script does this, in order:
    • creates a kind cluster named eddy (context kind-eddy) and installs Flux.
    • adds a demo podinfo GitRepository and Kustomization, so there is something to look at;
    • builds the hub and agent images and loads them into kind;
    • installs the CloudNativePG operator and a one-instance PostgreSQL Cluster named eddy-db in the eddy namespace.
    • installs two hub replicas with local users, the eddy-db-app Secret as the database connection, one registered cluster called kind, and the platform group allowed to use the Add cluster wizard (onboarding.admins).
    • installs two agent replicas in eddy-system, talking to the hub over TLS with a self-signed certificate that it hands to the agent as hub.caBundle.
    • grants the example user roles, so the dev user can read and operate (see Access and RBAC).
  3. Open a port-forward to the hub. The script prints this command at the end:
    $ kubectl --context kind-eddy -n eddy port-forward svc/eddy-hub 8080:80
  4. Sign in. Open http://localhost:8080 and sign in as dev with the password eddy-dev-password. That user is in the platform group, which the example RBAC binds to eddy-operator, so it can also reconcile and suspend. The password is for local demos only.

Verify

  • The fleet page shows one cluster, kind, as connected. From the terminal:
    $ kubectl --context kind-eddy get clusters.gitops.eddy.dev$ kubectl --context kind-eddy -n eddy get pods
  • Press ⌘K (Ctrl+K elsewhere) and search for podinfo.
  • Use j and k to move, l to open, r to reconcile. ? lists every key. See Using Eddy.

Add another cluster

The kind setup registers its own cluster in clusters[]. The dev user can also try the Add cluster wizard (n on the fleet page), because the script sets onboarding.admins.groups: [eddy:platform] (see Add clusters). The wizard prints a helm install command that dials the hub's agent endpoint, which on kind is only an in-cluster address. A second cluster that can reach it needs a real endpoint, so follow Install for that.

Tear down

$ task kind:down

This deletes the kind cluster eddy and everything in it. Without Task:

$ kind delete cluster --name eddy

Troubleshooting

  • A pod is ImagePullBackOff. The images are built locally and loaded into kind with pullPolicy: Never. Re-run task kind:up.
  • Sign-in fails with an Origin error. Use http://localhost:8080 exactly: the hub's publicURL is set to that address, and it must match the browser.
  • The cluster stays disconnected. Read the agent log: kubectl --context kind-eddy -n eddy-system logs deploy/eddy-agent.

The kind setup uses local users so it works offline. For a real deployment, sign in with GitHub or OIDC. See Sign-in.