Install with Helm

Each product is one helm upgrade --install. Run them in the order below: each step waits until the product is ready, including the one-off Jobs that run before its pods, such as the database migration.

The examples install everything into one namespace, tinyblox, and use example.com names. Each product’s guide lists every value its chart accepts; this page shows only what ties the products together.

0. Namespace, registry login and databases

kubectl create namespace tinyblox
helm registry login registry.tinyfactory.ai
kubectl -n tinyblox create secret docker-registry registry-pull \
  --docker-server=registry.tinyfactory.ai \
  --docker-username=<user> --docker-password=<token>

Create the databases, logins and password Secrets as described in Databases.

1. TinyGuard

TinyGuard signs everyone in. Before the install, create its secrets file, which holds its encryption key, and keep an offline copy (see Backups of the encryption keys):

IMAGE=registry.tinyfactory.ai/tinyblox/guard:0.3.2
docker run --rm --user "$(id -u):$(id -g)" -v "$PWD:/work" -w /work \
  "$IMAGE" generate-secrets --output secrets.toml
kubectl -n tinyblox create secret generic tinyguard-secrets \
  --from-file=secrets.toml=secrets.toml

helm upgrade --install tinyguard oci://registry.tinyfactory.ai/tinyblox/charts/tinyguard \
  --version 0.3.2 -n tinyblox -f guard.yaml --wait --wait-for-jobs

guard.yaml sets at least its public address (publicUrl: guard.example.com), the image digest, PostgreSQL storage and the first administrator. The TinyGuard Kubernetes guide has every value.

After the install, the issuer every other product trusts is https://guard.example.com/auth/v1.

Using your own identity provider instead? Skip this step and use its issuer below. See Sign-in across products.

2. TinyVault

coming TinyVault’s first release is coming. Its install will follow the same pattern: create its root key file once and keep an offline copy, then install the chart.

docker run --rm -v "$PWD:/out" registry.tinyfactory.ai/tinyblox/tinyvault:<version> \
  keys init --new-key-file /out/keys
kubectl -n tinyblox create secret generic tinyvault-keys --from-file=keys=./keys

helm upgrade --install tinyvault oci://registry.tinyfactory.ai/tinyblox/charts/tinyvault \
  --version <version> -n tinyblox -f vault.yaml --wait --wait-for-jobs

3. TinyConductor

helm upgrade --install tinyconductor oci://registry.tinyfactory.ai/tinyblox/charts/tinyconductor \
  --version <version> -n tinyblox -f conductor.yaml --wait --wait-for-jobs

conductor.yaml sets its public address, the database and its sign-in at the identity provider. Register its console client at the provider first (in TinyGuard’s console, or with the provisioner once that is released), and put the client secret in a Secret:

publicUrl: conductor.example.com
oidc:
  enabled: true
  issuer: https://guard.example.com/auth/v1
  clientId: tinyconductor-console
  clientSecret:
    existingSecret: tinyconductor-oidc-console

From 0.2.0, TinyConductor also reads secrets from TinyVault. In one namespace it works out TinyVault’s address itself; you only say how the connection is protected:

secrets:
  store: tinyvault
connections:
  tinyvault:
    transport: tls                 # no service mesh: TinyVault's own TLS
    ca:
      configMap: tinyblox-ca       # your environment's CA certificate

The TinyConductor Kubernetes guide has every value, its two modes (Bundled and Cluster) and the database setup.

4. The connector runtime

coming ```sh helm upgrade –install tinyconductor-connectors
oci://registry.tinyfactory.ai/tinyblox/charts/tinyconductor-connectors
–version -n tinyblox -f connectors.yaml –wait –wait-for-jobs

The connector runtime's first release is coming. It connects to the engine
and to TinyVault with the same [connection settings](/connections/) as the
other products. To let the TinyConductor console test stored connections
through it, set `connections.tinyconductorConnectors.enabled: true` in
`conductor.yaml`.

## 5. People and permissions

<span class="coming">coming</span> Give your administrators and teams their roles in every product with one
[access file](/provisioning/access/). Until the provisioner is released,
create groups and role assignments in your identity provider's console.

## Sign-in clients

<span class="coming">coming</span> Today you register each product's sign-in client at the identity provider
yourself, before installing the product, and give the product its client
secret in a Secret, as the product's guide describes. Once the provisioner
is released, each chart does this for you before its pods start: see
[Sign-in clients](/provisioning/sign-in-clients/).

## Checking an install

```sh
kubectl -n tinyblox get pods
kubectl -n tinyblox get jobs        # one-off Jobs such as migrations: Complete
helm -n tinyblox list

A Job that failed is kept, with its log:

kubectl -n tinyblox logs job/tinyconductor-migrate