A tiny Docker image to serve static websites

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"? I prefer "not needed at all".

> but also only works for a team of Adderall-chomping geniuses

Of course, not everything should be implemented by yourself. Maybe this project wouldn't have been possible at all without offloading some complexity (like the convenient NodeJS packages).

But in particular Docker and its ecosystem are only worth it when you have an amount of machines that make it worth it - when things become difficult to manage with a simple shell script everyone understands: when you have a lot of heterogeneous servers, or you want to deploy to the Cloud (aka Someone Else's Computers) and you have no SSH access.

> truisms

I don't have any experience with Kubernetes nor Docker Swarm. The reason is that the truisms have saved me from it. If you don't talk me into learning Kubernetes, I won't, unless a customer demands it explicitly.

> Has it occurred to you that it losing money for a while might have contributed to its eventual unmaintainability

It absolutely has. Maybe if the service hadn't used Docker Swarm or Docker at all, it would have lasted longer, since updating Docker would not have broken everything, since this was named a factor in the closure. And therefore, the time and money would have gone further.

That's true, but in my experience there is nothing mutually exclusive in systems being simple and systems running Docker.

Granted, you do need to learn how Docker works, and be ready to help others do likewise if you're onboarding folks with little or no prior experience of Docker to a team where Docker is used. That's certainly a tradeoff you face with Docker - just as with literally every other shared tool, platform, codebase, language, or technological application of any kind. The question that wants asking is whether, in exchange for that increased effort of pedagogy, you get something that makes the increased effort worthwhile.

I think in a lot of cases you do, and my experience has borne that out; software in containers isn't materially more difficult to maintain than software outside it if you know what you're doing, and in many cases it's much easier.

I get that not everyone is going to agree with me here, nor do I demand everyone should. But it would be nice if someone wanted to take the time to argue the other side of my claim, rather than merely insisting upon it with no more evident basis than arbitrarily selected first principles given no further consideration in the context of what I continue to hope may develop into a discussion.

Are you able to describe how you run yours? I scummed your blog but didn’t see anything about it.

> why do I need to wrap THAT of all things in a container?

If you can't see a reason why, then you probably don't need to. You probably have different needs than other people.

Many people use Docker not because of what they're doing inside of the container, but because it is convenient for tangential activities. Like lifecycle management, automation, portability, scheduling, etc.

I have several static sites in Docker containers in production. We also have dozens of other microservices in containers. We could do everything the same way, or we can one-off an entirely separate architecture for our static sites. The former makes more sense for us.

And maybe if my grandmother had wheels she'd be a bicycle. But - over a so far 20-year career of which "devops" work has been sometimes a fulltime job, and always a significant fraction, since back when we called that a "sysadmin" - I've developed sufficiently intimate familiarity with both sorts of deployment workflows that, when I say I'll always choose Docker where feasible even for single-machine targets, that's a judgment based on experience that in your most recent comment here you explicitly disclaim:

> I don't have experience with Kubernetes nor Docker Swarm. The reason is that the truisms have saved me from it.

Have they, though? It seems to me they may have "saved" you from an opportunity to significantly simplify your life as a sysadmin. Sure, your deployment shell scripts are "simple" - 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 - I started writing scripts like that in 2004, I have a pretty good sense of what "simple" means in the context where you're using it.

Meanwhile, my "simple" deployment scripts average about one line. Sure, sometimes I also have to write a Dockerfile if there isn't an image in the registry that exactly suits my use case. That's a couple dozen lines a few times a year, and I only have to think about dependencies when it comes time to audit and maybe update them. And sure, it took me a couple months of intensive study to get up to speed on Docker - in exchange for which, the time I now spend thinking about deployments is a more or less infinitesimal part of the time I spend on the projects where I use Docker.

Kubernetes took a little longer, and manifests take a little more work, but the same pattern holds. And in both cases, it's not only my experience on which I have to rely - I've worked most of the last decade in organizations with dozens of engineers working on shared codebases, and the pattern holds for everyone.

I don't know, I suppose. Maybe there's another way for twenty or so people to support a billion or so in ARR, shipping new features all the while, without most months breaking a sweat. If so, I'd love to know about it. In the meantime, I'll keep using those same tools for my single-target, single-container or single-pod stuff, because they're really not that hard to learn, and quite easy to use once you know how. And too, maybe it's worth your while to learn just a little bit about these tools you so volubly dislike - if nothing else, in so doing you may find yourself better able to inform your objections.

All that said, and faint praise indeed at this point, but on this one point we're in accord:

> If you don't talk me into learning Kubernetes, I won't, unless a customer demands it explicitly.

I did initially learn Docker and k8s because a customer demanded it - more to the point, I went to work places that used them, and because the pay was much better there I considered the effort initially worth my while. That's paid off enormously for me, because the skills are much in demand; past a certain point, it's so much easier to scale with k8s especially that you're leaving money on the table if you don't use it - we'd have needed 200 people, not 20, to support that revenue in an older style, and even then we'd have struggled.

I still think it's likely worth your while to take the trouble, for the same reasons I find it to have been worth mine. But extrinsic motivation can be a powerful factor for sure. I suppose, if anything, I'd exhort you at least not to actively flee these technologies that you know next to nothing about.

Sure, you might investigate them and find you still dislike them - but, one engineer to another, I hope you'll consider the possibility that you might investigate them and find that you don't.