Comment on Best way to dockerize a static website?

• jj4211@lemmy.world ⁨8⁩ ⁨months⁩ ago

  Because serving static files doesn’t really require any flexibility in web serving code.

  If your setup has an nginx or similar as a reverse proxy entry point, you can just tell it to serve the directory. Why bother making an entire new chroot and proxy hop when you have absolutely zero requirements beyond what the reverse proxy already provides. Now if you don’t have that entry point, fine, but at least 99% of the time I see some web server as initial arbiter into services that would have all the capability to just serve the files.

  source

  • possiblylinux127@lemmy.zip ⁨8⁩ ⁨months⁩ ago

    How will it scale though?

    source

    • smileyhead@discuss.tchncs.de ⁨8⁩ ⁨months⁩ ago

      My brother in Christ, serving a file through HTTP is exactly what Tim Berners-Lee invented in 1989.

      source
    • jj4211@lemmy.world ⁨8⁩ ⁨months⁩ ago

      For 90% of static site requirements, it scales fine. That entry point reverse proxy is faster at fetching content to serve via filesystem calls than it is at making an http call to another http service. For self hosting types of applications, that percentage guess to go 99.9%

      If you are in a situation where serving the files through your reverse proxy directly does not scale, throwing more containers behind that proxy won’t help in the static content scenario. You’ll need to do something like a CDN, and those like to consume straight directory trees, not containers.

      For dynamic backend, maybe. Mainly because you might screw up and your backend code needs to be isolated to mitigate security oopsies. Often it also is useful to manage dependencies, but that facet is less useful for golang where the resulting binary is pretty well self contained except maybe a little light usage of libc.

      source