DEV Community


Posted on • Originally published at on

Infrastructure as code homework #1

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.


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.

Top comments (0)