ankra services
Set up, inspect and retire managed services: PostgreSQL, Valkey, OpenSearch, VictoriaMetrics, VictoriaLogs and the other engines in the service catalogue, run on your own cluster as reviewed, health-checked platform services. A service is set up in four steps:- Pick a package from the catalogue: ankra services packages list
- Declare where the cluster is: ankra services policy set
--cluster<c>--region<r>--data-boundary<b> - Bind the application namespace that
will use the service: ankra services consumers bind
--application<a>--cluster<c>--namespace<ns> - Review and confirm the setup: ankra services setup <name>
--packagepostgresql--cluster<c>--consumer<id>
--yes skips
the question for scripts. Retiring a service deletes its data, so delete also
needs --acknowledge-data-loss.
‘ankra services list’ and ‘ankra services get <name>’ show each service’s
deployment state, health, readiness (for PostgreSQL, a consumer-path canary
logs in with the generated credentials) and connection: its endpoints and the
Secret holding its credentials. Credential values are never shown; they stay
in the cluster.
Examples
ankra services consumers
Bind, list and unbind consumers: the application namespaces a service is set up for. A consumer is one application’s namespace on one cluster, with a stable id. Setup takes one or more consumer ids (--consumer), and the plan records each
with the cluster policy it was resolved against. A binding normally resolves
to the application’s installation on that cluster; --allow-planned binds a
namespace the application is not installed in yet. A binding a service still
uses cannot be unbound until that service is retired.
ankra services consumers bind
Bind an application’s namespace on a cluster as a service consumer and print its consumer id, which ‘ankra services setup--consumer’ takes.
The cluster needs a placement policy first (‘ankra services policy set’). The
application must be installed in that namespace unless --allow-planned is
given. A binding is created once per application, cluster and namespace;
changing an existing one needs --revision with its current revision
(‘ankra services consumers list --application <app>’ shows it); a setting
not given on the command line keeps the binding’s current value. Binding
deploys nothing and delivers no credentials.
ankra services consumers get
Show a consumer binding resolved as setup would resolve it: the cluster’s declared region and data boundary, the policy and binding revisions, and the application installation it binds (none for a planned binding).ankra services consumers list
List an application’s consumer bindings as last saved: each binding’s id (what setup’s--consumer takes), cluster, namespace and revision. Bindings on
clusters you cannot read are not listed.
ankra services consumers unbind
Remove a consumer binding: the application namespace stops being a consumer services can be set up for. Nothing is deployed or removed on any cluster. A binding a service still uses - one that has not been retired - is kept; retire the service first (‘ankra services delete’). A setup review still pending that names the binding can no longer be confirmed. The platform removes a binding only at the revision you last read. Without--revision the current one is read from the binding. A binding whose
application or cluster has since been removed can still be unbound, but it can
no longer be read by id: pass --revision with the revision ‘ankra services
consumers list --application <application>’ shows. Asks first; --yes skips the
question.
ankra services delete
Retire a managed service, in two steps, deleting its data. First a retirement review is prepared: the platform resolves what retiring removes and keeps - the service’s stack and its members, its namespace with everything in it (objects it did not create are listed), every volume claim with the reclaim policy that decides its data, the consumers it is disconnected from and the shared operators it keeps - and stores that plan with a digest for ten minutes. Preparing changes nothing on the cluster. The plan is shown, and the service is retired only when you confirm it: at the prompt, or with--yes.
Retiring deletes the namespace, its volume claims and its Secrets, generated
credentials included, and no export is offered; restore points stay in their
backup vault under its retention. A volume whose reclaim policy is Retain
keeps its data until someone removes it, and the settled retirement names it.
So delete always needs --acknowledge-data-loss, before anything is prepared.
A retirement review you prepared earlier that is still open (for example one
whose answer was lost) is resumed instead of preparing another; --new-review
prepares a fresh one. --review-only stops after the review and prints the
command that confirms it. --wait follows the retirement until it settles.
ankra services get
Show one managed service by name or id: its package, cluster and location, its deployment state, health and readiness with the evidence behind each, how it is reached (endpoints and the Secret holding its credentials), the consumers it was set up for, and the latest retirement if one was confirmed. The connection names the Secret and its keys only. Credential values are never shown here; they stay in the service’s namespace on the cluster. A name that runs on more than one cluster needs--cluster.
ankra services list
List the organisation’s managed services: each with its cluster, package, deployment state, health and readiness. Deployment state is the recorded operation progress (accepted, deploying, verification_pending, deployment_failed, …), not current health. Health is what the platform last observed from the cluster (serving, progressing, degraded, unknown). Readiness says whether a consumer can use the service: for PostgreSQL a canary logs in with the generated credentials (ready, verifying, degraded, stale); engines without a canary read unverified.--application keeps the services an application uses: those whose reviewed
plan names one of the application’s namespaces as a consumer. The
application is given by name or id, and a Used by column says which of its
environments each service serves (or the namespace, where the application is
not deployed yet).
Retired services keep their record; --include-released lists them too.
ankra services packages
Browse the service catalogue: the immutable package versions this organisation may set up, Ankra’s own (PostgreSQL, Valkey, OpenSearch, …), any shared with it, and its own. ‘init’ and ‘publish’ turn one of your stack profiles into a package that connects to applications like Ankra’s own. Being listed is not being deployable: setup re-checks access and the pinned profile when the review is prepared.ankra services packages collisions
Read a running demo of a stack profile and check whether two services set up from a package built on it could run on the same cluster: a cluster-scoped object (a ClusterRole, a CRD, a webhook, a StorageClass) whose name does not change with the service’s namespace would be claimed by both. It also lists the Services and Secrets whose names do change with it, which a package’s connection cannot name as fixed values. Exits 0 only when every kind was read and nothing collides; collisions exit 1 with the objects named, and a check that could not read everything (the verdict unknown) exits 1 with the reason, so it never reads as no collision.ankra services packages get
Show a package version’s contract: the modes it can run in, the parameters a setup may choose (with their bounds and defaults), the secret inputs it needs and the outputs it publishes. The package is a name, name@version or id.ankra services packages init
Write a service package (contract schema 2) for one version of a stack profile this organisation owns, so the services it deploys can be set up from the catalogue and connected to applications like Ankra’s own. The skeleton pins the profile version and names the protocol consumers speak (nats, opensearch, postgres, redis, s3, victorialogs, victoriametrics). Before publishing, fill in what only you know about the engine the profile deploys:--addon with --registry and --chart-version instead of --profile and
--profile-version: init first creates a stack profile holding that chart
alone (installed into a namespace named after each service), then writes the
package pinned to it.
With --generate-secret, that profile also generates the service’s
credentials: a Secret of that name in each service’s namespace, created on
the first install and kept unchanged across upgrades. Name its keys with
--generate-key: “password” for a random value, “password:48” for a random
value of 48 characters. Random values are generated in the cluster and Ankra
never sees them. “username=app” sets a fixed value, which is stored in the
profile and visible on the command line, so use it only for names (a user or
database name), never for a password. Point the chart at the Secret in
--values (most charts take an existing-secret setting); the package’s
connection names it already.
ankra services packages list
List the service packages this organisation can set up: each version’s name, capability (database, cache, search, metrics, logs, …), publisher and id. Pass the name, name@version or id to ‘ankra services setup--package’.
ankra services packages probe
Probe the connection a package file declares against a running demo of its stack profile, before publishing: Ankra runs the protocol’s readiness canary in the demo’s namespace, the same one that verifies a published package. Without--wait the probe is only queued. With --wait the command follows it
and exits 0 only when the verdict is passed; failed and unknown (the canary
could not run, or the demo stopped) exit 1 with the reason, and a probe still
running when --timeout ends exits 5.
ankra services packages propose
Read a running demo of a stack profile on the organisation’s staging cluster and propose the connection blocks a service package made from that profile could declare: one per Service port speaking a protocol Ankra connects applications to, each field mapped to a key of the Secret that holds the most of the credentials. Only Service ports and Secret key names are read, never Secret values, and nothing is tried: probe a proposal with ‘ankra services packages probe’ before publishing. With -f, the best complete proposal is written into that package file (made by ‘ankra services packages init’), replacing its connection. A demo whose namespace could not be observed exits 1 with the reason, so an unobserved namespace is never read as one with nothing to propose.ankra services packages publish
Publish a service package version from its contract document. The document is sent as written; the platform validates it and refuses it with the path that failed. A published version is immutable: publishing the same name and version again with identical content returns it, and different content is refused, so a change needs a new version. Publishing makes the package available to set up in this organisation; it does not make Ankra operate it or qualify it.ankra services policy
Read or declare a cluster’s service placement policy: the physical region it runs in, the data boundary its data may stay within, and whether services on it are local-only. This is the organisation’s declaration, not verified location evidence. Setup refuses a cluster without one, and a setup’s region and data boundary default to it.ankra services policy get
Show a cluster’s service placement policyankra services policy set
Declare a cluster’s service placement policy: the physical region it runs in (for example eu-north-1), the data boundary its data may stay within (for example eu) and whether services on it are local-only. The first declaration creates the policy. Replacing one needs--revision with
the revision you reviewed (‘ankra services policy get’ shows it), so two
people cannot overwrite each other’s declaration unseen. Nothing is deployed.
ankra services retirements
List, read and confirm your own retirements of a service. ‘ankra services delete’ prepares a retirement review and confirms it. A review that was prepared with--review-only, declined at the prompt or whose
answer was lost stays pending for ten minutes: ‘list --state pending’ finds it
and ‘confirm’ confirms it instead of preparing another (each person may hold
10 open retirements). ‘get’ follows a confirmed retirement and, once it
settled, shows what became of every volume.
ankra services retirements confirm
Confirm one of your pending retirement reviews by its digest. This is the step that retires the service and deletes its data, so it needs--acknowledge-data-loss as well as a yes at the prompt (or --yes).
--digest names the digest you reviewed (‘delete --review-only’ prints it); a
review whose digest differs is refused, because it is not the plan you saw.
Without --digest the digest of the review shown is the one confirmed.
ankra services retirements get
Show one of your retirements: the plan, its progress and what became of the volumesankra services retirements list
List your retirements of a service, newest firstankra services reviews
List, read and confirm your own setup reviews. ‘ankra services setup’ prepares a review and confirms it. A review that was prepared with--review-only, declined at the prompt, or whose answer was lost
stays pending for ten minutes: find it here and confirm it instead of preparing
another (each person may hold 20 open reviews). An expired review needs a new
setup. Reviews are personal: nobody else sees or confirms yours.
ankra services reviews confirm
Confirm one of your pending setup reviews by its digest. This is the step that sets the service up. The review is shown and confirmed after a yes at the prompt, or with--yes.
--digest names the digest you reviewed (setup --review-only prints it); a
review whose digest differs is refused, because it is not the plan you saw.
Without --digest the digest of the review shown is the one confirmed. A
review that already expired needs a new ‘ankra services setup’.
ankra services reviews get
Show one of your setup reviewsankra services reviews list
List your setup reviews, newest firstankra services setup
Set up a managed service on a cluster, in two steps. First a review is prepared: the platform resolves the package, the cluster’s placement policy and every consumer, and stores the plan with a digest for ten minutes. Preparing changes nothing. The plan is shown, and the service is set up only when you confirm it: at the prompt, or with--yes. The confirmation
carries the digest of the plan you saw, so a plan that changed in between is
refused rather than deployed.
--review-only stops after the review and prints the command that confirms it
(‘ankra services reviews confirm <id> --digest <digest>’), for a person or a
pipeline that approves separately.
The name becomes the service’s namespace on the cluster: lower-case letters,
digits and single hyphens, starting with a letter. Ankra’s engines also need
it to be at most 36 characters and not a system namespace (default, kube-,
ankra, cert-manager, …); the platform refuses any other name when the
review is prepared, before anything is stored.
Every setup needs at least one consumer (--consumer, from ‘ankra services
consumers bind’). The region and data boundary default to the cluster’s
placement policy. Parameters (--param) default to the package’s defaults;
‘ankra services packages get <package>’ lists them with their bounds.
Confirming starts the deployment; it is not proof that the service is ready.
Follow it with ‘ankra services get <name>’.