I’d like to get involved in a project at work that involves taking a tool comprised of a lot of databases and web servers (running Java in Apache Tomcat) and putting them into “the cloud” using best-practice architectures for installation, upgrade, maintenance, patching, backup, & recovery considerations.

After reading this helpful background about Tomcat by Secure Any Cloud, I think I’ve just come up with my first “hello world” homework assignment.

The plan

• Rent a machine from a cloud service with which I have some free credits.
  • Always use Terraform to control working with the cloud service; avoid cloud-service-specific tools & GUIs as much as possible.
• Install & run Linux, Java, & Tomcat hosting Apache’s sample.war file on a non-8080 port.
  • Always use Git & continuous integration/deployment tools (Ansible? Jenkins?) & container images (Kubernetes? Docker?) rather than SSHing / SFTPing into the rented machine’s CLI or clicking around in GUI configuration panels when possible.
• Make sure sample has a public IP address – maybe even a public domain name to be snazzy.
  • Continue to pay attention to tooling & automation / infrastructure-as-code.
• Visit http://...:xxxx/sample/ from my home computer to confirm it’s alive and on the web.
• Kill the server & deallocate any IP / domain names gracefully.
  • Always use Terraform to control working with the cloud service; avoid cloud-service-specific tools & GUIs as much as possible.

The accomplishment

According to one of my colleagues, the jargon I can say I’m studying is:

1. Provisioning a server in the cloud
2. Deploying an application to that server

It’s nice to have goals & a plan.

Misc

Some notes I took from Secure Any Cloud’s article that led to me making this plan:

• A lot of what a 3rd-party vendor will be providing my workplace is WAR files for services running Apache Tomcat.
• Tomcat’s been around since 1998.
• Tomcat operates only on the HTTP protocol.
• Tomcat processes (provides a runtime environment for the Java code within) Java servlets, encapsulating code & business logic to define how requests & responses should be handled by a server.
  • “Servlet” is an API from the Java Platform Enterprise Engine designed to work with web servers.
  • Monitoring a server for incoming client requests is the web server’s job, not hte servlet’s.
  • “web.xml” maps servlet classes to incoming cloient requests.
  • Servlets are responsible for providing responses back to Tomcat as JSP pages.
• Tomcat processes JSP pages.
  • Java is a server-side view rendering technology (Salesforce Visualforce Pages are based off of it, I believe).
  • Tomcat returns responses back to a client by rendering the JSP pages that servlets hand off to it.
• As a developer, our 3rd-party vendor would’ve written the servlets or JSP’s and let Tomcat handle routing.
• Tomcat provides a port 8080 connector (Coyote engine?) for serving stuff over HTTP; can’t tell if that’s related to all this.
• On Windows, you’d install a JDK and then GUI-install Tomcat, pointing it at your JRE & detailing some things like port 8080 for HTTP during install.
  • It would likely install to C:\Tomcat8, which is where you’d likely think of CATALINA_HOME and CATALINA_BASE referring to in documentation.
• Look in server.xml to be sure what the “application base directory” (e.g. CATALINA_HOME/webapps) is – likely C:\Tomcat8\webapps.
  • That’s wher you’ll drop .war files (with the server stopped).
• There’s a file in CATALINA_BASE/conf/ (on Windows, likely C:\Tomcat8\conf</code>) called tomcat-users.xml that it seems you can add data to to make web sites present an authentication wall (again, edit with the server stopped).
• As with most web servers, the typical way to see if they’re reunning well is to visit http://localhost:XXXX/whatever/ in a web browser from the same box.

All this sounds like I’ve had to manage the installion/upgrade/configuration of:

1. An operating system
2. Java
3. Apache Tomcat

(Some sort of driver for talking to a database, like JDBC, would probably be #4 in a more real-world-like setup. More to explore later.)

Infrastructure as code / containerization with Docker/Kubernetes can help. Or so I’d think.

Note: per some GitHub repos I was looking at, containers can be configured themselves to be direct-connected to or to be behind a load balancer. More to explore for another day.