The Red Hat Edge Manager simplifies the management of a large number of devices and workloads through device fleets. A fleet is a resource that defines a group of devices governed by a common device template and management policies.

When you make a change to the device template, all devices in the fleet receive the changes when the Red Hat Edge Manager agent detects the new target specification.

Device monitoring in a fleet is also simplified because you can check the status summary of the whole fleet.

When vulnerability reporting is enabled, you can review CVE data aggregated for a fleet and drill into per-fleet impact from the Security overview page. For more information, see View fleet vulnerabilities.

Fleet-level management offers the following advantages:

• Scales your operations because you perform operations only once for each fleet instead of once for each device.
• Minimizes the risk of configuration mistakes and configuration drift.
• Automatically applies the target configuration when you add devices to the fleet or replace devices in the fleet.

The fleet specification consists of the following features:

Label selector

Determines which devices are part of the fleet.

Device template

Defines the configuration that the Red Hat Edge Manager enforces on devices in the fleet.

Policies

Govern how devices are managed, for example, how changes to the device template are rolled out to the devices.

A fleet resource does not run software itself; it carries a device template whose specification (including choices you make from the Software Catalog) is enforced on each device that matches the fleet label selector.

You can deploy or update catalog software on an individual device, or apply catalog items to a fleet so that the device template is updated and matching devices receive the software. Updates are available from the Catalog tab when you open a device or a fleet in the Flight Control web console.

Catalog updates use the same published upgrade paths for each catalog item, whether you target a single device or all devices governed by a fleet. See Validated upgrade paths and compatibility in the Additional resources section.

You can have both individually managed and fleet-managed devices at the same time. When a device is selected into a fleet, the Red Hat Edge Manager creates the device specification for the new device based on the device template. If you update the device template for a fleet or a new device joins the fleet, the Red Hat Edge Manager enforces the new specification in the fleet.

If a device is not selected into any fleets, the device is considered user-managed or unmanaged. For user-managed devices, you must update the device specification either manually or through an external automation.

Important

A device cannot be a member of more than one fleet at the same time.

For more information, see Labels and label selectors.

Device selection into a fleet

By default, devices are not assigned to a fleet. Instead, each fleet uses a selector that defines which labels a device must have to be added to the fleet.

Note

Fleet selectors always match devices based on labels. Values that the agent reports in status.systemInfo, such as hardware, operating system, or site attributes, are not directly selectable in fleet selectors.

Map those values to labels during enrollment by using label-from-systeminfo in the agent configuration. You can then use the resulting labels in fleet selectors and template placeholders. For more information, see Enrollment-time label mapping in the Additional resources section.

To understand how to use labels in a fleet, see the following example:

The following list shows point-of-sales terminal devices and their labels:

If all point-of-sales terminals use the same configuration and are managed by the same operations team, you can define a single fleet called pos-terminals with the type=pos-terminal label selector. Then, the fleet contains devices A, B, C, and D.

However, you might want to create separate fleets for the different organizations for development or production. You can define a fleet for development with the type=pos-terminal, stage=development label selector, which selects devices B and D. Then, you can define another fleet for production with the type=pos-terminal, stage=production label selector. By using the correct label selectors, you can manage both fleets independently.

Important

You must define selectors in a way that two fleets do not select the same device.

For example, if one fleet selects region=east, and another fleet selects stage=production, both fleets try to select device A. If two fleets try to select the same device, the Red Hat Edge Manager keeps the device in the currently assigned fleet, if any, and sets the MultipleOwners condition on the affected devices to true.

Fleets with mixed OS modes

Fleets can contain devices running in different OS modes (image and package). When a fleet template includes an OS image target, image-mode devices process the full spec normally, while package-mode devices reject the entire spec atomically. No partial configuration or application delivery occurs on package-mode devices that reject a spec. Package-mode devices appear as OutOfDate in fleet status when the fleet template includes an OS image they cannot apply.

For details, see Mixed-fleet behavior with image-mode and package-mode devices and Resolving mixed-fleet rollout issues in the Additional resources section.

Device templates

A device template of a fleet contains a device specification that is applied to all devices in the fleet when the template is updated.

For example, you can specify in the device template of a fleet that all devices in the fleet must run the registry.example.com/edge/rhel:9.5 operating system image.

The Red Hat Edge Manager service then rolls out the target specification to all devices in the fleet and the Red Hat Edge Manager agents update each device accordingly.

When the fleet template references Git, HTTP, or Kubernetes secret configuration providers, Red Hat Edge Manager can also create new template versions and roll out changes when those upstream sources change, without you editing the fleet specification. For details, see Automatic synchronization of external configuration in the Additional resources section.

You can change other specification items in the device template and the Red Hat Edge Manager applies the changes in the same way.

However, sometimes not all of the devices in the fleet need to have the exact same specification. Templates can contain placeholders that are populated based on the device name or label values.

The syntax of the placeholders matches that of Go templates. You can use simple text, actions, and conditional expressions such as if, else, else if, and with blocks, along with the comparison functions eq, ne, lt, gt, le, ge, and, or, and not.

The use of loops (range) in the placeholders is not supported.

You can reference anything from the metadata of a device, such as {{ .metadata.labels.key }} or {{ .metadata.name }}.

You can also use the following functions in your placeholders:

• The upper function changes the value to uppercase. For example, the function is {{ upper .metadata.name }}.
• The lower function changes the value to lowercase. For example, the function is {{ lower .metadata.labels.key }}.
• The replace function replaces all occurrences of a substring with another string. For example, the function is {{ replace "old" "new" .metadata.labels.key }}.
• The getOrDefault function returns a default value if accessing a missing label. For example, the function is {{ getOrDefault .metadata.labels "key" "default" }}.

You can combine the functions in pipelines, for example, a combined function is {{ getOrDefault .metadata.labels "key" "default" | upper | replace " " "-" }}.

Note

Ensure that you use proper Go template syntax. For example, {{ .metadata.labels.target-revision }} is not valid because of the hyphen. Instead, you must refer to the field as {{ index .metadata.labels "target-revision" }}.

You can use the placeholders in device templates in the following ways:

• You can label devices by deployment stage, for example, stage labels are stage: testing and stage: production. Then, you can use the label with the stage key as placeholder when referencing the operating system image to use, for example, use quay.io/myorg/myimage:latest-{{ .metadata.labels.stage }} or when referencing a configuration folder in a Git repository.
• You can label devices by deployment site, for example, deployment sites are site: factory-berlin and site: factory-madrid.
• Then, you can use the label with the site key as parameter when referencing the secret with network access credentials in Kubernetes.

Fleet device templates also support the catalogItemRef field as an alternative to the image field for both operating system and application entries. When you use catalogItemRef in a fleet device template, Red Hat Edge Manager resolves the catalog reference to a concrete OCI image URL during fleet-to-device rendering. All devices in the fleet receive the resolved image. For the complete field specification and YAML examples, see Catalog item reference field specification in the Additional resources section.

The following fields in device templates support placeholders:

When many devices share most of their configuration but differ in a few dimensions such as region or device type, you can use layered configuration and template placeholders to manage them in a single fleet instead of creating duplicate fleet definitions. For patterns and examples, see Fleet organization patterns in the Additional resources section.

To configure a fleet device template so that MicroShift clusters on devices in the fleet auto-register with Red Hat Advanced Cluster Management, see Configuring fleets to auto-register MicroShift clusters in the Additional resources section.