Configuration file and resource management of wildfly 21

brief introduction

In the last article, we introduced the basic use and management interface of wildfly 21. Today, we will explain the configuration file and resource management of wildfly in detail.

Profile for wildfly

Whether in standalone or domain mode, it is very important to have two configuration files. They are standalone XML and domain xml。

Other standalone – * XML can refer to standalone. XML XML to configure

Let’s look at standalone General structure of XML:

<server xmlns="urn:jboss:domain:14.0">
<extensions>
...
</extensions>
<management>
...
</management>
<profile>
...
</profile>
<interfaces>
    ...
</interfaces>
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
    ...
</socket-binding-group>
</server>

Server mainly has five parts: extensions, management, profile, interfaces and socket binding group.

extensions

Extensions represent modules outside the core application. With these external modules, the wildfly core application is very simple and lightweight.

These external modules are placed in the modules folder. We can refer to them by using the extension tag:

<extensions>
    [...]
    <extension module="org.jboss.as.transactions"/>
    <extension module="org.jboss.as.webservices" />
    <extension module="org.jboss.as.weld" />
    [...]
    <extension module="org.wildfly.extension.undertow"/>
</extensions>

profile

A profile is composed of multiple subsystems. Subsystem is a set of new functions added to the core server through extension.

Let’s look at an example of profile and subsystem:

<profile>
        <subsystem xmlns="urn:jboss:domain:logging:8.0">
            <console-handler name="CONSOLE">
                <level name="INFO"/>
                <formatter>
                    <named-formatter name="COLOR-PATTERN"/>
                </formatter>
            </console-handler>
            <periodic-rotating-file-handler name="FILE" autoflush="true">
                <formatter>
                    <named-formatter name="PATTERN"/>
                </formatter>
                <file relative-to="jboss.server.log.dir" path="server.log"/>
                <suffix value=".yyyy-MM-dd"/>
                <append value="true"/>
            </periodic-rotating-file-handler>
            <logger category="com.arjuna">
                <level name="WARN"/>
            </logger>
            <logger category="io.jaegertracing.Configuration">
                <level name="WARN"/>
            </logger>
            <logger category="org.jboss.as.config">
                <level name="DEBUG"/>
            </logger>
            <logger category="sun.rmi">
                <level name="WARN"/>
            </logger>
            <root-logger>
                <level name="INFO"/>
                <handlers>
                    <handler name="CONSOLE"/>
                    <handler name="FILE"/>
                </handlers>
            </root-logger>
            <formatter name="PATTERN">
                <pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
            </formatter>
            <formatter name="COLOR-PATTERN">
                <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
            </formatter>
        </subsystem>
</profile>

The above code configures a JBoss: domain: logging, and sets the log format, log level and other information.

Basically domain XML and standalone The content of the profile in XML is the same, but the difference is domain Multiple profiles can be configured in XML, while standalone. XML XML can only have one profile.

path

In the above log configuration, we used the path attribute of file in periodic rotating file handler. You need to specify the location of the log file in the path attribute.

<file relative-to="jboss.server.log.dir" path="server.log"/>

Here we use server Log, in fact, there are many built-in path variables in wildfly:

• jboss. home. Dir – the root directory of wildfly
• user. Home – user’s home directory
• user. Dir – the user’s current working directory
• java. Home – Java installation directory
• jboss. server. base. Dir – the root directory of the server instance
• jboss. server. config. Dir – configuration file directory of the server instance
• jboss. server. data. Dir – data directory of the server instance
• jboss. server. log. Dir – log directory of the server instance
• jboss. server. temp. Dir – temp directory of the server instance
• jboss. controller. temp. Dir – temp directory of controller instance
• jboss. domain. servers. Dir – the working directory created by host controller for servers in managed domain mode

In addition to the top five paths, users can customize or rewrite other built-in paths:

<path name="example" path="example" relative-to="jboss.server.data.dir"/>

Where name refers to the name of path, and path is the value of path. If there is no relative to, it is an absolute path, and if there is no relative to, it is a relative path.

Relative to represents the benchmark of the relative path.

The above format can only be in standalone Used in XML files. If you want to be in domain XML, you must use the following format:

<path name="x"/>

The name here is only for host A reference to the path definition in the XML file:

<path name="x" path="/var/x" />

interface

Iterface represents a network interface, which can be either a hostname or an IP address. It is used for the subsequent sockets binding.

Let’s take an example of an interface:

    <interfaces>
        <interface name="management">
            <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
        </interface>
        <interface name="public">
            <inet-address value="${jboss.bind.address:127.0.0.1}"/>
        </interface>
    </interfaces>

Similarly, if it is in domain The interface tag in XML can only contain the name attribute:

<interface name="internal"/>

This reference is defined in host XML.

socket-binding

Socket binding defines the network exit. By specifying the bound IP and interface, you can finally access the corresponding services through this address:

    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
        <socket-binding name="http" port="${jboss.http.port:8080}"/>
        <socket-binding name="https" port="${jboss.https.port:8443}"/>
        <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="${jboss.mail.server.host:localhost}" port="${jboss.mail.server.port:25}"/>
        </outbound-socket-binding>
    </socket-binding-group>

In the above example, we have defined the addresses of AJP, HTTP and HTTPS, as well as several management side, transaction and mail addresses.

Note that we have a property called port offset, which can set the offset of the standard interface, especially when the standard interface is occupied.

For example, our default HTTP port is 8080. If this port is already occupied, we can pass in a port offset = 100, so that the HTTP port becomes 8180, which is very convenient.

management

Management is the configuration of the wildfly management end. We know that the management of wildfly can be carried out through the web end or cli end of wildfly.

Let’s look at the definition of management:

    <management>
        <security-realms>
            <security-realm name="ManagementRealm">
                <authentication>
                    <local default-user="$local" skip-group-loading="true"/>
                    <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
                </authentication>
                <authorization map-groups-to-roles="false">
                    <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
                </authorization>
            </security-realm>
        </security-realms>
        <audit-log>
            <formatters>
                <json-formatter name="json-formatter"/>
            </formatters>
            <handlers>
                <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/>
            </handlers>
            <logger log-boot="true" log-read-only="false" enabled="false">
                <handlers>
                    <handler name="file"/>
                </handlers>
            </logger>
        </audit-log>
        <management-interfaces>
            <http-interface security-realm="ManagementRealm">
                <http-upgrade enabled="true"/>
                <socket-binding http="management-http"/>
            </http-interface>
        </management-interfaces>
        <access-control provider="simple">
            <role-mapping>
                <role name="SuperUser">
                    <include>
                        <user name="$local"/>
                    </include>
                </role>
            </role-mapping>
        </access-control>
    </management>

In the above example, we specify the access address of the management side and the security policy to be used through management interfaces.

In security realms, we can define a variety of security realms. User information and group information can be defined in security realm.

resource management

Wildfly provides two ways of resource management, one is through the webhttp://host: 9990 / console, one is through the command line:

./bin/jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server
or 'help' for the list of supported commands.
[disconnected /]
 
[disconnected /] connect
[[email protected]:9990 /]

Everyone on the web side should know how to use it. Here we focus on the use of the command line side.

We can get the commands that can be executed on the command line through help — commands:

attachment                              deployment enable-all                   module                                  security enable-http-auth-http-server
batch                                   deployment info                         patch apply                             security enable-http-auth-management
cd                                      deployment list                         patch history                           security enable-sasl-management
clear                                   deployment undeploy                     patch info                              security enable-ssl-http-server
command                                 deployment undeploy-cli-archive         patch inspect                           security enable-ssl-management
command-timeout                         deployment-info                         pwd                                     security reorder-sasl-management
connect                                 deployment-overlay                      quit                                    set
connection-info                         echo                                    read-attribute                          shutdown
data-source                             echo-dmr                                read-operation                          try
deploy                                  for                                     reload                                  undeploy
deployment deploy-cli-archive           grep                                    run-batch                               unset
deployment deploy-file                  help                                    security disable-http-auth-http-server  version
deployment deploy-url                   history                                 security disable-http-auth-management   xa-data-source
deployment disable                      if                                      security disable-sasl-management
deployment disable-all                  jdbc-driver-info                        security disable-ssl-http-server
deployment enable                       ls                                      security disable-ssl-management

In addition, the command line also provides a series of operators for resources to operate on resources.

In wildfly, manageable objects are regarded as resources one by one. We can access this resource through the path of the resource.

For example, I’d like to take a look at the resource named default server, which can be as follows:

 /server=default-server 

Resource paths can be concatenated, for example:

/subsystem=undertow/server=default-server/http-listener=default

These are valid resource paths.

With the resource path, we also need to provide operators to operate resources. Wildfly provides the following operators:

add

read-attribute

read-children-names

read-children-resources

read-children-types

read-operation-description

read-operation-names

read-resource

read-resource-description

remove

validate-address

write-attribute

We can use operators by prefixing them with colons:

/subsystem=logging:read-operation-names

The above example will get the operators for the logging subsystem:

{
    "outcome" => "success",
    "result" => [
        "add",
        "list-add",
        "list-clear",
        "list-get",
        "list-log-files",
        "list-remove",
        "map-clear",
        "map-get",
        "map-put",
        "map-remove",
        "query",
        "read-attribute",
        "read-attribute-group",
        "read-attribute-group-names",
        "read-children-names",
        "read-children-resources",
        "read-children-types",
        "read-log-file",
        "read-operation-description",
        "read-operation-names",
        "read-resource",
        "read-resource-description",
        "remove",
        "undefine-attribute",
        "whoami",
        "write-attribute"
    ]
}

summary

This article explains the operations related to the configuration file and resource management of wildfly. I hope you can like it.

Author: what about the flybean program

Link to this article:http://www.flydean.com/wildfly-config-resource/

Source of this article: flybean’s blog

Welcome to my official account: the most popular interpretation of “those things”, the most profound dry cargo, the most concise tutorial, and many small tricks you don’t know, etc. you’ll find them!