Concepts

These are the words the docs, the CLI and the admin UI use. Most of them are records you can list with weikio get and keep as a YAML file in Git. Agents, users and API keys are kept only in Weik.io.

Projects#

A project is a folder of related integrations and the people allowed to work on them, such as finance or hr. Roles are granted per project, and a grant can be narrowed to some environments and to single integrations or APIs. In Git a project is usually a folder with a project.yaml file, so the files below it don’t repeat the project’s name.

Environments#

An environment, such as devtest or production, is defined once for the whole platform by a platform administrator. Every project deploys into the same environments in the same order. An environment marked as production needs --env on every command that changes it, and it can refuse to reveal secrets.

apiVersion: weik.io/v1
kind: environment
metadata: { name: devtest }
spec: { displayName: Dev and test, order: 1, isProduction: false, protection: { allowSecretReveal: true, allowLatestVersion: true }, budgets: { entityStoreBytes: 536870912 } }
---
apiVersion: weik.io/v1
kind: environment
metadata: { name: production }
spec: { displayName: Production, order: 2, isProduction: true, protection: { allowSecretReveal: false }, budgets: { entityStoreBytes: 2147483648 } }

Integrations#

An integration is a folder of Camel files: routes in YAML, XML or Java, beans, kamelets, application.properties and anything else the routes use. Transfers, schedules, event sources, channels, subscriptions and change tracking are integrations too. You write them as short YAML documents, and the platform generates their routes.

Versions#

weikio apply publishes an integration as an immutable version, the way npm publish publishes a package. Weik.io builds the version once: it validates the routes, resolves the jars and stores every file by its content hash. The version doesn’t run until you deploy it. When integration.yaml declares a version, changing the files without raising it is refused, and the error tells you to run weikio apply --bump patch.

Deployments#

weikio deploy runs a version in an environment. The deployment runs on every agent whose capabilities match the integration’s requirements, so two matching agents run two copies. weikio run publishes and deploys, and it’s the command you use while you develop.

Promotion#

weikio promote copies a deployment from one environment to the next. Production gets the version devtest ran, and nothing is rebuilt.

$ weikio promote finance/erp-invoice-export --from devtest --to production

Variables and secrets#

Anything that differs between environments, or changes without a new version, is a variable or a secret. A variable without an environment is the default, and one with an environment overrides it there. Secrets have the same shape, but you set their values with the CLI so they’re never in Git. Routes read both as plain Camel properties, such as {{erp-url}} and {{erp-api-key}}.

The hub#

The hub runs the backend with the API, the admin UI and the builder, the API gateway, the message server that stores every record, and the log, metric and trace stores. It runs on one server, or on as many as you need for high availability, and those servers can be in different data centres.

Agents and sites#

An agent is the program that runs your integrations, and a site is wherever it runs. An administrator enrols each agent, gives it capabilities such as os=linux, region=fi and environment=production, and lists the projects it may run. The agent starts one Java process for each running integration and reports what it runs every 30 seconds.

What runs where#

An agent’s host never opens an inbound port. Everything the agent does is outbound, on port 443 to the two names of your Weik.io installation:

An integration’s own traffic, such as calls to an ERP or a bank’s SFTP server, goes from the agent’s host directly to that system on its own ports.