I’m currently researching the best method for running a static website from Docker.

The site consists of one single HTML file, a bunch of CSS files, and a few JS files. On server-side nothing needs to be preprocessed. The website uses JS to request some JSON files, though. Handling of the files is doing via client-side JS, the server only need to - serve the files.

The website is intended to be used as selfhosted web application and is quite niche so there won’t be much load and not many concurrent users.

I boiled it down to the following options:

  1. BusyBox in a selfmade Docker container, manually running httpd or The smallest Docker image …
  2. php:latest (ignoring the fact, that the built-in webserver is meant for development and not for production)
  3. Nginx serving the files (but this)

For all of the variants I found information online. From the options I found I actually prefer the BusyBox route because it seems the cleanest with the least amount of overhead (I just need to serve the files, the rest is done on the client).

Do you have any other ideas? How do you host static content?

  • arran 🇦🇺English
    5•9 months ago

    The busybox one seems great as it comes with shells. php looks like it would add some issues.

    Personally since I use go, I would create a go embedded app, which I would make a deb, rpm, and a dockerfile using “goreleaser”

    package main

import (
	"embed"
	"net/http"
)

//go:embed static/*
var content embed.FS

func main() {
	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		// Serve index.html as the default page
		http.ServeContent(w, r, "index.html", nil, content)
	})

	// Serve static files
	http.Handle("/static/", http.StripPrefix("/static/", http.FileServer(http.FS(content))))

	// Start the server
	http.ListenAndServe(":8080", nil)
}

    Would be all the code but allows for expansion later. However the image goreleaser builds doesn’t come with busybox on it so you can’t docker exec into it. https://goreleaser.com/customization/docker/

    Most of the other options including the PHP one seem to include a scripting language or a bunch of other system tools etc. I think that’s overkill

    • @[email protected]English
      2•9 months ago

      I would consider the lack of a shell a benefit in this scenario. You really don’t want the extra attack surface and tooling.

      Considering you also manage the host, if you want to see what’s going on inside the container (which for such a simple image can be done once while building it the first time more likely), you can use unshare to spawn a bash process in the container namespaces (e.g., unshare -m -p […] -t PID bash, or something like this - I am going by memory).