Release 1.3.0 des Anti-DoS-Valves – mit Docker

Heute habe ich ein neues Release des Apache Tomcat Valves zur Begrenzung von massenhaften Zugriffen auf Tomcat Server auf Github veröffentlicht. Funktional hat sich dabei nicht viel getan, abgesehen von der Anpassung des Codes an Tomcat 10 und den dort nun anders benannten Servlet API Paketen. Aber dazu schreibe ich noch etwas in einem anderen Post. Die wesentliche Verbesserung liegt hier:

Docker Logo

Im /docker-Unterzeichnis des Projekts findet sich nun eine Docker-Konfiguration, mit der sich sehr einfach ein Tomcat 10 Server mit einkonfiguriertem Valve und einer Testmöglichkeit als Containerinstanz starten lässt. Entweder um das Ganze einmal schnell auszuprobieren, oder um bei eigenen Weiterentwicklungen ohne Basteleien und manuelles Hin- und Herschieben von JARs und Konfigurationen schnell die letzte Version des Valves direkt ausführen zu können.

Ich bin noch nicht so routiniert mit Docker, daher gehe ich hier einmal die Inhalte des /docker-Verzeichnisses durch und falls eine Leserin oder ein Leser dazu Verbesserungsvorschläge hat freue ich mich:

Dockerfile

Es ist nahezu leer:

FROM tomcat:10-jdk16-corretto

Nur das Tomcat 10 Image von Dockerhub wird referenziert. Ich hätte hier schon die angepasste server.xml oder das Valve Jar in das Image bringen können, aber gerade für Entwicklungszwecke erschien es mir zu umständlich jedes Mal ein neues Image zu bauen. Tatsächlich hätte es das Dockerfile im Moment gar nicht gebraucht, es hilft in der jetzigen Form nur die unten beschriebenen Kommandozeilen von späteren Änderungen des verwendeten Tomcat Images zu isolieren.

Falls man aber ein Tomcat Image für produktive Zwecke bauen möchte, in dem das Valve schon enthalten ist, wäre es sicher eine gute Idee die Valve Anpassungen bereits hier zu integrieren und mindestens das Jar schon in das Image aufzunehmen.

README.md

Hier sind die Kommandos enthalten, die es braucht um den Tomcat samt Valve zu starten. Interessant ist dabei eigentlich nur dieses Kommando:

docker run \
   --mount type=bind,source="%cd%"/../target/anti-dos-valve-1.3.0.jar,target=/usr/local/tomcat/lib/anti-dos-valve.jar,readonly  \
   --mount type=bind,source="%cd%"/server.xml,target=/usr/local/tomcat/conf/server.xml,readonly  \
   --mount type=bind,source="%cd%"/advdemo/,target=/usr/local/tomcat/webapps/advdemo/,readonly \
   --name AntiDoSValveDemo \
   -p 8013:8080 \
   -it antidosvalve_demo

In den drei mount-Anweisungen werden drei Dateien/Order aus dem Host-System in den Container abgebildet und überdecken dabei die schon vorhandenen Dateien im Container:

  • JAR: Das Jar, welches sich eins höher im /target-Verzeichnis befindet, wird in das /lib-Verzeichnis des Tomcats im Container gebracht und steht dem Server damit zur Verfügung. Das Jar muss natürlich vorher schon gebaut worden sein
  • server.xml: Hier wird eine angepasste Version der server.xml, die sich im Tomcat Image befindet, in den Container gesetzt. Dadurch werden die Valve Konfigurationen wirksam
  • /advdemo: Dieser Ordner enthält eine JSP – siehe unten – und wird als Webapp eingebracht, die der Tomcat klaglos ausführt

Alle mounts werden als readonly deklariert, damit in keinem Fall der Server im Container etwas zurückschreiben kann. mounts benötigen absolute Pfad, damit die Anweisung trotzdem immer funktioniert wird der aktuelle Pfad eingesetzt. Hier für Windows, für Linux sind entsprechende Anpassungen notwendig.

Es wird ein Portmapping gemacht, dabei wird nicht der sonst übliche Port 8080 verwendet, um nicht in Konflikt mit anderen auf dem Host laufenden Servern zu kommen.

Schließlich wird ein Name vergeben, unter dem sich der Container ansprechen lässt. Das verhindert, dass man einen beendeten Container einfach erneut starten kann und ihn erst entfernen muss. Ich bin mir noch nicht sicher, ob ich das wirklich praktisch finde.

server.xml

Die server.xml Datei, mit der Tomcat 10 Distribution mitgeliefert wird, um 2 Valve Konfigurationen ergänzt. Wenn man alternative Konfigurationen ausprobieren will kann kann man einfach die Datei bearbeiten und den Container neu starten.

/advdemo-Ordner

Hier ist nur eine JSP enthalten, die für die Demonstration des Marking Modes des Valves benötigt wird. Sie wird als eigene Webapp in den Tomcat gebracht und ist dann dort ausführbar.

Schnelle Iterationen

Durch die Containerlösung, die sich in Sekunden hochfährt, ist es einfach neue Versionen des Valves, der server.xml oder auch der JSP auszutesten, deutlich schneller als mir das bisher mit einer separaten Tomcat Instanz möglich war. Auch der rasche Wechsel zwischen unterschiedlichen server.xml Dateien ist einfach, man muss sich nur eine alternative Kommandozeile zurechtlegen. Und dafür ist keine ‚Magic‘ mit in Eclipse und Co. integrierten Tomcats notwendig, alles sind einfache Kommandozeilen, die sich schnell ausführen und und anpassen lassen.

Mir gefällt das gut 😀🐳