Environments
A runtime cluster holds one or more environments. An environment is a separate place to run releases, for example one for trying things out and one for production. Each environment has a name and a tier. The Admin UI shows both at the top of the Status page, for exampleplayground development.
Most things are set per environment: who may deploy, which keys exist, and which runs were recorded. A key or a right in one environment does nothing in another.
Applications
When you deploy a project to an environment, it becomes an application there. The application’s name comes from the project’s name, in lowercase with hyphens. In some environments, the cluster adds 6 characters of the project’s ID, for examplepizza-pricing-calculator-180269. The Lab tells you the name when you deploy: “This project is called pizza-pricing-calculator-180269 there.”
Each application has its own current release and its own history. Two projects in the same environment never change each other. In short: a release is what runs, and an application is the place in one environment where it runs.
Releases and deploying
A release is a version of a project that never changes once it is created. In the Lab, the Deploy dialog first creates the release, then deploys it. Deploying tells an environment which release to serve for an application. The cluster records every deploy and every roll back with a number, for exampledeploy 11 on the Status page. A roll back serves the release before the current one again. A second roll back serves the newer release again. After a deploy or a roll back, the cluster needs a short time, usually one to three minutes, until every worker serves the new release.
Only public blueprints of a release can be called. The Deploy dialog lists them under Callable on the cluster. On the cluster, a blueprint is called by its name in lowercase with underscores: the blueprint Pizza Pricing is pizza_pricing.
Calling a release
Every callable blueprint has a run address:Evaluation keys
A caller sends an evaluation key in theX-API-Key header of every call. A key belongs to one application in one environment, and to the system that calls with it, not to a person. So it keeps working when the person who created it leaves. Its first characters show the environment’s tier: lk_dev_ in a development environment.
An application without a key is not served: nothing can call it. The Status page says “Not served yet: this application has no evaluation key in” and the environment’s name until you create a key. When you revoke a key, calls with it are refused within about a minute.
Runs and usage
Every call is a run. The cluster records each run: when it started, how long it took, which release ran, the input and the output. Test runs in the Lab are not recorded here. In the Admin UI, Runs lists the runs and Usage counts them. The input and output of a run are its payloads. They can be deleted on their own. The facts of the run stay: when it ran, how long it took, which release ran, its correlation ID and its status. So the cluster keeps a record that the run happened.Who may do what
The cluster decides from grants what a person may do: deploy a release, create and revoke evaluation keys, or read runs and usage. On Leapter Cloud, your first deploy of a project toplayground gives you the rights on that application there, so you need no one to give them to you. On a runtime cluster of your own workspace, the admin of the cluster gives you the rights you need.
What to do next
- Deploy a release and call it: try the whole way once.
- Create and revoke an evaluation key: give a system access.
- Find a run and read usage: see what your callers ran.