Red Hat Summit Red Hat SummitSuporteConsoleDesenvolvedoresComeçar um testeContato

Este conteúdo não está disponível no idioma selecionado.

Chapter 3. Administer MicroProfile in JBoss EAP

3.1. MicroProfile Telemetry administration
Copiar o link

3.1.1. Add MicroProfile Telemetry subsystem using the management CLI
Copiar o link

The MicroProfile Telemetry component is integrated into the default MicroProfile configuration through the microprofile-telemetry subsystem. You can also add the MicroProfile Telemetry subsystem using the management CLI if the subsystem is not included.

Prerequisites

  • The OpenTelemetry subsystem must be added to the configuration before adding the MicroProfile Telemetry subsystem. The MicroProfile Telemetry subsystem depends on the OpenTelemetry subsystem.

Procedure

  1. Open your terminal.

  2. Run the following command: 

    $ <JBOSS_HOME>/bin/jboss-cli.sh -c <<EOF
    if (outcome != success) of /subsystem=opentelemetry:read-resource
        /extension=org.wildfly.extension.opentelemetry:add()
        /subsystem=opentelemetry:add()
    end-if
    /extension=org.wildfly.extension.microprofile.telemetry:add
    /subsystem=microprofile-telemetry:add
    reload
EOF
    Copy to Clipboard Toggle word wrap

3.1.2. Enable MicroProfile Telemetry subsystem
Copiar o link

MicroProfile Telemetry is disabled by default and must be enabled on a per-application basis.

Prerequisites

  • The MicroProfile Telemetry subsystem has been added to the configuration.
  • The OpenTelemetry subsystem has been added to the configuration.

Procedure

  1. Open your microprofile-config.properties file.

  2. Set the otel.sdk.disabled property to false: 

    otel.sdk.disabled=false
    Copy to Clipboard Toggle word wrap

3.1.3. Override server configuration using MicroProfile Config
Copiar o link

You can override server configuration for individual applications in the MicroProfile Telemetry subsystem using MicroProfile Config.

For example, the service name used in exported traces by default is the same as the deployment archive. If the deployment archive is set to my-application-1.0.war, the service name will be the same. To override this configuration, you can change the value of the otel.service.name property in your configuration file: 

otel.service.name=My Application
Copy to Clipboard Toggle word wrap

3.2. MicroProfile Config configuration
Copiar o link

3.2.1. Adding properties in a ConfigSource management resource
Copiar o link

You can store properties directly in a config-source subsystem as a management resource.

Procedure

  • Create a ConfigSource and add a property: 

    /subsystem=microprofile-config-smallrye/config-source=props:add(properties={"name" = "jim"})
    Copy to Clipboard Toggle word wrap

3.2.2. Configuring directories as ConfigSources
Copiar o link

When a property is stored in a directory as a file, the file-name is the name of a property and the file content is the value of the property.

Procedure

  1. Create a directory where you want to store the files: 

    $ mkdir -p ~/config/prop-files/
    Copy to Clipboard Toggle word wrap

  2. Navigate to the directory: 

    $ cd ~/config/prop-files/
    Copy to Clipboard Toggle word wrap

  3. Create a file name to store the value for the property name: 

    $ touch name
    Copy to Clipboard Toggle word wrap

  4. Add the value of the property to the file: 

    $ echo "jim" > name
    Copy to Clipboard Toggle word wrap

  5. Create a ConfigSource in which the file name is the property and the file contents the value of the property: 

    /subsystem=microprofile-config-smallrye/config-source=file-props:add(dir={path=~/config/prop-files})
    Copy to Clipboard Toggle word wrap

    This results in the following XML configuration: 

    <subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0">
    <config-source name="file-props">
        <dir path="/etc/config/prop-files"/>
    </config-source>
</subsystem>
    Copy to Clipboard Toggle word wrap

3.2.3. Configuring root directories as ConfigSources
Copiar o link

You can define a directory as a root directory for multiple MicroProfile ConfigSource directories using the root attribute.

The nested root attribute is part of the dir complex attribute for the /subsystem=microprofile-config-smallrye/config-source=* resource. This eliminates the need to specify multiple ConfigSource directories if they share the same root directory.

Any files directly within the root directory are ignored. They will not be used for configuration. Top-level directories are treated as ConfigSources. Any nested directories will also be ignored.

Note

ConfigSources for top-level directories are assigned the ordinal of the /subsystem=microprofile-config-smallrye/config-source=* resource by default.

If the top-level directory contains a config_ordinal file, the value specified in the file will override the default ordinal value. If two top-level directories with the same ordinal contain the same entry, the names of the directories are sorted alphabetically and the first directory is used.

Prerequisites

  • You have installed the MicroProfile Config extension and enabled the microprofile-config-smallrye subsystem.

Procedure

  1. Open your terminal.

  2. Create a directory where you want to store your files: 

    mkdir -p ~/etc/config/prop-files/
    Copy to Clipboard Toggle word wrap

  3. Navigate to the directory that you created: 

    cd ~/etc/config/prop-files/
    Copy to Clipboard Toggle word wrap

  4. Create a file name to store the value for the property name: 

    touch name
    Copy to Clipboard Toggle word wrap

  5. Add the value of the property to the file: 

    echo "jim" > name
    Copy to Clipboard Toggle word wrap

  6. Run the following command in the CLI to create a ConfigSource in which the filename is the property and the file contains the value of the property: 

    /subsystem=microprofile-config-smallrye/config-source=prop-files:add(dir={path=/etc/config, root=true})
    Copy to Clipboard Toggle word wrap

  7. This results in the XML configuration: 

    <subsystem
xmlns="urn:wildfly:microprofile-config-smallrye:2.0">
 <config-source name="prop-files">
   <dir path="/etc/config" root="true"/>
 </config-source>
</subsystem>
    Copy to Clipboard Toggle word wrap

3.2.4. Obtaining ConfigSource from a ConfigSource class
Copiar o link

You can create and configure a custom org.eclipse.microprofile.config.spi.ConfigSource implementation class to provide a source for the configuration values.

Procedure

  • The following management CLI command creates a ConfigSource for the implementation class named org.example.MyConfigSource that is provided by a JBoss module named org.example.

    If you want to use a ConfigSource from the org.example module, add the <module name="org.eclipse.microprofile.config.api"/> dependency to the path/to/org/example/main/module.xml file. 

    /subsystem=microprofile-config-smallrye/config-source=my-config-source:add(class={name=org.example.MyConfigSource, module=org.example})
    Copy to Clipboard Toggle word wrap

    This command results in the following XML configuration for the microprofile-config-smallrye subsystem. 

    <subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0">
    <config-source name="my-config-source">
        <class name="org.example.MyConfigSource" module="org.example"/>
    </config-source>
</subsystem>
    Copy to Clipboard Toggle word wrap

Properties provided by the custom org.eclipse.microprofile.config.spi.ConfigSource implementation class are available to any JBoss EAP deployment.

3.2.5. Obtaining ConfigSource configuration from a ConfigSourceProvider class
Copiar o link

You can create and configure a custom org.eclipse.microprofile.config.spi.ConfigSourceProvider implementation class that registers implementations for multiple ConfigSource instances.

Procedure

  • Create a config-source-provider: 

    /subsystem=microprofile-config-smallrye/config-source-provider=my-config-source-provider:add(class={name=org.example.MyConfigSourceProvider, module=org.example})
    Copy to Clipboard Toggle word wrap

    The command creates a config-source-provider for the implementation class named org.example.MyConfigSourceProvider that is provided by a JBoss Module named org.example.

    If you want to use a config-source-provider from the org.example module, add the <module name="org.eclipse.microprofile.config.api"/> dependency to the path/to/org/example/main/module.xml file.

    This command results in the following XML configuration for the microprofile-config-smallrye subsystem: 

    <subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0">
    <config-source-provider name="my-config-source-provider">
         <class name="org.example.MyConfigSourceProvider" module="org.example"/>
    </config-source-provider>
</subsystem>
    Copy to Clipboard Toggle word wrap

Properties provided by the ConfigSourceProvider implementation are available to any JBoss EAP deployment.

3.3. MicroProfile Fault Tolerance configuration
Copiar o link

3.3.1. Adding the MicroProfile Fault Tolerance extension
Copiar o link

The MicroProfile Fault Tolerance extension is included in standalone-microprofile.xml and standalone-microprofile-ha.xml configurations that are provided as part of JBoss EAP XP.

The extension is not included in the standard standalone.xml configuration. To use the extension, you must manually enable it.

Prerequisites

  • JBoss EAP 8.0 with JBoss EAP XP 5.0 is installed.

Procedure

  1. Add the MicroProfile Fault Tolerance extension using the following management CLI command: 

    /extension=org.wildfly.extension.microprofile.fault-tolerance-smallrye:add
    Copy to Clipboard Toggle word wrap

  2. Enable the microprofile-fault-tolerance-smallrye subsystem using the following managenent command: 

    /subsystem=microprofile-fault-tolerance-smallrye:add
    Copy to Clipboard Toggle word wrap

  3. Reload the server with the following management command: 

    reload
    Copy to Clipboard Toggle word wrap

3.4. MicroProfile Health configuration
Copiar o link

3.4.1. Examining health using the management CLI
Copiar o link

You can check system health using the management CLI.

Procedure

  • Examine health: 

    /subsystem=microprofile-health-smallrye:check
{
    "outcome" => "success",
    "result" => {
        "status" => "UP",
        "checks" => []
    }
}
    Copy to Clipboard Toggle word wrap

3.4.2. Examining health using the management console
Copiar o link

You can check system health using the management console.

A check runtime operation shows the health checks and the global outcome as boolean value.

Procedure

  1. Navigate to the Runtime tab and select the server.
  2. In the Monitor column, click MicroProfile Health View.

3.4.3. Examining health using the HTTP endpoint
Copiar o link

Health check is automatically deployed to the health context on JBoss EAP, so you can obtain the current health using the HTTP endpoint.

The default address for the /health endpoint, accessible from the management interface, is http://127.0.0.1:9990/health.

Procedure

  • To obtain the current health of the server using the HTTP endpoint, use the following URL:. 

    http://<host>:<port>/health
    Copy to Clipboard Toggle word wrap

    Accessing this context displays the health check in JSON format, indicating if the server is healthy.

3.4.4. Enabling authentication for MicroProfile Health
Copiar o link

You can configure the health context to require authentication for access.

Procedure

  1. Set the security-enabled attribute to true on the microprofile-health-smallrye subsystem. 

    /subsystem=microprofile-health-smallrye:write-attribute(name=security-enabled,value=true)
    Copy to Clipboard Toggle word wrap

  2. Reload the server for the changes to take effect. 

    reload
    Copy to Clipboard Toggle word wrap

Any subsequent attempt to access the /health endpoint triggers an authentication prompt.

3.4.5. Readiness probes that determine server health and readiness
Copiar o link

JBoss EAP XP 5.0.0 supports three readiness probes to determine server health and readiness.

  • server-status - returns UP when the server-state is running.
  • boot-errors - returns UP when the probe detects no boot errors.
  • deployment-status - returns UP when the status for all deployments is OK.

These readiness probes are enabled by default. You can disable the probes using the MicroProfile Config property mp.health.disable-default-procedures.

The following example illustrates the use of the three probes with the check operation: 

[standalone@localhost:9990 /] /subsystem=microprofile-health-smallrye:check
{
    "outcome" => "success",
    "result" => {
        "status" => "UP",
        "checks" => [
            {
                "name" => "boot-errors",
                "status" => "UP"
            },
            {
                "name" => "server-state",
                "status" => "UP",
                "data" => {"value" => "running"}
            },
            {
                "name" => "empty-readiness-checks",
                "status" => "UP"
            },
            {
                "name" => "deployments-status",
                "status" => "UP"
            },
            {
                "name" => "empty-liveness-checks",
                "status" => "UP"
            },
            {
                "name" => "empty-startup-checks",
                "status" => "UP"
            }
        ]
    }
}
Copy to Clipboard Toggle word wrap

3.4.6. Global status when probes are not defined
Copiar o link

The :empty-readiness-checks-status, :empty-liveness-checks-status, and :empty-startup-checks-status management attributes specify the global status when no readiness, liveness, or startup probes are defined.

These attributes allow applications to report ‘DOWN’ until their probes verify that the application is ready, live, or started up. By default, applications report ‘UP’.

  • The :empty-readiness-checks-status attribute specifies the global status for readiness probes if no readiness probes have been defined: 

    /subsystem=microprofile-health-smallrye:read-attribute(name=empty-readiness-checks-status)
{
    "outcome" => "success",
    "result" => expression "${env.MP_HEALTH_EMPTY_READINESS_CHECKS_STATUS:UP}"
}
    Copy to Clipboard Toggle word wrap

  • The :empty-liveness-checks-status attribute specifies the global status for liveness probes if no liveness probes have been defined: 

    /subsystem=microprofile-health-smallrye:read-attribute(name=empty-liveness-checks-status)
{
    "outcome" => "success",
    "result" => expression "${env.MP_HEALTH_EMPTY_LIVENESS_CHECKS_STATUS:UP}"
}
    Copy to Clipboard Toggle word wrap

  • The :empty-startup-checks-status attribute specifies the global status for startup probes if no startup probes have been defined: 

    /subsystem=microprofile-health-smallrye:read-attribute(name=empty-startup-checks-status)
{
    "outcome" => "success",
    "result" => expression "${env.MP_HEALTH_EMPTY_STARTUP_CHECKS_STATUS:UP}"
}
    Copy to Clipboard Toggle word wrap

    The /health HTTP endpoint and the :check operation that check readiness, liveness, and startup probes also take into account these attributes.

You can also modify these attributes as shown in the following example: 

/subsystem=microprofile-health-smallrye:write-attribute(name=empty-readiness-checks-status,value=DOWN)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
Copy to Clipboard Toggle word wrap

3.5. MicroProfile JWT configuration
Copiar o link

3.5.1. Enabling microprofile-jwt-smallrye subsystem
Copiar o link

The MicroProfile JWT integration is provided by the microprofile-jwt-smallrye subsystem and is included in the default configuration. If the subsystem is not present in the default configuration, you can add it as follows.

Prerequisites

  • JBoss EAP 8.0 with JBoss EAP XP 5.0 is installed.

Procedure

  1. Enable the MicroProfile JWT smallrye extension in JBoss EAP: 

    /extension=org.wildfly.extension.microprofile.jwt-smallrye:add
    Copy to Clipboard Toggle word wrap

  2. Enable the microprofile-jwt-smallrye subsystem: 

    /subsystem=microprofile-jwt-smallrye:add
    Copy to Clipboard Toggle word wrap

  3. Reload the server: 

    reload
    Copy to Clipboard Toggle word wrap

The microprofile-jwt-smallrye subsystem is enabled.

3.6. MicroProfile OpenAPI administration
Copiar o link

3.6.1. Enabling MicroProfile OpenAPI
Copiar o link

The microprofile-openapi-smallrye subsystem is provided in the standalone-microprofile.xml configuration. However, JBoss EAP XP uses the standalone.xml by default. You must include the subsystem in standalone.xml to use it.

Alternatively, you can follow the procedure Updating standalone configurations with MicroProfile subsystems and extensions to update the standalone.xml configuration file.

Procedure

  1. Enable the MicroProfile OpenAPI smallrye extension in JBoss EAP: 

    /extension=org.wildfly.extension.microprofile.openapi-smallrye:add()
    Copy to Clipboard Toggle word wrap

  2. Enable the microprofile-openapi-smallrye subsystem using the following management command: 

    /subsystem=microprofile-openapi-smallrye:add()
    Copy to Clipboard Toggle word wrap

  3. Reload the server. 

    reload
    Copy to Clipboard Toggle word wrap

The microprofile-openapi-smallrye subsystem is enabled.

3.6.2. Requesting an MicroProfile OpenAPI document using Accept HTTP header
Copiar o link

Request an MicroProfile OpenAPI document, in the JSON format, from a deployment using an Accept HTTP header.

By default, the OpenAPI endpoint returns a YAML document.

Prerequisites

  • The deployment being queried is configured to return an MicroProfile OpenAPI document.

Procedure

  • Issue the following curl command to query the /openapi endpoint of the deployment: 

    $ curl -v -H'Accept: application/json' http://localhost:8080/openapi
< HTTP/1.1 200 OK
...
{"openapi": "3.0.1" ... }
    Copy to Clipboard Toggle word wrap

    Replace http://localhost:8080 with the URL and port of the deployment.

    The Accept header indicates that the JSON document is to be returned using the application/json string.

3.6.3. Requesting an MicroProfile OpenAPI document using an HTTP parameter
Copiar o link

Request an MicroProfile OpenAPI document, in the JSON format, from a deployment using a query parameter in an HTTP request.

By default, the OpenAPI endpoint returns a YAML document.

Prerequisites

  • The deployment being queried is configured to return an MicroProfile OpenAPI document.

Procedure

  • Issue the following curl command to query the /openapi endpoint of the deployment: 

    $ curl -v http://localhost:8080/openapi?format=JSON
< HTTP/1.1 200 OK
...
    Copy to Clipboard Toggle word wrap

    Replace http://localhost:8080 with the URL and port of the deployment.

    The HTTP parameter format=JSON indicates that JSON document is to be returned.

3.6.4. Configuring JBoss EAP to serve a static OpenAPI document
Copiar o link

Configure JBoss EAP to serve a static OpenAPI document that describes the REST services for the host.

When JBoss EAP is configured to serve a static OpenAPI document, the static OpenAPI document is processed before any Jakarta RESTful Web Services and MicroProfile OpenAPI annotations.

In a production environment, disable annotation processing when serving a static document. Disabling annotation processing ensures that an immutable and versioned API contract is available for clients.

Procedure

  1. Create a directory in the application source tree: 

    $ mkdir APPLICATION_ROOT/src/main/webapp/META-INF
    Copy to Clipboard Toggle word wrap

    APPLICATION_ROOT is the directory containing the pom.xml configuration file for the application.

  2. Query the OpenAPI endpoint, redirecting the output to a file: 

    $ curl http://localhost:8080/openapi?format=JSON > src/main/webapp/META-INF/openapi.json
    Copy to Clipboard Toggle word wrap

    By default, the endpoint serves a YAML document, format=JSON specifies that a JSON document is returned.

  3. Configure the application to skip annotation scanning when processing the OpenAPI document model: 

    $ echo "mp.openapi.scan.disable=true" > APPLICATION_ROOT/src/main/webapp/META-INF/microprofile-config.properties
    Copy to Clipboard Toggle word wrap

  4. Rebuild the application: 

    $ mvn clean install
    Copy to Clipboard Toggle word wrap

  5. Deploy the application again using the following management CLI commands:

    1. Undeploy the application: 

      undeploy microprofile-openapi.war
      Copy to Clipboard Toggle word wrap

    2. Deploy the application: 

      deploy APPLICATION_ROOT/target/microprofile-openapi.war
      Copy to Clipboard Toggle word wrap

JBoss EAP now serves a static OpenAPI document at the OpenAPI endpoint.

3.6.5. Disabling microprofile-openapi-smallrye
Copiar o link

You can disable the microprofile-openapi-smallrye subsystem in JBoss EAP XP using the management CLI.

Procedure

  • Disable the microprofile-openapi-smallrye subsystem: 

    /subsystem=microprofile-openapi-smallrye:remove()
    Copy to Clipboard Toggle word wrap

3.7. MicroProfile Reactive Messaging administration
Copiar o link

If you want to enable asynchronous reactive messaging to your instance of JBoss EAP, you must add its extension through the JBoss EAP management CLI.

Prerequisites

Procedure

  1. Open the JBoss EAP management CLI.
  2. Enter the following code: 
[standalone@localhost:9990 /] /extension=org.wildfly.extension.microprofile.reactive-messaging-smallrye:add
{"outcome" => "success"}

[standalone@localhost:9990 /] /subsystem=microprofile-reactive-messaging-smallrye:add
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
Copy to Clipboard Toggle word wrap
Note

If you provision a server using Galleon, either on OpenShift or not, make sure you include the microprofile-reactive-messaging Galleon layer to get the core MicroProfile 2.0.1 and reactive messaging functionality, and to enable the required subsystems and extensions. Note that this configuration does not contain the JBoss EAP modules you need to enable connectors. Use the microprofile-reactive-messaging-kafka layer or the microprofile-reactive-messaging-amqp layer to enable the Kafka connector or the AMQP connector, respectively.

Verification

You have successfully added the required MicroProfile Reactive Messaging extension and subsystem for JBoss EAP if you see success in two places in the resulting code in the management CLI.

Tip

If the resulting code says reload-required, you have to reload your server configuration to completely apply all of your changes. To reload, in a standalone server CLI, enter reload.

3.8. Standalone server configuration
Copiar o link

3.8.1. Standalone server configuration files
Copiar o link

The JBoss EAP XP includes additional standalone server configuration files, standalone-microprofile.xml and standalone-microprofile-ha.xml.

Standard configuration files that are included with JBoss EAP remain unchanged. Note that JBoss EAP XP 5.0.0 does not support the use of domain.xml files or domain mode.

Expand
Table 3.1. Standalone configuration files available in JBoss EAP XP
Configuration FilePurposeIncluded capabilitiesExcluded capabilities

standalone.xml

This is the default configuration that is used when you start your standalone server.

Includes information about the server, including subsystems, networking, deployments, socket bindings, and other configurable details.

Excludes subsystems necessary for messaging or high availability.

standalone-microprofile.xml

This configuration file supports applications that use MicroProfile.

Includes information about the server, including subsystems, networking, deployments, socket bindings, and other configurable details.

Excludes the following capabilities:

  • Jakarta Enterprise Beans
  • Messaging
  • Jakarta EE Batch
  • Jakarta Server Faces
  • Jakarta Enterprise Beans timers

standalone-ha.xml

 

Includes default subsystems and adds the modcluster and jgroups subsystems for high availability.

Excludes subsystems necessary for messaging.

standalone-microprofile-ha.xml

This standalone file supports applications that use MicroProfile.

Includes the modcluster and jgroups subsystems for high availability in addition to default subsystems.

Excludes subsystems necessary for messaging.

standalone-full.xml

 

Includes the messaging-activemq and iiop-openjdk subsystems in addition to default subsystems.

 

standalone-full-ha.xml

Support for every possible subsystem.

Includes subsystems for messaging and high availability in addition to default subsystems.

 

standalone-load-balancer.xml

Support for the minimum subsystems necessary to use the built-in mod_cluster front-end load balancer to load balance other JBoss EAP instances.

  

By default, starting JBoss EAP as a standalone server uses the standalone.xml file. To start JBoss EAP with a standalone MicroProfile configuration, use the -c argument. For example, 

$ <EAP_HOME>/bin/standalone.sh -c=standalone-microprofile.xml
Copy to Clipboard Toggle word wrap

You can update standard standalone server configuration files with MicroProfile subsystems and extensions using the docs/examples/enable-microprofile.cli script. The enable-microprofile.cli script is intended as an example script for updating standard standalone server configuration files, not custom configurations.

The enable-microprofile.cli script modifies the existing standalone server configuration and adds the following MicroProfile subsystems and extensions if they do not exist in the standalone configuration file:

  • microprofile-config-smallrye
  • microprofile-fault-tolerance-smallrye
  • microprofile-health-smallrye
  • microprofile-jwt-smallrye
  • microprofile-openapi-smallrye

The enable-microprofile.cli script outputs a high-level description of the modifications. The configuration is secured using the elytron subsystem. The security subsystem, if present, is removed from the configuration.

Prerequisites

  • JBoss EAP 8.0 with JBoss EAP XP 5.0 is installed.

Procedure

  1. Run the following CLI script to update the default standalone.xml server configuration file: 

    $ <EAP_HOME>/bin/jboss-cli.sh --file=docs/examples/enable-microprofile.cli
    Copy to Clipboard Toggle word wrap

  2. Select a standalone server configuration other than the default standalone.xml server configuration file using the following command: 

    $ <EAP_HOME>/bin/jboss-cli.sh --file=docs/examples/enable-microprofile.cli -Dconfig=<standalone-full.xml|standalone-ha.xml|standalone-full-ha.xml>
    Copy to Clipboard Toggle word wrap
  3. The specified configuration file now includes MicroProfile subsystems and extensions.
Voltar ao topo
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2025 Red Hat