Manage components

Reading the Components tab needs containerinstance/read; changing anything on it, and starting, stopping or restarting the instance, needs containerinstance/write.

Read the Components tab

Each component is one row: its status, the image of its first container, how many pods are ready, its compute plan, its ports and its volumes. A pod counts as ready when every one of its containers is. While an earlier startup wave is not ready, the tab's description names the wave the later components wait for.

Open a row to see the component's detail: the reason it is unhealthy, when there is one; its pods, when it has more than one; its replicas, compute plan and the user it runs as; each container with its image, ports and environment variable names (a key icon marks the vault-backed ones); and its volumes. A row whose component is failing opens by itself.

The Logs and Terminal buttons are described in View logs and open a terminal.

Edit a component

1. In the row's menu (…), choose Edit. The Edit sheet opens for that component.
2. Change what you need:
   • Startup wave — the component's wave, 1 or higher. Setting it lower than the highest existing wave makes the later waves report that they are starting, and pauses endpoint updates, until this component is available; the sheet warns about it.
   • Replicas, Compute Plan and Scaling — see Scale a component.
   • For each container: Image, Tag, Ports, Environment variables, and under Command & arguments the Command and Arguments. These work as in the create wizard.
   • Add container (up to 8 per component) and Add init container (up to 4). Give a new container its Container name before its image: the name field locks once the container has an image. Remove container (the bin icon) removes one; a component keeps at least one main container.
3. Choose Save changes.

Saving a change to the containers or the compute plan replaces the component's pods with pods running the new configuration; the other components keep running. A change to only the replicas, the scaling or the startup wave leaves the running pods alone. The names of the component, of saved containers and of saved ports are fixed.

• Removing a port that an endpoint uses asks you to remove that endpoint in the same save (Remove both). A port that a probe uses cannot be removed here.
• Expose this port, next to a saved port, opens a new endpoint for it on the Endpoints tab. It is offered only while the sheet has no unsaved changes.
• Every save of an instance that uses vault secrets gives the instance's identity Secrets Reader on each vault it references again, with your permissions, and that needs the Owner role on the vault. Without it the save is refused, whatever it changes. For the vaults of the component you are editing, the sheet says so and offers to request access — see When it happens for you and Permissions.

Warning

A container added to a component that uses vault secrets can read every one of the component's secret values — see Identity and secrets. Add a container that must not see them as a component of its own.

In a component that uses vault secrets, give every container that declares Arguments a Command as well. Without one, the container is started with its first argument as the command instead of the image's ENTRYPOINT, and fails.

The sheet does not change a container's private registry, probes, volumes or mounts; those are changed through the API or the CLI — see Add volumes and files.

Add a component

Choose Add component. The sheet opens with a new component: one replica, one container, and the highest existing startup wave. Give the component a Component name — lowercase letters, digits and hyphens, starting with a letter — and its container a Container name, then an Image and a Tag, and choose Save changes. An instance has at most 16 components.

The portal does not remove components. Through the API, update the instance with a component list that leaves the component out: its Deployment, in-cluster name and autoscaler are removed. A persistent volume that is kept on delete — the default — stays, and is attached again if a component of the same name declares a volume of the same name.

Re-deploy one component

In the row's menu, choose Re-deploy. The platform looks up the component's image tags again and replaces its pods; the other components keep running. Use it after pushing a new image under a tag the component already runs.

Start, stop and restart the instance

The buttons at the top of the instance page act on every component:

• Stop, shown while the instance is Running, sets every component to 0 replicas and remembers how many each had. Components that autoscale stop too, and their autoscalers are removed.
• Start, shown while it is Stopped, gives every component its remembered count back; a component without one — including one that was already at 0 before the stop — starts with a single replica.
• Restart, shown while it is Running, re-deploys every component: tags are looked up again and all pods are replaced.

Important

A component that autoscales does not come back with Start: its autoscaler is created again, but the autoscaler does not scale up a component that is at 0, so the component stays stopped. To start it, set its Scaling to Manual — fixed replica count with the number of replicas you want, save, and then turn autoscaling on again.

The buttons are not shown while the instance is in any other status. Setting one component's Replicas to 0 stops only that component; the instance keeps reporting Running as long as another component runs.

Browse opens the instance's public URL in a new tab. It is shown when an endpoint has a URL and the instance is Running or Degraded.

With the CLI:

stsh ci stop worker -g my-resource-group
stsh ci start worker -g my-resource-group
stsh ci restart worker -g my-resource-group

A single component is re-deployed through the API:

stsh api POST /boundaries/<boundary-id>/resourcegroups/my-resource-group/resources/containerinstances/worker/components/main/actions/redeploy