docs/dockerfile (#529)

Co-authored-by: Philipp Horstenkamp <philipp@horstenkamp.de>

documentations/Ergebnisse/Abschlussbericht_und_Praesentation/TrNo/S4-2.md

@@ -46,7 +46,16 @@ Auch für dieses Konstrukt galt es, eine Ausführungsumgebung zu bestimmen. Da s
 
 <img src="images/portainer.PNG" height=450/>
 
-Für das Deployment selbst wurde zunächst – neben dem automatisierten Bau der verwendeten Docker Images – eine [`docker-compose.yml`](https://github.com/fhswf/aki_prj23_transparenzregister/blob/main/docker-compose.yml) entwickelt. Diese Datei erfasst alle benötigten Komponenten, verknüpft sie über entsprechende Konfigurationen des Docker-Netzwerks und Umgebungsvariablen miteinander und steuert schließlich die Verteilung auf dem Swarm Cluster. Um eine automatisierte Bereitstellung der Services sowie Aktualisierung dieser zu ermöglichen, wurde mit Portainer ein neues Deployment namens `transparenzregister` erstellt und mit dem Code-Repository verknüpft. Auf diese Weise überprüft Portainer in regelmäßigen Intervallen, ob relevante Änderungen im Repository vorliegen – sei es eine direkte Modifikation an der `docker-compose.yml` oder die Bereitstellung eines neueren Docker Images. Bei einer solchen Erkennung startet Portainer automatisch das Deployment erneut. Zudem wurde die NGINX-Konfiguration des Jupiter Servers erweitert, und der Webserver des Transparenzregisters so unter [https://jupiter.fh-swf.de/transparenzregister](https://jupiter.fh-swf.de/transparenzregister) dem Internet zur Verfügung gestellt. Die damit verbundenen Anpassungen an der Konfiguration des Deployments, wie etwa die Einführung des `BASE_PATHs` */transparenzregister* und die Integration von Basic Auth, um den Service vor Zugriff Externer zu schützen, wurden ebenfalls über die `docker-compose.yml` ermöglicht.
+Für das Deployment selbst wurde zunächst eine [`docker-compose.yml`](https://github.com/fhswf/aki_prj23_transparenzregister/blob/main/docker-compose.yml) entwickelt. Diese Datei erfasst alle benötigten Komponenten, verknüpft sie über entsprechende Konfigurationen des Docker-Netzwerks und Umgebungsvariablen miteinander und steuert schließlich die Verteilung auf dem Swarm Cluster. Um eine automatisierte Bereitstellung der Services sowie Aktualisierung dieser zu ermöglichen, wurde mit Portainer ein neues Deployment namens `transparenzregister` erstellt und mit dem Code-Repository verknüpft. Auf diese Weise überprüft Portainer in regelmäßigen Intervallen, ob relevante Änderungen im Repository vorliegen – sei es eine direkte Modifikation an der `docker-compose.yml` oder die Bereitstellung eines neueren Docker Images. Bei einer solchen Erkennung startet Portainer automatisch das Deployment erneut. Zudem wurde die NGINX-Konfiguration des Jupiter Servers erweitert, und der Webserver des Transparenzregisters so unter [https://jupiter.fh-swf.de/transparenzregister](https://jupiter.fh-swf.de/transparenzregister) dem Internet zur Verfügung gestellt. Die damit verbundenen Anpassungen an der Konfiguration des Deployments, wie etwa die Einführung des `BASE_PATH`s `/transparenzregister/` und die Integration von Basic Auth, um den Service vor Zugriff Externer zu schützen, wurden ebenfalls über die `docker-compose.yml` ermöglicht.
+
+Gebaut werden die dafür benötigten Docker-Images automatisiert in einer mittels GitHub Actions umgesetzten CI/CD-Pipeline. Um das Erstellen weiterer Images auf Basis des Repos zu vereinfachen und Wiederholungen im Aufbau sowie in der Konfiguration zu vermeiden, werden die einzelnen Images in einem Prozess erstellt. Dieser greift das im Projektbau entstehende `*.whl` auf und transferiert dieses neben weiteren grundsätzlichen Einstellungen - unter anderem Labels - zunächst in ein Base Image.
+
+Dieses wird daraufhin von den einzelnen Applikationen aufgegriffen, um die zusätzlich benötigten Abhängigkeiten zu erweitern und letztlich mit dem entsprechenden `CMD` auf die Zielapplikation ausgerichtet.
+Als `ENTRYPOINT` wird dabei [`["/usr/bin/tini", "--"]`](https://github.com/krallin/tini) verwendet, um die Threads zu verwalten und Zombie-Prozesse zu vermeiden.
+
+So ist gewährleistet, dass zentrale Einstellungen global für alle Applikationen identisch sind und bei Änderungen nur an einer Stelle eingeführt werden müssen. Was dabei entsprechend entfällt, ist die Möglichkeit, die Images getrennt voneinander zu bauen. Da das Projekt jedoch nur in einer kompatiblen Version aller Applikationen lauffähig ist, stellt dies kein signifikantes Hindernis dar.
+
+Da die eingesetzten Datenbanken (MongoDB, PostgreSQL) bereits als Images frei zur Verfügung stehen und keine weiteren Sonderkonfigurationen benötigt werden, wird auf den Bau eigener Images verzichtet und stattdessen auf die via Docker Hub verfügbaren Images gesetzt.
 
 Auch wenn das Deployment anfangs wie gewünscht ablief, traten im Laufe der Zeit einige Probleme auf. Die hohe Frequenz an Änderungen am `main`-Branch, der vom automatisierten Deployment überwacht wird, durch die Integration von Dependabot sorgte dafür, dass schnell aufeinander folgende Deployments auf dem Server gestartet wurden und somit eine hohe Downtime der Services entstand. Ebenfalls hatte dies den Seiteneffekt, dass Unmengen an Docker Images erstellt und auf den Server transportiert wurden. Dies hatte in Kombination mit der ohnehin hohen Anzahl an – teilweise veralteten – Images zur Folge, dass der Speicherplatz auf dem Server an seine Grenzen geriet. Dieser Herausforderung hätte durch eine feinere Steuerung des Deployments begegnet werden können. Unter anderem hätten Änderungen erst auf einem `develop`- oder `release`-Branch gesammelt und erst bei Vollendung mehrerer Features oder relevanter Änderungen (z.B. Aktualisierung eingesetzter Bibliotheken) auf den `main`-Branch überführt und somit in das Deployment übergeben werden können. Eine erweiterte Versionierungsstrategie der Images (z.B. nach Semantic Versioning) hätte ebenfalls unterstützen können. Alternativ hätten Vorkehrungen getroffen werden müssen, um die auf dem Jupiter Server abgelegten Docker Images regelmäßig aufzuräumen.
 

documentations/Ergebnisse/Zwischenbericht_und_Praesentation/TrNo/Ausarbeitung.md

@@ -143,7 +143,7 @@ dennoch relevante Daten von der Seite zu scrapen. [3]
 
 Im Unternehmensregister werden veröffentlichungspflichtige Daten
 deutscher Unternehmen wie etwa die Firmengründung oder Liquidation in
-elektronischer Art zur Verfügung gestellt. [@unternehmensregister]
+elektronischer Art zur Verfügung gestellt. [4]
 
 Besonders relevant, um überhaupt ein Inventar an Unternehmen aufstellen
 zu können, sind die dort zu findenden Registerinformationen. In diesen
@@ -165,7 +165,7 @@ AG\" auch Einträge wie die Bayer Gastronomie GmbH zu Tage:
 <img src="Abbildungen/suche_bayer.PNG" height=450 />
 
 Auch eine Anpassung des Suchbegriffes durch die Verwendung regulärer
-Ausdrücke (z.B. \^̈Bayer AG\$)̈ kann die Qualität der Ergebnisse nicht
+Ausdrücke (z.B. `^̈Bayer AG$`)̈kann die Qualität der Ergebnisse nicht
 verbessern. Da es sich bei diesen ähnlichen Unternehmen jedoch auch
 tatsächlich um Tochtergesellschaften handeln könnte, die für die
 Verflechtsungsanalyse besonders interessant sind, werden nicht passende
@@ -295,6 +295,7 @@ class News:
 
     def to_dict(self) -> dict:
         return asdict(self)
+```
 
 Neben dem Inhalt des Artikels in Form des Titels, sowie dem Text werden
 wertvolle Meta-Informationen wie das Veröffentlichungsdatum sowie der
@@ -391,6 +392,7 @@ class HandelsblattRSS:
         return " ".join(
             [elem.text.replace("\n", " ") for elem in soup.find_all("p")][:]
 	)
+```
 
 Die eigentlichen Inhalte des Artikels weisen kein Standard Format mehr
 auf, auch wenn diese HTML basiert sind, und müssen daher mit einer
@@ -739,6 +741,7 @@ print(f"Number of inserted entries: {inserted_entries}")
 return inserted_entries
 
 news_dag = main()
+```
 
 ### Literaturverzeichnis