Deploy an app
Pick an app from the catalogue, say which version and which clusters, look at the preview, press go. New clusters that match get it by themselves.
Two ways to put an app on a cluster
- Install it on one cluster, once. From the cluster page. Good for trying something out.
- Deploy it: a standing rule that says what, which version and where. The platform keeps every matching cluster in line with it. Good for everything you mean to keep.
If you are not sure, deploy. Future you, adding the fifth cluster at 11 pm, will be grateful.
Deploy
- 1
Apps › pick the app
The catalogue lists what your organization may run. What an app stands on comes along — an app that needs a database operator brings the operator.
- 2
Say which version
Follow your organization's release (the default), or pin one release and stay on it while the organization moves on.
- 3
Say where
By labels — every cluster carrying, say,
env=dev, including ones you build next month. Or a fixed list of clusters. A cluster matches by its own labels and its account's; where both set the same key, the cluster wins. - 4
Read the preview, then create
For each cluster the preview says what would happen: gets it, updates, already up to date, skipped because its machines cannot run the app, or blocked (waiting for a domain, say). Nothing changes until you press create.
Rolling out
By default the rollout goes one by one and stops at the first cluster that fails — so one broken cluster does not become ten. You can choose all at once instead. Pause stops new clusters joining; resume carries on.
Labels are the lever
Adding a label a deployment matches installs the app there. Removing it does what the deployment says: keep the app (the default) or remove it. So before you tidy up a cluster's labels, glance at what deploys by them.
What next
Follow the rollout in Activity. Each cluster's state is on the deployment's page; a blocked or failed one says why in plain words.