Applications
An application is a named group of microservices on the Controller. It is the unit you start and stop together. NATS account policy lives on the application. The application can also instantiate an application template.
Every user microservice belongs to exactly one application name. System workloads use system-<agentName> applications the Controller creates. Inspect those with get system-applications and get system-microservices. See Networking. You do not deploy them as user kind: Application documents.
Field tables are on Application fields.
When to use it
| Approach | Use it when |
|---|---|
spec.microservices on the application | The app is small and one file should create the group and its services. |
Application plus separate kind: Microservice documents | Each service has its own lifecycle. CLI names stay application/microservice. |
spec.template | The same layout is deployed many times from an application template. |
| Microservice only | The application already exists and you are adding a service. |
A standalone microservice still needs spec.application, or a metadata.name that already contains /.
What deploy -f does
potctl deploy -f application.yaml -n my-ecn
deploy parses the spec, looks up the application by name, then creates or updates it. After create or update, the Controller starts the application.
Inline spec.microservices travel with the application document. A separate kind: Microservice in the same file is deployed on the microservice path.
Deploy the same metadata.name again to update. An update does not delete microservices that you removed from spec.microservices. Check get microservices and describe after the deploy.
NATS at application and microservice level
natsAccess and natsRule sit under natsConfig. A top-level natsAccess is rejected.
Set spec.natsConfig.natsAccess: true on the application before any microservice in that application sets natsConfig.natsAccess: true. Omit natsRule and the Controller uses the default-account account rule. A named rule must already exist. See NATS account rules.
What the Controller does after the flag is on (account JWT, resolver, microservice users) is NATS access. Per-service users are on the same pages and under Microservice fields.
Examples
From a template
The template edge-app-template is on Application templates. This file only supplies the name and the variable values.
apiVersion: datasance.com/v3
kind: Application
metadata:
name: shop
namespace: my-ecn
spec:
template:
name: edge-app-template
variables:
- key: agent-name
value: edge-01
- key: external-port
value: 9090
- key: application-name
value: shop
natsConfig:
natsAccess: false
You can still add microservices for services that are not in the template.
Inline microservices
One file creates the application and a WASM service on Edgelet node edge-01. The runtime handler spin must already be available on that node. See Runtime classes.
apiVersion: datasance.com/v3
kind: Application
metadata:
name: wasm
namespace: my-ecn
spec:
microservices:
- name: wasm
agent:
name: edge-01
images:
registry: remote
amd64: ghcr.io/spinframework/containerd-shim-spin/examples/spin-rust-hello:v0.22.0
arm64: ghcr.io/spinframework/containerd-shim-spin/examples/spin-rust-hello:v0.22.0
container:
hostNetworkMode: false
isPrivileged: false
platform: wasi/wasm
runtime: spin
ports:
- internal: 80
external: 8080
protocol: tcp
commands:
- "/"
Each inline entry uses the same fields as Microservice fields.
Commands
potctl get applications -n my-ecn
potctl describe application myapp -n my-ecn
potctl start application myapp -n my-ecn
potctl stop application myapp -n my-ecn
potctl delete application myapp -n my-ecn
Deleting an application removes its microservices. delete application does not remove system applications.
Running apps are in EdgeOps Console → Workloads. Container logs and shells are on Logs and exec.