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?

  • CameronDev@programming.devEnglish
    361·
    9 months ago

    Just go nginx, anything else is faffing about. Busybox may not be security tested, so best to avoid on the internet. Php is pointless when its a static site with no php. Id avoid freenginx until its clear that it is going to be supported. There is nothing wrong with stock nginx, the fork is largely political rather than technical.

    • 𝘋𝘪𝘳𝘬@lemmy.mlOPEnglish
      4·
      9 months ago

      Php is pointless when its a static site with no php

      Absolutely, but it has a built-in webserver that can serve static files, too (I constantly use that in my dev environment).

      But I guess you’re mostly right about just using Nginx. I already have multiple containers running it, though. Most of them just serving static files. But it’s ca. 50 megabytes compressed size each container just for Nginx alone.

      • CameronDev@programming.devEnglish
        6·
        9 months ago

        Having PHP installed is just unnecessary attack surface.

        Are you really struggling for space that 50mb matters? An 8gb usb can hold thar 160x?

        • 𝘋𝘪𝘳𝘬@lemmy.mlOPEnglish
          1·
          9 months ago

          Having PHP installed is just unnecessary attack surface.

          Yes! Especially running it’s built-in webserver outside your dev environment. They “advertise” doing so in their Docker packages documentation, though. Every project without PHP is a good project. It’s still an option - at least technically.

          Are you really struggling for space that 50mb matters?

          In a way, yes. I just want to optimize my stuff as much as possible. No unneeded tools, no overhead, a super clean environment, etc. Firing up another Nginx container just doesn’t feel right anymore. (Even if it seems to be possible to manually “hack” file serving into NPM - which makes it a multi-use container serving various different sites and proxying requests.)

          The machine I use as docker host also has a pretty low-end CPU and measly 4 gigabytes of RAM. So every resource not wasted is a good resource.

          • CameronDev@programming.devEnglish
            21·
            9 months ago

            RAM is not the same as storage, that 50mb docker image isn’t going to require 50mb of ram to run. But don’t let me hold you back from your crusade :D

            • 𝘋𝘪𝘳𝘬@lemmy.mlOPEnglish
              1·
              9 months ago

              Thanks for educating me on basic computer knowledge! 🤣

              Applications need RAM, though. A full-fledged webserver with all the bells and whistles likely needs more ram than a specialized single-binary static file delivery server.

              • CameronDev@programming.devEnglish
                1·
                9 months ago

                Sorry, wasn’t meant to be condescending, you just seem fixated on file size when it sounds like RAM (and/or CPU?) is what you really want to optimise for? I was just pointing out that they arent necessarily correlated to docker image size.

                If you really want to cut down your cpu and ram, and are okay with very limited functionality, you could probably write your own webserver to serve static files? Plain http is not hard. But you’d want to steer clear of python and node, as they drag in the whole interpreter overhead.

                • 𝘋𝘪𝘳𝘬@lemmy.mlOPEnglish
                  1·
                  9 months ago

                  I care about anything. RAM usage, file size, etc. I’m a minimalist when it comes to software. Use as less of all resources as possible. After once writing a router in Python I thought I could do this in Lua, too, but never actually tried. Maybe this would be a nice weekend project?

                  Even if Nginx is the way to go, I currently experiment with SWS which was suggested here. Technical aspects aside: The software is actively developed and the maintainer provides Docker images on their own (easy for Deploying a container based on that) and a package for my distribution (easy for development testing).

                  • Pyrosis@lemmy.worldEnglish
                    1·
                    7 months ago

                    Well op look at it this way…

                    A single 50mb nginx docker image can be used multiple times for multiple docker containers.

      • lemmyvore@feddit.nlEnglish
        1·
        9 months ago

        Absolutely, but it has a built-in webserver that can serve static files, too (I constantly use that in my dev environment).

        How about Python? You can get an HTTP server going with just python3 -m http.server from the dir where the files are. Worth remembering because Python is super common and probably already installed in many places (be it on host or in containers).

        • 𝘋𝘪𝘳𝘬@lemmy.mlOPEnglish
          1·
          9 months ago

          I once built a router in Python, but it was annoying. The much I like Python, the much I dislike coding in it. Just firing up a web server with it is no big deal, though.

          I was even thinking of node.js, but this comes with a whole different set of issues. It would allow for future extensions of the project on the server-side, though.