marvin-te
commented
3 years ago wird glaube ich schwierig. Ich habs lokal gemacht und konnte den Termin nicht buchen, da vaccipy Chrome nicht starten konnte. Sehr ärgerlich.
Open funnym0nk3y opened 3 years ago
marvin-te
commented
3 years ago wird glaube ich schwierig. Ich habs lokal gemacht und konnte den Termin nicht buchen, da vaccipy Chrome nicht starten konnte. Sehr ärgerlich.
funnym0nk3y
commented
3 years ago Darf ich fragen, wie genau du das gemacht hast? @marvin-te Ich hab das Programm leider noch nicht genau verstanden und weiß deshalb nicht, ob der Prozess komplett headless möglich ist, bzw warum manche Sachen headless gemacht werden und manche nicht. Prinzipiell könnte man ja chromium in den container mit rein packen...
marvin-te
commented
3 years ago In meiner Frage gestern #361 wurde mir bestätigt, dass für die Buchung des Termins eine GUI notwendig ist. Mir ist kein Weg bekannt, eine GUI Application in einem Docker Container laufen zu lassen.
marvin-te
commented
3 years ago Daher ist es, denke ich, nicht sinnvoll möglich, vaccipy in einem Docker Container laufen zu lassen. Mein Ansatz war bisher halt eine Dockerfile mit python als base, in der ich das repo gecloned habe und eine json mit entsprechenden Kontaktdaten kopiert habe. Lief super, bis zur Buchung. Die funktionierte nicht.
funnym0nk3y
commented
3 years ago Die habe ich leider nicht gesehen, danke für den Hinweis. Ist es denn prinzipiell möglich, valide Cookies headless zu generieren oder ist das eine Sache der Implementierung?
Also wenn ich das richtig verstanden habe braucht man für valide Cookies die Mausbewegungen und Klicks.
sinun98
commented
3 years ago Die habe ich leider nicht gesehen, danke für den Hinweis. Ist es denn prinzipiell möglich, valide Cookies headless zu generieren oder ist das eine Sache der Implementierung?
Also wenn ich das richtig verstanden habe braucht man für valide Cookies die Mausbewegungen und Klicks.
Wenn du es headless hinbekommst wäre klasse. Wir haben es leider nicht geschafft. Die Cookies werden immer geblockt.
s-hamann
commented
3 years ago Mir ist kein Weg bekannt, eine GUI Application in einem Docker Container laufen zu lassen.
Es ist durchaus möglich, GUI-Anwendungen in einem Container laufen zu lassen, allerdings nicht ganz intutiv. Mit Chrome/Chromium habe ich das nicht probiert, aber generell sieht der Aufruf (ganz grob) so aus:
args=()
# 1. export xauth cookie to the container
xauth_file='/tmp/container.xauth'
touch -- "${xauth_file}"
xauth nextract - "${DISPLAY}" | sed -e '/^..../ffff/' | xauth -f "${xauth_file}"
args+=( "--volume=${xauth_file}:/home/.../.Xauthority:ro" )
# 2. export X11 display information
args+=( "--env=DISPLAY=unix${DISPLAY}" "--volume=/tmp/.x11-unix:/tmp/.x11-unix:ro" )
# 3. export Wayland display information
args+=( "--env=WAYLAND_DISPLAY" "--env=XDG_RUNTIME_DIR" "--volume=${XDG_RUNTIME_DIR}/${WAYLAND_DISPLAY}:${XDG_RUNTIME_DIR}/${WAYLAND_DISPLAY}" )
# run it
podman run --rm -it "${args[@]}" vaccipyFalls auf dem Host X11 läuft kann man Schritt 3 weg lassen; falls Wayland läuft, dann ist Schritt 1 nicht nötig.
Getestet habe ich das nur mit Podman, sollte aber mit Docker ganz genauso funktionieren.
Möglicherweise müssen für Chrome/Chromium noch Einträge aus /dev/ exportiert werden.
apeltzer
commented
3 years ago Podman macht vieles einfacher als Docker, ähnlich wie Singularity - was bei Docker immer ein gebastel war um X11 rauszubekommen ging z.B. bei mir mit Singularity "einfach so". Gehen tuts, aber "schön" ist es nicht.
dnlfrst
commented
3 years ago Ich habe gerade gesehen, dass auf #418 keine positive Resonanz folgte, gerne kann meine PR (#424) daher kommentarlos geschlossen werden.
Das hier beschriebene Problem ist bereits vielfach hervorragend gelöst worden, u.a. für UI Tests in Docker. Eine solche Lösung bietet auch Selenium, deren Bibliothek bereits in vaccipy verwendet wird, selbst an. Da auch ich an einem Deployment von vaccipy in Docker interessiert bin, habe ich die nachfolgende Lösung in meinem Fork implementiert.
Selenium bietet die gängigen Browser wie Google Chrome als Docker Image auf Docker Hub an. Passend dazu, kann in selenium per Remote eine Verbindung zu der Instanz dieses Browsers aufgebaut werden.
Diese Funktionen sind out-of-the-box verfügbar und können in Docker Compose wie folgt kombiniert werden:
version: "3.9"
services:
google-chrome:
environment:
# Necessary to allow connections other than from the local address.
- JAVA_OPTS=-Dwebdriver.chrome.whitelistedIps=
image: selenium/standalone-chrome:91.0
ports:
- "4444:4444"
vaccipy:
build: .
# Arguments passed to vaccipy.
command: ${VACCIPY_ARGUMENTS}
environment:
- VACCIPY_CHROME_REMOTE_ADDRESS=http://google-chrome:4444/wd/hub
image: vaccipy
volumes:
- type: bind
read_only: true
source: ${VACCIPY_CONTACT_ADDRESS_PATH}
target: /vaccipy/kontaktdaten.jsonDer Service vaccipy basiert wiederum auf folgendem Dockerfile:
FROM python:3.9.5-buster
WORKDIR vaccipy
RUN apt-get update && apt-get install -y jq
ADD . .
RUN python -m pip install -r requirements.txt
RUN chmod +x ./wait-for-google-chrome.sh
ENTRYPOINT ./wait-for-google-chrome.sh python3 main.py search -f kontaktdaten.json -rDa das Deployment nicht auf Interaktion ausgelegt ist, habe ich zwei neue Umgebungsvariablen eingeführt: VACCIPY_ARGUMENTS und VACCIPY_CONTACT_ADDRESS_PATH. Erstere erlaubt zusätzlich Argumente für vaccipy zu definieren und zweitere ermöglicht, den Pfad einer bestehenden kontaktdaten.json festzulegen. Beide Werte sind standardmäßig durch .env festgelegt.
Mit dieser Implementation konnte ich erfolgreich einen Termin such und buchen:
Anmerkung: die obige Buchung erfolgte zu Testwecken und wurde umgehend storniert. Die angezeigten Uhrzeiten enstammen einer anderen Zeitzone und stimmen nicht mit UTC+0200 überein.
Obgleich die obige Implementation technisch einwandfrei funktioniert, ermöglicht sie keine Automation der Terminbuchung. Es ist weiterhin notwendig, den Termin per Mail manuell zu bestätigen. Es entzieht sich dem Zweck von vaccipy diesen Schritt zu automatisieren. Insbesondere wird der Docker Container stoppen, sobald vaccipy erfolgreich einen Termin gebucht hat.
Wie der Docker Compose Datei zu entnehmen, habe ich alle Verbindungen zur Instanz von Google Chrome zugelassen. Es ist daher denkbar, dass Dritte auf die Instanz von Google Chrome über den Docker Container zugreifen können. Standardmäßig lässt selenium/standalone-chrome bzw. Chromium nur Verbindungen von lokalen Adressen zu. Sollte Bedarf daran bestehen, den Vorschlag zu mergen, sollten wir versuchen, diese Whitelist einzuschränken, evtl. über den Namen des zugreifenden Containers, d.h. vaccipy.
Es ist mir bisher nicht gelungen, die neu eingeführten Umgebungsvariablen über die Umgebung (hier tmux) zu definieren. Ich konnte die Werte lediglich über .env setzen.
venv der .gitignore hinzuzufügen, habe ich ein vollständiges, automatisch generiertes Template von gitignore.io eingesetzt..env zusammenzuführen.Ich möchte mich an dieser Stelle für das Engagement aller Beteiligten an dieser Software bedanken, sie löst ein reales Problem auf eine praktische Art & Weise. 👏🏼
funnym0nk3y
commented
3 years ago @dnlfrst wirst du ein out-off-tree Dockerfile maintainen?
Hey,
es wäre cool, wenn es vaccipy auch als docker container geben würde.