This is an extension of this project (https://github.com/dchqinc/dchq-docker-java-example). The application now supports Solr for full-text search and both Mongo & Cassandra as the supported databases.

To run & manage the 24 Java application templates in this project on 13 different clouds and virtualization platforms (including vSphere, OpenStack, AWS, Rackspace, Microsoft Azure, Google Compute Engine, DigitalOcean, IBM SoftLayer, etc.), make sure that you either:

• Sign Up for FREE on DCHQ.io -- http://dchq.io (no credit card required), or
• Download DCHQ On-Premise Standard Edition for FREE -- http://dchq.co/dchq-on-premise-download.html

Table of Contents

• DCHQ - Docker Java Example
• A Step by Step Guide for Deploying & Managing a Docker-based Java Application with Solr on Mongo, Cassandra, MySQL and Oracle
  • Background
  • Configuring the Java files for database and Solr connection environment variables
  • Using the liquibase bean to initialize the connected MySQL, PostgreSQL and Oracle databases
  • Building the YAML-based application templates that can re-used on any Linux host running anywhere
    • Plug-ins to configure Web Servers and Application Servers at Request Time and Post Provision
    • Service Discovery with plug-in life-cycle stages
    • cluster_size and host Parameters for HA Deployment Across Multiple Hosts
    • Environment Variable Bindings Across Images
    • Multi-Tier Java (Nginx – Tomcat – Solr - MySQL)
    • Multi-Tier Java (Nginx – Tomcat – Solr - Oracle-XE)
    • Multi-Tier Java (Nginx – Tomcat – Solr - Mongo)
    • Multi-Tier Java (Nginx – Tomcat – Solr - Cassandra)
    • Multi-Tier Java (Nginx – Jetty – Solr - MySQL)
    • Multi-Tier Java (Nginx – Jetty – Solr - Oracle-XE)

DCHQ - Docker Java Example

 

A Step by Step Guide for Deploying & Managing a Docker-based Java Application with Solr on Mongo, Cassandra, MySQL and Oracle

 

Background

Containerizing enterprise Java applications is still a challenge mostly because existing application composition frameworks do not address complex dependencies, external integrations or auto-scaling workflows post-provision. Moreover, the ephemeral design of containers meant that developers had to spin up new containers and re-create the complex dependencies & external integrations with every version update.

DCHQ, available in hosted and on-premise versions, addresses all of these challenges and simplifies the containerization of enterprise Java applications through an advance application composition framework that extends Docker Compose with cross-image environment variable bindings, extensible BASH script plug-ins that can be invoked at request time or post-provision, and application clustering for high availability across multiple hosts or regions with support for auto scaling.

Once an application is provisioned, a user can monitor the CPU, Memory, & I/O of the running containers, get notifications & alerts, and get access to application backups, automatic scale in/out workflows, and plug-in execution workflows to update running containers. Moreover, out-of-box workflows that facilitate Continuous Delivery with Jenkins allow developers to refresh the Java WAR file of a running application without disrupting the existing dependencies & integrations.

In previous blogs, we demonstrated the end-to-end deployment automation of various Java applications (like Pizza Shop and Movie Store apps) on multi-tier Docker-based application stacks across 13 different clouds & virtualization platforms. For full list of these blogs, you can visit this page: http://dchq.co/docker-java-applications.html

However many users were still confused on some of the fundamental aspects of application modeling. These questions include:

• Where do these environment variables come from in your YAML-based application template?

• How is the database initialized with the proper schemas needed from my Java application?

• I already have a deployment plan for my WebLogic Application Server. Can I run my own script for deploying a Java application?

To address these questions, we created a sample “Names Directory” Java application in this GitHub project that can be deployed on these application stacks:

• Apache HTTP Server (httpd) and Nginx (for load balancing)

• JBoss, Tomcat and Jetty (as the application server)

• Solr (for the full-text search)

• Mongo, Cassandra, MySQL, and Oracle (for the database)

In this project, we will provide a step-by-step guide for configuring, deploying and managing this Java application using different application stacks and on different cloud/virtual infrastructure.

We will cover:

• Configuring the Java files for database and Solr connection environment variables

• Using the liquibase bean to initialize the connected database

• Building the YAML-based application templates that can re-used on any Linux host running anywhere

• Provisioning & auto-scaling the underlying infrastructure on any cloud (with Rackspace being the example in this blog)

• Deploying the multi-tier Java application on the Rackspace cluster

• Monitoring the CPU, Memory & I/O of the Running Containers

• Enabling the Continuous Delivery Workflow with Jenkins to update the WAR file of the running applications when a build is triggered

• Scaling out the Application Server Cluster when the application is resource-constrained

 

Configuring the Java files for database and Solr connection environment variables

You can clone this sample “Names Directory” Java application from GitHub.

git clone https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example.git

This is the most important step in “Dockerizing” your Java application. In order to leverage the environment variables you can pass when running containers, you will need to make sure that your application is configured in a way that will allow you to change certain properties at request time – like:

• The Solr URL & port you would like to use

• The database driver you would like to use

• The database URL

• The database credentials

• Any other parameters that you would like to change at request time (e.g. the min/max connection pool size, idle timeout, etc.)

To achieve this, we created several Java files to declare the environment variables we need to use to connect to the database and Solr. The Java files can be found in the config directory:

https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/tree/master/src/main/java/dchq/dbconnect/config

Let's first examine SolrConfig.java: https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/SolrConfig.java

@Configuration
public class SolrConfig {
    public static final String SOLR_HOST = "solr_host";
    public static final String SOLR_PORT = "solr_port";

You will notice that solr_host and solr_port are declared as environment variables that you can pass when running the applicatio