Skip navigation

Since WildFly 10 Final was just released, the OpenShift WildFly cartridge has been updated as well. This post will walk you through getting started on OpenShift and deploying a WildFly quickstart. If you already have an existing WildFly OpenShift app, you'll want to check out these tips for migrating your app to WildFly 10 Final.

 

Creating a new app

There are a few options for creating an app on OpenShift:

  • To use the OpenShift Web Console, just click here.
  • To get started directly from Eclipse, you'll first need to install the OpenShift JBoss Tools package. Then, simply use the New OpenShift Application Wizard to create your app.
  • With JBoss Developer Studio, the OpenShift JBoss Tools package is already installed so you can get started right away with the New OpenShift Application Wizard.
  • To use the CLI, make sure you've got the OpenShift Client Tools installed and then execute the following command:
    rhc app create <WILDFLY_APP_NAME> jboss-wildfly-10

 

WildFly management options

Once you've created your app, it will be available at http://<WILDFLY_APP_NAME>-<NAMESPACE>-rhcloud.com. You can then use the WildFly CLI or Admin Console to manage your server.


To connect to the CLI:

rhc ssh <WILDFLY_APP_NAME> # This command allows you to ssh into your OpenShift app
jboss-cli.sh -c --controller=$OPENSHIFT_WILDFLY_IP:$OPENSHIFT_WILDFLY_MANAGEMENT_HTTP_PORT


When logging into the Admin Console, you can use the credentials for the WildFly management user that's automatically created for you by the WildFly cartridge. To obtain the necessary credentials:

rhc ssh <WILDFLY_APP_NAME>
echo $OPENSHIFT_WILDFLY_USERNAME
echo $OPENSHIFT_WILDFLY_PASSWORD


Then, using port forwarding, you're ready to access the Admin Console from your local machine:

rhc port-forward <WILDFLY_APP_NAME>


Deploying a WildFly quickstart

Getting started with a WildFly quickstart on OpenShift is simple. The following steps will demonstrate how to deploy the kitchensink quickstart, an application that demonstrates a few different Java EE 7 technologies, using the OpenShift Client Tools.


If you created your OpenShift app using the CLI, Eclipse, or JBoss Developer Studio, you should already have a clone of your app's OpenShift git repository on your local machine. If you created your app using the OpenShift Web Console, you'll need to first clone your app's git repository as follows:

rhc git-clone <WILDFLY_APP_NAME>

 

Next, navigate to your app's git repository on your machine and remove the source for the default application that's created by the WildFly cartridge:

git rm -r src pom.xml

 

Now, copy over the source for the kitchensink quickstart:

cp -r QUICKSTART_HOME/kitchensink/src .
cp QUICKSTART_HOME/kitchensink/pom.xml .

 

Next, push your changes:

git add src pom.xml
git commit -m "Deploying the kitchensink quickstart on WildFly 10 on OpenShift!"
git push

 

That's it! The kitchensink quickstart will now be available at your application URL (i.e., http://<WILDFLY_APP_NAME>-<NAMESPACE>-rhcloud.com).


Enjoy!


This post provides some tips on how to migrate an existing OpenShift application to WildFly 10 Final.

 

Migrating from WildFly 10 Alpha/Beta/CR

If you already have an existing WildFly 10 Alpha/Beta/CR app, you can simply create a new WildFly 10 app based on the existing app using the following command:

rhc app create <NEW_WILDFLY_APP> --from-app <OLD_WILDFLY_APP>

 

The result will be a new WildFly 10 Final application that's a clone of your existing one. This means that your new app will have the same git repository, gear size, scaling configuration, environment variables, deployments, etc.

 

Migrating from WildFly 8 or WildFly 9

You can create a new WildFly 10 Final app that's based off your existing app's git repository. There are a couple ways to do this. One option is to first create a new WildFly 10 app and then manually copy over the contents of your old git repo to your new git repo once the new app has been created. Another option is to use the following command:

rhc app create <NEW_WILDFLY_APP> jboss-wildfly-10 --from-code http://url/to/git_repo.git

 

With both of these options, you should first replace the standalone.xml file from your git repo's .openshift/config directory with the WildFly 10 standalone.xml file.

 

Migrating from AS 7

You can create a new WildFly 10 Final app that's based off your existing app's git repository, as described above. However, there are some extra caveats that you should be aware of:

  • If your git repo contains any action hook scripts that end with "_jbossas", these scripts will need to be renamed to end with "_wildfly" instead.
  • If your git repo contains any action hook scripts that reference OpenShift environment variables that start with "OPENSHIFT_JBOSSAS_", these scripts will need to be updated to reference "OPENSHIFT_WILDFLY_" instead.

To see if you have any such scripts, have a look in the .openshift/action_hooks directory in your git repo.


Happy migrating!

Since WildFly 9.0.0.Final was just released, the OpenShift WildFly cartridge has been updated as well. Getting started on OpenShift is simple, the first thing you need to do is pick your favourite tool:

 

Getting started from the Web Console

 

Just click here.

 

Getting started from the command line

 

  1. Follow the instructions here to install the RHC client tools.
  2. Create your WildFly 9 application using the following command:

rhc app create <WILDFLY_APP_NAME> jboss-wildfly-9

 

Getting started from Eclipse

 

  1. Follow the instructions here to install the OpenShift JBoss Tools package from the Eclipse marketplace.
  2. Create your WildFly 9 application directly from Eclipse using the New OpenShift Application Wizard:

Wizard.png

Similarly, you can also create your application using JBoss Developer Studio which comes with the OpenShift plugin installed.

 

Accessing and managing your app

 

Once you've created your application, it will be available at the following URL:

http://{WILDFLY_APP_NAME}-{NAMESPACE}-rhcloud.com

To ssh into your OpenShift instance, the following command can be used:

rhc ssh <WILDFLY_APP_NAME>

You can then use the JBoss CLI to connect to WildFly:

jboss-cli.sh -c --controller=$OPENSHIFT_WILDFLY_IP:$OPENSHIFT_WILDFLY_MANAGEMENT_HTTP_PORT

To access the WildFly Admin Console, you'll need to use port forwarding:

> rhc port-forward <WILDFLY_APP_NAME>

 

Checking available ports ... done
Forwarding ports ...

To connect to a service running on OpenShift, use the Local address

Service Local OpenShift
------- -------------- ---- -------------------
java 127.0.0.1:8080 => 127.13.118.129:8080
java 127.0.0.1:9990 => 127.13.118.129:9990
java 127.0.0.1:9999 => 127.13.118.129:9999

In the example shown above, the Admin Console would then be available on your local machine at http://localhost:9990/console. To log into the Admin Console, you can use the username/password the WildFly cartridge automatically created for you. To find these values, simply ssh into your OpenShift instance and execute the following commands:

echo $OPENSHIFT_WILDFLY_USERNAME

echo $OPENSHIFT_WILDFLY_PASSWORD

 

Tips for migrating an existing OpenShift application to WildFly 9 Final

 

Migrating from WildFly 9 Alpha/Beta/CR

 

If you already have an existing WildFly 9 Alpha/Beta/CR OpenShift app, you can create a new WildFly 9 app based on the existing one using the following command:

rhc app create <NEW_WILDFLY_APP> --from-app <OLD_WILDFLY_APP>

This results in a new WildFly 9 Final application that's a clone of your existing one - same gear size, scaling configuration, environment variables, git repository, deployments, etc.

 

Migrating from WildFly 8 or AS 7

 

If you have an existing WildFly 8 or AS 7 OpenShift app, you can create a new WildFly 9 app using your existing app's git repo, as shown below. You'll want to first replace the standalone.xml file in your git repo's .openshift/config directory with the WildFly 9 standalone.xml file from here.

rhc app create <NEW_WILDFLY_APP> jboss-wildfly-9 --from-code http://url/to/git_repo.git

Alternatively, you can leave off the --from-code option above and manually copy the contents of your old git repo to your new app's git repo once the new app has been created.

 

Couple more steps when migrating from AS 7

 

When migrating from AS 7, there are a few more things to keep in mind:

  1. Any action hook scripts in your app's git repo (i.e., in .openshift/action_hooks) that end with "_jbossas" will need to be renamed to end with "_wildfly".
  2. Any action hook scripts with references to OpenShift environment variables that start with "OPENSHIFT_JBOSSAS_" will need to be updated to reference "OPENSHIFT_WILDFLY_" instead.

 

Fire up an OpenShift instance!

 

Getting WildFly 9 running on OpenShift is easy, try it out now, it only takes a few minutes. For more information about the WildFly cartridge, check out the documentation.

Since WildFly 8.2.0.Final was just released, the OpenShift WildFly cartridge has been updated as well. The WildFly cartridge is now a registered cartridge on OpenShift, which means it's easier than ever to create new apps from the command line! If you don't already have the OpenShift command line tools, follow the quick instructions here to install them. Then, simply use the following command to create a new WildFly 8.2.0.Final app:

rhc app create <APP> jboss-wildfly-8

That's it, no need to reference a long URL anymore in the creation command!

 

For more information on how to access your application, take a look at the cartridge documentation. Enjoy!

Since WildFly 8.1.0.Final was just released, the OpenShift WildFly cartridge has been updated as well and now includes support for Java 8! The WildFly cartridge now installs JDK 8 during instance creation since JDK 8 isn't available on OpenShift yet. All new WildFly applications on OpenShift will default to using Java 8. If you want to switch back to Java 7, simply rename the marker file in your application's git repo as follows:

 

git mv .openshift/markers/java8 .openshift/markers/java7
git commit -a -m "Switching to Java 7"
git push






















 

 

If you create a WildFly application based on an existing WildFly 8.0.0.Final or 8.1.0.CR1 OpenShift application using the --from-app command, your new WildFly 8.1.0.Final application will remain on Java 7. You can manually switch to Java 8 as follows:

 

1. In the pom.xml file in your application's git repo:

 

Change the maven.compiler.source and maven.compiler.target properties to:

 

<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>






















Add the following two properties:

 

<maven.compiler.executable>${env.OPENSHIFT_WILDFLY_DIR}usr/lib/jvm/jdk1.8.0_05/bin/javac</maven.compiler.executable>
<maven.compiler.fork>true</maven.compiler.fork>





















 

 

2. Now rename the marker file and push your changes:

 

git mv .openshift/markers/java7 .openshift/markers/java8
git commit -a -m "Switching to Java 8"
git push





















 

 

For more information on how to get started with the WildFly cartridge, take a look at the cartridge documentation. As always, feedback is welcome on the WildFly community forums. Enjoy!

Since WildFly 8.1.0.CR1 was released last week, the OpenShift WildFly cartridge has been updated as well.

 

Create a new WildFly 8.1.0.CR1 app

 

To create a new WildFly 8.1.0.CR1 application on OpenShift, you can either use the OpenShift Web Console or the following RHC command:

rhc app create <NEW_WILDFLY_APP> https://cartreflect-claytondev.rhcloud.com/reflect?github=openshift-cartridges/openshift-wildfly-cartridge

 

Create a new WildFly 8.1.0.CR1 app based on an existing app (takes a bit longer)

 

If you already have an existing WildFly 8.0.0.Final OpenShift application, you can try out a brand new RHC command that creates an application based on an existing one:


1. Upgrade to the latest version of the OpenShift command line tools:

gem update rhc

 

2. Create your WildFly 8.1.0.CR1 application using the new --from-app command:

rhc app create <NEW_WILDFLY_APP> --from-app <OLD_WILDFLY_APP>

 

This creates an application that's a clone of your existing one (i.e., same gear size, scaling configuration, environment variables, git repository, etc.). This means that your new WildFly 8.1.0.CR1 application will have the same configuration and deployment(s) as your existing application. However, because the --from-app command relies on an application snapshot, it will take some time to complete (be patient!). This should improve going forward since snapshot exclusions have now been added to the WildFly cartridge to reduce its snapshot footprint.


Be sure to check out the cartridge documentation for more information about the cartridge. Please try it out and provide feedback. Enjoy!

Since WildFly 8.0.0.Final was released this week, the OpenShift WildFly cartridge has been updated as well! There are a couple ways to get started quickly on OpenShift. To use the OpenShift Web Console to create your WildFly 8 application, simply click on "Deploy Now" here. If you'd like to use the OpenShift command line tools instead, just follow these steps:

 

Getting started from the command line

 

  1. Follow the instructions in the OpenShift Getting Started guide to install the OpenShift command line tools.
  2. Create your WildFly 8 OpenShift application using the following command:

rhc app create <APP> https://cartreflect-claytondev.rhcloud.com/reflect?github=openshift-cartridges/openshift-wildfly-cartridge

 

You're all set now!

 

Accessing your application

 

You can access your application via this url:

http://{APP}-{NAMESPACE}-rhcloud.com

 

To connect to your WildFly instance using the JBoss CLI tool, use the following commands:

  1. ssh into your application: rhc ssh <APP>
  2. jboss-cli.sh -c --controller=$OPENSHIFT_WILDFLY_IP:$OPENSHIFT_WILDFLY_MANAGEMENT_HTTP_PORT

 

To access the WildFly Admin Console, port forwarding can be used:

> rhc port-forward <APP>

 

Checking available ports ... done
Forwarding ports ...

To connect to a service running on OpenShift, use the Local address

Service Local OpenShift
------- -------------- ---- -------------------
java 127.0.0.1:8080 => 127.13.118.129:8080
java 127.0.0.1:9990 => 127.13.118.129:9990

In the above example, the Admin Console can be accessed using http://localhost:9990.

 

For more information about the cartridge, take a look at the cartridge documentation.

 

Try it out!

 

It only takes a few minutes to get WildFly 8 up and running on OpenShift! We encourage you to try it out and provide feedback. Enjoy!

The AeroGear team is happy to announce the first community release of the AeroGear Push Server downloadable OpenShift cartridge. This cartridge handles the necessary installation and configuration for getting both the AeroGear UnifiedPush Server and the AeroGear SimplePush Server deployed to OpenShift in minutes. In particular, the cartridge provides:

 

  • the AeroGear UnifiedPush Server deployed to JBoss Application Server 7 on OpenShift
  • the AeroGear SimplePush Server embedded within the same JBoss Application Server 7 instance
  • MySQL datasources for persistence for both the AeroGear UnifiedPush Server and the AeroGear SimplePush Server

 

Getting started on OpenShift

 

Want to try out the downloadable cartridge? It's easy! Just follow these two simple steps:

 

  1. Create an OpenShift account and follow the instructions in the Getting Started guide to install the OpenShift command line tools.
  2. Create your AeroGear Push Server OpenShift application using the following command (notice that this command also adds the MySQL OpenShift cartridge to your application):
rhc app create <APP> https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push mysql-5.1

 

That's it! Now:

 

  • You can access the AeroGear UnifiedPush Server Administration Console via the following URL. Temporarily, there is an "admin:123" user. You will need to change this password when you first log in. Check out the Administration Console user guide for more information about the console.
http://{APP}-{NAMESPACE}-rhcloud.com
  • Client applications can establish secured connections to the AeroGear SimplePush Server via

https://{APP}-{NAMESPACE}-rhcloud.com:8443/simplepush

  • The AeroGear UnifiedPush Server and the AeroGear SimplePush Server persist all data to the MySQL database that's been added to your application's gear.

 

For more information about the downloadable cartridge, check out the cartridge documentation.

 

What's next?

 

The AeroGear Push Server OpenShift cartridge will soon be available directly from OpenShift Online. Stay tuned for that! In the meantime, we encourage you to provide feedback on the downloadable cartridge via our mailing list.

Minification is often considered to be a best practice for improving the performance of web applications since it helps to reduce page loading time. The wro4j plugin is one tool that can be used to minify JavaScript and CSS files at build-time or at run-time.

Manually configuring minification using wro4j

If you want to set up JavaScript and CSS minification at build-time for a web application that will be deployed on JBoss AS 7 or EAP 6 on OpenShift, you can do the following:

 

  1. Add a "minify" profile that configures the wro4j plugin to your pom.xml.
  2. Add a wro.properties file to src/main/webapp/WEB-INF/.
  3. Add a wro.xml file to src/main/webapp/WEB-INF/.
  4. Make sure the minified versions of your JavaScript and CSS files are referenced in your web application code.
  5. Override OpenShift's default maven arguments by setting MAVEN_ARGS in .openshift/action_hooks/pre_build_{jbossas-7,jbosseap} as follows:
MAVEN_ARGS="clean package -Popenshift,minify -DskipTests"

 

After completing these steps, the next time you use the OpenShift infrastructure to build your web application (e.g., after a git push), wro4j will be used to minify your files. Want to see an example? Take a look at the kitchensink-html5-mobile quickstart for an example of how to configure the wro4j plugin in pom.xml and for a sample wro.properties file and a sample wro.xml file.

Automatic wro4j configuration?

Although the minification configuration described above isn't too painful, it has to be repeated for each web application that's created. Since it's generally considered good practice to use minification, there could be value in having the OpenShift AS 7/EAP 6 cartridges do some of this configuration automatically. It's one way to make it easier for users to optimize their web applications. Note that when an application is created using the AS 7 or EAP 6 OpenShift cartridge, a default pom.xml file and a default maven src structure are created. The cartridge could potentially configure wro4j for the user by doing some or all of the following:

 

  • Adding a "minify" profile to the default pom.xml.
  • Adding a sample wro.properties and a sample wro.xml file to the default src/main/webapp/WEB-INF directory.
  • Adding the "minify" profile to the default maven arguments used to build the application. Alternatively, instead of enabling minification by default, a user could be required to specify that they want to use the "minify" profile by overriding OpenShift's default maven arguments via the pre_build_{jbossas-7,jbosseap} action hook.

 

Any thoughts on this?

It's hard to believe it's already been a year since I started working at Red Hat! Time really does fly when you're having fun! I recently finished working on a domain controller discovery system for JBoss AS 8 and thought I'd give an overview of this new feature.

What is it?

When setting up a managed domain, each host controller must be configured with information that's needed to contact the master domain controller. In AS 7, this information is provided by statically configuring the master domain controller's host and port. The domain controller discovery system for AS 8 provides support for a brand new form of discovery and also allows a host controller to be configured with multiple options for contacting the master domain controller.

A new form of discovery

In addition to static discovery, a host controller can now dynamically discover a master domain controller via Amazon S3. In particular, host controllers and the master domain controller can now be configured with information needed to access an S3 bucket (sample configuration is below). When a master domain controller is started, it will write its IP address and port to an S3 file in the given bucket. Then, whenever a slave host controller needs to contact the master domain controller, it will get its IP address and port from that S3 file. If the master domain controller's IP address changes (e.g., this is common when stopping and starting an EC2 instance), the host controllers won't need to be reconfigured. They'll be able to get the new address from the S3 file.

 

Slave host controller configuration:

<domain-controller>
    <remote security-realm="ManagementRealm">
      <discovery-options>
          <discovery-option name="s3-discovery" code="org.jboss.as.host.controller.discovery.S3Discovery" module="org.jboss.as.host-controller">
            <property name="access-key" value="s3_access_key"/>
            <property name="secret-access-key" value="s3_secret_access_key"/>
            <property name="location" value="s3_bucket_name"/>
          </discovery-option>
      </discovery-options>
    </remote>
</domain-controller>

 

Master domain controller configuration:

<domain-controller>
    <local>
        <discovery-options>
            <discovery-option name="s3-discovery" code="org.jboss.as.host.controller.discovery.S3Discovery" module="org.jboss.as.host-controller">
              <property name="access-key" value="s3_access_key"/>
              <property name="secret-access-key" value="s3_secret_access_key"/>
              <property name="location" value="s3_bucket_name"/>
          </discovery-option>
      </discovery-options>
    </local>
</domain-controller>


Support for multiple discovery options

A host controller can now be configured with multiple options for contacting a master domain controller (sample configuration is below). Currently, any number of static discovery or S3 discovery options are supported. Whenever a host controller needs to contact the master domain controller, it will now loop through the provided options, in order. The first option provided should be the one that's expected to succeed. The remaining discovery options can be used in failover situations. For example, if the primary domain controller fails, a backup can be brought online as the new domain controller and the host controllers will be able to connect to it without requiring any configuration changes!

 

<discovery-options>
    <discovery-option name="option-one" code="org.jboss.as.host.controller.discovery.S3Discovery" module="org.jboss.as.host-controller">
        <property name="access-key" value="s3_access_key"/>
        <property name="secret-access-key" value="s3_secret_access_key"/>
        <property name="location" value="s3_bucket_name"/>
    </discovery-option>
    <static-discovery name="option-two" host="172.16.81.100" port="9999"/>
    <static-discovery name="option-three" host="172.16.81.101" port="9999"/>
</discovery-options>

 

You can try out this new feature by using the latest AS 8 snapshot. Enjoy!