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

81–90 of 156 posts

Re: A tiny Docker image to serve static websites

#81

Post by adolph »

danuker wrote: post #15
kissgyorgy wrote: post #4

Redbean is just 155Kb without the need for alpine or any other dependency. You just copy the Redbean binary and your static assets, no complicated build steps and hundred MB download necessary. Check it out: https://github.com/kissgyorgy/redbean-docker

Wow! This is the Redbean which is an "Actually Portable Executable", or a binary that can run on a range of OSes (Linux, Windows, MacOS, BSDs). http://justine.lol/ape.html

Well worth a read:

I believe the best chance we have of [building binaries "to stand the test of time with minimal toil"], is by gluing together the binary interfaces that've already achieved a decades-long consensus, and ignoring the APIs. . . . Platforms can't break them without breaking themselves.

Re: A tiny Docker image to serve static websites

#83

Post by deberon »

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

Earlier quoted context omitted.

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

I actually found myself needing something like this a couple weeks ago. I use a self-hosted platform (cloudron.io) that allows for custom apps. I wanted to host a static blog on that server. Some people are happy to accept "bloat" if it does, in fact, make life easier in some way.

Re: A tiny Docker image to serve static websites

#85

Post by mise_en_place »

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

Earlier quoted context omitted.

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

Because you want a reproducible environment/runtime for that static server. Nix/NixOS takes it a step further, in that it provides not only a reproducible runtime environment, but a reproducible dev and build environment as well.

Re: A tiny Docker image to serve static websites

#86

Post by throwaway894345 »

mr-karan wrote: post #75
throwaway894345 wrote: post #60

Earlier quoted context omitted.

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.

I did mention that it's the OP's server which I presume isn't in an autoscale group. Even then, saving a few MBs in image size is the devops parlance of early optimisation. There's so much that happens in an Autoscale group before the instance is marked healthy to serve traffic, that an image pull of few MBs in the grand scheme of things is hardly ever any issue to focus on.

Yeah, like I said, I'm not defending this image in particular--most static sites aren't going to be very sensitive to autoscaling concerns. I was responding generally to your reasoning of "the host will just cache the image" which is often used to justify big images which in turn creates a lot of other (often pernicious) problems. To wit, with FaaS, autoscaling is highly optimized and tens of MBs can make a significant difference in latency.

Re: A tiny Docker image to serve static websites

#87

Post by mr-karan »

throwaway894345 wrote: post #86
mr-karan wrote: post #75

Earlier quoted context omitted.

I did mention that it's the OP's server which I presume isn't in an autoscale group. Even then, saving a few MBs in image size is the devops parlance of early optimisation. There's so much that happens in an Autoscale group before the instance is marked healthy to serve traffic, that an image pull of few MBs in the grand scheme of things is hardly ever any issue to focus on.

Yeah, like I said, I'm not defending this image in particular--most static sites aren't going to be very sensitive to autoscaling concerns. I was responding generally to your reasoning of "the host will just cache the image" which is often used to justify big images which in turn creates a lot of other (often pernicious) problems. To wit, with FaaS, autoscaling is highly optimized and tens of MBs can make a significa…

Noted, that makes sense. Thanks!

Re: A tiny Docker image to serve static websites

#88

Post by danuker »

throwanem wrote: post #77
danuker wrote: post #72

Earlier quoted context omitted.

> what, a hundred lines? A couple hundred? You have to deal with different repos for different distros, I expect, adding repositories for deps that aren't in the distro repo, any number of weird edge cases Well, here is where I must thank you. Thank you for replying to me, and giving me a real reason to look at this ecosystem. My personal deployment script is really just one SCP command - it copies the new version of…

Don't worry about the arrogance - I was much the same myself, once upon a time. :) It's worth taking thought to ensure you don't let it run too far away with you, of course, but I'd be a fool to judge harshly in others a taste of which I once drank deep myself. And hey, what the hell - did anyone ever change the world without being at least a little arrogant? There are other ways to dare what seems impossible to achi…

Thanks again. Get well quick!

BTW, your CV is down, again due to relying on hidden complexity (Stack Exchange Jobs is extinct). You made me curious so I stalked you a bit :D

https://aaron-m.com/about

Re: A tiny Docker image to serve static websites

#89

Post by lolinder »

danuker wrote: post #29
somenewaccount1 wrote: post #22

Earlier quoted context omitted.

You forgot the step where you had to provision that server to run the software and maintain all the systems security updates on the live running server, and that server requires all the same maintenance, with or without docker. And if you fuck it up, better call the wife and cancell Sunday plans because you forgot how it all gets installed and ......yeah, just use docker :p

Debian offers unattended upgrades: https://wiki.debian.org/UnattendedUpgrades And security updates, as you said, are needed regardless of whether you run Docker on top. I think Docker is a needless complexity and security risk.

Security updates are only needed on the OS level if you're running Docker on bare metal or a VPS. If you're running Docker in a managed container or managed Kubernetes service such as ECS/EKS, you only need to update the Docker image itself, which is as simple as updating your pip/npm/maven/cargo/gem/whatever dependencies.

I see two main places where Docker provides a lot of value: in a large corp where you have massive numbers of developers running diverse services on shared infrastructure, and in a tiny org where you don't have anyone who is responsible for maintaining your infrastructure full time. The former benefits from a standardized deployment unit that works easily with any language/stack. The latter benefits from being able to piggy-back off a cloud provider that handles the physical and OS infrastructure for you.

Re: A tiny Docker image to serve static websites

#90

Post by 0xbadcafebee »

If you use "-Os" instead of "-O2", you save 8kB!

However, Busybox also comes with an httpd... it may be 8.8x bigger, but you also get that entire assortment of apps to let you troubleshoot, run commands in an entrypoint, run commands from the httpd/cgi, etc. I wouldn't run it in production.... but it does work :)

Post reply on HN