Skip to content
This repository has been archived by the owner on Jan 5, 2021. It is now read-only.

Latest commit

 

History

History
263 lines (192 loc) · 10.5 KB

Galleon_provisioning.adoc

File metadata and controls

263 lines (192 loc) · 10.5 KB
Raw

Provisioning WildFly with Galleon

With the WildFly server being internally built using the Galleon project, WildFly benefits
from Galleon’s provisioning capabilities. One of the main features that Galleon brings to WildFly is the ability to install a complete or customized WildFly server using Galleon tooling.

More information on Galleon features and tooling can be found in the Galleon docs.

WildFly Galleon feature-packs

WildFly provides a Galleon feature-pack maven artifact (a zipped file that contains installation content). This feature-pack, as well as the feature-packs on which its depends (core and servlet feature-packs), are deployed in public maven repositories.

When Galleon is used to install WildFly, WildFly feature-packs are retrieved and their content is assembled to create an installation.

Installing WildFly using Galleon

The Galleon maven plugin or Galleon CLI are used to install WildFly. The latest CLI and documentation can be downloaded from the Galleon releases page.

To install the latest final version of WildFly into the directory my-wildfly-server call:

galleon.sh install wildfly:current --dir=my-wildfly-server

Once installed, the directory my-wildfly-server contains all that is expected to run a complete WildFly server. By default, all standalone and domain configurations are installed.

Note

Append the release version to install an identified release, for example:

galleon.sh install wildfly:current#16.0.0.Final --dir=my-wildfly-server

Use wildfly-core:current to only install a core server, for example:

galleon.sh install wildfly-core:current --dir=my-core-server

Use wildfly-servlet:current to only install a servlet server, for example:

galleon.sh install wildfly-servlet:current --dir=my-servlet-server

Selecting the configurations to install

Galleon allows you to specify only a subset of the default configurations to be installed.

To only install the standalone.xml configuration call:

galleon.sh install wildfly:current --dir=my-wildfly-server --default-configs=standalone/standalone.xml

To install multiple configurations, a comma separated list of default configurations can be provided, for example:

galleon.sh install wildfly:current --dir=my-wildfly-server --default-configs=standalone/standalone.xml,domain/domain.xml
Note

A default configuration is identified by <configuration model>/<configuration name>. WildFly defines standalone and domain models. The configuration name is the XML configuration file name (e.g.: standalone.xml, domain.xml, standalone-ha.xml).

WildFly Galleon layers

WildFly Galleon feature-packs expose some Galleon layers. A layer identifies one or more server capabilities that can be installed on its own or in combination with other layers. For example, if your application (e.g.: microservice) is only making use of jaxrs and cdi server capabilities, you can choose to only install the jaxrs and cdi layers. The standalone.xml configuration would then only contain the required subsystems and their dependencies.

The benefit to installing WildFly using Galleon layers, in addition to configuration trim down, is that Galleon only installs the needed content (JBoss Modules modules, scripts, etc.).

To install a server only configured with jaxrs and cdi capabilities call:

galleon.sh install wildfly:current --dir=my-wildfly-server --layers=cdi,jaxrs

Once installed, the directory my-wildfly-server contains all that is expected to deploy an application that depends on jaxrs and cdi.

Note

  • Tools (jboss-cli, add-user, …​) are not always installed when installing WildFly using layers. Only server launcher scripts are installed into the bin directory. To include these tools include the core-tools layer.

Defined Galleon layers

Note on layers and feature-pack dependencies

When installing a feature-pack, its own defined layers as well as the layers present in its dependencies can be combined to build a custom configuration. This means that core and servlet defined layers can be combined with WildFly defined layers to assemble a custom configuration. Galleon CLI recipes contains examples of such combination of layers.

WildFly layers

Basic layers:

  • bean-validation: Support for Jakarta Bean Validation. Optionally depends on cdi.

  • cdi: Support for CDI.

  • datasources: Support for datasources.

  • ee-security: Support for EE Security. Depends on cdi.

  • jaxrs: Support for JAXRS. Depends on web-server (defined in the WildFly servlet feature-pack).

  • jms-activemq: Support for connections to a remote JMS broker.

  • jpa: Support for JPA (using the latest WildFly supported Hibernate release).

  • microprofile-config: Support for MicroProfile Config.

  • microprofile-fault-tolerance: Support for MicroProfile Fault Tolerance.

  • microprofile-jwt: Support for MicroProfile JWT.

  • microprofile-metrics: Support for MicroProfile Metrics.

  • observability: Support for MicroProfile monitoring and configuration features (Config, Health, Metrics, OpenTracing).

  • open-tracing: Support for MicroProfile OpenTracing. This layer is an optional dependency of the observability layer.

  • resource-adapters: Support for deployment of JCA adapters.

  • h2-driver: Support for the H2 JDBC driver.

  • h2-datasource: Support for an H2 datasource. Depends on h2-driver.

  • h2-default-datasource: Support for h2 datasource set as the ee subsystem default datasource. Depends on h2-datasource.

Aggregation layers:

  • cloud-profile, an aggregation of the basic layers (except h2-* layers) and a web-server .

Use-cases tailored server layers:

Note

The following layers depend on core-server and core-tools (layers defined in WildFly core feature-pack). The security is handled by elytron. Undertow subsystem is configured with other application-security-domain that references Elytron ApplicationDomain security domain.

  • datasources-web-server: A servlet container (web-server layer) with an optional dependency on datasources layer.

  • jaxrs-server: An extension of datasources-web-server layer with jaxrs and optional dependencies on cdi and jpa layers.

  • cloud-server: A cloud-profile with core features and tools.

Decorator layers:

Layers that you combine with "use-case tailored" layers to extend the capabilities of the provisioned server.

  • web-clustering: Infinispan-based web session clustering.

WildFly servlet layers

Basic layers:

  • ee: Support for common functionality in the Jakarta EE platform.

  • legacy-security: Support for legacy Picketbox-based web security.

  • naming: Support for JNDI.

  • undertow: Support for the Undertow HTTP server.

  • undertow-legacy-https: Support for the Undertow HTTPS server secured using the legacy security ApplicationRealm.

  • undertow-load-balancer: Support for Undertow configured as a load balancer.

  • vault: Support for Picketbox security vaults.

Servlet support layer:

  • web-server: A servlet container composed of ee, naming, deployment-scanner (from WildFly core feature-pack) and undertow configured as a servlet container.

WildFly core layers

Basic layers:

  • base-server: Empty runnable server.

  • core-management: Support for server management services.

  • core-security-realms: Support for core Application and Management realms.

  • deployment-scanner: Support for deployment directory scanning.

  • discovery: Support for discovery.

  • elytron: Support for Elytron security.

  • io: Support for XNIO workers and buffer pools.

  • jmx: Support for registration of Management Model MBeans.

  • jmx-remoting: Support for registration of Management Model MBeans and a JMX remoting connector.

  • logging: Support for the logging subsystem.

  • legacy-management: Support for remote access to management interfaces secured with the core ManagementRealm.

  • management: Support for remote access to management interfaces (unsecured).

  • remoting: Support for inbound and outbound JBoss Remoting connections.

  • request-controller: Support for request management.

  • secure-management: Support for remote access to management interfaces secured using Elytron.

  • security-management: Support for security manager.

Aggregation layers:

  • core-server: Aggregation of layers that compose a typical core server: core-security-realms, secure-management, jmx-remoting, logging, core-management, request-controller and security-manager.

Tools layers:

  • core-tools: Support for jboss-cli, add-user, elytron-tool launch scripts and configuration files.

Galleon CLI recipes

Installation of a cloud-profile with main core functionalities and management tools

galleon.sh install wildfly:current --dir=my-wildfly-server --layers=cloud-profile,core-server,core-tools

Installation of a cloud-profile with support for https (using legacy core ApplicationRealm)

galleon.sh install wildfly:current --dir=my-wildfly-server --layers=cloud-profile,undertow-legacy-https

Installation of jaxrs, cdi, elytron and logging

galleon.sh install wildfly:current --dir=my-wildfly-server --layers=jaxrs,cdi,elytron,logging

Installation of a servlet container with main core functionalities

galleon.sh install wildfly:current --dir=my-wildfly-server --layers=web-server,core-server

Installation of a servlet container with support for https (using legacy core ApplicationRealm)

galleon.sh install wildfly:current --dir=my-wildfly-server --layers=web-server,undertow-legacy-https

Installation of an Undertow http server with logging

galleon.sh install wildfly:current --dir=my-wildfly-server --layers=undertow,logging

Installation of an Undertow https server (using legacy core ApplicationRealm)

galleon.sh install wildfly:current --dir=my-wildfly-server --layers=undertow-legacy-https

Installation of a core server

galleon.sh install wildfly:current --dir=my-wildfly-server --layers=core-server