Concepts

These are the words the docs, the CLI and the admin UI use. Each one is a record you can list with weikio get and keep as a YAML file in Git, except agents, users and API keys, which the platform keeps for itself.

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 } }
---
apiVersion: weik.io/v1
kind: environment
metadata: { name: production }
spec: { displayName: Production, order: 2, isProduction: true, protection: { allowSecretReveal: false } }

Integrations#

An integration is a directory 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. The hub 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 in one step, which is the command you use while you develop.

Promotion#

weikio promote copies a deployment from one environment to the next. Production gets exactly 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 never sit 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 three or five for high availability.

Sites and agents#

A site is wherever integrations run, and an agent is the program that runs them there. An administrator enrols each agent at the hub, 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#

A site never opens an inbound port. Everything it does is outbound, to one hostname, on port 443:

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