Skip to content

Zentinelle in Astrolift (AWS)

The gate inside the platform. Astrolift builds its own VPC, Aurora cluster, Temporal, load balancer and EKS tenant cluster. Zentinelle joins Astrolift's network, Aurora cluster and load balancer, and its backend, worker, console and a Temporal of its own run as pods on Astrolift's tenant cluster. Its database, Redis, secrets and DNS record stay managed outside the cluster, and its ECS services are kept at zero as the way back.

Zentinelle never uses Astrolift's Temporal while it runs on the cluster: the cluster's nodes would admit every tenant pod to it, so Zentinelle runs its own there.

Not yet validated end to end

Written from the installer source as of release 0.1.57. No step on this page has been run end to end on a clean AWS account yet. Read the known blockers first. The Zentinelle cluster placement has been certified on a local kind cluster only; IRSA, the load balancer rules, the park phase against ECS and NetworkPolicy enforcement have not run on real EKS.

What you need

The common prerequisites, and the same required values as Astrolift standalone: Deployment name, Domain, Hosted zone ID and VPC CIDR. Zentinelle adds no required field; Advanced: footprint gains Zentinelle task sizes, database backup retention and deletion protection.

Capacity must be on-demand, or Spot with the on-demand anchor node (Lean has the anchor). Spot without the anchor is refused on the requirements screen, because Zentinelle's backend and console run on the anchor.

Choose it

  1. Choose what to install: Zentinelle in Astrolift.
  2. Pick the cloud: AWS and a region.
  3. Pick a footprint.
  4. Review the drawing: the card sets "What the products share" to Share everything and "Where Zentinelle runs" to On the Astrolift tenant cluster. Keep "Tenant runtime" on Create a cluster; with an attached cluster, or with less shared, Zentinelle falls back to its own ECS services.
  5. Fill in the values, review Before we start, and finish setup.

The card resolves to three units: Astrolift, Zentinelle, and Zentinelle on the Astrolift cluster.

Apply

On Install, in this order:

  1. Dry run Plan Astrolift, read the plan, Deploy it. Its apply records the cluster name, OIDC provider, node security group and anchor node group that the next units read.
  2. Dry run Plan Zentinelle, read the plan, Deploy it. Read the plan first: the task role trusts the cluster's service account, and the ECS services are created at zero. After the apply, the Deployment Manager parks Zentinelle's ECS services and marks the record parked.
  3. Dry run Plan Zentinelle on the Astrolift cluster, read the plan, Deploy it. The dry run is refused until step 2 has marked the record, so two Zentinelles never run against one database. Expect two target groups and their Auto Scaling attachments, three listener rules, the NodePort and Redis rules, the zentinelle namespace, its service account, a Secret and one Helm release.

Verify

Zentinelle answers at zen.<domain> with the default short names (zentinelle.<domain> redirects); Astrolift as in Astrolift standalone.

curl -fsS https://zen.<domain>/api/zentinelle/v1/health

The tenant cluster's Kubernetes API is private by default, so run kubectl from inside the VPC (a bastion or a pod), with the AWS identity that applied the install, or use the EKS console:

aws eks update-kubeconfig --name <deployment>-astrolift --region <region>
kubectl -n zentinelle get pod -o wide

The backend, console and Temporal pods run on the node labelled astrolift.ai/anchor=true; the worker prefers the other nodes. Both Zentinelle target groups show the anchor healthy, and the console signs in at its address.

To wire Astrolift organizations to this Zentinelle, use Install, Integrations, Zentinelle with Astrolift, Connect, naming the organization by slug. It runs a one-time enrollment inside the account; the code is single use and valid for 15 minutes.

First app and first agent run

As in Astrolift standalone.

Undo

Teardown enforces the order: Zentinelle on the Astrolift cluster first, then Zentinelle, then Astrolift. Each is a destroy plan you read and deploy. Then remove the state store and the Deployment Manager as in Undo.

To move Zentinelle back to ECS without removing it: tear down the cluster unit (keep data), set "Where Zentinelle runs" to Its own ECS services in Settings, then plan and deploy Zentinelle; the Deployment Manager scales its Temporal, worker, backend and console back up.