Neues Git-Repository auf Github

Ich kann es mir nicht merken – will es auch gar nicht.

Also, hier die Kurzfassung:

Um Ihr Projekt auf GitHub hochzuladen, folgen Sie diesen Schritten:

Repository auf GitHub erstellen

  1. Melden Sie sich bei GitHub an.
  2. Klicken Sie oben rechts auf das “+”-Symbol und wählen Sie “New repository”.
  3. Geben Sie einen Namen für Ihr Repository ein.
  4. Wählen Sie “Public” oder “Private” für die Sichtbarkeit.
  5. Lassen Sie die Option “Initialize this repository with a README” deaktiviert.
  6. Klicken Sie auf “Create repository”.

Verwendung von SSH

Die Verwendung von SSH ist generell sicherer und einfacher zu verwalten. Wenn Sie häufig mit GitHub arbeiten, ist es ratsam, auf SSH umzusteigen.

  1. Generieren Sie ein SSH-Schlüsselpaar:
ssh-keygen -t ed25519 -C "ihre-email@example.com"
  1. Fügen Sie den öffentlichen Schlüssel zu Ihrem GitHub-Konto hinzu:
  1. Ändern Sie die Remote-URL Ihres Repositories:
git remote set-url origin git@github.com:IhrBenutzername/IhrRepositoryName.git

Fügen Sie Ihren SSH-Key zum SSH-Agenten hinzu:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Sie werden einmalig nach der Passphrase (ihres SSH-Keys) gefragt. Danach speichert der SSH-Agent den entschlüsselten Key für die aktuelle Sitzung.

Dateien hochladen

  1. Fügen Sie alle Dateien zum Staging-Bereich hinzu:
git add .
  1. Committen Sie die Änderungen:
git commit -m "First Commit"
  1. Pushen Sie die Dateien zu GitHub:
git push -u origin main

Überprüfung

  1. Besuchen Sie Ihre GitHub-Repository-Seite.
  2. Sie sollten nun alle Ihre Dateien, einschließlich der README.md, sehen können.

Zusammenarbeit mit einem KI-Assistenten: Problemanalyse, Entwicklung von Lösungen, Tests und Feedback

In diesem Artikel beschreibe ich, wie ich gemeinsam mit einem KI-Assistenten (ChatGPT) regelmäßig Probleme analysiere, Lösungen entwickle, diese teste und anschließend kommentiere. Die Zusammenarbeit mit der KI ermöglicht es mir, systematisch an Herausforderungen heranzugehen und dabei schneller zu einer Lösung zu kommen, da der Assistent mir in jeder Phase des Prozesses unterstützend zur Seite steht.

1. Problemanalyse

Der erste Schritt unserer Zusammenarbeit besteht immer darin, das Problem klar zu definieren. Ich beschreibe das technische oder organisatorische Problem möglichst präzise, sei es eine Konfiguration, ein technisches Hindernis oder eine spezifische Frage zu einer Aufgabe. Der Assistent analysiert meine Beschreibung und stellt gegebenenfalls Rückfragen, um sicherzustellen, dass alle Aspekte des Problems berücksichtigt werden.

Beispiel: Ich wollte eine angepasste ISO-Datei für eine Debian-Netinstall erstellen und musste das grafische Installationsmenü entsprechend anpassen. Der Assistent half mir, das genaue Ziel (automatisierte Installation mit einer Preseed-Datei) klar zu formulieren.

2. Lösungsentwicklung

Nachdem das Problem vollständig erfasst ist, schlägt der Assistent Lösungen vor. Dabei bietet er oft mehrere Ansätze an und erklärt die Vor- und Nachteile der einzelnen Optionen. Der KI-Assistent kann auch spezifische Befehle oder Konfigurationen vorschlagen, die direkt auf das Problem zugeschnitten sind.

Beispiel: Für die Anpassung der Debian-ISO schlug der Assistent vor, die gtk.cfg-Datei zu modifizieren und zeigte mir, wie die Preseed-Datei in das grafische Menü integriert werden kann.

3. Testen der Vorschläge

Nach der Lösungsentwicklung teste ich die vorgeschlagenen Ansätze in meiner eigenen Umgebung. Manchmal folgen dabei iterative Schritte, bei denen ich die vorgeschlagenen Lösungen an meine spezifischen Anforderungen anpasse. Der Assistent gibt mir in diesen Phasen wertvolle Hinweise, worauf ich achten muss, und unterstützt mich dabei, Fehlerquellen zu identifizieren.

Beispiel: Nachdem ich die gtk.cfg angepasst hatte, testete ich die neue ISO-Datei in einer virtuellen Maschine. Dabei kam es manchmal zu unvorhergesehenen Schwierigkeiten, die ich dem Assistenten meldete.

4. Feedback und Kommentare

Ein wichtiger Bestandteil der Zusammenarbeit ist das gegenseitige Feedback. Nachdem ich die Lösung getestet habe, gebe ich dem Assistenten Rückmeldung darüber, ob der Ansatz funktioniert hat oder ob es noch offene Probleme gibt. Der Assistent passt daraufhin seine Vorschläge an oder gibt weitere Hinweise zur Fehlerbehebung.

Beispiel: Wenn eine Konfiguration nicht wie erwartet funktionierte, half mir der Assistent durch detaillierte Nachfragen oder alternative Lösungsvorschläge, das Problem weiter einzugrenzen und zu lösen.

5. Wiederholung des Prozesses

Manchmal erfordert ein Problem mehrere Iterationen, bis eine zufriedenstellende Lösung gefunden wird. In solchen Fällen durchlaufen wir den Prozess erneut: Analyse, Lösungsentwicklung, Test und Feedback. Der Assistent bleibt dabei flexibel und lernt aus dem Verlauf, welche Lösungen für mich am besten funktionieren.

Beispiel: Bei der Arbeit mit der Debian-ISO mussten wir mehrere Schritte durchlaufen, bis das grafische Installationsmenü korrekt funktionierte. Jede Runde führte zu einer besseren und effizienteren Lösung.

Fazit

Die Zusammenarbeit mit einem KI-Assistenten wie ChatGPT bietet mir die Möglichkeit, komplexe technische Probleme strukturiert anzugehen. Die Mischung aus Problemanalyse, Lösungsentwicklung, Testen und Feedback schafft eine produktive Arbeitsweise, bei der ich schnell Fortschritte mache und gleichzeitig von den Vorschlägen und Erklärungen der KI profitiere. Der Assistent unterstützt mich nicht nur mit technischen Details, sondern hilft auch, meinen eigenen Denkprozess zu strukturieren und zu verbessern.

Debian Custom ISO für unbeaufsichtigte Wunschinstallation(en)

Auch keine Lust mehr, mit einem zu langsamen Xampp zu entwickeln oder mit Docker Compose das Rad jedes Mal neu zu erfinden, wenn man doch eine richtige Entwicklungsumgebung benötigt und nicht einen persistenten Container, der nach dem Neustart alles wieder vergessen hat?

Ich nutze am liebsten immer noch meine virtuellen Maschinen auf Oracle VM Oracle VirtualBox.

Eigene Debian-12-Install-CD für eine komplett unbeaufsichtigte Installation unter Windows mit Oracle VM erstellen

Die Erstellung einer benutzerdefinierten Debian-12-Installations-CD für eine vollständig unbeaufsichtigte Installation kann besonders nützlich sein, wenn regelmäßig neue Systeme aufgesetzt werden müssen. Für eine solche Aufgabe ist es möglich, eine Preseed-Datei zu verwenden, die alle notwendigen Installationsoptionen und Softwarepakete automatisch konfiguriert.

Da Windows und Oracle VM genutzt werden, liegt der Fokus auf Tools und Prozessen, die auf Windows basieren, um die ISO-Datei zu bearbeiten und die Installation in einer Oracle VM zu testen.

Vorteile einer unbeaufsichtigten Installation

  • Zeitersparnis: Mehrere Systeme können schnell und ohne manuelle Eingaben installiert werden.
  • Automatisierung: Standardprogramme und Konfigurationen werden bereits während der Installation eingerichtet.
  • Konsistenz: Alle Installationen folgen denselben Konfigurationen, was das Management erleichtert.

Voraussetzungen

  • Debian 12 ISO: Die originale Debian-12-ISO wird als Grundlage verwendet.
  • Preseed-Datei: Diese Datei enthält die Antworten für alle Installationsschritte.
  • Windows-ISO-Editor: Programme wie UltraISO oder IsoEdit werden verwendet, um die ISO zu modifizieren.

Schritt 1: Herunterladen der Debian-12-Installations-ISO

Die Debian-12-Netinst-ISO bietet eine minimalistische Installation, bei der die meisten Pakete aus dem Internet heruntergeladen werden.

Schritt 2: Erstellen der Preseed-Datei

Die Preseed-Datei steuert die unbeaufsichtigte Installation. Hier ein Beispiel für eine einfache Preseed-Konfiguration:

d-i debian-installer/locale string de_DE
d-i console-setup/ask_detect boolean false
d-i keyboard-configuration/xkb-keymap select de

# Partitionierung
d-i partman-auto/disk string /dev/sda
d-i partman-auto/method string regular
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true

# Benutzer
d-i passwd/root-password password rootpasswort
d-i passwd/root-password-again password rootpasswort
d-i passwd/user-fullname string Benutzername
d-i passwd/username string benutzer
d-i passwd/user-password password benutzerpasswort
d-i passwd/user-password-again password benutzerpasswort

# Netzwerk
d-i netcfg/get_hostname string server
d-i netcfg/get_domain string localdomain

# Software
d-i pkgsel/include string git curl htop sudo

# GRUB
d-i grub-installer/only_debian boolean true

# Spätere Befehle ausführen und Skripte in das Root-Home kopieren
d-i preseed/late_command string \
  cp /cdrom/preseed/add_sudo_user.sh /target/root/; \
  cp /cdrom/preseed/change_hostname.sh /target/root/; \
  cp /cdrom/preseed/setup_database.sh /target/root/; \
  in-target chmod +x /root/add_sudo_user.sh; \
  in-target chmod +x /root/change_hostname.sh; \
  in-target chmod +x /root/setup_database.sh;

Hinzufügen von Skripten zum Root-Home-Verzeichnis

Es ist möglich, Batch- oder Shell-Skripte in das Verzeichnis /root/ des neu installierten Systems zu kopieren. Diese Skripte können nach Abschluss der Installation ausgeführt werden, um zusätzliche Aufgaben zu automatisieren, wie etwa das:

  • Anlegen eines neuen sudo-Benutzers,
  • Umbenennen des Hostnamens, oder
  • Einrichten einer Datenbank.

Beispiel für das Skript add_sudo_user.sh:

#!/bin/bash

# Nach dem Benutzernamen fragen (Standard: "newuser")
read -p "Geben Sie den Benutzernamen ein [newuser]: " user_name
user_name=${user_name:-newuser}

# Nach dem Passwort fragen (keine Anzeige des Passworts im Terminal)
read -s -p "Geben Sie das Passwort für den Benutzer '$user_name' ein: " user_pass
echo

# Neuen Benutzer erstellen
echo "Erstelle Benutzer '$user_name'..."
useradd -m -s /bin/bash "$user_name"

# Passwort für den Benutzer setzen
echo "$user_name:$user_pass" | chpasswd

# Benutzer zur sudo-Gruppe hinzufügen
usermod -aG sudo "$user_name"

echo "Benutzer '$user_name' wurde erstellt und hat nun sudo-Rechte."

Das Skript wird durch den late_command in der Preseed-Datei automatisch ins Root-Verzeichnis kopiert und kann dann nach der Installation ausgeführt werden.

Schritt 3: Bearbeiten der ISO-Datei mit Windows-Tools

Um die Preseed-Datei in die ISO zu integrieren, wird ein ISO-Editor auf Windows benötigt.

  • Öffnen der Debian-12-ISO mit bspw. UltraISO.
  • Die Preseed-Datei in das anzulegende Verzeichnis /preseed/ der ISO kopieren.
  • Die Boot-Konfiguration (z.B. isolinux/txt.cfg oder grub/grub.cfg) bearbeiten und den Parameter hinzufügen: append initrd=/install.amd/initrd.gz preseed/file=/cdrom/preseed.cfg auto=true priority=critical quiet
  • Die ISO-Datei speichern.

Schritt 4: Anpassen der Boot-Parameter

Um sicherzustellen, dass die Preseed-Datei während der Installation verwendet wird, müssen die Boot-Parameter der ISO angepasst werden. Dies erfolgt durch Bearbeiten der Datei isolinux/txt.cfg oder grub/grub.cfg (je nach Bootloader):

default install
label install
  menu label ^Install
  kernel /install.amd/vmlinuz
  append initrd=/install.amd/initrd.gz preseed/file=/cdrom/preseed.cfg auto=true priority=critical quiet

Hier heißt der Punkt „Automatic – DESTRUCTIVE“, da bei mir die komplette Festplatte genutzt und ohne Rückfrage überschrieben wird. Aber das kann jeder für sich selbst festlegen.

Schritt 5: ISO-Datei testen

Für eine virtuelle Testumgebung wird Oracle VM VirtualBox verwendet:

  • Download-Link: Oracle VM VirtualBox
  • Erstelle eine neue virtuelle Maschine in VirtualBox und verwende die angepasste ISO-Datei als Installationsquelle.

Schritte zur Erstellung der VM:

  1. Neue virtuelle Maschine erstellen und Debian als Gast-Betriebssystem auswählen.
  2. ISO-Datei einbinden: Die angepasste Debian-ISO als optisches Laufwerk für die VM verwenden.
  3. Automatisierte Installation testen: Die virtuelle Maschine starten und prüfen, ob die Installation ohne Eingriffe durchgeführt wird.

Schritt 6: ISO-Datei auf physischer Hardware testen

Um sicherzustellen, dass die erstellte ISO-Datei auch auf physischer Hardware funktioniert, kann die ISO-Datei auf einen USB-Stick übertragen (mit Rufus) und auf einem echten PC oder Server getestet werden. Die Installation sollte ebenfalls unbeaufsichtigt ablaufen und die in der Preseed-Datei definierten Einstellungen übernehmen.

Fazit

Mit Windows und Oracle VM VirtualBox kann eine vollständig unbeaufsichtigte Debian-12-Installation einfach eingerichtet und getestet werden. Durch die Anpassung der ISO und die Integration einer Preseed-Datei lässt sich der gesamte Installationsprozess automatisieren. Mithilfe von Tools wie UltraISO oder Rufus ist es möglich, die ISO auf Windows zu bearbeiten und für den Einsatz in virtuellen oder physischen Umgebungen vorzubereiten.

So sieht mein Home-Verzeichnis von root aus. Ich habe u.a. auch noch eine Batchdatei install_cms.sh mit der ich gleich ein komplettes CMS wie WordPress oder ein Framework wie Symfony installieren kann.

Mehr Informationen:

https://github.com/istepaniuk/debian11-preseed?tab=readme-ov-file

https://wiki.debian.org/DebianInstaller/Preseed

https://wiki.debian.org/DebianInstaller/Preseed/EditIso

https://wiki.debian.org/RepackBootableISO

Besser als XAMPP: Docker-basierte Entwicklungsumgebung

Traditionelle lokale Entwicklungsumgebungen wie XAMPP sind seit Jahren beliebt, da sie einfach einzurichten und zu verwenden sind. Allerdings stoßen sie schnell an ihre Grenzen, wenn es um Platzersparnis, Geschwindigkeit und Flexibilität geht. Hier kommt eine Docker-basierte Lösung ins Spiel, die XAMPP in vielerlei Hinsicht überlegen ist.

Platzersparnis und Geschwindigkeit

Mit Docker können Entwicklungsumgebungen schlank gehalten werden. Der gesamte Stack – bestehend aus Apache, MariaDB und Mailhog – wird in einem einzigen Container betrieben. Das spart nicht nur Speicherplatz, sondern sorgt auch für eine bemerkenswerte Steigerung der Geschwindigkeit. Der Start der gesamten Umgebung dauert nur wenige Sekunden, im Gegensatz zu den längeren Ladezeiten bei XAMPP.

Einfachheit des Buildings

Das Building eines Docker-Containers ist einfach und schnell erledigt. Mit einem einzigen Befehl wird der komplette Stack erstellt und konfiguriert. Im Gegensatz zu XAMPP müssen keine zusätzlichen Softwarepakete heruntergeladen und installiert werden. Eine Datei (dockerfile) regelt alle notwendigen Installationen und Konfigurationen:

FROM debian:latest

RUN apt-get update && apt-get install -y apache2 mariadb-server mailhog supervisor
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
COPY init.sh /usr/local/bin/init.sh
RUN chmod +x /usr/local/bin/init.sh

CMD ["/usr/bin/supervisord"]

In diesem Dockerfile werden die Anweisungen zum Erstellen eines Docker-Containers beschrieben, der auf einem Debian-basierten Betriebssystem läuft und verschiedene Dienste wie Apache, MariaDB und Mailhog enthält. Hier ist eine Erklärung, was in jedem Schritt passiert:

1. FROM debian:latest

  • Beschreibung: Legt das Basis-Image fest, auf dem der Container aufbaut. In diesem Fall wird die neueste Version des Debian-Betriebssystems verwendet.

2. RUN apt-get update && apt-get install -y apache2 mariadb-server mailhog supervisor

  • Beschreibung: Führt zwei Befehle in einer Zeile aus:
  1. apt-get update: Aktualisiert die Liste der verfügbaren Pakete und deren Versionen.
  2. apt-get install -y apache2 mariadb-server mailhog supervisor: Installiert die Pakete apache2 (Webserver), mariadb-server (Datenbankserver), mailhog (E-Mail-Testing-Tool) und supervisor (Prozesssteuerungstool). Der Schalter -y bestätigt automatisch alle Aufforderungen zur Installation der Pakete.

3. COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf

  • Beschreibung: Kopiert die Datei supervisord.conf aus dem lokalen Verzeichnis in das Verzeichnis /etc/supervisor/conf.d/ im Container. Diese Datei enthält Konfigurationen für Supervisor, um die Dienste zu steuern, die im Container ausgeführt werden sollen.

4. COPY init.sh /usr/local/bin/init.sh

  • Beschreibung: Kopiert das Skript init.sh in das Verzeichnis /usr/local/bin/ im Container. Dieses Skript wird später zur Initialisierung der Dienste verwendet.

5. RUN chmod +x /usr/local/bin/init.sh

  • Beschreibung: Ändert die Berechtigungen der Datei init.sh, um sie ausführbar zu machen. Dies ist notwendig, damit das Skript später im Container ausgeführt werden kann.

6. CMD ["/usr/bin/supervisord"]

  • Beschreibung: Legt den Standardbefehl fest, der ausgeführt wird, wenn der Container gestartet wird. In diesem Fall wird supervisord ausgeführt, um die in supervisord.conf definierten Dienste (wie Apache, MariaDB und Mailhog) zu starten und zu überwachen.

Zusammengefasst erstellt dieses Dockerfile einen Container, der auf Debian basiert, die benötigten Pakete installiert, Konfigurationsdateien kopiert und Supervisor verwendet, um die verschiedenen Dienste im Container zu verwalten.

Schnelleres Deployment

Mit Docker wird das Deployment zur Leichtigkeit. Es ist möglich, die gesamte Umgebung in kürzester Zeit auf einem anderen System zu replizieren. Es genügt, den Container auf einem anderen Rechner zu starten, und die Entwicklungsumgebung ist sofort einsatzbereit – ohne zusätzliche Installationen und Konfigurationen. Die Dateien build-container.bat und start-container.bat sorgen für einen nahtlosen Startprozess.

Den Build starten

Die build-container.bat Datei ist ein Batch-Skript für Windows, das verwendet wird, um das Docker-Image zu erstellen. Hier ist eine Erklärung, was in dieser Datei passiert:

Inhalt von build-container.bat

docker build -t my-fullstack-app .
Erklärung
  • docker build -t my-fullstack-app .
  • docker build: Dieser Befehl erstellt ein Docker-Image aus einem Dockerfile.
  • -t my-fullstack-app: Mit dem -t (Tag) Flag wird ein Name und optional ein Tag für das erstellte Image angegeben. In diesem Fall wird das Image als my-fullstack-app benannt.
  • .: Der Punkt gibt das Verzeichnis an, in dem das Dockerfile liegt. In diesem Fall ist es das aktuelle Verzeichnis.

Das Skript baut ein Docker-Image namens my-fullstack-app aus dem Dockerfile im aktuellen Verzeichnis. Sobald dieser Befehl ausgeführt wird, durchläuft Docker die Schritte im Dockerfile, um das Image zu erstellen. Dieses Image kann dann verwendet werden, um Container zu starten.

Gleichzeitige Entwicklung und Testing

Ein weiterer Vorteil der Docker-basierten Umgebung ist die Möglichkeit, lokale Änderungen in Echtzeit zu verfolgen. Die Daten werden direkt von einem lokalen Verzeichnis in den Container gemountet:

docker run -d -p 8080:80 my-fullstack-app

Damit werden Änderungen sofort übernommen, ohne dass der Container neu gebaut werden muss. Das bedeutet effizienteres Arbeiten und schnelleres Testen von neuen Funktionen.

Vorteile der Verwendung einer Batch-Datei für docker run

Die Verwendung einer Batch-Datei für den docker run Befehl bietet mehrere Vorteile, insbesondere für Entwickler, die sich einen effizienteren und konsistenteren Workflow wünschen:

  1. Wiederholbarkeit: Mit einer Batch-Datei können Sie den Container jederzeit mit den exakt gleichen Parametern starten. Das verhindert Fehler, die bei der manuellen Eingabe des Befehls passieren können.
  2. Zeitersparnis: Anstatt sich jedes Mal an alle notwendigen Parameter und Optionen zu erinnern, können Sie den Container mit einem einzigen Doppelklick oder einem kurzen Befehl im Terminal starten. Das spart wertvolle Zeit.
  3. Konsistenz: Durch die Automatisierung des Startvorgangs stellen Sie sicher, dass der Container immer in der gleichen Umgebung läuft, was für die Entwicklung und Fehlersuche sehr wichtig ist.
  4. Leichteres Deployment: Wenn Sie den Container auf einem anderen System starten möchten, können Sie die Batch-Datei einfach weitergeben. Der Empfänger muss lediglich die Datei ausführen, ohne sich um die genauen Details des docker run Befehls kümmern zu müssen.

Aufbau der start-container.bat

Die Batch-Datei start-container.bat enthält den folgenden Befehl:

@echo off
docker run -d -p 8080:80 -p 3306:3306 -p 8025:8025 -p 1025:1025 -v %cd%/src:/var/www/html my-fullstack-app
Was passiert hier?
  • Automatischer Start des Containers: Der docker run Befehl startet den Container my-fullstack-app. Durch das -d Flag wird der Container im Hintergrund ausgeführt.
  • Port-Mapping: Mit den -p Optionen werden die Ports des Hostsystems mit denen des Containers verknüpft. Dadurch werden der Webserver, die Datenbank und Mailhog korrekt verfügbar gemacht.
  • Direkter Zugriff auf den Quellcode: Das -v Flag sorgt dafür, dass das lokale Verzeichnis ./src in den Container gemountet wird. Dadurch werden Änderungen an den Dateien in ./src sofort im Container sichtbar, was die Entwicklungszeit verkürzt.
  • Einfache Ausführung: Durch die Batch-Datei muss man sich nicht die genauen Befehle und Parameter merken. Ein Doppelklick auf die Datei reicht, um den Container mit allen benötigten Einstellungen zu starten.

Die Batch-Datei vereinfacht und beschleunigt den Entwicklungsprozess erheblich. Sie ermöglicht es, den Docker-Container mit einem einzigen Klick oder Befehl im Terminal zu starten und stellt sicher, dass der Container immer mit den korrekten Einstellungen ausgeführt wird. Dies ist besonders praktisch, wenn Sie mehrere Projekte oder Umgebungen verwalten und immer wieder die gleichen Schritte ausführen müssen.

Einfache Einarbeitung

Die Einarbeitung in Docker ist genauso einfach, wenn nicht sogar einfacher, als der Einstieg in XAMPP und andere lokale Entwicklungsumgebungen. Mit gut dokumentierten Dateien wie init.sh, die sich um die automatische Konfiguration von Diensten wie Apache und MariaDB kümmert, wird der Einstieg erleichtert:

#!/bin/bash

# bind-address ändern auf 0.0.0.0, um remote Zugriff zu ermöglichen
sed -i 's/^bind-address\s*=.*$/bind-address = 0.0.0.0/' /etc/mysql/mariadb.conf.d/50-server.cnf

# Starte MariaDB
service mariadb start

# Warte darauf, dass MariaDB bereit ist
until mysqladmin ping &>/dev/null; do
  echo "Warte auf MariaDB..."
  sleep 1
done

# Erstelle Datenbank und Benutzer
# erstellt User: user1 mit Passwort: Geheim123
mysql -e "CREATE USER IF NOT EXISTS 'user1'@'%' IDENTIFIED BY 'Geheim123';"
mysql -e "GRANT ALL PRIVILEGES ON *.* TO 'user1'@'%';"
mysql -e "FLUSH PRIVILEGES;"

# Apache Konfiguration automatisch anpassen
sed -i 's/DirectoryIndex .*/DirectoryIndex index.php index.html/' /etc/apache2/mods-enabled/dir.conf

# Apache neu starten, um die Änderungen zu übernehmen
service apache2 restart

Der Supervisor-Dienst

Die supervisord.conf Datei konfiguriert den Supervisor-Dienst, der im Container verwendet wird, um mehrere Prozesse gleichzeitig zu starten und zu überwachen. Supervisor ist ein Prozesssteuerungswerkzeug, das hilfreich ist, um sicherzustellen, dass Dienste wie Apache, MariaDB und Mailhog kontinuierlich im Container laufen.

[supervisord]
nodaemon=true

[program:apache2]
command=/usr/sbin/apache2ctl -D FOREGROUND
autostart=true
autorestart=true
stdout_logfile=/var/log/apache2.log
stderr_logfile=/var/log/apache2_err.log

[program:mariadb]
command=/usr/bin/mysqld_safe
autostart=true
autorestart=true
stdout_logfile=/var/log/mariadb.log
stderr_logfile=/var/log/mariadb_err.log

[program:mailhog]
command=/usr/local/bin/MailHog
autostart=true
autorestart=true
stdout_logfile=/var/log/mailhog.log
stderr_logfile=/var/log/mailhog_err.log

Erklärung der Abschnitte
  1. [supervisord]:
    • nodaemon=true: Führt Supervisor im Vordergrund aus, was in einem Docker-Container erforderlich ist, damit der Container nicht sofort beendet wird.
  2. [program:apache2]:
    • command=/usr/sbin/apache2ctl -D FOREGROUND: Startet den Apache-Webserver im Vordergrundmodus.
    • autostart=true: Startet Apache automatisch, wenn der Container gestartet wird.
    • autorestart=true: Startet Apache automatisch neu, falls es unerwartet beendet wird.
    • stdout_logfile und stderr_logfile: Speichert die Standardausgabe und Fehlerausgabe von Apache in Log-Dateien.
  3. [program:mariadb]:
    • command=/usr/bin/mysqld_safe: Startet den MariaDB-Dienst im sicheren Modus.
    • Die anderen Optionen sind ähnlich wie bei Apache und sorgen dafür, dass MariaDB automatisch gestartet und überwacht wird.
  4. [program:mailhog]:
    • command=/usr/local/bin/MailHog: Startet den MailHog-Service, der zum Testen von E-Mails verwendet wird.
    • Die weiteren Optionen entsprechen denen für Apache und MariaDB und sorgen für den automatischen Start und Neustart von MailHog.

Durch die Verwendung von Supervisor wird sichergestellt, dass alle drei Dienste (Apache, MariaDB, und MailHog) im Container parallel laufen und überwacht werden. Wenn einer dieser Dienste abstürzt, wird er automatisch neu gestartet, was die Zuverlässigkeit des Containers verbessert.

Die Dateien in der Übersicht

Hier ist eine Übersicht der Verzeichnisstruktur und Dateien:

/project-directory
│
├── build-container.bat
├── dockerfile
├── init.sh
├── start-container.bat
├── supervisord.conf
├── src/
│   └── (die Webanwendungsdateien)
  • build-container.bat: Skript zum Bauen des Docker-Containers.
  • dockerfile: Definiert die Container-Umgebung und installierte Software.
  • init.sh: Initialisierungsskript, das während des Container-Starts ausgeführt wird.
  • start-container.bat: Skript zum Starten des Docker-Containers mit den benötigten Ports und Volumes.
  • supervisord.conf: Konfigurationsdatei für Supervisor, um Dienste wie Apache, MariaDB und Mailhog zu verwalten.
  • src/: Verzeichnis, das die Quellcodes deiner Webanwendung enthält.

Fazit

Im Vergleich zu XAMPP bietet eine Docker-basierte Entwicklungsumgebung zahlreiche Vorteile. Sie ist platzsparender, schneller im Start und Betrieb, einfacher zu konfigurieren und erleichtert das Deployment. Die Investition in die Einarbeitung lohnt sich, denn sie ermöglicht effizienteres Arbeiten und schnellere Entwicklungsprozesse.

Wie man die Versionsnummer in Symfony-Projekten automatisch im Frontend anzeigt

Im vorherigen Artikel habe ich schon erklärt, wie man in Symfony eine automatische Versionierung in Git einbinden kann. Hier zeige ich, wie man die Versionsnummer dann im Frontend zeigen kann.

In vielen Webprojekten ist es nützlich, die aktuelle Versionsnummer der Anwendung im Frontend anzuzeigen, um Transparenz zu schaffen und die Wartung zu erleichtern. In dieser Anleitung zeige ich dir, wie du eine Versionsnummer zentral in Symfony verwaltest und diese automatisch in deinen Twig-Templates verfügbar machst.

Schritt 1: Erstelle eine version.txt-Datei

Zunächst erstellen wir eine version.txt-Datei im Stammverzeichnis deines Projekts. Diese Datei wird die Versionsnummer enthalten. (Im optimalen Fall wird diese Datei automatisch erstellt und hochgezählt.)

  1. Erstelle eine Datei version.txt im Stammverzeichnis deines Projekts.
  2. Schreibe die aktuelle Versionsnummer hinein, z.B.:
   1.0.0

Schritt 2: Erstellen einer Twig-Erweiterung (AppExtension.php)

Um die Versionsnummer in allen Twig-Templates zugänglich zu machen, erstellen wir eine Twig-Erweiterung.

  1. Erstelle das Verzeichnis src/Twig/, falls es noch nicht existiert:
rc/Twig/
src/
├── Controller/
├── Entity/
├── Repository/
├── Twig/ <-- Hier
└── …
  1. Erstelle die Datei AppExtension.php im Verzeichnis src/Twig/ mit folgendem Inhalt:
<?php

// src/Twig/AppExtension.php

namespace App\Twig;

use Twig\Extension\AbstractExtension;
use Twig\TwigFunction;

class AppExtension extends AbstractExtension
{
    private $version;

    public function __construct()
    {
        $this->version = trim(file_get_contents(__DIR__ . '/../../version.txt'));
    }

    public function getFunctions(): array
    {
        return [
            new TwigFunction('app_version', [$this, 'getAppVersion']),
        ];
    }

    public function getAppVersion(): string
    {
        return $this->version;
    }
}

Diese Klasse liest die Versionsnummer aus der version.txt-Datei und stellt sie als Twig-Funktion app_version() zur Verfügung.

Schritt 3: Registriere die Twig-Erweiterung

Damit Symfony die neue Twig-Erweiterung erkennt, musst du sie in der services.yaml-Konfigurationsdatei registrieren.

  1. Öffne die Datei config/services.yaml.
  2. Füge die folgende Zeile hinzu, um die Erweiterung zu registrieren:
services:
    App\Twig\AppExtension:
        tags: ['twig.extension']

Schritt 4: Verwendung der Versionsnummer im Twig-Template

Jetzt kannst du die Versionsnummer in jedem Twig-Template deines Projekts einfach anzeigen.

  1. Öffne das Twig-Template, in dem du die Versionsnummer anzeigen möchtest, z.B. base.html.twig.
  2. Verwende die Twig-Funktion app_version():
<footer>
    <p>Version: {{ app_version() }}</p>
</footer>

Schritt 5: Testen

  1. Starte den Symfony-Server oder aktualisiere die Seite, um sicherzustellen, dass die Versionsnummer korrekt angezeigt wird.
  2. Die Versionsnummer sollte nun im Footer oder an der von dir gewählten Stelle im Frontend erscheinen.

Durch die Verwendung einer Twig-Erweiterung bleibt dein Code sauber und modular, und du vermeidest es, die Versionslogik in jedem Controller einzeln implementieren zu müssen.