Live data from Hacker News

A tiny Docker image to serve static websites

lipanski.com

121–130 of 156 posts

Re: A tiny Docker image to serve static websites

#121
post #44

Earlier quoted context omitted.

It shows up as a proper 301 when I load up the URL in Firefox. The question is, how?

One of the Jekyll plugins that GH Pages supports[0] is jekyll-redirect-from, which lets you put a `redirect_to` entry in a page's front matter. [0]: https://pages.github.com/versions/

I found this example of another repo that is using the same trick: https://github.com/kotokaze/kotokaze.github.io

    ~ % curl -i 'https://kotokaze.github.io/'
    HTTP/2 301 
    server: GitHub.com
    content-type: text/html
    permissions-policy: interest-cohort=()
    location: http://github.kotokaze.net/

Re: A tiny Docker image to serve static websites

#122
post #118

I love it! Can you add SSL though? Does it support gzip compression? What about Brotli? I like that it's small and fast so in addition to serving static files can it act as a reverse proxy? What about configuration? I'd like to be able to server multiple folders instead of just one? Where can I submit a feature request ticket?

I think is not precisely an active project, but it's open on GitHub[1], I guess we can try to open issues there.

- [1] https://github.com/lipanski/docker-static-website

Re: A tiny Docker image to serve static websites

#123
post #118

I love it! Can you add SSL though? Does it support gzip compression? What about Brotli? I like that it's small and fast so in addition to serving static files can it act as a reverse proxy? What about configuration? I'd like to be able to server multiple folders instead of just one? Where can I submit a feature request ticket?

https://github.com/weihanglo/sfz

check this out

Re: A tiny Docker image to serve static websites

#124
post #57

Earlier quoted context omitted.

Redbean supports UEFI too. Although we haven't added a bare metal implementation of berkeley sockets yet. Although it's on the roadmap for the future.

oh wow are you justine? i've been meaning to ask you this for a decade. whatever happened to when you wrote a blog with insanely irritating serifs that connected certain letters together? what was the rationale behind that? never seen it since I'm insanely impressed by APE and redbean by the way, blows OP out of the water!

Oh you mean the blog with the long s? I was reading a lot of books at the time that were written before 1800 and I found it so fascinating how different typography was back then. I found a font I could pay for called Quant that did a really good job reproducing archaic ligatures and the long s, so I used it on a blog for a short period of time. Sadly it got negative feedback. So lately I've been focusing on https://justine.lol/ which uses Roboto. I'm glad to hear you're enjoying it!

Re: A tiny Docker image to serve static websites

#125

Earlier quoted context omitted.

The term 'battle tested' has nothing to do with amount of features, it's about how proven the stability and/or security of the included features included are. The term also usually carries a heavy weight towards older systems that have been used in production for a long time since those have had more time to weather bugs that are only caught in real-world use.

Also, https is often dealt with on a different server (load balancer for example).

Yes but it's nice to have the SSL built-in for when you want it. Web servers like Varnish and thttpd take a really hard stance on the issue, where they don't want to touch the crypto at all. Honestly, I don't blame them because implementing SSL is prodigiously technical and emotional. One of the things I do is I offer a file called redbean-unsecure.com that has zero-security baked-in so that folks who love redbean but want to handle the security separately themselves can do so. But like I said when we don't have strong opinions on separation of concerns, having a fast snappy tiny zero config SSL is nice.

Re: A tiny Docker image to serve static websites

#126

Well, this will definitely serve an unchanging static website. But unchanging static websites are just archives. Most static websites have new .html and other files added on whim regularly.

You can just mount an external volume on top of /home/static to and be able to change the files that way. But for a single-page-app I think it works great to be able to version the entire site in the docker image tag.

Re: A tiny Docker image to serve static websites

#127

While this is remarkably a good hack and I did learn quite a bit after reading the post, I'm simply curious about the motivation behind it? A docker image even if it's a few MBs with Caddy/NGINX should ideally be just pulled once on the host and sit there cached. Assuming this is OP's personal server and there's not much churn, this image could be in the cache forever until the new tag is pushed/pulled. So, from a "h…

It gets pulled once per host, but with autoscaling hosts come and go pretty frequently. It's a really nice property to be able to scale quickly with load, and small images tend to help with this in a variety of ways (pulling but also instantiating the container). Most sites won't need to scale like this; however, because one or two hosts is almost always sufficient for all traffic the site will ever receive.

could be very useful in serverless space as lambda do support container image now. the image will be pulled much more often.

Re: A tiny Docker image to serve static websites

#128
post #16

Earlier quoted context omitted.

In terms of CPU cycles and disk space, maybe. In terms of engineer cycles, absolutely not. Which costs more?

Hmm, a SCP shell script on my laptop, prompting my SSH key's password and deploying the site to the target machine? Or a constantly-updating behemoth, running as root, installing packages from yet another unauditable repository chain?

The first option is something custom that you had to write yourself and remember how to use years later, or explain how to use to others

The second option is standardized and usually the same 1 or 2 commands to run anywhere

Re: A tiny Docker image to serve static websites

#129
I do something similar at work for internal only static docs.

The image is a small container with an http daemon. It gets deployed as a statefulset and I mount a volume into the pod to store the static pages (they don't get put into the image). Then I use cert-manager and an Istio ingress gateway to add TLS on top.

Updating the sites (yes, several at the same domain) is done via kubectl cp, which is not the most secure but good enough for our team. I could probably use an rsync or ssh daemon to lock it down further, but I have not tried that.

Re: A tiny Docker image to serve static websites

#130
post #118

I love it! Can you add SSL though? Does it support gzip compression? What about Brotli? I like that it's small and fast so in addition to serving static files can it act as a reverse proxy? What about configuration? I'd like to be able to server multiple folders instead of just one? Where can I submit a feature request ticket?

https://github.com/weihanglo/sfz check this out

This seems to be intended for local host usage exclusively. Is anyone using this for public or even internal http hosting?
Post reply on HN