Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A tiny Docker image to serve static websites

lipanski.com

Post reply on HN
Print view View original

51–60 of 156 posts

Re: A tiny Docker image to serve static websites

#51

Post by KronisLV »

> My first attempt uses the small alpine image, which already packages thttpd:

  # Install thttpd
  RUN apk add thttpd
Wouldn't you want to use the --no-cache option with apk, e.g.:

  RUN apk add --no-cache thttpd
It seems to slightly help with the container size:

  REPOSITORY       TAG       IMAGE ID       CREATED          SIZE
  thttpd-nocache   latest    4a5a1877de5d   7 seconds ago    5.79MB
  thttpd-regular   latest    655febf218ff   41 seconds ago   7.78MB
It's a bit like cleaning up after yourself with apt based container builds as well, for example (although this might not always be necessary):

  # Apache web server
  RUN apt-get update && apt-get install -y apache2 libapache2-mod-security2 && apt-get clean && rm -rf /var/lib/apt/lists /var/cache/apt/archives
But hey, that's an interesting goal to pursue! Even though personally i just gave up on Alpine and similar slim solutions and decided to just base all my containers on Ubuntu instead: https://blog.kronis.dev/articles/using-ubuntu-as-the-base-fo...

Re: A tiny Docker image to serve static websites

#52

Post by marginalia_nu »

mr-karan wrote: post #48

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…

The less resources you use from your system, the more things you can do with your system.

Re: A tiny Docker image to serve static websites

#53

Post by marginalia_nu »

throwanem wrote: post #14
memish wrote: post #8

Earlier quoted context omitted.

Wouldn't removing Docker entirely be a good optimization?

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

Building simpler systems allows you to save on all three.

Re: A tiny Docker image to serve static websites

#54

Post by kube-system »

jamal-kumar wrote: post #19
kube-system wrote: post #9

Earlier quoted context omitted.

Docker adds other value to the lifecycle of your deployment. An "optimization" where you're removing value is just a compromise. Otherwise we'd all run our static sites on UEFI.

yeah see some of us still do this on OSes that haven't turned into a giant bloated hodgepodge of security theatre and false panacea software. docker has dead whale on the beach vibes. what value does it offer to those of us who have moved on from the mess linux is becoming?

I’m not suggesting it has value to everyone. I’m suggesting it has value to the people who see value in it.

Re: A tiny Docker image to serve static websites

#56

Post by SahAssar »

somenewaccount1 wrote: post #17
tyingq wrote: post #11

Earlier quoted context omitted.

And it does https/tls, where thttpd does not.

I'm confused how the author considers thttpd more 'battle tested' if it doesn't resolve https. Either way though, it's a great article I'm glad the author took to write. His docker practices are wonderful, wish more engineers would use them.

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.

Re: A tiny Docker image to serve static websites

#57

Post by jart »

kube-system wrote: post #9
memish wrote: post #8

Earlier quoted context omitted.

Wouldn't removing Docker entirely be a good optimization?

Docker adds other value to the lifecycle of your deployment. An "optimization" where you're removing value is just a compromise. Otherwise we'd all run our static sites on UEFI.

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.

Re: A tiny Docker image to serve static websites

#58

Post by marginalia_nu »

mg wrote: post #23

For static websites, is there any reason not to host them on GitHub? Since GitHub Pages lets you attach a custom domain, it seems like the perfect choice. I would expect their CDN to be pretty awesome. And updating the website with a simple git push seems convenient.

Wanting to own your own web presence is reason not to host them on GitHub.

For static websites, CDNs are largely unnecessary. My potato of a website hosted from a computer in my living room has been on the front page of HN several times without as much as increasing its fan speed.

It took Elon Musk tweeting a link to one of my blog posts before it started struggling to serve pages. I think it ran out of file descriptors, but I've increased that limit now.

Re: A tiny Docker image to serve static websites

#59

Post by jamal-kumar »

kube-system wrote: post #54
jamal-kumar wrote: post #19

Earlier quoted context omitted.

yeah see some of us still do this on OSes that haven't turned into a giant bloated hodgepodge of security theatre and false panacea software. docker has dead whale on the beach vibes. what value does it offer to those of us who have moved on from the mess linux is becoming?

I’m not suggesting it has value to everyone. I’m suggesting it has value to the people who see value in it.

I'm super curious to know what the value to people who see that happens to be. It's serving static websites, why do I need to wrap THAT of all things in a container?

Really, enlighten me

Re: A tiny Docker image to serve static websites

#60

Post by throwaway894345 »

mr-karan wrote: post #48

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.
Post reply on HN