byteTuto/website

Bereitstellung, Überprüfung, Diagnose oder Zurücksetzen der auf Amazon EC2 gehosteten byteTuto-Website (Docker + nginx, GitHub Actions, GHCR, Let's Encrypt). Für alle Fragen zu Deployment, HTTPS, Server oder CI/CD-Pipeline.

Was ist website?

Diese Skill-Anleitung beschreibt den vollständigen CI/CD-Deployment-Workflow für die byteTuto-Website, die auf einer Amazon EC2-Instanz mit Docker und nginx läuft. Sie ist für Entwickler und DevOps-Ingenieure gedacht, die die Website bereitstellen, überprüfen, diagnostizieren oder auf eine frühere Version zurücksetzen müssen. Die Pipeline verwendet GitHub Actions, um bei jedem Push auf den `main`-Branch automatisch Tests auszuführen (Docker-Build, nginx-Konfigurationsprüfung, Smoke-Tests), ein Multi-Arch-Docker-Image (amd64 + arm64) in die GitHub Container Registry (GHCR) zu pushen und per SSH auf die EC2-Instanz zu deployen. Der Deployment-Prozess beinhaltet das Ziehen des neuen Images, das Starten der Container und einen Gesundheitscheck; bei Fehlschlag erfolgt ein automatisches Rollback auf die vorherige Version. Die Anleitung enthält außerdem nützliche Befehle für den Betrieb (Logs, Health-Checks, manuelles Rollback), die HTTPS-Einrichtung mit Let's Encrypt und eine Diagnosetabelle für häufige Probleme. Plattformen: GitHub Actions, Amazon EC2 (Docker), GHCR, Let's Encrypt, nginx.

Funktioniert mit~Claude Code~Codex CLI~Cursor

npx skills add https://github.com/byteTuto/website/tree/HEAD/.claude/skills/deploy-ec2

Dokumentation

Bereitstellung byteTuto auf EC2

Deployment-Kette

git push auf main → .github/workflows/deploy.yml
Job test : docker build, nginx -t, Smoke-Test (/healthz, Startseite, 404, CSP-Header).
Job publish : Multi-Arch-Image (amd64 + arm64) wird auf ghcr.io/bytetuto/website:<sha7> und :latest gepusht.
Job deploy : SSH auf EC2, schreibt /opt/bytetuto/.env, kopiert docker-compose.yml + deploy/*.sh, führt deploy/deploy.sh aus.
deploy.sh : pull, up -d, wartet auf /healthz (max. 40 s). Fehlschlag → automatisches Rollback auf das Image von .last_image.

PRs führen nur den Test-Job aus.

Secrets / Variablen GitHub (Settings → Secrets and variables → Actions)

Secrets : EC2_HOST, EC2_USER (ec2-user oder ubuntu), EC2_SSH_KEY (vollständiger privater Schlüssel), EC2_KNOWN_HOSTS (empfohlen: Ausgabe von ssh-keyscan -H <ip>).
Variablen : DOMAIN (z.B. bytetuto.com), LETSENCRYPT_EMAIL.
GitHub-Umgebung production (kann manuelle Genehmigung erfordern).

Nützliche Befehle (auf der EC2, in /opt/bytetuto)

Status : docker compose ps · Logs : docker compose logs -f web
Health : curl -fsS http://127.0.0.1/healthz
Eine bestimmte Version erneut bereitstellen : IMAGE=ghcr.io/bytetuto/website:<sha7> bash deploy/deploy.sh
Manuelles Rollback : deploy.sh mit dem alten Tag erneut ausführen (sichtbar im Tab Packages von GitHub).
HTTPS (einmalig, nach DNS OK) : bash deploy/init-ssl.sh (zuerst mit STAGING=1 testen).
Erneuerung : cron /etc/cron.d/bytetuto-certbot (2×/Tag), Log in certbot-renew.log.

Wie nginx HTTP oder HTTPS wählt

nginx/40-bytetuto-ssl.sh wird beim Start des Containers ausgeführt: Zertifikat für $DOMAIN vorhanden → https.conf.template, sonst → http.conf.template. Nach init-ssl.sh genügt ein einfaches docker compose restart web.

Schnelldiagnose

Symptom	Ursache
Job deploy : `Permission denied (publickey)`	`EC2_SSH_KEY` / `EC2_USER` falsch
`docker: permission denied`	Benutzer ist nicht in der Docker-Gruppe → nach `ec2-setup.sh` neu anmelden
`pull access denied`	GHCR-Paket privat und Anmeldung fehlgeschlagen, oder Paket öffentlich machen
Timeout HTTP von außen	Security Group: Ports 80/443 nicht geöffnet
certbot schlägt fehl	DNS noch nicht propagiert, oder Port 80 geschlossen
`exec format error`	Architektur: Prüfen, ob das Image wirklich Multi-Arch ist

Regeln

Niemals .env, SSH-Schlüssel oder certbot/ lesen oder anzeigen.
Vor git push, ssh, scp oder Änderungen an deploy/ und dem Workflow um Bestätigung fragen.