$ docker pull openshift/wildfly-101-centos7 $ docker pull openshift/wildfly-100-centos7
OpenShift Origin provides S2I enabled Wildfly images for building and running Java applications. The Wildfly S2I builder image assembles your application source with any required dependencies to create a new image containing your Java application. This resulting image can be run either by OpenShift Origin or by Docker.
These images are available on DockerHub. To download them:
$ docker pull openshift/wildfly-101-centos7 $ docker pull openshift/wildfly-100-centos7
To use these images, you can either access them directly from DockerHub or push them into your OpenShift Origin Docker registry. Additionally, you can create an image stream that points to the image, either in your Docker registry or at the external location. Your OpenShift Origin resources can then reference the ImageStream. You can find example image stream definitions for all the provided OpenShift Origin images.
S2I produces ready-to-run images by injecting source code into a container and letting the container prepare that source code for execution. It performs the following steps:
Starts a container from the builder image.
Downloads the application source.
Streams the scripts and application sources into the builder image container.
Runs the assemble script (from the builder image).
Saves the final image.
See S2I Build Process for a detailed overview of the build process.
The Wildfly image supports a number of environment variables which can be set to control the configuration and behavior of the Wildfly application server.
To set these environment variables as part of your image, you can place them into
a .s2i/environment file
inside your source code repository, or define them in
the environment
section of the build configuration’s sourceStrategy definition.
You can also set environment variables to be used with an existing image when creating new applications, or by updating environment variables for existing objects such as deployment configurations.
|
Environment variables that control build behavior must be set as part of the s2i build configuration or in the .s2i/environment file to make them available to the build steps. |
| Variable name | Description |
|---|---|
|
Overrides the default arguments passed to Maven during the build process. |
|
This value will be appended to either the default Maven arguments, or the value of |
|
Contains JVM parameters to Maven. Will be appended to JVM arguments that are calculated by the image itself (e.g. heap size), so values provided here will take precedence. |
|
When set to a non-null value, this value will be passed to the JVM instead of the default garbage collection tuning values defined by the image. |
|
When set to a non-null value, the number of parallel garbage collection threads will be set to this value. |
|
When set to a non-null value, various JVM related diagnostics will be turned on such as verbose garbage collection tracing. |
|
When set to a non-null value, the number of parallel garbage collection threads will be set to this value. |
|
When set to |
|
If set, WildFly will attempt to define a MySQL datasource based on the assumption you have an OpenShift service named |
|
If set, WildFly will attempt to define a PostgreSQL datasource based on the assumption you have an OpenShift service named |
Hot deployment allows you to quickly make and deploy changes to your application
without having to generate a new S2I build. Hot deployment for war files is already
enabled, but to enable hot deployment of exploded war content, you must set the
AUTO_DEPLOY_EXPLODED environment variable to true. For example, see the
oc new-app
command. You can use the oc set env
command to update environment variables of existing objects.
Deployed content is stored under /wildfly/standalone/deployments.
|
You should only use this option while developing or debugging; it is not recommended to turn this on in your production environment. |