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.
https://www.youtube.com/watch?v=kQp_p3_CDo0
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.
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.
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.
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
| Reference: | Docker 3-Tier Java App (Nginx, Tomcat, MySQL) Automation on Any Cloud from our JCG partner Amjad Afanah at the DCHQ.io blog. |
