DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Super Fast Tomcat Installation using FTP and Version Control

Super Fast Tomcat Installation using FTP and Version Control

Roger Hughes user avatar by
Roger Hughes
·
Jan. 02, 13 · Interview
Like (0)
Save
Tweet
Share
6.65K Views

Join the DZone community and get the full member experience.

Join For Free

When talking about Continuous Delivery one of the tests that both Martin Fowler and Jez Humble often mention is their "flame thrower" test. It goes something like this: Jez will say "How long would it take you to get up and running if Martin and I went into your machine rooms armed with flame throwers and axes and started attacking your servers"?

The answer, of course, should be: "oh about an hour - right after we've put the fire out, swept up the mess, found some new servers, plugged them in and contacted our top flight lawyers so that we can sue you for criminal damage". Most of the time this isn't the case as deployment is all too often a manual process, with the guy doing the installation simply following a list of instructions written in a Word document. And what is a list of instructions? A computer program. Now, hands up everyone who likes writing Word documents. Okay, now hands up everyone who likes writing code... In your imagination, you should see a room full of people voting for writing code, so why is it that when there are opportunities for writing deployment scripts do we prefer (or get lumbered with) writing Word documents? It must be more fun, productive and cost effective to write scripts that do our deployment for us in seconds rather than writing Word documents and then do every deployment ourselves.

Assuming that your machine room has been trashed, then Let's consider what you need to get up and running again. For a start, you'll need a machine with a few common things setup. I'm simplifying here; however, you'll probably need:

  • some user accounts.
  • a pinch of networking (knowledge of where your DNS is etc)
  • the correct version of Java
  • a Subversion (or other version control) client
  • tomcat (or other server)
  • some configuration files
  • your WAR file

Now, this should be as simple as getting hold of a basic drive image or virtual machine and turning it on, letting it boot up and running a deployment script.

If you've ever read Jez Humble and David Farley book Continuous Delivery you'll know that one of the major points they make is that, when setting up your deployment process, you should store your configuration files in your version control system. This to me sounds like one of those really obvious and useful ideas that you only do when someone else points it out to you. This is usually taken to mean your application's configuration files, but should also refer to your server's configuration files.

The other thing you'll notice about Continuous Delivery is that although it's full of good ideas, it's intentionally short on practical coding examples1. If you read my blog you may recall that I've mentioned updating most of my tomcat's config files at one point or another; for example adding datasource details or an SSL configuration. With this in mind, the rest of this blog takes Jez's and David's sound ideas and demonstrates creating a simple install script for my tomcat server.

If you download your candidate version of tomcat and expand the tar/zip file, you'll notice that if has a conf directory, so the first thing to do is to add this directory to version control and delete it from the expanded tomcat binaries. You can now check the conf files out and modify them, adding SSL, an admin user, a MySQL data source or whatever you like. Don't forget to check them in again.


The next thing to do is to put the remaining binaries directories on a FTP server1 in an accessible safe place.

What you now have is a basic setup with all the files held in two convenient places These can now be recombined to create a functioning server.


The big idea here is that although combining these two parts can easily be done manually, the best approach is to do it automatically using a simple script.
#!/bin/sh
# 
echo Running Tomcat install Script

TOMCAT_VERSION=apache-tomcat-7.0.33-blog

# The FTP server holding the tomcat binaries
SERVER=
TOMCAT_LOCATION=/Public/binaries/
SERVER_USER=
SERVER_PASSWORD=
CUT_DIRS=3

# The version control details
SVN_USER=
SVN_PASSWORD=
SVN_URL=https:/Tomcat/apache-tomcat-7.0.33/conf

mkdir ../$TOMCAT_VERSION
pwd
echo changing directory
cd ../vim $TOMCAT_VERSION
pwd

wget -r -nH -nc --cut-dirs=$CUT_DIRS ftp://$SERVER_USER:$SERVER_PASSWORD@$SERVER$TOMCAT_LOCATION$TOMCAT_VERSION
 
echo ..
echo The directory looks like this:
ls
echo ..
echo Getting the config files from config..
 
svn --username=$SVN_USER --password=$SVN_PASSWORD co $SVN_URL

bin/startup.sh

# At this point handover to the application deploy script.
In my script you'll see that all I do is to use three simple commands. Firstly I use wget to copy the files from my FTP server to the new server location. The second command is the svn co command, which checks out my tomcat config files and the final command simply starts the server. The rest of the script is all variables, comments and padding.

Now, I'm guessing that one of the reasons that we write so many Word documents is for traceability, so the final trick is to let your script be the documentation by also storing it in version control.

So, there you have it, a simple way of creating tomcat server installations in seconds. Obviously the next step would be for the server install script to handover to another script that installs your web app(s) on the server, but more on that later.



1 I guess that the main reason why there are no concrete examples is that there is no fixed structure, such as the Maven directory structure, for creating servers or deploying code as each organisation is different. Is this a good thing? Probably not, perhaps there should be a move to create a "standard server" to match the "standard" way we lay code out.
2 This could also be a file server, SFTP or web server and the tomcat binaries could be zipped or unzipped.

 

File Transfer Protocol Version control Apache Tomcat Continuous Integration/Deployment

Published at DZone with permission of Roger Hughes, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • DZone's Article Submission Guidelines
  • What Was the Question Again, ChatGPT?
  • API Design Patterns Review
  • Microservices Discovery With Eureka

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: