Over a million developers have joined DZone.

Docker 3-Tier Java App Automation on Any Cloud

Deployment automation and lifecycle management of a Java application deployed on Tomcat Servers with Nginx for load balancing and MySQL for the database.

· Java Zone

Navigate the Maze of the End-User Experience and pick up this APM Essential guide, brought to you in partnership with CA Technologies

DCHQ simplifies the containerization of enterprise applications and makes it possible to replicate very complex application environments on multiple hosts through a one-click deploy button. DCHQ does not just automate the application deployments, but it also integrates with 12 different cloud providers to automate the provisioning and auto-scaling of Weave-enabled clusters consisting of distributed virtual machines.

In this blog, we will go over the deployment automation and lifecycle management of a Docker-based 3-tier Java application deployed on Tomcat Servers with Nginx for load balancing and MySQL for the database.

This can be done by navigating to the Self-Service Library and then clicking on Customize to request a multi-tier application. In this example, we have a multi-tier application consisting of Nginx (for load-balancing), Tomcat (the clustered application server), and MySQL (as the database). You will notice Nginx is invoking a BASH script plug-in to add the container IPs of the application servers in the default.conf file dynamically (or at request time). Tomcat is also invoking a BASH script plug-in to deploy a Java WAR file from a specified URL. You will notice that the cluster_size parameter allows you to specify the number of containers to launch (with the same application dependencies). The host parameter allows you to specify the host you would like to use for container deployments. Here are the values supported for the host parameter:

  • host1, host2, host3, etc. – Selects a host randomly within a data-center (or cluster) for container deployments
  • <IP Address 1, IP Address 2, etc.> – Allows a user to specify the actual IP addresses to use for container deployments
  • <Hostname 1, Hostname 2, etc.> – Allows a user to specify the actual hostnames to use for container deployments
  • Wildcards (e.g. “db-*”, or “app-srv-*”) – To specify the wildcards to use within a hostname

Additionally, a user can create cross-image environment variable bindings by making a reference to another image’s environment variable. Here is a list of supported environment variables:

  • {{alphanumeric | 8}} – Creates a random 8-character alphanumeric string. This is most useful for creating random passwords.
  • {{<Image Name> | ip}} – Allows you to enter the host IP address of a template as a value for an environment variable. This is most useful for allowing the middleware tier to establish a connection with the database.
  • {{<Image Name> | container_ip}} – Allows you to enter the container name (or internal IP) of a template as a value for an environment variable. This is most useful for allowing the middleware tier to establish a secure connection with the database (without exposing the database port).
  • {{<Image Name> | port _<Port Number>}} – Allows you to enter the Port number of a template as a value for an environment variable. This is most useful for allowing the middleware tier to establish a connection with the database. In this case, the port number specified needs to be the internal port number, i.e. not the external port that is allocated to the container. For example, {{PostgreSQL | port_5432}} will be translated to the actual external port that will allow the middleware tier to establish a connection with the database.
  • {{<Image Name> | <Environment Variable Name>}} – Allows you to enter the value an image’s environment variable into another image’s environment variable. The use cases here are endless, as most multi-tier applications will have cross-image dependencies.

A user can select an Environment Tag (like DEV or QE) and a Weave-enabled Data Center before clicking on Run.

Picture

Picture

Once the application is up and running, a user can monitor the CPU, Memory, and I/O Utilization of the running containers and perform day-2 operations like Backup, Container Updates using BASH plug-ins, Scale In/Out and Continuous Delivery.

In the recorded demo, we scaled out the application server cluster from 2 to 3. A user can schedule the scale-out during business hours and the scale in during weekends. We then used the BASH plug-in to update Nginx’s default.conf file so that it’s aware of the new application server added. The BASH script plug-ins can also be scheduled to accommodate use cases like cleaning up logs or updating configurations at defined frequencies. An application timeline is available to track every change made to the application for auditing and diagnostics.

Picture

Picture

Picture

Alerts and notifications are available for when containers or hosts are down or when the CPU & Memory Utilization of either hosts or containers exceed a defined threshold.


Picture

Sign Up for FREE on DCHQ.io Hosted PaaS (http://dchq.io) to get this template along with Ruby, Python, PHP, MEAN.JS, Clustered MongoDB, and many other template.


Download DCHQ On-Premise Now


Thrive in the application economy with an APM model that is strategic. Be E.P.I.C. with CA APM.  Brought to you in partnership with CA Technologies.

Topics:
docker ,java ,mysql ,nginx ,cloud

Published at DZone with permission of Amjad Afanah, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}