The instructor setup is designed to make the lab most reliable even with bad internet connections. Most if not all of the software can be directly downloaded from the instructor machine. The machine is setup as docker host and also runs a docker registry. Please make sure to execute these instructions way prior to the lab to provide a good experience to the attendees.

Go directly to the Instructor Setup

This lab is designed for a BYOL (Brying Your Own Laptop) style hands-on-lab. We did our best to support a wide range of client configurations but only did test on machines as stated in the hardware section. Please make sure to double check your configuration.

Go directly to the attendee Setup

Docker simplifies software delivery by making it easy to build and share images that contain your application’s entire environment, or application operating system.

What does it mean by application operating system ?

Your application typically require a specific version of operating system, application server, JDK, database server, may require to tune the configuration files, and similarly multiple other dependencies. The application may need binding to specific ports and certain amount of memory. The components and configuration together required to run your application is what is referred to as application operating system.

You can certainly provide an installation script that will download and install these components. Docker simplifies this process by allowing to create an image that contains your application and infrastructure together, managed as one component. These images are then used to create Docker containers which run on the container virtualization platform, provided by Docker.

What can a Java Developer use Docker for?

Faster delivery of your applications

Docker helps you with the development lifecycle. Docker allows you to develop on local containers that contain your applications and services. It can then integrate into a continuous integration and deployment workflow.

For example, you write code locally and share the development stack via Docker with colleagues. When everybody is ready, you push the code and the stack you all are developing onto a test environment and execute any required tests. From the testing environment, you can then push the Docker images into production and deploy your code.

Deploying and scaling more easily

Docker’s container-based platform allows for portable workloads. Docker containers can run on a developer’s local host, on physical or virtual machines in a data center, or in the Cloud.

Docker’s portability and lightweight nature also make dynamically managing workloads easy. You can use Docker to quickly scale up or tear down applications and services. <Docker is so fast, that scaling can be near real time.

How is it different from VM?

Docker is an open source container virtualization platform.

Docker has three main components:

1. Images are build component of Docker and a read-only template of application operating system.

2. Containers are run component of Docker, and created from, images.Containers can be run, started, stopped, moved, and deleted.

3. Images are stored, shared, and managed in a registry, the distribution component of Docker. The publically available registry is known as Docker Hub.

In order for these three components to work together, there is Docker Daemon that runs on a host machine and does the heavy lifting of building, running, and distributing Docker containers. In addition, there is Client that is a Docker binary which accepts commands from the user and communicates back and forth with the daemon.

Client communicates with Daemon, either co-located on the same host, or on a different host. It requests the Daemon to pull an image from the repository using pull command. The Daemon then downloads the image from Docker Hub, or whatever registry is configured. Multiple images can be downloaded from the registry and installed on Daemon host. Images are run using run command to create containers on demand.

How does a Docker Image work?

We’ve already seen that Docker images are read-only templates from which Docker containers are launched. Each image consists of a series of layers. Docker makes use of union file systems to combine these layers into a single image. Union file systems allow files and directories of separate file systems, known as branches, to be transparently overlaid, forming a single coherent file system.

One of the reasons Docker is so lightweight is because of these layers. When you change a Docker image—for example, update an application to a new version— a new layer gets built. Thus, rather than replacing the whole image or entirely rebuilding, as you may do with a virtual machine, only that layer is added or updated. Now you don’t need to distribute a whole new image, just the update, making distributing Docker images faster and simpler.

Every image starts from a base image, for example ubuntu, a base Ubuntu image, or fedora, a base Fedora image. You can also use images of your own as the basis for a new image, for example if you have a base Apache image you could use this as the base of all your web application images.

Note: Docker usually gets these base images from Docker Hub.

Docker images are then built from these base images using a simple, descriptive set of steps we call instructions. Each instruction creates a new layer in our image. Instructions include actions like:

1. Run a command.

2. Add a file or directory.

3. Create an environment variable.

4. What process to run when launching a container from this image.

These instructions are stored in a file called a Dockerfile. Docker reads this Dockerfile when you request a build of an image, executes the instructions, and returns a final image.

How does a container work?

A container consists of an operating system, user-added files, and meta-data. As we’ve seen, each container is built from an image. That image tells Docker what the container holds, what process to run when the container is launched, and a variety of other configuration data. The Docker image is read-only. When Docker runs a container from an image, it adds a read-write layer on top of the image (using a union file system as we saw earlier) in which your application can then run.

Machine makes it really easy to create Docker hosts on your computer, on cloud providers and inside your own data center. It creates servers, installs Docker on them, then configures the Docker client to talk to them.

Once your Docker host has been created, it then has a number of commands for managing them:

1. Starting, stopping, restarting

2. Upgrading Docker

3. Configuring the Docker client to talk to your host

You used Docker Machine already during the attendee setup. We won’t need it too much further on. But if you need to create hosts, it’s a very handy tool to know about. From now on we’re mostly going to use the docker client. Find out more about the details at the Official Docker Machine Website

Check if docker machine is working with

The client communicates with the demon process on your host and let’s you work with images and containers. Check if your client is working with

The most important options you’ll be using frequently are:

1. run - runs a container

2. ps- lists containers

3. stop - stops a container

Get a full list of available commands with

TicketMonster is an example application that focuses on Java EE6 - JPA 2, CDI, EJB 3.1 and JAX-RS along with HTML5 and jQuery Mobile. It is a moderately complex application that demonstrates how to build modern web applications optimized for mobile & desktop. TicketMonster is representative of an online ticketing broker - providing access to events (e.g. concerts, shows, etc) with an online booking application.

Apart from being a demo, TicketMonster provides an already existing application structure that you can use as a starting point for your app. You could try out your use cases, test your own ideas, or, contribute improvements back to the community.

The application uses Java EE 6 services to provide business logic and persistence, utilizing technologies such as CDI, EJB 3.1 and JAX-RS, JPA 2. These services back the user-facing booking process, which is implemented using HTML5 and JavaScript, with support for mobile devices through jQuery Mobile.

The administration site is centered around CRUD use cases, so instead of writing everything manually, the business layer and UI are generated by Forge, using EJB 3.1, CDI and JAX-RS. For a better user experience, Twitter Bootstrap is used.

Monitoring sales requires staying in touch with the latest changes on the server side, so this part of the application will be developed in HTML5 and JavaScript using a polling solution.

First thing, you’re going to do is to build the application from source. Create a folder for the source and change to it

And checkout the sources from the instructor git repository.

From here, you’re free to explore the application a bit. Open it with JBDS and find more background about the use-cases and how the application is designed at the Ticket Monster Website.

Copy the Maven lab-settings.xml file that you have downloaded from the instructor machine and place it inside /docker-java

When you’re ready, it is time to build the application. Switch to the checkout directory and run maven package.

Congratulations: You just build the applications war file. Let’s see if this can be deployed.

The application needs two things from an infrastructure perspective. A WildFly application server and a Postgress Database. Let Docker do the magic for us.

Check if your docker host is running

If the machine state is stopped, starte it with

After it is started you can find out about the IP address of your host with

We already did this during the setup document, remember? So, this is a good chance to check, if you already added this IP to your hosts file. Type:

and see if this resolves to the IP address that the docker-machine command printed out. If it does, you’re ready to start over with the lab. Let’s get started with the real work.

Time to bring in WildFly and a database. You’ll start with the database. We choose Postgres as our database for the Ticketmonster application.

This command starts a container named "db" from the image in your instructor’s registry "<INSTRUCTOR_IP>:5000/postgres". As this will not be present locally, it needs to be downloaded first. But you’ll have a very quick connection to the instructor registry and this shouldn’t take long. The two "-e" options define environment variables which are read by the db at startup and allow us to access the database with this user and password. Finally, the "-d" option tells docker to start a demon process. Which means, that the console window, you’re running this command in, will be available again after it is issued. If you skip this parameter, the console will be directly showing the output from the process. "-p" option maps container ports to host ports and allows other containers on our host to access them.

This should have worked. To double check if it did, you can see the server logs

The "-f" flag keeps refreshing the logs and pushes new events directly out to the console.

After the database server is up and running we now need the WildFly.

This command starts a container named "wildfly" and links this container to the db (--link option) container we started earlier.

The "-v" flag maps a local directory into the host. This will be the place to put the deployments. Please make sure to use -v /c/Users/ notation for drive letters on windows. The other options are known to you already. Check the logs if the server is started.

And access the http://dockerhost:8080 with your webbrowser to make sure the instance is up and running.

Now you’re ready to deploy the application for the first time. Let’s use JBoss Developer Studio for this.

For the first deployment we used a shared volumen on the host computer. Let’s explore deeper, what other deployment options we have

Deployment to WildFly Container using Management API

A standalone WildFly process, process can be configured to listen for remote management requests using its "native management interface". The CLI tool that comes with the application server uses this interface, and user can develop custom clients that use it as well. In order to use this, the wildfly management interface listen IP needs to be changed from 127.0.0.1 to 0.0.0.0 which basically means, that it is not only listening on the localhost but also on all publicly assigned IP addresses.

The database server is still up an running. Now we’re starting another WildFly instance again:

As you can see, there is no mapped volume in this case but an additional port exposed. The WildFly image that is used makes ist easier for you to play around with the deployment via the management API. It has a tweaked start script which changes the management interface according to the behavior described in the first sentence. Now go and create another new server adapter in JBoss Developer Studio.

Keep the defaults in the adapter properties.

Set up server properties by specifying the admin credentials (Admin#70365). Note, you need to delete the existing password and use this instead:

Right-click on the newly created server adapter and click “Start”.Status quickly changes to “Started, Synchronized” as shown.

Now you need to right-click, Run on Server on the ticket-monster application and chose this server. The project runs and displays the start page of ticket-monster.

Keep the WildFly instance up and running this time. We will re-use it for the next deployment option.

Using the CLI

The Command Line Interface (CLI) is a tool for connecting to WildFly instances to manage all tasks from command line environment. Some of the tasks that you can do using the CLI are:

1. Deploy/Undeploy web application in standalone/Domain Mode.

2. View all information about the deployed application on runtime.

3. Start/Stop/Restart Nodes in respective mode i.e. Standalone/Domain.

4. Adding/Deleting resource or subsystems to servers.

In order to work with the CLI you need to have it locally installed on your machine. Your instructor has a download prepared for you at http://<INSTRUCTOR_IP:8082>/downloads/ Unzip into a folder of your choice (e.g. /Users/arungupta/WildFly82/). This folder is named $WIDLFY_HOME from here on. Make sure to add the /Users/arungupta/WildFly82/bin to your path environment variable.

Now run the jboss-cli command and connect to the running WildFly instance.

Once that you’re connected through the jboss-cli, run:

Now you’ve been sucessfully using the CLI to remotely deploy the ticket-monster application to a running docker container. And again, keep the container running, we’re going to look into the last deployment option you have.

Using the web console

The build in Web-Console also relies on the same management APIs that we’ve already been using via JBoss Developer Tools and the CLI. It does provide a nice web-based way to administrate your instance and if you’ve already exposed the container ports, you can simply access it via the URL: http://dockerhost:9990 in your webbrowser. This will point you to the management interface

If you’re prompted for username and password enter "admin" as username and "docker#admin" as password. Now navigate through it and execute the following steps:

1. Go to the "Deployments tab".

2. Click on "Replace" button.

3. On the "Step 1/2" screen, select the <TICKET_MONSTER_PATH>/ticket-monster.war file on your computer and click "Next".

4. On the "Step 2/2" screen, click "Next" again.

Now you’ve been successfully deploying the Ticket Monster application in three different ways. Time to look at some more features, that Docker can provide to Java developers. Make sure to stop the WildFly instance after this last option.

Stop wildfly when you’re done.