Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

このコンテンツは選択した言語では利用できません。

Chapter 1. Red Hat Edge Manager architecture

You can manage individual devices or an entire fleet by using the Red Hat Edge Manager. The Red Hat Edge Manager uses an agent-based architecture that allows for a scalable and robust device management, even with limited network conditions.

By deploying a Red Hat Edge Manager agent to a device, the agent autonomously manages and monitors the device while periodically communicating with the Red Hat Edge Manager service to check for new configurations and to report device status.

The Red Hat Edge Manager supports image-based operating systems. You can include the Red Hat Edge Manager agent and the agent configuration in the image that is distributed to the devices.

Image-based operating systems allow the agent to initiate a transactional update of the image and to roll back to the previous version in case of an update error.

The Red Hat Edge Manager architecture has the following main features:

  • Agent
  • Service
  • Image-based operating system
  • API server
  • Database
  • Device
  • Device fleet

Learn more details from the following sections:

1.1. Red Hat Edge Manager agent and service
リンクのコピー

The Red Hat Edge Manager agent is a process running on each managed device that periodically communicates with the Red Hat Edge Manager service.

The agent is responsible for the following tasks:

  • Enrolling devices into the service
  • Periodically checking with the service for changes in the device specification, such as changes to the operating system, configuration, and applications
  • Applying any updates independently from the service
  • Reporting status of the device and the applications

The Red Hat Edge Manager service is responsible for the following tasks:

  • Authenticating and authorizing users and agents
  • Enrolling devices
  • Managing device inventory
  • Reporting status from individual devices or fleets

The service also communicates with a database that stores the device inventory and the target device configuration. When communicating with the service, the agent polls the service for changes in the configuration. If the agent detects that the current configuration deviates from the target configuration, the agent attempts to apply the changes to the device.

When the agent receives a new target configuration from the service, the agent does the following tasks:

  1. To avoid depending on network connectivity during the update, the agent downloads all required resources, such as the operating system image and application container images, over the network to disk.
  2. The agent updates the operating system image by delegating to bootc.
  3. The agent updates configuration files on the file system of the device by overlaying a set of files that the service sends to the device.
  4. If necessary, the agent reboots into the new operating system. Otherwise, the agent signals system services and applications to reload the updated configuration.
  5. The agent updates applications running on Podman or MicroShift.

If the update fails or the system does not return online after rebooting, the agent automatically rolls back to the previous operating system image and configuration.

Note: You can maintain fleet definitions in Git. The Red Hat Edge Manager periodically syncs with the fleet definitions in the database.

1.2. Red Hat Edge Manager API server
リンクのコピー

The API server is a core component of the Red Hat Edge Manager service that allows users and agents to communicate with the service.

The API server exposes the following endpoints:

User-facing API endpoint
Users can connect to the user-facing API endpoint from the CLI or the web console. Users must authenticate with the configured external authentication service to obtain a JSON Web Token (JWT) to make HTTPS requests.
Agent-facing API endpoint
Agents connect to the agent-facing endpoint, which is mTLS-protected. The service authenticates devices using the X.509 client certificates.

The Red Hat Edge Manager service also communicates with various external systems to authenticate and authorize users, get mTLS certificates signed, or query configuration for managed devices.

1.3. Device enrollment
リンクのコピー

You need to enroll devices to a Red Hat Edge Manager service before you can start managing them. The Red Hat Edge Manager agent that runs on a device handles the device enrollment.

When the agent starts on a device, the agent searches for the configuration in the /etc/flightctl/config.yaml file. The file defines the following configurations:

  • The enrollment endpoint, which is the Red Hat Edge Manager service that the agent connects to for enrollment.
  • The enrollment certificate, which is the X.509 client certificate and key that the agent only uses to securely request enrollment from the Red Hat Edge Manager service.
  • Optional: Any additional agent configuration.

The agent starts the enrollment process by searching for the enrollment endpoint, the Red Hat Edge Manager service, that is defined in the configuration file.

After establishing a secure, mTLS-protected network connection with the service, the agent submits an enrollment request to the service.

The request includes a description of hardware and operating system of the device, a X.509 certificate signing request, and the cryptographic identity of the device.

The enrollment request must be approved by an authorized user. After the request is approved, the device becomes trusted and managed by the Red Hat Edge Manager service.

1.3.1. Enrollment methods
リンクのコピー

You can provision the enrollment endpoint and certificate to the device in the following ways:

Early binding: You can build an operating system image that includes the enrollment endpoint and certificate. Devices using an early binding image can automatically connect to the defined Red Hat Edge Manager service to request enrollment, without depending on any provisioning infrastructure.

The devices share the same long-lived X.509 client certificate. However, in this case, the devices are bound to a specific service and owner.

Late binding: You can define the enrollment endpoint and certificate at provisioning time instead of including them in the operating system image. Devices using a late binding image are not bound to a single owner or service and can have device-specific, short-lived X.509 client certificates.

However, late binding requires virtualization or bare metal provisioning infrastructure that can request device-specific enrollment endpoints and certificates from the Red Hat Edge Manager service and inject them into the provisioned system by using mechanisms such as https://cloud-init.io/, https://coreos.github.io/ignition/supported-platforms/, or https://anaconda-installer.readthedocs.io/en/latest/kickstart.html.

Note

Note: The enrollment certificate is only used to secure the network connection for submitting an enrollment request. The enrollment certificate is not involved in the actual verification or approval of the enrollment request. The enrollment certificate is no longer used with enrolled devices, as the devices rely on device-specific management certificates instead.

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat