WildFly Deployment Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(42 intermediate revisions by the same user not shown)
Line 5: Line 5:


* [[WildFly Concepts#Concepts|WildFly Concepts]]
* [[WildFly Concepts#Concepts|WildFly Concepts]]
=Deployment Name=
Each deployment is identified by an unique name. Unless explicitly specified with the --name CLI option, the default value of a deployment name is the name of the file that was used when the artifact content was added to the repository.
=Deployment Runtime Name=
Represents the runtime name of the deployment, and if not explicitly specified with --runtime-name CLI option, is the same as the [[#Deployment_Name|deployment name]]. The runtime name will form the basis for default Java EE application and module names. There are cases when users may wish to have two deployments with the same runtime name (two versions of application) both available in the management configuration, in which case the deployments would need to have distinct [[#Deployment_Name|name]] values but would have the same runtime name. Within an individual server, only one deployment with a given runtime name can deployed. However, multiple deployments with the same runtime name can exist in the configuration, so long as only one is enabled.
=Unmanaged Deployments=
The default behavior of the application server is to add the deployment artifact contents to the repository. This behavior can be explicitly avoided if a deployment is declared "unmanaged", with the --unamanged CLI option: the deployment content will remain at and be  deployed directly from its original location. Exploded deployments are supported only as unmanaged.
=Deployment Artifact Repository=
Both standalone and domain modes rely on the presence of an artifact repository.
For instances running in standalone mode, the repository is in $JBOSS_HOME/standalone/data/content.
For instances running in domain mode, the repository resides on the domain controller host. For more details see [[#Domain-Wide_Deployment_Artifact_Repository|Domain-Wide Deployment Artifact Repository]] below.


=Standalone Mode Deployments=
=Standalone Mode Deployments=


==Location of the Deployment Artifacts on the File System==
==Location of the Deployment Artifacts on the File System in Standalone Mode==
 
==Standalone Deployment Modes==
 
* CLI
* Management Console
* HTTP REST
* Deployment Scanner


=Domain Mode Deployments=
=Domain Mode Deployments=


=Deployment Artifact Repository=
==Domain Deployment Mechanics==
 
CLI deployment commands operate on artifacts existing in the [[#Deployment_Artifact_Repository|deployment artifact repository]]. An artifact must first be stored in repository before it is distributed to server nodes. The location of the artifact in the repository is reported by the domain controller upon deployment:
 
[Host Controller] 11:12:16,279 INFO  [org.jboss.as.repository] (management-handler-thread - 9) JBAS014900: Content added at location /jboss-eap-6.4.15/profiles/domain-deployment-test/data/content/1c/795338f655a8e6aa5b1d984e894ee5e89cc398/content
 
The naming scheme used to store content is explained in the [[#Domain-Wide_Deployment_Artifact_Repository|Domain-Wide Deployment Artifact Repository]] section. After storing the content in the repository, the content is usually pushed to target server nodes by the controller as part of the same operation. The deployment artifact content ends up in the data/content directory of each target server node, following the same naming scheme for storage on the file system (.../data/content/1c/795338f655a8e6aa5b1d984e894ee5e89cc398/content). Note that adding content to repository and pushing to nodes can be done in separate steps. Upgrades are handled differently. Once an artifact, identified by its name, is added to the repository, upgrades of artifacts with the same name will be pushed ''only'' to server nodes on which the artifact is already deployed. A special flag (--force) is required to specify that the operation is an upgrade, and the attempt to specify other target nodes than the ones that are already running the artifact - in fact, any target nodes, ends up in failure. As part of the upgrade operation, the content corresponding to the new version of the artifact is stored in a different location in the artifact repository, as the hash of the artifact is different, but under the same artifact name. For more operational details, see: {{Internal|WildFly_CLI_Deployment_Operations#Domain_Mode|CLI Deployment Operations in Domain Mode}}
 
A successful now deployment or upgrade reflects in changes in domain.xml. The <deployments> section lists the name and the hash of the artifact, and represents, in fact, the listing of the content of the repository:
 
<syntaxhighlight lang='xml'>
<deployments>
  <deployment name="servlet-example.war" runtime-name="servlet-example.war">
    <content sha1="b4bcac8f15c72e964076680932b0989675078889"/>
  </deployment>
</deployments>
</syntaxhighlight>
 
==Domain-Wide Deployment Artifact Repository==
 
The domain-wide deployment artifact repository is located on the controller host, under $JBOSS_HOME/domain/data/content. The content is maintained in a two-level directory structure named based on the content's hash. The names of the first level directories consist of the first two characters of content hashes. A second-level directory name contains the rest of the hash, and the directory contains the content itself, as a file named "content".
 
Example:
 
<syntaxhighlight lang='xml'>
<domain ...>
  ...
  <deployments>
    ...
    <deployment name="test-servlet.war" runtime-name="test-servlet.war">
      <content sha1="e85e00cddbae1752cb7eaaa73adb1eed09787d70"/>
    </deployment>
 
  </deployments>
</domain>
</syntaxhighlight>
 
$JBOSS_HOME/domain/data/content/''<first-two-characters-of-the-hash>''/''<the-rest-of-the-hash>''/content
 
domain
  |
  +-- data
        |
        +-- content
              |
              +-- e8
                  |
                  +-- 5e00cddbae1752cb7eaaa73adb1eed09787d70
                                    |
                                    +-- content                   
 
Also see {{Internal|WildFly CLI Deployment Operations#Overview|CLI Deployment Operations}}
 
==Location of the Deployment Artifacts on the File System in Domain Mode==
 
For the location of the domain-wide artifact repository, see [[#Domain-Wide_Deployment_Artifact_Repository|Domain-Wide Deployment Artifact Repository]] section below.
 
In case of server nodes, copies of the deployment artifacts are pushed by the domain management logic to:
 
$JBOSS_HOME/domain/data/servers/''<server-node-name>''/content/''<first-two-characters-of-the-hash>''/''<the-rest-of-the-hash>''/content
 
==Domain Deployment Modes==
 
* CLI
* Management Console
* HTTP REST
 
==Rollout Plans==
 
{{External|https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html/Administration_and_Configuration_Guide/sect-Rollout_Plan.html}}
 
=Deployment Scanner=
 
{{Internal|WildFly Deployment Scanner|Deployment Scanner}}
 
=Deployment Descriptor Validation=
 
{{External|https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html/Administration_and_Configuration_Guide/chap-Application_Deployment.html#About_Application_Deployment1}}


Also see [[WildFly CLI - Deployment and Undeployment#Overview|WildFly CLI Deployment/Undeployment]].
./domain.sh|./standalone.sh -Dorg.jboss.metadata.parser.validate=true

Latest revision as of 21:19, 21 September 2017


Migrating from https://home.feodorov.com:9443/wiki/Wiki.jsp?page=JBoss7Deployment

Internal

Deployment Name

Each deployment is identified by an unique name. Unless explicitly specified with the --name CLI option, the default value of a deployment name is the name of the file that was used when the artifact content was added to the repository.

Deployment Runtime Name

Represents the runtime name of the deployment, and if not explicitly specified with --runtime-name CLI option, is the same as the deployment name. The runtime name will form the basis for default Java EE application and module names. There are cases when users may wish to have two deployments with the same runtime name (two versions of application) both available in the management configuration, in which case the deployments would need to have distinct name values but would have the same runtime name. Within an individual server, only one deployment with a given runtime name can deployed. However, multiple deployments with the same runtime name can exist in the configuration, so long as only one is enabled.

Unmanaged Deployments

The default behavior of the application server is to add the deployment artifact contents to the repository. This behavior can be explicitly avoided if a deployment is declared "unmanaged", with the --unamanged CLI option: the deployment content will remain at and be deployed directly from its original location. Exploded deployments are supported only as unmanaged.

Deployment Artifact Repository

Both standalone and domain modes rely on the presence of an artifact repository.

For instances running in standalone mode, the repository is in $JBOSS_HOME/standalone/data/content.

For instances running in domain mode, the repository resides on the domain controller host. For more details see Domain-Wide Deployment Artifact Repository below.

Standalone Mode Deployments

Location of the Deployment Artifacts on the File System in Standalone Mode

Standalone Deployment Modes

  • CLI
  • Management Console
  • HTTP REST
  • Deployment Scanner

Domain Mode Deployments

Domain Deployment Mechanics

CLI deployment commands operate on artifacts existing in the deployment artifact repository. An artifact must first be stored in repository before it is distributed to server nodes. The location of the artifact in the repository is reported by the domain controller upon deployment:

[Host Controller] 11:12:16,279 INFO  [org.jboss.as.repository] (management-handler-thread - 9) JBAS014900: Content added at location /jboss-eap-6.4.15/profiles/domain-deployment-test/data/content/1c/795338f655a8e6aa5b1d984e894ee5e89cc398/content

The naming scheme used to store content is explained in the Domain-Wide Deployment Artifact Repository section. After storing the content in the repository, the content is usually pushed to target server nodes by the controller as part of the same operation. The deployment artifact content ends up in the data/content directory of each target server node, following the same naming scheme for storage on the file system (.../data/content/1c/795338f655a8e6aa5b1d984e894ee5e89cc398/content). Note that adding content to repository and pushing to nodes can be done in separate steps. Upgrades are handled differently. Once an artifact, identified by its name, is added to the repository, upgrades of artifacts with the same name will be pushed only to server nodes on which the artifact is already deployed. A special flag (--force) is required to specify that the operation is an upgrade, and the attempt to specify other target nodes than the ones that are already running the artifact - in fact, any target nodes, ends up in failure. As part of the upgrade operation, the content corresponding to the new version of the artifact is stored in a different location in the artifact repository, as the hash of the artifact is different, but under the same artifact name. For more operational details, see:

CLI Deployment Operations in Domain Mode

A successful now deployment or upgrade reflects in changes in domain.xml. The <deployments> section lists the name and the hash of the artifact, and represents, in fact, the listing of the content of the repository:

<deployments>
  <deployment name="servlet-example.war" runtime-name="servlet-example.war">
    <content sha1="b4bcac8f15c72e964076680932b0989675078889"/>
  </deployment>
</deployments>

Domain-Wide Deployment Artifact Repository

The domain-wide deployment artifact repository is located on the controller host, under $JBOSS_HOME/domain/data/content. The content is maintained in a two-level directory structure named based on the content's hash. The names of the first level directories consist of the first two characters of content hashes. A second-level directory name contains the rest of the hash, and the directory contains the content itself, as a file named "content".

Example:

<domain ...>
  ...
  <deployments>
    ...
    <deployment name="test-servlet.war" runtime-name="test-servlet.war">
      <content sha1="e85e00cddbae1752cb7eaaa73adb1eed09787d70"/>
    </deployment>

  </deployments>
</domain>
$JBOSS_HOME/domain/data/content/<first-two-characters-of-the-hash>/<the-rest-of-the-hash>/content
domain
  |
  +-- data
       |
       +-- content
             |
              +-- e8
                  |
                  +-- 5e00cddbae1752cb7eaaa73adb1eed09787d70
                                   |
                                   +-- content                    

Also see

CLI Deployment Operations

Location of the Deployment Artifacts on the File System in Domain Mode

For the location of the domain-wide artifact repository, see Domain-Wide Deployment Artifact Repository section below.

In case of server nodes, copies of the deployment artifacts are pushed by the domain management logic to:

$JBOSS_HOME/domain/data/servers/<server-node-name>/content/<first-two-characters-of-the-hash>/<the-rest-of-the-hash>/content

Domain Deployment Modes

  • CLI
  • Management Console
  • HTTP REST

Rollout Plans

https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html/Administration_and_Configuration_Guide/sect-Rollout_Plan.html

Deployment Scanner

Deployment Scanner

Deployment Descriptor Validation

https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html/Administration_and_Configuration_Guide/chap-Application_Deployment.html#About_Application_Deployment1
./domain.sh|./standalone.sh -Dorg.jboss.metadata.parser.validate=true