
Stage two containers
Diese Container werden dynamisch basierend auf der Build-Benutzerkonfiguration (Job) gestartet, die über die purpleteam CLI bereitgestellt wird, insbesondere der Anzahl der von Ihnen definierten testSessions.
Die folgenden Konfigurationen sind relevant, wenn Sie beabsichtigen, das purpleteam Backend in der local-Umgebung auszuführen. In der cloud wird dies alles für Sie erledigt.
Klonen Sie dieses Repository.
Wir verwenden eine .env-Datei direkt im app-slave-Verzeichnis zum Testen.
ZAP_API_KEY
Stellen Sie sicher, dass Sie der Umgebungsvariable ZAP_API_KEY einen Wert zugewiesen haben.
Der ZAP_API_KEY kann von Ihnen frei gewählt werden, stellen Sie nur sicher, dass Sie ihn nicht nur für app-slave definieren, sondern auch in der app-scanner-Projektkonfiguration hinzufügen. Das app-scanner-Projekt benötigt den Zap-API-Key zur Authentifizierung gegenüber Zap, der im Stage Two Container läuft. Für das app-scanner-Projekt muss dies wie folgt gesetzt werden:
{ "slave": { "apiKey": <zap-api-key-here> } }
HOST_ZAP_LOG4J_PROPERTIES_PATH und ZAP_LOG4J_PROPERTIES_PATH_MOUNT_TARGET
Wenn/sobald Sie Zap-Debug-Logs benötigen, müssen Sie auch die Umgebungsvariablen für die LOG4J-Debug-Konfiguration hinzufügen.
.env-Datei
Wenn Sie sich für eine .env-Datei entscheiden, würde das Hinzufügen all dieser Umgebungsvariablen wie folgt aussehen:
ZAP_API_KEY=<zap-api-key-here>
HOST_ZAP_LOG4J_PROPERTIES_PATH=<absolute-path-to/purpleteam-s2-containers/app-slave/log4j.properties>
ZAP_LOG4J_PROPERTIES_PATH_MOUNT_TARGET=/home/zap/.ZAP/log4j.properties
Vorausgesetzt, Sie haben die oben besprochenen Umgebungsvariablen eingerichtet:
Um das Debug-Logging für die app-slave (Zap)-Container zu aktivieren, die in der local-Umgebung laufen, kommentieren Sie das volumes-Array und das Element mit dem source-Schlüssel und der Umgebungsvariable HOST_ZAP_LOG4J_PROPERTIES_PATH aus.
Details unten zur eigentlichen Anzeige der Logs.
Sie können während der Ausführung Ihrer Tests mit Zap interagieren (die Zap-Benutzeroberfläche abfragen). Wir fanden dies in der Vergangenheit nützlich, um den Zustand von Zap beim Debuggen des app-scanner zu überprüfen.
docker stats
docker container ls
8080-8091 sein, wie in der docker-compose.yml definiert.
zap:8080/*
http://zap:8080/zap-Prozess im Container beantwortet, der durch den Host-Port in Ihrer FoxyProxy-Konfiguration angegeben wirdUm das Debug-Logging für die Selenium-Container zu aktivieren, die in der local-Umgebung laufen, kommentieren Sie das environment-Array und das Element SE_OPTS=-debug für chrome und/oder firefox aus.
Details unten zur eigentlichen Anzeige der Logs.
Das Folgende beschreibt, was Sie tun müssen, um den Browser in einem der von diesem Projekt ausgeführten Selenium-Container anzuzeigen.
-debug-Images aus. Die -debug-Images sind möglicherweise auskommentiert. Kommentieren Sie daher einfach das übliche Image aus und das Image mit angehängtem -debug ein.5900-Portbereich auskommentieren. Durch die Angabe eines Bereichs als externen Port (z.B. 5900-5901) können Sie gleichzeitig per VNC auf mehrere Container zugreifen. Im Beispiel haben wir zwei gleichzeitige Sitzungen zugelassen. Wenn Sie mehr als zwei per VNC erreichen möchten, erweitern Sie einfach den externen Portbereich.Sie benötigen einen VNC-Client, um eine Verbindung zum VNC-Server im Container herzustellen. Wir hatten Erfolg mit dem Remmina Remote Desktop Client unter Linux Mint. Installieren Sie das Remmina-plugin-vnc über den Software-Manager
Starten Sie Ihren Remmina Remote Desktop Client
Erstellen Sie neue Einträge. Wenn Sie beabsichtigen, per VNC auf mehrere Selenium-Container gleichzeitig zuzugreifen, könnten Sie jeden wie folgt einrichten:
Weitere Details auf dem SeleniumHQ github
Sobald die Selenium-Container laufen (Es ist praktisch, docker stats in einem Terminal offen zu lassen, um dies zu sehen), können Sie mit docker container ls überprüfen, welcher Selenium-Container welchen externen Port verwendet. Docker weiß nicht, welche Ports Sie welchen Ihrer VNC-Client-Einträge zugewiesen haben. Der Name eines bestimmten VNC-Client-Eintrags stimmt möglicherweise nicht mit dem gleichnamigen Selenium-Container überein. Aus diesem Grund ist es ratsam, die Port-Zuordnungen mit docker container ls zu überprüfen.
Um zu korrelieren, welcher Selenium-Container für welche Test-Sitzung verwendet wird, wenn Sie mehrere Test-Sitzungen haben, müssen Sie möglicherweise das laufende app-scanner-Log überprüfen. Möglicherweise müssen Sie auch sicherstellen, dass der app-scanner auf Log-Level debug konfiguriert ist, um einige oder mehr der folgenden Log-Meldungen zu sehen:
[app.parallel] cucCli process with PID "28" has been spawned for test session with Id "lowPrivUser"
[app.parallel] cucCli process with PID "34" has been spawned for test session with Id "adminUser"
[pid-28,world] seleniumContainerName is: seleniumstandalone_chrome_1
[pid-34,world] seleniumContainerName is: seleniumstandalone_chrome_2
In diesem Beispiel haben wir zwei Test-Sitzungen in unserer Build-Benutzerkonfiguration (Job) konfiguriert. Eine hat die id lowPrivUser und die andere adminUser. In diesem Beispiel hat die Test-Sitzung lowPrivUser einen Prozess mit PID 28 und die Test-Sitzung adminUser einen Prozess mit PID 34.
In den nächsten beiden Log-Meldungen sehen wir durch Korrelation der PIDs, dass die Test-Sitzung lowPrivUser einen Container namens seleniumstandalone_chrome_1 ausführt und die Test-Sitzung adminUser einen Container namens seleniumstandalone_chrome_2.
Es gibt keine Garantie, welche Test-Sitzung welchen der seleniumstandalone_chrome_[n]-Container ausführt. Wenn Sie sicher sein müssen, verwenden Sie diese Korrelationstechnik.
Um per VNC auf die Selenium-Container zuzugreifen, sobald Remmina läuft, doppelklicken Sie einfach auf einen oder mehrere der oben erstellten VNC-Einträge. Sie sollten dann den Browser sehen können, mit dem interagiert wird... vorausgesetzt, die Cucumber-Test-Schritte im app-scanner sind tatsächlich an diesem Punkt angelangt.
Sie können natürlich Ihre Tests verlangsamen, anhalten oder mit einem Debugger Schritt für Schritt durchgehen. Details dazu finden Sie im purpleteam-Wiki auf der Workflow-Seite.
local können Sie docker stats laufen lassen, wenn Sie sehen möchten, welche Container laufen und wann sie gestartet und gestoppt werden. Dies gibt Ihnen auch ihre Namen für die folgenden Befehle.
Um die Stage Two Container-Logs anzuzeigen, tailen Sie stdout (und stderr, da Docker stdout und stderr zusammenführt) eines Containers:
docker logs --follow [container-name]
Wenn Sie diese Logs auch in eine Datei senden möchten:
docker logs --follow [container-name] |tee output.log$(date '+%Y-%m-%d_%T')
Wenn Sie diese Logs in eine Datei senden möchten, ohne sie im Terminal zu sehen:
docker logs --follow [container-name] > output.log$(date '+%Y-%m-%d_%T')
| Schlüssel | Wert |
|---|
| Name | seleniumstandalone_chrome_1 |
| Protokoll | VNC - Virtual Network Computing |
| Im Reiter Basic | |
| Server | 127.0.0.1:5900 |
| Passwort | secret |
| Farbtiefe | True color (24 bit) # Dies war die einzige, die bei uns funktioniert hat |
| Qualität | Poor (fastest) |
| Schlüssel | Wert |
|---|---|
| Name | seleniumstandalone_chrome_2 |
| Protokoll | VNC - Virtual Network Computing |
| Im Reiter Basic | |
| Server | 127.0.0.1:5901 |
| Passwort | secret |
| Farbtiefe | True color (24 bit) # Dies war die einzige, die bei uns funktioniert hat |
| Qualität | Poor (fastest) |