Projekt LB2 – WordPress Migration¶
1. Warum WordPress?¶
WordPress ist das meistverbreitete CMS der Welt – über 40% aller Websites laufen darauf. Es ist ein klassischer Monolith: Webserver, PHP, Datenbank und alle Plugins sind eng miteinander verbunden und laufen als eine Einheit zusammen.
Genau deshalb eignet sich WordPress ideal als Migrationsprojekt: Es vereint alles was du in der Theorie gelernt hast in einer einzigen, realen Applikation.
| Theorie-Block | Praxis im Projekt |
|---|---|
| Client-Server, HTTP/HTTPS, DNS | Webserver aufsetzen, SSL konfigurieren, Domain einrichten |
| Reverse Proxy, Virtual Host | Apache Virtual Host und PHP-FPM konfigurieren |
| IaaS, Cloud | AWS EC2 Instanz als Zielumgebung |
| SQL-Datenbank | MySQL/MariaDB für WordPress |
| Monolith, Migrationsansätze | WordPress von A nach B migrieren |
| Blob Storage, Backup | Automatisches Backup mit rclone auf Backblaze B2 |
2. Lernziele¶
Nach Abschluss des Projekts kannst du:
- Eine Linux-Serverumgebung (Apache, PHP-FPM, MySQL) von Grund auf aufsetzen
- Eine AWS-Netzwerkumgebung (VPC, Subnetz, Security Group) konfigurieren
- Eine WordPress-Applikation manuell migrieren (Datenbank + Dateien)
- SSL/HTTPS mit einem gültigen Zertifikat einrichten
- Ein automatisiertes Backup-System mit Cloud-Speicher aufbauen
- Eine vollständige technische Dokumentation nach vorgegebener Struktur erstellen
3. Ausgangslage¶
Die WordPress-Applikation unter https://m158.geekz.ch/ soll auf einen neuen Server migriert werden. Deine Aufgabe besteht darin, die Zielumgebung vollständig aufzusetzen und die Applikation zu migrieren.
3.1 Zielarchitektur¶
3.2 Rahmenbedingungen¶
- Der neue Webserver läuft unter Linux (Distribution, Webserver und Datenbankserver sind frei wählbar, solange WordPress-kompatibel)
- WordPress-Migrationsplugins sind nicht erlaubt – die Migration erfolgt manuell über Datei- und Datenbankübertragung
- Die Zielumgebung wird auf AWS EC2 betrieben
3.3 Quellsystem – WordPress-Backup via FTP¶
Verbinde dich mit einem FTP-Client und lade das vollständige Backup herunter:
| Host | m158.geekz.ch |
| User | m158 |
| Passwort | Zh42p_z82 |
4. Bewertung¶
4.1 Die 5 Phasen¶
Das Projekt ist in 5 Phasen aufgeteilt. Nach jeder Phase findet eine Bewertung statt – die Summe der Phasenbewertungen ergibt die LB2-Note.
[!IMPORTANT] Lass jede Phase von der Lehrperson abnehmen, bevor du mit der nächsten weitermachst.
4.2 Kompetenzmatrix¶
Die Bewertung erfolgt nach der Kompetenzmatrix LB2. Jede Kompetenz hat drei Stufen – du entscheidest wie weit du gehst.
Für die Benotung ist die Dokumentation auschlaggebend.
4.3 Docker¶
Du darfst Docker oder andere Containerisierung für alle Dienste einsetzen. Eine gemischte Umsetzung (teils Container, teils klassisch) ist ebenfalls erlaubt.
[!NOTE] Für Docker gibt es keine zusätzlichen Punkte – in manchen Situationen ist eine containerisierte Lösung sogar einfacher als eine klassische Installation.
5. GitLab-Repository¶
Erstelle ein eigenes Repository für die LB2-Dokumentation und lade die Lehrperson als Developer ein (Settings → Members).
[!NOTE] Das Repository kann öffentlich oder privat sein – wichtig ist, dass die Lehrperson als Mitglied eingeladen ist und jederzeit Zugriff hat.
[!TIP] SmartGit ist für schulische Zwecke kostenlos: https://www.syntevo.com/register-non-commercial/#academic
5.1 Struktur des Repositorys¶
📁 01_Dokumentation/
├── README.md → Projektübersicht
├── 01_projektplan.md
├── 02_architektur_system.md
├── 03_umgebung.md
├── 04_dns.md
├── 05_webserver.md
├── 06_php.md
├── 07_datenbank.md
├── 08_phpmyadmin.md
├── 09_sftp_ftps.md
├── 10_wordpress_migration.md
├── 11_wpcli.md
├── 12_backup.md
├── 13_testing.md
├── 14_monitoring.md
└── 15_deployment.md
📁 03_Diverses/
├── Logins/
└── Links/
Die Vorlage für 01_Dokumentation/ findest du unter Vorlage LB2 – kopiere den gesamten Ordnerinhalt in dein Repository.
5.2 Kanban Board einrichten¶
Für die Fortschrittsverfolgung verwendest du das integrierte GitLab Issue Board in deinem Repository.
Schritt 1 – Labels anlegen (Issues → Labels → New label):
| Label | Farbe |
|---|---|
Todo |
Grau |
In Progress |
Blau |
Review |
Orange |
Abgenommen |
Grün |
Schritt 2 – Issues importieren (Issues → List → Import issues):
Lade die CSV-Vorlage herunter und importiere sie direkt in dein Repository. Alle 14 Kompetenzen werden automatisch als Issues angelegt – inklusive Stufen-Checkliste.
Schritt 3 – Board einrichten (Issues → Boards → Create list):
Erstelle je eine Spalte für Todo, In Progress, Review und Abgenommen.
Ablauf:
1. Du arbeitest an einer Kompetenz → Issue auf In Progress schieben
2. Bereit zur Abnahme → Issue auf Review schieben + Kommentar mit Hinweis an Lehrperson
3. Lehrperson prüft, kommentiert und schliesst das Issue → Label Abgenommen
6. Weitere Infos¶
Erlaubte Hilfsmittel: Google, Claude, ChatGPT und andere KI-Tools sind ausdrücklich erlaubt. Die Dokumentation muss aber in eigenen Worten verfasst sein und zeigen, dass du verstanden hast was du gemacht hast.
Bewertung: Die Lehrperson führt eine Excel-Tabelle mit dem aktuellen Stand und der Note pro Lernenden. Den aktuellen Stand deiner Kompetenzen siehst du jederzeit auf dem Kanban-Board in deinem GitLab-Repository.
[!NOTE] Die Lehrperson erstellt zu Beginn des Moduls einen privaten Teams-Kanal pro Lernenden. Sämtliche persönliche Kommunikation zur LB2 – Fragen, Abnahmen, Feedback – erfolgt ausschliesslich über diesen Kanal.
[!NOTE] Wenn du trotz Google, Claude und anderen Hilfsmitteln länger als 20 Minuten feststeckst – hol dir Hilfe. Die Lehrperson hilft dir gerne weiter.