NGINX auf dem Raspberry Pi hosten

Stelle NGINX auf deinem Raspberry Pi bereit und diagnostiziere Docker-Ports.

Introduction

30 Second Summary

Eine Webseite kann auf einem Gerät problemlos laufen. Für einen Kunden ist sie trotzdem nutzlos, sobald sie sich auf seinem Mac nicht öffnen lässt.

In diesem Projekt wirst du deinen Raspberry Pi in einen lokalen Kunden-Webserver mit NGINX in Docker verwandeln. Du erlebst dabei den Ausfall durch fehlendes Port-Publishing samt gezielter Wiederherstellung.

What You'll Build

In Safari siehst du die NGINX-Willkommensseite, die ein Container auf deinem Raspberry Pi im lokalen Netzwerk ausliefert.

Am Ende dieses Projekts hast du:

  • Eine SSH-Verbindung, über die du das Netzwerkprofil deines Raspberry Pi abliest. Du dokumentierst dabei IPv4-Adresse, Präfixlänge, Gateway sowie DNS-Server.
  • Eine erreichbare NGINX-Willkommensseite auf Port 8080, die du in Safari vom Mac aus aufrufst.
  • Eine reproduzierbare Docker-Diagnose für fehlendes Port-Publishing. Docker-Ausgaben machen den Fehlerweg sichtbar. Ein kontrollierter Neustart bestätigt den wiederhergestellten Betrieb.
  • Secret Mission: Einen echten Host-Port-Konflikt erzeugen. Danach betreibst du einen zweiten NGINX-Webdienst auf Port 8081.

Welche Voraussetzungen gibt es?

Dein Mac muss den Raspberry Pi über dasselbe lokale Netzwerk erreichen können. Auf dem 64-Bit-fähigen Pi brauchst du Raspberry Pi OS mit aktiviertem SSH, Docker sowie Internetzugang.

Before We Start

Bevor die praktische Arbeit beginnt, legst du fest, welchen lokalen Dienst dein Raspberry Pi bereitstellt und welches sichtbare Ergebnis Erfolg bedeutet. Dein Ziel ist ein lokaler NGINX-Kundenwebdienst, dessen Willkommensseite Safari auf dem Mac über http://<PI_IP>:8080 lädt.

Verify Server Access and Network Settings

Your planned NGINX service is useful only when your Mac can reliably reach the Raspberry Pi. Safari eventually needs a verified LAN address before it can load the customer page.

An SSH session in Apple Terminal gives you a dependable administration path to the Pi. You will use it to document the active adapter's IPv4 configuration.

Finally, you will confirm that Docker Engine 29.9.3 can reach its daemon on the Pi.

In this step, get ready to:
  • Establish an active SSH session from Apple Terminal to the Raspberry Pi.
  • Record the active adapter's IPv4 configuration.
  • Verify the Docker daemon with version and container-list checks.
Connect to the Raspberry Pi

SSH creates an encrypted remote terminal session. Every command after login runs on the Raspberry Pi.

A first connection may ask you to confirm the host. Apple Terminal then requests the password for your Pi account.

  • Press Cmd+Space on your Mac to open the search bar.
  • Type Terminal in the search bar.
  • Press Enter to open Apple Terminal.
  • Use your Raspberry Pi account name in place of <username>.
  • Choose the Pi's current address or known .local hostname for <pi_ip_address>.
  • Start the SSH session by running the completed command:
ssh <username>@<pi_ip_address>

What does this command do?

  • The username selects the account that manages the Raspberry Pi.
  • The host portion tells SSH which Raspberry Pi to contact on your local network.
  • The resulting shell lets you administer the Pi from your Mac.
  • Approve the host confirmation if Apple Terminal shows one.
  • Enter your Pi account password when Apple Terminal requests it.

You should see a remote shell prompt for the Raspberry Pi. That secure shell is now your management path for the web server.

Unable to start the SSH session?

  • Confirm that your Mac is connected to the same local network as the Raspberry Pi.
  • Check the Pi address or known hostname for typing mistakes.
  • Confirm that SSH is enabled on the Raspberry Pi.

Ask for help: Help me diagnose why my Mac cannot establish an SSH session with my Raspberry Pi on the same local network.

Document the active network settings

The active adapter's network settings identify where the Pi lives on your LAN. They also show how the Pi reaches destinations beyond its local network.

What do these network values mean?

  • The IPv4 address identifies the Pi's active network endpoint.
  • The prefix length defines the local subnet boundary.
  • The gateway carries traffic beyond that subnet.
  • The DNS server translates hostnames into network addresses.
  • Display the Raspberry Pi's network interfaces by running this command in the active SSH session:
nmcli device show

What does this command show?

  • The command groups network details by interface.
  • The IP4.ADDRESS[1] field contains the IPv4 address with its prefix length.
  • The IP4.GATEWAY field identifies the IPv4 gateway.
  • The IP4.DNS[1] field identifies the first IPv4 DNS server.
  • Find the connected Ethernet or Wi-Fi block that contains IP4.ADDRESS[1].
  • Record the interface name from that block as <ACTIVE_INTERFACE>.
  • Read IP4.ADDRESS[1] as an address part followed by a prefix length.
  • Record the address part as <PI_IP>.
  • Record the prefix length as <PREFIX_LENGTH>.
  • Record IP4.GATEWAY as <GATEWAY>.
  • Record IP4.DNS[1] as <DNS_SERVER>.

You now have the exact LAN address Safari uses later. You also have the supporting network values needed to diagnose the route beyond the Pi.

Unsure which adapter is active?

  • Choose the Ethernet or Wi-Fi block that contains populated IPv4 address information.
  • Ignore disconnected adapter blocks with no usable IPv4 address.
  • Check the same block for its gateway and DNS values.

Ask for help: Help me identify the active adapter in my nmcli output and separate its IPv4 address from its prefix length.

Confirm the Docker daemon

The Docker command-line client sends requests to the Docker daemon. A client version alone does not prove that the server component is responding.

Before you run the check, which two sides of Docker do you expect the output to confirm?

  • Request the Docker client and server details by running this command in the active SSH session:
docker version

What does this command verify?

  • The Client section describes the command-line client running in your SSH session.
  • The Server section proves that the Docker daemon answered.
  • The server version confirms which Docker Engine release is active on the Raspberry Pi.

You should see separate Client and Server sections without a connection error. The Server section should report version 29.9.3.

  • Confirm that the daemon responds to a running-container query by running:
docker ps

What does this command verify?

  • The command asks the daemon for its current running-container list.
  • A returned list proves that the Docker client can communicate with the daemon.
  • The output can contain only column headings when no containers are running.

You should receive a container list without a daemon connection error. That is the Docker host verified and ready for the first web service.

Docker daemon not responding?

  • Confirm that both Docker commands are running inside the active Raspberry Pi SSH session.
  • Check that the output includes a Server section.
  • Compare the reported server version with 29.9.3.

Ask for help: Help me diagnose why Docker responds with client information but does not return a working server section on my Raspberry Pi.

Your Verified Baseline

  • The Mac has an active SSH session to the Raspberry Pi.
  • Active adapter: <ACTIVE_INTERFACE>.
  • IPv4 address: <PI_IP>.
  • Prefix length: <PREFIX_LENGTH>.
  • IPv4 gateway: <GATEWAY>.
  • IPv4 DNS server: <DNS_SERVER>.
  • The Docker daemon is reachable with Docker Engine 29.9.3.

No NGINX image has been pulled. No web container has been created.

Your Mac now has a verified administration path to a known Raspberry Pi LAN address. Next, you will turn that verified host into a web service that Safari can reach.

Launch the First LAN Web Service

Your previous checks proved that the Mac can reach the Raspberry Pi through SSH. They also proved that Docker Engine 29.9.3 can answer commands on the Pi.

This step runs NGINX inside a container. Port publishing gives Safari on your Mac a path to the web server.

In this step, get ready to:
  • Pull the version-pinned nginx:1.30.6 image onto the Raspberry Pi.
  • Run a container named customer-web with host port 8080 published.
  • Verify the published web service from your Mac.
Keep the NGINX version repeatable

A Docker image contains the files needed to create a container. The version tag keeps every new container on the same NGINX release.

Why Docker for this service?

Docker gives the web server a defined container boundary. Its publishing controls make the route between the Raspberry Pi and your Mac visible.

A native NGINX package could also serve pages. Docker makes the networking behavior easier to reproduce during diagnosis.

  • Pull the selected NGINX image through your active SSH session by running:
docker pull nginx:1.30.6

What does this command do?

  • The nginx:1.30.6 tag selects the exact NGINX image version used by this project.
  • Docker downloads the image layers into its local image store on the Raspberry Pi.
  • Confirm the pull completed when Apple Terminal returns to the SSH prompt without reporting a download failure.

Image download not completing?

  • Check that the Raspberry Pi still has internet access if the download stops before completion.
  • Confirm that the image tag is exactly nginx:1.30.6.

Ask for help: Why is my NGINX image pull failing on the Raspberry Pi?

Connect the container to the LAN

NGINX listens on container TCP port 80. The host mapping forwards Raspberry Pi port 8080 to that internal port.

  • Create the named web service with its published port by running:
docker run --name customer-web -d -p 8080:80 nginx:1.30.6

How is the container published?

  • The --name option assigns the container the name customer-web.
  • The -d flag keeps the container running in the background.
  • The -p 8080:80 mapping sends host port 8080 to container port 80.
  • The missing host IP causes Docker to publish the port on all host interfaces.
  • Inspect the running container and its published port by running:
docker ps

What does the container list prove?

The container list reports processes that are currently running. Its port information shows whether traffic from the Raspberry Pi can reach a container port.

You should see customer-web with a running status. You should also see host port 8080 mapped to container port 80/tcp.

Container missing from the list?

  • Check the preceding command output for a name conflict involving customer-web.
  • Check the preceding command output for a host-port conflict involving 8080.
  • Confirm that the active SSH session is still connected to the Raspberry Pi.

Ask for help: Why is customer-web missing from my running Docker containers?

Verify the service from the Mac

Before you check, predict what Safari will show when it contacts port 8080 on your Raspberry Pi.

  • Switch back to Safari on your Mac.
  • Enter http://<PI_IP>:8080 in the Safari address field.
  • Press Return to load the page.

You should see the NGINX welcome page. Great work. Your Mac can now reach the containerized web server through the Raspberry Pi's LAN address.

Welcome page not loading?

  • Confirm that the address uses your recorded <PI_IP> value.
  • Confirm that the address ends with port 8080.
  • Check that your Mac remains connected to the same local network as the Raspberry Pi.

Ask for help: Why can Safari not reach my NGINX container on port 8080?

The service path from your Mac to NGINX is now proven. Next, you'll challenge that path and use Docker diagnostics to identify which layer changed.

Reproduce the Missing Port Mapping

Your first web service test proved that the NGINX welcome page can travel from a Docker container on your Raspberry Pi to Safari on your Mac. The existing SSH session gives you a stable control path into the server.

A running container proves that its process is active. Browser reachability also depends on a published route from the Raspberry Pi's LAN interface into the Docker bridge network.

You'll recreate the same container without the publishing option. Then you'll test the browser before using Docker's status views to explain the failure.

In this step, get ready to:
  • Replace the published customer-web container with an unpublished instance from the same image.
  • Test the existing Safari address from your Mac.
  • Compare the running container state with its missing host-port mapping.
Replace the published container

A container name must be available before Docker can assign it to a replacement. The next command removes the running container while leaving the local nginx:1.30.6 image ready for reuse.

  • Return to the active SSH session from earlier.
  • Remove the published customer-web container by running:
docker rm -f customer-web

What did Docker remove?

Docker prints customer-web after it removes the container. The local nginx:1.30.6 image remains available for the replacement.

  • Create the replacement container from the same image by running:
docker run --name customer-web -d nginx:1.30.6

What did Docker start?

  • The --name option assigns the familiar customer-web name to the replacement.
  • The -d option starts the container in the background, so Docker returns a container ID to your terminal.

Container Did Not Start?

  • Check the removal output for the customer-web name to confirm that the original container was deleted.
  • Review the creation output for a container-name conflict or an image-related failure.

Ask for help: Help me diagnose why the replacement customer-web container did not start from nginx:1.30.6.

Test the existing browser address

The replacement container has started. Safari is still pointed at the Raspberry Pi address that worked for the original container.

Before you refresh, do you think a running container alone is enough to keep the same page reachable?

  • Switch back to Safari from earlier.
  • Refresh http://<PI_IP>:8080.

You should see that the NGINX welcome page no longer loads. This browser failure is the intended result.

What Did This Failure Prove?

The container started successfully, but no published route now carries TCP traffic from host port 8080 into the container. The failed refresh separates process state from network reachability.

Compare process state and port publishing

Docker reports process state separately from published port mappings. Comparing both views reveals whether the web server stopped or its external route disappeared.

Before you run the checks, can a container be Up while its webpage remains unreachable from another computer?

  • Check the replacement container's running state by running:
docker ps

What Does the Container List Prove?

  • The customer-web container appears as Up, which proves that its process is running.
  • The port details show 80/tcp without a host-port mapping, which explains why the Raspberry Pi exposes no route on port 8080.
  • Inspect the container's published mappings by running:
docker port customer-web

What Does the Empty Result Mean?

This command lists the published mappings for customer-web. Returning to the terminal prompt without a mapping confirms that container port 80/tcp has no published host port.

Seeing a Different Result?

  • Confirm that you removed the original customer-web container before creating the replacement if a host-port mapping still appears.
  • Review the container creation output for a startup failure if customer-web is missing from the running container list.
  • Check that you recreated the container from nginx:1.30.6 without adding a publishing option.

Ask for help: Help me compare my running container state with its published port mappings.

That is a strong diagnostic win: customer-web is alive while its LAN route is absent. Next, you'll restore the route on the Raspberry Pi's selected LAN address.

Restore LAN Port Publishing

The active SSH session still proves that your Raspberry Pi is reachable from the Mac. Your previous checks isolated the failure to Docker port publishing.

In this step, you'll replace the isolated customer-web container with a published NGINX container. The specific mapping restores access through the Raspberry Pi LAN address.

In this step, get ready to:
  • Confirm that the Raspberry Pi remains reachable through the active SSH session.
  • Replace the isolated container with one bound to <PI_IP>:8080.
  • Verify the restored customer web service from Safari.
Confirm host and process health

A running container confirms process health. The open SSH session confirms host reachability.

  • Switch back to the Apple Terminal window that contains the active SSH session.
  • Confirm the current container status by running:
docker ps

What does this check prove?

  • The command asks the Docker daemon for its running containers.
  • The Up status proves that NGINX is still running inside customer-web.
  • The exposed 80/tcp entry identifies the container port without creating a host mapping.

You should see customer-web with an Up status. Its ports entry shows 80/tcp without a host-port mapping.

Container missing from the list?

  • Check that the terminal prompt still belongs to the Raspberry Pi through your active SSH session.
  • Confirm that you entered the container name as customer-web.

Help me diagnose why customer-web is missing from the running container list.

Recreate the container with a LAN binding

Port publishing creates a route from a Raspberry Pi host port to a container port. A host address in the mapping limits that route to the recorded LAN IPv4 address.

Removing this container is safe. The local nginx:1.30.6 image remains available for its replacement.

  • Remove the isolated customer-web container by running this command:
docker rm -f customer-web

What does this command do?

The command force-removes the running container named customer-web. The downloaded NGINX image stays on the Raspberry Pi.

You should see customer-web in the terminal output. That name confirms the isolated container was removed.

Container not removed?

  • Check that the container name is exactly customer-web.
  • Confirm that the Docker daemon still responds in the active SSH session.

Help me remove the existing customer-web container safely.

  • Start the replacement container with the recorded LAN address by running:
docker run --name customer-web -d -p <PI_IP>:8080:80 nginx:1.30.6

How does this restore the route?

  • The --name customer-web option gives the replacement container the original service name.
  • The -d option runs the container in the background.
  • The -p <PI_IP>:8080:80 option publishes host port 8080 on the recorded LAN address. Requests arriving there are sent to container port 80.
  • The nginx:1.30.6 value selects the local versioned image.

You should see a container identifier in the terminal. That risky swap is complete because the replacement container now holds the intended LAN binding.

Container fails to start?

  • Check that <PI_IP> matches the Raspberry Pi IPv4 address recorded earlier.
  • Confirm that the mapping is exactly <PI_IP>:8080:80.
  • Verify that the image name is exactly nginx:1.30.6.

Help me diagnose why the replacement customer-web container did not start with its LAN binding.

Verify the mapping and welcome page

Docker's port inspection reports the translation between the container endpoint and the Raspberry Pi endpoint. The browser test proves that a different device can use that translation.

Before you inspect the mapping, which Raspberry Pi address do you expect Docker to report for container port 80?

  • Inspect the published mapping by running:
docker port customer-web

How do you read the mapping?

  • The left side identifies container port 80/tcp.
  • The right side identifies the Raspberry Pi LAN address with host port 8080.
  • The arrow shows that traffic moves from the published host endpoint to the container endpoint.

You should see 80/tcp -> <PI_IP>:8080. This proves that Docker published the web service specifically on the recorded LAN address.

  • Switch back to the Safari tab from the previous step.
  • Enter http://<PI_IP>:8080 in the address bar.
  • Press Return to load the page.

You'll see the NGINX welcome page again. That page proves the complete path from the Mac to the container works again.

Welcome page still unavailable?

  • Check that Safari uses the exact recorded value for <PI_IP>.
  • Compare the reported mapping with 80/tcp -> <PI_IP>:8080.
  • Confirm that the active SSH session still responds before repeating the browser check.

Help me diagnose why Safari cannot reach the NGINX welcome page after restoring the LAN port mapping.

Your customer web service is reachable across the LAN again. Next, you'll inspect its request logs and define how it restarts.

Check Logs and Restart Behavior

Dein NGINX-Webdienst ist wieder über die LAN-Adresse des Raspberry Pi erreichbar. Jetzt prüfst du, ob er sich auch zuverlässig betreiben lässt.

Im Betrieb brauchst du sichtbare Anfragen. Eine definierte Wiederanlaufregel macht den Neustart kontrollierbar.

In this step, get ready to:
  • Browseranfragen in den Containerlogs erkennen.
  • Eine Wiederanlaufregel für den Webdienst festlegen.
  • Den Webdienst nach einem kontrollierten Neustart erneut erreichen.
Browseranfragen in den Logs prüfen

Die Logs eines Docker-Containers zeigen Startinformationen und eingehende Anfragen. Jeder Aufruf aus Safari hinterlässt dadurch eine sichtbare Spur.

  • Wechsle in Safari zur bereits geöffneten Seite unter http://<PI_IP>:8080 zurück.
  • Aktualisiere die Seite dreimal.
  • Wechsle zur offenen SSH-Sitzung zurück.
  • Lies die Containerlogs durch Ausführen dieses Befehls:
docker logs customer-web

Was zeigen die Containerlogs?

  • Der Log-Befehl ruft die vom Container ausgegebenen Informationen ab.
  • Die Startinformationen zeigen den Beginn des laufenden NGINX-Prozesses.
  • Die neueren Einträge stammen von deinen Browseranfragen aus Safari.

Du siehst die Startinformationen des Webservers. Darunter siehst du Einträge für deine Browseranfragen.

Keine Browseranfragen sichtbar?

  • Aktualisiere die geöffnete NGINX-Seite in Safari erneut.
  • Führe den Log-Befehl danach noch einmal in der offenen SSH-Sitzung aus.
  • Kontrolliere, dass Safari weiterhin http://<PI_IP>:8080 verwendet.

Bitte um Hilfe: Hilf mir herauszufinden, warum meine Safari-Aufrufe nicht in den Containerlogs erscheinen.

Restart Policy festlegen

Eine Restart Policy legt fest, wie Docker nach einem Containerstopp oder einem Daemon-Neustart reagiert. Die Einstellung unless-stopped lässt den Container wieder anlaufen, solange du ihn nicht absichtlich gestoppt hast.

  • Setze die Restart Policy des laufenden Containers durch Ausführen dieses Befehls:
docker update --restart=unless-stopped customer-web

Was ändert dieser Befehl?

  • Die Option --restart=unless-stopped weist Docker an, den Container nach einem ungeplanten Stopp wieder zu starten.
  • Docker übernimmt die neue Restart Policy sofort für den laufenden Container.
  • Ein absichtlich gestoppter Container bleibt nach einem Neustart des Docker-Daemons gestoppt.

Damit ist ein wichtiger Betriebsschritt geschafft: Dein Container verwendet jetzt die Restart Policy unless-stopped.

Wurde die Restart Policy nicht gesetzt?

  • Prüfe die Schreibweise von --restart=unless-stopped.
  • Prüfe den Containernamen customer-web.
  • Vergewissere dich, dass die offene SSH-Sitzung weiterhin mit dem Raspberry Pi verbunden ist.

Bitte um Hilfe: Hilf mir herauszufinden, warum Docker die Restart Policy für meinen Container nicht aktualisiert.

Container kontrolliert neu starten

Ein kontrollierter Neustart prüft die Wiederanlaufregel unter realen Bedingungen. Danach müssen sowohl der Containerstatus als auch die Webseite wieder verfügbar sein.

Überlege vor dem Neustart kurz, ob der Container danach wieder als laufend erscheinen wird.

  • Starte den Container neu und rufe anschließend die Liste der laufenden Container durch Ausführen dieser Befehle ab:
docker restart customer-web
docker ps

Was prüfen diese Befehle?

  • Der erste Befehl stoppt den benannten Container kontrolliert und startet ihn erneut.
  • Der zweite Befehl listet die aktuell laufenden Container auf.
  • Der Status Up bestätigt, dass der NGINX-Prozess nach dem Neustart wieder läuft.

Du siehst customer-web nach dem Neustart in der Containerliste. In der Statusspalte erscheint Up.

  • Wechsle zur bereits geöffneten NGINX-Seite in Safari zurück.
  • Aktualisiere die Seite unter http://<PI_IP>:8080.

Die NGINX-Willkommensseite wird erneut geladen. Der entscheidende Betriebscheck ist geschafft: Dein Webdienst bleibt nach einem kontrollierten Containerneustart vom Mac erreichbar.

Webseite nach dem Neustart nicht erreichbar?

  • Prüfe in der Containerliste, ob customer-web als Up erscheint.
  • Kontrolliere, dass Safari weiterhin http://<PI_IP>:8080 verwendet.
  • Prüfe in der offenen SSH-Sitzung, ob die Verbindung zum Raspberry Pi noch aktiv ist.

Bitte um Hilfe: Hilf mir zu prüfen, warum der NGINX-Webdienst nach dem Containerneustart nicht mehr erreichbar ist.

Secret mission

Einen Portkonflikt lösen

Erzeuge einen echten Konflikt um Port 8080 auf deinem Raspberry Pi. Leite aus der Fehlermeldung eine Lösung ab und betreibe anschließend einen zweiten NGINX-Webdienst auf Port 8081.

Clean Up Your Resources

Clean Up Your Resources

Wähle zwischen Behalten, Pausieren oder Löschen deiner lokalen Webdienste.

Dein Raspberry Pi benötigt nur Strom sowie Netzwerkzugang. Cloud-Kosten entstehen nicht.

Verwendete Ressourcen:

  • Ein laufender Docker-Container namens customer-web mit der NGINX-Willkommensseite unter http://<PI_IP>:8080 sowie der Restart Policy unless-stopped.
  • Ein laufender Testcontainer namens customer-web-test mit einer zweiten Willkommensseite unter http://<PI_IP>:8081.
  • Das lokal gespeicherte Docker Official Image nginx:1.30.6.

Keep everything running

Keine Aktion nötig. Wähle diese Option, wenn du mit den beiden Webdiensten weiterarbeiten möchtest.

  • Lass customer-web auf Port 8080 weiterlaufen.
  • Lass customer-web-test auf Port 8081 weiterlaufen.
  • Behalte das lokale Image nginx:1.30.6 für spätere Containerstarts.
  • Schließe deine SSH-Sitzung bei Bedarf. Die Container laufen unabhängig von der geöffneten Terminalverbindung weiter.

Pause - I'll come back to this later

Mit dieser Option stoppst du beide Webdienste. Die Container sowie das Image bleiben auf dem Raspberry Pi gespeichert.

  • Stoppe beide Projektcontainer über die aktive SSH-Sitzung mit diesen Befehlen:
docker stop customer-web
docker stop customer-web-test

Was bewirken die Stopp-Befehle?

Die Befehle beenden die laufenden Prozesse kontrolliert. Docker behält beide Container für eine spätere Verwendung.

Der Container customer-web bleibt nach diesem manuellen Stopp trotz der Policy unless-stopped gestoppt.

Im Terminal siehst du die Namen beider Container. Damit bestätigt Docker den kontrollierten Stopp.

  • Aktualisiere http://<PI_IP>:8080 sowie http://<PI_IP>:8081 in Safari.

Safari kann die beiden Willkommensseiten jetzt nicht mehr laden. Das bestätigt, dass beide Webdienste pausiert sind.

Lädt eine Seite weiterhin?

Prüfe im Terminal, ob Docker nach jedem Stopp-Befehl den passenden Containernamen ausgegeben hat. Aktualisiere danach die entsprechende Browseradresse erneut.

Hilf mir zu prüfen, warum einer meiner gestoppten Docker-Container weiterhin erreichbar ist.

Delete - I don't want to use this again

Das Löschen ist für die beiden Container endgültig. Dein Raspberry Pi sowie seine Netzwerkkonfiguration bleiben unverändert.

  • Entferne beide Projektcontainer sowie das lokale Image mit diesen Befehlen:
docker rm -f customer-web
docker rm -f customer-web-test
docker image rm nginx:1.30.6

Was entfernt diese Befehlsfolge?

  • Die ersten beiden Befehle stoppen die laufenden Projektcontainer und entfernen sie vom Docker-Host.
  • Der letzte Befehl entfernt die lokale Kopie des versionierten NGINX-Images.
  • Die Docker Engine sowie alle Netzwerkwerte des Raspberry Pi bleiben erhalten.

Im Terminal siehst du Bestätigungen für beide Containernamen sowie die entfernten Image-Daten. Damit sind alle Projektressourcen gelöscht.

  • Prüfe die Liste der laufenden Container mit diesem Befehl:
docker ps

Was prüft diese Kontrolle?

Docker zeigt standardmäßig nur laufende Container. Die Namen customer-web sowie customer-web-test dürfen deshalb nicht mehr in der Liste stehen.

  • Aktualisiere http://<PI_IP>:8080 sowie http://<PI_IP>:8081 in Safari.

Beide Adressen sind jetzt nicht mehr erreichbar. Dein Raspberry Pi stellt keinen der beiden Projekt-Webdienste mehr bereit.

Lässt sich das Image nicht entfernen?

Ein anderer Container kann das Image noch verwenden. Entferne keine unbekannten Container, bis du ihren Zweck geprüft hast.

Hilf mir herauszufinden, welcher Docker-Container mein NGINX-Image noch verwendet.

Nice Work!

Nice Work!

You made it work. Your Raspberry Pi now serves an NGINX welcome page to your Mac through Docker port publishing.

What you can now do:

  • Administer a Linux server from your Mac through SSH. Identify its IPv4 configuration from the active address, prefix length, gateway, and DNS server.
  • Deploy nginx:1.30.6 as a reachable web service by publishing its container port to the Raspberry Pi's LAN address. Load its welcome page from the Mac.
  • Diagnose a running but unreachable container by comparing SSH reachability, container status, and port mappings. Inspect request logs. Apply an unless-stopped restart policy. Confirm the web service returns after a controlled restart.
  • Secret Mission: Resolved a host-port conflict by placing customer-web-test on port 8081. Kept customer-web reachable on port 8080 while both services ran together.

Ready to quiz yourself?