Last week, Wildfly community has just released Wildfly 9.0.0.Final and I wrote a post about enabling HTTP2 into Wildlfy via the offline command line. Today, we will see how to do it with a Docker container. Docker container simplifies lot of thing when we need to deploy middleware infrastructure. I love this technology, because it is an Open Source project, it provides lot of command line stuff, the build process is awesome and run process is very easy ;-).

How to setup HTTP/2 configuration into Wildfly 9.0.0.Final with offline mode via Docker container.

Let’s see how to do it.

Requisites

Docker is already installed and running. Please see official documentation

X509 Certificate

HTTP/2 doesn’t need an encryption layer for transport, but we gonna implement it in this example.

Create certificates like I wrote my previous blog post

Warning

Be Careful, Firefox doesn’t accept anymore selfsigned certificate (to confirm, I switch to Chrome). I will post soon an full shell script PKI generation ;-)

Build the Wilfly Docker image

In this section, we will build the wildfly-http2 docker image.

But before building it we have to create a directory and copy :

  • previous keystore.jks and trustore.jks files

  • offlinecli-http2.cli file

curl https://gist.githubusercontent.com/gautric/604e885885df0ed042f8/raw/f7d668edd82c35c23215a8a812074a4d47e1688b/offline-http2.cli -o offlinecli-http2.cli
  • Dockerfile file
curl https://gist.githubusercontent.com/gautric/c705e9e8572dd84b2bd9/raw/3ebfe805e767343f91104ef87ff3c0793f3efdd3/Dockerfile -o Dockerfile

Build your image with the next comand line sample

docker  build --rm=true --tag=wildfly-http2   .

You should retrieve an output like this

[mbp:~/Source/local/wildfly-docker]$> docker --tlsverify=false  build --rm=true --tag=wildfly-http2   .
Sending build context to Docker daemon 74.75 kB
Sending build context to Docker daemon
Step 0 : FROM jboss/wildfly
 ---> e908c8c95a8b
Step 1 : ENV ALPN_VERSION 8.1.3.v20150130
 ---> Using cache
 ---> 87116bbedcb5
Step 2 : ENV ALPN_LIB_DIR /tmp/eclipse/lib
 ---> Using cache
 ---> b4672d6008ee
Step 3 : ENV HTTP2_ENABLE_CLI offlinecli-http2.cli
 ---> Using cache
 ---> 635ac811b927
Step 4 : ADD keystore.jks /opt/jboss/wildfly/standalone/configuration/keystore.jks
 ---> Using cache
 ---> d0e62373566c
Step 5 : ADD truststore.jks /opt/jboss/wildfly/standalone/configuration/truststore.jks
 ---> Using cache
 ---> f3e274485c1c
Step 6 : RUN mkdir -p $ALPN_LIB_DIR
 ---> Using cache
 ---> fd2da0f5ee22
Step 7 : RUN curl http://central.maven.org/maven2/org/mortbay/jetty/alpn/alpn-boot/$ALPN_VERSION/alpn-boot-$ALPN_VERSION.jar > $ALPN_LIB_DIR/alpn-boot-$ALPN_VERSION.jar
 ---> Using cache
 ---> f8032e23c9b5
Step 8 : ENV JAVA_OPTS "$JAVA_OPTS -Xbootclasspath/p:$ALPN_LIB_DIR/alpn-boot-$ALPN_VERSION.jar"
 ---> Using cache
 ---> 3e49cf6ca1c6
Step 9 : ADD $HTTP2_ENABLE_CLI /tmp/
 ---> Using cache
 ---> e309bce6ec5a
Step 10 : RUN /opt/jboss/wildfly/bin/jboss-cli.sh --file=/tmp/$HTTP2_ENABLE_CLI
 ---> Using cache
 ---> 85fb55ecc742
Step 11 : RUN rm -rf /opt/jboss/wildfly/standalone/configuration/standalone_xml_history
 ---> Using cache
 ---> 566da0a2cb80
Step 12 : CMD /opt/jboss/wildfly/bin/standalone.sh -b 0.0.0.0
 ---> Using cache
 ---> 3372a817bfc1
Successfully built 3372a817bfc1

Startup the Wilfly Docker image

After a full an a correct configuration, you can startup the JBoss instance as a container via your container provider aka Docker. Startup like this

 docker run -it -p 9990:9990 -p 8080:8080 -p 8443:8443 wildfly-http2

Check it

After a very quick JBoss startup inside Docker container (about 3s), you can check the welcome page (with Linux Docker) or the welcome page (with MAC OSX Docker) with your favorite browser like Chrome. I use to check HTTP/2 protocol, the network panel available inside Chrome.

Conclusion

Docker (Today) and HTTP/2 (tomorrow) will be inevitable for their specific reasons. The first one simplifies full stack deployment from the OS to application including middleware. The second one is an huge update of WWW protocol to improve network performance (binary header), latency (multiplexing) and security (TLS recommended).