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

91–100 of 156 posts

Re: A tiny Docker image to serve static websites

#91

Post by throwanem »

danuker wrote: post #88
throwanem wrote: post #77

Earlier quoted context omitted.

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

Hahaha, that's perfect. I'll fix it when I get the chance, thanks again!

Re: A tiny Docker image to serve static websites

#93

Post by EnigmaCurry »

amanzi wrote: post #92

I assume the author would then publish this behind a reverse proxy that implements TLS? Seems like an unnecessary dependency, given that Docker is perfect for solving dependency issues.

That's certainly what I would do. I think its great that thttpd does not include a TLS dependency itself. Every once in awhile I find a project that forces their own TLS and its annoying to undo it.

Re: A tiny Docker image to serve static websites

#94

Post by spicybright »

marginalia_nu wrote: post #52
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.

Only matters if you're actually using those extra cycles or not. The majority of web servers hover at <10% CPU just waiting for connections.

Re: A tiny Docker image to serve static websites

#95

Post by pojzon »

Tbh the moment the author thought about hosting yourself anything to serve static pages -> it was already too much effort.

There are free ways to host static pages and extremely inexpensive ways to host static pages that are visited mullions of times per month using simply services built for that.

Re: A tiny Docker image to serve static websites

#96

Post by spicybright »

vorticalbox wrote: post #71
vanviegen wrote: post #46

Earlier quoted context omitted.

What value is that, for running such a simple piece of software?

A few off the top of my head. The ability to pull the image on to any machine without needing to clone the source files and build it. Smaller images mean faster pod starts when you auto scale.

You have to login to some docker repository anyways and know the series of commands to actually run it. Cloning a repo and running a shell script is probably a lot easier and faster than that.

What kind of work are you doing that requires really fast auto scaling? Is a few minutes to spin up a new instance really that cumbersome? Can you not signal for it to spin up a new instance a tiny bit earlier than when it's needed when you see traffic increases?

Re: A tiny Docker image to serve static websites

#97

Post by [deleted] »

pojzon wrote: post #95

Tbh the moment the author thought about hosting yourself anything to serve static pages -> it was already too much effort. There are free ways to host static pages and extremely inexpensive ways to host static pages that are visited mullions of times per month using simply services built for that.

[deleted]

Re: A tiny Docker image to serve static websites

#98

Post by krick »

pojzon wrote: post #95

Tbh the moment the author thought about hosting yourself anything to serve static pages -> it was already too much effort. There are free ways to host static pages and extremely inexpensive ways to host static pages that are visited mullions of times per month using simply services built for that.

So, the best free or extremely inexpensive way to host static pages that are visited a lot would be...?

Re: A tiny Docker image to serve static websites

#99

Post by krick »

marginalia_nu wrote: post #53
throwanem wrote: post #14

Earlier quoted context omitted.

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.

Does it? Or, rather, is it even simpler?

To host something as a docker container I need 2 things: to know how to host docker, and a docker image. In fact, not even an image, just a dockerfile/docker-composer.yaml in my source code. If I need to host 1000 apps as a docker containers, I need 1000 dockerfiles and still to know (and remember) 1 thing: how to host docker. That's 1 piece of knowledge I need to keep in my head, and 1000 I keep on a hard-drive, most of the time not even caring what's the instruction inside of them.

If I need to host 1000 apps without dockerfiles, I need to keep 1000 pieces of knowledge in my head. thttpd here, nginx to java server there, very simple and obvious postgres+redis+elastic+elixir stack for another app… Yeah, sounds fun.

Re: A tiny Docker image to serve static websites

#100

Post by mountainriver »

danuker wrote: post #61
throwanem wrote: post #45

Earlier quoted context omitted.

Docker Swarm isn't Docker; it's an orchestration service on top of Docker, that happens to have originated with the same organization that Docker does - hence the name. A few years ago Swarm looked like it might be competitive in the container orchestration space, but then Kubernetes got easy to use even for the small deployments Swarm also targeted, and Swarm has withered since. It wouldn't be impossible or probably…

Just because a project has a larger budget, doesn't mean any of it should be spent on Docker, Docker Swarm, or Kubernetes or whatever other managers of Docker that you can mention here. Fact is, for 3 servers, it would be hard to convince me of any use of Docker compared to the aforementioned deployment shell script + Debian unattended-upgrades. What problem does Kubernetes address here? So what if it is "easy to use…

Exploring technologies can give you great insight into your current practices. You are living by assumption which is a pretty weak position
Post reply on HN