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.
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?
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
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).
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
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”
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 execinto 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
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).