Show HN: #!/usr/bin/env docker run

Was ist #!?

• #! (ausgesprochen als shebang) ist eine Konvention unter Unix, die hauptsächlich für Skriptsprachen wie Python oder Bash verwendet wird
• Vorgestellt wird ein Beispiel, wie dies genutzt werden kann, um eine Anwendungsbereitstellung für Cross-Platform-Umgebungen und verschiedene Linux-Distributionen als einzelne Datei zu paketieren
• Das Beispiel-Dockerfile konfiguriert einen Full-Stack-Server mit Backend, Datenbank und UI in einer einzigen Datei
• Ähnlich wie Cosmopolitan Libc, aber für das Paketieren von Anwendungen

Warum sollte man das verwenden?

• Warum sollte man es nicht verwenden?

Ist es sicher?

• Wahrscheinlich nicht.

Sollte man es verwenden?

• Wenn man möchte, kann man es verwenden.

Ist die Performance gut?

• Möglich.

Ist es wartbar?

• Nein.

Funktioniert es?

• Ja.

Wie führt man es aus?

• Ausführbar mit folgendem Befehl: chmod +x ./Dockerfile ./Dockerfile
• Danach http://127.0.0.1:8080 aufrufen.

Meinung von GN⁺

• Dieser Artikel stellt eine ungewöhnliche Methode vor, mit #! (shebang) einen Full-Stack-Server in einem einzelnen Dockerfile zu paketieren.
• Sie weckt technische Neugier und zeigt einen neuen Ansatz für traditionelle Methoden der Anwendungsbereitstellung.
• In Bezug auf Wartbarkeit und Stabilität ist dieser Ansatz nicht empfehlenswert, kann aber für Entwickler, die sich für experimentelle und innovative Projekte interessieren, eine interessante Alternative sein.

[minhoryang]

Um ein Heredoc wie <<EOF zu verwenden, ist am Anfang des Dockerfiles # syntax = docker/dockerfile:1.4.0 erforderlich. Überraschenderweise wird sogar syntax aus der Docker-Registry bezogen.

[pmc7777]

Wow ... das ist mein größter mentaler Schock dieses Jahres lololololol

[arfwene]

Ein interessanter Ansatz.

[bbulbum]

Haha … wirklich originell.

[sagee]

Wow … das ist wirklich originell. Fast so, als hätte man die Kombination aus Bewehrungsstahl und Beton entdeckt … na ja, das ist etwas übertrieben, aber ich finde es gut.
Dass dieser kleine Trick auf diese Weise funktioniert, weil #! ausgerechnet in einer Dockerfile wegen des # als Kommentarzeichen durchgeht …
Künftig sollte ich das wohl in die Dockerfile packen statt in eine separate Datei wie build-run-test.sh.

[xguru]

Das ist ja interessant. Haha. "Warum sollte man es nicht verwenden?"

• Cosmopolitan libc - Build-Once Run-Anywhere C
• Cosmopolitan v1.0 veröffentlicht
• Cosmopolitan v2.0 veröffentlicht
• Cosmopolitan v3.0 - "Build Once Anywhere, Run Anywhere C/C++"

[GN⁺]

Hacker-News-Kommentare

• Beispiel für die Verwendung eines nix-shell-Shebangs

  • Es wird erklärt, wie man mit einem nix-shell-Shebang ein ausführbares Skript erstellt, das alle benötigten Abhängigkeiten enthält.
  • Es wird ein Beispiel für ein Python-Skript gegeben, das Bilder auf 50 % ihrer Größe verkleinert.
  • Wenn man dem Skript Ausführungsrechte gibt (chmod +x), wird es zu einer ausführbaren Datei mit den festgelegten Abhängigkeiten.

• Die Option -S / --split-string von /usr/bin/env

  • Erläuterung der Option -S, die seit GNU Coreutils 8.30 verfügbar ist.
  • Diese Option beruht auf nicht standardisiertem Verhalten und funktioniert nur auf Betriebssystemen, die den gesamten Text als Argumente der ausführbaren Datei behandeln.
  • Auf den meisten modernen GNU/Linux-Systemen, BSDs und macOS funktioniert dieses nicht standardisierte Verhalten.

• Docker und Architekturkompatibilität

  • Es wird darauf hingewiesen, dass Docker auf anderen Plattformen als Linux tatsächlich eine Linux-VM benötigt.
  • Linux-Container sind großartig, aber Docker ist nur schwer als wirklich plattformübergreifende Lösung zu betrachten.

• Meinungen zu Single-File-Anwendungen

  • Die Idee, eine vollständige Anwendung in einer einzigen Datei zu bündeln, wird gelobt.
  • Es gibt Kritik an der Komplexität von Docker und Zweifel daran, Container für Sicherheit oder Versionsverwaltung zu verwenden.
  • Es wird gefragt, ob WebAssembly (WASM) diese Probleme lösen könnte.

• Podman und bubblewrap als Docker-Alternativen

  • Es wird erwähnt, dass die Verwendung von Podman oder bubblewrap anstelle von Docker besser sein könnte.
  • Podman ist etwas stärker von bestimmten Distributionen abhängig, und bubblewrap ist auf manchen Distributionen wegen Sicherheitsproblemen möglicherweise nicht enthalten.

• Single-File-Projekte mit heredocs

  • Auch ohne cleveren Shebang kann man mit heredocs Single-File-Projekte für jede Sprache oder Infrastruktur erstellen.
  • Es wird ein Beispiel derselben App gegeben, die als Bash-Skript verpackt ist.

• Kritik an der Fixierung auf „Single File“

  • Es wird darauf hingewiesen, dass man statt alles in eine einzelne Datei zu packen auch ein Verzeichnis für eine in sich geschlossene Anwendung verwenden kann.
  • Es wird erwähnt, dass eine einzelne Datei nicht zwangsläufig der bessere Weg ist.

• Das Muster selbstkonsumierender Skripte

  • Es wird erklärt, wie man andere Interpreter-Skripte in ein Skript einbettet und mit sed das Skript zwischen Tags extrahiert.
  • Es wird eingeräumt, dass solche Methoden manchmal sehr nützlich sein können, aber auch komplex werden können.

• Verwendung von guix shell an der Shebang-Position

  • Es wird ein aus dem Guix-Handbuch übernommenes Beispiel mit guix shell gezeigt.
  • Es funktioniert zusammen mit einer Manifestdatei, die komplexere Umgebungen festlegt.

• Sich selbst bauendes und ausführendes Dockerfile

  • Es werden eine Beschreibung und ein Beispielcode für ein sich selbst bauendes und ausführendes Dockerfile vorgestellt, das im November 2021 geschrieben wurde.