WildFly CLI Concepts: Difference between revisions
(Created page with "=Internal= * WildFly CLI") |
No edit summary |
||
| (77 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=Internal= | =Internal= | ||
* [[WildFly CLI#Subjects|WildFly CLI]] | * [[WildFly CLI#Subjects|CLI]] | ||
=TODO= | |||
<font color=red>Continue processing https://developer.jboss.org/wiki/CommandLineInterface, https://developer.jboss.org/wiki/JBossAS7Command-lineOperationRequestFormat, https://developer.jboss.org/wiki/CLICompoundValueFormat</font> | |||
=Overview= | |||
The management CLI is a command line administration tool that manages WildFly nodes running in both standalone and domain mode. The tool exercises the [[WildFly Management Interfaces|native management API of the application server]]. The CLI client works with a managed domain or a standalone instance, allowing the user to control either the ''domain controller'' or the ''standalone server'' and execute management operations through a de-typed (string-driven) management model. | |||
The Management CLI may be used to start and stop servers, deploy and undeploy applications, configure system settings and perform other administrative tasks. Operations can be performed in ''batch mode'', allowing multiple tasks to be executed as a group. | |||
The Management CLI can perform all tasks the web-based [[WildFly Management Console|management console]] can perform, as well as many other lower level operations that are not available to the web-based administration tool. | |||
For servers running in domain mode, the CLI connects to the domain controller and can be used to manage the entire domain. For more details on CLI in domain mode, see [[#CLI_in_Domain_Mode|CLI in Domain Mode]]. | |||
=CLI and Management Interfaces= | |||
CLI clients connect to the managed WildFly instances over ''management interfaces''. There are two types of management interfaces: native and http. For more details on management interfaces see: | |||
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;"> | |||
:[[WildFly Management Interfaces]] | |||
</blockquote> | |||
=Management Model Node= | |||
A ''management model node'' can be thought of as an XML element in the standalone instance or domain's configuration files. | |||
CLI interacts with nodes via [[#Operations|operations]]. The list of operations available for interaction with a node can be obtained at any time by navigating to that node and executing <tt>:read-operation-names</tt>. For more details see: | |||
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;"> | |||
:[[#Operations_Available_for_a_Certain_Node|Operations Available for a Certain Node]] | |||
</blockquote> | |||
==Management Model Node Address== | |||
A management node ''address'' (or a ''path'') is sequence of slash-separated management node IDs. A management node ID is specified as "node-type=node-name" pair. | |||
The generic format of an address is: | |||
<pre> | |||
/node-type=node-name[/node-type=node-name/...] | |||
</pre> | |||
where: | |||
''node-type'' is the resource node type. Usually, it maps to an element name in the configuration XML (<tt>standalone.xml</tt>, <tt>domain.xml</tt> and <tt>host.xml</tt>). | |||
''node-name'' is the resource node name. It maps to the "name" attribute of the element in the configuration XML. | |||
=Resource= | |||
<font color=red> | |||
TODO | |||
Clarify the fact that <tt></tt> implies that "/subsystem=jgroups/stack=tcp/protocol=MPING/property=initial_hosts:add(value="jdg1,jdg2")" is a resource and it has a value. | |||
Is "initial_hosts" the resource, or "property=initial_hosts"? | |||
How do we define the resource in this case. Is "property" a resource type? | |||
What is the difference between a "management node" and a "resource"? | |||
</font> | |||
=Command and Operations= | |||
The CLI interacts with the target controller by reading the user's ''commands'' and issuing ''operations''. | |||
==Commands== | |||
Commands correspond to higher-level interactions with the controller. They are supposed to have user-friendlier syntax, but ultimately they translate into operations, or even composite operation requests. The list of available commands can be obtained with: | |||
<pre> | |||
help --commands | |||
</pre> | |||
To get more details about a specific command: | |||
<pre> | |||
<command-name> --help | |||
</pre> | |||
Some commands require an established connection to the controller (standalone or domain). Other commands may depend on the availability of specific subsystems (e.g. if the messaging subsystem is not available, messaging-related commands will not be listed). | |||
===Common Commands=== | |||
* <span id="quit_command">[[WildFly CLI quit Command|quit]]</span> | |||
* <span id="whoami_command">[[WildFly CLI whoami Command|whoami]]</span> | |||
==Operations== | |||
Operations are the finest-possible grained interaction mode with the controller: if it can't be done with an operation, it can't be done in any other way. | |||
In general operations apply to a [[#Management_Model_Node|management model node]], which is specified as an ''[[#Management_Model_Node_Address|address]]'' (path) to that operation. In this respect, operations are interactions with management nodes: | |||
<pre> | |||
/<address>:<operation-name>[(parameter-name-1=parameter-value-1,...)] | |||
</pre> | |||
Example: | |||
<pre> | |||
/core-service=platform-mbean/type=threading:dump-all-threads(locked-monitors=true,locked-synchronizers=true) | |||
</pre> | |||
The current node path is used as the address for operation requests that do not contain the address part. If an operation request does include the address, the included address is considered relative to the current node path. The current node path may end on a node-type. In that case, to execute an operation specifying a node-name would be sufficient, such as logging:read-resource. | |||
===Operations Available for a Certain Node=== | |||
====:read-operation-names==== | |||
Navigate to the node and: | |||
<pre> | |||
[domain@172.31.17.207:9999 subsystem=jgroups] :read-operation-names | |||
</pre> | |||
Or specify the full path: | |||
<pre> | |||
/profile=ha/subsystem=jgroups:read-operation-names | |||
</pre> | |||
Example: | |||
<pre> | |||
"add", | |||
"read-attribute", | |||
"read-children-names", | |||
"read-children-resources", | |||
"read-children-types", | |||
"read-operation-description", | |||
"read-operation-names", | |||
"read-resource", | |||
"read-resource-description", | |||
"remove", | |||
"undefine-attribute", | |||
"whoami", | |||
"write-attribute" | |||
</pre> | |||
====:read-operation-description==== | |||
More details for a specific operation can be obtained with: | |||
<pre> | |||
/profile=ha/subsystem=jgroups:read-operation-description(name=write-attribute) | |||
</pre> | |||
===Common Operations=== | |||
* <span id="add_operation"><tt>[[add|:add]]</tt></span> | |||
* <tt>[[write-attribute|:write-attribute]]</tt> | |||
* <tt>[[reload|:reload]]</tt> | |||
* <tt>[[read-resource|:read-resource]]</tt> | |||
* <tt>[[read-resource-description|:read-resource-description]]</tt> | |||
* <span id="remove_operation"><tt>[[remove|:remove]]</tt></span> | |||
* <tt>[[WildFly CLI - Starting and Stopping Instances|:shutdown]]</tt> | |||
=Batch= | |||
<pre> | |||
batch | |||
... | |||
run-batch | |||
</pre> | |||
=CLI Archive= | |||
A cli archive is a zip archive containing script(s) as well as artifacts or applications to deploy. To be recognized as a cli archive, the extension of the archive file should be '.cli'. This is [[WildFly CLI Deployment Operations#--script|how they are used]]. | |||
=CLI in Domain Mode= | |||
For servers running in domain mode, the CLI connects to the domain controller and can be used to manage the entire domain. Once connected to the domain controller, the domain's host are available under "/host". Each host is associated with a number of servers, which are available under "/host/<host-name>/server". The management model view of a server accessed this way is similar to the management model view of a server in standalone mode. | |||
=Offline CLI= | |||
* https://developer.jboss.org/wiki/AS7InternalArchitectureOverview | |||
Latest revision as of 15:03, 20 September 2017
Internal
TODO
Continue processing https://developer.jboss.org/wiki/CommandLineInterface, https://developer.jboss.org/wiki/JBossAS7Command-lineOperationRequestFormat, https://developer.jboss.org/wiki/CLICompoundValueFormat
Overview
The management CLI is a command line administration tool that manages WildFly nodes running in both standalone and domain mode. The tool exercises the native management API of the application server. The CLI client works with a managed domain or a standalone instance, allowing the user to control either the domain controller or the standalone server and execute management operations through a de-typed (string-driven) management model.
The Management CLI may be used to start and stop servers, deploy and undeploy applications, configure system settings and perform other administrative tasks. Operations can be performed in batch mode, allowing multiple tasks to be executed as a group.
The Management CLI can perform all tasks the web-based management console can perform, as well as many other lower level operations that are not available to the web-based administration tool.
For servers running in domain mode, the CLI connects to the domain controller and can be used to manage the entire domain. For more details on CLI in domain mode, see CLI in Domain Mode.
CLI and Management Interfaces
CLI clients connect to the managed WildFly instances over management interfaces. There are two types of management interfaces: native and http. For more details on management interfaces see:
Management Model Node
A management model node can be thought of as an XML element in the standalone instance or domain's configuration files.
CLI interacts with nodes via operations. The list of operations available for interaction with a node can be obtained at any time by navigating to that node and executing :read-operation-names. For more details see:
Management Model Node Address
A management node address (or a path) is sequence of slash-separated management node IDs. A management node ID is specified as "node-type=node-name" pair.
The generic format of an address is:
/node-type=node-name[/node-type=node-name/...]
where:
node-type is the resource node type. Usually, it maps to an element name in the configuration XML (standalone.xml, domain.xml and host.xml).
node-name is the resource node name. It maps to the "name" attribute of the element in the configuration XML.
Resource
TODO
Clarify the fact that implies that "/subsystem=jgroups/stack=tcp/protocol=MPING/property=initial_hosts:add(value="jdg1,jdg2")" is a resource and it has a value.
Is "initial_hosts" the resource, or "property=initial_hosts"?
How do we define the resource in this case. Is "property" a resource type?
What is the difference between a "management node" and a "resource"?
Command and Operations
The CLI interacts with the target controller by reading the user's commands and issuing operations.
Commands
Commands correspond to higher-level interactions with the controller. They are supposed to have user-friendlier syntax, but ultimately they translate into operations, or even composite operation requests. The list of available commands can be obtained with:
help --commands
To get more details about a specific command:
<command-name> --help
Some commands require an established connection to the controller (standalone or domain). Other commands may depend on the availability of specific subsystems (e.g. if the messaging subsystem is not available, messaging-related commands will not be listed).
Common Commands
Operations
Operations are the finest-possible grained interaction mode with the controller: if it can't be done with an operation, it can't be done in any other way.
In general operations apply to a management model node, which is specified as an address (path) to that operation. In this respect, operations are interactions with management nodes:
/<address>:<operation-name>[(parameter-name-1=parameter-value-1,...)]
Example:
/core-service=platform-mbean/type=threading:dump-all-threads(locked-monitors=true,locked-synchronizers=true)
The current node path is used as the address for operation requests that do not contain the address part. If an operation request does include the address, the included address is considered relative to the current node path. The current node path may end on a node-type. In that case, to execute an operation specifying a node-name would be sufficient, such as logging:read-resource.
Operations Available for a Certain Node
:read-operation-names
Navigate to the node and:
[domain@172.31.17.207:9999 subsystem=jgroups] :read-operation-names
Or specify the full path:
/profile=ha/subsystem=jgroups:read-operation-names
Example:
"add",
"read-attribute",
"read-children-names",
"read-children-resources",
"read-children-types",
"read-operation-description",
"read-operation-names",
"read-resource",
"read-resource-description",
"remove",
"undefine-attribute",
"whoami",
"write-attribute"
:read-operation-description
More details for a specific operation can be obtained with:
/profile=ha/subsystem=jgroups:read-operation-description(name=write-attribute)
Common Operations
Batch
batch ... run-batch
CLI Archive
A cli archive is a zip archive containing script(s) as well as artifacts or applications to deploy. To be recognized as a cli archive, the extension of the archive file should be '.cli'. This is how they are used.
CLI in Domain Mode
For servers running in domain mode, the CLI connects to the domain controller and can be used to manage the entire domain. Once connected to the domain controller, the domain's host are available under "/host". Each host is associated with a number of servers, which are available under "/host/<host-name>/server". The management model view of a server accessed this way is similar to the management model view of a server in standalone mode.