Tag Archives: techtip

Bind WildFly to a different IP address, or all addresses on multihomed (Tech Tip #75)

techtip, wildfly,

Interface is a logical name, in WildFly parlance, for a network interface/IP address/host name to which sockets can be bound. There are two interfaces: “public” and “management”.

The “public” interface binding is used for all application related network communication (i.e. Web, Messaging, etc). The “management” interface is used for all components and services that are required by the management layer (i.e. the HTTP Management Endpoint).

By default, “public” interface is configured to listen on the loopback address of 127.0.0.1. So if you start WildFly as:

Then WildFly default page can be accessed as http://127.0.0.1:8080. Usually, /etc/hosts provide a mapping of 127.0.0.1 to localhost, and so the same page is accessible at http://localhost:8080. 8080 is the port where all applications are accessed.

On a multihomed machine, you may like to start WildFly and bind “public” interface to a specific IP address. This can be easily done as:

Now the applications can be accessed at http://192.168.1.1:8080.

For compatibility, -b 192.168.1.1 is also supported but -b=192.168.1.1 is recommended.

Or, if you want to bind to all available IP addresses, then you can do:

Similarly, by default, WildFly can be managed using Admin Console at http://127.0.0.1:9990. 9990 is the management port.

WildFly “management” interface can be bound to a specific IP address as:

Now Admin Console can be accessed at http://192.168.1.1:9990.

Or, bind “management” interface to all available IP addresses as:

You can also bind to two specific addresses as explained here.

Of course, you can bind WildFly “public” and “management” interface together as:

Learn more about it Interface and Port Configuration in WildFly. And more about these switches in Controlling the Bind Address with -b.

Java EE 7 and WildFly on Kubernetes using Vagrant (Tech Tip #71)

containers, javaee, techtip, wildfly, , , ,

This tip will show how to run a Java EE 7 application deployed in WildFly and hosted using Kubernetes and Docker. If you want to learn more about the basics, then this blog has already published quite a bit of content on the topic. A sampling of some of the content is given below:

Lets get started!

Start Kubernetes cluster

Kubernetes cluster can be easily started on a Linux machine using the usual scripts. There are Getting Started Guides for different platforms such as Fedora, CoreOS, Amazon Web Services, and others. Running a Kubernetes cluster on Mac OS X require to use the Vagrant image which is also explained in Getting Started with Vagrant. This blog will use the Vagrant box.

  1. By default, Kubernetes cluster management scripts assumes you are running on Google Compute Engine. Kubernetes can be configured to run with a variety of providers: gce, gke, aws, azure, vagrant, local, vsphere. So lets set our provider to vagrant as:
    This means, your Kubernetes cluster is running inside a Fedora VM created by Vagrant.
  2. Start the cluster as:
    Notice, this command is given from the kubernetes directory where it is already compiled as explained in Build Kubernetes on Mac OS X.

    By default, the Vagrant setup will create a single kubernetes-master and 1 kubernetes-minion. This involves creating Fedora VM, installing dependencies, creating master and minion, setting up connectivity between them, and a whole lot of other things. As a result, this step can take a few minutes (~10 mins on my machine).

Verify Kubernetes cluster

Now that the cluster has started, lets make sure we verify it does everything that its supposed to.

  1. Verify the that your Vagrant images are up correctly as:
    This can also be verified by verifying the status in Virtual Box console as shown:

    Kubernetes Virtual Machines in Virtual Box
    Kubernetes Virtual Machines in Virtual Box

    boot2docker-vm is the Boot2Docker VM. Then there is Kubernetes master and minion VM. Two additional VMs are shown here but they not relevant to the example.

  2. Log in to the master as:

    Verify that different Kubernetes components have started up correctly. Start with Kubernetes API server:

    Then Kube Controller Manager:

    Similarly you can verify etcd and nginx as well.

    Docker and Kubelet are running in the minion and can be verified by logging in to the minion and using systemctl scripts as:

  3. Check the minions as:

    Only one minion is created. This can be manipulated by setting an environment variable NUM_MINIONS variable to an integer before invoking kube-up.sh script.

    Finally check the pods as:

    This shows a single pod is created by default and has three containers running:

    • skydns: SkyDNS is a distributed service for announcement and discovery of services built on top of etcd. It utilizes DNS queries to discover available services.
    • etcd: A distributed, consistent key value store for shared configuration and service discovery with a focus on being simple, secure, fast, reliable. This is used for storing state information for Kubernetes.
    • kube2sky: A bridge between Kubernetes and SkyDNS. This will watch the kubernetes API for changes in Services and then publish those changes to SkyDNS through etcd.

    No pods have been created by our application so far, lets do that next.

Start WildFly and Java EE 7 application Pod

Pod is created by using the kubectl script and providing the details in a JSON configuration file. The source code for our configuration file is available at github.com/arun-gupta/kubernetes-java-sample, and looks like:

The exact payload and attributes of this configuration file are documented at kubernetes.io/third_party/swagger-ui/#!/v1beta1/createPod_0. Complete docs of all the possible APIs are at kubernetes.io/third_party/swagger-ui/. The key attributes in this fie particularly are:

  • A pod is created. API allows other types such as “service”, “replicationController” etc. to be created.
  • Version of the API is “v1beta1”.
  • Docker image arungupta/javaee7-hol used to run the container.
  • Exposes port 8080 and 9090, as they are originally exposed in the base image Dockerfile. This require further debugging on how the list of ports can be cleaned up.
  • Pod is given a label “wildfly”. In this case, its not used much but would be more meaningful when services are created in a subsequent blog.

As mentioned earlier, this tech tip will spin up a single pod, with one container. Our container will be using a pre-built image (arungupta/javaee7-hol) that deploys a typical 3-tier Java EE 7 application to WildFly.

Start the WildFly pod as:

Check the status of the created pod as:

The WildFly pod is now created and shown in the list. The HOST column shows the IP address on which the application is accessible.

The image below explains how all the components fit with each other:

Java EE 7/WildFly in Kubernetes on Mac OS X
Java EE 7/WildFly in Kubernetes on Mac OS X

As only one minion is created by default, this pod will be created on that minion. The blog will show how multiple minions can be created. Kubernetes of course picks the minion where the pods are created.

Running the pod ensures that the Java EE 7 application is deployed to WildFly.

Access Java EE 7 Application

From the kubectl.sh get pods output, HOST column shows the IP address where the application is externally accessible. In our case, the IP address is 10.245.1.3. So, access the application in the browser to see output as:

Java EE 7 Application on Kubernetes
Java EE 7 Application on Kubernetes

 

This confirms that your Java EE 7 application is now accessible.

Kubernetes Debugging Tips

Once the Kubernetes cluster is created, you’ll need to debug it and see what’s going on under the hood.

First of all, lets log in to the minion:

List of Docker containers on Minion

Lets take a look at all the Docker containers running on minion-1:

The first container is specific to our application, everything else is started by Kubernetes.

Details about each Docker container

More details about each container can be found by using their container id as:

In our case, the output is shown as:

Logs from the Docker container

Logs from the container can be seen using the command:

In our case, the output is shown as:

WildFly startup log, including the application deployment, is shown here.

Log into the Docker container

Log into the container and show WildFly logs. There are a couple of ways to do that.

First is to use the container id and use “exec”:

In our case, log into the container as:

Other, more classical way, is to get the process id of the container as:

In our case, the output is:

And now log into the container as:

And now the complete WildFly distribution is available at:

Clean up the cluster

Entire Kubernetes cluster can be cleaned either using Virtual Box console, or using the command line as:

So we learned how to run a Java EE 7 application deployed in WildFly and hosted using Kubernetes and Docker.

Enjoy!