Home » DevOps » Docker 3-Tier Java App (Nginx, Tomcat, MySQL) Automation on Any Cloud

About Amjad Afanah

Amjad Afanah
Amjad Afanah is the founder of DCHQ. He has extensive experience in application deployment automation and systems management. DCHQ was part of 500 Startups.

Docker 3-Tier Java App (Nginx, Tomcat, MySQL) Automation on Any Cloud

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 IP’s 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.

2097352_orig

1766514_orig 

Once the application is up and running, a user can monitor the CPU, Memory, & 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 time-line is available to track every change made to the application for auditing and diagnostics.

7572635_orig

8393152_orig

4364095_orig

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.

  3325521_orig

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

(0 rating, 0 votes)
You need to be a registered member to rate this.
Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments