From 63142e27eab499260336e91db2ec91e81a362d25 Mon Sep 17 00:00:00 2001 From: Denis Ergin Date: Tue, 22 Apr 2025 18:10:57 +0200 Subject: [PATCH] feat(slides): first throw build and deploy --- src/components/slides/deployments/build.astro | 142 ++++++++++++++++++ .../slides/deployments/docker.astro | 97 ++++++++++++ .../slides/deployments/file-server.astro | 29 ++++ src/components/slides/deployments/index.astro | 13 ++ src/components/slides/deployments/title.astro | 4 + .../04-deployment-and-production.astro | 17 +++ 6 files changed, 302 insertions(+) create mode 100644 src/components/slides/deployments/build.astro create mode 100644 src/components/slides/deployments/docker.astro create mode 100644 src/components/slides/deployments/file-server.astro create mode 100644 src/components/slides/deployments/index.astro create mode 100644 src/components/slides/deployments/title.astro create mode 100644 src/pages/slides/flexi-pool/04-deployment-and-production.astro diff --git a/src/components/slides/deployments/build.astro b/src/components/slides/deployments/build.astro new file mode 100644 index 0000000..575698f --- /dev/null +++ b/src/components/slides/deployments/build.astro @@ -0,0 +1,142 @@ +
+
+

Wie machen wir den Code Produktionsreif?

+
+ +
+

Wir haben nun unsere erste App geschrieben. Nun wollen wir die natürlich auch "öffentlich" Verfügbar haben. Das macht ja immerhin das Internet aus...

+

Wir schauen uns nun an, welche Schritte wir unternehmen sollten, um von lokal zu global zu wechseln.

+
+ +
+

Der erste Schritt besteht darin, den von uns geschrieben Code zu optimieren.

+
+ +
+

Warum sollte ich meinen Code optimieren?

+
+ +
+

Der Rohe Code den wir geschrieben haben ist, wenn wir das auf große Projekte projezieren, ineffizient.

+

Wir können den Code mittels Tools auf verschiedene Arten transformieren und effizienter gestalten.

+
+ +
+

Optimierungsmöglichkeiten:

+
    +
  • Minification
    • +
  • Tree-Shaking
    • +
  • Bundling
    • +
  • Compatibility
    • +
+
+ +
+

Minification

+
+ +
+

Während der Minification wird der Code verkleinert. Dabei werden unnötige Whitespaces entfernt, und Variablennamen verkürzt.

+

Variablennamen werden so verkürzt, dass es nur noch kurze Buchstabenfolgen (a, b, c, d, usw...) sind.

+

Verkleinert das finale JavaScript deutlich und reduziert dadurch die Menge der Daten die übertragen werden müssen.

+
+ +
+

Tree-Shaking

+
+ +
+

Wenn wir externe Bibliotheken und Frameworks verwenden, nutzen wir in den meisten Fällen nicht alle Features des Pakets.

+

Während des Tree-Shaking werden ungenutzte Code-Schnippsel von externen Paketen entfernt, sodass ungenutzter Code erst gar nicht ausgeliefert wird.

+
+ +
+

Bundling

+
+ +
+

Der Übersicht wegen teilen wir unseren Code in mehrere Dateien auf.

+

Beim Bundling sollen diese zusammenhängenden JavaScript-Codeschnippsel möglichst so zusammengefasst werden, dass eine Website nur ein einziges File herunter laden muss.

+

Hier gibt es aber auch eine "Anforderung", dass solche Bundles eine bestimmte Dateigröße nicht überschreiten sollten.

+
+ +
+

Compatibility

+
+ +
+

Das ist eher ein Relikt aus alten Zeiten, als der Support für den Internet Explorer 11 noch "sichergestellt" werden musste.

+

Tools wie Babel stellt sicher, dass moderne Features aus neueren JavaScript-Versionen auch "funktional" in alten Browsern verwendet werden können.

+

Hierzu wurden sogenannte "Polyfills" verwendet. Code der moderne Features "nachmacht", ohne dass sich der Entwickler darum kümmern muss.

+
+ +
+

Das sind die wichtigsten Dinge, die passieren müssen, damit unser JavaScript-Code auf einer realen Website "ausgrollt" werden können.

+

Jetzt stellt man sich natürlich die Frage, wie man das alles erreichen kann. Dass sind immerhin keine "kleinen" Änderungen die man an seinem Code machen muss.

+

Das gute: Wir müssen eigentlich recht wenig machen. Tools wie Bundler und Co. erledigen die schwere arbeit für uns.

+
+ +
+

Ein solches Tool verwenden wir bereits: Vite

+

Wir haben unseren vergangenen (Frontend) Projekte mit Vite aufgesetzt. Und Vite macht für uns das alles, was oben beschrieben wurde.

+
+ +
+

Um unser Frontend für die Produktion optimiert zu bauen, ist auch nur ein einzlnes Kommando notwendig: npm run build

+
+ +
+

Ein kurzer Blick: Möglichkeiten um eine Website zu "rendern"

+
+ +
+

Das was wir bisher gebaut haben ist eine Statische Website. Die Inhalte die Ausgespielt werden sind vollständig und es sind z.B. keine weiteren Requests notwendig, damit die Website funktionieren kann.

+

Auch meine (also diese) Website ist Statisch erzeugt: Alle Inhalte sind zum nach dem Build-Prozess vollständig uns es muss der Content nur noch auf einen Server geladen werden.

+
+ +
+

Aber was gibt es für Alternativen?

+

Im Allgemeinen gibt es 2 weitere "Möglichkeiten", wie eine Website funktionieren kann

+
+ +
+

Single Page Applications

+
+ +
+

Single Page Applications sind spezialisierte Websites, die größtenteils auf JavaScript basiertem Rendering aufgebaut sind (Beispiele sind: React, Vue, etc.)

+

Die Website besteht eigentlich nur aus einer kleinen HTML-Datei mit einem Script-Tag. Das Script sorgt dann dafür, dass Inhalte angezeigt werden und Interaktivität hergestellt wird.

+
+ +
+

Die angezeigten Inhalte sind dann meist dynamischer Natur. Das heißt, die Inhalte werden nachträglich über Requests aus einem Content-Server ausgespielt.

+

Konzepte wie Routing passiert dann auch vollständig im Browser/JavaScript. In einer Art und Weise wie es der Endnutzer nicht mehr mitbekommt.

+
+ +
+

Server Side Rendering

+
+ +
+

Server-Side-Rendering ist eigentlich ein sehr altes Konzept:

+

Das auszuliefernde HTML-Markup wird auf einem Server dynamisch bei der Abfrage generiert.

+

Eines dieser älteren Systeme ist PHP. Moderne Alternativen sind vor allem React (NextJS oder Remix), Vue (Nuxt), Svelte oder eines der vielen anderen Systeme die es mittlerweile gibt.

+
+ +
+

Auch hier gibt es nochmals 2 "Unter"-Wege: Ein Hybrides Setup oder Klassiches Server-Side-Rendering

+

Im klassischen Server-Side-Rendering wird bei einem Seitenwechsel ein neues HTML angefordert.

+

Im Hybriden Setup (z.B. NUXT), wird der initiale Inhalt auf dem Server vor-generiert. Sobald der Inhalt beim Nutzer im Browser liegt, "übernimmt" JavaScript alle weiteren Seiten (ähnlich zu einer Single-Page-Application)

+
+ +
+

Aber wieso das "Hin-und-Her" mit Server-Side-Rendering?

+

Wir (als Webentwickler oder Betreiber eures eigenen Shops) wollen natürlich auffindbar sein. Und das größte "Ding" um gefunden zu werden ist Google.

+

Und Google hat bestimmte Anforderungen um unsere Website besser zu "ranken". In der Webentwicklung spricht man bei diesen Anforderungen von "Search Engine Optimization".

+
+ +
+

Im großen und ganzen wollen wir simpel gesprochen unsere Inhalte bereits bei der Ankunft beim Nutzer im HTML-Markup haben und nicht erst nachträglich durch JavaScript generieren.

+

Das Thema Search-Engine-Optimization wird nochmals tiefer in Web-Engineering II (zumindest bei mir behandelt.)

+
+
\ No newline at end of file diff --git a/src/components/slides/deployments/docker.astro b/src/components/slides/deployments/docker.astro new file mode 100644 index 0000000..f0379de --- /dev/null +++ b/src/components/slides/deployments/docker.astro @@ -0,0 +1,97 @@ +
+
+

Docker

+
+ +
+

Was ist Docker?

+

+ Docker ist eine Plattform, mit der Anwendungen in isolierten Containern verpackt, verteilt und ausgeführt werden können. Diese Container enthalten alles, was die Anwendung zum Laufen braucht, wodurch sie unabhängig von der Umgebung funktioniert. +

+

-- ChatGPT

+
+ +
+

Docker ist zunächst eines: Eine Virtualisierungs-Software. Auf ihr können also im weitesten Sinne komplette Betriebssysteme in Isolation laufen.

+

Jede Applikation eines Anwendungs-System sollte möglichst allein laufen. Abhängigkeiten zu weiteren Applikationen (zum Beispiel Datenbanken), werden in einem isolierten Container ausgeführt.

+
+ +
+

Da wir nur einen statischen Webserver laufen lassen wollen, ist dies zunächst alles recht einfach.

+

Wir bauen innerhalb eines Docker-Containers unsere Website und stellen die gebaute Website innerhalb eines "sauberen" Containers zur Verfügung.

+

Wir schauen uns den Prozess Schritt für Schritt an.

+
+ +
+

Eine Simple Konfiguration für Caddy

+
+ +
+

Wir werden als Beispiel einen Caddy Web-Server verwenden um unsere Website verfügbar zu machen.

+

Die minimale Konfiguration für Caddy umfasst lediglich 3 Zeilen, wer an ein Beispiel mit nginx interessiert ist, findet diese auf meinem GitHub.

+
+ +
+ 

+      # Caddyfile
+      :80
+
+      root * /srv
+      file_server
+
+
+ +
+

Anweisungen für den Bau eines Docker-Containers

+
+ +
+

Wir müssen nun Docker eine Bauanleitung geben, wie wir vom Development-Code, zu einer gebauten Version und dann zu einem isolierten Web-Server (Caddy) kommen.

+

Dafür legen wir die Datei "Dockerfile" im root unseres Projektes an.

+
+ +
+

Wir können uns den Prozess in 2 Schritten vorstellen:

+
    +
  1. Die Website bauen
    2. +
  2. Die gebaute Website in einem Caddy-File-Server ablegen
    3. +
+
+ +
+ 

+      FROM node:20-alpine AS base
+
+      COPY . /app
+      WORKDIR /app
+
+      FROM base AS build
+      RUN npm ci
+      RUN npm run build
+
+
+ +
+ 

+      FROM caddy:alpine
+
+      COPY ./dist/ /srv/
+      COPY ./Caddyfile /etc/caddy/Caddyfile
+
+
+ +
+

Wenn wir das ganze lokal ausprobieren wollen, müssen wir einfach (bei laufender Docker-Engine) folgenden Befehl in der Kommandozeile ausführen:

+

docker build . -t my-website

+

Das veranlasst Docker zum Bau der Website anhand des angegebenen Dockerfile

+
+ +
+

Der gebaute Container ist kann dann lokal mit Docker ausgeführt werden:

+

docker run my-website -p 8080:80

+
+ +
+

Damit haben wir nun die Möglichkeit, die Website bei Anbietern wie Sevalla, Railway oder Fly zu deployen...

+
+
\ No newline at end of file diff --git a/src/components/slides/deployments/file-server.astro b/src/components/slides/deployments/file-server.astro new file mode 100644 index 0000000..586e21c --- /dev/null +++ b/src/components/slides/deployments/file-server.astro @@ -0,0 +1,29 @@ +
+
+

Wie wir unseren Website "hosten"

+
+ +
+

Wir haben nun unseren optimierten Code bei uns liegen, wie kommt also der Inhalt von dir zu mir?

+

Nun der Code der bei uns liegt, wird nicht dort bleiben. Wir müssen die Website in einem Web-Server ablegen und diesen Server korrekt konfigurieren.

+
+ +
+

Je nach Anwendungsfall gibt es hierfür verschiedene Optionen.

+

Da wir bis jetzt nur eine statische Website erstellt haben, ist ein einfacher Webserver, der Dateien "ausliefern" kann, vollkommen ausreichend.

+
+ +
+

Mögliche Server-Applikationen für einen statischen Web-Server:

+
    +
  • nginx ("Hoher" Konfigurationsaufwand, existiert bereits länger)
    • +
  • Caddy (Moderner mit weniger Konfigurationsaufwand)
    • +
  • Viele Weitere...
    • +
+
+ +
+

Unser Ziel ist es, die fertig gebaute Website an einem für den Web-Server geeigneten Ort abzulegen, sodass die Dateien ausgeliefert werden können.

+

Wir werden unsere Arbeit aber nicht direkt auf unserem PC "laufen" lassen. Wir verwenden die Virtualisierungs-Software "Docker" um unsere Applikation lokal zu testen und später im Internet laufen zu lassen.

+
+
\ No newline at end of file diff --git a/src/components/slides/deployments/index.astro b/src/components/slides/deployments/index.astro new file mode 100644 index 0000000..b9b3b37 --- /dev/null +++ b/src/components/slides/deployments/index.astro @@ -0,0 +1,13 @@ +--- +import Title from "./title.astro"; +import Build from "./build.astro"; +import FileServer from "./file-server.astro"; +import Docker from "./docker.astro"; +--- + +
+ + <Build /> + <FileServer /> + <Docker /> +</div> \ No newline at end of file diff --git a/src/components/slides/deployments/title.astro b/src/components/slides/deployments/title.astro new file mode 100644 index 0000000..d7cca9e --- /dev/null +++ b/src/components/slides/deployments/title.astro @@ -0,0 +1,4 @@ +<section> + <h1>Vom Code zu "Production"</h1> + <p>Wie wir unsere Website der Öffentlichkeit zugänglich machen.</p> +</section> \ No newline at end of file diff --git a/src/pages/slides/flexi-pool/04-deployment-and-production.astro b/src/pages/slides/flexi-pool/04-deployment-and-production.astro new file mode 100644 index 0000000..09f71ce --- /dev/null +++ b/src/pages/slides/flexi-pool/04-deployment-and-production.astro @@ -0,0 +1,17 @@ +--- +import Reveal from "../../../layouts/Reveal.astro"; +import Slides from "../../../components/slides/deployments/index.astro"; +--- + +<Reveal title="Build and Deploy to Production"> + <Slides /> +</Reveal> + +<!-- + Hosting Files + NGINX + + Modern Web + Containerization + Docker +--> \ No newline at end of file