100 Days of DevOps and Cloud (AWS), Day 11: A WAR File Deploys Itself, and an ENI Is a Network Card You Can Move

Tomcat: install, set the port, drop in the WAR

Tomcat is a servlet container, the thing that actually runs Java web applications. Install it from the package manager, and you get the service plus a standard directory layout under /usr/share/tomcat:

sudo su -
yum update -y
yum install -y tomcat zip

# Enable, start, verify
systemctl enable tomcat
systemctl start tomcat
systemctl status tomcat

The HTTP port lives in server.xml:

vi /usr/share/tomcat/conf/server.xml
# Find the Connector with protocol="HTTP/1.1" and change its port
systemctl restart tomcat

Change the Connector with protocol="HTTP/1.1", and only that one. There is a second Connector for the AJP protocol further down - leave it alone, it is not your HTTP port. Restart Tomcat to apply the change.

Then deploy the application:

# Copy the WAR into Tomcat's webapps directory
cp /tmp/ROOT.war /usr/share/tomcat/webapps/

# Optionally expand it in place to inspect or edit files
cd /usr/share/tomcat/webapps
unzip ROOT.war

# Test
curl -i http://localhost:<port>

Here is the part that surprises people. Deploying is copying the WAR into the webapps directory. Tomcat watches that folder and automatically expands and deploys anything you drop in. A WAR named ROOT.war becomes the application at the root path. Unzipping it yourself is optional - handy when you want to look inside or change a file, but Tomcat would have expanded it on its own.

If the app server has no direct internet access, you move the WAR onto it from a jump server with scp, which is how the file got there to begin with. That jump-server-then-scp pattern shows up constantly once you work inside locked-down networks.

ENI: a network card you can move between instances

An Elastic Network Interface is a virtual network card. Every instance has one by default at device index 0, the primary. This task attached a second, pre-existing ENI as a secondary interface:

# List available interfaces to get the ENI ID
aws ec2 describe-network-interfaces

# Attach it as a secondary interface (index 1; index 0 is the primary)
aws ec2 attach-network-interface \
    --network-interface-id eni-0dc56a8d4640ad10a \
    --instance-id i-1234567890abcdef0 \
    --device-index 1

# Verify
aws ec2 describe-network-interfaces \
    --network-interface-ids eni-0dc56a8d4640ad10a

The interesting part is what an ENI carries. It holds its own private IP, any Elastic IP, its MAC address, and its security groups, and it keeps all of that when you detach it from one instance and attach it to another. That is what makes it a failover tool. If an instance dies, you can move its ENI - and its entire network identity - to a standby instance, and traffic follows without anything upstream needing to change.

The one hard rule is the same one that governs EBS volumes: the ENI and the instance have to be in the same availability zone. Network interfaces do not cross zones.

The pattern underneath

Both tasks were about how little some things actually take once you understand them. A Java deployment is a file copied into a watched folder. A failover network setup is one interface moved between two machines. The complexity people imagine is often just unfamiliarity, and it shrinks fast once you have done the thing a single time.

So here is the Day 11 question. Would you rather keep treating deployment and networking as intimidating black boxes, or open them once and find out how simple the moving parts really are?

Day 11 down. Eighty-nine to go.